What does SSL have to do with it? As you say yourself, as long as you are checking the signing key on each package, you can guarantee that the package is intact and genuine, not matter what the MITM tries to do. The worst that happens with http is that someone can determine which file you downloaded. Hence the injecting of malware can't happen to Linux packages (if the private key is secured by the distro maker). Couldn't happen to any signed executable either, but on Windows users often blindly allow programs to run even with bad signatures.

Obviously there is a way, since their malware driver was detecting it and *then* changing the pid to 0x0000. In fact you can see source code for this that someone posted to the Linux Kernel Mailing list a few days ago. Hopefully the new driver will do exactly as you suggest, though I think a big warning message box saying that the device is not genuine, but continue to function might be enough for end users to let companies know their devices are using the fake chips.

Well the fact of the matter is that Google is only interested in making sure their app store is the only trusted store. The choice to make it all or nothing was deliberate on their part. They could easily have implemented user-selectable trust of signing certificates. Granted 90% of android users don't even understand the problem, let alone the solution.

Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?

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).