Debian User Forums

Hallvor wrote: No, it doesn't have that checkbox that automatically installs the missing firmware by pressing yes. (...)

OK, it's not a checkbox - it's a radio-button
But seriously: the thing is that default Debian installer has an option to include non-free software, including firmware.

LE_746F6D617A7A69 wrote:

Hallvor wrote: No, it doesn't have that checkbox that automatically installs the missing firmware by pressing yes. (...)

OK, it's not a checkbox - it's a radio-button
But seriously: the thing is that default Debian installer has an option to include non-free software, including firmware.

That option adds non-free to sources, it doesn't install anything.

sunrat wrote:That option adds non-free to sources, it doesn't install anything.

Of course, but it allows to:
- install proprietary firmware after normal installation is finished.
- install missing firmware from additional installation media (*)

(*) At least in expert text mode - I've never used any other mode to install Debian - one of the reasons is the possibility to choose non-default NTP server.

Huh, the Politics of Operating Systems! It is always 'interesting' to discuss politics whatever the subject may be, and this, holds for a vast proportion of the population. Politics is all about values on which decisions are made which affect people. In our case, they are the decisions made by politically empowered representatives who decide what should be included in a distribution and what should not.

In my case, having non-free forcefully removed rendered my laptops and even some destops with several hardware pieces not working and above all inexistent from the Linux kernel's point of view.

Let me put it bluntly: the biggest weakness of all Linux distributions is the provision of hardware drivers or as they are called kernel modules. Most users are left deeply frustrated and disappointed after struggling for hours upon hours to install and experience what they imagine, an exciting 'new' operating system.

The Linux kernel developer team could have created a fork of the ndiswrapper package to make it compatible with a wider range of hardware devices. As it is, it is limited only to network devices, although, very ironically, this is NOT the ONLY instance when someone may find themselves struggling with a piece of hardware with only a Windows driver available.

I will recount my experience struggling to breathlessness to make a Hantek USB oscilloscope properly work under Linux. Hantek only make drivers for MS Windows, and reading sites about the many various attempts to crack and reverse-engineer their driver, has consistently shown they change driver architecture to break whatever crack ever surfaces at great effors by reverse-engineers. A package that would permit the use of Hantek's drivers would allow the oscilloscope software to be used under WINE running under Linux. Hantek's software frontend GUI works under WINE.

Any Linux distribution, especially Debian or Devuan, would be a huge advancement with so many tools available. Currently, I run the simpler to use LTSpice simulator under WINE which works with sufficient speed to be useful and comfortable. Why should a much much simpler application fail to work under Linux, for the simple reason of a political standing which has proven time and time again, it goes against most business practices, and most manufacturers are very hostile to adopting it as they want to protect their industrial secrets regarding internal hardware functioning?

edbarx wrote:Huh, the Politics of Operating Systems!

It's not politics, its a policy - aka contract or insurance or a plan.

