Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: 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-режиме
Я, конечно, не знаю: как у вас в организации оно реально устроено; но в примере из статьи фичи Chocolatey не то что не используются, а скорее даже сломаны.
Каждое приложение стоило бы собрать в отдельный пакет с реальной версией этого ПО. А buh-software сделать метапакетом - который сам по себе ничего не содержит, кроме списка зависимостей от других пакетов.
Вместе с choco ставятся модули powershell где реализована и установка из msi, и создание ярлыков с дополнительной "магией" для, например, автоматического удаления этих ярлыков при удалении пакета. Вы же и штатную автоматизацию не использовали, и явно обновление и удаление не заскриптовали.
Не очень понятно: что вы хотите получить от Nexus? - в файловом nuget-репозитории точно так же рядом прекрасно сосуществуют разные версии одного пакета.
Это не показатель - у ботов обычно есть пастух. И успеха достигают как раз те пастухи, которые периодически впрыскивают немного человеченки в своих питомцев, говоря от их имени.
В этом-то и вопрос: AFAIK поначалу BigSur на M1 вообще всё написанное для iOS ставила из AppStore и запускала. А потом это дело прикрыли, чуть ли не из-за заботы о пользователях - дескать на совместимость не проверялось, поэтому вендору стало нужно специальные телодвижения совершать для разрешения запуска своих iOS-приложений на MacOS.
Почему iPad не на MacOS и так где-то на уровне подсознания было понятно. Тут скорее противоположный вопрос напрашивается: когда на MacOS можно будет запускать все приложения созданные для iPad? - там уже стали нормой и оконный интерфейс, и горячие клавиши, и управление "мышью".
Edge-устройства подаются как решение для приватности — данные не уходят в облако.
Edge устройства — это по определению оптимизирующие шлюзы в/из облака. Огромная LLM в датацентре генерит связный разумный текст, локальная компактная модель на edge-устройстве его озвучивает; локальные легковесные модели обрабатывают шаблонные голосовые команды "включи лампочку", а всё выходящее за рамки их шаблонов пересылают на обработку в облако и т.д. и .т.п.
Мне кажется: формат форума не близок современной аудитории. Отсюда и падение интереса, активности.
А зачем именно палатки?
Туристический коврик и спальный мешок — понятно. А зачем палатка в помещении?
У меня ощущение/подозрение, что палатки исключительно для демонстрации усердия работников руководству/акционерам/внешним наблюдателям.
Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: 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
Я, конечно, не знаю: как у вас в организации оно реально устроено; но в примере из статьи фичи Chocolatey не то что не используются, а скорее даже сломаны.
Каждое приложение стоило бы собрать в отдельный пакет с реальной версией этого ПО. А buh-software сделать метапакетом - который сам по себе ничего не содержит, кроме списка зависимостей от других пакетов.
Вместе с choco ставятся модули powershell где реализована и установка из msi, и создание ярлыков с дополнительной "магией" для, например, автоматического удаления этих ярлыков при удалении пакета. Вы же и штатную автоматизацию не использовали, и явно обновление и удаление не заскриптовали.
Не очень понятно: что вы хотите получить от Nexus? - в файловом nuget-репозитории точно так же рядом прекрасно сосуществуют разные версии одного пакета.
Это не показатель - у ботов обычно есть пастух. И успеха достигают как раз те пастухи, которые периодически впрыскивают немного человеченки в своих питомцев, говоря от их имени.
В этом-то и вопрос: AFAIK поначалу BigSur на M1 вообще всё написанное для iOS ставила из AppStore и запускала. А потом это дело прикрыли, чуть ли не из-за заботы о пользователях - дескать на совместимость не проверялось, поэтому вендору стало нужно специальные телодвижения совершать для разрешения запуска своих iOS-приложений на MacOS.
Почему iPad не на MacOS и так где-то на уровне подсознания было понятно. Тут скорее противоположный вопрос напрашивается: когда на MacOS можно будет запускать все приложения созданные для iPad? - там уже стали нормой и оконный интерфейс, и горячие клавиши, и управление "мышью".
p.s. добавил в текст "все" (приложения)
Это у них называется «вернули контроль в руки пользователей, учреждений и государственных органов»?
что такое "исходный код ИИ-модели"?
Я так понимаю, модель - это компилляция данных. Исходный код - это наборы данных на которых обучали модель?
Edge устройства — это по определению оптимизирующие шлюзы в/из облака. Огромная LLM в датацентре генерит связный разумный текст, локальная компактная модель на edge-устройстве его озвучивает; локальные легковесные модели обрабатывают шаблонные голосовые команды "включи лампочку", а всё выходящее за рамки их шаблонов пересылают на обработку в облако и т.д. и .т.п.