Very bad choice of design for the website. I'm supposed to be interested in this, but this website looks like they're trying to sell me some multi-million contract.
Too much white space. They could have condensed it quite a bit. And who needs a hero image that big anyway? That was "modern" when people just started using the word "modern". Like using the word "modern" now, it's pretty dated.
Define "technical requirement". It's not really technical, it's political. As an end user, I couldn't care less about being able to inspect how the code works. What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".
If they are afraid of getting bug reports from guys running out-of-tree drivers, they can still keep using the "tainted" mechanism. It is not incompatible with having a stable API.
I believe that the Linux folks don't want a stable ABI because they want to be able to smoothly redesign the internal architecture of their kernel whenever they want. Once you have a stable ABI, you have to worry about continuing to support the model of that ABI for a long time (or, if something akin to the "don't break userspace" policy were adopted, forever), which ossifies your design & blocks you from adding certain features. Additionally, by applying technical and political pressure to move drivers in-tree, the kernel devs gain the power to self-maintain over time (even Windows breaks its ABIs every once in a while and causes havoc: see Vista)
That's the rationale Linux people give. But FreeBSD has managed to maintain much stronger backwards compatibility (with older ABIs gradually moved into -compat modules and eventually removed entirely) than Linux without it noticeably damaging kernel development speed. Linux is the only major platform where hardware that worked frequently stops working (not just because of closed-source drivers; the same problems exist for open-source drivers that are out-of-tree for whatever reason - there are plenty of high-quality open-source drivers that the kernel doesn't accept in-tree or that don't want to be in-tree), and what do you actually gain for that high price?
> What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".
Quit the rage and just stick to Windows then. I'm using NVIDIA card and don't want to have this supposedly "stable API" which would leave me at the mercy of their whimsy. NVIDIA as a company deserves much more shame than the middle finger which Linus gave them. And there's no politics here, it's simply their business decision not to support Linux, not the other way around. Once you make an exception for one company you ought to do this for everyone else, it's not how that works in the Kernel community. So yeah it is a "technical requirement", technically it is how drivers get their stable implementation there.
That's got nothing to do with having a stable API. There are thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows and which will keep working for years to come.
Linux made the political decision not to allow this, at the expense of end users.
That seems the exact opposite of my experience. Most hardware drivers break after one or two Windows versions once the vendor stops updating the driver, eg. audio hardware, printers. On Linux things generally keep working. As an end user, having drivers in-tree is one of Linux's best features.
Having drivers in-tree is great, but a lot of drivers can't or won't be in-tree. My webcam (using qc-usb), PDA (using synce) and TV capture card (I can't remember what the project that supports those was called) all stopped working on Linux, even though the drivers were open-source and seemingly high-quality, because that's not enough for Linux - you have to be in-tree or you'll get broken.
At the time when I had TV capture card (Hauppage PVR250; it was analog TV tuner with MPEG-2 hw encoder), it stopped working in Windows way before Linux: in XP, the driver installation was showing HRESULT errors, but once a blue moon it would succeed. Forget anything newer. With Linux, I think it should work with the current ivtv driver, but I don't have it anymore to try.
Another example are scanners. Does your driver for Windows use TWAIN? Well, then it won't work in Windows 10 anymore, which made WIA the only option. Lot of fun for folks, who were automatically updated.
> thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows
Is that really true? A couple months ago I bought a USB to serial adapter that advertised Windows Vista support on the packaging. It did not work with Windows 10 at all, and I ended up returning it.
I have plenty of hazy memories of printers that worked fine under Windows 9x not playing nice with Windows XP.
It's unfair to use printers as an example. For one, they're still a huge problem in Linux, but for two they're universally regarded as some of the crappiest things to work with in all of IT.
For the record, the last time I did this it was Ubuntu and I think the printer was Brother. Neither particularly uncommon. Point is, because you're an apologist it literally doesn't matter what my circumstances are, you'll try to blame me anyways.
Just like you were describing your experience, I was describing mine.
But because you experienced the not-so-ideal scenario, doesn't mean that all scenarios are like that. If I used your argumentation, you are just an hater that blames system you don't like, in the most general way possible, which unsurprisingly includes scenarios that objectively do not conform to your description.
Note that I wrote "if the specific model is supported" and "the hard part is to choose, which model to purchase."
> Note that I wrote "if the specific model is supported" and "the hard part is to choose, which model to purchase."
Yeah, but that certainly doesn't mean it doesn't have a lot of problems with printers now does it? After all, I can say that IE works great as long as you only visit pages supported by IE.
Compared to other operating systems? Not that many problems. The printer queues do not magically disappear, or refuse to work for some unknown reason, which of course they will not tell you.
There are always both more and less problematic pieces of hardware. Given the forum where we discuss, it is reasonable to assume, that we both know which are which, and make a reasonable effort to avoid the former.
If doesn't always work: at home, I have an older Samsung MFD, which uses the older splix driver, and it works great. Due to that experience, I've got another Samsung printer for the office, but this one is newer and uses the closed-source uld driver. It means, that this printer doesn't work out of the box, driver installation is necessary (after that it will auto-discover anything it should, though). Not that it doesn't work, but it is a minor annoyance. It also means, that I won't be purchasing any Samsung-branded printer in the future (not that it matters, they sold the printer division to HP).
On the other hand, at friends & family, any HP printer, both inkjet and laser, worked out of the box. When I can, I won't be getting any Brother, OKI, Lexmark or another second-tier branded printer, because they were PITA even in 90's and under Windows.
So is it perfect for every piece of hardware? No. But is it that bad, as you said? Also no, that's too much overgeneralization and extrapolation.
Well, 9x and XP were two completely different operating systems that just implemented similar user space APIs. That was a one time transition. Drivers written for NT or 2k might have worked.
> Linux made the political decision not to allow this, at the expense of end users.
There are many pros and cons of having a stable API, and it can be technical and political and more. Saying it's just a "political decision" is plain wrong.
That is true and, at the same time, the EU is forcing all countries to implement this directive into their law, whether they want it or not. There are 8 countries that don't want it, but they can't oppose.
Every country in the EU agreed to implement these directives when they joined the EU, whether they agreed to it or not. There were various stipulations on how much support there needed to be before everyone had to implement them. Some things need unanimous support (trade deals, accession), some countries have certain opts outs in certain areas
However when it comes to harmonizing copyright legislation it was agreed unaminously that 65% of the EU population, plus 55% of the EU countries, could implement laws that are binding on the rest.
DNS over HTTPS and DNS over TLS require URLs. Controversial features in that they break abstractions apart from breaking some apps too (for instance, usage of TCP, overhead of TLS/SSL handshakes, absuing HTTP etc)
systemd became a standard because the guy works at Red Hat so he can make GNOME require it (there is no way to use GNOME without systemd; distros that allow that such as Gentoo do so by patching GNOME, which is costly.)
I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.
You make it sound like the systemd author was something the CEO of all Linux Distros.
The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd:
0) it is hotplug capable
1) we can know the state of the system
2) it is modular
3) it allows dbus/udev to go back to doing the task they are meant to do
4) we can reduce the number of explicit ordering dependencies between daemons
5) we get a lot of security/sandboxing features for free
6) systemd service files can be written and distributed upstream
7) systemd is a cross-distro project
8) logind will finally deliver on what consolekit was supposed to do
9) systemd is fast
systemd became a standard because Debian adopted it after a lengthy discussion, partially because big Debian users like Spotify expressed an interest in systemd.
The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out, so systemd was changed to mass kill processes. The interplay between GNOME and systemd in backroom dealings is a major pain point.
I think that's an oversimplification. There are definitely cases where some thing started as a daemon under a user session, graphical or not, should be killed to be safe. For example, ssh-agent.
There are other things that are meant to be left around, as that's their purpose, such as screen and tmux.
I would say the safe solution would be to kill everything in the user session at multiple levels (GNOME, and user session management demon like logind, etc), and to provide a defined safe way for the very few programs that want to stick around to do so. That seems like what systemd came up with as well.
I don't believe this to be a "conspiracy". It's nothing shadowy, really. What they did is completely natural. That doesn't mean I support the idea though.
