x86 за счёт своей истории и множества «так исторически сложилось» скорее сложный. «Байкал» как раз попытка реализовать не уникальное и одновременно не такое сложное, как x86.
что вы (в ответ на это) делаете — автоматизируете создание кусков
Wiki — это как раз и есть движок позволяющий собрать в системные знания разрозненную информацию через ссылки, include страниц и фрагментов (обеспечивая DRY); ещё и за целостностью следит: отслеживает переименования/перемещения страниц; при попытках удалить предупреждает о входящих ссылках. Конкретно упомянутый Confluence, ещё и содержимое задач в Jira позволяет расковырять. Вот это и это и есть живая документация, когда изменения в одном документе или задаче актуализируют документы зависимых компонентов.
Документация как код и автогенерация документации — прекрасные инструменты, но решают совсем другие задачи.
Не знаю, не знаю: раньше у меня были проводные вкладыши с активным шумоподавлением Samsung EO-IC500 - в любой момент можно было включить и использовать бесконечно долго. Сейчас на рынке в принципе нет ничего подобного - только беспроводные на аккумуляторах.
Ко второму пункту я бы ещё добавил, что ремонт не восстанавливает автомобиль, и понижает его рыночную стоимость. Недостаточно только стоимость ремонта компенсировать.
Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: chef, puppet, powershell dsc — когда описано некоторое состояние системы, а агент старается постоянно приводить систему к этому состоянию.
Но на самом деле автоматический перезапуск упавшей службы реализуется штатными средствами что в Windows, что в systemd в linux.
Пакеты chocolatey крохотные — там же только скрипт установки и xml с метаданными. Уверен, что скорость низкая из-за файловай шары на которой лежат непосредственно дистрибутивы. Т.е. скорее всего всё упирается в производительность сети.
Тут можно пойти разными путями:
Закидать проблему ресурсами: проапгрейдить файловый сервер/сеть или поднять ещё несколько таких же, распределив по ним нагрузку.
Оптимизировать особо тормозные дистрибутивы — в некоторых случаях скопировать дистрибутив и установить с локального (RAM)диска получается в разы быстрее, чем запускать установку напрямую из сетевой шары.
Попробовать p2p технологии: штатный виндовый BranchCashe умеет прозрачно тянуть данные не с центрального сервера, а в том числе и с таких же соседних клиентов. Нужно поднастроить и сервер, и клиенты, и порты открыть, но дальше оно само прозрачно заработает без правки скриптов/пакетов. Либо попробовать изобрести велосипед и в скрипте инсталляции качать дистрибутивы каким-нибудь пиринговым клиентом.
А это вообще работает в контексте именно рабочих мест? Я имею ввиду безагентский push-подход и Ansible в частности.
Это серверы из-за своей бизнес функции имеют постоянную сетевую доступность и покрыты мониторингом. Там безагентский push-подход в целом и Ansible в частности прекрасно работают by design: подавляющее большинство доступно и работает в любой момент времени, а что вот прямо сейчас не работает — на особом контроле.
А с рабочими местами в большинстве своём хаос: в сколько-нибудь крупной организации всегда часть рабочих мест недоступны: сотрудник на выезде с ноутом без сети, болеет, в отпуске, командировке, на обеде, встрече.
И с рабочими местами агентская pull-схема выглядит наиболее рабочей: клиент при первой же возможности тянет (синхронизирует) описание целевого состояния и автономно поддерживает конфиг/состояние рабочего места в требуемом состоянии, а не когда у админа (или Jenkins’а) доходят руки до этого конкретного клиента.
Если кратко, то истекут сертификаты не в Windows 11, а в железе.
На этапе производства на материнку устанавливаются сертификаты доверенных центров сертификации. При включенной опции SecureBoot проверяется доверие серту которым подписан загружаемый бинарник.
Таким образом подписаны не только компоненты Windows, а так же и бут-менеджеры, ядра Linux многих дистрибутивов и т.п., но реально настроено и используется в основном в случае предустановленной ОС.
Пакет с новыми сертами центов сертификации для SecureBoot должен быть подписан сертами действующих (известных прошивке EFI) центров сертификации. Windows помимо обновлений самой себя так же обновляет серты (и списки отзывов сертов) центров сертификации для SecureBoot.
Т.е. если железа не распоследнее и наисвежайшее, то одно из трёх
нужно на этом железе в ближайший год ставить актуальные обновления на Windows установленную в EFI-режиме
x86 за счёт своей истории и множества «так исторически сложилось» скорее сложный. «Байкал» как раз попытка реализовать не уникальное и одновременно не такое сложное, как x86.
У вас проблема:
что вы (в ответ на это) делаете — автоматизируете создание кусков
Wiki — это как раз и есть движок позволяющий собрать в системные знания разрозненную информацию через ссылки, include страниц и фрагментов (обеспечивая DRY); ещё и за целостностью следит: отслеживает переименования/перемещения страниц; при попытках удалить предупреждает о входящих ссылках. Конкретно упомянутый Confluence, ещё и содержимое задач в Jira позволяет расковырять. Вот это и это и есть живая документация, когда изменения в одном документе или задаче актуализируют документы зависимых компонентов.
Документация как код и автогенерация документации — прекрасные инструменты, но решают совсем другие задачи.
по всей видимости продавать предполагается в виде набора для самостоятельной сборки, а корпус нужно будет печатать самому
Не знаю, не знаю: раньше у меня были проводные вкладыши с активным шумоподавлением Samsung EO-IC500 - в любой момент можно было включить и использовать бесконечно долго. Сейчас на рынке в принципе нет ничего подобного - только беспроводные на аккумуляторах.
Может наоборот: любителю некуда деваться? - в магазине проводные либо дешмань, либо профессиональные решения.
должник - это вполне актуальный клиент банка. Это не холодный звонок.
Ко второму пункту я бы ещё добавил, что ремонт не восстанавливает автомобиль, и понижает его рыночную стоимость. Недостаточно только стоимость ремонта компенсировать.
Что значит "вместо киберпанка"? Вы хотите жить в киберпанке? 😳
Мне кажется: формат форума не близок современной аудитории. Отсюда и падение интереса, активности.
А зачем именно палатки?
Туристический коврик и спальный мешок — понятно. А зачем палатка в помещении?
У меня ощущение/подозрение, что палатки исключительно для демонстрации усердия работников руководству/акционерам/внешним наблюдателям.
Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: chef, puppet, powershell dsc — когда описано некоторое состояние системы, а агент старается постоянно приводить систему к этому состоянию.
Но на самом деле автоматический перезапуск упавшей службы реализуется штатными средствами что в Windows, что в systemd в linux.
...интересно: влезет монитор в шредер для дисков из статьи? 🤔
…и без сенсорного управления
эволюционно оно, наверное, ближе к моноблоку
Вы можете прямо ответить: в какой столбец вы записывали OpenVPN?
В статье прямым текстом было, что речь в том числе про VPN и GitLab. Впрочем, это осталось на картинке-диаграмме.
А где в этом списке асимметричная криптография: сертификаты и ssh-ключи?
Пакеты chocolatey крохотные — там же только скрипт установки и xml с метаданными. Уверен, что скорость низкая из-за файловай шары на которой лежат непосредственно дистрибутивы. Т.е. скорее всего всё упирается в производительность сети.
Тут можно пойти разными путями:
Закидать проблему ресурсами: проапгрейдить файловый сервер/сеть или поднять ещё несколько таких же, распределив по ним нагрузку.
Оптимизировать особо тормозные дистрибутивы — в некоторых случаях скопировать дистрибутив и установить с локального (RAM)диска получается в разы быстрее, чем запускать установку напрямую из сетевой шары.
Попробовать p2p технологии: штатный виндовый BranchCashe умеет прозрачно тянуть данные не с центрального сервера, а в том числе и с таких же соседних клиентов. Нужно поднастроить и сервер, и клиенты, и порты открыть, но дальше оно само прозрачно заработает без правки скриптов/пакетов. Либо попробовать изобрести велосипед и в скрипте инсталляции качать дистрибутивы каким-нибудь пиринговым клиентом.
А это вообще работает в контексте именно рабочих мест? Я имею ввиду безагентский push-подход и Ansible в частности.
Это серверы из-за своей бизнес функции имеют постоянную сетевую доступность и покрыты мониторингом. Там безагентский push-подход в целом и Ansible в частности прекрасно работают by design: подавляющее большинство доступно и работает в любой момент времени, а что вот прямо сейчас не работает — на особом контроле.
А с рабочими местами в большинстве своём хаос: в сколько-нибудь крупной организации всегда часть рабочих мест недоступны: сотрудник на выезде с ноутом без сети, болеет, в отпуске, командировке, на обеде, встрече.
И с рабочими местами агентская pull-схема выглядит наиболее рабочей: клиент при первой же возможности тянет (синхронизирует) описание целевого состояния и автономно поддерживает конфиг/состояние рабочего места в требуемом состоянии, а не когда у админа (или Jenkins’а) доходят руки до этого конкретного клиента.
Если кратко, то истекут сертификаты не в Windows 11, а в железе.
На этапе производства на материнку устанавливаются сертификаты доверенных центров сертификации. При включенной опции SecureBoot проверяется доверие серту которым подписан загружаемый бинарник.
Таким образом подписаны не только компоненты Windows, а так же и бут-менеджеры, ядра Linux многих дистрибутивов и т.п., но реально настроено и используется в основном в случае предустановленной ОС.
Пакет с новыми сертами центов сертификации для SecureBoot должен быть подписан сертами действующих (известных прошивке EFI) центров сертификации. Windows помимо обновлений самой себя так же обновляет серты (и списки отзывов сертов) центров сертификации для SecureBoot.
Т.е. если железа не распоследнее и наисвежайшее, то одно из трёх
нужно на этом железе в ближайший год ставить актуальные обновления на Windows установленную в EFI-режиме
ставить обновления прошивки материнки
не использовать SecureBoot с современными ОС
в diskpart набрать
там будут все флэшки, CD/DVD