There are many distros which have a different policy and everyone is free to use them.
Trying to enforce a change of Debian policy is at least a nonsense (speaking gently), especially in a situation where it is possible to use closed source drivers without any restrictions (in fact, it's even possible to use drivers from other distros)

edbarx wrote:I will recount my experience struggling to breathlessness to make a Hantek USB oscilloscope properly work under Linux. Hantek only make drivers for MS Windows, (...)
Any Linux distribution, especially Debian or Devuan, would be a huge advancement with so many tools available. Currently, I run the simpler to use LTSpice simulator under WINE which works with sufficient speed to be useful and comfortable.

I've used Hantek oscilloscopes - their firmware is littered with bugs (starting from little bugs in GUI and ending with broken fourier transform or software bandwith limiter) - better buy FLUKE
LTSpice is just a closed-source fork of ngspice, and ngspice is packaged for Debian, and it can be used with KiCad or GEDA, and there's also a gnucap.

edbarx wrote:Why should a much much simpler application fail to work under Linux, for the simple reason of a political standing which has proven time and time again, it goes against most business practices, and most manufacturers are very hostile to adopting it as they want to protect their industrial secrets regarding internal hardware functioning?

Openness of driver code has completely nothing to do with "industrial secrets regarding internal hardware functioning" - drivers are communicating with the interface that the "internal hardware" is exposing to the outside world.

F.e. AMD opened the specification of their GPUs, allowing to create open source drivers - have they bankrupt?
Now we have fully Linux-compatible AMD driver stack, while NVIDIA's drivers are just a hack which works only in typical use cases, and they lag behind regarding support for newest kernels.
BTW: NVIDIA's compressed (!) driver package for Winblows takes almost 500MB - obviously this is not just the driver, but that deserves a separate thread (on Windows forums )

"Know-how protection" - I've heard this excuse many times, but it has nothing to do with reality, where usually this means "Don't know how - protection". Proprietary software is never truly tested, exactly because of today's "business practices": software development takes 10% of time, testing/QA takes 90% - so accordingly to the best "business practices", the proprietry drivers are not fully tested - they are tested by the users...
Open source code ensures higher quality, because it is tested by the developers, who really do care about their reputation, which is tightly tied to the quality of source code - and this makes a huge difference.

It's like this. Imagine you're swimming in a lovely pool of crystal clear water... The pool may not be so big but it's so clean you can drink from it. Then WTF!
Someone wants to take a dump in the pool. Now we might have a turd in the pool. What choices do we have?

1. Get out the pool swim in another cleaner pool : fsf free distro
2. Try and swim around it. : currently Debian main
3. Remove it to another pool : Debian contrib/nonfree
4. Eat the turd : Might be very tasty, but it will lead to 5
5. Death of Debian

edit:
If one has free hardware and free software "hard to install" does not exist. Spend time and money where it's needed. I've been trying to run both for so long that the question is almost irrelevant.

've used Hantek oscilloscopes - their firmware is littered with bugs (starting from little bugs in GUI and ending with broken fourier transform or software bandwith limiter) - better buy FLUKE

FLUKE?! You mean, the exorbitantly priced brand? Well, if one wants to impress the gullible and naive, one can choose to impress.

Openness of driver code has completely nothing to do with "industrial secrets regarding internal hardware functioning"

Openess has a LOT to do with industrial secrets as it is the opposite. Publishing how software should communicate with hardware can easily give insights regarding the hardware's architecture. Manufacturers do NOT want to risk that. Remember, there are very very intelligent people who can easily conclude how a piece of hardware works given enough hints.

Dear respondent, like you and many others who use Linux, I depend entirely on it, but facts remain facts irrespective of denial.

oswaldkelso wrote:If one has free hardware

So I take it you don't have a hard drive on your computer then? Stuxnet demonstrated that the controller firmware is well suited to malware payloads.

Even RAM will have firmware in future: https://www.devever.net/~hl/omi

Head_on_a_Stick wrote:

oswaldkelso wrote:If one has free hardware

So I take it you don't have a hard drive on your computer then? Stuxnet demonstrated that the controller firmware is well suited to malware payloads.

Even RAM will have firmware in future: https://www.devever.net/~hl/omi

Don't talk wet. It strikes me that the first thing to do if you were worried about unaudited code running on your machine would be don't install contrib/non-free and any non-free blobs.

What has someone hacking in to my machine and installing dodgy malware got to do with Debian sticking non-free blobs in the install disk. If GCHQ/The Chinese/ Russians etc want to hack in to my PC or anyone elses I doubt there is anything we could do about it. The whole point of Main/contrib/non-free is about user choice. There are plenty options for people that want non-free if they RTFM. For people that don't care Ubuntu is over there >>--->

edbarx wrote:

've used Hantek oscilloscopes - their firmware is littered with bugs (starting from little bugs in GUI and ending with broken fourier transform or software bandwith limiter) - better buy FLUKE

FLUKE?! You mean, the exorbitantly priced brand? Well, if one wants to impress the gullible and naive, one can choose to impress.

Well, FLUKE is definitely overpriced - I agree (at least +30..40% more than real HW value), but I've never found any software BUG in their equipment.

edbarx wrote:

Openness of driver code has completely nothing to do with "industrial secrets regarding internal hardware functioning"

Openess has a LOT to do with industrial secrets as it is the opposite. Publishing how software should communicate with hardware can easily give insights regarding the hardware's architecture. Manufacturers do NOT want to risk that. Remember, there are very very intelligent people who can easily conclude how a piece of hardware works given enough hints.

I think we have a misunderstanding here:
1. I've just gave an example of AMD GPUs - try to guess how the vertex shaders are implemented in the HW basing only on the description of the corresponding registers ...
2. Having sufficient experience in HW designing, You don't need to read the driver code - in such case It's just sufficient to read the product flyer - and implement the advertised features in your own, most probably better way

Historical notes:
1. The first stable Ethernet card driver for nForce3/4 has been created for Linux - NVIDIA was unable to create stable driver for their own chipset
2. Microshit was unable to write a stable USB3.0 driver for Win7 (system crashes) - probably they have stolen the stable driver from Linux, adjusting the code for WDM (windows driver model) - they are very good at stealing the code and ideas.

Interesting convo. Wondering how difficult it'd be to install Debian with eyes closed. They've even made provisions for visually impaired persons. Short of coming to someone's place and installing it for people, not sure what else the Debian project can be expected to do further.

Not shipping with nonfree has likely always been a founding principle .. I can't help but respect that. For those disinclined to make the slightest efforts or demonstrate any bit of technical competence can only say, awwww poor widdle fellas/felettes. Will spend the next 23secs of my life bawling eyes out over their plight n suffering.

oswaldkelso wrote:Don't talk wet.

Fair comment. Sorry for the noise.

This topic is very helpful to me.
Coming from Ubuntu family and Manjaro and others. I installed non-free and soon came to realize I have some missing firmware.

After spending the day looking at this I finally found some answers. There are several issues I encountered. debian installer mentioned non-free about wifi. That was the beginning. Found out I needed wifi along with bluetooth drivers.

$ sudo dmesg -T|grep error
[Fri Mar 5 09:32:26 2021] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2
[Fri Mar 5 09:32:27 2021] EXT4-fs (nvme0n1p4): re-mounted. Opts: errors=remount-ro
[Fri Mar 5 09:32:28 2021] r8169 0000:02:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
[Fri Mar 5 09:32:28 2021] bluetooth hci0: Direct firmware load for intel/ibt-17-16-1.sfi failed with error -2

that "i915/kbl_dmc_ver1_04.bin" error I couldn't get rid of until I issued a update-initramfs. Took me awhile to find that out.
There was something about a "yoyo" error, but now that's gone. I always wondered about the 200-500 megbyte firmware folder that Ubuntu has. I would just try and edit out what I thought was unneeded. I know what version of wifi, bluetooth I had. There's a tone of drivers that I will never need, hence the mega folder.
An Admin over at Manjaro told me not to remove any files from that folder because it will be rebuilt on the next update, and I was foolish for doing so.

Didn't know much about non-free or why the firmware folder was so large until I started reading this topic. Quite the learning experience!
I kept seeing this topic getting a lot of traction but never read it until today. Thanks for asking a question that I didn't know I needed.
Now I'm very glad I accidentally install a non-free debian.

What I always found extremely unintuitive, is the disk partitioner. Since, usually, I have other installations on the same disk, I must always opt to use the manual partitioner. But I always end up not being able to continue with the installation except for the last two installations. Previously, I had to resort to using debootstrap to first install a very minimal base system, manually add to it files like /etc/network/interfaces and add a root user and a normal user. Then, after connecting to the internet, if allowed, I would continue installing the rest of the system manually.

The 'unintuitive' step was, that I did not realise I had to press enter before a dialog was displayed allowing me to make changes to various partition options like mount points, file system, label, etc.

I take it, it is my wetware that is to blame: ageing is unrelenting and my wetware is no longer that sharp.

edbarx wrote:What I always found extremely unintuitive, is the disk partitioner (...)

I'm a little bit surprised: I'm always using the console to setup my RAID - perhaps You didn't realize that during installation it's still possible to to switch between TTY's (ctrl-alt-F<2..7>) - and f.e. use the tune2fs to configure the partitions/devices ...

LMAO wetware = brain, ... nice. I was like what the hell is wetware, did they come out with something, should I google ? Then it hit me ... looks like my wetware is getting kinda buggy too.

Don't remember why but pretty much from the start took to prepartitioning with something like gparted live or whatever setting up for installs. So not overly sure about the installers partitioner. Can see how it could be confusing though. At least it's got a confirmation dialogue etc.

Also at some point switched to a no more than 3 installs at any given time rule. Which now it's down to one. Debian long since cured me of the distro-hop, may briefly revisit some distro's like Linux Mint occasionally but never for long. Tend to keep a testing partition for the purpose ready to go just in case.

When get to that step of doing an install, designating partitions, think it's definitely a good time to double check and look twice before pressing buttons. Have always done the manually guided thing, thought of the automagic install options makes me uneasy and my teeth sweat.