Even if the guy intentionally put his food in the refrigerator, it would not justify flipping out and yelling for 20 minutes, let alone punching the producer in the face.

Someone who hates everything else even more?

It has the advantage that it does backwards compatibility well with advance notice when a feature is about to disappear This means that if I need to upgrade my PHP application, I am sure to have a version that supports both the new interfaces and the old deprecated interfaces and more importantly it means that if I have a number of different apps that I need installed, I am not likely to need to move them each into their own VM. Python as an example of everything I hate doesn't even try. Their "fix" is to install a local copy of python with the app which is great until something needs a security update and now someone must upgrade each app's environment individually.

It also, quite amusingly doesn't come pre tuned to handle Oracle databases. Last month a burst of traffic crashed two Oracle instances on Oracle Linux machines I don't maintain. When they called me in to debug it, the problem turned out that the SHM limits were too small.

One thing I absolutely love about PostgreSQL is that it sanity checks the system limits on startup and throws an error if something is off.

Not always, sometimes it's that they want perfection. I had one case where the requirements were pretty much the existing guy's exact experience but they forgot that they didn't hire him in that condition he grew into it as their needs expanded. In the end they found no one and put the decision off for later. In the meantime I wish them the best of luck finding a Linux server admin, storage admin and Mac deployment expert in a single person.

This one seems better

Why would the guy who wrote the driver in question not have standing?

Beta no longer exists.

Toshiba: large hole in the bottom where the air gets sucked in and then blown against a heat sink on with tiny fins. dust gets sucked in and blown against the heat sink where it gets stuck and when that dust layer gets thick enough, the only way to clean it is to rip the whole laptop apart. It's almost as if they designed the laptop to wear out after a year or two passes.

Right, you would put Telefonica's pubic key into the authorized_keys on each device file but never the local device public key. The simple fact is that unless they are far more stupid than the article suggests this cannot be used to break into the routers.

I don't think so. The pubic and private keys are only good for outgoing connections and not incoming.

They could do that, but then Telefonica wouldn't be able to buy the routers from China for $15 each (non wholesale price for the exact model Telefonica had in my house when I lived in Spain).

I strongly suggest avoiding Lenovo completely. They already fail to boot if there is an unrecognized wifi card ( I had to hack the BIOS) and for their latest move towards evilness refuse to charge both third party and batteries the system detects as too old.

You do realize RedHat (the distro running systemd for the longest) has reported their subscriptions going up for the last several quarters? Meanwhile we have people who are making a lot of noise about leaving but never actually do. (Distrowatch is showing interest in *BSD as dropping) We have a Debian fork claiming to be a bunch of "veteran admins" without naming any of them and a mailing list of people who like to argue more than they like actually doing anything. So where are all of these upset people going?

Well reasoned like the post I was replying to? It managed a "Score 5: Informative" despite not having any arguments that were actually true.

The Slashdot echo chamber is what annoys me the most about all of this. I see posts like "SystemD is Monolithic" (it isn't) "SystemD includes an NTP and DHCP server in PID 1(They are optional and don't run as PID 1). Or my all time favorite: "SystemD" is designed for desktops and makes server administration harder" When the reality is that SystemD was designed with some of the more complicated server setups in mind and the speed improvement on the desktop was mostly an accidental byproduct. The only actual valid complaint I have seen so far is about the binary logs but they are easy to bypass and even with journald doing mostly nothing, the whole thing uses less RAM and disk space than the init system it is replacing.

Naturally, this is plumbing and boring by nature. "Works best for this case" is actually a good reason for doing it In the meantime, the old system was a bug ridden mess. I mean really, I had until recently some servers that need a partial filesystem mount followed the network followed by GlusterFS followed by Apache. Care to guess how well that works in a default Debian stable install?

I am not so much pro SystemD as much as I am anti FUD. I am annoyed that I let the slashdot crowd actually made me worry about my future as a Linux admin until I researched for myself what the facts were .In the end, I wouldn't be shocked if SystemD ended up being a good proof of concept and replaced with something else. In the meantime, it solves more problems than it creates and manages to be better than the alternatives.

It's right in their "Why SystemD" document. " But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."

For me, there is only a single mandatory piece that I have a problem with and that is the binary logging but that is easy to bypass even if I can't turn it off. For the rest of the crap such as his DHCP server or his NTP server, I have no plans to install them.

This will not be the end of Linux, it is slightly different and hasn't caused me any headaches server side and a single problem with pulseaudio (permissions problem) on my desktop running Debian testing (my laptop works fine however). It has however saved me once on the server when I accidentally typed "/etc/init.d/networking restart" instead of "nohup /etc/init.d/networking restart" Previously that would have caused the machine to terminate the script as soon as my remote console dropped without completing, leaving me without a network connection but now the command runs in the background and it just works.

When they spread misinformation? Yes. When they bring up every possible opportunity to tell the whole world how much they hate SystemD? Yes.

What pisses me off is that based on the posts I was seeing here, I started to really worry about my future as a Linux admin but then I looked for myself and discovered just how much misinformation was being passed around here.