I've read some good criticisms of systemd by another init system developer. He had valid things to say and put them on his blog in a nice point by point way that can be responded to and rebutted.

Rather than bad-mouthing Red Hat on slashdot, why not put up a direct, technical critique of systemd on your own web site (or post it here). I know many people would appreciate having a point by point critique. You say their code is a "mess" but what does that even mean? Please provide examples (such examples can only benefit everyone). Otherwise it's FUD. I know you probably feel like it's not worth your time, yet you post a half dozen or more anti-systemd posts here. So you clearly have the time.

Your mistake was going to Best Buy to find a cable. You're better off going to Princess Auto of all places to find cheap ethernet patch and HDMI cables. No hard drives though. And everything smells like smokey rubber.

Home Depot carries the best little set I've owned:

http://www.homedepot.com/p/Hus...

I have probably bought half a dozen of them as they are super handy. If you take out the little plastic insert in the handle, you can put all the bits in the handle also.

How do you know their code is dangerous? Have you reviewed it and published your results? Systemd is bloated? Have you even looked at the code? You do realize that systemd-init is not much bigger than sysv init was.

Furthermore, I don't think Red Hat would support systemd if their best engineers (and I know several of them; they are very smart people) doubted it. In fact if you read up on systemd you'll find that initially Red Hat was hesitant to pursue systemd. The systemd devs proved their case and won people on technical merit, especially as Linux has been moving into new areas like virtual machines and containers. And other distros are picking it up because it addresses major shortcomings that were starting to really impact Linux.

Interesting you should feel systemd is the worst of the lot when every commercial Unix out there abandoned sysv init years ago. Solaris, HPUX, Apple. You name it. They all did for the same reasons. init scripts are error-prone, clunky, hard to audit, and a maintenance nightmare. You couldn't even move an init script between systems. Have your worked with modern systems that employ containers, storage pools, logical volumes, hotplugged ethernet, storage, etc? I have, and it always was a bit kludgy before. Just consistent naming of ethernet devices is a nice benefit of systemd. Back in the dark days of Linux I would often put in ethernet cards from different manufacturers just to make sure I could map names to them in a consistent way.

Sorry, that's not udevil. That should be traditional udev, or eudev.

So far as I know, gvfs is dependent on udev, not systemd. There are versions of udev still available out there that are not part of the systemd. On systems running systemd, udev is going to be provided by systemd-udev.

So if you could rebuild your packages with a different udev implementation like udevil, gvfs could be build against it possibly.

And it was a bad idea when OS X did it, and it's still a bad idea. I hope they can be disabled (this is actually a GTK thing, not a Gnome thing). I can see how this is useful on a very small screen with a finger as the pointer. But not a mouse on a desktop. We've really gone backwards in usability on computer desktops generally in the last 5 years. Perhaps this coincides with the rise of the "user experience" field of thought, rather than focusing on intuitive "user interfaces."

FUD FUD FUD. Systemd is not a hard requirement of Gnome. Gnome developers have chosen to focus on using systemd-logind at this moment, but there's no reason why ConsoleKit couldn't be updated and maintained for use on other platforms. Gnome developers with their finite resources have chosen not to work on ConsoleKit, but you certainly could.

From the Linux Voice interview:

Some people donâ(TM)t realise that when Gnome started making use of Logind, I actually wrote the patch for that. I ported GDM onto Logind. But when it did that, I was very careful to make sure it would still run on ConsoleKit. I didnâ(TM)t want to have those fights â" if people want to continue running ConsoleKit, they can. Those patches made it in, but some people saw that Gnome now works with Logind, hence it must not work with ConsoleKit any more!

But thatâ(TM)s actually not true. And to my knowledge the code is still in there â" the compatibility for ConsoleKit. The Gnome team has the general problem though, that nobodyâ(TM)s willing to maintain it. People who want to stick to the old stuff, they actually need to do some work on it. If they donâ(TM)t, then it will bit-rot and go away.

And just to be clear, logind is not some part of a bloated init system. It is a service that is developed and shipped with the systemd project but it is not part of init, and is a completely optional part of systemd.

I think you'll find you only get the $10.99 price the first time. after that it's typically more like $25 or more a year for a .com registration. At least it is on godaddy.

I would like to switch off of godaddy, but I only ever remember to think about it when it's time to renew, and from what I've been told, during this renewal time your name is locked and you can't migrate away. Not sure if this is just a godaddy cash grab, or if that's the way ICANN works in general. I use godaddy only for the name registration; I do all my own DNS and hosting.

Then why do you want bash or csh, which are inherently unix-centric and require the use of forward slashes, and know nothing about windows drive letters?

From your post there I can tell you've never used cygwin. It uses /cgydrive/c for C:, not /mount. Which isn't that hard to deal with. Works well for me, since I'm used to Unix to begin with.

There are a variety of command-line shells available for Windows you can try out. They each seem to somewhat resemble cmd.exe with various enhancements.

Don't you mean there are cheaper methods of heating than resistive heating? Because as far as I can tell, resistive heating is 100% efficient. Incandescents convert some fraction of the input energy to visible light. Almost all of the rest is emitted as heat. And if there was no light emitted, a resistive element is nearly 100% efficient. It's just that compared to cheap gas it's not particularly cheap to heat with electricity.

My computer is 100% efficient at converting every last drop of electricity that goes into its power supply to heat.

And I actually don't think the OP is really joking. In northern climates, moving away from incandescent lighting will mean that more heating from other sources is required. But even with additional heating needed, it is still going to cost you less in the end at least in terms energy cost, not counting investment cost.

Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.

Doesn't look like he bothered with the synchros. And at the low input speeds his demonstration uses, they aren't necessary either. The dog clutches aren't spinning that fast so as to cause a lot of damage while engaging and they take no load in this demonstration.

And even on a real car transmissions, synchros are not actually necessary on real transmissions either; you just have to know the theory of how to shift.

Of course we can blame her for this. She's the one that made the decision to use personal email for government and public purposes, hiding her correspondence from government archives, and hidden from freedom of information requests. If not outright illegal, this is morally wrong. When she becomes president will she continue to hide her official correspondence from government archives and the public? Nixon would have loved to have had a system of off-the-record private correspondence instead of those pesky papers that leave trails.

I was not aware that lightening had any springs or "moving parts" on the cable or the jack. Thought they were magnetic.

Good points otherwise.

As to the other posts talking about how the ports and plugs are engineered so that the port breaks before the inner plastic breaks, or before the board mount breaks, well that may be true in theory. But not always in practice.