Lennart Poettering goes to Microsoft

I must have missed that. Any pointers?
I'd have to go back and search but kernel mailing lists or maybe OpenZFS when it was "ZFS on Linux". Something about a kernel function the ZFS module was using, but it was decided the license for OpenZFS was incompatible with GPL and the Linux kernel moved scope of the function so it was no longer available to OpenZFS module. Bunch of back and forth on the mailing lists one of the Linux guys (maybe a Greg last name started with a K I think?) effectively said "screw the ZFS team ZFS will never be a native Linux filesystem". OpenZFS found a way to work around it by using different available functions.
A lot of the attitude struck me as NIH.

Here's a quick link to an interview with Torvalds about it. Should give a starting point to looking at LKML, it got rather heated.
 
Yeah, that one - right. Another case of "Better be silent and thought stupid then speak up and remove any doubt".
 
  • Like
Reactions: mer
I remember, in the 90's, I think, a joke about Microsoft Linux. At the time it was a joke, with things like MS having a daemon krapd, and the like. Then MS started becoming more Linux involved and one does wonder if this is more of embrace, extend, extinguish. (To me, that's what Slack is doing. For the first year or two, it was easy to use it with irssi, now, I don't know if it's possible. I gave up and switched to weechat which works with a python plugin. https://github.com/wee-slack/wee-slack, if anyone's interested, though even that's become harder to use.)
Another rather mean-spirited term I've been hearing around is calling Linux Poettering-ix, though I can certainly understand the logic. Systemd is quite insidious. I've been at a BSD shop for years now, so was less affected, but we did have some CentOS servers for things that wouldn't run on FreeBSD, but for our limited usage, it didn't greatly affect us.
 
Yeah, that one - right. Another case of "Better be silent and thought stupid then speak up and remove any doubt".
I think Linus being stupid is the most charitable take on what he did. I believe the knew exactly what ZFS was and is, and was trying to use his considerable fame and popularity to quash interest in it. This is Linus' political side, which is not often called out for what it is.
 
but it was decided the license for OpenZFS was incompatible with GPL
Well CDDL isn't compatible with GPL in the same way FreeBSD can't have GPL code in their base, they're incompatible licenses.
 
Actually nowadays Microsoft is one of the biggest contributors to the Linux kernel, it's in the TOP 5.

Microsoft also ported own software to Linux because probably they got fed up with Windows, e.g. HyperV has been ported totally over to Linux. And Microsoft Teams is available natively for Linux, as well as Microsoft Edge.

Reg. ZFS: the CDDL license is incompatible to GPLv2 on purpose.

Also there are two pillars the development is being based on, namely:

1. it's got a stable application binary interface. You can still run binaries compiled mid of the 90s on modern Linux kernels.
2. it has no binary kernel interface, nor a stable kernel interface.

Linux wants all drivers at least being under GPL, and prefers them to be part of the kernel. Period. This is probably one of the most important decisions why it never took off on the desktop, that lack of interface.

When running a Linux module, then exported interfaces are separated between vanilla interfaces (EXPORT_SYMBOL) or GPL tagged interfaces (EXPORT_SYMBOL_GPL). When trying to load a BSD licensed module for example, which registers as BSD module, EXPORT_SYMBOL_GPL will be not available for that module during runtime.

In 2019 there was a commit which tagged previously only EXPORT_SYMBOL interface API calls as EXPORT_SYMBOL_GPL - and that broke ZFS. It was _kernel_fpu_ which was GPL tagged. Having no access to it prevented ZFS from it only prevents them from using the kernel's own state-management facilities to preserve and restore state. It affected back then only a few ZFS users, and the solution was to re-implement that stuff in the ZFS module.

The stance of the Linux developers is: if you want to run in kernel space you need to keep up with kernel development. Or at least commit the code into the main kernel with GPLv2, and we'll maintain it then, keeping it running.

IMHO they just retagged this symbol, because they were on a tagging spree. That it affected ZFS made that tagging then quite well known and controversial.

Going back to Lennart Poettering: Poettering is a BTRFS lover. I mean he wants to do stuff like this: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html, using systemd and Btrfs. What could possibly go wrong... it's safe to say that he's a full blown Btrfs lovah boy.

Which is funny, becuse nobody nowadays really still believes that aside RAID0/1 Btrfs ever will become something usable after the CoreOS desaster. As a matter of fact there's a COW file system written from scratch for Linux in development called Bcachefs exactly because of its developer Kent Overstreet has given up hope on that.
 
This kind of news is no longer surprising. Linux fans may have a problem, in that a Microsoft employee now develops and maintains an integral part of the handful of main Linux distributions. But they already had a problem, with "big tech" (Microsoft included), funding and steering Linux development anyway.

In my view that horse already bolted.
 
