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