lol, yeah, that's what I was thinking, they must be doing this research at NIMH!

Gold isn't any more 'real' or 'funny' than any other sort of money.

I mean basically we have $1 trillion worth of funny money from QE1-42 that has to be burned sooner or later anyway. If no actual real money is spent, is it really a valuation? Is it really a bubble?

No, you cannot 'unilaterally' create a condition between two groups of people. You can DO something unilaterally, "The introduction of systemd has unilaterally created a polarization..." is a misuse of the word. The EFFECT of what systemd did was a polarization, in which BOTH PARTIES moved further away from one another "towards opposite extremes." Polarization cannot, definitionaly, be unilateral. Its crappy writing. I suppose complaining about crappy writing on /. is like complaining about the smell of sewage on a particular day, but so be it.

Really, someone should get a dictionary for their birthday and read the definition for "unilateral" lol.

As soon as we lost that it all went to hell, and until we get it back there's really nothing that's going to fire up competition, nor can we maintain network neutrality when so few entities control the last mile.

http://en.wikipedia.org/wiki/P... is the original nuclear fusion powered starship study. It would be a 500 ton scientific payload reaching 0.12C, but it does require some capabilities not yet available. An Orion type system, http://en.wikipedia.org/wiki/P... using nuclear pulse propulsion however could presumably be built today with existing tech and would suffice for a trip to 8000 AU.

Ah, yeah, I've been reading around and I have to agree, the 40k must be a typo or something. So it sounds like these kinds of passes are something like 1/megayear. That doesn't make them exactly very likely to let you spread your civilization all that much, does it? I mean if you have a planning horizon of millions of years and have been around that long I'd expect a trip of 3-5 light years wouldn't be completely infeasible.

Exactly. Something like a fusion reaction energizing a VASIMIR-like magnetic nozzle choked down to a small diameter would produce a very high specific impulse (IE very fast exhaust velocity). You might also utilize gravity assist, but that would only be worth a fairly small increment of extra velocity (perhaps a Solar gravity assist would work, stealing some energy from the Sun's orbit around the galaxy, this could be possible though I don't know if it would be a good idea or not).

As far as the Voyager comment goes, they are going as fast as we could possibly get something moving at the time given the tech and navigational constraints. Its possible to attain somewhat higher velocities, but not a LOT higher with chemical rockets. Fusion power in the sense of a really efficient controlled fusion power source is not 'Star Trek' tech however. Its maybe 100 years out tech, but nothing new is required in terms of physics, etc. A fission rocket could actually work too, something like the Daedalus pusher-plate bomb concept could essentially be built today. It would be less efficient than some sort of advanced gas-core reactor, but we have not yet worked out how to build those either (easier than fusion probably, but not by a lot).

I feel confident that some pathway exists to say 100 AU/year velocities, which is enough for Oort Cloud type exploration, beyond that it is all very speculative though. There are plenty of concepts that can get to 8,000 AU, laser sails, fission/fusion, etc.

