Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:On the ignorance of this debate (Score 1) 774

There are points where I definitely disagree with you on points where systemd is better. Containers for daemons can easily be made into a separate process, in fact it would be useful for testing if I could just do "contain-app --cgroup ... myapp" and check it works then make the init/dependency/startup system run the same command line. I'd love for this tool to exist, and if instead of rewriting the entire init system just this tool, with a focus on it working with the various other tools that are out there, was developed I would be a much happier man.

Logging in systemd is terrible, really really terrible. The appending text to a file model is great because it's very hard to corrupt the whole file in the event of a system crash. Indexing logs can, and should, be done by a separate process monitoring the files (Splunk being the best example of how to do this, if you can afford it), this way you get rollback capabilities for your indexes. This is how databases have done it for years, in filesystems it's called journaling - which is the ultimate irony of the systemd journal.

For service supervision what I've seen of systemd seems to pale in comparison to monit, which allows expect testing of various network protocols, restart management and is just all round awesome. You can run monit as init if you want, but it's probably not a good idea.

OS containers have been around with UML for longer than systemd has existed. They don't need a new init system to work, it's all a feature of the clone syscall.

Essentially I see systemd as a case of RedHat NIH, when RedHat desperately need things to have been invented there in order to try and remain relevant.

Comment Re:On the ignorance of this debate (Score 1) 774

I can't really take your comment seriously about systemd features being coupled together with no good reason. I have yet to see a systemd-opponent that have any real experience with systemd or even have read all the documentation and man pages.

You see, this is just it. I write a bunch of stuff that needs to be deployed to a run on hundreds of instances, what we have is tied into the init system as it was all done properly - that is to say it was designed to work with the system rather than against it. Suddenly the system is changing, and it's taking everything with it. If we want to keep using ubuntu then the migration is going to be awful once we need get of the current LTS; which thankfully is a long way off right now. If it were just the startup system that was changing it wouldn't be so bad, but it's an ever growing pile of stuff. Now I don't even know if we're going to be able to get the console output off our EC2 instances when they refuse to boot. Just rolling our own distro, or switching distro means changing a whole bunch of stuff, especially annoying as we use upstart so Ubuntu is the only option. So instead, some point in my future is going to mean completely replacing all my knowledge about how current init systems, logging, consoles, and who knows what else, instead of making new features. And this is probably going to result in investors yelling.

Comment Re:On the ignorance of this debate (Score 1) 774

Is condescension your default response? I've been developing software on Linux for years and using it for longer. There is no need for the console terminal emulator to be part of systemd; none whatsoever - you say as much yourself. Systemd is becoming a single package that does everything but your windowing system, this is a terrible state of affairs. No matter how much they claim that it's modular it's really not, everything ends up coupled together for no good reason that it's easier for Lennart to think about when it is.

Comment Re:Its a population crunch (Score 1) 452

I think the guy has just got lost in his own model, which tries to liken such a complex thing as the human civbilisation with a simple physical system, employing a constant relationship between global energy use and the civilisation's accumulated economic productivity. This is just naive...

The laws of thermodynamics relate the incredibly complex interactions of unfathomable numbers of resonating particles to a handful of simple laws.

Is it not intuitively correct to assume that no system can grown limitless, that there must be an upper bound for everything?

No, it is not.

Then why does our economy need to grow all the time? Why can't we just be content with a very high output? Does it need to increase all the time? And worse, does the growth need to increase all the time?

Well it passes the time while we wait for the sun to explode. The problem really is that we measure growth by GDP. The easiest way to raise GDP is to open a factory employing half the population to make intricate gold figurines, then employ the other half of the population to smash them.

Comment Re:So much raw data (Score 1) 309

Actually making a much bigger more expensive mistake is a great way of covering up a smaller one. The bigger and more expensive the mistake the more people are likely to be involved, once enough people are involved there's no one left to hold anyone accountable.

It's a fairly common pattern to see in business, it's better to lead a $100 million failure than a $10 thousand dollar success. The latter marks you out as an unimportant small fry, the former marks you a person of great prestige.

Comment Re:MySQL Sucks (Score 1) 381

Sequential execution scales perfectly if your batches can be run in parallel :-)

Take a webserver, each CGI script runs sequentially but a load balancer and an array of cheap machines gives you scalability. And that by the way is scalability, the ability to vary resource consumption with regard to desired output capacity, if the former varies linearly with regard to the latter your system is said to be scalable. What you describe is capacity. Performance is what you worry about when you exceed capacity.

Comment Re:bad design (Score 1) 381

Er no. Adding spacial data is a completely reasonable addition to the relational calculus, it doesn't even change any of it's properties. One requirement of the relational calculus is the ability to form a subset by a predicate i.e. {x | x in X /\ P(x)}. For spacial data the predicate is just selection over an area. No breaking of the calculus, no changes to it.

Slashdot Top Deals

Too many people are thinking of security instead of opportunity. They seem more afraid of life than death. -- James F. Byrnes