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_ and downloading the firmware included image) further dilutes the project's free software position and will encourage users to install software that does not respect their freedoms. If users never brush up against the inconvenience they'll be much less likely to seek out hardware alternatives or even educate themselves on the topic at all, this is damaging to the community as a whole.
I know I'm in the minority, and expect my opinion to be weighted accordingly, but principle is a key factor I use when choosing anything - including software. My loyalty to Debian would be significantly impacted by such a change.
Is Debian missing projected growth KPI's or shedding users? Is this a key hurdle to onboarding new contributors? I'm aware there may be other considerations that those actively participating in the community or leadership may be aware of that I am not, and I might be ignorant to the full value of the proposition. Debian is amazing and I have the upmost respect for everyone involved over the decades, but a move in a direction that weakens its position on non-free components would most likely drive me to using Guix exclusively.
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.
Enabling it should display a big scary warning about handing over partial control of your machine to greedy faceless megacorps who will throw you under the bus in a heartbeat if that makes them money. Maybe add an illustration of a robot terminator, to really drive the point home.
Yes, I agree that a default Debian configuration should be clean. But I also know the reality of needing at least Atheros (Wifi), Intel (Ethernet), and NVIDIA firmware blobs to get my tower to boot correctly. Not including any firmware repository on the CD or on a fully installed system is just a recipe for users to get frustrated while they are trying to follow a half-outdated tutorial on one of those spammy tech support blogs.
So in my opinion, the most common blobs should be cached by default, but not activated by default. If the machine boots without them, they can be deleted upon first reboot. If not, we can let the user decide if they are willing to compromise their principles in order to boot the system ;)
> 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. Actually there are Zip files containing all firmware for a release, which can be added to a USB drive and added during install, but it's not well documented.
Maybe, this Zip files can be made more prominent, and using them can be better documented. Yes, it's not including firmware in the CD, but it's a good compromise.
What about a nice tool (akin to GRML2USB) which writes the ISO to USB and leaves a mountable FAT32 partition where user can drop in the firmware.zip file, so it becomes self contained if user wants?
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.
I know they're present, but they're "Unofficial ISOs", and most people don't get these (incl. me, when I need them).
The blog post is putting the idea of adding the firmware blobs into the official ISO files, and as a Debian user, I'm not comfortable with that.
So, I'm offering another trade-off: "Make inclusion of firmware blobs to installation media on the fly easier, keep firmware off the official ISOs". It's a bit of a DIY solution, but it doesn't need flexing policies, DFSG and the values Debian is standing for.
IIRC there are ways to use the firmware blobs with the official free ISOs, but I have never bothered with that, just having them present in the ISO and not having to fiddle around with putting them where they are expected is easier.
You can just add the firmware.zip file (or extract it, I don't remember clearly) to a USB drive, and the installer will just mount and use it during installation. So, if there's a tool to merge both easier, or better documentation for the current situation, the problem will solve itself, in my opinion.
I get the trouble for networking chipsets, but not for the video card - all x86 systems should be able to fall back to ye goode olde days of at least a text console using the old BIOS interface. A default setup of any Linux distribution should in my opinion at least automatically detect if there is something lacking for a framebuffer console or a GUI, and fall back to a plain console.
This isn't what the radeon driver does for AMD gpu's, and hasn't for years: loading the driver automatically enables the full rendering engine and disables the VESA modes, even if no firmware has been loaded. Which means that on a normal system with radeon.ko present but not the firmware files, you get a few seconds of kernel output followed by a black screen. For the systems where I don't want the firmware (servers), I must be very careful to blacklist the radeon driver or I completely lose the local console.
This has been the case since the SI chipsets in 2012. I'm not sure if the fault lies fully with the driver, maybe the hardware doesn't allow querying the state of the engine firmware before enabling the engine.
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.
Because of the very common issue with network card firmware (wired&wireless) I have taken to always providing initial network access during install through me hooking up my phone via USB-tethering. No Firmware needed.
Then select "expert mode", enable "non-free" repo, maybe "backports", go through base install only, reboot, re-enable USB-tethering a last time on the phone, install needed network card firmware, reboot, disconnect phone, run "tasksel", select whatever you want to install to finish install.
Having done this "detour" for many years now, it's "automatic" for me, and takes barely 3 minutes longer than the "normal" install from the IsoWithNonFree.
I usually want "backports" enabled, so going into "expert mode" is required anyway.
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 install an OS. I understand the FOSS advocacy angle, but this is impractically stupid. You're not the only one who has learned to deal with this, so I'd wager there's months if not years of waking hours lost to what could easily be automated away.
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.
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.
This kind of attitude is what makes FOSS good compared to (for example) ChromeOS though. It's hard to see when you've got one singular problem in front of you but once you abandon your principles and change all these things you're left with what is essentially Windows lite. It might be popular but it's hardly an improvement.
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 get applications in containers and other things like that.
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.
You're correct, there might be a text-mode fallback. It's just that it is effectively useless for me. If I don't have network access, how am I going to install the firmware for the network card?
That's why I believe the most common firmware .deb packages should be cached during installation so that they are on-disk in case they are needed.
Back in my early Linux days I had an issue where the default Ubuntu/Debian installer would come up with a garbled display and I'd have to use `vga=...` or `nomodeset` (or similar, can't remember) to get a proper console going. Once installed I would install a package and it would "just work".
A way to directly boot into an environment with non-free firmware available could help and the user doesn't lose any more freedom if they're already determined to use non-free firmware post-install anyway.
> meaning it needs to be stored on the official CD
Wouldn't this imply per-seat IP licenses for things like embedded H.264 software fallback decoding in GPU drivers? I.e. the reason that Ubuntu (that doesn't really care about "proprietary" software by itself) still doesn't ship media codecs on the CD, nor driver blobs that could include them?
As a long time non-contributing Debian/Ubuntu user (I hop between the two whenever one of them annoys me too much), I've had a lot of issues locating and using non-free firmware when required.
For the longest time (since fixed), trying to use Wi-Fi in debian-installer simply didn't work, regardless whether I used the unofficial image or dumped the firmware debs on disk. Can't complain about that anymore since it's fixed.
Now that Wi-Fi works when available at install-time, let's try to install a bog standard desktop system. Did you run the text installer or the graphical installer? If you used the text installer, you might be surprised to get an unescapable gray screen on an otherwise fully working booted system! Your video out doesn't work properly because kernel modesetting doesn't work without firmware or some mumbo jumbo like that. Your options are:
- Run the graphical installer in the first place so that the GPU firmware is used/installed by the installer
- Run a shell in the text installer and do "apt-install firmware-blah", a command which is only documented in a dusty unstyled html in a file cabinet hidden by a beware of leopard sign copyrighted 2010
- On boot up, use some relatively arcane GRUB magic (I'm just a user, so I have to look it up every time, okay?) to boot into some kind of safe non-graphical mode and install the GPU firmware
(Bonus: the unofficial firmware-included disc image symlinks the firmware debs, so the image only works when you DD it. The most popular Windows disc writing software Rufus recommends writing disc images in ISO mode (file-by-file) so that you can use excess free space. If you're wondering why the firmware directory has a bunch of 0 byte files, that's why, and you need to switch to DD mode.)
> My loyalty to Debian would be significantly impacted by such a change.
It's so funny that this doesn't affect you at all but merely making the platform more accessible "significantly impacts" your loyalty.
Doesn't that mean your loyalty was conditional anyway? You are ready to jump ship if anything you don't like changes, even if it doesn't have anything to do with your system. Some loyalty.
the generous interpretation of their comment is that their loyalty is predicated on an understanding of shared values; if it transpires that the values are not, in fact, shared, then their relationship may require re-evaluation.
> 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 have had some doubts about Dell installs which had non-free blob dependencies which were "insert USB stick and hit enter" -when I am doing remote install via virtual media. Mainly this was for broadcom ethernets.
I found in the end, proceeding to install and then post-install patching was easier but tedious.
If you have access to USB slots, this is a non-problem. If it were possible to find and make and maintain "CD with a bit of the blobset glued in" I'd be happier frankly.
This could be seen as a benefit and a downside. It’s basically suggesting that you find other distros nicer to use but chose to use the less nice one due to principals. Most users will pick the nicer to use one.
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 regularly use the "firmware-misc-nonfree" package, along with 9.57% for the realtek package, 8.76% for the modern Intel wifi firmware package (iwlwifi), and 7.07% for firmware-amd-graphics.
I can't claim that's a statistically significant percentage of Debian users, I don't have that data, but of the ones who volunteered their information, even assuming perfect overlap, a not insignificant number of users are happily opting into the "not officially Debian, we swear" portion of the world.
Speaking as someone who is part of this "significant percentage of Debian users", I'd like to point out that opting in is the key part in the phrase "happily opting into".
I've made a conscious choice to install the non free packages. I'm quite happy I had that choice, but I'm even happier that they weren't forced on me.
I certainly hope nobody will point to me and say "look here, non-free should obviously be the default!"
I don't think anyone is proposing removing the ability to not install with nonfree packages, merely whether the default should remain as it is.
Personally, while I would prefer to be able to change and replace the software running on the tiny computers that make up a modern system, focusing on the distinction between "the vendor shipped it on a flash chip so we don't have to think about it" and "we need to load it at runtime" seemed a bit like spending too much effort on too little reward, to me - if we convince the manufacturer to up the cost by a few cents to hide the firmware blob from us, is that really a victory for Free Software, simply because we don't have to think about it? (Particularly if it sometimes results in never having ready access to a mechanism to replace the firmware blob, should someone sufficiently motivated either convince them to Free it or develop a replacement?)
It's great whenever someone develops replacements bits or, even more rarely, convinces a company to release their firmware bits permissively, but without a list of examples of Debian's stance changing the policies of other organizations, I think it's not that effective a tool for changing behavior in this case, and instead primarily inconveniences people who want to use Debian.
Whether they end up changing the default behavior or not, people in this thread replying "wait, there are firmware-bundled images?" makes me think Debian should either stop making them or stop making them so unintuitive to discover.
I'm a Debian desktop user for both principles and stability. I try to use free software only, but I use the non-free ISO when installing onto a new machine, because I need it to work in the first place.
The Web has plenty of tutorials explaining the installation process and the difference between the official ISO and the non-free ISO, even though I would love a better Debian Wiki.
Maybe it's a bit of gatekeeping, but popularity by itself shouldn't be the goal for Debian. You don't know how to install Debian, you don't want to search for a tutorial first, you won't let someone more knowledgeable to help you? Well, I believe this is not the best place for you, you'll face worse things on the road if you keep using Linux.
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.)
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 do where you check a box on install to include the proprietary bits.
I'm a Debian desktop user not because of principles - I use proprietary blobs including Nvidia's drivers - but just because it's what works best of the distros I know.
I've been burned a couple times too many on Ubuntu's regressions. They'll ship a newer version of a package that breaks some use case which isn't super common but not super obscure either, and then I have to figure out what broke. I've stopped trusting Ubuntu's packages so I don't use Mint either even though I like the distro.
Debian continues to impress me with its stability. I run the testing branch at home and breakage is still extremely rare. Yes, there's things that Debian makes harder to set up, and running Debian means you basically resign yourself to running a userspace that's 1+ year old, but the overall experience just works better in my experience.
Maybe I should give Fedora a serious try one day. I haven't properly used any Red Hat based desktop since Mandrake but I did like CentOS a lot for servers.
Have been using Debian as my daily driver for 5+ years on both desktops and laptops. No issues at all though I did spend some time on gnome shell to get it closer to what I prefer (multiple desktops, alt-tab behaviour, etc)
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.)
I use Debian on desktop, because it's the most problem-free distro I've used. Once something works, it usually stays this way with no effort on my part. Ubuntu was the opposite for me, which is weird given how it's a Debian derivative.
I don't care about FOSS, so the principles are not a motivation for me.
I have no idea but it stayed through many staff changes. The university I went to next (U. Bordeaux, ~50k students) 's comp. sci. department computers were also running Debian iirc.
I don't want non-free software. I don't find other distros nicer to use. I chose a distribution whose values aligned with mine. I have switched before and will, admittedly reluctantly, change again to find one whose principals align with mine. I find Debian, as it exists now, the correct balance of ease of use while still respecting my ideals.
I line-up with Debian's principled stand against non-free blobs.
Having said that, my reason for preferring firmware freedom mainly isn't principle; it's that non-free firmware potentially deprives me of control of my own equipment. By turning it's nose up at non-free firmware, Debian increases incentives for people to buy equipment that depends less on these blobs. That in turn incentivises manufacturers to offer equipment that doesn't depend on blobbiness.
I realise that these incentives are strictly at the margin; but Debian is the only leading distro that takes a hard line on these matters. If Debian were to retire from the battlefield, nobody would be left standing except the closed-firmware hardware makers. That would make me sad.
The problem is that freedom respecting hardware pretty much doesn't exist if you are buying the latest generation of hardware from popular vendors. Even if you are willing to go outside of x86, even the latest generation of OpenPOWER requires blobs.
> By turning it's nose up at non-free firmware, Debian increases incentives for people to buy equipment that depends less on these blobs. That in turn incentivises manufacturers to offer equipment that doesn't depend on blobbiness.
Actually, it only incentives people to buy and manufacturers to offer equipment which has the exact same blobs on a NAND chip on the equipment itself. It's more convenient, sure, since there's no need to find a copy of (the correct version of) the blob and load it together with the driver, but it still depends on these blobs.
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.
That sounds like an issue that should not happen, please report a bug about it. The non-free version should be identical to the free version except for the installed firmware.
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, and almost all of them will choose the latter in a big net loss for freedom. (E.g., "What do you mean this Linux thing doesn't support my network card unless I jump through all these hoops? I'll stick with Windows, where it just works out of the box.")
> 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
How about all three? We have plenty of very good "open with proprietary firmware" distros, many very similar to debian (Ubuntu, PopOS, Mint, Manjaro...), but not that many good "fully open" ones. That is the whole point of distros. If we dilute Debian's fully open philosophy, we don't really gain anything in middle category, but lose one of the few remaining good fully open distros.
To fix your example:
"Oh, you say this Debian thing doesn't support my network card? I see why everyone recommended that Pop thing instead, I'll use that then."
Debian is not a friendly distro for users who don't know what they're getting themselves into and that's fine. That's why nobody should (and nobody does) recommend it to Windows users looking for their first Linux distro.
I think part of the problem is identifying which of those alternatives is closest to "exactly Debian, but without the hardware support problems". You really want something which tracks closely enough that bug reports against packages in that distro could be directly and intentionally accepted by Debian's tracker.
The problem with accepting "Debian is not a friendly distro and that's fine" is that unlesss the snags are addressed, the number of reasons for people to run off to Pop and Ubuntu will only increase over time. Having a friendlier on-ramp to something that is actually Debian is good, but I suspect you could satisfy the "keep Debian pure" requirement with a fairly thin branding layer.
Yes, but it needs a different name to create a clear space between Debian's comparative purity and the ideologically messy practicalities of actually getting the hardware working. Technically there's little challenge, the hard work on that part has been done.
"What is the likelihood of closed-firmware-blob hardware manufacturers changing their behavior because of Debian?"
vs
"What is the likelihood of fewer people using Debian because their installer is more difficult?"
IMHO, the odds aren't good that ideological purity is going to have any net result on hardware manufacturers. So you're really just shooting yourself in the foot so you can feel painfully just.
That said, there are absolutely fights Debian can and should focus on, even if they're painful: ones where there's a chance of victory, and the rewards of victory balance with the risks of the attempt.
Why cant FSF groups just do what FANG do, and make it easy for users in the first place, then once you have them in your walled garden pull the ol' ideological switcharoo.
It goes against the whole point of user freedom, which is kind of like starting a nonviolent movement and then pointing guns at people if they refuse to join.
100% this. A decade ago I needed to replace some internal Linux file servers. I was keen to try ZFS, and so I tried BSD. Naturally on new hardware. Turns out BSD didn't support the on-board ether net. Tried a bunch of network cards from the cupboard, no support their either. Opportunity lost.
Switched to Windows server (and was blown away by how polished that was, but that's another story.)
I get the advantages of free software, I really do, but this sort of neglect of usefulness in the name of ideological purity does not win converts.
On the other hand who cares? Free Software does not need to grow, it fulfils a purpose for those who want to be ideological pure, and I accept that is a valuable thing. Chasing converts at the cost of purity may just end up being no-man's-land.
Perhaps what the author is looking for I'd a debian derivitive, not debian itself?
> On the other hand who cares? Free Software does not need to grow
Sure, there's no VC breathing down the neck of Debian, but arguably the purpose of free software is to provide software freedom for users. If people aren't able to use that free software, it's a bit pointless. Further, a (small) fraction of users grow into developers creating more free software.
To the extent non-free firmware allows more people to use free software, I don't think it's clear at all that a puritan approach to firmware is a net win for software freedom.
The purpose is to provide free software _for those who want it_.
If the goal is to create converts then a puritanical approach is a poor approach, IMO.
Personally I've never seen the FSF approach as being "conversional" - rather it acts as a purity touchstone.
Debian needs to articulate its specific goals to the author, there are many paths they can take, but unless the goals are clearly articulated its hard to see what the right path is.
Note that some goals which we take for granted (everything should be free, get folk to switch) are not necessarily compatible. I think that is the root of this discussion.
I don't think Debian needs "converts". This isn't a religious revival movement. There are many Debian derivatives that aren't as arsey as Debian about non-free blobs; if that's what people want, then they should "convert" to one of those derivatives, rather than raw Debian.
One could just as well claim that if Debian decides to include non-free firmware on the official install images, those that are deeply offended about that can sod off and create some derivative distro with the dirty bits removed. It's not written in stone that Debian has to be the purest distro of them all.
Well, Debian the OS, yes. But where do you draw the line? Debian still allows your web browser to execute non-free Javascript that you download from some shady site on the internet. ;)
Anyway, for FW one can certainly argue it's not part of the OS, as it's executing in some auxiliary core on the device rather than being part of the OS itself executing on the main CPU's. And further, if that same non-free FW would be stored in ROM or on flash, Debian has no problems with it as long as open source drivers are present in the kernel. So the only problem here is devices that want the driver to provide the FW blob to them upon initialization instead of the FW blob being persistently stored on the device. Not really any meaningful difference from a software freedom perspective either way.
Debian itself provides the blobs for years, the post is mostly about making those CDs with blobs the default user experience for Debian itself, not for derivatives, some of which provide blobs by default.
> Switched to Windows server (and was blown away by how polished that was, but that's another story.)
Have you told this story anywhere else already? I'd love to read it. In a past life I worked very close to Windows Server, but I mostly selfhost Linux at home now.
What is it mostly identity related? I miss AD sometimes...or maybe storage? The SMB stack is pretty good too.
I haven't. I had set up the machine with 2 large spindle drives, 2 large SSDs, and a separate SSD for the OS.
after booting windows looked at the disk layout and asked me what I planned to do. It suggested some quick options, one of which was exactly what I planned to do (raid the spindle pair, and raid the SSD pair) and one even better (create a volume putting the SSD and spindle together, and then raid that.)
Yes thanks I said, and it did everything. By contrast setting up raid on the previous Linux box, albeit 5 years earlier) took days of searching for docs, specific magic incantations on the command line, and lots of rebooting.
So yes, I get the freedom thing, but sometimes a computer is just a tool, and I want it to just work.
If I recall correctly Fedora in the 2003 - 2006 era included an option to set up raid as part of the standard installer. Around the same time frame gnomes disk tool supported actually doing operations like replacing a disk in that array.
Even the incantation to do it manually isn't that magic. I'm guessing you could read the manual for the options to mdadm --create in minuted rather than days. If you want to be really fancy zpool create mirror foo mirror bar.
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 firmware.
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. If that policy were successful at promoting open firmware I think that would be acceptable, but I don't think I even need to argue that is not the case.
Not disagreeing that policies should be made with success in mind. But by the same reasoning "vegan" should include the top 5 most popular meat dishes as exceptions. This would easily make it more popular, more accessible and probably much more successful at reducing meat usage over all. The issue is that the definition of "success" might be entirely unacceptable. Just like "entirely free but...." might be unacceptable.
In all fairness, flexitarianism is a thing, and I know a lot of people who would never want to go fully vegetarian or vegan, but who want to reduce their meat intake significantly, generally for environmental reasons. The change in messaging from "a single animal death is murder and unacceptable" to "any reduction is good, the more the better" is probably significantly not effective in this context at actually reducing overall meat consumption (although I unfortunately don't have any evidence for that hunch).
The first time I tried becoming vegetarian I failed. I often had no reasonable options in restaurants nor social events. Also I live in a country where meat is cheap and barbecues are a key social activity.
Nowadays I still eat meat 0-2 times per week when my choices are limited, but that's much better than eating 14 times per week.
If you consider the fact that veganism/vegetarianism is very unhealthy without taking the nutrients you're missing as supplements (which could be argued as being "reverse engineered meat"), then I would suggest that yes, until we reverse engineer the "meat" we should include it in the "diet" (along Free software).
> 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.
As bad as it is in the short term the only way we'll see long term change is to keep the friction on. It's this friction that forces the change of habit to support manufacturers who open their firmware. If it's seamless then there's no incentive to seek out the open option next time you buy.
In my personal case nVidia stopped supporting my graphics card and eventually their binary blob stopped working with the newer Linux kernels so I had to chuck it away.
Now I've learnt the hard way that I'll never by nVidia again (or if I do I'll make sure it's open first). At the time nVidia was getting a lot of good press supporting Linux and I didn't realise that meant closed source blobs that would eventually stop working.
What incentive do manufacturers have to release open firmware? Let's get serious, it's been 20+ years and desktop Linux usage isn't moving the needle or getting any of their attention.
IMHO it would be far better to put effort into change at a different level, like perhaps a broader push with right to repair legislation that expands it to include releasing firmware in addition to schematics, spare parts, etc. Change is going to have to come from a different source, you're just abusing users today for no benefit.
Everyone in the embedded space goes to kernel.org for WiFi stuff (firmware, regulatory info etc) regardless of which OS they're using. Being put at the top of the Wiki because you're "easy to work with" would be a massive advertisement.
By all means, the "free software community" should promote HW with free firmware, and giving the top spot on the kernel.org pages sounds like a good approach. And yeah, I spent a lot of time looking at wifi drivers when getting a wifi router. ath9k was the gold standard here with no blobs, and as a result was the favored platform for the wifi bufferbloat work. Unfortunately the follow-up ath10k needs a blob.
But I don't think punishing potential users who just want to get their laptop to work is particularly effective free software advocacy. Most likely the user has no clue what wifi chip their laptop has.
> As bad as it is in the short term the only way we'll see long term change is to keep the friction on. It's this friction that forces the change of habit to support manufacturers who open their firmware. If it's seamless then there's no incentive to seek out the open option next time you buy.
My experience is the same as the author's: there's more today that needs non-free support to use Linux on the desktop than there was in the past.
So the friction isn't doing its job.
So why bother if the friction is just pushing users to distros which bundle the blobs more directly, instead of pushing manufacturers at all?
> My experience is the same as the author's: there's more today that needs non-free support to use Linux on the desktop than there was in the past.
Is that a function of Linux Desktop simply being more capable nowadays?
Also, there is a world of difference between not publishing signed closed-source firmware for a driver that does not exist vs having an open source driver with published firmware.
> Is that a function of Linux Desktop simply being more capable nowadays?
I don't think so - it's more a function of hardware becoming more complicated, and vendors choosing to put a lot of the logic in firmware rather than putting it in ROM because there's a much lower chance of them getting it right first time now than there was in the past.
Is hardware becoming more complicated without being more capable? I just think that we’re taking lots of things for granted nowadays, which require complexity to be managed successfully.
ROM to firmware creep is understandable, given flexibility that you mentioned. But to an end-user, is there a difference between having a blob in ROM vs firmware, if both are closed source?
> Is hardware becoming more complicated without being more capable?
I don't think so. Every component on my system that runs firmware is significantly more complicated than the iterations that didn't. 802.11ax is much harder than 802.11b, for instance.
> But to an end-user, is there a difference between having a blob in ROM vs firmware, if both are closed source?
Yeah, bugs that are discovered after release can be fixed.
> Yeah, bugs that are discovered after release can be fixed.
I definitely understand that real benefit.
But I was questioning the premise that having blob in ROM is somehow better than needing same blob in firmware, simply because that one doesn’t need/want to distribute non-free firmware on media.
If one wanted libre hardware, then both cases are not great.
> But I was questioning the premise that having blob in ROM is somehow better than needing same blob in firmware, simply because that one doesn’t need/want to distribute non-free firmware on media.
Oh right! I absolutely believe that having non-free firmware on media is preferable - in some cases this has led to free implementations that replace the non-free firmware, and even outside that, given the choice between non-free code that doesn't work and non-free code that does, I'd prefer to take the latter.
I wouldn't say the Linux Desktop has gotten any more capable since Compiz, so no. (Nor have most desktops - depending on how much you value things like iMessage integration in modern Macs.) Before that, since... Phoenix/Firebird/Firefox and the decline of IE-only sites? Office file format compatibility?
It's more the examples provided in the original article: cpu firmware blobs, network firmware blobs, same as always, just even more.
That's a good point. I think the author might be forgetting using ndis wrapper to run Windows drivers (so that's non-free software on the same machine as your OS) for unsupported network cards. We've come farther and have new, different problems now. The situation then looked bleak much like the situation now.
>As bad as it is in the short term the only way we'll see long term change is to keep the friction on. It's this friction that forces the change of habit to support manufacturers who open their firmware. If it's seamless then there's no incentive to seek out the open option next time you buy.
The only friction you're causing is to Debian users. My current laptop is Arch after 5 laptops that ran Debian. My Debian desktop is barely functional with the friendliest AMD GPU to Linux I could find.
By my next update cycle I will be Debian free for the first time in 20 years. Debian needs less friction if it wants to keep me as a user.
I doubt that has anything to do with "friction", Debian's release cycle just isn't compatible with wanting to run new hardware. Drivers are distributed via the kernel, Debian uses old kernels and can't afford to do the same kind of hardware enablement backports that Red Hat, SUSE and Canonical can do, so being stuck with the old kernel means poor support for brand new hardware.
>the only way we'll see long term change is to keep the friction on
... but there are two possible long term changes, right?
In one of them, the friction incrementally pushes manufacturers not to have proprietary firmware and the number of machines supported by the Debian official install improves.
In the other one, the friction incrementally discourages users from installing Debian, and they either give up on Linux or adopt a distribution that isn't quite so user-hostile.
Depends on how you define 'user-hostile'. There's already a link to the non-free image on the current installation page, and I wouldn't consider respecting your freedoms as hostile.
So if Debian were some megacorp, someone would already be complaining about the "dark pattern" that puts the link to the directory (n.b. not the actual images) for non-free images down the bottom of that page in small print inside a box labeled like a warning, and calls them "unofficial".
As opposed to making it clear that this is the one you need if you're doing something outrageous like ... using a laptop or something.
One way that vendors have released libre firmware is when someone already working on the proprietary firmware convinced their bosses that libre firmware is a good idea. This happened with two of the open WiFi firmware projects.
As long as the code running on the Linux side is open and the closed source firmware stays on their chip that's fine by me. At least then you have a fighting chance to change the open source side up to date to allow the card to keep working.
I know it's not pure freedom but I'm picking my battles these days and if I can keep something working by bridging the gap between an evolving kernel and static closed firmware then that's good enough for me.
>it's this friction that forces the change of habit to support manufacturers who open their firmware.
You can only force anyone to do anything if you have power. If you don't have power you're just a weird guy screaming from a soapbox and people are going to ignore you. No offense but do you think nvidia cares about your boycott? There's no shortage of graphics card buyers.
I assume the non-free version of Debian sees significant amounts of downloads, maybe at this point more than the free version, so the situation is obviously quite awful or this post would not exist.
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 have no idea how to install them, which ones mean what, what's free, non-free, optimal, professional - I have no idea how any of it works and it's a source of frustration for me.
What is mesa? Why do people tell me not to install the video drivers from the Radeon website. When I download and install the drivers from the Radeon website there are lots of errors but it still seems to work - did I install them wrong? How to I update them?
When I install the `apt install firmware-amd-graphics` I get loads of warning, but it works so I ignore them.
What is going on and why isn't it as simple as Window's where I run an executable and a setup wizard does the rest?
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 best. There is "AMDGPU Pro" video drivers, which gives you the AMD OpenGL/Vulkan libraries, but they are generally not as good as Mesa as Mesa has everyone working on it.
> How to I update them?
AMD have spent a lot of time getting them in the kernel. You update by getting the latest version of Debian, or switching to a distribution that uses a newer kernel.
> What is going on and why isn't it as simple as Window's where I run an executable and a setup wizard does the rest?
It is a lot more simple. It is all built in. This is the beauty of collaborative development, AMD and Intel get improvements based upon each others work and they concentrate on giving us better hardware. This is also the reason that AMD works so much better on Linux than Windows, and generally AMD gives Nvidia a run for its money on Linux, at least according to the last benchmarks I saw.
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 presented with the wrong resolution and no GPU acceleration - It's really hard to find a tl;dr of how to get your graphics card working.
Your comment was literally more valuable than a few hours on the internet trying to disambiguate the situation.
Yes, they are. Of the big three (Intel, AMD, Nvidia), only the Nvidia drivers aren't open source (there's an open source driver for Nvidia, called "nouveau", but it doesn't come from the manufacturer and isn't that good).
It doesn't do reclocking on any modern card, so the power consumption is vastly higher than it needs to be.
There are other points that aren't directly applicable to gaming which just aren't as great. Nouveau are pretty open and honest about how their driver will never be that great on the modern cards because Nvidia doesnt want it to be.
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.
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 `firmware-amd-graphics` package, it provides proprietary firmware for your GPU. That could be as insignificant as microcode updates or an important part of the interface that the driver expects. It's probably a good idea to install (and maybe try and fix the warnings.)
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 releases of enterprise distros. They can be made to work (with varying degrees of pain) for some releases of desktop distros but it is currently very far from painless.
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.
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. <sigh>
[4] Multi-GPU setups for compute are not uncommon on consumer hardware, especially rendering and ML.
I am just one lowly engineer, but I do what I can.
The other 5000 and 6000 series cards work to varying degrees. Unfortunately, since AMD doesn't officially support them, I can't easily get hardware to test them myself.
My understanding is that the RX 6700 XT (gfx1031) mostly works, with some caveats. Gentoo did some performance tuning for the BLAS libraries with that GPU. The AMD GPU libraries aren't built for that architecture by default, but I'd be happy to help anyone compile them from source. There's an extensive open source test suite that can be used to validate GPU functionality outside of the official hardware support list.
Don't get me wrong, your efforts are definitely appreciated. It would just be nice if AMD officially put more of a priority on consumer Linux users. That's the reason I push back on the assertion that AMD Linux GPU (compute) support is there: it really isn't as what we've got are retrofitted enterprise drivers that, if you can get them to install, may or may not work for a given GPU and have some caveats if they do work. And if they don't work, well tough luck as they aren't officially supported anyways. Short of official support happening, it would be nice to see at least some skunkworks project(s) to get open source compute drivers going as the open source graphics drivers work quite well.[1]
I've gotten both the 6700 XT and 6600 to work (that's how I discovered the PCIe atomics issue: trying to run both cards at the same time with OpenCL) which is why I initially said 'can be made to work'. It took quite a bit of fiddling and I'm sure having the drivers packaged in the Debian repos will be better still as I don't know what I don't know and knowledge on the ground re: AMD compute drivers still appears a bit thin.
[1] The part of this story I find so depressing is that AMD should be eating nVidia's lunch re: Linux support. But since at a management level AMD doesn't seem to care about consumer Linux they actually manage to make nVidia's drivers look good in comparison. It would be nice if they would take a page out of Intel's playbook and give engineers like yourself their support to actually do consumer (open source) Linux support work as your day job. I can dream...
I agree with a lot of what you're saying. Thanks for the support, and for the information about compatibility. That sort of info is not always easy to discover (let alone contextualize), so I definitely appreciate the feedback.
Setting aside the ideological arguments, the primary reason you should not be installing video drivers, or any other device drivers, outside of what your distro has packaged (if you can help it) is that they have an annoying tendency to break when you do a version upgrade leaving you with, if you're lucky, only the ability to log in via the command line or ssh. Worst case, you can end up with an entirely hosed install. Even if they work (for now), keeping them in sync with the rest of your system can be an exercise in frustration.
As someone who is currently dealing with proprietary AMD drivers (and previously proprietary nVidia drivers) on Debian testing, it's pretty much only a matter of time before things will break... you've been warned but I understand if you need to do it anyways (as I do for compute support with AMD currently.) I'm very much looking forward to the day when we have Debian packages (at least in the non-free repo) for current AMD GPU compute stuff.
Why would you want to? This is not something I want to actually have to care about. And also I absolutely don't have to.
> What is going on and why isn't it as simple as Window's where I run an executable and a setup wizard does the rest?
Do you mean the included drivers? Or the OEM ones? Or the Nvidia ones? Current or beta? Also, it is even simpler than that on distros that support nonfree stuff, e.g. on ubuntu it is just click here for which nvidia stuff you want and done. As opposed to navigate websites, versions and wizards in windows.
mesa is the thing that handles opengl and vulkan for most cards that aren't nvidia.
Generally you don't have to touch video drivers at all in linux except for arm stuff and nvidia. (that's not always the case,but mostly) Just keep your kernel up to date. That's the main problem with debian and wanting to say play games or have newer hardware.
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:
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.
OpenBSD is in a similar boat and continues to fight the good fight. The developers continue to reach out to the hardware manufacturers to get permission to include firmware in OpenBSD without an NDA. Sometimes they're successful, but, more often than not, they're not. I think if more of the open source community stood steadfast in this regard, more progress could be made here. The saddest part of all this, perhaps, is we're all purchasing hardware that is, basically, useless without the firmware as it's not included with the hardware we purchased.
OpenBSD kinda does what's proposed here. The firmware packages aren't included in the distribution per se, but they're auto downloaded. It's pretty transparent for users.
Yes, but one you need these blobs for wireless, you will may to use a wired connection or download them to a flash drive and copy them over.
What OpenBSD seems better, but in many cases, you may need a wired connection for on First Install. Upgrading, no issues but I like to be plugged in anyway just in case wireless drops.
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://wiki.debian.org/Firmware/Open
It's a depressingly short list.
I guess the problem is in part that there's no money to fund anyone for doing such (very hard) work, and no incentive for companies to pay for it.
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.
The canonical firmware is the BIOS, I was pleasantly surprised when Fedora updated the BIOS on my Dell XPS device by itself recently... historically that has been somewhere between a nuisance (Reboot and then UEFI network update), a struggle (dig out the image from an EXE on a flash drive), or impossible (some windows-only app that doesn't work via a VM). And whatever the annoyance level, when done manually it was usually done months or years after the BIOS release.
Other firmware the cpu microcode is handled via packaging.
There has been a lot of work packaging peripheral firmware for things like mice... it's not like it is going to go away. This is also distributed in packaging in Fedora now.
It's not ideal that these are proprietary blobs but some accommodation is needed I think.
That firmware update was made possible by the fwupd software project (containing various firmware updaters) and the LVFS project, a service for hardware vendors to upload their proprietary firmware updates for mice, the BIOS/UEFI and other devices to.
While it is great, it doesn't solve the problem that this post is talking about; when devices have no pre-installed firmware and expect you to upload (proprietary) firmware on every boot. This is usually things like WiFi chips, GPUs, Ethernet etc.
> it doesn't solve the problem that this post is talking about; when devices have no pre-installed firmware and expect you to upload (proprietary) firmware on every boot. This is usually things like WiFi chips, GPUs, Ethernet etc.
Same as Fedora, Debian seems to package linux-firmware?
Right, and linux-firmware contains mostly proprietary firmware. There is a small amount of libre firmware in it but that doesn't get built from source. The post is about directing users to an installer ISO that installs the proprietary firmware by default.
I hesitate to post, but I respect Debian. Firmware has gotten so large, all distributions and OS communities would benefit from focusing on it as a project to provide free firmware. I don't know how large the firmware developer community is. Firmware space has gotten so large, an entire OS could fit in there. What if there were a miniDebian, or miniFreeBSD, that was a virtuous but smaller reflection of the OS, not unlike iOS and macOS? I'm not sure if crypto or key signing by hw makers, under the excuse of security, makes this impossible, but I'd really like to have more options with the firmware on my machines. Like, why can't I run VMWare ESXi from firmware? It should fit in there. If if is technically possible, it should be allowed; we pay for the hardware, it belongs to us. Why is this even a thing? Who are the bad guys here? Why are they screwing with us?
The amount of people capable of doing firmware work is extremely low, and the amount of documentation available that's needed to write firmware for highly embedded systems is even lower - not to mention that the stuff that is implemented in this kind of firmware is extremely complex and if anything RF is involved it gets even hairier because of compliance to standards and legal regulations. Last thing an open source dev wants is complaints from users that their home got raided by the FCC for operating a noisy transmitter that interrupts service for someone else.
There isn't even enough manpower to get the Raspberry Pi, the world's most used embedded system for tinkerers, a fully blob-free experience - it's madness to expect that for systems like GPUs that are orders of magnitude more complex than that.
Is the situation really that different from how it used to be? At least for me personally, if I compare to around 2008 or so when I had Debian installed as the primary OS on a desktop PC and as a toy on my Mac laptop:
> Modern laptops normally don't come with wired ethernet now.
Both then and now, on my laptop, I use Ethernet occasionally but rarely, only when I specifically need its speed or reliability advantages. The rest of the time I use Wi-Fi, which did and does require non-free firmware. Ethernet moved from a built-in port to a dongle, but my actual usage patterns have barely changed.
That said, there used to be some Wi-Fi chips that didn't require non-free firmware (just not the ones I had), whereas now there are none.
For desktops, on the other hand, it was and is worth hooking up Ethernet, making the point largely moot. (I think I used Wi-Fi on my desktop at the time, but I wished I didn't have to. Now I don't.)
> There won't be any usable graphics on the laptop's screen.
Even at the time, I saw hardware-accelerated graphics as essential, both for windowing (Compiz) and for gaming. So I used the 'nvidia' non-free driver on the PC… just as I do now. (I don't remember what the Mac had.)
Incidentally, for those who don't prioritize graphics performance over freedom, free drivers are better than they used to be. Unfortunately, they require non-free firmware – and I know this post is about firmware. But still… that seems like a win of some sort.
What to do? Fund the development of, and provide to top tier support for open hardware and open firmware. Computers aren't just software, after all; Debian drawing the line at software probably needs to end.
There will always be calls to compromise on principles to maximize some metric or another. There are legions of business wannabes and people who think they know best, and they will sweetly offer up their opinions to tempt you towards what they think is best.
>Due to these reasons, more and more devices in a typical computer now need firmware to be uploaded at runtime for them to function correctly. This has grown:
> Going back 10 years or so, most computers only needed firmware uploads to make WiFi hardware work.
You can actually go back to almost 30 years with dialup modems, most notably the winmodem/softmodem popularizing this concept in the pc market. If there is anything to blame on this path of binary blobs, I'd fault them.
Non free firmware is a huge ongoing problem for me. I am posting this from a laptop that has some major failings because of the lack of updated firmware.
Slightly apart from the main issue here I would suggest that there is an opportunity for communication with some of the parties that matter most. Producing media that shows how much happier customers are with products that have freely available firmware with updates might convince some manufacturers to change their ways. If it were clear that power users would direct purchasing for whole organizations based in part on availability of firmware then there would be a clear profit motive for doing that. At this time makers see providing firmware as an expense and a risk that only diminishes their position.
Installing the non-free firmware on Debian is as easy or easier than similar installation on all other operating systems. So this is really a complaint about something that is almost as easy as it gets needing to be just slightly easier. It’s making a mountain out of a molehill.
That said, who cares if some users want it? Debian doesn’t aim to serve all users’ needs. Those who want non-free firmware bundled with the operating system can get that with one of the many Linux-based (or non Linux-based) operating systems out there. Debian just isn’t for those users. That’s fine.
It is annoying for sure, that for something like AMD GPU you have to go out of the way to get a "non official" Debian installer that includes amdgpu firmware, otherwise installer won't be able to work.
For the most part this annoyance affects the installation step. After your system is in some semi-working state where you at least can install packages or have access to network, you can add any firmware you want already.
I am a 20yr linux user. I got a new HP laptop recently and decided to try Debian. To my surprise Debian didn't recognise my network adapter and would not let me continue the installation. I wrongly assumed the installer would install, let me fix the adapter.
I read around and used an installer which apparently had proprietary drivers. Same issue, couldn't install.
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.
My 5c: Debian is a free base distro. For users who want an all-batteries-included image including non-free firmware, there are derivatives like Mint and Ubuntu. If someone wants to step up and maintain [Debian+non-free-firmware] releases, this will probably be greatly appreciated but it should not come at the expense of maintaining the rest of Debian and stretching their already thin resources.
One thing that could start paving a path forward would be to make contributing to Debian more approachable... Not saying they should get on GH/GL or anything, but there's huge room for improvement in their existing tools and docs.
Debian already maintains these images and has non-free firmware packages. They're just not enabled on the main installation disc by default. You can get non-free Debian images, they're just harder to get to.
Can anyone say with a straight face that there is anything wrong with Debian's vision or principles merely existing somewhere in the world?
Ok, so they exist somewhere in the world, in Debian.
And it predates you. Debian didn't come along and fuck up your life. There is no basis for any kind of "take it back" idea to "fix" Debian.
If you don't subscribe to those principles, great news! The entire rest of the world agrees with you! Go use Ubuntu or Mint or really anything.
If your argument is that Debian is an important base for countless users of other distros, and so it's inconsiderate or irresponsible or something not to serve all those indirect users better (according to your personal definition of "better"), well then why ARE so many other distros choosing Debian's shoulders to stand on if it's so unhelpful? All those other distros are perfectly free to provide their own base the "right" way.
You in fact are free yourself to launch a new better os to replace Debian. Go ahead. No one is stopping you. Show those backwards clods how it's done by practical people with their heads screwed on straight.
I know I'm in the minority, and expect my opinion to be weighted accordingly, but principle is a key factor I use when choosing anything - including software. My loyalty to Debian would be significantly impacted by such a change.
Is Debian missing projected growth KPI's or shedding users? Is this a key hurdle to onboarding new contributors? I'm aware there may be other considerations that those actively participating in the community or leadership may be aware of that I am not, and I might be ignorant to the full value of the proposition. Debian is amazing and I have the upmost respect for everyone involved over the decades, but a move in a direction that weakens its position on non-free components would most likely drive me to using Guix exclusively.