function pickPizza {
    return { crust -> chewy, toppings -> [ 'pepperoni', 'extra cheese']};
}

Hey, ALL 60's cars were deathtraps! The OP never said anything about it had to be safe. Not sure why you hate on the '66 though, its a very classic model. The disc brakes were pretty much crap, but you can easily fix that (and by now if you own such a car it has long since been dealt with). The drive train in the performance model is pretty much standard Ford. The Windsor HiPO with the 4 barrel is a pretty nice engine.

Remember to get the high performance model, not the crappy one!

Oh, you didn't mean "drop in a new tranny when you said 'hack'??" Damned lazy kids.

Its just introducing another dependency. While I agree that shell scripts aren't the most elegant thing in existence and you could certainly write better ones in say Perl that would just mean that everyone would have to install an interpreter, just to boot their machine, and I think that wouldn't go over too well. Shells are unavoidable, so that dependency is pretty trivial.

Beyond that you can certainly write some perfectly nice shell scripts, and it should be possible to hide whatever ugliness there is with some more extensive libraries. Shell scripts allow for includes of packages of routines, and RedHat did a lot of work in that direction way back when. I guess they just had better things to do and it was never pushed to its limits. As I said before there are also /etc/sysinit scripts which are intended to contain ALL the user-settable configuration parameters for system services. Again, this hasn't been pushed hard, probably because its just not glamorous work.

Frankly I think if someone put their mind to it they could clean up the existing sysVinit process, init itself, build some libraries and establish some better conventions and you'd have 75% of the benefits of systemd without all the ruckus. The other 25% most people can probably live without and its not at all clear to me it belongs in the same project. Much of it could exist as stand-alone tools/libraries and some better conventions covering how to use cgroups and etc. That would IMHO have been a better approach.

I'm sorry, but just saying "X is 'primitive'" isn't actually very useful. There is nothing primitive about scripts.

Also this isn't about SysVinit, this is about systemd. Picking at the one isn't an argument for the other. In fact SysVinit is pretty sophisticated in its own way, but its fine if we make it better or replace it with something BETTER. Again, just pointing out the problems with it isn't automatically enough to make systemd the correct alternative. I've pointed out negatives about the systemd approach, you need to address those.

There are two problems with this statement. First of all properly written init scripts ala RedHat put all their config in /etc/sysconfig, not mixed into any script. This is a perfectly easy practice that has been the state of the art for at least 10 years. Secondly blanket statements decreeing what is and isn't 'indefensible' are ridiculous. You need to make concrete arguments, I and many others are FAR past the point where any sort of decrees like this mean squat to us. There are many cases where basic invariant configuration elements are perfectly reasonably placed within a script. These are things that are not going to be changed in your installation but should be parameterized as good PROGRAMMING practice. Don't confuse those with configuration options that the system's user is going to want to change, they are very different things.

Horse Petunias. Computing hasn't fundamentally changed, and the same use cases that existed back in the mid 1980's when init systems in use today were birthed exist today. Believe me, I was there, and I know. A machine room today is solving the same problems that they were back then. Some of the technology is different and there are obviously some new things, but my 1980's Sun Unix machines ran pretty much like my Linux servers do today. If you want to tell me that a mobile phone is quite different from a mini-computer, well yes. However nobody is asserting that a mobile phone should be running the same init system as a web server, except the people making everything depend on systemd....

Obviously we will have to agree to disagree. As a highly experienced system architect I'll take my instincts over those of people that seem to be going up the wrong path every time. IPC isn't a big deal, and if your init system is doing enough work that 'killing performance' is even a remote possibility then something is VERY wrong. At the most basic level there are a whole series of different problems here, starting and stopping services at system initialization/termination, managing hotplugging, general event management, and "compatibility layer". These need not in any sense be lumped together into one solution. Respectfully, you are wrong on this. I've been doing my system engineering trade for a LONG LONG time since an early age and when I know I'm right about something, I'm just right. Its not that common, but this is one of those cases, so you're going to have to do detailed exposition of every single technical point if you expect guys like me to be AT ALL convinced.

Yeah, I'm actually not pissed off at the people writing systemd. I'm pissed off at the people that maintain RHEL because they showed incredibly poor judgement, and making them pay for it is going to be quite a lot of work that should never have needed to be done.

I don't know what 'SCO' has to do with it. Tandem wasn't SCO, they were supplying their own NonStop solution into the financial industry, which drove DEC's VAX cluster solutions clean out of that space. They were acquired by HP in 1997. I know because I was and still am friends with a number of the DEC engineers who worked in their clustering group in the late 80's and early 90's.

