Neato! That worked rather well on Ubuntu 16 server.
Hm, this didn't work on Kali 2.0, though, which also uses systemd. I wonder why that didn't bother it.
Wait a moment... nope... it looks like it did impact it. I can't restart the box properly. It doesn't seem to mind letting me start/stop services, though.
Subject: Re: Systemd uber.
I don't think it can be done. :)
Slackware isn't really a Linux operating system. It's FreeBSD with a Linux kernel.
That having been said, here are the technical reasons I like systemd. I don't really care to get into the religious war on this one -- in fact, people who dislike systemd are *not* necessarily Hitler. I happen to personally like it because:
* It is a single subsystem that replaces dozens of scripts that can interact in weird ways.
* Installing a new service is simple, and done one way: "systemd enable <svcname>" (assuming you dropped the systemd config in the one proper directory where it is expected to be found).
* systemd does not require specially-formatted comments to be placed in init scripts to give the OS a hint as to ordering and dependencies. Instead, its configuration syntax has proper dependency management.
* Services started by systemd do not require extra code to place themselves into the background (daemonize). Therefore, they don't have to drop pidfiles onto the system so that some other script knows how to shut them down later.
* If a service started by systemd crashes, systemd can respawn it automatically.
Back when sysvinit was ubiquitous, I used to start services directly from /etc/inittab for exactly that reason. systemd offers this ability in a more formal declaration syntax: here's the program; run it in the foreground; if it exits, fire it up again.
sysvinit was designed to be configured by greybeards; systemd was designed to be configured by installation scripts. For that reason alone, it makes more sense for mainstream Linux distributions to be using systemd. Slackware isn't really a mainstream Linux distribution though.
Does it even have the normal init scripts? It's been a long time since I looked at Slackware, but the last time I used it, it had /etc/rc.d style scripts.
Like I said ... FreeBSD with a Linux kernel.
Subject: Re: Systemd uber.
So, automation and daemon management. Slackware has rc init scripts (BSD). Never had issues with them, but I mostly use Slackware in cases of set up once and run till it dies cases (one off routers, single board computers with one task, etc...).
I did not mean to invoke a vi vs emacs type holy war. Just wondering what sysadmin type tasks you found to be helped by using systemd, and what I could do differently with my Slackware installs if they ran it, but for what I do with them, it probably won't help much.
Thanks, I think I see the benefits. I run systemd at work on a couple of machines so far, and the learning curve has been a fair amount of digging up documentation with each new line in syslog to see what might need tweaking next. I know it does logging (journalctl), and have started using it as well, but I find it hard not to fall back to reading syslog :-)
Most of the automation I do uses fabric helper scripts to keep my ever growing farm of pets (i.e. not cattle) alive.
Hoping to work in to more automation and cattle servers in the near future though.
The more I look at Docker, the more I'm convinced that it could potentially become *the* universal package distribution format for third-party software.
I think I was looking at it the wrong way, assuming that it served the same purpose as Virtuozzo/OpenVZ or LXC by itself -- basically just a more lightweight version of a virtual machine that uses a shared kernel and cannot easily be live migrated. And maybe that's marginally useful, but probably not enough to justify using it instead of actual virtual machines, except maybe if you needed exceptionally high density on a single host.
But now that I'm playing around with it I see that the real value is that a Docker image carries around all of the dependencies for an application, so there is literally nothing that can go wrong. And the image format being git-like so that it can not only be expressed as deltas from a parent image, but also pool those deltas on a central repository, is sheer genius.
I installed Docker because I was trying to build an application that had a lot of steps to put all of the pieces together. In the past, application providers might have solved this problem by distributing the application as a virtual appliance. But they chose to go with Docker instead. I downloaded the container and ran it. Everything came up on the first try.
I'm definitely going to start distributing my software this way.
Try OnlyOffice... it seems to have dependencies on other docker apps, which seems somehow kind of fucked up.
You might expect binaries to have dependencies, but there's something ... wrong ... about docker dependencies.
Now you've got a ship-shipping ship shipping shipping ships, which can't ship ships without... a tugboat.
Apparently, Mark Shuttleworth finally got around to reading the emails I sent him in 2011.
[ http://tinyurl.com/kkdsapr ]
The awful "Unity" desktop is going away. Starting with Ubuntu 18.04LTS, the Ubuntu desktop will be returning to GNOME. The long international nightmare is finally over. Shuttleworth has finally understood what the rest of us already knew: phones are not tablets are not computers. A single environment that spans them all is a bad idea. (Hey Satya, are you listening? Doze 10 is more capable of acting like a computer than Doze 8, but it doesn't go far enough. Kill your phone project like Ubuntu did.)
This is one thing that Apple got right. Different devices call for different operating environments. I'm not a fan of Mac OS or iOS, but at least each one is designed specifically for the type of device it runs on.
Ubuntu will be refocusing on the things it does well, with (omg!) a focus on the things that are actually bringing in revenue: cloud and IoT, and some desktop as well.
Unity was the reason I abandoned Ubuntu in 2011 and went to stock Debian, even though Ubuntu made the installation and maintenance experience easy.
I'm looking forward to returning to it.
Hm... I might have a use for that.
I'm waiting for the day they run it on WSL.
And yes, I'm ok with this. It's the same as Windows software running on OS/2, eliminating any motivation for software developers to write for the platform that can emulate the other one. It's actually the same as Windows on OS/2 in another way: it isn't really emulation, but rather a well-hidden copy of the other operating system inside the environment.
Linux uber alles.