В Fedora Linux 43 на системах с архитектурой x86 планируют оставить только возможность использования таблиц разделов GPT (GUID Partition Table) во всех установках Fedora, использующих UEFI. Изменение пока не рассмотрено комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora. В случае утверждения предложения поддержка установки Fedora в режиме UEFI на диски с таблицами разделом MBR (Master Boot Record) будет прекращена на системах x86, но оставлена на системах ARM и RISC-V...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63520
Федора как обычно движет индустрию вперед. Лет через 10 этот паровоз прогресса догонит и бабанта.
Нет. Тут топтание на месте было из-за AWS.
и в чем тут вперед?У нас уже несколько релизов efi грузиться с mbr - и все замечательно. Этот mbr на сервера еще лет 10 будет в полном объеме поддерживаться.
думаю шапка не поддержит этот выпендрешь
Еще б на сервера кто федору ставил, да? А новый-мажорный-рхел-на-основе-этой-федоры до тех серверов как раз через 10 лет и доедет (Но это не точно).
Fedora - это тестовый полигон для Red Hat. То, что обкатывается в Fedora, затем попадает в Шапку. Поэтому, шапка может не одобрить.
ну да, в рхел10 оно уже не попало. тоесть в лучшем случае в рхел11, тоесть несколько лет еще есть.
Зачем нужен mbr на сервере?
Во-первых - это красиво!(С):)
Легаси наверное. Но зачем на таком железе распоследняя фидора ... вопрос без ответа :)
Вопрос надо ставить так: зачем сейчас вообще MBR?
Ну покупаете к примеру типичную MicroSD карту и там будет MBR. И еще куча применений.Виртуализация домашняя опять же, возьмете VirtualBox или что там у вас, GPT и UEFI загрузка будет очень опциональная с хитрой галочкой где-то в глубине и комментарием что это не очень поддерживается / оттестировано / экспериментально при попытке включения.
В итоге ситуаций когда у обычных людей (не техногиков) появляется все больше MBR а GPT это что-то странное/ не по умолчанию. Вот затем сейчас вообще MBR. Потому что куча где все рассчитано на его применение.
Да и у техногиков тоже. Ну вот совершенно рандомный юзкейз: хотите вы посмотреть на ReactOS какой-нибудь. Скачаете, разметите загрузочный диск (пускай Rufus'ом из оффтопика). Думаете, там где-то хоть в каком-то виде всплывет GPT? Ха-ха. Все это (ОС отличные от линукса и винды, загрузочные флешки и тп) в реальности MBR.
Поддержку MBR никто и не грозится выпиливать. Переформулирую вопрос так: какая может быть причина на живой системе использовать MBR?
> Поддержку MBR никто и не грозится выпиливать. Переформулирую вопрос так: какая может
> быть причина на живой системе использовать MBR?Ну вот теперь фидору вкатить на SD карту без последствий станет заметно сложнее. Но вы можете перепартиционировать и отформатировать ее сами, только не обижайтесь когда у вас при слете питания партишн "куда-то" пропадет.
> Поддержку MBR никто и не грозится выпиливать. Переформулирую вопрос так: какая может быть причина на живой системе использовать MBR?Multiboot.
Испольховать MBR вместо совсем кала - не?... В т.ч.и на возможный будущий multiboot с другими.
EFI не поддерживает multiboot? Вот это новость!
Убирают не поддержку mbr, а поддержку загрузки с mbr на uefi системах, так как надёжность и стабильность хромает.
> Убирают не поддержку mbr, а поддержку загрузки с mbr на uefi системах,
> так как надёжность и стабильность хромает.О да, а с FAT32 разделам надёжность и стабильность ух какие будут — всем на загляденье!
Кк раз вчера писал где то тут что, это самая надёжная из распрстранённых ФС в мире, в т.ч.и из-за простоты.
вообщето загрузкой управляет не федора, а уефи, тесть сама загрузка никуда не денется, убирают из инсталлятора такой режим разбивки.
ну тоесть если кому то прямо очень надо, придётся както ставится без этого инсталлятора (ну как вариант ставить последнюю поддерживающую версию федоры и обновлять поверх). Вот рхерл вроде обновлений поверх не очень умеет, когда оно доедет до рхела 11 (ну или если решат еще отложить, до 12) то тогда надо будет руками диск бить, по всей видимости (если оно комуто надо будет почемуто, именно уефи и фат)
> у как вариант ставить последнюю поддерживающую версию федоры и обновлять поверхДа ты садо-мазо...
И уж точно никто из новых потенциальных пользователей - таким страдать не будет.
Даже просто потому что, с высокой вероятностью - не знает линукс вообще... и в ч.н.как именно тут такое садо-мазо провернуть.
> Вопрос надо ставить так: зачем сейчас вообще MBR?А GPT зачем? Для меня в нём никаких плюсов, а вот минусов хватает, начиная от совершенно необязательной мороки со всякими там конвертациями и переездами, заканчивая эстетически отвратной и изначально идиотской идеей с созданием на диске специального раздела для данных uefi, да ещё и отформатированного в FAT32 (!) раздела. В статье, вроде, надёжность MBR ругали? И кстати, нет желания спросить что-то вроде «зачем сейчас вообще FAT32»?
> начиная от совершенно необязательной мороки со всякими там конвертациями и переездамиИ ещё раз повторю: на НОВОЙ системе. Если у вас десять лет всё на MBR работает — и прекрасно, и дальше работать будет.
> изначально идиотской идеей с созданием на диске специального раздела для данных uefi
Ну да, лучше же 16-битный загрузчик в MBR в нулевом секторе, который загружает… и тут уже та ещё морока начинается.
> да ещё и отформатированного в FAT32 (!) раздела.
Нет ничего страшного в FAT32, если её применять по назначению.
> Нет ничего страшного в FAT32, если её применять по назначению.Так это как раз не по назначению - все эти лишние реално не используемые пользователем разделы.
> Ну да, лучше же 16-битный загрузчик в MBR в нулевом секторе, который загружает… и тут уже та ещё морока начинается.
Как то или же до твоего высера в MBR и 16 бит...
> И ещё раз повторю: на НОВОЙ системе. Если у вас десять лет всё на MBR работает — и прекрасно, и дальше работать будет.Ну установи туда на MBR образ с сайта...
> Зачем нужен mbr на сервере?Как раз на серверах ему и место ))
В принципе непонятен этот кипишь с mbr - это дефолт для любого нового накопителя. Даже флэшки идут с ним, а попробуйте всю ее сделать разделом - далего не все OS ее поймут.
А с gpt нужно сделать лишний шаг - подумать о выборе, а люди ленивы ))) есть mbr - и ок.
И если по hi-end серверам - так там диск целиком вставляют в том, без mbr или gpt.
Ну и конечно - совместимость, тут заказчик нашу систему на старый сервер HP решил поставить - а там нет чего модного. И нам бы пришлось тянуть две системы с efi/gpt и old bios/mbr, если бы мы отказались от efi/mbr
PS MBR - достаточен всем! ))))
Члена там. Как раз в случае с HP(E). Буквально пару-тройку лет назад разбирал, почему ядро (грубо, 10 МБ) грузится (из grub2) на HP360 gen10+ минут 5.
Да, индийские (или уже́ либерианские?) кодеры сумели внести новое слово в эмуляцию того самого int13h.
Лечить пришлось переразметкой в GPT (по принципу наименьших усилий). Патамушта можно разметить поверх имеющегося. Пусть и с толикой нетрадиционного секаса с загрузочным сектором.
> Федора как обычно движет индустрию вперед. Лет через 10 этот паровоз
> прогресса догонит и бабанта.В смысле - превращает поддерживаемые конфиги - в тыквы, снижая редхату затраты? Зачем это рхбм - понятно. Зачем остальным конвертировать проблемы рхбм в свои - не совсем.
С MBR не прогресс, а регресс. Из всех rwdasd загрузочных менее процента, остальные используется для хранения данных. Никто не будет заниматься переформатированием тысяч петабайт ради угодить федоре (сам пока на ней сижу, но буду слезать на rhel для разработчиков).
>Предполагается, что оставив в инсталляторе Anaconda только поддержку GPT на системах x86 удастся исключить аварийные завершения на стадии загрузки, вызванные сбоями efibootmgr.Заработок на поддержке не стимулирует написание качественного софта.
Заработок на софте тоже не стимулирует.
Давай проще: люди лечатся в продолжении всей жизни?
Развитие медицины не стимулирует спартанский подход к деторождению и воспитанию.
Хотя Дарвинизм и наиболее правильный подход со взгляда природы.Вот так и с софтом - любую отбраковку (ошибку аборта) по пьяни можно "недорого" (в сравнении с Евгеникой) дотащить до общественно принятых норм.
Если это не мертворождённое тело с иного прохода, требующее утилизации.
Пора x86 выкинуть и оставить ARM
А могли бы на сервера хотя бы вытолкнуть x86S, наверное, он стрельнул бы лучше, чем Itanuim.
Это решение было принято предыдущем руководством Intel, которое нечего не хотело менять.
Сейчас надежда на отмену новым гендиром Лип Бу Таном.
это уже какой по счёту гендир за пару лет?
> это уже какой по счёту гендир за пару лет?Гелсингер был инженерным специалистом, но защищал менеджмент среднего звена, когда был CEO.
Весь тормоз был в них, сокращение этих трутней, сидящих по 20-30 лет, имеющих крепкие связи и саботирующих изменения, напрашивалось очень давно. Это бич любой крупной компании.Лип Бу Тан не решился продать заводы, но начал именно с этого. По итогу, заводы всё равно будут проданы, т.к. время уже упущено. Доля в Intel Foundry у материнской компании снизится до уровня 25%. После этого могут реанимировать x86S, т.к. у Intel по сути больше ничего и нет.
Это их последний шанс.
Зачем нужен ARM, когда есть RISC-V?
И чего там коммерчески успешного?
> И чего там коммерчески успешного?32-битные микроконтроллеры за 10 центов произвели небольшой отраслевой фурор. Теперь можно 32-битное ядро с DMA и нормальной моделью памяти - по цене ссаного PIC-10 под который на си то нормально програмить - не того.
В Raspberry Pico есть RISCV ядра.
А вон на гитхабе отшнуровка алибабы выложили сорцы 64-бит апликушников. И уже энное количество SoC взяло их в оборот.
В куче новых GPU от AMD и Nvidia - RISCV ядра под сервисные процы.
Вполне коммерчески успешные вещи если что.
> А вон на гитхабе отшнуровка алибабы выложили сорцы 64-бит апликушникоГде и Чего именно выложили?
(но, будущее - всёравнё за x86, если его как следует "приправить")
> Где и Чего именно выложили?На гитхабе сорцы 64-бит апликушников относительно жирных, https://github.com/XUANTIE-RV/ - 906 и 910 выводки. Это не самый топ что у них есть, но как видите - китайцы начинают поддемпинговывать. И конечно завалят мир своими процами. А вон например что они сделали http://web.archive.org/web/20250316191548/https://www.thereg.../ - не, на этого сорц не дадут вообще всем, но - желающим они свои ядра лицензируют только в путь, и видимо условия гламурнее ARM ибо есть энное количество SoC где накопипастили XuanTie'ских ядер уж сколько лезло на кристалл - и пошли продавать.
А так - во https://en.wikipedia.org/wiki/RISC-V - там довольно длинный список реализаций.
> (но, будущее - всёравнё за x86, если его как следует "приправить")
Горбатого могила исправит. И я посмотрю как вы им подвинете вон того - за 10 центов - хоть откуда-нибудь. В свое время 8086 в эмбед версии даже был - но это ужасный изврат.
>И чего там коммерчески успешного?ESP32C3
> когда есть RISC-V?А когда он есть? Нет его. Разговоров много, выхлопа - 0
Брал одноплатник banana pi f3 для тестов и он довольно неплохо себя показал. Браузеры работают, компиляторы C, C++ и Rust есть, даже софт в репозиториях обновляется, чего еще не хватает? А производительность это дело наживное.
Вот когда наживут производительность, тогда и поговорим. А пока —
> для тестов
Если винды, причём все, и даже DOS не ставятся - в топку.Ну и кому то как импортозамещение не поддходит же, не говоря уже про т.б.в военку,
если он не дурак или предатель...
>> когда есть RISC-V?
> А когда он есть? Нет его. Разговоров много, выхлопа - 0Его уже - миллиарды. Надо просто разуть глаза.
Ты всегда можешь выкинуть дома x86 и оставить только ARM.
И на работе не забудь - но тебе будет сложно найти работу без x86.
> Ты всегда можешь выкинуть дома x86 и оставить только ARM.
> И на работе не забудь - но тебе будет сложно найти работу без x86.И тут гугло такое, вместе с амазоном - с серваками на ARM - наседающим EPYC на пятки - чокаво?! А ему на пятки наседают RISCV чипы как раз. Алибаба вон то для своих серверов ищначально настрогали. А потом частью немного поделились, как замануха.
Вперёд-вперёд. Потом расскажешь, как там в дивном новом мире, с учётом того, что не в гугле, ни в амазне ты не нужен. Ну и да, у гугла серверов на x86 - десятки тысяч штук, если не сотни, арм там в пределах статистической погрешности. У амазона та же ситуация.
Для i/o bound задач арм топчик. Дёшево и сердито, именно что в гугле и амазоне. Они и сами пользуются, и другим рекомендуют. Мы эти инстансы тысячами за сутки оборачиваем. И мы далеко не самый крупный клиент. Вот когда дело доходит до расчетов, то тут да, x86_64 и только. Но подготовка данных, ci/cd и прочий шум только на армах — так дешевле.
> Для i/o bound задач арм топчикУже смешно. Хотя конечно смотря какой i/o bound, если всё на оффлоудах - там и STM32 с выносным руткомплексом зайдёт.
> Вперёд-вперёд. Потом расскажешь, как там в дивном новом мире, с учётом того,
> что не в гугле, ни в амазне ты не нужен.Мне тоже нормуль будет. Воткну в какой-нить жирный 64-бит RISCV с PCIe AMDGPU, и порядок. И вот мой workstation-ng по сути и готов. С полностью открытым системным уровнем конечно, а не uefi от винтеля в виде мутноблобов, всякими boot guard, ME и PSP - вот уж нафиг покупать это все за свои деньги. Я готов доплатить премиум за отсутсвие у меня в системе всего этого ацкого крапа от винтеля и его последователей.
...и мои воркфлоу на конкретную систему команд уже не привязаны никак. Debian на RISCV как раз портировали. Что мне еще для счастья надо? :)
> Ну и да, у гугла серверов на x86 - десятки тысяч штук,
> если не сотни, арм там в пределах статистической погрешности. У амазона
> та же ситуация.Судя по тому как они барыжат инстансами и это уже на серьезных щах обсуждают, бенчмаркают всякие форониксы и проч - я не удивлюсь если для новых внедрений эти господа вообще пошлют AMD и Intel курить бамбук и будут юзать то что надевелопали in-house для сеья и своих нужд. Это почему-то удобнее. Особенно когда системный уровень полностью профаченый нефиксабельными блобами - в котоорых багов так по жизни более чем хватает, желаемое поведение типа интеграции в СВОЕ управление инфрой хрен прикрутишь и проч.
Ну давай, найди мне арм, который по производительности способен тягаться с х86. Шоб стоил столько же, а лучше дешевле.Х86 платформа, на которой все просто работает. Но армовцам нужно продавать свои поделия, вот и пытаются убедить всех что х86 плохой, неэкологичный, а наш арм может работать от картошки и сделан из бамбука.
Десятки лет все работало, но кто-то все равно недоволен. Прямо как с иксами, ха!
Apple silicon?
Первый абзац прочти, в идеале весь текст целиком.
> Первый абзац прочти, в идеале весь текст целиком.Они прекрасно задвигают x86 маки по производительности. По цене - примерно 1 фиг.
>> Первый абзац прочти, в идеале весь текст целиком.
> Они прекрасно задвигают x86 маки по производительности.Ещё бы сравнивать x86 маки пятилетней давности с современными M-процами. А ты с современным какинтошем на современных же x86 процах сравни!
> По цене - примерно 1 фиг.
Вот именно, что по соотношению цена/производительность M-процы всё также отстают, единственное в чём они относительно хороши, это в энергоэффективности и в том что под них подгоняют ОС с работой этой их модной быстрой памятью, но эти все фичи нивелируются тем, что разрабы софта забивают болта пользоваться ими, из-за чего мифические приросты и меганагибаторство x86 случается только в синтетических тестах в вакууме и то не всегда.
> Ещё бы сравнивать x86 маки пятилетней давности с современными M-процами. А ты
> с современным какинтошем на современных же x86 процах сравни!Там вон в бенчах фороникса - ARM на пятки EPYC с 192 ядрами, на минуточку, сел. У вас
> Вот именно, что по соотношению цена/производительность M-процы всё также отстают,
> единственное в чём они относительно хороши, это в энергоэффективности и в том
> что под них подгоняют ОС с работой этой их модной быстрой
> памятью, но эти все фичи нивелируются тем, что разрабы софта забивают
> болта пользоваться ими, из-за чего мифические приросты и меганагибаторство x86 случается
> только в синтетических тестах в вакууме и то не всегда.А таки у x86 дико переусложненное, кривое и глючное управление питанием с 1 стороны и позорная энергоэффективность при всем этом - с другой. В планшетах и смартах он за это уже вымер, а теперь и в ноутах начинает понемногу поджимать...
Это лишь способ увеличения гру... то есть ЧСВ. Причём независимо от пола. Причём только для "своих", остальные не поймут.
> Х86 платформа, на которой все просто работаетДавно же уже не так - EFI и дажен w7, не говоря уже про XP и ниже, как читал: не запустить же на новье, с видеоадптерами аналогично.
У arm все очень плохо с производительностью в десктопных играх, так что домашний сегмент перевести не получится, пока arm не придумает что-то что нивелирует это. А для остальных задач вы уже сейчас можете использовать arm процы вполне успешно.
Если перекомпилировать в натив арма то разницы мало, если правильно настроить слой совместимости то провал и 20% не будет.
Всё зависит от того насколько заморочиться.
Но в мак.производительность арм не может, хуже чем последние интелы качегарят в киловатник.
Ну не расчитана архитектура на 4+ггц 24\7\365
> У arm все очень плохо с производительностью в десктопных играх, так чтоУ армов всё очень плохо с производительностью _везде_. Это унылая эмбедовка, которая ориентирована на низкое энергопотребление в простое, а в CPU-bound задачах она при сходной производительности (да-да, придётся подбирать более высокие частоты, возможно больше ядер, чем у сопоставимого x86) выстреливает по потреблению даже выше x86 за счёт слабой оптимизации потока исполнения.
> У армов всё очень плохо с производительностью _везде_. Это унылая эмбедовка,Вон там унылая эмбедовка, в инстансах гугли и амазона. Или вон там в бенче фороникса плотно на пятки село EPYC'у dense c его 192 ядер. Нормальная такая эмбедовка. Или кому-то надо иногда букмарки апдейтить чтобы не выглядеть тупо.
>В качестве причины прекращения поддержки MBR упоминается низкая надёжность загрузки в подобных конфигурацияхЧо? 0_0
А возможность апгрейда MBR-систем хоть сохранится? Хотя, федоро-разрабы уже столько всего «замечательного» наобещали, что может и не понадобится…
Никто не убирает поддержку mbr, убирают возможность загрузки системы с них на uefi системах. Вы хоть читайте новость дальше заголовка прежде чем комментировать.
Загрузиться, конвертировать и жить дальше, но Федоровцы запрещаютЬ
> Никто не убирает поддержку mbr, убирают возможность загрузки системы с них на
> uefi системах. Вы хоть читайте новость дальше заголовка прежде чем комментировать.Ок, вот есть ПК с uefi. Uefi в legacy-режиме, на нём работает система, которая грузится с mbr-диска. Это является «установкой Fedora, использующей uefi» или нет? По мне, так новость написана так, что не вот и разберёшься, чего сказать хотели, да ещё приправлена перлами от федороразрабов про «низкую надёжность».
> Никто не убирает поддержку mbr, убирают возможность загрузки системы с них на
> uefi системах.Ну и да, вот это вот и называется «убрать поддержку mbr», ибо чего там на незагрузочном диске — по большому счёту плевать.
Да на системах ARM и RISC-V и УЕБИ не сильно-то и нужно. Там Das U-Boot самое то.
Ещё как нужно, иначе будет невозможно делать универсальные дистрибутивы и придётся делать отдельный образ под каждую железку. UEFI уже нормально работает в ARM[64] и RISC-V. Серверные платформы требуют UEFI и ACPI.> Там Das U-Boot самое то.
U-Boot также поддерживает UEFI.
> U-Boot также поддерживает UEFI.В нем это - опционально собирается. Можно собрать и без этой Wintel'овской дряни.
> Ещё как нужно, иначе будет невозможно делать универсальные дистрибутивы и придётся делать отдельный образ под каждую железкуээ, так для этого всё и делается
Заметьте, это тестовый дистр. Они до 2025 года держали поддержку дисков с разметкой MBR.
Разработчики эволюционировали до состояния, когда перестали понимать даже MBR...
Жаль, что какой-нибудь MBR64 не запилили... На простых разбивках можно вообще ни одного сектора не терять. Допустим sda1 - это swap с сектора 0 (mkswap к такому более бережно относится, чем mke2fs). С EBR можно аналогично, если в extended размещать ext2/3/4.Страшновато такое юзать... но если действовать аккуратно, то брат будет жить ;)
>это swap с сектора 0А код первоначальной загрузки куда?
Дык туда же, в сектор 0. Загрузчик там же и был. В разделах linux swap (swapspace2) и ext2/3/4 первый килобайт примерно не трогается (или забит нулями). Вот как раз туда и помещается MBR (загрузчик+информация о разделах).Загрузчик смотри сам - либо stage1 сразу, а про stage 1.5 думай сам (может он и не нужен как таковой в том же lilo)... Или типовой загрузочный сектор, который передаёт управление первому сектору активного раздела (этот активный раздел будет 2,3 или 4 и там как обычно всё).
Формально да, в EFI на загрузчике немного экономия есть, но по факту линукс её не использует. Ядро сразу (без EFI-загрузчика) обычно не стартует, т.к. тяжело поменять командную строку загрузки при необходимости и менюшек красивых не будет.
Вроде бы мин.в в Японии издавно BIOS был и OS стартовала сразу не в 16 битах,
- и где они все... никому особо в мире были не нужны. Обратная совместимость вещь такая...
Кто у них устанавливает sysctl kernel.yama.ptrace_scope
0
пакет default-yama-scope удалил все равно 0.
Ядро? Перерыл патчи ничего не нашел. Как это узнать? По дефолту должно быт 1. Чат гпт от моих вопросов глючить стал, бред какой-то выдает.
он всегда бред выдает, если он чем-то оказался полезен, то в это день объявляется праздникпро хелоу ворд конечно не идет речи
Не понял, нафига MBR в системах с UEFI если там по дефолту GPT?
Чтобы не лочило на неподписанном загрузчике и при неправильных флешках.
Ну, выпилят и выпилят. gdisk давно mbr в gpt преобразовывать умеет.
И, вроде бы, речь идёт только о загрузочных разделах, а не о полном выпиле поддержки дисков с mbr.
Именно, люди дальше заголовка прочитать не удосужились просто.
> Ну, выпилят и выпилят. gdisk давно mbr в gpt преобразовывать умеет.Ну и как ты загруишь затем ОС - только MBR поддерживающие?...
P.S.
Или даже просто заменишь на что то из них - эту, когда решишь это.
И т.б.далеко не все NIX'ы поддерживают не MBR, подозреваю даже - только про MS дырявые.
Когда же наконец-то выпилят поддержку tty ?
Ты про ядерную консоль? Консоль не трожь!
Ядерная консоль, это та что в чемоданчике, с красной кнопкой?)
Ну тоже вариант. Там она тоже через /dev/tty :)
Людям делать нечего и они начинают ломать работающие вещи.
"Испортил хорошую вещь." (C)
Забавно конечно, из новости в новость красношапка показывает свое отношение к пользователям, а фанатов меньше не становится)
> разнобой поддержки MBR в прошивкахПусть тогда и ACPI удаляют отовсюду, вот там настоящий зоопарк.
> отсутствие должного тестирования в Fedora
Ну дак тестируйте. А то такие - Мы удаляем потому что мы не тестируем должным образом.
Нашли ещё одно место, где надо срочно всё сломать... К чему бы это?
> В качестве причины прекращения поддержки MBR упоминается ... отсутствие должного тестирования в Fedora"Мы не работаем, потому что мы не работаем".
Так а тестировать кто будет? Пользователям оно нафиг не надо. Я вот очень слабо представляю себе ситуацию, когда железка с UEFI, я ставлю систему и такой «не-не-не, не надо GPT, давай MBR, как деды завещали».
>Так а тестировать кто будет?Пользователи.
>Пользователям оно нафиг не надо.Их мнение в федоре никто не спрашивает.
>Я вот очень слабо представляю себе ситуацию, когда железка с UEFI, я ставлю систему и такой «не-не-не, не надо GPT, давай MBR, как деды завещали».
Банально вынуть хард и засунуть в другую пекарню. В которой MBR. Или запустить эту же систему под QEMU. В котором... ну ты понял.
Вроде gpt лучше. Но в винде только её и используют. Я другого не понимаю причём тут решение команды Федоры. В gparted встроена эта функция. Я часто разработчиков особо не понимаю.
> Прекращение поддержки MBR также снизит нагрузку на людей, занимающихся поддержкой пользователей, упростит сопровождение и тестирование.Короче, как всегда: решение не такое, как пользователям лучше, а такое, как самим создателям лучше.
Девеломпент ради (и для) девелоперов.