Не только реклама, я прекрасно помню, что когда-то хромиум был маленьким и быстрым (или хорошо делал вид, что он быстрый). Но те времена давно прошли. Просто для оценки размеров, вот
время сборки из исходников
# genlop -te chromium
* www-client/chromium
Fri Oct 7 01:49:47 2011 >>> www-client/chromium-14.0.835.163
merge time: 17 minutes and 36 seconds.
...
Thu Dec 12 01:30:19 2013 >>> www-client/chromium-31.0.1650.63
merge time: 42 minutes and 28 seconds.
...
Mon Jan 26 00:12:21 2015 >>> www-client/chromium-40.0.2214.91
merge time: 1 hour, 15 minutes and 3 seconds.
...
Sun Apr 16 21:43:44 2017 >>> www-client/chromium-57.0.2987.133
merge time: 2 hours, 51 minutes and 47 seconds.
Сейчас Firefox потребляет в разы меньше памяти и работает, на мой взгляд, не медленнее хромиума
Да, современный уровень технологий не позволяет «получать блага первой необходимости при минимальном участии человека». Похоже, что как цивилизация мы в теории сейчас способны сделать такое, но на практике никто автоматические заводы вроде делать не умеет.
Сбросить что-то на Солнце не очень просто. Для этого придется или почти полностью погасить орбитальную скорость Земли (это втрое больше второй космической), или использовать какие-нибудь хитрые траектории вроде гравитационных маневров.
Не назвал бы лисп прямо таким функциональным (мы же о Common Lisp?). Да, присваиваний в нормальном коде не увидишь, но и функциями типа map/reduce пользоваться там не слишком удобно.
Зато, возвращаясь к теме статьи, в нём самый шикарный цикл for из всех языков, что я видел (точнее конструкция loop и библиотека iter как развитие этой идеи). Там решение задачи типа «найти такой элемент массива A, что функция F от следующего за ним элемента примет максимальное значение» будет выглядеть примерно как сам текст этой задачи. В чистом ФП же тут будет жонглирование zip, map, filter, etc. А в условном C или императивном js будет куча вспомогательных переменных и манипуляций с ними. Оба варианта как-то так себе.
А что, Dockerfile уже позволяет описать нужное состояние системы? Мне почему-то казалось, что там описан порядок действий, а в какое состояние придет система после этих действий, докеру совершенно безразлично.
Такие статьи были бы даже если бы автопилот совершал ошибок не больше, чем лучший из водителей. И это относится не только к автопилотам, мы вообще склонны искать идеальное техническое решение и не столь остро воспринимать недостатки «естественных» решений.
Если отнестись, например, к организму человека с тем же подходом, как и к продукту разума, то впору хвататься за голову — сплошные архитектурные костыли, уязвимость к куче разных факторов среды, сама концепция нормальности болезней, неспособность надежно запоминать информацию и стабильно мыслить продолжительное время. И как-то не особо это смущает общество, многие даже считают что всё так и должно оставаться. А вот к ИИ или тем же машинам требования совершенно иные.
Это обычный сайт который живёт себе на одном сервере, обновляется через git, и горя не знает. Какая тут будет выгода от Docker, кроме лишней головной боли?
Например докер дает повторяемый деплой, а git, по моему опыту, нет. Допустим, у вас после деплоя очередной версии под нагрузкой проявляется какой-то критичный баг. Сколько времени у вас займет возврат к рабочей версии, если проблема вызвана сменой версии какой-то из зависимостей (как pip/npm/watever, так и системной библиотеки)?
Совершенно необязательно, чтобы ваш адрес где-то когда-то публиковался. Например, ZMap еще когда его анонсировали пять лет назад, мог просканировать всё пространство ipv4 адресов за 45 минут. Сейчас, судя по уверениям на сайте, достаточно 5 минут и 10-гигабитного подключения.
Не вижу в этом проблемы, просто нужно понимать, что такое публичный доступ, и не надеяться на то, что этим доступом никто не воспользуется. И понимать это должны в первую очередь производители, поскольку большинство пользователей воспринимают всё связанное с компьютерами как магию, совершенно не представляют как оно работает и не имеют ни малейшего желания понимать.
Требование о передаче ключа шифрования почти нереализуемо технически, к счастью. В том же TLS используются сеансовые ключи, т.е. каждое соединение шифруется уникальным ключом.
Во — первых, почти все органы чувств принимают участие в управлении автомобилем. Ну это уже до меня написали.
Да, принимают. Просто потому, что они у человека есть. Необходимы ли они? Видимо нет, раз человек способен управлять машиной удаленно. Да, это непривычно, но возможно ведь.
Про автономность. Тут в треде речь вроде шла об автономности в плане управления. На автономность в плане обслуживания никто пока не замахивается. Там ведь не только протереть фары нужно уметь, но решать задачи типа: счистить снег/грязь, откопать машину из сугроба, заменить колесо, дотолкать до ближайшей заправки. Только не думаю, что такое будут делать, скорее изменится подход.
Сомневаюсь, но даже если и так, то микрофон и акселерометры добавить проблемы нет. При этом данные вроде положения руля, сцепления и т. п. уже сейчас используются в современных автомобилях в системах типа ESP.
Так я возражал тезису о том, что без всего перечисленного там нельзя сделать систему, выполняющую функции водителя. Человек вполне способен управлять автомобилем удаленно используя одну камеру и приводы на руле с педалями. Выходит, что этих сенсоров и приводов достаточно для управления автомобилем, просто мы сейчас не можем делать ИИ.
Представьте себе количество датчиков, разных приводов, систем самоочистки и прочих мелочей, необходимых чтобы полностью заменить водителя.
А что, в человеке-водителе так много различных датчиков? Вроде человеку для управления автомобилем из датчиков достаточно одного лишь зрения, причем монокулярного.
Если честно, не помню ничего, кроме Lyx, да и тот не очень похож на MS Word. Мне было удобнее писать в обычном тестовом редакторе. Там ведь вся сложность скрыта в шаблоне. Если он уже есть, то пишется обычный текст с достаточно простой разметкой.
Вот всё описанное можно хоть сейчас в LaTeX'e сделать. Чтобы содержимое было отдельно, а форматирование отдельно. И общую часть документов можно вынести в отдельный файл. И версионировать можно по-человечески. Но ведь хотят же MS Word и никак иначе.
Ну отчего же сразу «невозможно»? При должной упоротости можно сделать транслятор с машинных кодов в js. Хотя это, конечно, все равно оторвано от реальности.
# genlop -te chromium
* www-client/chromium
Fri Oct 7 01:49:47 2011 >>> www-client/chromium-14.0.835.163
merge time: 17 minutes and 36 seconds.
...
Thu Dec 12 01:30:19 2013 >>> www-client/chromium-31.0.1650.63
merge time: 42 minutes and 28 seconds.
...
Mon Jan 26 00:12:21 2015 >>> www-client/chromium-40.0.2214.91
merge time: 1 hour, 15 minutes and 3 seconds.
...
Sun Apr 16 21:43:44 2017 >>> www-client/chromium-57.0.2987.133
merge time: 2 hours, 51 minutes and 47 seconds.
Сейчас Firefox потребляет в разы меньше памяти и работает, на мой взгляд, не медленнее хромиума
Зато, возвращаясь к теме статьи, в нём самый шикарный цикл for из всех языков, что я видел (точнее конструкция loop и библиотека iter как развитие этой идеи). Там решение задачи типа «найти такой элемент массива A, что функция F от следующего за ним элемента примет максимальное значение» будет выглядеть примерно как сам текст этой задачи. В чистом ФП же тут будет жонглирование zip, map, filter, etc. А в условном C или императивном js будет куча вспомогательных переменных и манипуляций с ними. Оба варианта как-то так себе.
Если отнестись, например, к организму человека с тем же подходом, как и к продукту разума, то впору хвататься за голову — сплошные архитектурные костыли, уязвимость к куче разных факторов среды, сама концепция нормальности болезней, неспособность надежно запоминать информацию и стабильно мыслить продолжительное время. И как-то не особо это смущает общество, многие даже считают что всё так и должно оставаться. А вот к ИИ или тем же машинам требования совершенно иные.
Например докер дает повторяемый деплой, а git, по моему опыту, нет. Допустим, у вас после деплоя очередной версии под нагрузкой проявляется какой-то критичный баг. Сколько времени у вас займет возврат к рабочей версии, если проблема вызвана сменой версии какой-то из зависимостей (как pip/npm/watever, так и системной библиотеки)?
Не вижу в этом проблемы, просто нужно понимать, что такое публичный доступ, и не надеяться на то, что этим доступом никто не воспользуется. И понимать это должны в первую очередь производители, поскольку большинство пользователей воспринимают всё связанное с компьютерами как магию, совершенно не представляют как оно работает и не имеют ни малейшего желания понимать.
Да, принимают. Просто потому, что они у человека есть. Необходимы ли они? Видимо нет, раз человек способен управлять машиной удаленно. Да, это непривычно, но возможно ведь.
Про автономность. Тут в треде речь вроде шла об автономности в плане управления. На автономность в плане обслуживания никто пока не замахивается. Там ведь не только протереть фары нужно уметь, но решать задачи типа: счистить снег/грязь, откопать машину из сугроба, заменить колесо, дотолкать до ближайшей заправки. Только не думаю, что такое будут делать, скорее изменится подход.
А что, в человеке-водителе так много различных датчиков? Вроде человеку для управления автомобилем из датчиков достаточно одного лишь зрения, причем монокулярного.