Intel выкидывает легаси

https://wiki.manjaro.org/index.php/Pamac

Ну вот, например. Linuxhint — это не сайт манжары.

Я не вижу здесь ничего про кодеки.

Ну, то что документация в впопенсорце сосёт, это давно всем известно. Тем не менее, это гуй для установки кодеков (и всего остального).

Ну, то что документация в впопенсорце сосёт, это давно всем известно. Тем не менее, это гуй для установки кодеков (и всего остального).

Ну вот мы и вышли на круг. UX сосет, везде придется лезть в дебри документации чтобы выяснить какого черта твое любимое порно с говорящими грибами не работает.

Ну, то что документация в впопенсорце сосёт, это давно всем известно. Тем не менее, это гуй для установки кодеков (и всего остального).

Ну вот мы и вышли на круг. UX сосет, везде придется лезть в дебри документации чтобы выяснить какого черта твое любимое порно с говорящими грибами не работает.

На самом деле, нет. В манжаре ты просто ставишь VLC и кодеки подтягиваются. А в Fedora ты идёшь пердолить RPMFusion.

И я не уверен, что в других ОС лучше. В венде ровно та же хрень, тоже без VLC хрен чо посмотришь. Про мак не знаю.

Да-да, а генту ставится тремя командами.

Производители серверного оборудования по-прежнему предоставляют прошивки в виде образов с DOS, иной раз — как единственный возможный (или как минимум рекомендуемый) вариант.

Выходит что SeaBIOS в любом случае не нужен, уже хорошо

Тут есть нюанс: при схеме coreboot --> X --> GRUB2 --> OS , где в роли X выступает SeaBIOS - этот GRUB2 располагается на HDD ; в случае же казалось бы упрощённой схемы coreboot --> GRUB2 --> OS - GRUB2 разумеется должен храниться в SPI Flash вместе с coreboot'ом . При этом с упрощённой схемой мы получаем следующие недостатки:

1. GRUB2 существенно жирнее чем SeaBIOS - в результате остаётся мало свободного места в SPI Flash / CBFS которое на вес золота;
2. SPI Flash'ный GRUB2 окажется менее функционален чем HDD'шный, т.к. при сборке (по причине той же жирности) приходится жертвовать модулями чтобы влезло;
3. GRUB2 менее удобен в использовании по сравнению с KISS-бутменюшкой SeaBIOS;
4. GRUB2 не умеет вот так запросто грузить виртуальные дискеты наподобие KolibriOS как это делает SeaBIOS - вообще без предварительной настройки, просто обнаруживая файлы дискет .img в CBFS;
5. GRUB2 сложнее собирать и настраивать чем SeaBIOS

Тогда уж надо брать GRUB 2 в качестве Coreboot payload. Только вот ничего кроме Линукса на такой конфигурации запускаться не будет. То есть не будут работать различные BSD, Solaris, Haiku, Windows и т.д..

Винда - да, скорее всего отвалится; но те люди кто ставят себе coreboot - винду гоняют разве что в виртуалке. А вот BSD и Solaris должны работать т.к. выглядят достаточно продвинутыми чтобы обходиться без услуг БИОСа; про Haiku не знаю - она ещё и из беты не вышла

В итоге получается вендор лок на Линукс что далеко от концепции свободного ПО

Вендорлок скорее будет если ещё упростить и взять ядро Linux в качестве payload'а («полезной нагрузки») coreboot - но это упрощение ожидаемо приведёт к ещё большему пердолингу и лишениям...

В-общем, есть веские причины, почему именно coreboot --> X (SeaBIOS) --> GRUB2 --> OS с использованием SeaBIOS'а в качестве полезной нагрузки coreboot'а - является наиболее популярным (~89.91% по состоянию на 03.12.2022) вариантом среди коребутчиков. И дело не в том, что все так любят подноготную БИОСа (всякие 16 бит там) - просто SeaBIOS оказался самым удобным и минималистичным X

удалении MBR в установщике и удаление VESA я взял из роадмапа федоры

