Solus Releases Linux Driver Management 1.0

[starshipeleven]

RPM does it already:

> https://www.suse.com/documentation/s...tml#sec.system

It constantly blows my mind why Solus never bothers to make any research before boasting they have invented something new.

Well, they made a package-manager-agnostic system, for the inferior distros not using RPM packages. That's still something worth it.

That said, is this thing working at all? did you see it in action?

[monraaf]

And lets say you're a new user - you're going to need to know what package is relevant for your hardware - if at all. Many users will end up installing the wrong thing, or not installing anything at all, and this leads to an incredibly poor user experience. Additionally, an OS should just know how to look after itself. If i plug a new device in and it needs drivers, my OS should tell me, I shouldn't need to hunt down arcane incantations for the terminal from some wiki.

RPM does it already:

> https://www.suse.com/documentation/s...tml#sec.system

It constantly blows my mind why Solus never bothers to make any research before boasting they have invented something new.

[monraaf]

But it was not offering you that stuff for other hardware components, like input devices for example. Solus does now with Linux Driver Management.

Yes, they do. Heck, it's even part of the RPM spec:

> https://www.suse.com/documentation/s...tml#sec.system

[kalin]

Oh absolutely, it doesn't excuse us from having documentation



Technically you can do that, but we're going to do it in Solus via a notification system. User clicks the notification (which persists) which'll open the Software Center, which will in turn show the devices to be configured/installed. With the way that we do packaging of drivers, we expect them to be effectively zero configuration from the user side (and distros like Fedora also do the same kind of thing here). So basically it becomes a confirmation step from the notification, and then the user is sorted.

Beauty of course is that its entirely up to the distros/authors how they make use of the library and what those steps look like

Thanks for your effort. I really appreciate it. I just have questions. What is the reason to use glib and c language ? From what I can see You really prefer c over c++ for your tools.
Is that caused by reason or just You feel more comfortable with c

[ikey_solus]

Well, I totally agree with you on your stance as far as it concerns non-enthusiast linux users. But I wouldn't give up on wiki documentation for more advanced stuff, and I wouldn't discourage any user from educating themselves from sources like wiki documentation.

Oh absolutely, it doesn't excuse us from having documentation

EDIT: I've been reading in the mean time as well and I think I have a better understanding what this driver manager is. In a simplified scenario, a user can just plug in a device, and the driver will be installed, any important applications it needs, any profiles that need symlinked all get taken care of. And it's all just from the act of plugging in the device. Does that sound like a scenario that would be correct?

Technically you can do that, but we're going to do it in Solus via a notification system. User clicks the notification (which persists) which'll open the Software Center, which will in turn show the devices to be configured/installed. With the way that we do packaging of drivers, we expect them to be effectively zero configuration from the user side (and distros like Fedora also do the same kind of thing here). So basically it becomes a confirmation step from the notification, and then the user is sorted.

Beauty of course is that its entirely up to the distros/authors how they make use of the library and what those steps look like

[duby229]

And lets say you're a new user - you're going to need to know what package is relevant for your hardware - if at all. Many users will end up installing the wrong thing, or not installing anything at all, and this leads to an incredibly poor user experience. Additionally, an OS should just know how to look after itself. If i plug a new device in and it needs drivers, my OS should tell me, I shouldn't need to hunt down arcane incantations for the terminal from some wiki.

This itself does not provide **any** frontend, it provides tooling and a library for distros to integrate into their existing tools and software centers (or new ones) and drop some technical debt for a shared solution among all distros, On top of that it throws in some extra capabilities, like proper classification, plugins, hotplug events, device tree encapsulation, etc, to be trivial for anyone to use. It makes no host assumptions and allows anyone to bolt on driver + hardware enabling with very little effort, and allows folks to move away from the temptations of forks-of-forks-of-Jockey (which is very scope limited). Notably the library isn't tied to any distro or package manager.

Beyond that there is core support for GLX management as a distro hook to provide proper configuration of X for proprietary drivers and Optimus (Which will evolve beyond always-on PRIME in time.)

Well, I totally agree with you on your stance as far as it concerns non-enthusiast linux users. But I wouldn't give up on wiki documentation for more advanced stuff, and I wouldn't discourage any user from educating themselves from sources like wiki documentation.

EDIT: I've been reading in the mean time as well and I think I have a better understanding what this driver manager is. In a simplified scenario, a user can just plug in a device, and the driver will be installed, any important applications it needs, any profiles that need symlinked all get taken care of. And it's all just from the act of plugging in the device. Does that sound like a scenario that would be correct?

[Brophen]

Additionally, an OS should just know how to look after itself.

100 times this.

[ikey_solus]

So, I don't get it, I don't understand the dilemma. If a package for a device driver exists you just install the package.... So what is this thing? Like a limited scope package manager frontend? Is it just an enumerator?

And lets say you're a new user - you're going to need to know what package is relevant for your hardware - if at all. Many users will end up installing the wrong thing, or not installing anything at all, and this leads to an incredibly poor user experience. Additionally, an OS should just know how to look after itself. If i plug a new device in and it needs drivers, my OS should tell me, I shouldn't need to hunt down arcane incantations for the terminal from some wiki.

This itself does not provide **any** frontend, it provides tooling and a library for distros to integrate into their existing tools and software centers (or new ones) and drop some technical debt for a shared solution among all distros, On top of that it throws in some extra capabilities, like proper classification, plugins, hotplug events, device tree encapsulation, etc, to be trivial for anyone to use. It makes no host assumptions and allows anyone to bolt on driver + hardware enabling with very little effort, and allows folks to move away from the temptations of forks-of-forks-of-Jockey (which is very scope limited). Notably the library isn't tied to any distro or package manager.

Beyond that there is core support for GLX management as a distro hook to provide proper configuration of X for proprietary drivers and Optimus (Which will evolve beyond always-on PRIME in time.)

[duby229]

So, I don't get it, I don't understand the dilemma. If a package for a device driver exists you just install the package.... So what is this thing? Like a limited scope package manager frontend? Is it just an enumerator?

[Vistaus]

Ubuntu was already offering me a driver manager where I could simply switch from MESA to Nvidia or AMD binary drivers.
As far as I remember SUSE Linux has similar capabilities with YAST.

But it was not offering you that stuff for other hardware components, like input devices for example. Solus does now with Linux Driver Management.