Управление модулями ядра мышкой в графике и с плюшевыми мишками, весёлыми пони, конфетными радугами и добрым волшебником

lsmod, lspci тебе в руки и делай.

не буду оригинальным: нет, и не нужно.

На самом деле, нужно, но не в том качестве, как обычно бывает у подобных утилит в linux - проще в консольке все посмотреть, чем продираться через глюки полурабочего, неоттестированного, нефункционального ГУЯ (а после преодоления всех препон выяснится, что именно нужная тебе опция из мана - не поддерживается в гуе)

Типа диспетчера устройств?

Извечная проблема Linux для любителей поней и радуг в том, что подмножество людей, который могут наваять интерфейс и подмножество людей, которым он нужен, никак не пересекаются.

Нужно идти по пути SUSE: нанимать за деньги из второго подмножества, чтобы пилили тебе YaST с блекджеком и шлюхами.

и делай

И вот в этом нашем Линуксе всё так: нихрена нет, но можно сделать:(

нихера нет

Все есть, только в терминале.

Так всё есть уже. Посмотри в сторону QProcess и QFile в Qt5. Нарисуй парсер текстового вывода на ++.

И вот в этом нашем Линуксе всё так: нихрена нет, но можно сделать:(

Кому, кроме тебя, это будет нужно?

Очень полезная была бы утилита, жаль что никто не сделал! С удовольствие бы пользовался. Мне кажется что можно было бы быстро сделать на электроне, надеюсь кто нибудь возьмется.

Вам, любителям консоли, вообще ничего не нужно. Вы готовы банальный миднайт хейтить.

управлять модулями мышью

В чём именно состоит «управление модулями»? Что ты собрался с ними делать?

краткое описание этих модулей

Краткие описания модулей есть в самих модулях. Но навряд ли ты имел в виду настолько краткие описания. Другой информации просто нет в природе в письменном виде. Она только в головах авторов модулей.

определять используется ли на практике какой модуль или он просто загружен в память

Это невозможно определить в общем случае.

Что ты собрался с ними делать?

Загружать/выгружать. Делать это на «постоянной основе». Это как минимум.

Другой информации просто нет в природе в письменном виде.

Вот только когда я вижу очередной dsa5738, то вполне могу нагуглить, что это устаревший драйвер асимптотного сепулькария.

Это невозможно определить в общем случае.

Скорее всего это так. И что?

Делать это на «постоянной основе»

Я бы просто на горячие клавиши повесил. А так, наверное, это не сложно написать на каком-нибудь pygtk или pyqt. Заодно и разберёшься.

то вполне могу нагуглить

Один-два-десять вполне можно нагуглить. Но сейчас у меня в системе для текущего ядра 3400 модулей. Не забывай, что модули появляются и пропадают, их описания от ядра к ядру могут меняться, как и действия, которые они производят. Прикинь объём работы и сопоставь с тем временем, которое ты потратил на поиск информации об одном модуле.

И что?

Твоя проблема не решаемая, вот что.

вот что.

Хочешь я тебе расскажу древнюю программистскую мудрость? Она гласит: ежели случаем столкнёшься ты с проблемой невозможною, то не пускайся в ратный бег аки выхухоль на стены амбразурные, а пройди мимо ибо редко возможно сделать невозможное.

Один-два-десять вполне можно нагуглить.

а зачем их гуглить? меня устроило бы и кратенькое из modinfo. вот только почему это до сих пор никто не сделал, тоже не понимаю. модули лежат по понятным папкам (ну, более менее понятным - net, disk, cpu, graphics и т.д.) - это будут категории, кратенькое описание получить из modinfo, ну и пару кнопок - загрузить, выгрузить. хотя бы даже на консольном ncurses. оно же наглядное будет, я хоть узнаю, какие модули у меня вообще есть. но это всё сложно будет, ессно легче в консоли 3400 раз написать modinfo чтоб просто узнать, что же у меня за модули там есть.

А зачем их выгружать, если они без багов работают? И загружаются автоматически.

А зачем им быть если они нафиг не нужны?
Вычистить и убедиться что автоматически более не загрузятся.

оно же наглядное будет, я хоть узнаю, какие модули у меня вообще есть. но это всё сложно будет, ессно легче в консоли 3400 раз написать modinfo чтоб просто узнать, что же у меня за модули там есть.

find "/lib/modules/$(uname -r)" -name '*.ko' | while read fname; do modname=$(basename $fname); modname=${modname%.*}; echo Module $modname; modinfo -F description $modname; echo; done | zenity --text-info

Вычистить и убедиться что автоматически более не загрузятся.

А-а-а, так ты оптимизатор.

Тогда будет достаточно ярлыка для открывания modprobe.conf в любимом gui-редакторе, если так нужен gui. С прибитыми заготовками на макросах с типовыми строками.

Ты хорошо подтвердил неудобство использования кучи мелких утилит, бесполезных по отдельности.

неудобство использования кучи мелких утилит, бесполезных по отдельности

Но это же unix-way as is.

Не-а. Все эти утилиты не нужны без друг друга. Ни одна из них не выполняет никакой полезной задачи. Юниксвейный принцип «одна задача, но хорошо» не выполняется.
Это раз, а во-вторых срать я хотел на юниксвейность. Мне подавай удобство, рационализм и адекватность.

удобство

Это субъективно.

рационализм

Unix-way рационален.

адекватность

Сложно сказать.

Да, считать мышь чем-то ужасным это точно к адекватности никак не относится.
Забей. Тебе программа такая не нужна. Я тебя услышал.

Сложно представить, зачем это надо, поэтому вряд ли такая утилита когда-либо появится

неудобство использования кучи мелких утилит

Да, можно и так сказать. Только вот если представить ситуацию, что тебе и мне понадобилось посмотреть в GUI на список модулей с описаниями, то я это уже сделал, а ты всё ещё нет.

Жди. Может, кто-то когда-нибудь и сподобится.

Я как-то тоже ждал двухпанельник с GUI. Не дождался. Сейчас они уже есть, но у меня уже нет в них надобности.

посмотреть в GUI на список модулей с описаниями,

Это, честно, формальный подход. GUI для такого не нужен, это всего лишь неинтерактивный список, который проще изучать с помощью grep и less. Тем более, он жутко убого по дефолту вылез в маленьком окне, хорошо хоть позволено размер менять (но по дабл-клику по заголовку оно не разворачивается)

Если считать это прототипоим - то явно видна бесполезность.

Пусть ТС формализует требования, опишет use cases, для чего бы ему понадобился GUI. Я примерно догадываюсь, и вижу в этом большой объем работы, который оправдать можно только оплатой, потому что таким формошлепством никто фо фан заниматься не будет.

Сложно представить, зачем это надо, поэтому вряд ли такая утилита когда-либо появится

Здравая идея борьбы с ветряными мельницами почему-то всегда натыкается на реалии сопровождения и обновления мёртвого кода.

нанимать за деньги из второго подмножества,

из первого :)

Кстати, судя по последним версиям яста, в сусе уже не так все радужно со специалистами, имхо. Изначально надо было держать вектор на то, что бы яст можно было ставить на другие дистрибутивы, делать абстрактную прослойку. А сейчас востребованность его мала, и интерес у самой суси пропал за это платить, походу. Ибо любой васян делает с нуля в очередной раз регулировку звука, настроку обоев и тп. для своего дистра, вместо вклада развитие зрелого ПО.

Pup-kwiev, но он управлять вроде не умеет, можно запилить расширение функционала т.к. Это скрипт на gtkdialod

Это виртуал фрактала что ли с пальцем приросшим?

«Вролшебник» — это опечатка, или у неё есть скрытый смысл?

Это опечатка с очевидным смыслом. Ничего скрытого:)