Значит, могут появиться некие патчи «удалить MBR» и «удалить VESA» которые смёржат в Fedora - но в теории ничто не помешает тебе ревёртнуть их, вопрос лишь в том какими усилиями - придётся ли пересобирать федорин ISO, например

Лучше конечно перейти на нормальный дистр, желательно без-SystemD'шный: например - Artix Linux, дружелюбный арч без SystemD со свежайшим софтом и прекрасной стабильностью, там-то пользователя никогда не обидят

А вот BSD и Solaris должны работать т.к. выглядят достаточно продвинутыми чтобы обходиться без услуг БИОСа

Вы в упор игнорируете пробоему совместимости интерфейса BIOS <-> загрузчик ОС. Загрузчик в MBR не может обходиться без услуг BIOS потому что другого ничего нет. Он должен грузить компоненты ОС с диска через int 13h и т.д..

Как вы себе представляете 64 битный BIOS? Запускать MBR в 16 битной виртуальной машине? Или вместо int 13h придумать некие новые 64 битные интерфейсы? Как тогда будут согласовываться эти интерфейсы между разными вендорами ОС?

Вопрос в том, зачем тебе пердолиться? Я перешел на UEFI и у меня все хорошо.

Ну, то что документация в впопенсорце сосёт, это давно всем известно.

От авторов которая - как правило да. Но это с лихвой компенсируется хаутушками от энтузиастов. Copy-paste команды и пояснение, что делает каждая - коммунизм просто. Лучше только правильно написанный плейбук готовый - git clone, ansible-playbook «и вы можете откинуться на спинку кресла» :)

Шинда этим похвастаться не может, людям просто лень делать скриншоты и на них подрисовывать всякое.

Загрузчик в MBR

А зачем это на уефи-системах?

SakuraKun выступает против UEFI и за BIOS в виде SeaBIOS аргументируя тем что он менее раздутый.

Софт на электроне и снэпы их не напрягают, а потно бороться за килобайты в прошивках и загрузчиках - это пожалуйста...

Прошивка на флеш-память пишется, которая весьма ограничена. Там может быть и 512 Килобайт памяти( https://libreboot.org/docs/hardware/d945gclf.html ) и что-то жирное просто не поместится.

Как тогда у проприетарщиков всё помещается?

Софт на электроне и снэпы их не напрягают,

Кстати, я тут узнал мимоходом, сколько релизится мажорных релизов электрона за год. И был несколько обескуражен.

Если под виндами у приложений нет выхода, кроме как таскать по копии электрона с собой…

То под линуксом электрон можно использовать общий… Если бы не тот факт, что каждому приложению может потребоваться своя версия. Например, в репах Арча их сейчас пять штук. Каждая при установке занимает почти 200 метров. Итого гиг с куста, если вам не повезло пользоваться соответствующим софтом.

А у них на той плате ничего не поместилось. Насколько я помню, с проприоритарщиной там даже с sata-диска загрузится нельзя, а с libreboot можно.

То под линуксом электрон можно использовать общий

Да-да, а получится, как с попыткой экономить место на за счёт shared-библиотек.

«Виртуально имеем 3 миллиона долларов, а реально - двух проституток и одного старого тридвараса» :)

Прямо как с DirectX, .net, Жабой и минимум двумя-тремя Пистонами. То есть, ничего нового.

DirectX выходит по 7 мажорных версий за год?

DirectX выходит по 7 мажорных версий за год?

Нет, но их нужно несколько штук в системе иметь.

А DirectX то тут при чём? Это ж графическое API, ещё и не переносимое, а не система программирования. И самое главное, непонятно зачем такие вещи, как Electron, Java и .NET вообще нужны. Переносимость только на словах, в винде 100500 разных версий дотнета, а с джавой не лучше. Не проще уж взять какой-нибудь Qt, слинковать его статически или таскать so с собой и получить почти полную кроссплатформенность без зависимостей(Qt весит сильно меньше джавы)?

Java

Вполне себе есть java-софт, который без доработок одинаковым способом запускается под win/mac/lin. Выглядит страшненько, но работает же. И оно не такое заторможенное, как вебня.