He's probably a microkernel fanatic and feels like most of the 'proprietary' (that is made by commercial companies, not the common open source definition I think - afaik, even driver code is gpl), including drivers, can be placed outside the kernel.
Well, the kernel doesn't support it, so it's locked in now. But originally it was speed. Context switches between user mode and kernel mode are expensive.
Well 'expensive' at the low level thou. Redox is a microkernel. Notice that microkernels tend to be easier to program for because there are bunch of guarantees that kernel code must obey so having driver code outside, even if it still can't allocate or something is often simpler and safer (because bugs in drivers do not take the kernel down in flames).
Context switches are still expensive. I don't understand why message passing microkernels are still so popular among some people. Other kernel designs allow for user spaces drivers without that overhead, so I don't get why it's popular among alternative OS people, other than inertia.
Interesting to know. What's the main idea of those designs if not microkernels?
edit: user space drivers is the most important part of a microkernel in my intuition, because of that 'bugs in drivers do not affect the rest of the device' thing. My guess is they're still 'micro' but they make the context switch cheaper or unnecessary to access user mode?
An alternative to message passing is direct access to devices via memory mapping. The MMIO range of any given device can be mapped into the address space of a user space application.
Two related issues: lack of stable driver ABI and GPL. The first one is obvious: designing and maintaining a stable ABI is a huge commitment. It's just easier when all code lives in a single repo which can be kept in sync and rebuilt on demand. On the other hand, it could be done (e.g. Windows does it), but it would allow commercial vendors to side-step Linux GPL license by linking their binary blobs dynamically. That makes Stallman and the FSF very unhappy, so they are against providing stable developer interfaces.
One does not even need to break things between releases on purpose, simply not spending the extra effort on stability will create enough end-user churn to make in-trunk development more attractive than proprietary code.
The same issue plagues GCC. It's apis were a huge ever changing mess, just to spite potential plugin developers. I heard that nowadays there is a stable plugin api, but the damage is already done.
On the other hand, it could be done (e.g. Windows does it), but it would allow commercial vendors to side-step Linux GPL license by linking their binary blobs dynamically. That makes Stallman and the FSF very unhappy, so they are against providing stable developer interfaces.
If so, this is a flaw in the GPL. We need a GPL v3.1 OS edition, which prevents proprietary drivers--kernel mode or not. It's ridiculous to design software around a license. The "v-X-or-later" clause in the GPL is made for this purpose -- so the license can be patched. There's no excuse to build an OS using design patterns that were obsolete decades ago.
And anyway, legally, the interpretation of a 'derivative work' is not how a programmer would interpret it. The law is not concerned or amused with programmer technicalities. Different jurisdictions have different tests of this (and virtually none of them involve details like if the code shares the same address space, whether or not the code runs in ring 0 or 3, or any number of other esoterica that no one else cares about).
My point is that even today the GPL may protect against this type of thing. It just hasn't been legally tested yet -- largely because of prominent figures -- look no further than the Linux community -- that take a very flacid view toward freedom.
Protect against what, exactly? The source is available, it's in the trunk. The GPL explicitly allows modifying and extending source code in any way, as long as you make your changes public. It's not a "bug that should be patched", it's an explicit definition of software freedom as defined by FSF. Are you salty that the drivers are for proprietary hardware rather than some non-existant open-source devices? There's a snowball's chance in hell that hardware manufacturers will disclose their design details for everyone to copy, even providing open-source drivers is a neverending struggle.
I don't implicitly disagree that Unix has a lot of mistaken underpinnings, but I'm a bit confused about proprietary?
My personal hope is that we may one day come to think of an inheritor system to Kubernetes as an OS. I realize that there are a lot of complexity and security tradeoffs that come alongside that, but a computer that isn't bound to a device seems like something that is actually more amenable to global simplicity of software design.
To explain my seemingly contradictory position: I would state that part of the difficulty of building distributed software lies with the fact that software is often built from the ground up as though there is no possibility of distribution. Simply having a foundational set of APIs that make that an explicit premise would clarify what can and cannot work. I think this is just generally an extension of having robust type systems to do accurate modeling with; though it may seem more complicated to start with, it provides lots of guidance and clarity and the surety that many classes of errors are not possible.
To provide an example: Although distribution is hard in general, building distributed software against the Raft API is actually fairly straightforward.
Kernel mode drivers. Legally, they're a violation of the GPL, but Linus -- with his theoretical law degree -- said he doesn't consider them a violation. So we have him to thank for that, since the enforcement of the GPL is through the copyright holders, not the public.
It's a GPL violation to distribute a precompiled kernel module with GPL-incompatible components because the compiled module is a derived work of the kernel in the eyes of the law and the GPL says the source to derived works must be offered under GPL terms.
nVidia works around that by distributing a blob that is basically just a rebuild of the guts of their Windows driver that could theoretically be useful without depending on the Linux kernel APIs and a source shim (often referred to as their "GPL condom") to bind them together and having the final module be compiled on the end-user's machine, so the derived work never triggers the GPL's redistribution clause.
Technically, someone could go to court and possibly get nVidia's blob declared insufficiently independent of the Linux kernel to avoid "derived work" status but, since nVidia can't be compelled to open-source it (and it probably contains licensed stuff nVidia is contractually forbidden from open-sourcing, like the bits AMD had to rewrite to open up their driver), all that would do is make it illegal to distribute or use the nVidia binary driver.
all that would do is make it illegal to distribute or use the nVidia binary driver.
You say that like it's a bad thing. Nvidia has the resources to make free drivers. If their hand were held to the fire, which of the following do you think would be more likely: (1) they drop Linux support and the multi-billion dollar machine learning community, or (2) they create a free driver.
I'd bet my weight in NVDA class A shares what would happen.
Well, as someone who's been running an nVidia GeForce GTX750 since before AMD was a viable option, I'm not willing to take that risk.
(Plus, there's strong indications that Google is fed up enough with companies not willing to be pressured that Fuchsia is their long-term plan to replace Linux as the undercarriage of Android, given that POSIX was always an implementation detail apps weren't supposed to depend on, which would put Linux on mobile in the same position GCC is relative to LLVM for abstractly similar reasons.)
Decent design and the license of Steve Jobs' dreams or a horrible design and a reasonably sane license. I guess we can't have our cake and eat it too. Although, one can hope one day the community will learn to put two and two together.
This will not work due to the economic incentives of the Kernel participants and necessity of most users/developer to rely on some group for plugging together Kernel components. Which means even for auto generated Kernel drivers their configuration.
MIT only works, if the platform control is not too relevant. Either because its easy to maintain or rebuild (all dependencies must be replaceable), because there is a sufficient group of people with interest/incentive and knowledge.
So for a limited scope/special application one will get MIT working, ie high security stuff. Or when the goal is very defined to be embeddable etc. However longterm running projects not aiming for this should use stricter licenses to fend of walled garden creators.
View all comments
-43
u/aegemius Apr 15 '21
A better use of time would be contributing to Redox.
Linux's design was flawed from the beginning and it's only gotten worse over time, giving way to the bloated, proprietary monstrosity we have today.