На Xbox 360 можно установить только специальные HDD, предназначенные именно для консоли: диск идентифицируется через ATA Identify, данные которого дублированы на диске с цифровой подписью Microsoft. Произвольный диск установить невозможно.
Для HDD от WD старых моделей давно есть программа HDDHackr, позволяющая подменить ATA Identify на произвольный дамп от другого диска, а для SSD до недавнего момента ничего не было. Разработчик утилиты fatxplorer поисследовал разные SSD и написал утилиту, подменяющую ATA Identify на контроллерах разных производителей.
Удобство в том, что перепрошивка контроллера не требуется — программа только меняет данные. Не нужно искать подходящий файл-загрузчик для типа памяти, и т.п.
Пока она заточена только для xbox (не позволяет загружать произвольные дампы), но я написал сообщение, что такая функция была бы полезна многим, не только для xbox.
Ранее для всех устройств, вещающих на 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 Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
Надёжней делать дамп всего блока ATA Identify:
sudo sg_sat_identify -H /dev/sdX, из комплекта sg3-utils.А
smartctl --identify /dev/sdXпокажет дамп в человекочитаемом виде.На Xbox 360 можно установить только специальные HDD, предназначенные именно для консоли: диск идентифицируется через ATA Identify, данные которого дублированы на диске с цифровой подписью Microsoft. Произвольный диск установить невозможно.
Для HDD от WD старых моделей давно есть программа HDDHackr, позволяющая подменить ATA Identify на произвольный дамп от другого диска, а для SSD до недавнего момента ничего не было.
Разработчик утилиты fatxplorer поисследовал разные SSD и написал утилиту, подменяющую ATA Identify на контроллерах разных производителей.
Удобство в том, что перепрошивка контроллера не требуется — программа только меняет данные. Не нужно искать подходящий файл-загрузчик для типа памяти, и т.п.
Пока она заточена только для xbox (не позволяет загружать произвольные дампы), но я написал сообщение, что такая функция была бы полезна многим, не только для xbox.
Кто хочет поиграть в современные карты 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'ы.