Там на самом деле несколько моментов. Дуров в интервью говорил о том, что бэкдоры используются спецслужбами правительств разных стран, не утверждая что это законно или незаконно.
Законодательство U.S. по разному трактует уровень допустимого, в зависимости от того находится оно внутри или снаружи страны. FISA Section 702 разрешает слежку за негражданами за пределами U.S. без ордера суда.
Сотруднику Дурова некие люди, похожие на агентов, предлагали добавить некую open-source зависимость в Telegram, что по его мнению могло быть бэкдором.
А потом те же Google придумали CT, где браузеры периодически отсылают им сертификаты куда недавно ходили. Отличие лишь в том, что процесс асинхорнный и поэтому менее нервный для юзера.
Начальник это вообще не про задачи - на это есть специалист. Начальник руководит людьми - вот эти все пресловутые soft skills, подковерные игры, кумовство, взятки, откаты и т.п. Как их заменить LLM вообще не понятно.
Переделывать что ? Запросы , конфигурацию субд , инфраструктуру ?
Всё переделывать, есть повезёт. Потому, что менять по частям выйдет ещё дороже.
Если серьёзно, то LLM это ещё один инструмент в копилке инженера, а не замена ему. Сейчас есть ярые оптимисты и такие же пессимисты, но нормальные применения им находятся где-то между. С LLM можно быстро экспериментировать на уровне PoC.
Там ещё с точки зрения структуры их бизнеса и экономики интересно https://www.rusprofile.ru/id/1207700132804 . Как им удаётся вообще хоть что-то разрабатывать и внедрять?
С другой стороны, на таких дорогах и трафик не тот, чтобы можно было сэкономить на автоматизации - пара грузовиков в сутки? Речь скорее идёт о маршрутах, где фуры табунами ходят и для этого нанимаются десятки тысяч водителей.
Что вы будете делать , если документация не подтверждается экспериментально?
Переделывать) Относительно перфоманса и вообще цифр LLM врут регулярно, это больное место. Они видят цифры из бенчмарков в Интернете, но не учитывают контекст. Поэтому легко могут насоветовать и потом закодить химеру, которая будет еле ворочаться.
С другой стороны, если дело не зашло слишком далеко, то переделывать с помощью тех же LLM довольно дешево.
хочет чтобы ему персонально добавили CA в его хранилище для конкретного пользователя
Формально, они пытались решить проблему с отзывом сертификатов, обещая обновлять данные в своём хранилище чаще, чем это делают пользователи - в системных.
На практике это означает полный контроль за списком доверенных сертификатов со стороны компании, выпустившей браузер. Те, кто ожидает подвох лишь со стороны УЦ, не видят гораздо более простых механизмов.
Mozilla, например, от поддержки OCSP отказывается как раз потому, что при обращении к сайту браузер пользователя лезет по OCSP проверять отозванность сертификата и тем самым сервер OCSP может сделать вывод "раз с такого-то IP-адреса запрашивают сведения о сертификате для домена, значит, вероятно, кто-то с этого адреса пытается посетить этот сайт
Firefox отправляет кучу телеметрии, а тут внезапно совесть проснулась?
Что касается неудобства набора, в программах легко можно сделать автозамену — дефис, отбитый пробелами, заменяется на тире, окруженный цифрами — на короткое тире. В Word так было испокон веков
Скрытый текст
Вы имеете ввиду "In the beginning was the Word" или программу, которая появилась в конце прошлого века?
Да, но зачем автоматизировать то, что не решает ни каких реальных проблем?
Человекам не писать лень, а печатать неудобно. В чем вообще реальная практическая польза от правил, придуманных в эпоху, когда люди писали гусиными перьями, и ни каких компьютеров с клавиатурами ещё в помине не было?
Мне больше нравится ООП'шный кот: cat.eat(food), - поскольку и до и после это все тот же самый кот.
food.beEatenBy(cat) выглядит отвратительно - не хочу смотреть на еду после того как она была проглочена котом.
В функциональном подходе в результате кормления получается суперпозиция из нового кота и ошибки. Натурально как ящик Шредингера. После нескольких кормежек вы наверное смогли бы получить за это изобретение премию по физике, гору ящиков и стадо клонированых котов (если получится их от туда извлечь).
Погодите, управление транзакциями это уровнь application, а не domain. От репозитория в домене лежит только его интерфейс, а конкретная реализация живет в infrastructure. Модели не используют репозитории - это привилегия use case'ов.
Rich модели в домене это не про то, чтобы вообще всю бизнес логику в них притащить. Логика, связанная с бизнес сценариями, живёт в юз кейсах - т.е на уровне application (собственно ради чего мы его и пишем). Domain (уровень данных если угодно) отвечает за обеспечение базовых гарантий, ограничений, инвариантов - на уровне этих самых данных. Объекты домена могут быть связаны только с другими объектами домена и ни чем другим больше. Поэтому в них нет и не может быть ни какого IO.
Реализовывать логику средствами базы или приложения это вопрос не к DDD. Здесь выбор между 2-tier и 3-tier архитектурами, у которых есть отдельные причины и аргументы.
Организации покупают лицензии пакетами на год вперёд и потом в конце еще получают скидки за фактически активированые.
Но на практике невозможно точно спрогнозировать потребность, поэтому обычно берут с запасом и потом пытаются распихать излишки между сотрудниками под разными предлогами. В итоге массы таких ключей за бесценок всплывают на маркетплейсах.
. 4 колеса диаметрами от 12 до 20, двс, дисковые тормоза через 2х контурную систему через гур на педали, руль это колесо, а не штурвал, управление педалями и ручкой КПП, 2-3 зеркала, ну вы поняли...
Да, вы описали конструктор из магазина детских игрушек, который даёт некое представление об устройстве. Но это не про езду по дорогам общего пользования. Между ними пропасть в виде технических регламентов, стандартов безопасности, экологических норм, испытаний, сертификации и т.п. В итоге, в реальном конечном изделии вы не имеете права поменять практически ни чего, если это не было предусмотрено производителем.
На этом уровне для интернет-магазина сейчас даже фреймворк не нужен - любая LLM напишет код для абстрактной витрины с корзиной минут за 15. Но вопросы безопасности, надёжности, бухгалтерского и складского учета, обработки персональных данных и т.п., что требуется в реальной жизни, оставляем за скобками.
Эксперимент необходим для практического подтверждения логически обоснованных предсказаний.
Там на самом деле несколько моментов. Дуров в интервью говорил о том, что бэкдоры используются спецслужбами правительств разных стран, не утверждая что это законно или незаконно.
Законодательство U.S. по разному трактует уровень допустимого, в зависимости от того находится оно внутри или снаружи страны. FISA Section 702 разрешает слежку за негражданами за пределами U.S. без ордера суда.
Сотруднику Дурова некие люди, похожие на агентов, предлагали добавить некую open-source зависимость в Telegram, что по его мнению могло быть бэкдором.
Из-за возможности клонирования второго фактора, которая существует в TOTP, но практически исключена в WebAuthn/Passkeys.
А потом те же Google придумали CT, где браузеры периодически отсылают им сертификаты куда недавно ходили. Отличие лишь в том, что процесс асинхорнный и поэтому менее нервный для юзера.
Начальник это вообще не про задачи - на это есть специалист. Начальник руководит людьми - вот эти все пресловутые soft skills, подковерные игры, кумовство, взятки, откаты и т.п. Как их заменить LLM вообще не понятно.
Всё переделывать, есть повезёт. Потому, что менять по частям выйдет ещё дороже.
Если серьёзно, то LLM это ещё один инструмент в копилке инженера, а не замена ему. Сейчас есть ярые оптимисты и такие же пессимисты, но нормальные применения им находятся где-то между. С LLM можно быстро экспериментировать на уровне PoC.
Там ещё с точки зрения структуры их бизнеса и экономики интересно https://www.rusprofile.ru/id/1207700132804 . Как им удаётся вообще хоть что-то разрабатывать и внедрять?
С другой стороны, на таких дорогах и трафик не тот, чтобы можно было сэкономить на автоматизации - пара грузовиков в сутки? Речь скорее идёт о маршрутах, где фуры табунами ходят и для этого нанимаются десятки тысяч водителей.
Переделывать) Относительно перфоманса и вообще цифр LLM врут регулярно, это больное место. Они видят цифры из бенчмарков в Интернете, но не учитывают контекст. Поэтому легко могут насоветовать и потом закодить химеру, которая будет еле ворочаться.
С другой стороны, если дело не зашло слишком далеко, то переделывать с помощью тех же LLM довольно дешево.
Shopify, BigCommerce, WooCommerce и т.п.
Формально, они пытались решить проблему с отзывом сертификатов, обещая обновлять данные в своём хранилище чаще, чем это делают пользователи - в системных.
На практике это означает полный контроль за списком доверенных сертификатов со стороны компании, выпустившей браузер. Те, кто ожидает подвох лишь со стороны УЦ, не видят гораздо более простых механизмов.
Firefox отправляет кучу телеметрии, а тут внезапно совесть проснулась?
Скрытый текст
Вы имеете ввиду "In the beginning was the Word" или программу, которая появилась в конце прошлого века?
Да, но зачем автоматизировать то, что не решает ни каких реальных проблем?
Человекам не писать лень, а печатать неудобно. В чем вообще реальная практическая польза от правил, придуманных в эпоху, когда люди писали гусиными перьями, и ни каких компьютеров с клавиатурами ещё в помине не было?
Мне больше нравится ООП'шный кот: cat.eat(food), - поскольку и до и после это все тот же самый кот.
food.beEatenBy(cat) выглядит отвратительно - не хочу смотреть на еду после того как она была проглочена котом.
В функциональном подходе в результате кормления получается суперпозиция из нового кота и ошибки. Натурально как ящик Шредингера. После нескольких кормежек вы наверное смогли бы получить за это изобретение премию по физике, гору ящиков и стадо клонированых котов (если получится их от туда извлечь).
Погодите, управление транзакциями это уровнь application, а не domain. От репозитория в домене лежит только его интерфейс, а конкретная реализация живет в infrastructure. Модели не используют репозитории - это привилегия use case'ов.
Rich модели в домене это не про то, чтобы вообще всю бизнес логику в них притащить. Логика, связанная с бизнес сценариями, живёт в юз кейсах - т.е на уровне application (собственно ради чего мы его и пишем). Domain (уровень данных если угодно) отвечает за обеспечение базовых гарантий, ограничений, инвариантов - на уровне этих самых данных. Объекты домена могут быть связаны только с другими объектами домена и ни чем другим больше. Поэтому в них нет и не может быть ни какого IO.
Реализовывать логику средствами базы или приложения это вопрос не к DDD. Здесь выбор между 2-tier и 3-tier архитектурами, у которых есть отдельные причины и аргументы.
Организации покупают лицензии пакетами на год вперёд и потом в конце еще получают скидки за фактически активированые.
Но на практике невозможно точно спрогнозировать потребность, поэтому обычно берут с запасом и потом пытаются распихать излишки между сотрудниками под разными предлогами. В итоге массы таких ключей за бесценок всплывают на маркетплейсах.
Штраф за переход по ссылке в неположенном месте.
А не получится как с часами: у кого есть один телескоп, тот точно знает как устроена Вселенная, у кого их два - тот никогда ни в чём не уверен?
Да, вы описали конструктор из магазина детских игрушек, который даёт некое представление об устройстве. Но это не про езду по дорогам общего пользования. Между ними пропасть в виде технических регламентов, стандартов безопасности, экологических норм, испытаний, сертификации и т.п. В итоге, в реальном конечном изделии вы не имеете права поменять практически ни чего, если это не было предусмотрено производителем.
На этом уровне для интернет-магазина сейчас даже фреймворк не нужен - любая LLM напишет код для абстрактной витрины с корзиной минут за 15. Но вопросы безопасности, надёжности, бухгалтерского и складского учета, обработки персональных данных и т.п., что требуется в реальной жизни, оставляем за скобками.