11 ms·

Linux Driver Management 1.0 Released

162 points by dEnigma 9y ago

zython 9y ago
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
tomc1985 9y ago
This looks fantastic! Hardware enumeration on linux is so painful. What I would give for a copy of Windows' Device Manager on Mint...
- akulbe 9y ago
  You can see when hardware gets plugged in by running "dmesg" on the command line.
  - krylon 9y ago
    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 9y ago
      This is a problem with bluetooth, full-stop. The protocol is insane, and this sort of thing happens frequently on every platform.
      - com2kid 9y ago
        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 9y ago
        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.
  - ktta 9y ago
    udevadm is a better help. I use `udevadm monitor` to see what's happening when I'm plugging something in.
    - dEnigma 9y ago
      That monitoring function is neat. I just tested it with my USB mouse.
    - krylon 9y ago
      Thank you!
  - rwmj 9y ago
    A better idea is to look at /sys/class and /sys/devices.
    - tomc1985 9y ago
      All of the suggestions given work but none of them are a TreeView of every hardware node grouped by category then device. That said I much prefer doing I/O programming on Linux than Windows :)
stryk 9y ago
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 9y ago
  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-package/en/ https://solus-project.com/articles/packaging/request-a-packa...
  - stryk 9y ago
    Well, I've found my weekend project. Gonna install it on an older Laptop that's just laying around. Just for fun and experimentation. Thanks for the info
    - dEnigma 9y ago
      No problem. I've switched a laptop and my PC to Solus (dual-boot with Windows for gaming), and so far I've had fewer problem than I had with e.g. Ubuntu and other "mature" distributions. If you need support, there is the #Solus IRC channel on freenode (where lead developer Ikey Doherty is very active), or the Solus subreddit[1]. Development can be followed on Google+[2], Twitter[3], and in the #Solus-Dev channel. Have fun! [1]https://www.reddit.com/r/SolusProject/ https://www.reddit.com/r/SolusProject/ [2]https://plus.google.com/u/0/+Solus-Project https://plus.google.com/u/0/+Solus-Project [3]https://twitter.com/SolusProject https://twitter.com/SolusProject
  - FireBeyond 9y ago
    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?
unhammer 9y ago
does it relate in any way to Isenkram? http://people.skolelinux.org/pere/blog/Isenkram__Appstream_and_udev_make_life_as_a_LEGO_builder_easier.html http://people.skolelinux.org/pere/blog/Isenkram__Appstream_a...
- dEnigma 9y ago
  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 9y ago
When a distribution is centred around a custom desktop environment, I know to avoid that distribution.
deleted 9y ago
[deleted]

162 points by dEnigma 9y ago

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

tomc1985 9y ago

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

akulbe 9y ago
You can see when hardware gets plugged in by running "dmesg" on the command line.
- krylon 9y ago
  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 9y ago
    This is a problem with bluetooth, full-stop. The protocol is insane, and this sort of thing happens frequently on every platform.
    - com2kid 9y ago
      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 9y ago
        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.
- ktta 9y ago
  udevadm is a better help. I use `udevadm monitor` to see what's happening when I'm plugging something in.
  - dEnigma 9y ago
    That monitoring function is neat. I just tested it with my USB mouse.
  - krylon 9y ago
    Thank you!
- rwmj 9y ago
  A better idea is to look at /sys/class and /sys/devices.
  - tomc1985 9y ago
    All of the suggestions given work but none of them are a TreeView of every hardware node grouped by category then device. That said I much prefer doing I/O programming on Linux than Windows :)

stryk 9y ago

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 9y ago
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-package/en/ https://solus-project.com/articles/packaging/request-a-packa...
- stryk 9y ago
  Well, I've found my weekend project. Gonna install it on an older Laptop that's just laying around. Just for fun and experimentation. Thanks for the info
  - dEnigma 9y ago
    No problem. I've switched a laptop and my PC to Solus (dual-boot with Windows for gaming), and so far I've had fewer problem than I had with e.g. Ubuntu and other "mature" distributions. If you need support, there is the #Solus IRC channel on freenode (where lead developer Ikey Doherty is very active), or the Solus subreddit[1]. Development can be followed on Google+[2], Twitter[3], and in the #Solus-Dev channel. Have fun! [1]https://www.reddit.com/r/SolusProject/ https://www.reddit.com/r/SolusProject/ [2]https://plus.google.com/u/0/+Solus-Project https://plus.google.com/u/0/+Solus-Project [3]https://twitter.com/SolusProject https://twitter.com/SolusProject
- FireBeyond 9y ago
  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?

unhammer 9y ago

does it relate in any way to Isenkram? http://people.skolelinux.org/pere/blog/Isenkram__Appstream_and_udev_make_life_as_a_LEGO_builder_easier.html http://people.skolelinux.org/pere/blog/Isenkram__Appstream_a...

dEnigma 9y ago
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 9y ago

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

deleted 9y ago

[deleted]