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.
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.
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.
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.
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.
If I'm not pedantic my databases fail to scale. The reason being that I pay attention to detail, as such your requirement that they "handle tons of data" - for example - is crap. What are the inputs? what are the outputs? What form of query? What form is the data in on insertion/output? What if I need to do more than a single big flat index into my data?
The word "scale" is my most hated, to use that word on its own without context is to make the claim that all knowledge about building large scale computer systems acquired over the last 40 years can be boiled down to a single attribute that can be simply applied, like a salve, to your software.
Simply applying BigTable to your problems will not make them go away, it will give you a different set of problems to solve. If you chose wisely it will be a simpler set of problems, but it is not "make my website faster" cream.
NoSQL can not possibly scale, because it is not an implementation (protip: implementations scale/don't scale, concepts don't). Unless you are referring simply to the fact that it is a meme, and as such scales trivially.
BTW, when you say "scale" are you talking about data size, active data size, CPU load, memory bandwidth, latency, concurrent queries or something else?
SQL is a language used to query relational databases, by no means the only one, just the most widely supported.
Relational databases are a subset of databases.
Object persistence has nothing to do with databases. You might use a database to store and manage your serialized state, but the point where it becomes an object you can send messages to it stops being data.
The problem is when people don't think about the solution and apply the cargo cult mentality. Facebook uses Eeeerlaaaang therefore we should. Facebook wrote it's own database, therefore we should. People end up writing their own database engines that do exactly the same thing as modern relational engines, with all the bugs that were fixed in the relational engines 10 years ago (5 for Microsoft). Even MS SQL will split a large group by aggregate operation (which takes 3 lines to specify) across multiple CPUS by turning it into a map reduce problem, and it will do this all without you having to be aware of it. Oracle (and many others, Oracles is supposed to be the best) will maintain multiple concurrent versions of your data in order to allow multiple users to work with a snapshot that doesn't change under them while others are changing the data, and this happens transparently. You can go ahead and implement all this stuff yourself if you want, in C and sockets, call me when your done, in 10-20 years.
The real issue I have with the NoSQL people is they're a bunch of whiny babies, who haven't even taken the time to understand the problem before lashing out at the first thing they see. Just the name tells you this, they call themselves "No SQL" and then lash out at relational databases. SQL is is a terrible language, which really needs replacing, but it is only one possible language for querying relational databases. Relational databases represent several decades of research into how to query data in a fault tolerant scalable way as a standing implementation, re-implementing them is a waste of time.
Sounds like you don't understand sarcasm. I'll spell it out for you: Simply because Facebook are running 5 million processes is neither here nor there. The impressive thing is that it actually works (from what I hear it does any way. If it did it with one process or 5 million it has nothing to do with the relative weight of Erlang and Unix processes.
The case is not yet completed, everyone has a right to sue for libel, it's up to the court to decide whether it's justified. The key word is justified, a statement can be true and yet still libellous, for example "Simon Singh has not beaten his wife recently." The fact that the judge has ruled that Singh must prove his statement as true to the court in order to defend himself, this should be trivial for him. He just needs to present studies showing there is no benefit, he is lucky he does not have to prove he did not unfairly damage the reputation of the plaintiff. However he is publicising the case from the standpoint of having already lost, if he takes this attitude to court he will lose and set a bad precedent.
In the old days they'd just settle it like men with a duel.
There have been a few cases recently of fashion designers suing people selling goods that were legitimate goods, but were not being sold through approved vendors. Fashion designers are the kind of people who get uptight about their stuff appearing on eBay because it damages their brand. The press releases all said counterfeit goods, but that's not my definition of counterfeit. I wonder if this case was the same.
Buying support is an interesting way of saying he stops his population starving and gives them access to healthcare. It's almost as if his support comes from him doing things the majority want him to do, instead of sloganeering.
Is that not because Brasil was the country that figured out the quick work around for fingerprint based car ignition, i.e. steal the drivers fingers when you hijack the car. I mean, if a dozen children choose to mug me by ripping off all my clothes, I'd stand fairly still for fear of losing body parts. If they have guns, I'd probably give them the body parts if they asked.
Slashdot Mirror
You can patch the kernel on a running system without writing to disk. Their claims are self contradictory.
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.
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.
The laws of thermodynamics relate the incredibly complex interactions of unfathomable numbers of resonating particles to a handful of simple laws.
No, it is not.
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.
If I'm not pedantic my databases fail to scale. The reason being that I pay attention to detail, as such your requirement that they "handle tons of data" - for example - is crap. What are the inputs? what are the outputs? What form of query? What form is the data in on insertion/output? What if I need to do more than a single big flat index into my data?
The word "scale" is my most hated, to use that word on its own without context is to make the claim that all knowledge about building large scale computer systems acquired over the last 40 years can be boiled down to a single attribute that can be simply applied, like a salve, to your software.
Simply applying BigTable to your problems will not make them go away, it will give you a different set of problems to solve. If you chose wisely it will be a simpler set of problems, but it is not "make my website faster" cream.
PostgreSQL.
NoSQL can not possibly scale, because it is not an implementation (protip: implementations scale/don't scale, concepts don't). Unless you are referring simply to the fact that it is a meme, and as such scales trivially.
BTW, when you say "scale" are you talking about data size, active data size, CPU load, memory bandwidth, latency, concurrent queries or something else?
You still fail to understand the points that:
The problem is when people don't think about the solution and apply the cargo cult mentality. Facebook uses Eeeerlaaaang therefore we should. Facebook wrote it's own database, therefore we should. People end up writing their own database engines that do exactly the same thing as modern relational engines, with all the bugs that were fixed in the relational engines 10 years ago (5 for Microsoft). Even MS SQL will split a large group by aggregate operation (which takes 3 lines to specify) across multiple CPUS by turning it into a map reduce problem, and it will do this all without you having to be aware of it. Oracle (and many others, Oracles is supposed to be the best) will maintain multiple concurrent versions of your data in order to allow multiple users to work with a snapshot that doesn't change under them while others are changing the data, and this happens transparently. You can go ahead and implement all this stuff yourself if you want, in C and sockets, call me when your done, in 10-20 years.
The real issue I have with the NoSQL people is they're a bunch of whiny babies, who haven't even taken the time to understand the problem before lashing out at the first thing they see. Just the name tells you this, they call themselves "No SQL" and then lash out at relational databases. SQL is is a terrible language, which really needs replacing, but it is only one possible language for querying relational databases. Relational databases represent several decades of research into how to query data in a fault tolerant scalable way as a standing implementation, re-implementing them is a waste of time.
Sounds like you don't understand sarcasm. I'll spell it out for you: Simply because Facebook are running 5 million processes is neither here nor there. The impressive thing is that it actually works (from what I hear it does any way. If it did it with one process or 5 million it has nothing to do with the relative weight of Erlang and Unix processes.
Next up, tying your own shoelaces...
The case is not yet completed, everyone has a right to sue for libel, it's up to the court to decide whether it's justified. The key word is justified, a statement can be true and yet still libellous, for example "Simon Singh has not beaten his wife recently." The fact that the judge has ruled that Singh must prove his statement as true to the court in order to defend himself, this should be trivial for him. He just needs to present studies showing there is no benefit, he is lucky he does not have to prove he did not unfairly damage the reputation of the plaintiff. However he is publicising the case from the standpoint of having already lost, if he takes this attitude to court he will lose and set a bad precedent.
In the old days they'd just settle it like men with a duel.
There have been a few cases recently of fashion designers suing people selling goods that were legitimate goods, but were not being sold through approved vendors. Fashion designers are the kind of people who get uptight about their stuff appearing on eBay because it damages their brand. The press releases all said counterfeit goods, but that's not my definition of counterfeit. I wonder if this case was the same.
Buying support is an interesting way of saying he stops his population starving and gives them access to healthcare. It's almost as if his support comes from him doing things the majority want him to do, instead of sloganeering.
Is that not because Brasil was the country that figured out the quick work around for fingerprint based car ignition, i.e. steal the drivers fingers when you hijack the car. I mean, if a dozen children choose to mug me by ripping off all my clothes, I'd stand fairly still for fear of losing body parts. If they have guns, I'd probably give them the body parts if they asked.