> Аналогично, тоже инсталлеры не юзаю. Максимум для чего может быть нужен инсталляционный
> диск(или флешка) - это загрузиться в работоспособную консоль чтобы из нее
> установить grub (если это на x86 происходит).Я пришел к выводу что искренне ненавижу как сделаны Live у дебиана и убунты - это загружается какое-то совершенно непотребное время. Особенно на некоторых компах где скорость чтения с usb в режиме загрузки, до того как linux kernel kicks in - издевательская.
Поэкспериментировав я заметил что просто "инстальнутый на флешку" демьян с защелкнутым readonly свичом флехи в общем то норм работает, особенно если чуток подрихтовать, стартует куда шустрее тех ливок, а заодно можно сразу более потребное окружение, скажем с уклоном в data recovery или оживление систем. Это ессно нишевая штука для себя, average joe именно это именно так не понравится. Это же и с убунтой катит.
> В случае всяких там ARM скорее потребуется железный программатор для вписывания загрузчика.
Не обязательно.
1) Часть грузится с SD карты. У некторых типа Sunxi сие имеет приоритет над остальным и это довольно удобно в вон тех целях. Тот же Sunxi (часто бывающий в Mele).
2) У многих SoC есть boot ROM умеющий usb-device или хотя-бы UART. Заливаем uboot через ЭТО, програмим u-boot'ом сам себя в NAND/карту или что там у вас, а дальше уже и основную тушку ОС не особая проблема. Такой дизайн платформы делает ее "unbrickable". Sunxi и упомянутые железки относятся к этому классу: Sunxi можно полностью загрузить через usb, да и тот v5 через uart - аналогично.
3) Иногда существовавший лоадер можно убедить вгрузить то что надо. А иногда бывают и вовсе забавные хаки. Скажем некоторые дают uboot под видом кернела, и Uboot Lv2 - делает то что на самом деле хотелось.
> Полностью поддерживаю и разделаю ваш подход.
...поэтому на мощном 64-бит компе получается - звездолет. Быстрый. Эффективный. Крутой. С ним я могу почти что угодно. Ну, вон, takeover железок. Перестроив uboot, kernel, OS. По сути я могу уровень OEM-а.
>>Лол, вы преувеличиваете. Просто иногда лошадь объективно сдохла.
> Применительно к какой-нибудь экзотике типа того же MIPS - я с вами соглашусь.
Ну вот у меня есть пара железок на которые теоретически можно вкатить САБЖЕВЫЙ дебиан. Практически у них 64-128 рамы, и это на минималках, и винч внешний. А лоадер как раз вот - древний, в mainline uboot вот именно ЭТОГО - нет, и так что осовременнить сие под современный boot sequence с DTB не то чтоб совсем нельзя но - костыли.
> Но объявлять сдохшей лошадью самую массовую за последние три десятка
> лет архитектуру x86-32 - это тоже на мой взгляд преувеличение.
Ну ее _совсем_ еще и не того этого. Gradual phase-out технологии. Делать свой мозг проблемами тридцатилетней давности, исключительно во имя compat - надоело даже майкрософту (где-то в районе восьмеры они UEFI затребовали, древние компы его не умеют). А у них дофига денег и порядка 70К чтоли сотрудников по всей планете. У дебиана не столько ресурсов.
> Да и одноплатных компов на armv7 выпущено и продано огромное количество. И
> используют их для своих экспериментов как раз всякие самодельщики,опенсорс двигающие.
А они вроде armhf пока и не грозились вытряхнуть окончательно, больше на armel покушаются, это более древняя штука.
> Хотябы например роботостроители. И там как раз наиболее важна совместимость как
> железная так и софтовая,а не новизна процессора.
Зачем при DIY совместимость? Это создаваемое с ноля решение - там можно что угодно делать в принципе. Compat нужен только если нужно нечто внешнее, и оно прибито на гвозди к энной платформе, но это - хреновый выбор сразу на старте создания железки. Если нечто навязывает конкретный выбор, это отольется в будущем, когда например захочется платформу померять.
Скажем сейчас пришествие RISCV SoC. В основном 64 бит конечно. И если я захочу сменить в энный момент в некоем проекте 32 бит armhf на RISCV-64 а это не получится - упс, я подложил сам себе конкрентую свинью на фазе архитектуры и имплементации. И теперь откушаю последствий своего решения. Мне это надо?
> и выкинуть управляющий комп (типа той же Raspberry, которые часто как
> раз armv7) и поменять его на более дорогой только из-за
> прихоти сборщиков дистрибутива,
Ну вот да - на allwinner есть 10-баксовые одноплатники, и они 32-битные, но это armhf конечно, armel там пофигу. И даже если они долбанутся совсем и armhf тоже спишут - есть еще около 5-6 лет времени подумать как маневрировать дальше. Т.е. это не "most pressing issue" хоть как.
> я что-то сомневаюсь что сами дебианщики на каких-нибудь
> arm-ноутбуках сидят.
В случе armhf несколько полегче - там железок под сборку пакетов помощнее все же можно найти. Но они по RAM by design ограничены. У 64-бит нет таких проблем, так что некоторые RISCV-64 например уже могут как воркстейшн и билдферма сойти даже для жирных пакетов.
> Вот и поддержку дропать надо именно когда железо скопытится.
Ну вот x86-32-only компы уже и повымерли в массе своей. Я видел 64-бит AMD уже примерно 20 лет назад. Электролиты в активно юзаемых мамках столько все же не живут в >= pentium. Оно и мрет естественным способом. Там как раз кризис вышел: "классические" электролитические капы оказались не готовы к ТАКИМ аппетитам - и пульсациям - и дохли как мухи осенью. А производители lowESR респины капов смогли далеко не сразу, а лишь когда OEM заваленые по гарантии стали требовать что-то придумать с этим. Постепенно вообще полимерные капы придумали но это привилегия новых, топовых мамок в основном.
А у одноплатников обычно - керамика, она более-менее вечная. Вот эти более живучие будут.
> что у них почти перестали качать и x86-32 и особенно armv7 варианты.
Armhf наверное качают. Во всяком случае я - точно :). А x86-32 кмк сильно сдулся в последнее время. Говоря за себя - я кажется за всю жизнь не пробовал debootstrap в x86-32. И меня оно если и интересует - то как специфичный тесткейс к моему скрипту генерации образов, а для себя я это юзать ессно не юзаю и не планирую.
> Кстати, у меня отлично работают несколько штук Raspberry Pi c процом armv7,
> хотя им уже лет десять.
У меня целые выводки одноплатников, в основном Sunxi и немного рокчипов - и не только для себя, я такой байдой для других балуюсь for fun and profit. В целом они весьма живучие штуки. Некоторым более 10 лет, но даже там "armhf". В этом смысле первые малины были залет уже на момент выпуска, с их дохлым ARMv6 ядром - ибо armhf это ARMv7 - он на тот момент уже был. И это косяк броадкома - они слили хомякам лежак который был ТАДАМ - чипами для DVD плееров! У которых системный проц это второстепенная штука для рисования меню, а основа основ это GPU. Так что этот изврат после старта аж бутявится с ROM GPU - а потом оно может и врубит ARM для этого вашего линуха если захочет. Такая структура boot sequence означает что мало того что все прибито на гвозди к FAT32 - так еще уйти от блобов boot sequence довольно сложно. Ибо сперва надо GPU раскочегарить вообще, а из него ARM. А на GPU изначально из блобов по сути целая операционка подымается, работающая side by side с ARM и живущая своей жизнью.
> в то что у этого проца только два выхода аппаратного pwm. Если
> у робота больше моторов то уже аппаратные костыли требуется добавлять.
Я в это точно не упираюсь - ибо смог STM32 и могу развесить его на UART/i2c/spi в помощь вон тому.
И кстати, систeмд с его вачдог апи - оказался довольно полезен для трекинга живости важных прог координирующих вот это все, как бы там не плевались вон те господа. Нокия в мобилах сравнимое делала, но в N900 был апстарт и им пришлось изобретать свой вел с квадратными колесами. Он есно отлично ездит только по лестницам - в офисе Нокии. Остальное - упсъ. Они называли это "mission control".
