i was asking about software you wrote as you are the one moaning.
Questioning someone's ability to write software or telling everyone to write a patch knowing full well they either can't, or it won't be accepted if they do, is right up Lennart's alley. Is that you Lennart?
....and I'll qualify the Windows Event Viewer comparison by saying at least I'm reasonably confident Microsoft will fix an issue or I'll find a workaround.
This will be coming, and the Linux developers will have to chip in because systemd is already compromising their ability to actually do their work. I know you, and others like you, make that kind of comment because you believe it will never happen. It will, because it will have to.
It's the opinion of anyone who has ever interacted with him, and the crew he has around him. The kernel developers at the moment are just trying to avoid that lot. Soon they won't be able to. Passive aggressive, corrosive, unresponsive to any problem that looks serious and when they do respond it's a problem somewhere else or it's waved away with a completely non-sensical response.
Yer, Wait until we get bugs like that within systemd. "Nothing we need to fix". "This is something the kernel needs to fix". etc. etc. That's been the consistent pattern.
Fucking hell. The whole point of plain text logs, readable by standard tools, is that you can always find out what happened and if you run this on a server it is of vital importance. Anyone with half a brain cell of intelligence knows that giving that up in favour of a binary logging system knows this is a risk, therefore it needs to be investigated and fixed when it occurs. Developers have to be more interested than 'nothing we really need to fix hence'.
Let me tell you I do not want to have to deal with that shit at some ungodly hour. This is Windows Event Viewer crap.
The ignored the whole debug/Linux kernel incompatibility until they were called out as the passive aggressive crew they are and somebody else had to go in and fix their shit while they stayed silent. This behaviour in any open source project would be corrosive, but in something that is supposedly trying to be a central part of an OS that is downright worrying. The developers have to be responsive and we haven't seen them have to deal with a major security problem yet.
You know that as well as the rest of us so stop trying to deny it please.
If Poettering wasn't passive aggressive and incredibly difficult, as described by the Linux kernel developers, then this kind of thing might happen less.
I love the wailing that RDBMS fanboys make when anyone mentions NoSQL. Most of it is downright wrong, but the sound is nice.
I also love the uncomfortable bum shuffling that NoSQL fanboys do when they have to tell people they've lost data and all those corner cases they said were unlikely to happen.....well, they kind of have happened. It's also amusing to see people labelled as 'RDBMS fanboys' considering that relational database systems have worked very well for decades.
Sure you can. You can do that and get useful gains. Your imagination may be too limited to understand it, but it's perfectly possible out here in the real world.
Yes, you can get gains. Just don't expect your data to be there in the event of a failure, which is exactly what a system to handle data is supposed to prevent. You generally also get the "That data isn't critical" and a whole list of exceptions from these twats as to how it's all acceptable, but if it's one thing I've learned it's that the risk of data loss is only a problem once it happens and then you get a request for "We'd like a report on all X historical data for Y occurrences". Queue uncomfortable bum shuffling. That's before I've even got to the ludicrous twilight zone consistency problems that can arise.
It's a distributed database. They don't need the data to be consistent across every node on every write; "eventually consistent" is fine provided that they know the write has reached at least n+1 nodes, and modern NoSQL databases can do just that.
Ahhhh, yes, here we go. The corner cases that cannot happen. I could turn off fsync and do a great deal of things with relational database systems that would easily equal or surpass any write performance that a NoSQL system has. You know why I don't do that? Because it's fucking stupid, that's why.
I also love the implicit suggestion that performing an effective query on any large normalised relational dataset is easy, by the way.
Let me see. A language and data structure built for constructing queries, with an established process of refining data through normal forms, or a free-for-all using JavaScript or whatever other language a web developer monkey who is now apparently a database developer pulls out of his arse. Tough choice.
Look, we get it: you've invested a lot of time and effort into becoming an Oracle developer
Where did he say he was an Oracle developer?
...and yes your skills are now under attack by something that's totally foreign to you, but perhaps you could try learning about those new things and extending your knowledge base instead of dismissing them an hoping they'll go away.
Alas, SQL skills are not under attack at all no matter how you'd desperately like to believe in your own fantasy world that they are. The reason why those experienced amongst us get animated about this NoSQL diarrhoea is because companies and organisations get burned by it. Badly. It's a concept put together by a bunch of utterly ignorant and moronic web developers who believe they are now database developers, can throw away the lessons learned over the past several decades about how data is treated and can throw away that computer science learning they were too stupid to pick up.
It'll make you more employable and you'll look like less of a petulant child, all at the same time.
In general, because of communication delays, the banking system depends not on consistency for correctness, but rather on auditing and compensation. Another example of this is "check kiting," in which a customer withdraws money from multiple branches before they can communicate and then flees. The overdraft will be caught later, perhaps leading to compensation in the form of legal action.
You can claim Eric Brewer is a fucking idiot as much as you want. Eventually all you will do is destroy your own credibility.
You're misunderstanding what's been written in that article. This is exactly the scenario that banks *have* to prevent before and as it happens. Chasing around for compensation later cannot be an option in many cases because it is going to be abused. It could happen in the case that a bank branch loses connectivity and they have to work manually, but this is a very rare exception and not the rule, and in that scenario many bank branches simply won't process certain types of transactions. Whatever system you use locally will be checked live, usually with a mainframe based system that is ACID compliant. If that isn't possible then you have a gradual system degradation where only certain types of transactions are processed. Simply relying on an audit trail to piece things together is the exception you don't want rather than how things work, but of course, you'd better hope that audit trail is consistent;-).
I know because I've been there in a bank and these corner cases are what you have to account for and deal with. This attitude is what made the Mt Gox Bitcoin exchange a laughing stock, amongst others. The article is not a carte blanche to justify NoSQL systems or to do away with any core systems that compromise ACID at their heart. Indeed, that's what they have to fall back to.
The opposite of ACIDis BASE where the "E" stands for eventual consistency. The beauty of this is that it DOES NOT lose completed transactions and at the same time it allows for high availability.
I'm awaiting the rest of the comment with a mixture of trepidation and mild amusement......
In many industries, including banking, eventual consistency plus high availability (NoSQL) is preferable to strict consistency plus lower availability (RDBMS). Of course there are many other factors involved in selecting a database architecture.
No. Creating corner cases like this is what all the NoSQL nutters do, and certainly what they've had to do in recent years when it's become painfully apparent that if you start mucking about with data consistency in any way and telling people things don't matter you WILL get burned.
Acquainting a traditional RDBMS with a phrase like 'lower availability' just highlights to kind of twilight zone you start getting into when talking to any of the NoSQL crowd.
It is true that "show balance" does not strictly commute with deposits and withdrawals but: a) this does not cause the system to lose track of your money, and b) no one expects it to strictly commute.
You didn't work on Mt Gox's systems at any point did you?
Banking transactions are generally backed up by large mainframes, SQL databases and infrastructure that most certainly are ACID compliant so people like you can play idiotic games with NoSQL and then act as if nothing happened when you lose data.
Rackspace has been living a charmed life for quite some time. The thorny issue of making money rears its head though and people just aren't going for the completely uneconomical prices that Rackspace charges.
Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
I'm afraid you're just trying to cloud the systemd nonsense with nonsense of your own, which is a classic tactic of the passive aggressive way in which the systemd crew deal with things.
You don't have to use journald - that is the point. Or at least you can set it to non-persistant storage so it doesn't exist outside of/run, and the only logs you look at after a reboot are the ones stored by your syslog.
I don't understand what this is supposed to mean. They are an integrated whole. You can't just swap out for syslog otherwise you'll face a heck of a lot of corner cases.
The newspaper reports that about 80% of all Munich city workers use LiMux at the office, and that, according to Schmid, many of those workers are “suffering.”
So after well over ten years they've now just discovered that users are suffering? Microsoft are moving their headquarters to Munich? Pull the other one.
Slashdot Mirror
i was asking about software you wrote as you are the one moaning.
Questioning someone's ability to write software or telling everyone to write a patch knowing full well they either can't, or it won't be accepted if they do, is right up Lennart's alley. Is that you Lennart?
Troll? For pointing out that networkmanager, pulseaudio and systemd actually work?
You sound surprised. However, they all still have longstanding problems which their developers have a long history of passing off.
....and I'll qualify the Windows Event Viewer comparison by saying at least I'm reasonably confident Microsoft will fix an issue or I'll find a workaround.
This will be coming, and the Linux developers will have to chip in because systemd is already compromising their ability to actually do their work. I know you, and others like you, make that kind of comment because you believe it will never happen. It will, because it will have to.
I mean, some of us are legally required to keep logs. Look at that piece of meaningless crap Lennart posts as a final response to this.
Posted as AC? Check. Comment blames crazy user? Check. Is that you Lennart?
Considering that it's posted under AC I'd say that's affirmative.
It's the opinion of anyone who has ever interacted with him, and the crew he has around him. The kernel developers at the moment are just trying to avoid that lot. Soon they won't be able to. Passive aggressive, corrosive, unresponsive to any problem that looks serious and when they do respond it's a problem somewhere else or it's waved away with a completely non-sensical response.
Part of the same crew and culture I'm afraid.
Yer, Wait until we get bugs like that within systemd. "Nothing we need to fix". "This is something the kernel needs to fix". etc. etc. That's been the consistent pattern.
Fucking hell. The whole point of plain text logs, readable by standard tools, is that you can always find out what happened and if you run this on a server it is of vital importance. Anyone with half a brain cell of intelligence knows that giving that up in favour of a binary logging system knows this is a risk, therefore it needs to be investigated and fixed when it occurs. Developers have to be more interested than 'nothing we really need to fix hence'.
Let me tell you I do not want to have to deal with that shit at some ungodly hour. This is Windows Event Viewer crap.
The ignored the whole debug/Linux kernel incompatibility until they were called out as the passive aggressive crew they are and somebody else had to go in and fix their shit while they stayed silent. This behaviour in any open source project would be corrosive, but in something that is supposedly trying to be a central part of an OS that is downright worrying. The developers have to be responsive and we haven't seen them have to deal with a major security problem yet.
You know that as well as the rest of us so stop trying to deny it please.
If Poettering wasn't passive aggressive and incredibly difficult, as described by the Linux kernel developers, then this kind of thing might happen less.
Ukraine? Ahhh, you mean the western initiated coup that put a bunch of ultra right-wing Nazis into power?
I love the wailing that RDBMS fanboys make when anyone mentions NoSQL. Most of it is downright wrong, but the sound is nice.
I also love the uncomfortable bum shuffling that NoSQL fanboys do when they have to tell people they've lost data and all those corner cases they said were unlikely to happen.....well, they kind of have happened. It's also amusing to see people labelled as 'RDBMS fanboys' considering that relational database systems have worked very well for decades.
Sure you can. You can do that and get useful gains. Your imagination may be too limited to understand it, but it's perfectly possible out here in the real world.
Yes, you can get gains. Just don't expect your data to be there in the event of a failure, which is exactly what a system to handle data is supposed to prevent. You generally also get the "That data isn't critical" and a whole list of exceptions from these twats as to how it's all acceptable, but if it's one thing I've learned it's that the risk of data loss is only a problem once it happens and then you get a request for "We'd like a report on all X historical data for Y occurrences". Queue uncomfortable bum shuffling. That's before I've even got to the ludicrous twilight zone consistency problems that can arise.
It's a distributed database. They don't need the data to be consistent across every node on every write; "eventually consistent" is fine provided that they know the write has reached at least n+1 nodes, and modern NoSQL databases can do just that.
Ahhhh, yes, here we go. The corner cases that cannot happen. I could turn off fsync and do a great deal of things with relational database systems that would easily equal or surpass any write performance that a NoSQL system has. You know why I don't do that? Because it's fucking stupid, that's why.
I also love the implicit suggestion that performing an effective query on any large normalised relational dataset is easy, by the way.
Let me see. A language and data structure built for constructing queries, with an established process of refining data through normal forms, or a free-for-all using JavaScript or whatever other language a web developer monkey who is now apparently a database developer pulls out of his arse. Tough choice.
Look, we get it: you've invested a lot of time and effort into becoming an Oracle developer
Where did he say he was an Oracle developer?
...and yes your skills are now under attack by something that's totally foreign to you, but perhaps you could try learning about those new things and extending your knowledge base instead of dismissing them an hoping they'll go away.
Alas, SQL skills are not under attack at all no matter how you'd desperately like to believe in your own fantasy world that they are. The reason why those experienced amongst us get animated about this NoSQL diarrhoea is because companies and organisations get burned by it. Badly. It's a concept put together by a bunch of utterly ignorant and moronic web developers who believe they are now database developers, can throw away the lessons learned over the past several decades about how data is treated and can throw away that computer science learning they were too stupid to pick up.
It'll make you more employable and you'll look like less of a petulant child, all at the same time.
I've just ruptured my spleen. Thanks.
Again we could get infinite scalability with Cassandra for free.
Jesus Christ......
In general, because of communication delays, the banking system depends not on consistency for correctness, but rather on auditing and compensation. Another example of this is "check kiting," in which a customer withdraws money from multiple branches before they can communicate and then flees. The overdraft will be caught later, perhaps leading to compensation in the form of legal action.
You can claim Eric Brewer is a fucking idiot as much as you want. Eventually all you will do is destroy your own credibility.
You're misunderstanding what's been written in that article. This is exactly the scenario that banks *have* to prevent before and as it happens. Chasing around for compensation later cannot be an option in many cases because it is going to be abused. It could happen in the case that a bank branch loses connectivity and they have to work manually, but this is a very rare exception and not the rule, and in that scenario many bank branches simply won't process certain types of transactions. Whatever system you use locally will be checked live, usually with a mainframe based system that is ACID compliant. If that isn't possible then you have a gradual system degradation where only certain types of transactions are processed. Simply relying on an audit trail to piece things together is the exception you don't want rather than how things work, but of course, you'd better hope that audit trail is consistent ;-).
I know because I've been there in a bank and these corner cases are what you have to account for and deal with. This attitude is what made the Mt Gox Bitcoin exchange a laughing stock, amongst others. The article is not a carte blanche to justify NoSQL systems or to do away with any core systems that compromise ACID at their heart. Indeed, that's what they have to fall back to.
The opposite of ACIDis BASE where the "E" stands for eventual consistency. The beauty of this is that it DOES NOT lose completed transactions and at the same time it allows for high availability.
I'm awaiting the rest of the comment with a mixture of trepidation and mild amusement......
In many industries, including banking, eventual consistency plus high availability (NoSQL) is preferable to strict consistency plus lower availability (RDBMS). Of course there are many other factors involved in selecting a database architecture.
No. Creating corner cases like this is what all the NoSQL nutters do, and certainly what they've had to do in recent years when it's become painfully apparent that if you start mucking about with data consistency in any way and telling people things don't matter you WILL get burned.
Acquainting a traditional RDBMS with a phrase like 'lower availability' just highlights to kind of twilight zone you start getting into when talking to any of the NoSQL crowd.
It is true that "show balance" does not strictly commute with deposits and withdrawals but: a) this does not cause the system to lose track of your money, and b) no one expects it to strictly commute.
You didn't work on Mt Gox's systems at any point did you?
Banking transactions are generally backed up by large mainframes, SQL databases and infrastructure that most certainly are ACID compliant so people like you can play idiotic games with NoSQL and then act as if nothing happened when you lose data.
Rackspace has been living a charmed life for quite some time. The thorny issue of making money rears its head though and people just aren't going for the completely uneconomical prices that Rackspace charges.
No. It just means that banks are looking for ways in which they can manipulate them.
Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
I'm afraid you're just trying to cloud the systemd nonsense with nonsense of your own, which is a classic tactic of the passive aggressive way in which the systemd crew deal with things.
Or maybe having to run ejabberd as root, because it simply wants to bind to a 1024 port?
Are you really that fucking retarded?
You don't have to use journald - that is the point. Or at least you can set it to non-persistant storage so it doesn't exist outside of /run, and the only logs you look at after a reboot are the ones stored by your syslog.
I don't understand what this is supposed to mean. They are an integrated whole. You can't just swap out for syslog otherwise you'll face a heck of a lot of corner cases.
The newspaper reports that about 80% of all Munich city workers use LiMux at the office, and that, according to Schmid, many of those workers are “suffering.”
So after well over ten years they've now just discovered that users are suffering? Microsoft are moving their headquarters to Munich? Pull the other one.
Incomplete sentence...... .....but then Israel and Jewish people tend to frame things in that manner.