SELinux is not dependent on obscure crypto-constants. It would be very hard to place backdoors in it.
As to "complicated mess", yes, that may be true, but configuring mandatory access control right is something only for advanced levels. So the actual syntax matters not that much, what matters is what it can do. It is a bit like coding: Beginners care very much about the syntax of a language, experienced experts only care what it can do, syntax is secondary.
While I think Poettering has no clue about UNIX Architecture and philosophy and is doing work of negative impact, he is doing work and trying things. He is likely a pretty good coder, he is just no architect, and no UNIX person. And while I do not "hate" him, nothing of his stuff will ever make it onto my machines, unless he starts to get a clue.
While true, it is the (rare) exception, not the rule. For most real-world projects, the only way to speed them up is start with the best people you can get (and not the cheapest as is done to often these days) and then make sure they are not bothered by other things while they work. And, of course, use the smallest team that is still reasonable.
This actually matches what I have seen. I think this whole thing is about people with entitlement issues that think whatever great thing they do deserves unconditional respect and admiration. And when it then turns out their idea was not so smart and Linus is telling them in language that cannot be misunderstood, they look for fault with him instead of themselves. The language argument is completely bogus. In fact, when Linus rants at somebody, he is not disrespecting them, as he always gives rational reasons. Disrespecting them would be to add them silently to an ignore-list.
My take is that the SJWs and the self-proclaimed geniuses just cannot deal with running into people smarter and more experienced than them. The Linux core-team is admittedly one of the most high-powered engineering teams on the planet. And yes, there quite a few decisions they made that I do not like, but these are details in comparison to the overall achievement.
Hypervisors are a really bad idea when you have high security requirements. They increase complexity and hence, attack surface. (And they have bugs.) In addition, you still have a distro in there, so in order to be somewhat secure, you still need the jails/sandboxing/chroot.
The increased complexity also makes attacks more complex, so for lower security needs, this can work.
While I have not submitted any kernel patches, I have submitted several bug reports via the kernel bugzilla and only got feedback between neutral and very positive (from Alan Cox). I did not see any patch-proposals being attacked either. Hence, I cannot confirm any "toxicity" there.
Sure the LKML may look different, but I have quite a bit of experience with really bad proposals (one could say "dumb") cropping up again and again by people that have not bothered to find out how things actually work on the low-volume mailing-list where I am active. As it is low-volume, I am usually polite and explain things, but these people are really annoying and keep coming and sometimes they even bring really bad patches and expect them to be included immediately.
Since the Linux kernel does not only exist, but is doing fine, the LKML is very likely not often subject to "every discussion quickly devolves into name calling and profanity", negating your argument nicely for the case at hand. In general you are right of course, but these are dysfunctional groups. The one on the LKML is not one of those.
In hard-core engineering (and if the Linux kernel does no qualify, then nothing does), results are the only thing that counts. Because if you let anything else become important, then you fail. My take is that the actual engineers in kernel development do not place much importance on the language Linus and others use, but take what they mean to say as very important. Engineering on this level takes its complexity from the technical objective, a communication breakdown is not acceptable. Anybody lamenting the communications style is not actually participating or has issues meeting the level of expertise required.
And no, it is not a game of "mine is bigger". Nobody of the ones doing the heavy lifting has anything to prove there.
No, it is not. It is a filter that that is needed because lots of people ask questions without having looked into things or thought about them. In this case the effort of answering vastly outstrips the effort of asking. That is a losing game for those answering. You can do it on a low-volume mailing list (I do) and invest an hour to answer a question asked with 5 minutes of effort. You cannot do in on anything less tranquil. Hence they only take questions seriously where people have invested significant time. You see that they care not by the language used, but whether they actually address technical issues. The language used is a complete side-show and irrelevant.
1. The ones that learn from their mistakes. It takes either recognizing them yourself or being able to stand and understand criticism. 2. The ones that blame everything on others given an excuse to do so.
Type 1 learns and gets better over time. Type 2 stays incompetent. (As we are all starting out incompetent in this life. Hard to accept, but true nonetheless.)
And that is why people like you will never build something like the Linux kernel. Prioritizing secondary skills over primary ones is a sure way to stay mediocre.
Indeed. And that is excessively destructive behavior. The only reason to blast something like this into the open is "to play the victim-card" as Linus immediately remarked. The victim-card is verbal violence of the highest order and passive-aggressive to the extreme. After you have done such a thing, there are realistically only to options: Either you take over or you leave. In both cases, your role in the project is doomed, in the first case together with the project.
It does not get any more unprofessional than playing the victim-card in public.
Incidentally, I know a few female engineers and scientists and they all would have not been this unprofessional, ever. It is just a certain type of female (fortunately rare, but unfortunately loud) that abuses the available communication mechanisms in this way. The personality type also exists among males, but they know this underhanded and despicable strategy does not stand a chance, so they usually do not try it.
The real goal is power and personal dominance. Coding is just an excuse.
In quite a few of the myriad of failed IT projects that may certainly be true. But that does not express itself in the language used. I have seen people being destroyed in exquisitely polite and "professional" language. The only difference is that some of them only understood what was being said when they were shown the door a short time later. Language is only "violence" if the person it is addressed to sees it as such. There is an interpretation step in between. Also, the Linux Kernel if one of the most successful IT projects ever, so your argument is clearly not generally applicable.
The other thing you seem to be missing is that in any complex engineering project, a person seeing a serious issue _must_ get the message across. (For example, "professional" language killed those Columbia astronauts. Also refer to http://www.nytimes.com/2003/12...) Most people in subordinate positions are not very good at exercising the authority this needs. Those with these skills will usually use them, but the others must communicate effectively as well. As the "political correctness" aberration has made it excessively difficult to tell people that some things they created are broken or some ideas will not work, and made it in turn excessively easy for said people to ignore the criticism, it is better to resort to "unprofessional" language than to have a communications breakdown.
"Aggressive" language is a valid tool to generate short-term attention when needed and when no equally effective tool is available to the person that needs to produce the attention. If abused, any grown-up recipient will just adjust his/her filter for that person and it will lose its effectiveness. If used appropriately, it will continue to be effective.
Point in case: Linus will use abusive language to signal that he considers what he says important. He does not abuse this tool or nobody would be listening anymore and the Linux kernel would have never gotten anywhere. This does mean that Linus is not a master-level communicator, but he is a master-level project-builder and Unix-coder and a "good enough" communicator. Find a person that can do all three things on master level, and you could build a Linux kernel without its project leader using abusive language. Unfortunately, such people do not exist. We already only have one Linus. There are critical skills and there are "nice to have" skills when working in a technological project. Overload it in the "nice to have" class, and you will only get people that are lacking critical skills. This eventually and universally leads to a really bad outcome. I see this all the time in my line of work.
The Linux USB 3.0 host controller driver sucks. Apparently she was responsible for it. Maybe somebody else can now fix it.
Of course, those with weaker skills will always find a highly sophisticated environment "brutal". No surprise there. And yes, some people will use language that looks personal and insulting, when it is merely meant to be clear. The predecessors of the aberration that is now "political correctness" make it often difficult to do otherwise. I do however not see the problem with that. Being told, for example, that you lack the insight at this time to solve a specific problem, does not become less hurtful if expressed politely. It does need to be said though.
I said "competent human", not "human". There is a rather large difference. I also said "human in the loop", not "purely human". I am quite aware that the algorithms alone are better than humans alone and that they are critically needed to filter down the volume, but the combination of both is a lot better and currently the only way to reach a good outcome for the customer. 20 false positives per fraud caught is pretty bad. Please note that I had access to fraud data including full analysis in the past and have done risk analysis in the area.
And do not give me that "they do not know your life" nonsense. That is not even true in countries where strong privacy laws exist. Sure, that context is needed to distinguish between the different fraud cases (including fraud by the customer), but it is available. Just blocking the card immediately and without said review by a competent human being that also looks at what the customer has done in the past is quite expensive. Of course, most of the cost is on the customer side and for the bank it is cheap, especially when they also have cheap customer service and only short-term planning, so customers that leave for a different card provider do not factor into the bonuses of those that make the decisions.
The problem is, reasonable fraud detection has a competent human in the loop and that costs money. Unless we get strong AI (which is highly doubtful to ever happen), that will not change. If they remove the human, both the false positive and false negative rates surge to unacceptable levels, but the cost is paid by their customers, not by them.
Hence the source of this problem is plain, old-fashioned corporate greed. I suggest you look for a different bank to get your cards from.
To illustrate what good handling of this looks like: I was some time ago issued a new card without cost and without asking for it. The bank told me on request that my card was used with a company that may have gotten hacked and in order to make sure I do not lose its use they took that step. Now, that is what good customer service looks like. Of course, this was not a US bank.
Even if it did... how are people using ad-blockers even going to find out?
Good point. I will find out because I use several computers and not all have ad-blocking. The ones I use more rarely do not. But that is likely not the typical situation, so most people will not find out. Still a boycott. If you look at what it gave it its name, Mr. Boycott finally had to leave the country because nobody did any business with him anymore. An end to it is not necessary for a boycott. Incidentally, Mr. Boycott seems to have had business practices about as despicable and repulsive as the ad industry.
According to the actual blog-posting, the passwords are protected by bcrypt(). While they also say passwords are protected by an 2048 bit RSA-key, that is likely a mistake and refers only to credit card numbers, social security numbers and tax form information.
Still, you do never use production data on test-systems that are not specially isolated, i.e. far more so than the production systems. This will likely be one of the first thing the security firm that they have hired will tell them. Ideally, you would only test with synthetic data, but that has rather strong limits in practice. Hence you test everything with outside connectivity with synthetic data, test everything that needs real data with the machines completely isolated and hope that is enough. Of course you also make sure to be able to roll back after deployment and of course this costs more money and needs more competent engineers than just using production data on non-isolated test systems.
As usual, somebody needs to lose their job over this. I strongly recommend making it the person that _hired_ those that messed up or authorized this use of production data.
Slashdot Mirror
It is also pretty hard to hide backdoors in an access control layer. Nothing at all like using compromised constants in EC Crypto.
SELinux is not dependent on obscure crypto-constants. It would be very hard to place backdoors in it.
As to "complicated mess", yes, that may be true, but configuring mandatory access control right is something only for advanced levels. So the actual syntax matters not that much, what matters is what it can do. It is a bit like coding: Beginners care very much about the syntax of a language, experienced experts only care what it can do, syntax is secondary.
While I think Poettering has no clue about UNIX Architecture and philosophy and is doing work of negative impact, he is doing work and trying things. He is likely a pretty good coder, he is just no architect, and no UNIX person. And while I do not "hate" him, nothing of his stuff will ever make it onto my machines, unless he starts to get a clue.
Other than that, I fully agree.
While true, it is the (rare) exception, not the rule. For most real-world projects, the only way to speed them up is start with the best people you can get (and not the cheapest as is done to often these days) and then make sure they are not bothered by other things while they work. And, of course, use the smallest team that is still reasonable.
This actually matches what I have seen. I think this whole thing is about people with entitlement issues that think whatever great thing they do deserves unconditional respect and admiration. And when it then turns out their idea was not so smart and Linus is telling them in language that cannot be misunderstood, they look for fault with him instead of themselves. The language argument is completely bogus. In fact, when Linus rants at somebody, he is not disrespecting them, as he always gives rational reasons. Disrespecting them would be to add them silently to an ignore-list.
My take is that the SJWs and the self-proclaimed geniuses just cannot deal with running into people smarter and more experienced than them. The Linux core-team is admittedly one of the most high-powered engineering teams on the planet. And yes, there quite a few decisions they made that I do not like, but these are details in comparison to the overall achievement.
Only if it is actually "talent" they are "running away". So far it seems to be quite the opposite.
Hypervisors are a really bad idea when you have high security requirements. They increase complexity and hence, attack surface. (And they have bugs.) In addition, you still have a distro in there, so in order to be somewhat secure, you still need the jails/sandboxing/chroot.
The increased complexity also makes attacks more complex, so for lower security needs, this can work.
And that is your problem. These people are not "being an asshole". You have a cultural misunderstanding and are trying to force your culture on them.
And, incidentally, there is basically nothing bigger (in complexity) than the Linux kernel at this time, and not a lot that is more important.
While I have not submitted any kernel patches, I have submitted several bug reports via the kernel bugzilla and only got feedback between neutral and very positive (from Alan Cox). I did not see any patch-proposals being attacked either. Hence, I cannot confirm any "toxicity" there.
Sure the LKML may look different, but I have quite a bit of experience with really bad proposals (one could say "dumb") cropping up again and again by people that have not bothered to find out how things actually work on the low-volume mailing-list where I am active. As it is low-volume, I am usually polite and explain things, but these people are really annoying and keep coming and sometimes they even bring really bad patches and expect them to be included immediately.
Since the Linux kernel does not only exist, but is doing fine, the LKML is very likely not often subject to "every discussion quickly devolves into name calling and profanity", negating your argument nicely for the case at hand. In general you are right of course, but these are dysfunctional groups. The one on the LKML is not one of those.
In hard-core engineering (and if the Linux kernel does no qualify, then nothing does), results are the only thing that counts. Because if you let anything else become important, then you fail. My take is that the actual engineers in kernel development do not place much importance on the language Linus and others use, but take what they mean to say as very important. Engineering on this level takes its complexity from the technical objective, a communication breakdown is not acceptable. Anybody lamenting the communications style is not actually participating or has issues meeting the level of expertise required.
And no, it is not a game of "mine is bigger". Nobody of the ones doing the heavy lifting has anything to prove there.
No, it is not. It is a filter that that is needed because lots of people ask questions without having looked into things or thought about them. In this case the effort of answering vastly outstrips the effort of asking. That is a losing game for those answering. You can do it on a low-volume mailing list (I do) and invest an hour to answer a question asked with 5 minutes of effort. You cannot do in on anything less tranquil. Hence they only take questions seriously where people have invested significant time. You see that they care not by the language used, but whether they actually address technical issues. The language used is a complete side-show and irrelevant.
There are two types of human beings:
1. The ones that learn from their mistakes. It takes either recognizing them yourself or being able to stand and understand criticism.
2. The ones that blame everything on others given an excuse to do so.
Type 1 learns and gets better over time. Type 2 stays incompetent. (As we are all starting out incompetent in this life. Hard to accept, but true nonetheless.)
Power games.
The domain of those that have nothing worthwhile to contribute.
It is well known that recognizing behaviors in others is easy, while recognizing the same behaviors in one-self is very hard.
And that is why people like you will never build something like the Linux kernel. Prioritizing secondary skills over primary ones is a sure way to stay mediocre.
And put in polite language, "posting a long-winded rant about why you're leaving" is simply unprofessional.
Indeed. And that is excessively destructive behavior. The only reason to blast something like this into the open is "to play the victim-card" as Linus immediately remarked. The victim-card is verbal violence of the highest order and passive-aggressive to the extreme. After you have done such a thing, there are realistically only to options: Either you take over or you leave. In both cases, your role in the project is doomed, in the first case together with the project.
It does not get any more unprofessional than playing the victim-card in public.
Incidentally, I know a few female engineers and scientists and they all would have not been this unprofessional, ever. It is just a certain type of female (fortunately rare, but unfortunately loud) that abuses the available communication mechanisms in this way. The personality type also exists among males, but they know this underhanded and despicable strategy does not stand a chance, so they usually do not try it.
The real goal is power and personal dominance. Coding is just an excuse.
In quite a few of the myriad of failed IT projects that may certainly be true. But that does not express itself in the language used. I have seen people being destroyed in exquisitely polite and "professional" language. The only difference is that some of them only understood what was being said when they were shown the door a short time later. Language is only "violence" if the person it is addressed to sees it as such. There is an interpretation step in between. Also, the Linux Kernel if one of the most successful IT projects ever, so your argument is clearly not generally applicable.
The other thing you seem to be missing is that in any complex engineering project, a person seeing a serious issue _must_ get the message across. (For example, "professional" language killed those Columbia astronauts. Also refer to http://www.nytimes.com/2003/12...) Most people in subordinate positions are not very good at exercising the authority this needs. Those with these skills will usually use them, but the others must communicate effectively as well. As the "political correctness" aberration has made it excessively difficult to tell people that some things they created are broken or some ideas will not work, and made it in turn excessively easy for said people to ignore the criticism, it is better to resort to "unprofessional" language than to have a communications breakdown.
"Aggressive" language is a valid tool to generate short-term attention when needed and when no equally effective tool is available to the person that needs to produce the attention. If abused, any grown-up recipient will just adjust his/her filter for that person and it will lose its effectiveness. If used appropriately, it will continue to be effective.
Point in case: Linus will use abusive language to signal that he considers what he says important. He does not abuse this tool or nobody would be listening anymore and the Linux kernel would have never gotten anywhere. This does mean that Linus is not a master-level communicator, but he is a master-level project-builder and Unix-coder and a "good enough" communicator. Find a person that can do all three things on master level, and you could build a Linux kernel without its project leader using abusive language. Unfortunately, such people do not exist. We already only have one Linus. There are critical skills and there are "nice to have" skills when working in a technological project. Overload it in the "nice to have" class, and you will only get people that are lacking critical skills. This eventually and universally leads to a really bad outcome. I see this all the time in my line of work.
The Linux USB 3.0 host controller driver sucks. Apparently she was responsible for it. Maybe somebody else can now fix it.
Of course, those with weaker skills will always find a highly sophisticated environment "brutal". No surprise there. And yes, some people will use language that looks personal and insulting, when it is merely meant to be clear. The predecessors of the aberration that is now "political correctness" make it often difficult to do otherwise. I do however not see the problem with that. Being told, for example, that you lack the insight at this time to solve a specific problem, does not become less hurtful if expressed politely. It does need to be said though.
I said "competent human", not "human". There is a rather large difference. I also said "human in the loop", not "purely human". I am quite aware that the algorithms alone are better than humans alone and that they are critically needed to filter down the volume, but the combination of both is a lot better and currently the only way to reach a good outcome for the customer. 20 false positives per fraud caught is pretty bad. Please note that I had access to fraud data including full analysis in the past and have done risk analysis in the area.
And do not give me that "they do not know your life" nonsense. That is not even true in countries where strong privacy laws exist. Sure, that context is needed to distinguish between the different fraud cases (including fraud by the customer), but it is available. Just blocking the card immediately and without said review by a competent human being that also looks at what the customer has done in the past is quite expensive. Of course, most of the cost is on the customer side and for the bank it is cheap, especially when they also have cheap customer service and only short-term planning, so customers that leave for a different card provider do not factor into the bonuses of those that make the decisions.
The problem is, reasonable fraud detection has a competent human in the loop and that costs money. Unless we get strong AI (which is highly doubtful to ever happen), that will not change. If they remove the human, both the false positive and false negative rates surge to unacceptable levels, but the cost is paid by their customers, not by them.
Hence the source of this problem is plain, old-fashioned corporate greed. I suggest you look for a different bank to get your cards from.
To illustrate what good handling of this looks like: I was some time ago issued a new card without cost and without asking for it. The bank told me on request that my card was used with a company that may have gotten hacked and in order to make sure I do not lose its use they took that step. Now, that is what good customer service looks like. Of course, this was not a US bank.
Even if it did... how are people using ad-blockers even going to find out?
Good point. I will find out because I use several computers and not all have ad-blocking. The ones I use more rarely do not. But that is likely not the typical situation, so most people will not find out. Still a boycott. If you look at what it gave it its name, Mr. Boycott finally had to leave the country because nobody did any business with him anymore. An end to it is not necessary for a boycott. Incidentally, Mr. Boycott seems to have had business practices about as despicable and repulsive as the ad industry.
That can get excessively expensive. But no doubt some semi-competent wannabe "developers" are doing it this way.
According to the actual blog-posting, the passwords are protected by bcrypt(). While they also say passwords are protected by an 2048 bit RSA-key, that is likely a mistake and refers only to credit card numbers, social security numbers and tax form information.
Still, you do never use production data on test-systems that are not specially isolated, i.e. far more so than the production systems. This will likely be one of the first thing the security firm that they have hired will tell them. Ideally, you would only test with synthetic data, but that has rather strong limits in practice. Hence you test everything with outside connectivity with synthetic data, test everything that needs real data with the machines completely isolated and hope that is enough. Of course you also make sure to be able to roll back after deployment and of course this costs more money and needs more competent engineers than just using production data on non-isolated test systems.
As usual, somebody needs to lose their job over this. I strongly recommend making it the person that _hired_ those that messed up or authorized this use of production data.