Ранее для всех устройств, вещающих на 5 ГГц вне помещений, распространялись требования по регистрации, независимо от мощности сигнала.
И сейчас требование не распространяется только на условно-потребительские роутеры, т.е. не только частота и мощность, но и протокол. Мосты, работающие не по Wi-Fi, а по собственному радиопротоколу, номинально нужно регистрировать.
Хотел написать про законность, а, похоже, в декабре 2019 года в протоколе №19-53дсп внесли поправки, позволяющие использовать 5ГГц Wi-Fi на улице без регистрации оборудования и лицензии на частоты. Но только Wi-Fi, не другие протоколы на 5ГГц.
И небольшая ремарка по поводу нейминга - VRF или namespace? На схемах я придерживаюсь классического названия сущностей - VRF, так как оно более универсально в разрезе сетевого администрирования. Но в практикуме мы будем оперировать понятием namespace, раз уж практикум посвящен целиком Linux.
VRF и Namespace это разные сущности, и в Linux есть и то, и то. Вы настраиваете Namespace, это не VRF.
Много, потому что сервер едва ли что-то делает, а запись небольших данных с использованием надёждых файловых систем даёт значительный write amplification. Я бы хотел снизить это значение до 10 гигабайт.
Я за эти же четыре года ссд два раза поменял по независящим от износа причинам
А я за последние 12 лет трижды износил SSD до невозможности комфортного использования (многосекундные задержки при записи, медленная скорость чтения в районе единиц-десяток мегабайт в секунду), зарабатывал на восстановлении оборудования, которое затёрло NAND-флеш до дыр (переразметкой области флеша или его заменой), исследовал работу памяти и контроллеров в дешевых MicroSD-картах, чтобы уменьшить степень износа и read disturbance со временем, а также имел смартфон, который спустя множество циклов перезаписи флеша держал заряд всего от нескольких месяцев от пол года.
Так там речь не о сервере, а о диске, который работает только в режиме чтения. В целях экономии ресурса.
Речь не об экономии ресурса, а об обновлении ячеек. Заряд у любой NAND флеш-памяти утекает в тех или иных условиях (температура записи, температура хранения, износ ячейки, износ соседних ячеек в блоке (!), и т.п.), и его периодически нужно обновлять, по-хорошему. Утечка происходит и в момент чтения, т.е. постоянное чтение приведёт к невозможности чтения, если не обновлять заряд (не перезаписывать ячейки).
Если вы отвечали только в контексте обновления заряда самим диском, то я вас не так понял, он скорее всего незначителен. Но в целом ресурс записи у NAND-память очень конечен, чтобы не задумываться о нём.
Чем больше циклов записи в ячейку, тем хуже она хранит заряд (тем больше он утекает и тем чаще его необходимо перезаписывать).
Возьмите два диска одной модель из одной партии. На один запишите данные и оставьте его лежать, а другой серьёзно износите записью, затем запишите данные и оставьте желать. Первый, скорее всего, будет работать и через 10 лет, второй, скорее всего, уже через полгода будет едва восстанавливать ecc-данные и читать со скоростью улитки, если вообще.
Тормоза на смартфонах вызваны в немалой мере снижением скорости чтения и записи флеша со временем. А лет 6-8 назад вообще срок службы флеша в бюджетных моделях был около 3 лет, когда «прошивка слетала».
А вы прикидывали хотя бы приблизительно на сколько десятилетий хватает ресурса ссд без всяких экономий?
Не знаю, о каких дисках и каких объёмах вы говорите, но на моём слабозагруженном сервере после череды оптимизаций удалось достигнуть записи порядка 30-50 ГБ/день. За 4 года на диск записалось половина от гарантийного TBW — это много. На десктопе за полтора года записано 27 ТБ, тоже немало.
Технология называется 6to4, сейчас считается depricated, но по факту еще работает
Очень много где не работает, увы: шлюзы всё ещё анонсируют anycast 192.88.99.1 по BGP, но сам сервис (шлюзы) отключён. Я писал нескольким компаниям, чтобы хотя бы убрали анонс, но без ответа. Это, однако, было больше года назад, может сейчас что-то поменялось.
Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
Системные компоненты естественно с перезагрузкой. При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical. Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot? Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты. Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива). В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
Кто хочет поиграть в современные карты Doom, рекомендую Eviternity 2. Она очень длинная (не менее 20 часов для заядлого думера), и очень красивая!
Качаете последний DSDA-Doom, оригинальный DOOM2.WAD + Eviternity 2, запускаете как:
dsda-doom -iwad DOOM2.WAD -file Eviternity_II.wadРанее для всех устройств, вещающих на 5 ГГц вне помещений, распространялись требования по регистрации, независимо от мощности сигнала.
И сейчас требование не распространяется только на условно-потребительские роутеры, т.е. не только частота и мощность, но и протокол. Мосты, работающие не по Wi-Fi, а по собственному радиопротоколу, номинально нужно регистрировать.
Хотел написать про законность, а, похоже, в декабре 2019 года в протоколе №19-53дсп внесли поправки, позволяющие использовать 5ГГц Wi-Fi на улице без регистрации оборудования и лицензии на частоты.
Но только Wi-Fi, не другие протоколы на 5ГГц.
VRF и Namespace это разные сущности, и в Linux есть и то, и то. Вы настраиваете Namespace, это не VRF.
https://docs.kernel.org/networking/vrf.html
Чтобы сеть не сканировали
Много, потому что сервер едва ли что-то делает, а запись небольших данных с использованием надёждых файловых систем даёт значительный write amplification. Я бы хотел снизить это значение до 10 гигабайт.
А я за последние 12 лет трижды износил SSD до невозможности комфортного использования (многосекундные задержки при записи, медленная скорость чтения в районе единиц-десяток мегабайт в секунду), зарабатывал на восстановлении оборудования, которое затёрло NAND-флеш до дыр (переразметкой области флеша или его заменой), исследовал работу памяти и контроллеров в дешевых MicroSD-картах, чтобы уменьшить степень износа и read disturbance со временем, а также имел смартфон, который спустя множество циклов перезаписи флеша держал заряд всего от нескольких месяцев от пол года.
Речь не об экономии ресурса, а об обновлении ячеек. Заряд у любой NAND флеш-памяти утекает в тех или иных условиях (температура записи, температура хранения, износ ячейки, износ соседних ячеек в блоке (!), и т.п.), и его периодически нужно обновлять, по-хорошему. Утечка происходит и в момент чтения, т.е. постоянное чтение приведёт к невозможности чтения, если не обновлять заряд (не перезаписывать ячейки).
Если вы отвечали только в контексте обновления заряда самим диском, то я вас не так понял, он скорее всего незначителен. Но в целом ресурс записи у NAND-память очень конечен, чтобы не задумываться о нём.
Чем больше циклов записи в ячейку, тем хуже она хранит заряд (тем больше он утекает и тем чаще его необходимо перезаписывать).
Возьмите два диска одной модель из одной партии. На один запишите данные и оставьте его лежать, а другой серьёзно износите записью, затем запишите данные и оставьте желать.
Первый, скорее всего, будет работать и через 10 лет, второй, скорее всего, уже через полгода будет едва восстанавливать ecc-данные и читать со скоростью улитки, если вообще.
Тормоза на смартфонах вызваны в немалой мере снижением скорости чтения и записи флеша со временем. А лет 6-8 назад вообще срок службы флеша в бюджетных моделях был около 3 лет, когда «прошивка слетала».
Не знаю, о каких дисках и каких объёмах вы говорите, но на моём слабозагруженном сервере после череды оптимизаций удалось достигнуть записи порядка 30-50 ГБ/день. За 4 года на диск записалось половина от гарантийного TBW — это много.
На десктопе за полтора года записано 27 ТБ, тоже немало.
TLC (Triple-Level Cell) это подтип MLC (Multi-Level Cell), как и QLC. У TLC 3 бита заряда, у QLC 4.
Очень много где не работает, увы: шлюзы всё ещё анонсируют anycast 192.88.99.1 по BGP, но сам сервис (шлюзы) отключён. Я писал нескольким компаниям, чтобы хотя бы убрали анонс, но без ответа. Это, однако, было больше года назад, может сейчас что-то поменялось.
Неправильная гальваническая развязка убила пользователю компьютер: https://github.com/sipeed/NanoKVM/issues/40#issuecomment-2400855308
Я подключил устройство к сети и получил ssh root:root, доступный отовсюду: https://github.com/sipeed/NanoKVM/issues/198
Это типичная китайская поделка, увы.
Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
А зачем:
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138757647
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138761715
https://www.ferra.ru/news/tv/umnye-televizory-yandeksa-stali-aktivnee-zakhvatyvat-khakery-v-botnety-22-12-2024.htm
Системные компоненты естественно с перезагрузкой.
При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical.
Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot?
Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md
Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
Это системный компонент, поэтому нет. Полагаю, он будет в составе слоя "такой-то-desktop", который монтируется поверх rootfs.
Ubuntu'вский Snap подходит и для системных компонентов (он может «добавлять» симлинки в /usr/bin и подобные системные директории на свои snap'ы)
Это пользовательское ПО и оно устанавливается в домашнюю директорию (или какую-то общую директорию с ПО), а не в систему.
В Ubuntu Core это Snap'ы.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты.
Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива).
В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.