Linux had nothing in the way of traction in the workstation market in the 90's, it was not a player at all in any commercial sense. There was a very limited use of Linux on Multias by DEC as a way to make a cheap XTerm out of a failed workstation product, that was about it. Workstations at that time were heavily dominated by SGI with IBM, DEC, SUN, and some smaller 3rd party Alpha and MIPS system resellers. Many of those were NT 4.0 based boxes. I know people who used these things, sometimes 1000's of them, none of them ran Linux on them, it was unheard of. They were almost entirely used to run specific commercial applications (CAD, 3D software like Lightwave 3D, etc) which were rarely, if ever, ported to Linux (for instance there were some custom ports of Adobe products, which certainly shops had access to around this time, but they were never made widely available even to Adobe's bigger clients).

BSDs were indeed quite popular in the hosting space in the early-mid 90's. Linux eventually eclipsed BSD in most shops by around '97, but particularly in the 93-94 time frame there were significant issues with using Linux in Line-of-business server applications. I should know, I was a significant supplier to and engineer of commercial web solutions, local ISPs, etc during this time. I set up a LOT of these people's IP networks, server rooms, built a lot of their first web applications, etc. This goes all the way back to things like the first discussion boards. In fact I may well have created THE first http based discussion board, hard coded handlers compiled directly into the CERN httpd that used BDB index files to implement multi-level threaded boards. It was all run under IRIX on big quad-core SGI servers. We had 128 megs of RAM in or main server that handled the NGA and some other organizations. I did buy a pile of Multias and got early RedHat working on them, mainly because BSD wasn't available for the Alpha processor they had in them. In any case, the point is BSD was at least as much used in the early server rooms as Linux was.

One of the real issues with Linux on a workstation in those days was A) there were no good graphics cards for PCs that could compete with the stuff on the workstations (and no drivers so you could run Linux on the DEC/SGI hardware) and CDE wasn't available on Linux. CDE was no prize but TWM was far more limited back then and it was mostly the only alternative. These days you can make a realistic Linux Workstation, but back then all the high performance hardware was proprietary and even the fastest 486s weren't in the same league with workstation processors, so I am not even really sure what you would have called a "Linux Workstation" back then. Believe me, had it been possible for there to be one I'd have been running it. My company had VERY good access to advanced hardware and software at that time and we played around with and used Linux a lot, but for real workstations it was SGIs or some of the Alpha based boxes, at least until around '98 when some of the Pentium II Xeon's started to show up with enough oomph to do the job.

There's NOTHING wrong with script files. As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'. A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.

I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.

And no, I'm not really being given a choice when the only option I have is something like Arch Linux, which no offense to its maintainers, is not something I'm going to run my bank on top of. Neither am I going to suddenly convert said operation to using systemd willingly. I've already had to deal with a lot of fallout from this stupid idea. I didn't have any problems before that needed this solution frankly and the changes ARE disruptive while we've noted zero practical benefit.

It wasn't Linux that killed DEC, I was there and saw it. By 1994 DEC was toast and that was purely because you could spend $5k on an x86 box that could do as much as your $50k DEC Alpha 4000 series. It was mostly stuff like Tandem and commercial unix running on x86 boxes that ate into their business, not Linux, which was NOTHING at the time. Recall the products DEC rolled out to try to fight it, there was Alpha itself, then there was the Multia, and there were several other workstation products, none of which could compete with NT on a Compaq.

Linux was a little sprout hiding in a bush watching the giants kill each other back then. It sure had nothing to do with the workstation market, though around 94 it started to become modestly popular as a quick cheap 'put it on some old 386s' server for mail/bind/etc and some casual web server stuff. FreeBSD was actually both a better choice and more popular in all those roles at the time. The only reason Linux thrived was the community was open and easy to play with, so it grew large quickly. The BSDs were a lot more elitist, you weren't WORTHY to commit code there. Anyway, I don't think systemd is going to sit well with the community, ever.

You have the factoring wrong on this sort of system design. You shouldn't have a monolithic controller implementing all these features. Instead you should have individual scripts that CAN do it any way they want, and then a large library of tools that properly implement all the things that people ACTUALLY want to do in a proper fashion. This allows incremental adoption, avoids dependency lock-in, and preserves flexibility and modularity. Instead of replacing init and trying to incorporate every possible feature in systemd and exposing them with configuration options what systemd SHOULD be is a set of functions that daemons can call and some wrappers that will let you compensate for or enhance whatever ill-behaving services already exist which can't simply be fixed up with changes to their init scripts.

As for security, that's an independent cross-cutting concern which is already handled by other tools. If there's a need for some command-line tools to expose some kernel functionality, or some libraries to do so, then that's one thing, but why is this grafted into the same tool that performs system startup? That's not good factoring.

We could have the same discussion WRT container support and other elements of systemd, most of which belong in completely seperate tools. If there needs to be additional framework around those different tools so they can do some new/better things then that should be done in the wider community so that we can have standards, not dumped on everyone as a fait acompli.

this is precisely the point. There's no need for a single giant monolithic product that tries to do every damned thing.

This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.

I have all sorts of high reliability services running on quite a few different servers, and I have plenty of them that will restart themselves, monitor their own crashrate and terminate completely if they crash N times in M minutes, etc. This is not rocket science and doesn't require to be built into PID 1 or something like that.

Frankly I think its a bad idea to create dependency chains onto huge complicated subsystems that often aren't appropriate, aren't needed, or are simply overkill.

Yeah, that could be better for some people. The $30 part is nice if you aren't going to use a HUGE amount of data and just want 4G. T-Mobile's network only has patchy 4G around here though, so I've not tried it. Truthfully all wireless internet kinda sucks in one way or another. At least some of the resellers are FAIRLY honest about what you get, like Straight Talk, and the price is pretty reasonable considering its an unlimited everything plan. At least you never need to be watching your usage.

Yeah, this is basically the best there is. Its mostly 3G speeds, but not always, and you will at least get what you get, all the time, at the best price there is. Frankly anyone expecting 4G speeds, unlimited, for less than huge money is just SOL.

OK, in 140 years when you've made actual progress towards general-purpose AI and convinced me that one CAN EVEN BE WRITTEN by humans well....