So you know the majority of system administrators? That's an awful lot of people.

I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.

If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.

It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.

Not always. His yacht was hideous!

Always good to hear things from the original source! Thanks for posting.

Just fyi, your "homepage" link refers to your old Easy Software web site, which no longer exists. Apparently an e-cigarette company has bought up your old domain name!

MS Windows is still the dominant platform, and it doesn't seem to have any guidelines or standard widgets anymore. Every app seems to use s different set of widgets and owner-drawn window decorations are a plague in certain spaces like anti-malware and anti-virus. MS themselves started this trend by using a different set of widgets with every release of MS Office. I just laugh when people talk about Linux apps being all different and not fitting into together. Windows is at least as bad these days, if not worse. And yes Chrome has made the problem even worse, and now Firefox.

If I could use classic theme restorer plus the GTK theme addon for Firefox I'd be a happy camper. As it is I'm stuck on ESR 24 for the time being.

Here's a real product that seems to almost do what the original poster is wanting, but not quite. But the it's a similar solution to what I described, but instead of discarding packets to allow the fasted packet to win, it aggregates bandwidth. Different problem, but similar solution.

http://www.pcpro.co.uk/news/br...

Seems like reading and comprehending the question is not doable for most of the folks in the comments of this story today. If you go back and read what the original poster asked, I think you'll realize that it's completely doable, with some (perhaps significant) effort. Certainly there aren't any out -of-box solutions that I know of. Basically a combination of mTCP and VPN is what he's looking for. The multipath connection is not between him and the gaming server. He wants it between him and a VPS running linux. The gaming server part is the final goal, but nothing to do with his problem or question. He certainly could invent his own tunneling protocol using, say UDP. As an example, if we consider the tcp/ip protocol, each packet has a unique sequence number. So if we take a TCP/IP packet, wrap it in a UDP packet and send one to the server through each interface, the server could unpack the UDP packet, note the sequence number, and if it already saw it recently, discard it. Otherwise, make a note of it and drop it onto the internet. On the return trip, acknowledgements would have to be handled on the client side. IE if one ack comes, we can safely ignore any others for the same sequence number. If no acks come from either pathway, then it's a standard timeout. This is TCP/IP only. I'm sure UDP could be encapsulated in a similar way, ICMP also probably.

As I type this, I wonder if this could be done by hacking OpenVPN. OpenVPN already has udp encapsulation of UDP, ICMP, and TCP/IP. It would just be a matter of hacking in some support to send the same packet out multiple interfaces at once, and then logic to track and discard duplicates. Not sure how long either hand would have to track things for, or how much would have to be tracked.

Now if we can just get them all to sign up and donate money.

Well you'll be happy to know, then, that plain text log files are alive and well under systemd. They are still there. Really. syslog facility continues to function. The journal provides a fine-grained, extremely searchable facility in addition. As for the journal being binary, that is certainly a good debate to have. But it's not even close to the windows event viewer.

Your comment makes no sense. If you don't like or want to use it then don't! What a bizarre notion. You act as if you're forced to use it. Besides all that you're using something that is provided for free! How dare they mess with my precious linux! If you don't like it, move on. Use something better. You might have to pay for it, but that's the way the world works. Windows 9 with classic shell isn't that bad.

What the op is saying is that whining about free software makes you a freeloader, plain and simple. There is such thing as feedback and criticism, but the crap over systemd passed that line a long time ago.

Citations needed. Please post the bugzilla links to the bugs that the systemd team are ignoring? And what current issues of compatibility are you referring to? I seriously wish to know, and I think folks here would like to know also.

Except that RC init wasn't fine. More than a few times over the years I've had a service that wouldn't start right on a server that actually prevented boot! Whether it was some stuck PID file that wasn't properly erased on boot, or some other race condition (often a network condition, or a chicken/egg problem), it happened enough that I modified inittab on all my servers to throw up a login console near the beginning of boot so I could at least log in to try to fix the problem. Ideally none of this should ever happen, but it did. Bugs are there. Combine that with the fact that init scripts are huge, fragile, hacks, and yes you can say sysv init has serious problems. As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script, and have little to no debugging capabilities, no process supervision, and no easy way to control how many instances of the daemon can run.

All other major unix server vendors ditched sysv init for the same reasons as I state long ago. To my knowledge, of the major important players, only Linux and BSD still use sysv init. The world has not ended, and the sky has not fallen. Life goes on, and Unix and Linux continue to do well and provide stability and reliability. In fact, all I see here is vitriolic teeth knashing. I've yet to see anyone with a specific argument against systemd. It's really disappointing, actually. I think I read one criticism from a developer of another init system that was actually insightful and valid. Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice. RHEL's mailing list has nary a mention of it. It just works and works well. Uselessd is a validation of the systemd approach. They clearly also believe that init is broken, or they wouldn't be working on the uselessd fork. Will be interesting to see their approach to the VT issue. Competition is good.

First off, what are you talking about when you say none of the X11 terminal emulators can set the color palette? Every terminal emulator I've used change the basic 16 standard terminal colors to whatever you want.

But, who said anything about VTs going away? Moving them out of kernel space in no way makes them disappear. If not systemd, then some other light-weight VTd. In fact this is the whole point. And you'll be able to set your color palette just fine as you do now, and choose your fonts. But unlike the current setup, if the VTd develop wants to you could have font scaling, instead of native resolution bitmapped fonts (which can get very small on high res displays).

I can tell you don't use Linux on a regular basis. Don't mistakenly think that Windows' broken localization applies to Linux. The Linux commandline and terminal has been localized for many years with no issues as you report.

Maybe in Windows things are bad, but in Linux, scripts will work regardless of the localization. The command names don't change, nor do the command-line options. But filenames and data certainly can be in any language. Unlike Windows, system folders do not change names. It's possible that grepping for specific output from programs will fail. But if you're doing that in your script, you can set the LANG variable to whatever language the you need (probably english to be most universal).

Again, though, this has nothing to do with the idea of putting kernel VT code in userspace. There are valid arguments against this idea, but I've not read of any on slashdot yet. Just knee-jerk teeth knashing, and, sadly, more inappropriate ad hominom attacks.

Oh really? From the sound of it, VT code in the kernel hasn't been KISS in a long time, certainly not since KML was introduced. Was KML a solution in search of a problem? Hardly. The VT code is full of hacks, bugs, and hard to fix and improve. And we're not just referring to the lack of unicode support, which isn't hugely important. This knee-jerk reaction to systemd is way silly too. One would think Linux users would understand that moving things out of the kernel into userspace is desirable, especially on a server, and especially in an environment where virtualization is the norm. Besides all this,you could just, you know, not run the systemd console daemon. Linux has always supported serial terminals, and will continue to do so. If you're a hardcore server operator (physical or virtual servers) I'm sure you already have this set up.

Just to nuance my answer a bit more... not completely wasted. Fruit, flowers, and other things do absorb other wavelengths. And there are other things in a full spectrum light that probably help the plant too, such as UV, infrared. Light that does bounce off the plant, though, is "wasted" and that is most of the full spectrum light, or the HFS light.

There are several experiments in growing crops in green houses under magenta lighting with success. It's the most efficient way to artificially light plants.