HIP 85605 will come within 8,000 AU of the Sun, still quite a distance, but VASTLY less than 3 light years. The blurb was also incorrect, this close pass will be in about 40k years, not 250k or more as stated (though perhaps this is a difference in sources, I don't know). 8,000 AU is something we could probably bridge with some advanced tech. For scale Voyager 1 is now at approximately 200 AU after 36 years of travel time, meaning it will take just shy of 2,000 years to reach this distance. It is certainly feasible to build a larger craft and fly it at 50x this speed using say fusion power, still only a very tiny fraction of C but yielding a trip time on the scale of a human lifetime. A little beyond our current engineering, but something similar to Daedelus, for instance, would suffice.

So, the idea isn't crazy. Its not that big a stretch of the imagination to think that true interstellar travel in the classic sense is simply infeasible. In fact it really is fairly difficult to imagine from an engineering perspective, there are technical issues so vast that they may well be insoluble, or only solvable by making compromises that are just not acceptable or limit such travel to very infrequent probes or something. That would leave close approaches as the single exception.

function pickPizza {
    return { crust -> chewy, toppings -> [ 'pepperoni', 'extra cheese']};
}

Hey, ALL 60's cars were deathtraps! The OP never said anything about it had to be safe. Not sure why you hate on the '66 though, its a very classic model. The disc brakes were pretty much crap, but you can easily fix that (and by now if you own such a car it has long since been dealt with). The drive train in the performance model is pretty much standard Ford. The Windsor HiPO with the 4 barrel is a pretty nice engine.

Remember to get the high performance model, not the crappy one!

Oh, you didn't mean "drop in a new tranny when you said 'hack'??" Damned lazy kids.

Its just introducing another dependency. While I agree that shell scripts aren't the most elegant thing in existence and you could certainly write better ones in say Perl that would just mean that everyone would have to install an interpreter, just to boot their machine, and I think that wouldn't go over too well. Shells are unavoidable, so that dependency is pretty trivial.

Beyond that you can certainly write some perfectly nice shell scripts, and it should be possible to hide whatever ugliness there is with some more extensive libraries. Shell scripts allow for includes of packages of routines, and RedHat did a lot of work in that direction way back when. I guess they just had better things to do and it was never pushed to its limits. As I said before there are also /etc/sysinit scripts which are intended to contain ALL the user-settable configuration parameters for system services. Again, this hasn't been pushed hard, probably because its just not glamorous work.

Frankly I think if someone put their mind to it they could clean up the existing sysVinit process, init itself, build some libraries and establish some better conventions and you'd have 75% of the benefits of systemd without all the ruckus. The other 25% most people can probably live without and its not at all clear to me it belongs in the same project. Much of it could exist as stand-alone tools/libraries and some better conventions covering how to use cgroups and etc. That would IMHO have been a better approach.

I'm sorry, but just saying "X is 'primitive'" isn't actually very useful. There is nothing primitive about scripts.

Also this isn't about SysVinit, this is about systemd. Picking at the one isn't an argument for the other. In fact SysVinit is pretty sophisticated in its own way, but its fine if we make it better or replace it with something BETTER. Again, just pointing out the problems with it isn't automatically enough to make systemd the correct alternative. I've pointed out negatives about the systemd approach, you need to address those.

There are two problems with this statement. First of all properly written init scripts ala RedHat put all their config in /etc/sysconfig, not mixed into any script. This is a perfectly easy practice that has been the state of the art for at least 10 years. Secondly blanket statements decreeing what is and isn't 'indefensible' are ridiculous. You need to make concrete arguments, I and many others are FAR past the point where any sort of decrees like this mean squat to us. There are many cases where basic invariant configuration elements are perfectly reasonably placed within a script. These are things that are not going to be changed in your installation but should be parameterized as good PROGRAMMING practice. Don't confuse those with configuration options that the system's user is going to want to change, they are very different things.

Horse Petunias. Computing hasn't fundamentally changed, and the same use cases that existed back in the mid 1980's when init systems in use today were birthed exist today. Believe me, I was there, and I know. A machine room today is solving the same problems that they were back then. Some of the technology is different and there are obviously some new things, but my 1980's Sun Unix machines ran pretty much like my Linux servers do today. If you want to tell me that a mobile phone is quite different from a mini-computer, well yes. However nobody is asserting that a mobile phone should be running the same init system as a web server, except the people making everything depend on systemd....

Obviously we will have to agree to disagree. As a highly experienced system architect I'll take my instincts over those of people that seem to be going up the wrong path every time. IPC isn't a big deal, and if your init system is doing enough work that 'killing performance' is even a remote possibility then something is VERY wrong. At the most basic level there are a whole series of different problems here, starting and stopping services at system initialization/termination, managing hotplugging, general event management, and "compatibility layer". These need not in any sense be lumped together into one solution. Respectfully, you are wrong on this. I've been doing my system engineering trade for a LONG LONG time since an early age and when I know I'm right about something, I'm just right. Its not that common, but this is one of those cases, so you're going to have to do detailed exposition of every single technical point if you expect guys like me to be AT ALL convinced.

Yeah, I'm actually not pissed off at the people writing systemd. I'm pissed off at the people that maintain RHEL because they showed incredibly poor judgement, and making them pay for it is going to be quite a lot of work that should never have needed to be done.