Управление модулями ядра... на электроне? Разупорись!

Не понимаю твоего хейта. Удобный «тулкит» для быстрой разработки гуевых приложений. Я надеюсь ты не думаешь что от скорости тулкита для гуя управления модулями ядра будет зависит производительность этих модулей.

Понимаешь, есть такое замечание. Если средства быстрой разработки излишне «быстры», то тут явно идет ущерб качеству проектирования UX.

Да посмотрите на скайп, в конце концов! Классическая версия была проста, удобна и понятна. Там все работало. А сейчас? Пароль не сохраняет, часовой пояс поменять нельзя, сохранить номер городского телефона в контактах нельзя. Электрон головного мозга разработчиков налицо. В зад этот электрон засунут

Да посмотрите на скайп

Не стоит по одному примеру делать далеко идущие выводы об интересном средстве разработки.

Электрон головного мозга разработчиков налицо.

Я все таки склонен считать что это Microsoft головного мозга. Проблема в переписывании. Я же говорил о начале разработки.

man localmodconfig man xconfig

Ты немного в пятничном настроении, да?

Первое показывает неиспользуемые модули, второе-информацию о них в гуе, всё, как ты хотел!

Удачи тебе. И лекарств. И людей добрых вокруг побольше. Прощай.

Пароль не сохраняет

Сохраняет, в keyring. Не стали изобретать велосипед, взяли готовый. Ну и там как бы уже не пароль, а токен для входа.

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

нихрена нет, но можно сделать:(

это жисть, детка

Загружать/выгружать. Делать это на «постоянной основе». Это как минимум.

https://yandex.ru/yandsearch?&text=туда%20сюда%20обратно%20о%20боже%20как...

А-а-а, так ты оптимизатор.

Нееее, это называется словом «мастурбация». Это как котики, которым делать нефиг, только не котики.

Вычистить и убедиться что автоматически более не загрузятся.

It's adven^Wkernel compilation time!

Сохраняет, в keyring.

У меня какие-то проги используют этот keyring, но не скайп. Что ему надо, понятия не имею. Gnome 3.14, CentOS7.

Так что нет, не сохраняет оно пароль

Что ему надо, понятия не имею. Gnome 3.14

У меня стоял gnome-keyring, он его заюзал.

видел gui для systemd юнитов?