This has to be the biggest piece of Apple adulation that I've ever seen. A practice of flattery over everything Apple do is always superabundant in most of the output of the American tech press: we're used, for instance, to the reviewers' pirouettes when they first dismiss some bad choice by Apple as irrelevant, and then they have to praise the reversal of that choice as the best thing after sliced bread in some later version of an Apple product.
But in this case, well, Apple does something wrong (not even remotely comparable to the trainwreck that Microsoft did with Metro, I'll concede) that devalues the largest part of its already expensive product line, with the exception of the most expensive products, and without adding any value to those either, but Apple fan are happy nonetheless because... it's good to be shown how Apple does not care about who doesn't spend the most?
What is this, an exercise of asceticism in the path of the true Apple worship?
From reading the linked discussion (before people started having shitfits), a dev suggested removing extFS support as "an unnecessary feature"
A dev announced that extFS support had been removed in beta. To people protesting, they replied that the feature was going away full stop. They even modified the ChromeOS feature page stating that ChromeOS had ext support.
because of theoretical security issues
Because of FUD. Stating that supporting the ext file system poses a security issue is FUD: it is FUD by definition, and it is FUD in particular because ext is massively used in security-critical contexts including Google's servers and Google's Android operating system. Why, ext4's key developer is a Google employee IIRC!
and because it interfered with implementing file system renaming (which looks to be surprisingly tricky to do right).
Because they didn't want to implement the few lines of code supposed to invoke the already existing facilities that set the file system label. A thing that, for tricky that it may be, was done right by the Commodore 64's 1541 floppy drive OS, by MS-DOS, by all versions of Windows, by all Linux-based desktops, by AmigaDOS, by OSX, and probably most existing operating system.
In no time at all, objections were posted, some of them rather aggressive in tone.
One of the last comments before disallowing further comments was that they were looking into keeping extFS support, but throwing an error message if you try to rename an extFS volume, and possibly implementing extFS support in userspace for security reasons.
After the slashdot story was published, after my comment was written, when more and more people started stating, most of them politely, that removing ext support would make ChromeOS unsuitable for their work, and that they were upset because there was no credible explanation for the removal of the feature, only after that developers stopped ignoring their discontent and decided to leave ext support in for the time being, but still without writing the code required to alter the filesystem label.
All of this seems quite reasonable when considering what ChromeOS is and its usual usecase.
And when did I say otherwise? I even said the same thing in another comment.
Open Source != GPLv3. People can write all the code that they like but unless Google want to, their chances of actually seeing that code running on Chromebooks is zero. In this case, Google have already decided that the feature (which is already there) has to go, because simplicity.
Buy a real laptop if you want to do whatever you want with it. If you buy (?) a locked-down device, which is controlled by a remote commercial entity and not by you, then don't act surprised when they don't support some use case of yours which doesn't help them make money.
DRM in HTML will “break the internet” too, and you pushed for it. Surveillance sucks whether the data is gathered by a hostile government or by a friendly commercial entity.
In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash.
Even if this is true, and no I haven't checked it, it has no relevance over the reality of how many people are effectively using Bash together with the Linux kernel, which is a matter of which distributions people effectively use. I do aknowledge that RedHat-derived distributions are probably more common on servers, but I'm just guessing that out of prejudice.
Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell,
If you really had a server of any kind which spawned a *real user login shell* as a result of a remote client request of any kind, then you would already have a huge security problem.
Moreover, I expect lots of people will use Bash as their persoanl shell even on BSDs as it's so much better than Tcsh.
and many scripts specify #!/bin/bash in their shebang line.
Then they are as broken on FreeBSD (or any other OS) as well as they are on Linux distributions that haven't Bash as the system shell.
That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock.
How so? The bug is triggered when you start a buggy Bash shell having a malicious environment variable set up by the parent. Having Bash itself as a parent isn't a problem, because the bug is triggered when the environment is parsed at Bash's startup time (the shell might even crash afterwards).
The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.
The karma bonus is there as a measure to let *you* moderate your own comments. If you consider 2,000 characters of condescendension as something that is worth promoting, good for you, but don't expect other readers to share your conviction.
Now you just have to find some server package which allows an unnprivileged remote client to trigger the execution of a Zimbra init script.
The funny thing is that, should you find it, such package would be vulnerable on FreeBSD in the exactly same way as it were on Linux, nullifying the argument that you are trying to make, about the Bash bug being a "Linux bug" that FreeBSD users shouldn't worry about.
Please tell us all how many Linux-based systems you operate that run only a bare kernel.
In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.
and the Karma Bonus
Who cares about that?
You should. Its purpose is to override other people's posts when you have something important to say.
Wrong. It's not personal, really.
[...]
You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation.
Plonk.
That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.
Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.
Which is not to say that this bug isn't serious, because it's huge. It's to say that this is not a "Linux bug", in any possible meaning of the phrase, strict or lax.
Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running.
You fail to appreciate the difference between Linux and Bash (there's Linux with no Bash, there's Bash with no Linux). You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell. And yet you invest almost two thousand letters, and the Karma Bonus, doing the condescendent and attacking me personally. If you were trying to appear funny, in my opinion, you aren't. If you were trying to appear smart, then you had better get your facts right before attempting to.
Debian doesn't. Ubuntu doesn't. Anything embedded doesn't. OSX does. There's nothing to "laugh at Linux" for, because even leaving aside the fact, as huge as a house, that this is not a bug of Linux, we must take into account that Bash isn't used on all Linux distributions, is used on many non-Linux unices, and can be installed on non-Unix systems where it'll see environment variables too.
I also register with amusement the fact that OSX gets pulled by the coat into the BSD family when it's time to calculate market share, but is carefully set aside now that the distinction is convenient.
I'm correct. Linux has no concept of a "default shell", being an operating system kernel, and its security wrt this bug is the same as FreeBSD or OSX. That is, it's completely orthogonal, contrary to what the post I was responding to was implying.
Don't present userspace drivers as a panacea for all kinds of driver troubles: when a driver fails, it can make the hardware it drives hang your machine solid from the hardware's side, or make said hardware DMA all over your RAM with complete disregard any CPU-imposed protection; there's no safe recovery from such a situation, and in this case applications had better be stopped even if they appear to be still running.
That there is no inconsistence in Java between classes for which supposedly you can get away with == and classes which require you to use equals(), as was suggested in the post I was replying to.
Please read the post I was replying to, it was claiming that checking for object value equality using == sometimes works. That's what doesn't work, and rightfully so. Sorry if it wasn't clear, but unfortunately I'm using the mobile site and I can't find the "quote parent" option.
No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and it "works" with compiler-generated structures in the same way as comparing C strings with == instead of strcmp() may happen to "work", or comparing C arrays using > may happen to "work". The difference between a value and a reference is a very basic concept of programming, and in the case of Java it's explained very early in learning courses. If anything, languages that allow complexity-hiding features such as the overloading of == are much better puzzler-generators than the simple, elegant, plain Java. Which didn't even have autoboxing originally.
Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:
- Comparing two "int" variables, you use ==
- Comparing two Integer variables, you probably want.equals()
Comparing *any* object, you want to use equals(), there's no "probably".
- But it is possible to have two different Integer objects with the same value - this is when you wand ==
No, you don't. Comparing two Integer objects, as any other object, with ==, will compare the two references to the object in order to determine if they point to the same object. The object contents won't be looked at. This is simple to learn and teach, and elegant as a design. I find no ugliness whatsoever in this.
- But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127
Although you didn't mention it, you are thinking about autoboxing. Java makes efficient use of memory and, by using == to test object identity instead of equals() you can detect this optimization. This can't influence any working code (because comparing the results of.equals() and == makes no logical sense) and certainly isn't confusing.
A more advanced example are the generics that disappear when the code is compiled. I understand the arguments for doing it this way, but I disagree with them - if you have generics, you ought to be able to query the types at run-time. There are lots and lots of highly questionable design decisions - basically, 20 years of backwards compatibility.
It's past time to clean house. Building a new language on top of the established JVM technology seems like a very good idea indeed. Perhaps Scala can fulfill this role...
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.
So when, precisely, in your opinion did the Italian Republic become "fascist," or "military-controlled"?
To sum it up in poor words, the point of Gladio was to replace a left-wing government with a fascist one. This was never needed however, because the Italians were good boys and never elected a left-wing government. This notwithstanding, the Italian military secret service supported right-wing terrorism with money, weapons and judiciary protection.
The people who created Gladio were Italians elected by their countryman. They preferred a world where their country had a secret, Anti-Soviet Army directed partially by the CIA to one where it didn't. When those countrymen realized it was acting up they disbanded it.
Those countrymen were never aware of such activities, precisely because they were kept secret. In those cases when they become aware of them, the few persons identified as responsible for them had to spend the rest of their lives in South America or Africa to flee from Italian justice.
As for "terrorism-ridden," Italy has never had a year in which Gladio bombings made up the majority of terror attacks. There were leftists, and other Fascists active in the same period. Most of the time Gladio was third, behind the various leftists, and the Ordine Nuovo Fascists.
If we want to be precise, no bombing (or targeted murder) was ever set up by "Gladio". They were carried out by right-wing terrorists that were sponsored by "deviated" Italian secret services. But frankly, counting the victims of the "red" terror versus the ones of the "black" terror seems silly to me (others have done it, and in case you're interested, it's "a draw"). I can assure you that I despise the KGB-sponsored killings as much as the CIA ones. The point of this discussion was that the USA's only interest was a peaceful and boring Europe, and in my opinion terrorism is incompatible with peace and boredom.
In fact I think if you consult a dictionary, you'll note that "military control" is generally considered the opposite of having terrorists run around your country, so that Italy in the 70s and 80s was suffering from a distinct lack of military control.
Military control would have been an option of last resort, and it was never put in place. However, in certain times we got pretty close to that. It's not surprising, as the rest of southern Europe was not democratic until the 70s, and something like that went on in America's backyard.
It was an emanation of the government of the United States of America, which, as we've already discussed here, is an expression of the private corporations that pay the politicians it's made up of.
It was an anti-soviet guerilla-prep program run by NATO in every country in Europe, wherein later a few groups got infiltrated by right-wingers who tried to use their power in immoral manners.
It wasn't anti-soviet. It was anti-democratic-countries-of-europe should one of them elect a government that wasn't appreciated by the USA. In this aspect, it was very soviet-like if anything.
About the "right-wingers", I don't know if "immoral manners" is the label that best describes turning hundreds of innocent people into jumbled meat, and then derailing the investigations with the support of the local secret services (very tangible stuff, both the bombs and the evidence that emerged during countless investigations, not conspiracy theory).
But that doesn't stop a particlar brand of conspiracy theorist from crediting to Gladio everything under the sun.
Eh, that's what happens when you set up secret organizations to subvert the democratic order of foreign states and end up supporting and funding terrorism. As a side effect, when you get busted, people tend to lose the faith in you.
Your government wants Europe to meet the interests of the companies that rule your country. Whether that means a peaceful, stable, boring place or a fascist, military-controlled, or terrorism-ridden state is of secondary importance.
Slashdot Mirror
make money != be the Government
But in this case, well, Apple does something wrong (not even remotely comparable to the trainwreck that Microsoft did with Metro, I'll concede) that devalues the largest part of its already expensive product line, with the exception of the most expensive products, and without adding any value to those either, but Apple fan are happy nonetheless because... it's good to be shown how Apple does not care about who doesn't spend the most?
What is this, an exercise of asceticism in the path of the true Apple worship?
From reading the linked discussion (before people started having shitfits), a dev suggested removing extFS support as "an unnecessary feature"
A dev announced that extFS support had been removed in beta. To people protesting, they replied that the feature was going away full stop. They even modified the ChromeOS feature page stating that ChromeOS had ext support.
because of theoretical security issues
Because of FUD. Stating that supporting the ext file system poses a security issue is FUD: it is FUD by definition, and it is FUD in particular because ext is massively used in security-critical contexts including Google's servers and Google's Android operating system. Why, ext4's key developer is a Google employee IIRC!
and because it interfered with implementing file system renaming (which looks to be surprisingly tricky to do right).
Because they didn't want to implement the few lines of code supposed to invoke the already existing facilities that set the file system label. A thing that, for tricky that it may be, was done right by the Commodore 64's 1541 floppy drive OS, by MS-DOS, by all versions of Windows, by all Linux-based desktops, by AmigaDOS, by OSX, and probably most existing operating system.
In no time at all, objections were posted, some of them rather aggressive in tone.
One of the last comments before disallowing further comments was that they were looking into keeping extFS support, but throwing an error message if you try to rename an extFS volume, and possibly implementing extFS support in userspace for security reasons.
After the slashdot story was published, after my comment was written, when more and more people started stating, most of them politely, that removing ext support would make ChromeOS unsuitable for their work, and that they were upset because there was no credible explanation for the removal of the feature, only after that developers stopped ignoring their discontent and decided to leave ext support in for the time being, but still without writing the code required to alter the filesystem label.
All of this seems quite reasonable when considering what ChromeOS is and its usual usecase.
And when did I say otherwise? I even said the same thing in another comment.
Open Source != GPLv3. People can write all the code that they like but unless Google want to, their chances of actually seeing that code running on Chromebooks is zero. In this case, Google have already decided that the feature (which is already there) has to go, because simplicity.
Buy a real laptop if you want to do whatever you want with it. If you buy (?) a locked-down device, which is controlled by a remote commercial entity and not by you, then don't act surprised when they don't support some use case of yours which doesn't help them make money.
DRM in HTML will “break the internet” too, and you pushed for it. Surveillance sucks whether the data is gathered by a hostile government or by a friendly commercial entity.
In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash.
Even if this is true, and no I haven't checked it, it has no relevance over the reality of how many people are effectively using Bash together with the Linux kernel, which is a matter of which distributions people effectively use. I do aknowledge that RedHat-derived distributions are probably more common on servers, but I'm just guessing that out of prejudice.
Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell,
If you really had a server of any kind which spawned a *real user login shell* as a result of a remote client request of any kind, then you would already have a huge security problem. Moreover, I expect lots of people will use Bash as their persoanl shell even on BSDs as it's so much better than Tcsh.
and many scripts specify #!/bin/bash in their shebang line.
Then they are as broken on FreeBSD (or any other OS) as well as they are on Linux distributions that haven't Bash as the system shell.
That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock.
How so? The bug is triggered when you start a buggy Bash shell having a malicious environment variable set up by the parent. Having Bash itself as a parent isn't a problem, because the bug is triggered when the environment is parsed at Bash's startup time (the shell might even crash afterwards).
The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.
The karma bonus is there as a measure to let *you* moderate your own comments. If you consider 2,000 characters of condescendension as something that is worth promoting, good for you, but don't expect other readers to share your conviction.
The funny thing is that, should you find it, such package would be vulnerable on FreeBSD in the exactly same way as it were on Linux, nullifying the argument that you are trying to make, about the Bash bug being a "Linux bug" that FreeBSD users shouldn't worry about.
I have never seen this even by the BSD folks. I think you are delusional.
Look at the comments of every slashdot story about some BSD, when the topic of market share comes out.
I won't post links to individual comments here, because I would find it both rude and pedantic.
For most users OSX will have no exposure even though it has the vulnerable Bash.
It depends on wether /bin/sh points to bash on OSX.
It does not use dhclient nor does it use a shell for processing DHCP, instead it uses the ipconfig agent.
Not to mention the fact that if people are connecting their machines to rogue DHCP servers, they're compromised anyway.
Sharing is disabled by default and this includes SSH. Only folks that explicitly run remote services or use the Server product will be exposed.
It's not that the typical Linux distribution opens telnet to the world by default, either.
Please tell us all how many Linux-based systems you operate that run only a bare kernel.
In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.
and the Karma Bonus
Who cares about that?
You should. Its purpose is to override other people's posts when you have something important to say.
Wrong. It's not personal, really.
[...]
You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation.
Plonk.
That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.
Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.
Which is not to say that this bug isn't serious, because it's huge. It's to say that this is not a "Linux bug", in any possible meaning of the phrase, strict or lax.
Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running.
ls -l /bin/sh , that's what your scripts are going to use. It should be dash.
You fail to appreciate the difference between Linux and Bash (there's Linux with no Bash, there's Bash with no Linux). You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell. And yet you invest almost two thousand letters, and the Karma Bonus, doing the condescendent and attacking me personally. If you were trying to appear funny, in my opinion, you aren't. If you were trying to appear smart, then you had better get your facts right before attempting to.
Debian doesn't. Ubuntu doesn't. Anything embedded doesn't. OSX does. There's nothing to "laugh at Linux" for, because even leaving aside the fact, as huge as a house, that this is not a bug of Linux, we must take into account that Bash isn't used on all Linux distributions, is used on many non-Linux unices, and can be installed on non-Unix systems where it'll see environment variables too. I also register with amusement the fact that OSX gets pulled by the coat into the BSD family when it's time to calculate market share, but is carefully set aside now that the distinction is convenient.
I'm correct. Linux has no concept of a "default shell", being an operating system kernel, and its security wrt this bug is the same as FreeBSD or OSX. That is, it's completely orthogonal, contrary to what the post I was responding to was implying.
FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.
Don't present userspace drivers as a panacea for all kinds of driver troubles: when a driver fails, it can make the hardware it drives hang your machine solid from the hardware's side, or make said hardware DMA all over your RAM with complete disregard any CPU-imposed protection; there's no safe recovery from such a situation, and in this case applications had better be stopped even if they appear to be still running.
That there is no inconsistence in Java between classes for which supposedly you can get away with == and classes which require you to use equals(), as was suggested in the post I was replying to.
It's needed, among other things, to write basic code such as if (source == cancelButton) { ... }
Please read the post I was replying to, it was claiming that checking for object value equality using == sometimes works. That's what doesn't work, and rightfully so. Sorry if it wasn't clear, but unfortunately I'm using the mobile site and I can't find the "quote parent" option.
No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and it "works" with compiler-generated structures in the same way as comparing C strings with == instead of strcmp() may happen to "work", or comparing C arrays using > may happen to "work". The difference between a value and a reference is a very basic concept of programming, and in the case of Java it's explained very early in learning courses. If anything, languages that allow complexity-hiding features such as the overloading of == are much better puzzler-generators than the simple, elegant, plain Java. Which didn't even have autoboxing originally.
Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:
- Comparing two "int" variables, you use == - Comparing two Integer variables, you probably want .equals()
Comparing *any* object, you want to use equals(), there's no "probably".
- But it is possible to have two different Integer objects with the same value - this is when you wand ==
No, you don't. Comparing two Integer objects, as any other object, with ==, will compare the two references to the object in order to determine if they point to the same object. The object contents won't be looked at. This is simple to learn and teach, and elegant as a design. I find no ugliness whatsoever in this.
- But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127
Although you didn't mention it, you are thinking about autoboxing. Java makes efficient use of memory and, by using == to test object identity instead of equals() you can detect this optimization. This can't influence any working code (because comparing the results of .equals() and == makes no logical sense) and certainly isn't confusing.
A more advanced example are the generics that disappear when the code is compiled. I understand the arguments for doing it this way, but I disagree with them - if you have generics, you ought to be able to query the types at run-time. There are lots and lots of highly questionable design decisions - basically, 20 years of backwards compatibility.
It's past time to clean house. Building a new language on top of the established JVM technology seems like a very good idea indeed. Perhaps Scala can fulfill this role...
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.
So when, precisely, in your opinion did the Italian Republic become "fascist," or "military-controlled"?
To sum it up in poor words, the point of Gladio was to replace a left-wing government with a fascist one. This was never needed however, because the Italians were good boys and never elected a left-wing government. This notwithstanding, the Italian military secret service supported right-wing terrorism with money, weapons and judiciary protection.
The people who created Gladio were Italians elected by their countryman. They preferred a world where their country had a secret, Anti-Soviet Army directed partially by the CIA to one where it didn't. When those countrymen realized it was acting up they disbanded it.
Those countrymen were never aware of such activities, precisely because they were kept secret. In those cases when they become aware of them, the few persons identified as responsible for them had to spend the rest of their lives in South America or Africa to flee from Italian justice.
As for "terrorism-ridden," Italy has never had a year in which Gladio bombings made up the majority of terror attacks. There were leftists, and other Fascists active in the same period. Most of the time Gladio was third, behind the various leftists, and the Ordine Nuovo Fascists.
If we want to be precise, no bombing (or targeted murder) was ever set up by "Gladio". They were carried out by right-wing terrorists that were sponsored by "deviated" Italian secret services. But frankly, counting the victims of the "red" terror versus the ones of the "black" terror seems silly to me (others have done it, and in case you're interested, it's "a draw"). I can assure you that I despise the KGB-sponsored killings as much as the CIA ones. The point of this discussion was that the USA's only interest was a peaceful and boring Europe, and in my opinion terrorism is incompatible with peace and boredom.
In fact I think if you consult a dictionary, you'll note that "military control" is generally considered the opposite of having terrorists run around your country, so that Italy in the 70s and 80s was suffering from a distinct lack of military control.
Military control would have been an option of last resort, and it was never put in place. However, in certain times we got pretty close to that. It's not surprising, as the rest of southern Europe was not democratic until the 70s, and something like that went on in America's backyard.
Gladio had what to do with private corporations?
It was an emanation of the government of the United States of America, which, as we've already discussed here, is an expression of the private corporations that pay the politicians it's made up of.
It was an anti-soviet guerilla-prep program run by NATO in every country in Europe, wherein later a few groups got infiltrated by right-wingers who tried to use their power in immoral manners.
It wasn't anti-soviet. It was anti-democratic-countries-of-europe should one of them elect a government that wasn't appreciated by the USA. In this aspect, it was very soviet-like if anything.
About the "right-wingers", I don't know if "immoral manners" is the label that best describes turning hundreds of innocent people into jumbled meat, and then derailing the investigations with the support of the local secret services (very tangible stuff, both the bombs and the evidence that emerged during countless investigations, not conspiracy theory).
But that doesn't stop a particlar brand of conspiracy theorist from crediting to Gladio everything under the sun.
Eh, that's what happens when you set up secret organizations to subvert the democratic order of foreign states and end up supporting and funding terrorism. As a side effect, when you get busted, people tend to lose the faith in you.
Your government wants Europe to meet the interests of the companies that rule your country. Whether that means a peaceful, stable, boring place or a fascist, military-controlled, or terrorism-ridden state is of secondary importance.