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.

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.

Systemd can spawn containers that manage web servers, why not have a web server built into systemd?

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.

You mean where Google comes along, does a ton of work, and for some reason doesn't think it should have to pay someone else for the work they did?

Seems completely fair to me.

Why is it part of systemd? There's no reason I can see for a thing called systemd-consoled to exist.

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.

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.

Yeah, it's easier to find albums of obscure artists on Google. Even then you miss the point, TPB will have to go to court again to find out if this is illegal, and that could take years. So we now have a few years to find another workaround.

I'm confused, are you agreeing or disagreeing with me? (Or just drunk?)

Writing a custom solution costs money. Or do you work for free?

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.

Show me your data which is hard to model as a collection of sets.

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.

Rigid schema design is a feature of the relational model + some type checking, not SQL. SQL queries can often fail with run time type errors (in all the SQL systems I've used at least), so SQL is not that rigid in its enforcement.

I'd love to be able to use Datalog with a database (perhaps with some type of dependent type system to enforce constraints at compile time, and a pony...), but there's nothing outside academia that supports it as far as I know.

The idea of RDBMSs being slow seems to stem from people confusing special purpose databases with general purpose key value stores. The former can achieve access times in the sub 10ms range, the latter are more in the 100ms lower bound that RDBMSs are. Also, stored procedures are kind to your query cache people, ad hoc queries are bad for performance.