I wouldn’t kneecap a OS project I wish to be adopted by licensing it GPL. Look at glibc which basically can’t practically support static linking.
You make any of your OS standard libraries GPL and they need to suck to use and can’t statically link your code without being forced to also be licensed GPL.
WRT kneecapping, history has shown that companies will bleed the commons dry and they need to be legally strong-armed into contributing back to the free software projects they make their fortunes off of.
Virality might suit the ego, but it doesn't make for a healthy project when its primary users are parasitic.
> history has shown that companies will bleed the commons dry and they need to be legally strong-armed into contributing back to the free software projects they make their fortunes off of.
Software is not a scarce good. Let companies use free software without contributing back as much as they wish; it doesn't affect others in the least. There is no bleeding of the commons here, because even if companies take as much as they can without giving back, it doesn't reduce the resources available for others.
Software is rarely finished, and development has real costs.
When that development gets silo'ed away in proprietary systems, that is potential development lost upstream. If that happens enough, upstream becomes starved and anemic, and with forks only living on in silos.
Apple, for example, has made trillions of dollars off of FreeBSD. To this day, FreeBSD still does not have a modern WiFi or Bluetooth stack.
Meanwhile, AMD, Intel, Microsoft, and even Apple, etc have full-time engineering roles and teams dedicated to upstreaming their improvements to Linux. And there are paid engineers at these companies that ensure WiFi and Bluetooth work on Linux.
Companies do worse than bleeding of the commons: lock down weak-licensed software and lock in users and devices. It totally reduces users ability to benefit from FOSS and reduces funding for developers.
Rust's technical choices seem to make releasing GPL software with it cumbersome and unattractive. Also the implied goal of a lot of Rust projects is to replace GPL'ed programs with permissive ones.
Which technical choices are thinking of here? My best guess is the crates ecosystem and the oft discussed ‘dependency hell’ that pervasive package manager usage seems to engender. Is there something else I’m missing contributing to the (maybe purposeful) reluctance to push GPL code?
The most important effort is seL4[0], the fastest OS kernel out there which also happens to be the most formally verified.
LionsOS[1] is its static scenario building framework, with some dynamic scenario support.
Genode[2] is an independent OS construction kit that can also use the seL4 kernel. Their general purpose OS, Sculpt, just had a very interesting multi-kernel release[3].
The systems group at ETHZürich is building Kirsch[4], an effort with seL4 and CHERI.
Managarm[5] is also building something of interesting architecture with some Linux software compatibility.
Note: IPC performance isn't the only factor in overall OS performance. Especially for a "traditional microkernel", where programs are split up into separate processes liberally, performance degrades due to the sheer number of cross-boundary interactions. A whole system is performant if the design of the whole system, not just the design of the kernel, is aligned with performance. This is not to put down seL4; on the other hand, it continues the trend of L4 microkernels demonstrating the viability of stricter designs. But keep in mind that more time and effort is necessary to implement larger systems well.
Do not miss the latest seL4 summit's state of seL4 talk by Gernot Heiser[0], which besides providing an update on the work done this year, goes into performance[1].
This is real world throughput and latency seL4 is crushing Linux on, not some synthetic IPC benchmark.
I think I've got the gist now. Although I think Gernot Heiser doesn't consider the following to be ideal, I think it's fair to say that true claims have undergone some sensationalization. I don't think people generally lie when they say their product has achieved some impressive performance, but those results exist in the context they are taken under. In the embedded roles LionsOS is being targeted for, I have no doubt that they represent a real improvement over existing Linux systems, and probably any Linux system short of a magical one. However, in a general-purpose OS (which is what I focus on), which is the same as saying that many distinct user bases are simultaneously involved, the kernel is far from being the only load-bearing component. Also note that the functionality compared is not 1:1, nor is Linux the final contender of monolithic systems.
Something I want to explore, and which has some viability in the LionsOS model too, is that a general-purpose system may still liberally cut out unused functionality if highly modular and easily configurable. Like Legos.
In conclusion, props to the people at Trustworthy Systems as always, but it's safe to say that the OS field is still far from settled. My best compliment to seL4 is that it has raised the bar and simultaneously paved the way for future generations of advances. It's a seminal work that was desperately needed.
I will check those out tomorrow, but in the meantime: I don't mean to say that a microkernel-based system is necessarily worse on performance. However, I think a highly optimized monolithic system will probably always be somewhat faster than a highly optimized microkernel-based system. And note that the seL4 system is probably less mature, and that I have many criticisms of Linux in being a supposedly highly optimized system. I'm all for microkernels. I'm planning to write one myself. But there are some aspects that microkernel-based systems have to work harder on.
I have ideas as well, and wrote about some of them (including some partial specifications), although I do not have a name for my own, so due to this, there is not a repository or anything like that yet. Note that, there are multiple parts, and different projects will have a different set of these parts: hardware, kernel, user/application programs; my ideas involve all three (there may be other parts, and different ways to divide them, too).
What other exciting projects like these exist?