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

151–160 of 180 posts

Re: Debian and firmware

#151

Post by stragies »

eptcyka wrote: post #146
stragies wrote: post #135

Earlier quoted context omitted.

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.

Not nasty, but unnessesary, for the both of us. He was a non-technical auditor, and was hoping to put something damning on his report to justify the expense. He "cleared" that item after discussion, but I did not want to have that talk about the "unofficial.iso" again. And since I +-always take expert mode for other reasons anyway, having to select "non-free" repo on devices with non-free components from inside the standard installer is no big detour.

Re: Debian and firmware

#152

Post by marcosdumay »

the_biot wrote: post #117

It's a shame that there's barely even a conversation about fixing the problem of the ever growing pile of proprietary firmware blobs; more and more often people seem to just accept the situation. There isn't AFAIK an organisation or project dedicated to producing free firmware to replace the blobs. The most you see is the occasional project for making firmware for a single chip. Debian's page lists these: https://wik…

It's not really growing. They just used to come inside the device, and now they are changing into the distro. That's an improvement, just not as big one as it could be.

Re: Debian and firmware

#153

Post by zajio1am »

mastax wrote: post #6

Almost every hardware device has one or more CPUs on it. As Foone joked, "USB is a standard to let you connect 8051 microcontrollers to PCs." Given the choice between burned-in firmware and externally-loaded firmware, the latter seems clearly superior from an openness perspective. The firmware binary and the loading mechanism opens up the opportunity for reverse engineering, modification, and replacement open firmwar…

> We currently have a strange situation where the devices that are easy to use are the most open and the most locked down ones, and the middle-ground is punished by policy.

Yes, but that is a result of legal framework, where handling and using independent firmware requires accepting appropriate licences, while handling and using burned-in firmware does not.

Re: Debian and firmware

#154

Post by eptcyka »

usrn wrote: post #150
eptcyka wrote: post #145

Earlier quoted context omitted.

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.

The freedom is already lost, it just takes users more time to get their machine to have a working network connection.

Re: Debian and firmware

#155

Post by happymellon »

apatheticonion wrote: post #81
happymellon wrote: post #54

Earlier quoted context omitted.

> 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…

This is great context, this only threw me because when I installed Debian and some other distros, I didn't have any graphics card drivers and was confused why and how to get them. > Because AMD have spent a lot of time and effort getting the drivers in the kernel Does that mean the drivers are open source? > It is a lot more simple. It is all built in. When it works. When you have no context (like me) and you are pre…

I'm glad it helped, asking questions is the only way to learn. Especially when you can't RTFM because there isn't a fine manual to read.

Yes, Intel and AMDs video drivers are opensource.

> It's really hard to find a tl;dr of how to get your graphics card working.

So I don't know what video card you have, or what the problem is. With something like Debian it could easily be that your video card is too new for the kernel version if you don't have backports enabled.

That is when the AMD website drivers come in, as they are normally for older kernels, so they are used to enable to video card while your distribution gets up to date.

This is why Ubuntu became so popular, it took Debian and made everything slightly more up to date, plus made the Nvidia drivers accessible. Though if you find Debian not quite new enough for your usecase, try something like OpenSuse or Fedora. Make a bootable USB and see if they are any better for you. Or enable backports, I found that didn't work for my usecase as I had kernel panics, and could not get to enable them.

Let me know if you have any other questions or queries.

Re: Debian and firmware

#156

Post by bayindirh »

derefr wrote: post #138
bayindirh wrote: post #120

Earlier quoted context omitted.

> I believe there should be an official non-free repository (akin to Ubuntu's) which users can enable offline, meaning it needs to be stored on the official CD. There's already a "non-free" section under official "dists" ([0] for stable). It's just not added to the ISOs. Netinstall directly asks that whether you want non-free enabled during installation too. The only thing is whether building CDs with it or not. Actu…

A better tool would slipstream the data into the ISO image, I would think, since you might want/need the drivers available at install time in order to even boot certain non-free hardware, and you might only be getting the thing to boot in the first place using e.g. a PXE server.

In my proposition, the installer will find the ZIP file automatically, extract and use the required firmware files (This mechanism works already). It might be already working under Preseed + PXE too. I need to look into it.

Re: Debian and firmware

#157

Post by xioren00 »

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_…

The non-free version is not official. The last time I used it, it came pre-installed with a bunch of Indonesian language bloat software that it not part of the official Debian install. This is not an acceptable middle ground.

Re: Debian and firmware

#158

Post by yyyk »

My subjective impression is that Debian has been losing ground, especially against Arch. I don't think firmware is the main issue - the complex packaging method and the contradictory nature of Debian 'testing' are the main issues. Yet this change will help, so I'm in favour.

Re: Debian and firmware

#159

Post by BugsJustFindMe »

josephcsible wrote: post #23

I'm usually on the FSF's side about everything, but this is one place where I disagree with them and agree with this article. A free OS with free firmware is definitely better than a free OS with proprietary firmware, but both of those are way better than a proprietary OS with proprietary firmware. By making the middle ground difficult, a lot of users have to choose between ideological purity and working hardware, an…

Your sentiment is the exact premise behind https://github.com/fiendish/The-Debian-Gotham-Needs

(You can tell from the blurbs on the readme and download page).

Re: Debian and firmware

#160

Post by blihp »

slavik81 wrote: post #144
blihp wrote: post #64

Earlier quoted context omitted.

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 a…

A big 'thank you' to you and the others working on this as it is badly needed! I've been following the progress of this work and I'm looking forward to the day when it makes it into testing. Unstable lives up to its name too often for my needs[1]. Unfortunately, my hobby project dance card is full right now or I'd probably try to pitch in.

Now a bit of cold water for real world use cases currently...

The bulk of the market is on 6700 XT and lower so ROCm is currently effectively saying 'we don't support the vast majority of our shipped cards for compute'[2] which sends a bad message to the consumer/prosumer market. Also, I do hope AMD reconsiders the requirement for PCIe 3.0 atomics support for compute as it seriously limits the utility of its cards in the consumer space.[3] It limits the compute support for most systems to a single slot (i.e. the processor direct PCIe connection) which will result in a 'no-sale' for many people.[4] I recently upgraded to a B550 system and imagine my surprise when I found out the chipset doesn't support it, but the compute drivers require it, so only one AMD card for me... this pushes me back to nVidia, or possibly Intel if they ever ship, for most of my compute needs for foreseeable future.

I don't write this to discourage you as it would be great to see AMD be successful on Linux. However, I think it's important for AMD folks to hear real world feedback on the current situation and understand you've got a long ways to go still: I'm on a full AMD system and my experience has been that it (GPU support) is far from ready for prime time so it probably won't be a full AMD system for much longer.

[1] Where key packages can disappear for months at a time and serious breakage can and does occur. I understand the need for this in unstable which is why I steer clear of it for my daily driver.

[2] Saying 'well just get a 6800 or better' isn't realistic given availability and pricing of the higher end cards to date. I had planned on getting a 6800 [XT] but was not willing to pay the markups due to scalpers/AIB markups. Even the AMD weekly drops didn't help on these cards. So I settled on a 6700 XT until prices return to a more sane level.

[3] I tried to raise this issue on the AMD forums but my message got marked as spam.

[4] Multi-GPU setups for compute are not uncommon on consumer hardware, especially rendering and ML.

Post reply on HN