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.
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.
No the OP is correct. Plants use red and blue light for photosynthesis, not green. Green does very little for the plants and in fact very little is absorbed by the plant, some more than others. That's why plants look, um, green. An HPS lamp may work because it puts out sufficient red wavelengths for the plant to absorb. The rest is completely wasted. So yes it works, but not very efficiently. Most of the light just bounces off the plant.