Команда архитекторов — это нормально и не так уж и редко встречается на практике. Даже если у вас не очень большой проект, ну, скажем, миллиона два строк (строки — плохой критерий, конечно, но примерно представить средний по больнице проект можно), то уже одному человеку становится сложно.
Лиспов без скобочек много (например, dylan, ну а если немного упороться, то можно посчитать python за лисп — norvig.com/python-lisp.html), и все они хуже лиспов со скобочками. Скобочки вообще неважны — в джаваскрипте их ГОРАЗДО больше, чем в лиспе (если брать common lisp), и ничего, люди живут как-то.
Нормального разработчика нормальные языки не пугают — ни лисп, ни хаскель, ни R. Common lisp крайне практичный инженерный язык, нет смысла делать что-то другое «на идеях лиспа», ибо получится явно хуже. Если хочется более понятного и «чистого» (в смысле научности) языка — то есть scheme, тоже очень достойная штука, особенно если это racket, но в плане библиотек и общей взрослости CL всё-таки на голову выше.
И да, синтаксис — это не идея лиспа, это следствие. Если синтаксис поменять, то лисп как раз потеряет одну из своих основных идей — регулярность/консистентность.
У Раста система типов может показаться особенной тем, кто не в курсе про GADT, например (ну и да, в расте ADT, без G), про зависимые типы. Ну то есть кто застрял в примитивных крестоподобных системах типов.
В целом не совсем понятно, почему не ограничиться lexical scope (со всеми традиционными батарейками в виде HOF и так далее) и агентами (как в Oz, например, ну или даже как в эрланге), или вообще пойти по пути хаскеля (раз уж и так что-то типа GADT и pattern matching уже есть). Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.
Ну да ладно, лень спорить. То, что раст не единственный, где думают про конкурентность, и то, что система типов у него хоть и не самая простая, но вполне себе обычная для 21 века (даже всяких agda не надо вспоминать, сравнения с простым хаскелем достаточно) — ну собственно я в этом убедился, ну а большего мне и не надо.
Прочитал документацию по Расту, не вижу абсолютно ничего особенного в его системе типов, можете раскрыть мысль? Насчёт «единственного языка, который решает проблему параллельного программирования» также непонятно.
Я б в жизни не догадался, что можно выстрелить в воздух и это как-то сработает. Это же игра, а не реальность.
Ну то есть чтобы сделать выбор, надо таки понимать, что он вообще есть.
Видео смотреть надо долго (34 минуты), а доклад со слайдами я прочитаю за пять-десять минут, причём пропуская ненужную мне воду (ну то есть может оказаться, что вообще в минуту уложусь).
Let's Encrypt не имеет никакого отношения к приватному ключу. Как и всегда, приватный ключ (да и CSR целиком, да и коммуникации по ACME-протоколу, ибо приватный ключ никогда не должен покидать той машины, на которой он генерился, то есть если ты что-то подописываешь, то должен это делать на той машине, на которой генерил ключ) должен генериться на том сервере, с коротого происходит запрос на выписку сертификата.
1. https://letsencrypt.org/how-it-works/
2. https://letsencrypt.org/docs/faq/ + поиск по слову private key
При желании можно использовать приватный ключ повторно, но единственная причина так делать — отсутствие автоматизации. Ну и естественно это ухудшает безопасность — если мы постоянно используем один и тот же ключ, посылая пакетики известной структуры, то сложность взлома шифрования уменьшается.
На данный момент индустрия может бороться с атаками только усложнением процедур. Чем процедура сложнее — тем её сложнее делать человеку, соответственно, без автоматизации либо это не будут делать (у скольки людей настроен и работает hpkp? «работает» — это когда можно не бояться окончания срока действия сертификата и когда можно отозвать сертификат без проблем с клиентами, учитывая все кешинги, CDN-ы и подобные вещи), либо будут делать с ошибками (типичный пример — hsts).
Одной из проблем всей системы является централизация, то есть вот те самые корневые CA, которым договорились доверять. Уже сейчас это реально проблема как со стороны секурити (собственно, dane, hpkp, ocsp stapling и так далее одной из причин имеют ту самую централизацию), так и со стороны хайлоада. Одной из основных нерешённых вещей является процедура отзыва сертификата (вероятность компрометации приватного ключа вовсе не такая уж маленькая, как многие думают, а текущая тенденция всё виртуализировать/контейнезировать только повышает её), короткий лайфтайм — это попытка решить эту проблему наиболее простым способом.
Эмм, не понял, откуда следует радость и ожидание появления сертификатов на 10 лет.
Форум сократил максимальный лайфтайм с трёх лет до двух лет. Изначально хотели сократить до года, но там какие-то интересные кейзы вылезли (не разбирался), и чтобы долго не спорить, сошлись на двух годах.
Тенденция к сокращению лайфтайма есть, и она правильная, ибо сертификаты должны быть довольно короткие, по причинам, изложенным в документе от let's encrypt. И если причину секурити можно (и даже нужно) побеждать всякими oscp, hpkp, dane etc, то вторую причину (давление на автоматизацию реньювала) никуда не денешь. А отсутствие автоматизации настолько угроза для всей системы TLS, что если грубо не давить на общество, форсируя эту самую автоматизацию, то развал всей системы видится очень так неиллюзорно и в довольно краткосрочной перспективе (пяток лет).
Тут лучше таки разобраться с Cloudflare, и получить сертификаты для входных точек у них самих. Ибо коннект пользователя будет на CDN entry point, и сертификат нужен именно на тот домен.
1. https://letsencrypt.org/2015/11/09/why-90-days.html
2. «CAB Forum Ballot 193, which was proposed by Entrust, will place a new limit on maximum lifetime for all publicly trusted SSL certificates. The new limit will be 825 days – that’s two years with some padding built in to allow for renewal and replacement – and will come into effect on March 1st of 2018.
Currently, the maximum SSL certificate validity period is 3 years (39 months to be exact), and CAs will continue to issue such certificates until the new ballot comes into effect.»
Твоё заоблачное ЧСВ не делает тебя умником во-первых.
Во-вторых никто тебя не ненавидит здесь.
А минусы тебе лепят за твой стиль общения — ты просто не уважаешь собеседника, с тобой общаться неприятно.
С одной стороны, даже вот такой вот несистемный частный набор «советов» имеет смысл, с другой — ну в целом-то гораздо больше профита даёт системное обучение фундаментальным вещам, под нормальными названиями.
В общем всем, кому статья показалась годной, рекомендую прочитать хотя бы https://www.info.ucl.ac.be/~pvr/book.html, толку будет в разы больше, как мне кажется.
Автор вообще дико ошибается в оценке стоимости оверхеда контейнеризации во-первых, во-вторых сильно ошибается в важности расхода машинных ресурсов (в той области, про которую он говорит). В итоге предлагает решать проблему, которой на самом деле нет.
Нормального разработчика нормальные языки не пугают — ни лисп, ни хаскель, ни R. Common lisp крайне практичный инженерный язык, нет смысла делать что-то другое «на идеях лиспа», ибо получится явно хуже. Если хочется более понятного и «чистого» (в смысле научности) языка — то есть scheme, тоже очень достойная штука, особенно если это racket, но в плане библиотек и общей взрослости CL всё-таки на голову выше.
И да, синтаксис — это не идея лиспа, это следствие. Если синтаксис поменять, то лисп как раз потеряет одну из своих основных идей — регулярность/консистентность.
У Раста система типов может показаться особенной тем, кто не в курсе про GADT, например (ну и да, в расте ADT, без G), про зависимые типы. Ну то есть кто застрял в примитивных крестоподобных системах типов.
В целом не совсем понятно, почему не ограничиться lexical scope (со всеми традиционными батарейками в виде HOF и так далее) и агентами (как в Oz, например, ну или даже как в эрланге), или вообще пойти по пути хаскеля (раз уж и так что-то типа GADT и pattern matching уже есть). Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.
Ну да ладно, лень спорить. То, что раст не единственный, где думают про конкурентность, и то, что система типов у него хоть и не самая простая, но вполне себе обычная для 21 века (даже всяких agda не надо вспоминать, сравнения с простым хаскелем достаточно) — ну собственно я в этом убедился, ну а большего мне и не надо.
Ну то есть чтобы сделать выбор, надо таки понимать, что он вообще есть.
А так-то надо и то, и другое.
1. https://letsencrypt.org/how-it-works/
2. https://letsencrypt.org/docs/faq/ + поиск по слову private key
При желании можно использовать приватный ключ повторно, но единственная причина так делать — отсутствие автоматизации. Ну и естественно это ухудшает безопасность — если мы постоянно используем один и тот же ключ, посылая пакетики известной структуры, то сложность взлома шифрования уменьшается.
Одной из проблем всей системы является централизация, то есть вот те самые корневые CA, которым договорились доверять. Уже сейчас это реально проблема как со стороны секурити (собственно, dane, hpkp, ocsp stapling и так далее одной из причин имеют ту самую централизацию), так и со стороны хайлоада. Одной из основных нерешённых вещей является процедура отзыва сертификата (вероятность компрометации приватного ключа вовсе не такая уж маленькая, как многие думают, а текущая тенденция всё виртуализировать/контейнезировать только повышает её), короткий лайфтайм — это попытка решить эту проблему наиболее простым способом.
Форум сократил максимальный лайфтайм с трёх лет до двух лет. Изначально хотели сократить до года, но там какие-то интересные кейзы вылезли (не разбирался), и чтобы долго не спорить, сошлись на двух годах.
Тенденция к сокращению лайфтайма есть, и она правильная, ибо сертификаты должны быть довольно короткие, по причинам, изложенным в документе от let's encrypt. И если причину секурити можно (и даже нужно) побеждать всякими oscp, hpkp, dane etc, то вторую причину (давление на автоматизацию реньювала) никуда не денешь. А отсутствие автоматизации настолько угроза для всей системы TLS, что если грубо не давить на общество, форсируя эту самую автоматизацию, то развал всей системы видится очень так неиллюзорно и в довольно краткосрочной перспективе (пяток лет).
2. «CAB Forum Ballot 193, which was proposed by Entrust, will place a new limit on maximum lifetime for all publicly trusted SSL certificates. The new limit will be 825 days – that’s two years with some padding built in to allow for renewal and replacement – and will come into effect on March 1st of 2018.
Currently, the maximum SSL certificate validity period is 3 years (39 months to be exact), and CAs will continue to issue such certificates until the new ballot comes into effect.»
Во-вторых никто тебя не ненавидит здесь.
А минусы тебе лепят за твой стиль общения — ты просто не уважаешь собеседника, с тобой общаться неприятно.
С одной стороны, даже вот такой вот несистемный частный набор «советов» имеет смысл, с другой — ну в целом-то гораздо больше профита даёт системное обучение фундаментальным вещам, под нормальными названиями.
В общем всем, кому статья показалась годной, рекомендую прочитать хотя бы https://www.info.ucl.ac.be/~pvr/book.html, толку будет в разы больше, как мне кажется.