Linux md maintainer, Shaohua Li, has died
spinics.net
spinics.net
A very brief bio: https://raid.wiki.kernel.org/index.php/User:Shaohua_Li
Patches to Linux kernel while at Facebook: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Additionally there were 47 commits with his involvement in the pre-git era (starting Sep 2003):
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history...
Sad to see a prolific longtime contributor pass away.
I'm pretty sure it supports RAID level 1 as well:
https://raid.wiki.kernel.org/index.php/RAID_setup#RAID-1
Or am I misunderstanding something?
https://web.archive.org/web/20180211041128/www.linuxdevcente...
Because it's a huge project with so many eyes on it, Linux's transition to the next generation of developers will probably be The textbook case on the viability of large human endeavours in general.
Mr. Li has had a good impact in this world, and his work will live on for a long time.
> Because it's a huge project with so many eyes on it, Linux's transition to the next generation of developers will probably be The textbook case on the viability of large human endeavours in general.
True. I agree with this statement.
The sub-systems will fall into obsolescence otherwise...
I'm seeing 2466 unique maintainers (curl -s 'https://raw.githubusercontent.com/torvalds/linux/master/MAIN... | grep -P "M:\t" | uniq | wc -l), and only 10 of them with @oracle.com emails. They're the 11th biggest contributor by company.
edit: and this is a really contrived subject and example, because honestly, I can't think of how Oracle would take control of Linux anyway.
As new technologies arise, it's almost always easier to write something new, from scratch, than to muck about in legacy code (that you probably didn't even write in the first place). md is great and works exceptionally well, but it's only a matter of time before a newer, better, more well-supported software RAID is born and md goes the way of init and Xorg
> simplified
I like systemd, but it never simplified anything, especially with the huge amount of dependencies. At most, it made things relatively uniform across Linux distros, but in the end of the day each distro has to maintain their own .service files anyway.
Lightweight and embedded Linux distros won't use systemd by default in the foreseeable future because it's anything but simple.
That's an odd way of looking at things. Ultimately it's software accomplishing task X. How are things simpler if instead of depending on other projects they'd have implemented those things on their own? Then you'd be carrying duplicate work.
> [...]but in the end of the day each distro has to maintain their own .service files anyway.
Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does.
And for that "simplicity" all you need is a daemon that depends on dbus, glibc and cgroups (IIRC), just to name a few - which makes it non-portable for anything that isn't Linux and non-usable for anything that doesn't want to depend on, say, glibc.
And if they got their way, dbus would have been shoved into the kernel (kdbus, bus1, or whatever they called it) - adding a bloated mess of an IPC mechanism into the kernel.
Simplicity. Right.
Imagine how much more complex systemd would be for even common things like "start this daemon and make sure neither it or any of its sub-processes collectively use more than 1GB of memory" would be if it had to run on z/OS, AIX, Solaris, OpenBSD, HP/UX, Windows, Mac OS X etc.
And let's be clear, systemd is perfectly usable for things that don't want to depend on glibc, for example it works just fine for starting Go programs, or your random C program you've linked to uClibc. What you can't do is not have a glibc on your system at all. Given how tiny glibc is in terms of modern hardware resources, if you can't have it on your system you probably weren't the target audience for systemd in the first place.
The Debian people responsible for van Smoorenburg rc copied OpenRC and Mewburn rc, and shifted most of the mechanism of rc scripts out of being part of every individual rc script and into a common interpreter, /lib/init/init-d-script .
The rc script for opendnssec-signer (to pick just one example) in 2016 shrank to roughly one third of its prior size with this change. Mewburn rc scripts have been reaping this same benefit since 2000.
* https://sources.debian.org/src/opendnssec/1:1.4.6-6/debian/o...
* https://sources.debian.org/src/opendnssec/1:2.1.3-0.2/debian...
So, less simple in terms of number of moving parts, but simpler in terms of how much you have to know to deal with it. As in all things, it's a tradeoff.
Everyone was definitely not OK with sysV init. That was the problem. The distros extended it in various incompatible and not very good ways. Regular sysV init was OK for what it did but hardly anyone used it that way. Systemd was not a rewrite of sysV; it was its own thing.
The question of how to do stuff in a Unix like OS is still very much open, making systemd did not magically make the question go away.
* https://news.ycombinator.com/item?id=18788974
The motivation for writing systemd, and what it was initially intended to replace, was upstart, the software that preceded systemd on both Ubuntu and Fedora. The idea that only van Smoorenburg init+rc and systemd existed is a common fallacy.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235)
That is literally the point of software.
Most of the years I was a heavy user of md it seemed like Neil Brown was the only person working on it, so for every weird use case or if documentation was lacking I'd shoot him an email and he'd get back. I can only imagine how many other people were doing the same!
R.I.P.