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 — братья навек».