> usb-2-serial можно не рассматривать - даже если их два десятка включить, это
> будет меньше мегабайта,Но зачем мне этот хлам висящий просто так? Аналогично - а что если у меня допустим интеловская интеграшка а я потом туда еще радеон воткну? Мне для профилактики модуль на мег размером в ядро втулять или бежать рекомпилить систему?
> а по факту достаточно 4 драйверов, что бы покрыть 70%-90% устройств.
Меня как-то слабо утешит что мой девайс в эти 70% не вошел.
> Китайский безымянный 3-в-1 usb-to-sata/ide-3.5"/ide-2.5"
> заработал тоже без проблем,
Mass storage - относительно беспроблемная категория устройств. В первом приближении. Ну...эээ...пока мы не вспомним что там еще файловые системы бывают и задумаемся о том какие из них нам нужны. И вгружать все их сразу с их модулями по полмега... нуууу.... если там мег, там полмега и прочая - так постепенно везде и натикает.
> притом не только с hdd, но и с dvd, не требуя никаких драйверов.
> Фактически все свелось к usb wi-fi.
Фактически все свелось к подгону решения под удобный вам ответ.
> 1. Как часто вы их (usb wi-fi) меняете?
Может и не часто. Но для меня нормально взять у кого-нибудь не нyжный им свисток и задействовать под мои нужды. Какой там будет чипсет - random(). В идеале конечно атерос, но тут можно не угадать даже если адресно целиться, т.к. у многих производителей есть подлая тенденция продавать совершенно разные по устройству девайсы под одним названием. Мало с..ам букв в алфавите, на новое название девайса не хватает.
> 2. Не получится ли так, что новый usb wi-fi потребует сборки последней версии ядра?
Зависит от. Чаще всего нет. Но... но те же убунтуи например включают немало дров из staging, в том числе пачку добра для разных беспроводных и не очень рыгалтеков.
Зато потом через 30 секунд после power-up ливфлеха убунты вваливается в работоспособный десктоп, где можно и к беспроводке прицепиться в том числе. И я пять раз сделаю все что хотел и даже с взятого наобум компа, пока зилот дpoчится вприсядку с перекомпилом ядра по причине "блин, нужного модуля нет".
> 3. Всегда остается вероятность, что необходимый драйвер не будет включен основную ветку ядра.
Да. И убунтуи например еще из staging берут кучу дров. Зато потом работает. Даже с ливфлехи. Через ...цать секунд после включения. Пока зилоты сношаются с контрпродуктивными ритуальными действиями, экономя пару мегов в initramfs (имхо не самое удачное место для экономии в общем случае).
А еще мне просто удобно раскидать одно и то же ядро на пачку разноплановых машин. Ну то-есть конечно для ARM или MIPS конфиг будет достаточно сильно отличаться, но минимизировать эту возню имхо можно и нужно.
> Для мне лично важно малое время сборки - это здорово экономит время,
> когда нужно найти последнее без проблемное ядро в случае регрессии.
При поиске регрессии обычно пересобираются только измененные файлы, что при более-менее разумном диапазоне поиска занимает довольно умеренно времени.
> ядра - а это уже будет 30 минут, а на ноутбуке
> будет 1-2 часа (против 5-10 минут для подогнанного конфига).
Реально будет меньше - если у вас поменялось вообще все, это какое ж расстояние между коммитами в bisect и сколько там итераций будет? O_o
А так я столкнулся с тем что просто воспроизведение бага - может требовать полдня. Я так рад на этом фоне экономии пары минут, блин.
> ИМХО проще потратить 2-3 минуты на make menuconfig и 5-10 минут на пересборку,
> чем при каждом обновлении ядра тратить 1-2 часа.
Ну я и не трачу по 2 часа на сборку ядра. Зато убить полдня на попытку спровоцировать баг... так это... нечто более очевидное и тривиальное обычно загашено еще до меня оказывается, чаще всего вообще без bisect-ов :)
> Для меня также удобно, что я могу быстро переключаться между ядрами прямо
> из загрузчика, без шаманства с initrd и модулями.
В убунтах и дебиане в случае grub все так и получается, если ядро ставить из пакета. Удобно. Правда билдовка пакетв - вот она времени требует, это да. Потому что не параллелится в дефолтном виде.
> утверждение, что без модулей жизни нет.
Ну, мне кажется что это делает обычный десктопный сценарий контрпродуктивным, усложняет жизнь разработчиком и в целом - шаг назад в каменный век осестроения, с монолитом который даже не модульный. Как-то таким, конечно, пользовались...
> и OpenBSD вроде не позиционирует себя как end-user friendly.
Как dev-friendly - видимо, тоже.
> привычку сперва проверить, есть ли для устройства поддержка под linux и
> в каком она состоянии, а лишь потом его покупать.
Если честно - от такой практики хотелось бы уйти. Намного лучше когда машина сама разбирается что там к каким шинам понавешали. А надежно узнать на каком чипе собран вон тот вайфай свисток - довольно много возни для человека.
> Если устройство уже в руках, то забить в поиск PID:VID тоже не
> составляет большого труда.
ИМХО, машинную работу должны делать машины. У них это лучше получается.
> Ну и всегда можно собрать ядро со всеми
> включенными устройствами нужного класса и посмотреть, кто его подхватит.
Понятно все. Кроме одного: какой выигрыш дает все это дрoчивo на практике?
Ну я там могу понять device-specific оптимизации типа роутера с 4Мб флеша. Но нафуя все это на десктопе?