In my view that horse already bolted.
I feel it is important to analyse what allowed this (in terms of mindset of the Linux community) and ensure it can't happen to FreeBSD.

There are too many people that revere large commercial companies. Perhaps they incorrectly feel that "little guys" can't possibly achieve great things together.
 
There are too many people that revere large commercial companies. Perhaps they incorrectly feel that "little guys" can't possibly achieve great things together.
The old "buy IBM Buy DEC" you'll never go wrong syndrome. Funny thing is a lot of the large companies (IBM, DEC, HP) started out small, almost "someone's garage".

Absolutely agree with the "analyze" aspect.
 
This kind of news is no longer surprising. Linux fans may have a problem, in that a Microsoft employee now develops and maintains an integral part of the handful of main Linux distributions. But they already had a problem, with "big tech" (Microsoft included), funding and steering Linux development anyway.

In my view that horse already bolted.
The thing is: nobody forced Debian and many other Linux distributions to move over to systemd; they actively decided to do so. Only a few, like Slackware or Gentoo refused to do so. Devuan came into existance as Debian fork due to Debian embracing systemd.
 
to be honest, I do not like systemd, I do not like Lennart but then I do not care about him. I also do not like Linus Torvalds and Theo de Raadt, I think those geniuses lack some "social intelligence", however, I like their work.

That said, I really like systemds best idea: the declarative init system with unit files, I would love to have such a thing for *BSD. That is also my main reason why I prefer pf over ipfw - I can lint it, and it is digestest in an atomic way (more or less). The bad thing is: the implementation of systemd is especially bad, does not work as expected, is overengineered and lets not forget all the services around it that are installed no matter if you want/need them. In my 20 years of infrastructure administration I think systemd is the worst piece of crap we have got ... I think it is especially hard for me because I really like the unix philosophy of one great tool for one task. Whenever I had to deal with Windows, Lotus Domino, Blackberry Enterprise Server, SAP and all those "business software" I knew before I would not like it, however, I liked Linux/GNU until systemd came along and completely broke with that philosophy.
 
The thing is: nobody forced Debian and many other Linux distributions to move over to systemd; they actively decided to do so. Only a few, like Slackware or Gentoo refused to do so. Devuan came into existance as Debian fork due to Debian embracing systemd.
Artix also have an actual great work maintaining a bunch of different inits. That said, it is (somehow) easily doable to just no using it, at this point is quite hard because some distributions (and some software maintainers as well) decided that was easy to just do what the "Mr. Everyone" was doing, embracing systemd.
 
RH is sort of the Windows of the Linux world. They decided on systemd, and others fell in line, as it was apparently easier to do so. I've heard it said (by BSD folks), that Poettering is good at C but knows nothing about system administration and comments of his that losing logs wasn't a big deal sort of enforce that. RH's latest is that their RHEL9 won't run on older x86_64 machines, only on x86_64-v2 machines. As I've kept an older (~2007) machine to keep my hand in at RH and clones, this is a nuisance for me, though not necessarily a terrible thing.
TLDR, RH is the Windows of Linux and their decision to back Poettering's ideas meant that many other distributions did the same. I don't like a lot of it, but whether I'm right or just an old guy yelling at clouds, is something I'd rather not confirm.
 
For me the main problem with systemd is not the program itself, but that certain other basic and important building blocks for a Linux system have been usurped by that project.

So stuff like udev, elogind and such which in the past were maintained separately, are now part of systemd.
 
So stuff like udev, elogind
and hald. Things like these three shouldn't even exist in the first place. Or at least shouldn't be underpinnings. If a company needs some of their more niche features, they should maintain them / integrate them themselves. If that is too difficult, they should take that as a hint and avoid them like the rest of us.

and PAM to be honest. These big abstraction things are messy. It is easier to write auth for one or two systems (which is all you will need anyway), than to use an abstraction that can pull into 12 (mostly obsolete) systems that you will never want in practice.
 
  • Like
Reactions: mer
For me the main problem with systemd is not the program itself, but that certain other basic and important building blocks for a Linux system have been usurped by that project.

So stuff like udev, elogind and such which in the past were maintained separately, are now part of systemd.
That said, I really like systemds best idea: the declarative init system with unit files,

For me these two quotes are the crux of my problem with systemd. It's not just an init system. The biggest problem with an init system is the dependencies. What needs to wait on what, who needs to start first, who can start at any time. Provides and Depends. Determine that correctly and it just works. Muck that up and the system boots inconsistently.
From an init point of view, I don't think systemd unit files are any better or any worse than rc run scripts.
Thing I hate the most about systemd is binary logging. If you have a failure to boot you get some obscure message on the console then you need to know some magic decoder ring to figure out "Oh it's trying to mount a flash drive during boot that is not connected".
 
Back
Top