Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian and firmware

blog.einval.com

Post reply on HN
Print view View original

141–150 of 180 posts

Re: Debian and firmware

#141

Post by anthk »

tremon wrote: post #140
anthk wrote: post #111

Earlier quoted context omitted.

The Radeon module works on non-accelerated mode with the modesetting driver instead of the xorg Radeon one. At /usr/share/X11/xorg.conf.d/10-radeon.conf: Section "Device" identifier "Radeon" Driver "modesetting" EndSection Bugs may arise, maybe it could be a good idea to disable the Composite extension too.

I guess I confused the issue by referring it as the "radeon driver", but I meant to implicate the radeon.ko kernel module, not the radeon(4) Xorg driver. The servers I'm talking about don't even have X installed (they're Ceph OSD nodes).

Linux libre here. I ran Trisquel on TTY mode to debug issues, I modprobed the radeon module and KMS switched the resolution to a native one in a laptop. Starting X with the radeon driver for X messes everything garbled up. The modesetting driver works, but no GL.

TTY works well before and after KMS.

Re: Debian and firmware

#142

Post by yabones »

happymellon wrote: post #54
apatheticonion wrote: post #29

As a Windows/MacOS user who has moved full time to linux, I ended up on Debian Testing as my daily (going to try Fedora soon). I still live back in the days when Fedora would give you a pop up to install non-free drivers ("additional software" or something like that). I have been using Debian as my daily driver for almost 6 months now and Linux in general for years - I still have no idea how the video drivers work. I…

> What is mesa? It is the OpenGL and Vulkan libraries. Code calls the Vulkan API, and mesa translates that into something the video driver can handle, which in turn passes the command to the video card. > Why do people tell me not to install the video drivers from the Radeon website. Because AMD have spent a lot of time and effort getting the drivers in the kernel, and the website drivers are old and no longer the be…

You can also use backports to get a newer kernel. I'm on Bullseye which released with 5.10, but you can install 5.16 this way.

    sudo apt install -t bullseye-backports linux-image-amd64
I prefer this to running testing, since I still want reliable and prompt security patches.

Re: Debian and firmware

#143

Post by marcosdumay »

rincebrain wrote: post #68
zrm wrote: post #30

Earlier quoted context omitted.

Debian is one of the top Linux distributions, so there are empirically a large number of people not being deterred. And many of the other top Linux distributions are Debian derivatives which both participate in the community and provide the alternate experience. Upholding its principles is the way Debian distinguishes itself. If you don't like it, use Mint or something.

I think the question becomes, are people using Debian in large part because of those principles, or in spite of the inconveniences that come with them because of other benefits (e.g. it's a fairly well-maintained, stable Linux distribution, that very aggressively believes if something worked on 11.0 it better still work on 11.9)? If we look at popcon[1], it currently says 11.84% of users who opted into popcon regular…

It's not that simple. Debian is the way it is because of its principles. You can't remove the principles and keep everything else working the same way.

(But, of course, this isn't an uncompromisable principle, as evidenced by the existence of the non-free repository. Packaging basic firmware on the same image as the rest of the system isn't the unthinkable action that people are talking about, but silently running them would be.)

Re: Debian and firmware

#144

Post by slavik81 »

blihp wrote: post #64
Cu3PO42 wrote: post #50

Earlier quoted context omitted.

The driver situation for modern AMD GPUs is pretty good. There is an open-source `amdgpu` driver in the mainline Linux kernel maintained by AMD themselves. If you use a somewhat recent kernel, that'll be there. You need `mesa` in userspace which provides the OpenGL interface, etc. to your applications. This is why there's no need to install anything from the Radeon website -- you already have a driver. As for the `fi…

Unless you're running one of the handful of 'officially' supported distros/versions, it really isn't that good yet for at least 6000-series cards. Sure, the upstream video drivers work fine if you just need basic functionality. But if you need more advanced capabilities (i.e. monitoring/managing frequencies/power consumption/etc) or do GPU compute, you're pretty much stuck using the AMD repos which are built for LTS…

All the ROCm components beneath HIP are in Debian Unstable (aside from the firmware as per topic), and I think at least a few components made it into Ubuntu 22.04. Facilitating Debian packaging for ROCm has been my hobby for the past year or so.

While ROCm doesn't officially support consumer GPUs, the supported W6800 is Navi 21. The consumer Navi 21 cards thus also work. Those are the 6800 / 6800 XT and 6900 XT.

If any Debian contributors would like to help package the rest of the ROCm stack, the Debian AI mailing list is where most of the action happens.

Disclosure: I work for AMD on ROCm, but all opinions are my own.

Re: Debian and firmware

#145

Post by eptcyka »

usrn wrote: post #136
eptcyka wrote: post #133

Earlier quoted context omitted.

I don't think equating FOSS with tedious rituals does any good to any one. You can still have Debian installers be the way they are, with the addition of having a button that enabled non-free firmware to remove the need for USB tethering and three reboots. FOSS has a problem with UX design, and this is definitely one symptom.

>You can still have Debian installers be the way they are, with the addition of having a button that enabled non-free firmware Like I said, each thing is just "fix this one thing by compromising principles." If you do that with all the UX problems you literally end up with ChromeOS. Different distros are on different places along the spectrum between Debian and ChromeOS. Ubuntu is further along for example, so you ge…

Allowing one to make the choice in a pragmatic manner instead of wasting time dancing around to praise the FOSS gods to achieve the same end goal is stupid. Just having an option in the installer to allow non-free firmware and drivers won't move Debian to be any closer to ChromeOS. It will make it easier to use for a lot of people. Stop with this false dichotomy that bad UX implies giving up freedoms. All I'm arguing for is allowing users to make their choices about their own freedoms easier.

Re: Debian and firmware

#146

Post by eptcyka »

stragies wrote: post #135
eptcyka wrote: post #114

Earlier quoted context omitted.

This is such a solvable issue it deeply disturbs me you need to dance this dance. Whilst you might not be complaining about it, this is exactly the kind of stuff that deters people from using more FOSS. Not only are selecting non-default options every time you install a debian system, you've also spent the time to learn this ritual and you've had to comprehend the complexities of what, how and why to do this. Just to…

The other reason I do it like this, is because many years ago I got a comment from an auditor about an item on the install-log: "Used CD-Image from https://cdimage ...", because he spotted the "/unofficial/non-free/" part of the URL. The resulting discussion is what I wanted to avoid in future.

That must have been a nasty discussion you had there.

Re: Debian and firmware

#147

Post by marcosdumay »

Gigachad wrote: post #43
zrm wrote: post #30

Earlier quoted context omitted.

Debian is one of the top Linux distributions, so there are empirically a large number of people not being deterred. And many of the other top Linux distributions are Debian derivatives which both participate in the community and provide the alternate experience. Upholding its principles is the way Debian distinguishes itself. If you don't like it, use Mint or something.

Debian is a great project I know. But the comment that they only use debian for its principals directly suggests they would use something else if principals were not considered. Suggesting the other distros are better for their uses. Anecdotally I don't think I have ever seen a debian desktop user, and I wouldn't pick it for desktop either because they don't make it easy to get everything working like other distros d…

Another Debian desktop user here. Ages ago I tried a lot of different distros, but none of them just stay running like Debian. My computers are for using, not for fixing random errors at inconvenient times.

The installation process, that I have to run when a local disk eventually fails is insignificant compared to constantly fixing shit. (And yes, it's not a nice process - even worse because every time I run it, it changed.)

Re: Debian and firmware

#148

Post by marcosdumay »

techie128 wrote: post #79
b5n wrote: post #14

As a long time Debian user I'm reluctant to criticize developer ergonomics as I'm not an _active_ contributor. That being said, _as a user_, I've not had any issue locating and using non-free firmware when required, and I would be disappointed to see the project change course by including non-free components in an offical manner. Removing the slight inconvenience (literally clicking a link _on the installation page_…

> If users never brush up against the inconvenience they'll be much less likely to seek out hardware alternatives I think you got it backwards. Users will seek out SOFTWARE alternatives. They're easier to change than the hardware. They're likelier to go the Ubuntu or Linux Mint route than to die on a Debian hill.

I do pick my hardware based on free software support.

Life is too short to depend on people that don't want to support your use-case.

Re: Debian and firmware

#149

Post by hedora »

More importantly, going to debian.org/shop should provide a list of best-of-current-generation hardware devices that work flawlessly without setting the kernel taint bit, covering a dozen hardware niches:

- router

- NAS

- thin and light laptop

- cheap laptop

- beast of a CPU laptop

- gaming laptop

- ml laptop

- low wattage compact desktop / htpc

- workstation

- gaming desktop

- tablets, watches, phones, etc.

- handheld portable gaming system (e.g. rk2020, steam deck, odin pro)

To get on the list, manufacturers would have to commit to making a Linux SKU that does not change (modulo hardware bugfixes) for 3-5 years. PC Engines alrady does this for routers; Pine does it for cheap laptops; AMD GPU gaming desktops are also an easy target.

They'd also need to donate a few dev / continuous integration machines to the project (or operate them themselves). Each night, these machines would automatically confirm that all hardware devices are working right in top of trunk and all contemporary supported releases.

There could be revenue sharing, or not. Don't care.

Re: Debian and firmware

#150

Post by usrn »

eptcyka wrote: post #145
usrn wrote: post #136

Earlier quoted context omitted.

>You can still have Debian installers be the way they are, with the addition of having a button that enabled non-free firmware Like I said, each thing is just "fix this one thing by compromising principles." If you do that with all the UX problems you literally end up with ChromeOS. Different distros are on different places along the spectrum between Debian and ChromeOS. Ubuntu is further along for example, so you ge…

Allowing one to make the choice in a pragmatic manner instead of wasting time dancing around to praise the FOSS gods to achieve the same end goal is stupid. Just having an option in the installer to allow non-free firmware and drivers won't move Debian to be any closer to ChromeOS. It will make it easier to use for a lot of people. Stop with this false dichotomy that bad UX implies giving up freedoms. All I'm arguing…

>Compromising on freedom doesn't result in a loss of freedom

This is an immediate and direct contradiction.

Post reply on HN