
Linux Driver Management 1.0 Released - dEnigma
https://solus-project.com/2018/01/26/linux-driver-management-1-0-released/
======
zython
Link to the github project which gives more information about LDM:

[https://github.com/solus-project/linux-driver-
management](https://github.com/solus-project/linux-driver-management)

------
stryk
I've always wanted to try Solus. The budgie desktop looks intriguing, and I've
always wanted to try one that was an O/S of it's own and not a Debian or RHEL
derivative. My main hang-up is concerning software availability. Since it's
not your typical Debian-based OS the normal (huge) package repositories are
out, so do you have to compile everything from source specifically for Solus,
or do they have their own pre-compiled archive of stuff?

~~~
dEnigma
There is a (growing) repository of software packages and the developers are
open to sensible package requests[1]. So far I've found that almost everything
I needed was already in the Solus repository.

[1][https://solus-project.com/articles/packaging/request-a-
packa...](https://solus-project.com/articles/packaging/request-a-package/en/)

~~~
FireBeyond
I have wondered, and certainly not exclusively to Solus, if there’s any reason
why some “package capture” couldn’t be built in to people compiling from
source for distros where a package isn’t available.

Certainly there would have to be a bunch of checks and balances, not blind
acceptance, capturing source code URLs, checksums and the like, potentially
reproducible builds, but could be a way to ‘crowd source’ packages. Or is this
a solution in search of a problem?

~~~
ekianjo
Thats Arch and its AUR basically.

~~~
e12e
... If aur uploaded the binary from the first person building it, saving
others the need to recompile.

~~~
ekianjo
Except for very large applications, most software you would find on the AUR
can be compiled in a few minutes or less.

And it's not about "saving the time to recompile", it's about using the source
code so that you can keep using the AUR as long as the compilation process
does not break.

------
tomc1985
This looks fantastic! Hardware enumeration on linux is so painful. What I
would give for a copy of Windows' Device Manager on Mint...

~~~
akulbe
You can see when hardware gets plugged in by running "dmesg" on the command
line.

~~~
krylon
That does not _always_ help, though.

A while back, I tried to connect my Bluetooth headset to my low-end notebook.
As far as dmesg could tell me, the Bluetooth chip was detected and worked just
fine. But it did not detect any devices that were around. After the headphones
failed, I tried again with my phone and a tablet (I have too many gadgets, I
know) - the result was consistent throughout: The notebook did not discovery
any pair-able devices.

After about ten minutes of this, I decided I am too old for this crap and got
my _good_ notebook. This time, the notebook discovered the headphones, like it
should, and it happily paired with the headphones, like it should, but every
now and again, the Bluetooth connection just dropped, and the notebook could
not re-discover the headphones until I rebooted it. dmesg was ominously silent
about this, it merely pointed out that it had killed the Bluetooth daemon (but
I suspect that was a result of the driver or the BT chip misbehaving).

To be fair, otherwise both notebooks work perfectly fine, and I also have no
idea if a "Driver Manager" would have helped me with either of these issues.
And it is not a deal breaker for me either, because do not normally use my
notebooks for anything that requires headphones. But I did run into problems
that I suspect were caused either by the hardware or the driver, and dmesg did
not help me at all.

In case it matters, though, both notebooks run openSuse Tumbleweed, but I have
a hunch neither of these problems is distro-specific.

EDIT: OK, so this was not about enumeration. But still.

~~~
ohazi
This is a problem with bluetooth, full-stop. The protocol is insane, and this
sort of thing happens frequently on every platform.

~~~
com2kid
BT itself is NOT the problem. Some of the profiles are a bit odd, and others
are downright eloquent and wonderful. The LE stuff is actually quite nice in
places!

BT chipsets on the other hand, are complete crap. And every single BT stack
has its own mess of bugs and is 90% of an implementation of what the spec
says, and each stack implements a slightly different 90%, and the remaining
10% is just random bugs.

~~~
ohazi
Strongly disagree. Every time I look into building anything with bluetooth I
come to the same conclusion that the protocol is irredeemably awful.

The fact that the massive pile of profiles essentially all need to be
supported inside the chipset is what makes their firmware so buggy and
unreliable. Software written by semiconductor manufacturers is famously bad,
and the approach that bluetooth has taken basically asks them to do more of
the firmware work, keep track of more application state, and never get their
wires crossed. And because the chipset firmware is almost always a binary
blob, system designers have no way to fix anything. Of course it's going to be
a massive failure.

What they should have done was built a dumb, encrypted pipe, and let
downstream driver and application developers deal with the application-layer
logic. Then the semiconductor manufacturers would only be responsible for a
basic bulk transfer interface that's a lot harder to screw up. This is why
wifi and ethernet and usb drivers tend to work reasonably well, and bluetooth
drivers are an unreliable mess.

I get why they did it... in the early days, prices for bluetooth chipsets
varied depending on which profiles they supported. This was supposed to be a
way for semiconductor companies to differentiate themselves in a world where
they were increasingly viewed as commodity suppliers. But because they never
bothered to invest in their firmware development (these companies have like 20
people working on chip design and verification and like 3 on firmware), they
ended up making everything worse rather than adding value.

~~~
com2kid
AVRCP is quite eloquent. I get the feeling that whoever designed it is upset
that it never got properly implemented or used.

BTLE in its entirety is just simple. It is possible to read over the BTLE spec
in a couple hours and understand it. (AVRCP can be read in half an hour tops,
15 minutes if you skim the same-y diagrams)

BT SPP is, well, a glorified serial port, with all the advantages and
disadvantages that entails.

If you want a glorified pipe, BT SPP is where you go. You can actually use BT
LE to do the same thing, at a much slower transfer rate.

> wifi and ethernet and usb drivers tend to work reasonably well

WiFi and USB drivers are also flaming piles of trash. Since 90% of USB use
cases consist of either USB-HID or Mass Storage, there is less to get wrong.

Do anything beyond that and you can easily find yourself SOL.

And Wi-Fi drivers are complete crap. Power management sucks, Wi-Fi chips hard
lock and _somehow_ a watch dog timer never kicks in (how?), and they rarely
give the speeds that they are supposed to. Intel had some Wi-Fi chip a few
years back that, for a good 2 years after its release, it would randomly stop
deciding to finding networks to connect to, until it was power cycled. After a
couple of years on the market they finally released a firmware update.

Don't get me wrong, Chipset BT Firmware is horrible. I've worked with vendors
who obviously weren't using version control, subsequent patches would have
regressions that made it apparent they had built today's patch off of old
source code that predated the last patch they had sent us. Hilarity like that.

But the OS side BT stacks also tend to suck. Then there is the driver for the
BT chip, which can also suck.

The actual BT standard itself, I would argue, isn't the largest part of what
is wrong.

------
unhammer
does it relate in any way to Isenkram?
[http://people.skolelinux.org/pere/blog/Isenkram__Appstream_a...](http://people.skolelinux.org/pere/blog/Isenkram__Appstream_and_udev_make_life_as_a_LEGO_builder_easier.html)

~~~
dEnigma
Interesting, hadn't heard about Isenkram. I have no idea if there is any
relation. I would have to ask Ikey Doherty (the main Solus developer)
directly. The only similar projects he mentioned on Reddit were Jockey and (I
think) Gnome Software.

------
snvzz
When a distribution is centred around a custom desktop environment, I know to
avoid that distribution.

