BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.
What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.
Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting to take effect in IT. Unix-like operating systems are supposed to be non-complex. My example above, of OpenBSD, is true. Maintaining OpenBSD systems is trivial compared to similar Linux systems, and I maintain both. Sadly, I admin a series of CentOS PBX servers that are an absolute pain. A friend runs his on FreeBSD and has less than half the pain points I do. And we're running the same PBX software.
I believe in lowest common denominator everytime. Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs. You will not see this in OpenBSD, for example. The BSD folk reverse engineer the drivers and write their own free drivers -- and they are usually far and away better afterwards.
Take the wireless chipset drivers for Ralink. The BSD guys took a 30,000 line driver and rewrote the entire thing in less than 1/3 of the code. That's just the whole attitude between Linux and BSD. Linux is a series of cobbled-together hacks on top of an ever-growing, ever-complex kernel (that really needs legacy crap removed). BSD, on the other hand, is engineered as a single OS with a small collection of pruned base programs. Big difference. If you've ever used BSD, you will know the joy of /etc/rc.conf vs the nightmare of Linux config files that live in myriad locations depending on the distro.
I can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-init script.
It's curious that he says "Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs."
That's not exactly true now, is it? He seems to be implying that there are closed source binaries in the Linux kernel...
You seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system.
Those commands will not help you if you have to find a bug into systemd code to find something like a constant on the maximum size of a core dump and work around it. Then open a bug and hope it does not get ignored for ~3 years. But who needs core dumps anyway, right?
What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a reasonable choice. There will be more bugs in systemd than init and bash (or ash or dash), simply based on age and maturity of the respective projects.
There's complaints to be made about systemd, but I don't find this complaint compelling, at all. I think moving from procedural programs that are sometimes hundreds of lines long to declarative config files that are never more than a couple dozen is an overwhelmingly positive thing.
On Debian they're specifically not bash scripts, they're posix shell scripts and /bin/sh is provided by dash which is much lighter than bash.
I like the declarative nature of service files I'm just not a fan of the hoops it makes us jump through to achieve the same results (see my other comment about changing daemon args)
The bash scripts invoke programs and wrapper programs. It's a bit ridiculous to say that she'll scripting is the only thing that operates startup of services in a system.
It's not like new services and startup programs aren't constantly being introduced - so whilst the old scripts were pretty steady, new ones weren't always foolproof.
I'm not adverse to SysV and rc scripts, but they were never the panacea that some grey-beards make out. Dependency orders and parallelisation are particularly difficult, but it could be argued the scripts give control during the boot process.
I think in practice, it's fairly rate that the scripts were really needed - certainly systemd's more declarative nature for a problem that naturally lends itself to a dependency structure that has a directed acyclic graph seems like it's quite an effective an elegant approach!
Aside from the reasonable daemon-arguments issue you raise in the other comment (I just read this, interesting observation!) I really feel that systemd largely eliminates huge quantities of shell scripting in the startup process!
I've been wondering what scenarios there are that would require scripting. I thought that perhaps a more complex setup might be that a service needs to wait on two or three processes before starting, in which case a child can have multiple parents? Can systemd handle that?
You already answered the question and acted like it wasn't an answer: "Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities," - yeah, those binary blobs (inherently unstable blobs of logic).
There isn't anything "inherently unstable" about them!
The only true competitor to systemd is s6, and you should see the amount of "binary" he has had to develop to get his service manager to run outside of PID 1!
However... it's all a moot point, because that isn't the definition of a "binary blob". In the context of Linux, or "free and open-source software, a binary blob is a closed-source binary-only piece of software without publicly available source code." [1]
Does it really work for others? Because I've yet to see any init system that provides even a small proportion of the functionality of systemd that I actively rely on.
I was in IT security for many years and got out largely because of the sheer attitudes of many of the people I encountered. Some of them were genuinely very nice, very smart people, but these gentlemen were few and far between. Sadly.
I started off as an abuse investigator for a very large East Coast ISP, moved into firewalls, then penetration testing once I knew what I was doing. All along this path, the vast majority of guys I worked with, for, and around (on contracts) were sheer jerks of the highest order. Everyone seemed to be angry, upset, on edge. I can understand this. IT security--especially abuse investigations--necessitates seeing the seedy side of the Internet. Ditto IT security in general. You're not working for or with people who are "creatives". You're working for and with people whose sole job is to minimize threats and vulnerabilities.
The most stressful time was being a firewall engineer. Having to deal--on the fly--with impatient customers wanting a six-spoke VPN "right now!" and them being jerks about it was annoying.
I hated the calls that involved my placing a "tap" on some poor sod whose boss wanted an 8-hour tcpdump on him to see where he went when online. They wanted a gzipped log file placed on the server where they could SSH in and retrieve it.
I hated the double standards where executives were given static IP addresses on their machines and special rules created to allow them carte blanche access to the Internet at large--no filtering. They also avoided the proxy. These special executives were &^%#$@ and everyone knew it.
When you spend your life seeing nothing but evil, you take on a different view of life and the world around you. I saw this happening and I got out in favor of being a sysadmin. I'm much happier, and the IT security roles I do have are much smaller in scope and I know how to handle them quickly and quietly.
What bothers me about this device is the necessity to have a live Google account, which takes in everything I surf in real time. I have serious reservations about this.
