Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Do people who post on lkml actually know englis (Score 1) 755

by Giant Electronic Bra (#49070383) Attached to: Removing Libsystemd0 From a Live-running Debian System

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.

Comment: Re:I think you misunderstood (Score 1) 272

by Giant Electronic Bra (#48726089) Attached to: How Civilizations Can Spread Across a Galaxy 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, using nuclear pulse propulsion however could presumably be built today with existing tech and would suffice for a trip to 8000 AU.

Comment: Re:I think you misunderstood (Score 1) 272

by Giant Electronic Bra (#48725915) Attached to: How Civilizations Can Spread Across a Galaxy

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.

Comment: Re:How? (Score 1) 272

by Giant Electronic Bra (#48725887) Attached to: How Civilizations Can Spread Across a Galaxy

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.

Comment: I think you misunderstood (Score 4, Informative) 272

by Giant Electronic Bra (#48722161) Attached to: How Civilizations Can Spread Across a Galaxy

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.

Comment: Re:1966 Ford Mustang (Score 1) 195

by Giant Electronic Bra (#48436069) Attached to: Ask Slashdot: What's the Most Hackable Car?

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.

Comment: Re:And again (Score 1) 928

by Giant Electronic Bra (#48325955) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?

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.

Comment: Re:And again (Score 1) 928

by Giant Electronic Bra (#48300787) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?

There's NOTHING wrong with script files.

Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.

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.

Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.

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.

No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.

I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.

They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).

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

As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.

I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.

The core of systemd is certainly a lot more complex than SysVinit and similar, and the complexity isn't avoided by using SysVinit; it is just moved into other external programs.

systemd it isn't large, and all core daemons are really lightweight when it comes to memory/cpu and other resources.

A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.

I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.

Sure, an improved "Super" SysVinit would have been easier to deal with for many. Upstart was one such attempt. But the problems with making such an improved script based init system is harder than it appears; Why should upstream support it, if it breaks compatibility or just have small improvements? Changing how everything works for a small gain will mean little traction for such a project, which again will mean little support from upstream projects.

What makes systemd so attractive for upstream projects is, that while it changes things a lot, it also really help upstream projects in many ways by making a cross distro compatibility layer, providing needed low level functions like logind, and by simplifying daemon development and daemon configs. I am aware that you think systemd provides no benefit for your user case; fair enough, but it is a mistake to think other people doesn't have other user cases where systemd is a huge improvement over existing solutions.

I think many of the design decisions made in systemd are really sensible; if someone wanted to design a modern, general purpose init-system that scaled from embedded to supercomputers, and had the same features as systemd, including backward compatibility, they would end up with a design very much like systemd.
I think it is armchair OS design to think one could have systemd features by making many small totally independent programs; all performance would be killed by inter-process communication, and the design would be really, really fragile and complicated.

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.

And no, I'm not really being given a choice when the only option I have is something like Arch Linux, which no offense to its maintainers, is not something I'm going to run my bank on top of. Neither am I going to suddenly convert said operation to using systemd willingly. I've already had to deal with a lot of fallout from this stupid idea. I didn't have any problems before that needed this solution frankly and the changes ARE disruptive while we've noted zero practical benefit.

There is Slackware too. But I understand what you mean; at the moment there simply isn't a stable long term release Linux distro besides Slackware and its derivatives. If you run a traditional server setup, Gentoo and other rolling release distros aren't so attractive.

It would be strange if such an distro didn't materialize at some point however.

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.

Put not your trust in money, but put your money in trust.