the best of both worlds. I just installed Kubuntu on one of them and

am realizing how much I missed having a native Linux around. KDE is

And I'm really liking this. KDE 5 looks and acts like a desktop.

I just dropped my Linux laptop into the dock (which fits both of my laptops) and it picked up *everything* without requiring any configuration. Multiple monitors, multiple audio devices, multiple network interfaces, it's all there, no fuss, no muss. And it looks fantastic.

I'm tempted to make this my daily driver for a while and see how it does at the workplace. In the meantime it's going to stay in the dock all weekend.

AWK is still your friend.

I used it today. I use it every day. AWK!

I virtually never use awk, but when I do, its value becomes immeasurable.

I'm in systemd hell...

Gah... I wish you luck with that, LS.

systemd, upstart, init....

Personally I'm with the Boycott Systemd folks - it goes against basic Unix philosophy.

Looks like that horse has left the barn.


Things don't seem to be working the way I expect, but maybe my expectations are wrong. I have to read up and test a bit more.

I suppose it's unsurprising that some of systemd's APIs have Haskell bindings... *vomit*

I've been pretty happy with systemd, but it is true that systemd (like upstart, which fortunately is dying, and launchd, which unfortunately is not) is somewhat less "unix-like" than sysvinit.

The thing about systemd is that it *has* an API. And to install a service you only have to create a single unit file, and then make an API call (or just run the equivalent command from a shell script) to activate it. sysvinit is more understandable from a traditional unix perspective, but unfortunately it's a mess.

Of course, I never really liked init scripts to begin with. /etc/rc was better. (Yes I know slackware and BSD still use /etc/rc and I don't care.)

Binary logs? Blech.

Contrary to historical indications, the 'd' in systemd does not stand for daemon. It stands for disease.

Well, as I understand things (with my horribly Windows-esque background), sysvinit has this terrible problem where the scripts cannot be started concurrently.
So, we have two attempts, so far, to create something that can sanely start these services, yet still feel 'unixy-enough' to please people... and I guess from what I'm reading here, they both fail.

I think I prefer systemd to upstart... it feels more featureful, and I think it's slightly easier to write configuration files for it than upstartd (maybe because it's better documented? I forget).

I know that I've had to write scripts for installations that account for all three systems, and systemd felt more mature than upstart in this regard.

I think another problem I experience with sysvinit involves the many variations per distribution of linux of any kind of helper script to get things running.
Basically, if you're trying to write something that can be installed on Redhat, Debian, and variants of these, sysvinit risks introducing a lot of pain unless you build the entire thing from scratch without any assisting batch scripts.... and if you do that, you might miss some special thing that the distribution does that helps inform the user of some detail or something.

Or, putting all of this more concisely, the initialization of services in Linux is very problematic without *something*, while Windows (much as I hate it) with its SCM seems to have happened upon a fairly (for Windows) elegant solution. It'd be nice if someone could figure out something for Linux that felt right for posix-oriented OSes.

the point about mission creep might be valid; I don't really know why they decide to make another logging service where we already had syslog.

That is a bullshido response if I'd ever seen one. Systemd is a total slap in the face, and completely ignores a TON of prior art in improving or even replacing sysvinit with alternatives that work as well, while retaining the Unix-y flavor.

BTW, Windows has a ton of supporting "batch" scripts as well (MS Installer anyone? OK, they're not literally .BAT files, but they do the same job) which gets executed upon installation or removal of a program. The only benefit to Windows is that you have one, and exactly one, precise directory layout.
But this is a solved problem in Linux, and has been for years.

Meanwhile, systemd seems to be a literal breeding ground for CVEs and bugs (DNS daemon that can't handle dashes? Sure. Why not?)

Systemd works great until it doesn't, then you're left in a world of pain and suffering. For cloud deployments, which is where systemd really shines, it works great because you have (like Windows) consistent system configurations.
But for anything else, it's a catagorical mistake.

OK, that's perhaps a bit harsh on my part, but it burns me UP when I see revisionist defense of crapware. For example, numerous init replacements had already existed when systemd was first introduced which relied on multiprocessing for concurrently launching daemons and the like. One was even so simple that it basically relied on make (via make -j) to perform its system startup.

The only reason that systemd took hold in the industry is, quite frankly, it's a Red Hat product. And RH is popular in Enterprises around the globe (in one form or another). All the other, and more technically appropriate/superior solutions, were offered as one-off projects as your typical open source fare, hoping teh Bazaar style of project management would take hold and let projects become self-sustaining.

MS Installer packages are little databases that you access with a limited Structured Query Language. Describing them as a script file is ... not accurate.

Windows has an SCM for services. It has been this way since NT (I can't recall if the 9x systems had it as well, but I know it's been around since NT 3.5). And while it's a bit heavy handed in some ways, it's a standard that you can mostly rely upon when working with Windows.

Linux has... kind of a mess. At least, from my perspective, as someone having to craft a debian package to install a product on an ungodly number of distributions of linux, with relatively limited resources. I have to be able to install this closed-source tool on 10-year old distributions of linux, and account for the different init styles so it fits in properly with that distributions best practices... such as they are/were. Add to this that I haven't had to do this before this job, and you'll see that I'm approaching this topic from a perspective free of opinions about any history of these systems, or even the degree to which something 'fits in' with the 'feel' of linux, since unfortunately my career has been dominated by working with Windows.

So, yeah... I'm more interested in accomplishing something specific. I don't care about the politics or history, just getting shit done. And I have to deal with every fucking variation of these damned init systems (even the fucking older versions, which occasionally couldn't handle something properly... like a binary that does the correct approach to turning into a daemon of all the most ridiculous and stupid things).

And so, I found systemd easier... because nobody has released a version of it in a distribution of linux made publically available that fails to work with an executable that turns itself into a daemon. Unlike upstart.

This said, I'm not suggesting it's a great system. To me, it feels like linux simply hasn't managed to find and settle on something that really works for it, so they're making do with systemd until someone comes up with The Right Thing.

Because at the end of the day, sysvinit sucks even worse than either upstart or systemd, if you want your OS to start in a snappy way.

What about launchd? Does the "not unix like" design requirement apply to Apple or are they too far off the reservation already?

Like most old-skool unixheads, I am partial to SysV Init, but I've never liked the way init scripts are built. All those silly files and symlinks are a nuisance. I would have liked it if inittab had been expanded for scripts the way every other configuration file was: just have /etc/inittabs.d/ and a package maintainer can drop files in for startup, shutdown, etc.

As for systemd ... I didn't think it was necessary but it doesn't bother me enough to dwell on it for a long time. And you guys know that I am the kind of person who *will* do that.

They're way off the reservation, but a lot of this systemd/upstart/no-shell stuff could be viewed as the rest of the industry playing catchup to NeXT/Apple