Разработчики проекта Solus, развивающего одноимённый дистрибутив GNU/Linux и окружение рабочего стола Budgie, представили (https://solus-project.com/2018/01/26/linux-driver-management.../) первый выпуск пакета Linux Driver Management (https://github.com/solus-project/linux-driver-management) (LDM), предоставляющего библиотеку функций и инструментарий для быстрого определения состава аппаратного окружения текущей системы. Библиотека позволяет получить список имеющихся устройств и сопоставить каждое устройство с применяемыми для этого устройства драйверами или приложениями из репозитория. Код библиотеки написан на языке Си и ххhttps://github.com/solus-project/linux-driver-management распространяетсяъъ под лицензией LGPL2.1.
Библиотека не привязана к конкретным классам устройств и может использоваться в дистрибутивах для организации управления драйверами, определения доступного оборудования и подбора подходящих драйверов для всех имеющихся устройств, включая устройства, подключенные через HID-интерфейс (клавиатуры, мыши), USB, PCI, DMI, ieee80211 и Bluetooth. Предоставляются средства как для стационарных аппаратных компонентов, так и для подключаемых устройств (обработка hotplug через udev).
При интеграции LDM в дистрибутив пользователю не нужно задумываться о драйверах при подключении нового устройства - инструментарий обеспечит поиск и активацию необходимого драйвера, а при его отсутствии предложит установить недостающие пакеты из репозитория. Например, пользователь может быть информирован о доступности дополнительных проприетарных драйверов для видеокарт NVIDIA, для мышей Logitech могут быть предложены дополнительные пакеты для настройки DPI и индикаторов, осуществлена подборка драйверов для принтеров и рекомендовано дополнительное ПО для брелоков Yubikey, такое как Yubikey NEO Manager или Yubikey Personalization GUI.
Для опроса и определения устройств предлагается API на базе GObject, позволяющий встроить предоставляющую библиотекой функциональность в центры управления приложениями (на базе LDM уже построен Solus Software Center). Возможно расширение функциональности и типов поддерживаемого оборудования через плагины, которые могут создаваться не только на Си, но и на любых языках с поддержкой биндингов для интроспекции GObject, включая Vala, JavaScript и Python.
Кроме установки драйверов в LDM имеются средства корректировки конфигурации графической подсистемы для работы проприетарных видеодрайверов и механизма Optimus/PRIME (например, LDM может динамически подменять библиотеки libGL в зависимости от активного драйвера и изменять конфигурацию X.Org). Также предоставляется уровень абстракции для разбора системной конфигурации для определения iGPU и dGPU, идентификации гибридных систем (переключение между дискретной видеокартой и интегрированным GPU) и классификации устройств.
URL: https://solus-project.com/2018/01/26/linux-driver-management.../
Новость: http://www.opennet.me/opennews/art.shtml?num=47977
По описанию звучит слишком уж хорошо, полезно и удобно.
В чём подвох?
Так уже ж давно были всякие kudzu
Солус не только этот инструмент написали для "хорошо и удобно". Думаю, подвоха нет.
если не путаю их с кем-то, то там один из основных разрабов тесно связан с разработкой ПО Intel...
> если не путаю их с кем-то, то там один из основных разрабов
> тесно связан с разработкой ПО Intel...У интела есть куча открытого, он может и не знать, что там в микрокоде.
Безмерно рад в первом же комментаторе встретить человека, который объяснит:
1. Зачем оно?
2. Чем принципиально отличается от аналогичных комбайнов для приготовления кактусов, вроде ubuntu-drivers?
3. Что умеет прямо сейчас?
>> В чём подвох?В GObject
>В чём подвох?В том, что оно работать нормально не будет. За эту задачу многие брались, пока никто не справился. Что, в общем-то, не удивительно: драйвера пишут как угодно и кто во что горазд. Простые случаи вполне можно обрабатывать, но чуть в сторону и ага. Проблемы технические, проблемы юридические, снято с поддержки, портит оборудование и так далее.
Я так понял, что там идея в том, чтобы драйвером не ограничиваться, а подтянуть всё, что касается найденной железки - фирмвари, тулзы для настройки и т.д.
Вот тут, собственно, и подвох. Должно вписаться большинство производителей сколько-нибудь популярного железа. Получится сагитировать — взлетит.
Не работает или не адаптировано к популярным дистрам (и не будет т к на си и про расширяемость простыми модулями ни слова).
Так-то хорошо конечно. Тонкостей связанных оборудованием много, все это множится на число дистров ядер и прочего. Кто будет все это поддерживать?
Подвох?
>GObject, включая Vala, JavaScript и Pythonже
срочно выкидывай весь софт, который юзает zlib, потому что для zlib тоже есть биндинги на "вспомнити жс"
Ну наконец-то! Дождались! 2018 год! :D
> Ну наконец-то! Дождались! 2018 год! :DНесомненно отличная новость!
И как оно узнает адрес SPI контроллера в китайском SoC?
Никак, это для десктопа
А разве на десктопе существует проблема определения периферии?
Для десктопа всё уже в ядре
Из DTB. Ее цель не шины отсканитровать, и даже не устройства на них. А сопоставить устройство и драйвер. Как раз для десктопа полезно, но уже бессмысленно. А для встраиваемо-промышленного просто не нужно.
Использовался VSCode?
Проект уйдет к черту.
Некоторые даже в vim пишут. Правда они и не палятся.
> Некоторые даже в vim пишут. Правда они и не палятся.VIM наоборот лучше, всякого VS. (Я его пока не осилил, но пользуюсь пока gedit'ом для разработки на C. (Рано или поздно все равно перейду на VIM как только начну его осваивать в полную силу.))
Попробуй ed. Vim изобрели неосиляторы ed. Спроси у Саахрикту -- он не даст соврать.
> Попробуй ed.А почему бы и нет. (И через пять минут, на что я подписался...)
> Vim изобрели неосиляторы ed.Ещё скажи что Emacs сделали неосиляторы vi.
> Спроси у Саахрикту -- он не даст соврать.Пусть сам придет и скажет.
> Vim изобрели неосиляторы ed.Неосиляторы ed изобрели ex. Неосиляторы ex изобрели vi. Неосиляторы vi изобрели vim.
> Попробуй ed. Vim изобрели неосиляторы ed. Спроси у Саахрикту -- он не
> даст соврать.Пфф. Вы просто не освоили бабочек.
>> Попробуй ed. Vim изобрели неосиляторы ed. Спроси у Саахрикту -- он не
>> даст соврать.
> Пфф. Вы просто не освоили бабочек.Мило. Но вообще-то у нас в emacs есть команда и для любителей бабочек:
M-x butterfly
Чёртов Emacs! Даже butterfly-mode есть. Скажите лучше сразу, чего он НЕ может.
>чего он НЕ можетПритвориться вимом?
https://www.emacswiki.org/emacs/VimMode
> https://www.emacswiki.org/emacs/VimModeгы
https://hsto.org/files/3c8/1c8/2d3/3c81c82d353043aa9bf6d7cad...
>>чего он НЕ может
> Притвориться вимом?Ха-ха-ха! Extensible Vi Layer: https://www.emacswiki.org/emacs/Evil
> Чёртов Emacs! Даже butterfly-mode есть. Скажите лучше сразу, чего он НЕ может.Быть доступным в освоении.
Супер!
> USB, PCI, DMI, ieee80211 и BluetoothРелюшки через GPIO находить умеет?
Хотя бы оно прошивки для блютуза осилило.
И тогда суровые сибирские мужики положили шпалу.Не всё сразу. Спасибо что на Си, а не на Питоне, Яве, Моно или Электроне.
> ЭлектронеЭлектрон может в такой низкий уровень?
> Электрон может в такой низкий уровень?Электрон - это ниже плинтуса. Куда ещё ниже?
Ждем менеджер браузеров и защитник настроек.
И еще не забудьте Driver Updater Pro!
Так все это кроме настройки пользовательских программ
ядро делает автоматически,
нафига их библиотека то нужна?
думаю оновная причина - пляски с бубном вокруг ноутбуков. на трансформерах с дискретной графикой установка линукса - та еще задача
> Так все это кроме настройки пользовательских программ
> ядро делает автоматически,
> нафига их библиотека то нужна?Чтобы ядро что-то могло сделать, ему нужны драйверы и прошивки, которые могут быть распиханы по отдельным пакетам, которые могут быть не установлены. Вот чтобы объяснить хомячку, что надо доустановить, прежде чем он со словами "гамно этот ваш линyпс" вернётся на винду, и нужна эта библиотека.
>Вот чтобы объяснить хомячку, что надо доустановить, прежде чем он со словами "гамно этот ваш линyпс" вернётся на винду, и нужна эта библиотека.А может ну их, этих хоячков?
Чтобы делало ядро - драйвер должен быть в ядре. А если, допустим, с железкой через lubusb работа - то ядро о ней понятия не имеет. И уж точно ядро не предложит поставить дополнительный софт для настройки или использования дополнительных функций девайса. И интнгрировать в ваш DE не поможет.
Два раза перечтал новость, так и не понял — зачем это нужно.
Чтобы ты не лез внутрь системника смотреть микросхемы, а запустил lspci lsusb + pciid usbid. Не выковыривал vid'ы, pid'ы, dev'ы и т.п.
Эверест в одном флаконе.
Годная штука!
> Чтобы ты не лез внутрь системника смотреть микросхемы, а запустил lspci lsusb
> + pciid usbid. Не выковыривал vid'ы, pid'ы, dev'ы и т.п.Странно что до них не было lspci, lsusb, dmidecode, sysfs, репозитория идентификаторов вендоров и оборудования и многократных малополезных попыток всё это интегрировать в одну кнопку "сделать хомячку пересевшему с Виндоус хорошо".
Хотя постой...
какое отношение смотрение на мискросхемы имеет к названию программы? Почему авторы программы подобно поцтеру не слыхали о каком-нить lshw? Почему ваш ответ породил новые вопросы?
И нафига оно? Не хочешь возится с файлами или dmidecode? inxi, за глаза.
Как я подозреваю, внутри у него какая-то база знаний. Вряд ли всю полезную информацию можно вытащить автоматически. Что есть в базе - то обработается корректно, чего нет - не найдётся. Если люди хорошие, то тогда можно расширять базу пользовательскими пакетами.
Неудели кто-то допетрил, что пихать в ядро все драйверы мира плохая идея и там должно быть только самое необходимое?
Но, кажется, не каждый драйвер способен работать как модуль?
>Код библиотеки написан на языке Сивносите хейтеров
Там хуже, чем C - там GObject
Хотелось бы верить что сабжу хитро-вые... пардон! - хитро-сделанные китайские тачпады и прочие девайсы, весящие на i2c, окажутся по зубам. Доселе ни одной вменяемой софтинки горящей желанием показать мне что прицеплено к i2c я не встречал.
> Доселе ни одной вменяемой софтинки горящей желанием показать мне что прицеплено к i2c я не встречал.Потому что сама шина не предполагает подобного. sensors-detect пытается, впрочем, но с неизменным предупреждением, что при этом может что-нибудь сломать.
И тем не менее делает.Ровно как и еще одна самописка на питоне, которую я как-то увидел в Сети. Только ID устройств в ней было очень не много, - чуть более тридцати. Явно писал человек на раз и для себя. А вот промышленного решения я не видел, и где взять эти идентификаторы - понятия не имею.
А вопрос вовсе не праздный - китайцы в последнее время цепляют к i2c отнюдь не только сенсоры, а определить чего же они там подцепили крайне сложно. Думаю, что я не один такой, кто на этом огреб проблемы.
Хотелось бы подобное, но чтобы генерило конфиг ядра, и не как localmodconfig на основе подгруженных модулей, а также на основе имеющегося железа.
Наконец то.
Для OpenSSL определяет VIA Eden (padlock) аппаратный крипто-генератор?
> динамически подменять библиотеки libGL в зависимости от активного драйверадля этого уже существует libglvnd
> и изменять конфигурацию X.Org
спасибо, но такой prime как в ubuntu, с логаутом, не нужен. а иначе зачем еще при оптимусе дергать xorg.conf?
Не нашёл дрова для BCM5821
Рад за ребят - надо же с чего-то начинать изучать на практике низкоуровневый язык программирования ;) Вдвойне рад, что не выбрали сразу С++, а таки остановили свой выбор на Си.
GObject - это крайне уродливое ООП на C, плюсы на порядок лучше.Больше того - это как раз тот случай, когда высокоуровневый язык подошёл бы куда лучше - для собственно анализа оборудования инструментов и так хватает, тут надо фактически сделать обвязку с базой подходящего софта, драйверов и подобного. Смысл возиться с чистыми сями?
А смысл квакать то?!
Напиши на своём любимом языке и криком БАНЗАЙ!^W ... смотрите как нада! медленно и неотвратимо выкладывай линк на ... 8-)
И тут не только мы оба, но таки даже не только лишь все поняли - не будет этого, ибо не мешки ворочать!(С) :)
Перечитай ещё раз диалог. Существо заявило, что, мол, хорошо, что низкоуровневое и не плюсы. Я ответил, что: 1) здесь не критично, чтобы на сях; 2) там GObject, который чистыми C ну никак не назвать и что он урод (ну дык - оно там всё на макросах, иначе ООП в сях не сделать, так что красивым не может быть в принципе), и то же самое делается на плюсах чисто и красиво.Каким боком это связано со "сделай сам"?
А так - ну да, лучше проект на любом языке, чем его полное отсутствие. Только конкретно к моему комментарию это не относится.
0. Проект только для Linux. По факту, - Solus знает только то, о чём знает ядро Linux. Упростил (для usb, например, дополнительно используется libusb), но суть не в этом.
1. Проект только для десктопов (bluetooth, dmi, pci, usb, wi-fi). Все остальные сразу могут расходится.
2. Проект использует объекты, там где можно обойтись более простыми и эффективными средствами, -> структурами. Те, кому это не по нраву, тоже могут отсекаться.
3. Не совсем понятно, зачем там используются алиасы. Типа, такой хитрый ход, чтобы усложнить понимание исходного кода?Дальше углубляться не стал, потому что понял, что для меня, во всяком случае на данном этапе, не подходит.
При этом я фанат Linux, не противник GObject, но не приветствую его бездумное использование. :-)
Сам udev умеет больше, а для его простого использования (если вам уж совсем лень) есть Eeze (часть EFL).
> 1. Проект только для десктопов (bluetooth, dmi, pci, usb, wi-fi). Все остальные
> сразу могут расходится.Кроме того, проект, как кажется (!), надеется только на отдельные идентификаторы, а должна же быть и логика по апп. комплексам, для которых требуются иногда нетривиальные действия. Чем тут помогут объекты? Неужели правы в GNU guix с их лиспом?
Нет, липс - это просто традиция. :-) При желании, можно работать и с произвольными массивами, а писать на языке оболочки. Или, даже, вообще, складывать всё во временные файлы (не обязательно на hdd, можно ведь и в ОЗУ). :-) Но это, опять же, про желания и удобство _для программиста_, а не для пользователя. Я же, лишь хотел заметить, что независимо от выбранного инструмента не нужно забывать о использовании бритвы Оккамы. Только и всего. Разуметься, без фанатизма.Если посмотреть на GNU/HURD сверху, то всё это, как минимум, крайне странно: с одной стороны, - микроядро, а с другой, - приложения с зоопарком интерпретаторов. :-)
Впрочем, так можно сказать о многих ОС, а для GNU это, скорее, даже фишка, чем недостаток...
