sysvinit (or any init) does not need to have a lot of features, so long as you can build more complex features and functionality on top. The very essence of modularity and substitutability. The priority is to be minimal, reliable and bug free. Just look at how many other systems run more advanced stuff on top of sysvinit. It doesn't have to be there in PID1 or provided by the same software package. sysvinit had a very clearly-defined role and within that constrained scope, it provided a working robust solution that worked for multiple decades. The design of sysvinit can be described in a couple of paragraphs of text; you'd need a book to describe systemd, and I doubt even the authors could fully describe it themselves. Overcomplexity and poor design has a cost, and systemd is already an unmaintainable mess.
The very fact that it had a small interface (signals, initctl, inittab) meant that it could very easily be replaced by other systems (and this was done multiple times). The fact that it was easily built upon meant that there were multiple systems built on top of it. It wasn't perfect, and it didn't have every feature everyone wanted. But the point is that it didn't have to while it could be used as a building block by others. systemd is at one extreme (large, complex, tightly-coupled) while s6 is at the other (tiny, simple, loosely-coupled); sysvinit is toward the s6 side of the spectrum; were I writing it from scratch, I'd lean more towards s6 and strip out the more complex bits into separate parts; PID1 doesn't need to deal with inittab for example, nor with runlevels or shutdown.
The core C code of sysvinit was feature-complete, reviewed, debugged and tested years and years ago. Its original design goals were satisfied, and the project is "done". Software does not need continual churn to mark it as "maintained". The same applies to startpar/insserv and other ancillary bits. If you found a bug in sysvinit, I'd review and test it, and push a commit for it. I no longer maintain the Debian packaging, but I still have upstream commit rights should I need them.
Compare this with systemd. It doesn't have the same clearly-defined scope; it's not possible to say when it will be complete as a result. Software can be complete and finished.
When I was a Biology undergraduate in the late '90s I got several haranguing lectures by various researchers about GMOs and how awful it was that people were against them, how safe they were and how they were the experts and knew they were fine. I later checked, and they were funded by Monsanto, Novartis and other big agribusinesses. Being funded to do fundamental research by big companies can introduce bias, and in some cases it's quite unsubtle.
The big problem I have with claiming something is "safe" is that it's often in a very narrowly-defined and short-term scope. In the case of GMOs, that's often limited to "safe for human consumption" ("because we fed it to rodents for a few years with no ill effects" or similar). What about the effects upon people and the environment in the long term (many decades)? Contamination and change to wild populations of the same organism, for example.
The problem I have with it is that it's easy to prove something specific is safe while ignoring the bigger picture. We were assured that glyphosate was safe for bee populations. It had been tested in the lab and we knew its toxicity precisely. But it later turned out that at sublethal doses it screwed up their navigation leaving them unable to make it back to their hives. That hadn't been investigated, and that was an important part of the bigger picture. It wasn't toxic but it was still deadly.
When such important glaring omissions are made, which could potentially destroy our agricultural productivity, leading to starvation and civilisational collapse at the extreme, it also makes you wonder what important but uninvestigated aspects there are in all areas of science. GMOs might be "obviously safe" to the intelligentsia of the present, but who knows if it will be quite so obvious in 30 years time if some fatal flaw is discovered. While it's clearly profitable today, and it might well be safe, it doesn't hurt to have a sensible amount of caution when our entire population is critically dependent upon this stuff for our continued survival.
In all seriousness, while Unicode is intended to be universal, I don't think that bullshit emojis have a place in it. We have markup in addition to characters, not to mention SVG and other formats which can better represent them. They don't have to be in the Unicode standard.
Regarding the "performance penalty", it's generally going to be positive and improve performance. We are talking lz4 here, not gzip/bzip2/xz. It's fast, trading a lower compression ratio for performance. It can compress and decompress blocks in parallel. It can do this much faster than it can read data from disk, so you'll actually improve read and write speeds. And this is on top of ZFS being able to pull data of multiple spindles as the data is distributed over multiple zvols, with redundant copies of data, etc. It's likely not the penalty you think it is. It does multiple rounds of lightweight lz4 compression to reduce the entropy, and it bails out early if poorly compressible.
% zfs get refcompressratio red/home/rleigh system/usr/ports system/usr/src system/var/log system/var/mail
NAME PROPERTY VALUE SOURCE
red/home/rleigh refcompressratio 1.33x -
system/usr/ports refcompressratio 1.60x -
system/usr/src refcompressratio 2.16x -
system/var/log refcompressratio 6.54x -
system/var/mail refcompressratio 4.99x -
With compression like this, you no longer need to bother compressing rotated logs. And while the homedir compression is small in comparison, it's gained me an extra 100GiB just for this single dataset, which is not to be sneezed at.
365 Days of drinking Lo-Cal beer. = 1 Lite-year