autonomous: denoting or performed by a device capable of operating without direct human control.
driverless: without driver at vehicle
Т.е. есть большая разница между полностью автономным, т.е. когда человек вообще не присутствует нигде, и удаленным, когда есть оператор. Тот факт, что они даже на своем сайте смешивают эти 2 понятия и продают радиоуправляемую машину по цене автономной, с рассуждениями о хайпе, плохих инвесторов и дебилов вокруг, которые не понимают важности проделанной работы, говорит о том, что автор статьи — типичный манипулятор.
А инвесторы видимо стали что-то подозревать. Ну и статья, где большинство абзацев — переливание из пустого в порожнее без фактологии и с обилием эмоций, — она явно для тех, кто не любит включать мозг.
исходная задача — обеспечить консистентность частей старого и нового конфига приложения между собой. При том что едет на хост он частями.
Мне не очень понятно, откуда взялась такая задача. В исходной статье решается задача консистентной репликации KV-хранилища. При этом под консистентностью здесь понимается вполне определенное поведение — это линеаризумость операций чтений и записи. Помимо этого здесь вводится сериализумость и транзакционное поведение. Можно доказать, что для решения этой задачи необходимо использовать консенсус, который и будет являться строительным блоком для подобного рода хранилищ.
Если не использовать консенсус в качестве базы, то можно легко показать (и Aphyr это не раз демонстрировал), что данные разъезжаются, реплики будут содержать разные данные, что может приводить к конфликтам и некорректной работе всей системы. Именно поэтому важно поддерживать согласованность данных, и консенсус — это единственный способ этого достичь.
Уровень дискуссии в стиле "всё реализовывать не обязательно в KV хранилище, а например вообще в админке" говорит о фундаментальном непонимании, что такое админка и как она взаимодействует с хранилищем. Не говоря уже про саму задачу консенсуса, свойств живучести и безопасности, и способов верификации полученного решения.
Даже не знаю, что в это комментарии наиболее безграмотно:
Предложения, начинающиеся с маленькой буквы.
Отделение отдельных предложений абзацами.
Использование выдуманных терминов: "АСИНХРОННОЕ ключ-значение хранилище", ""доехать" по репликации", "конфигфайле", "ключ-значение-хранилище".
И наконец, отсутствие понимание исходной задачи, какие гарантии хотим предоставлять с точки зрения консистентности, доступности и отказоустойчивости.
По поводу оригинальной статьи. Ее автор — небезызвестный Aphyr, который каждый раз находит проблемы в распределенных системах, начиная от документации, и заканчивая разбором крайне нетривиальных сценариев обработки запросов и моделирование сбоев системы. В данном случае можно констатировать, что etcd выстояла очень достойно и решила свою главную задачу на отлично.
Чтобы делать какие-то выводы информации более, чем предостаточно. Чтобы сделать окончательные выводы — да, нужно ждать информацию от официальных источников, включая фигурантов. Думаю, пока адвокаты запрещают разглашать подробности дела.
Осталось лишь применить эту логику к самому Маску. Тут стоит отметить один нюанс: телескопы Старлинку не мешают, однако обратное неверно. Это все равно как если бы ваш сосед зашел на вашу лужайку и устроил там барбекю. А на ваши жалобы сказал бы: "все равно ты рано или поздно продашь этот дом, надо искать другие способы".
We experimentally demonstrate imaging in the long-wave infrared (LWIR) spectral band (8 μm to 12 μm)
Переводу на человеческий. Если совсем грубо, 400nm — 700nm — это видимый спектр. В статье 8000-12000nm. Т.е. до реальных фотиков еще очень далеко.
А название настолько желтушное, насколько это вообще возможно: в оригинальной статье про телефоны вообще ни слова. Тем более про "обещания".
Our results firmly establish the potential for lightweight, ultrathin, broadband lenses for high-quality imaging in the LWIR band.
Найти потенциал для далекой инфракрасной области, и обещать избавиться от выступающих камер в смартфонах — между ними знак равно может поставить только и исключительно "журналист".
Можно и так, только это случай не trailing return type, а лишь улучшение описанной идеи. Опять же, это не защищает от хаков типа myAbs<int, nullptr>(v) от слова совсем. Т.е. если пользователь хочет докопаться, то он это сделает и его ничего не остановит.
Концепты — отличная штука. Это как раз то, что нужно разработчику, чтобы определять зависимости и условия для типов. Можно накладывать условия на сами типы через concept, а можно условие на все типы в функции через requires
С возвращаемым значением есть одна проблемка. В приведенном выше простом примере так можно делать. Однако если тип возвращаемого значения auto, то такой вариант не очень подходит.
По-моему, тут путаются 2 понятия:
Т.е. есть большая разница между полностью автономным, т.е. когда человек вообще не присутствует нигде, и удаленным, когда есть оператор. Тот факт, что они даже на своем сайте смешивают эти 2 понятия и продают радиоуправляемую машину по цене автономной, с рассуждениями о хайпе, плохих инвесторов и дебилов вокруг, которые не понимают важности проделанной работы, говорит о том, что автор статьи — типичный манипулятор.
А инвесторы видимо стали что-то подозревать. Ну и статья, где большинство абзацев — переливание из пустого в порожнее без фактологии и с обилием эмоций, — она явно для тех, кто не любит включать мозг.
Шифрование end-to-end, только концы заканчиваются на стороне Zoom серверов. Не придерешься!
Хотелось бы узнать основания, на которых построена эта модель. Согласуется ли она с реальными данными? Или это сферические кони в вакууме?
Мне не очень понятно, откуда взялась такая задача. В исходной статье решается задача консистентной репликации KV-хранилища. При этом под консистентностью здесь понимается вполне определенное поведение — это линеаризумость операций чтений и записи. Помимо этого здесь вводится сериализумость и транзакционное поведение. Можно доказать, что для решения этой задачи необходимо использовать консенсус, который и будет являться строительным блоком для подобного рода хранилищ.
Если не использовать консенсус в качестве базы, то можно легко показать (и Aphyr это не раз демонстрировал), что данные разъезжаются, реплики будут содержать разные данные, что может приводить к конфликтам и некорректной работе всей системы. Именно поэтому важно поддерживать согласованность данных, и консенсус — это единственный способ этого достичь.
Уровень дискуссии в стиле "всё реализовывать не обязательно в KV хранилище, а например вообще в админке" говорит о фундаментальном непонимании, что такое админка и как она взаимодействует с хранилищем. Не говоря уже про саму задачу консенсуса, свойств живучести и безопасности, и способов верификации полученного решения.
Даже не знаю, что в это комментарии наиболее безграмотно:
По поводу оригинальной статьи. Ее автор — небезызвестный Aphyr, который каждый раз находит проблемы в распределенных системах, начиная от документации, и заканчивая разбором крайне нетривиальных сценариев обработки запросов и моделирование сбоев системы. В данном случае можно констатировать, что etcd выстояла очень достойно и решила свою главную задачу на отлично.
Шифрованный трафик невозможно сжать. А скоро любой трафик будет шифрованный.
Чтобы делать какие-то выводы информации более, чем предостаточно. Чтобы сделать окончательные выводы — да, нужно ждать информацию от официальных источников, включая фигурантов. Думаю, пока адвокаты запрещают разглашать подробности дела.
Точно, это не верхняя граница, а верхняя медианная граница. Подписи вводят в заблуждение.
На медианную они могут влиять, но как они влияют на верхнюю границу?
Напомнило анекдот:
Осталось лишь применить эту логику к самому Маску. Тут стоит отметить один нюанс: телескопы Старлинку не мешают, однако обратное неверно. Это все равно как если бы ваш сосед зашел на вашу лужайку и устроил там барбекю. А на ваши жалобы сказал бы: "все равно ты рано или поздно продашь этот дом, надо искать другие способы".
Т.е. если я напишу:
То это будет компилироваться даже с учетом правок? Несимметрично как-то.
Это просто отлично, достижение вполне себе практическое и полезное. Только не имеющее отношение к "статье" на хабре.
В оригинальной статье:
Переводу на человеческий. Если совсем грубо, 400nm — 700nm — это видимый спектр. В статье 8000-12000nm. Т.е. до реальных фотиков еще очень далеко.
А название настолько желтушное, насколько это вообще возможно: в оригинальной статье про телефоны вообще ни слова. Тем более про "обещания".
Найти потенциал для далекой инфракрасной области, и обещать избавиться от выступающих камер в смартфонах — между ними знак равно может поставить только и исключительно "журналист".
Я к тому, что это решение по сути ничем не отличается от того, что приведено в статье.
Можно и так, только это случай не trailing return type, а лишь улучшение описанной идеи. Опять же, это не защищает от хаков типа
myAbs<int, nullptr>(v)
от слова совсем. Т.е. если пользователь хочет докопаться, то он это сделает и его ничего не остановит.Концепты — отличная штука. Это как раз то, что нужно разработчику, чтобы определять зависимости и условия для типов. Можно накладывать условия на сами типы через
concept
, а можно условие на все типы в функции черезrequires
С возвращаемым значением есть одна проблемка. В приведенном выше простом примере так можно делать. Однако если тип возвращаемого значения
auto
, то такой вариант не очень подходит.Надо было назвать dev null, тогда бы было ok.
Надо поменять местами, чтобы в рифму было: «C++ и CMake — братья навек».