Unfortunately, the law has a long history of favoring those with power, and especially those males with power, and especially those males of the dominant social group with power.
So while it's quite reasonable to doubt a lot of the accusations, it's also quite reasonable to believe that they didn't dare take their case to court without respect to whether it was valid or not.
Trial by social media sure isn't guaranteed to produce justice, but neither is the legal system. And people are strongly disposed to pick the venue that they consider most favorable to themselves. Different systems have different biases, and were I a woman I'd think long and hard before I took even a conclusive case of sexual assault to the legal system.
I think you are wrong in asserting that the University would be more willing to side with the student. What they would do, however, is whatever it takes to sweep the event under the rug. That may appear to be the same, but it has many different secondary effects.
A key item here is that the University of California is mainly paid for by taxes...which everyone pays. (OTOH, enrollment costs have skyrocketed over the last few decades, so that statement may be based on old data...and perhaps it's just "...largely paid for...".)
I don't think you understand the University of California enrollment process. You don't get to select the campus you want, you get to request it. If you are only willing to accept one campus, you will likely be rejected even if you otherwise qualify, because there are lots of students who aren't so picky. This is made worse because a certain number of "foreign exchange students" are accepted. This number is artificially high because they pay higher rates and are thus more profitable. Many of the campuses try to limit the number of undergraduates, so they can concentrate on graduate students. (I don't know to what extent the university allows this to actually be done, but I know attempts are made.)
I'm not really that familiar with current procedures, but student choice is generally considered an thing that can readily be sacrificed to administrative whims. They've got more applicants than they can handle.
I went there decades ago (different campus), and so, a decade or so earlier did my mother (same different campus). Neither of us liked the experience...though I don't know what the alternatives would have been like.
FWIW, when I went to UC the dorms were more expensive than living in an apartment...but there was other student housing with provided meals that was cheaper. And, of course, the frats were more expensive than the dorms, but I never even considered them.
The University of California is largely paid for by taxes, so yes, a university education should be a right, subject only to being an adequate student. Even that limit only to prevent wasting the time and effort of the professors.
Pointers are one way in which C/C++ loses track of semantics. There are others, but it's been well over a decade since I was a heavy C++ programmer. Still, I'm rather certain that old C++ code still usually works with recent versions of the compiler, so the effects should still happen.
OK. If you want to argue that C++ is Turing Complete, I can't disagree with you. That, however, is not the language understanding semantics. That's the program doing it.
FWIW, I suspect that actual semantic analysis is not formally possible, but will always demand heuristics, and a reasonable chance of reaching the wrong conclusion.
Also, an approach that could work in both C and C++ to do what you are suggesting is to define a struct for each type, and then operators between the types. But that's not the language being semantically aware, that's the programmer doing it, and is riddled with problems with misapplication, pointer conversion, etc. Making things overly complex and then asking a human rather than a computer to do this is begging for problems. People are fairly good at simple thing, terrible at precise complex things and very good at pattern recognition. Computers are extremely good at simple things, extremely good at precise complex things, and horrible at pattern recognition. It's probably partially an optimization problem, but it's also our technical limitations. The computers handle a lot fewer transactions/second than do human brains, but the software is more precise.
Still, a simple to use approximation to a semantic analysis could help a lot. E.g., I really appreciate the spell checker that is built into my browser...but I need to be able to override it when a word that it doesn't recognize shows up. The grammar checker, however, is so bad that I have it turned off.
No, actually it isn't. You can easily do a half-assed implementation, but not a real one. A real one wouldn't quite be beyond the state of the art, but pretty close. And it still wouldn't be a full semantic analysis.
As for your currency type, how does it handle conversion between dollars and yen? Does it forbid conversion of dollars to inches? What about hours to dollars? And even that's just talking about matching types, and requiring argument agreement. Yes, I understand that you can do the type matching kind of thing with struct declarations and macros to hide the messiness, but that's syntactic, not semantic.
OTOH, a multi-level template system might approach semantic analysis as closely as we can now manage. Maybe. But you need to distinguish between things that have a fixed conversion and those that have a varying conversion. E.g. dollars to yen conversion depends on when you do it, so it's quite probable that no compiled code could handle it without referring to an external source for the current conversion rate. This still isn't semantic, but it's more than syntactic.
The reason that it's easier to do a half-assed version in C++ than in Ada is that C/C++ allows you to do unchecked conversions without noting an error. Ada is so picky it detects errors even when they aren't there, but C++ just lets them through until they cause a run-time problem. Well, Ada lets you say "This isn't really an error, even though it looks like one", and you can write extra logic in C++ to validate your code...neither approach is very nice. D is closer to ideal in this respect, but it doesn't allow you to specify (at declaration time) what range a variable is allowed to have, only how much storage it uses. This variable is a long int, and that one's a byte and...etc. Ada allows you to specify ranges of permissible values at the time the variable is declared...e.g. this variable must be between 3.1415 and 9.4245 inclusive. It also allows modular types that aren't multiple of 2. Not always useful, and a bit expensive to implement, but sometimes quite useful. (OTOH, I once had to write a program that used a 36 hour day with overlaps between days. It was tracking jobs from when they started rather than by the calendar date.)
Semantics is tricky, and actual semantics is beyond the state of the art, so any approach used would need to allow itself to be overridden. But the default should be to catch errors.
Yi! I'm going to guess that IBM has some sort of technology sharing arrangement with Intel, but that's admittedly a guess. It's hard to believe that IBM would make that kind of tech goof on it's own.
Yes, but the only way to deal with many of those problems is with a language with semantic, as opposed to simply syntactic, validity checking. And we don't know how to do that yet.
The thing is, we can to *parts* of semantic checking, but the languages we use don't facilitate this, and actually act as roadblocks. Languages have types for things like int and float, but not for things like dollars and inches....but it's the dollars and inches that are important. The floats and ints can be represented in any way that's appropriate to the semantics....but we can't handle the semantics. It's not even a question of "Can we handle it efficiently?", as our languages can't handle it at all. Some specialized libraries can handle parts of this, but when they link into our languages, the results come in a ints, floats, strings, or some combination. A few decades ago I started trying to figure out how to do that kind of thing in ADA for units of length (both metric and imperial). It's quite easy to state the rules, but implementing them in a usable way appears impossible. In most languages I can't even specify them in an unusable way that will catch erroneous uses.
This depends on the class of error. Some C errors are blatant, others sneaky. And some are "merely" stylistic, and don't cause a problem until someone else has to deal with the code. One guy I worked with had a passion for macros with names that meant something to him, but not to anyone else. He left. The only way to deal with the code was to run it thorough the preprocessor, and then try to figure out what it was doing without comments to help. (Well, the original code was "sort of" commented, but again, cryptically. And the preprocessor changed things around a lot.) I'd be more explicit, but *I* didn't end up dealing with it, only watching someone else try to deal with it.
Standard Pascal strings were limited to 255 ASCII-7 characters. IIUC FreePascal has a variant kind of string that allows longer strings, and another variant for Unicode. Also a version for binary blocks. The Pascal strings could contain embedded null chars. (Well, so could the C strings, but the utilities would end the string a the first null.)
To say "C is not broken" is to close your eyes to it's real problems. But it's only broken in the same sense that assembler is broken. It has features that tend to lead to code that is unsafe, difficult to debug, and difficult to understand.
C is an excellent design for a computer language, just not an excellent design for a programming language. And arguments about what makes an excellent programming language are never-ending, because different use cases yield different answers. If you need resizable arrays you have a different answer than if you need fixed length strings, and that's different than if you need immutable values to access between different processes.
But for the basic C use case I generally think certain features should be forbidden. Writing beyond the bounds of allocated storage sounds good, but is expensive to check for...and sometimes needs to be allowed in special cases (e.g., and array within a struct that isn't the final element), but in other cases (e.g. when the array isn't the final element) it should be normally forbidden....except that when it's a pointer based overlay on other storage...
C is full of misfeatures that are inherently dangerous. They allow you to do useful things, but those things should be done through some alternate mechanism, that isn't so liable to errors or abuse. I'm really dubious about all the features that allow you to address an indefinite amount of memory. I'm not sure that there IS a safe way to do that that is also efficient. (One way to handle that would be to allow the program to be loaded with a specified amount of reserved RAM, and if you need to exceed that, to do a save state, and then reload it with a larger specified amount...but allocation on the heap is probably less expensive.)
Rust is quite unpleasant to use (when last I checked) and was recently changing rapidly. It's also difficult to properly implement. C is easy to use (with problems), easy to port, and has lots of decent libraries.
FWIW, I don't like C, and consider it unreasonably dangerous, but my use case is very different. I do think that projects should adopt a subset of C rather than full C, and have a strong "super lint" to ensure that casting is done properly and void pointers have proper typing. (A macro preprocessor could be used to handle ensure that void pointers had semantic casts, that would be ignored by C.) This would take a bit of custom work, but not a huge amount....nothing like that required by the Mortran preprocessor for Fortran back in the day, as the notations would be a lot simpler...things like macros that translated into empty replacements, but which were recognized by the preprocessor. The terms would need to be defined by the preprocessor, so you could write something like: a = func (C_INT_PTR p) where p is a void pointer, and func requires an int pointer argument. This is something that could be done by convention, but you need the preprocessor to ensure compliance.
How far you want to take this is a matter of taste, but you could have a preprocessor that did a full type check if you wanted to put in the effort, and still have final output that is pure C code.
Perhaps the best way to do it would be to start off with a C to C compiler, and slowly add in additional checks, constraints, pre-defined semantic macros, etc.
Sorry, I didn't mean to include current IBM designs. I know nothing about them. Are you saying that they are vulnerable to Meltdown?
As for the 1967 design problem, I believe that's about when the problem was originally identified...though at the time the exploits were considered only theoretically possible, not actually possible. Still, that was when mitigation measures were first considered.
Yes, but as another comment indicated, only the chips based on Intel designs had the Meltdown problem, so I still tend to think of it as an Intel defect. Were I considering purchasing an ARM, of course, the manufacturer would be more significant.
Since I'm not, to me that's still an Intel defect. Where you draw the line is, in a sense, arbitrary...or at least situational.
There have indeed been times when Intel acted in ways that benefited the Linux community. Of course, they also benefitted Intel.
OTOH, have you ever heard the term "Wintel"? They've acted detrimentally about as much as they've acted beneficially, and arguably more. They've designed systems that intentionally shut Linux out of application. They've refused to publish interface specs that they shared with a different OS vendor. Etc.
The problem with trying to assign a position to the company is that it's not an individual. Different groups have adopted different policies. If they were a person they'd be described as being MPD to an extreme degree, and in need of hospitalization. I find them untrustworthy, and when one of the legal or marketing personalities is in charge, totally untrustworthy. But they aren't the worst company that one must deal with.
I have not encountered any trustworthy references to the effect that any company besides Intel had the Meltdown problem. Spectre, yes, to a small (I'm not sure how small) degree, but not Meltdown. And only some variants of Spectre.
And my first thought was "I wonder what *amazing* new holes they've opened in those models.". I don't *know* that they've intentionally introduced new bugs...but their entire process in this last case (which they have "improved" on paper after the fact) causes me to doubt their intentions.
But perhaps AMD just hasn't been caught yet. Any chip that requires a "management engine" is dubious, even if you call it a "trust zone" or some such. It's a sign that they're trying to rent you the CPU rather than sell it to you. The "trust zone" is about the company's trust, not the users.
When you're trying to prove something you need stronger evidence than when you're trying to assign probability. Particularly if the probability estimate is going to have large error bars. To me the evidence is strongly in favor of the machines being designed to product the votes they are instructed to produce. I'd agree it's far short of proof. I'd agree they they can be operated honestly, and that that is probably the default behavior.
In short, I see no reason to trust the honesty of the machines and many reasons to doubt it. That this is not proof, I'll agree. But it isn't proof either way...including definitely not proof that the machines are honest.
This is not, basically, a problem with capitalism. It exists in every system where those who control payout control their own payout. If the control is indirect, then the feedback is less extreme. E.g., if the payment is decided by the board of directors, then the person paid benefits by being glib in front of the board of directors.
Think of it as a feedback system problem and you'll understand why it happens. And it doesn't only happen under capitalism.
That said, it is inherent in systems where one entity exerts strong control over the rest of the system. And capitalism is often one of those systems. Note that the article mentions that it is more extreme in larger corporations. This is just what this analysis would have predicted. In smaller groups other effects can dominate, particularly is the "boss" is also the owner. So on a small scale capitalism works, or can work, very well. And on the smallest scale there is little to choose from between capitalism, communism, and socialism. In fact, even anarchy seems to work at a small enough scale, unless there are exogenous stresses. (I've been referred to the yk tribe as an example, but I've never tracked this down. The reference was given during the 1940's about anarchy disintegrating under external stresses...but I don't know what kind of external stresses.)
That said, in this case I think your argument is against hierarchical systems with control at the top (i.e., almost all of them).
Slashdot Mirror
Unfortunately, the law has a long history of favoring those with power, and especially those males with power, and especially those males of the dominant social group with power.
So while it's quite reasonable to doubt a lot of the accusations, it's also quite reasonable to believe that they didn't dare take their case to court without respect to whether it was valid or not.
Trial by social media sure isn't guaranteed to produce justice, but neither is the legal system. And people are strongly disposed to pick the venue that they consider most favorable to themselves. Different systems have different biases, and were I a woman I'd think long and hard before I took even a conclusive case of sexual assault to the legal system.
I think you are wrong in asserting that the University would be more willing to side with the student. What they would do, however, is whatever it takes to sweep the event under the rug. That may appear to be the same, but it has many different secondary effects.
A key item here is that the University of California is mainly paid for by taxes...which everyone pays. (OTOH, enrollment costs have skyrocketed over the last few decades, so that statement may be based on old data...and perhaps it's just "...largely paid for...".)
I don't think you understand the University of California enrollment process. You don't get to select the campus you want, you get to request it. If you are only willing to accept one campus, you will likely be rejected even if you otherwise qualify, because there are lots of students who aren't so picky. This is made worse because a certain number of "foreign exchange students" are accepted. This number is artificially high because they pay higher rates and are thus more profitable. Many of the campuses try to limit the number of undergraduates, so they can concentrate on graduate students. (I don't know to what extent the university allows this to actually be done, but I know attempts are made.)
I'm not really that familiar with current procedures, but student choice is generally considered an thing that can readily be sacrificed to administrative whims. They've got more applicants than they can handle.
I went there decades ago (different campus), and so, a decade or so earlier did my mother (same different campus). Neither of us liked the experience...though I don't know what the alternatives would have been like.
FWIW, when I went to UC the dorms were more expensive than living in an apartment...but there was other student housing with provided meals that was cheaper. And, of course, the frats were more expensive than the dorms, but I never even considered them.
The University of California is largely paid for by taxes, so yes, a university education should be a right, subject only to being an adequate student. Even that limit only to prevent wasting the time and effort of the professors.
Pointers are one way in which C/C++ loses track of semantics. There are others, but it's been well over a decade since I was a heavy C++ programmer. Still, I'm rather certain that old C++ code still usually works with recent versions of the compiler, so the effects should still happen.
OK, it's been awhile. I still won't buy anything from them.
From my point of view, Sony ended their repair the day they removed the Linux install. And I haven't bought anything from them since, and won't.
OK. If you want to argue that C++ is Turing Complete, I can't disagree with you. That, however, is not the language understanding semantics. That's the program doing it.
FWIW, I suspect that actual semantic analysis is not formally possible, but will always demand heuristics, and a reasonable chance of reaching the wrong conclusion.
Also, an approach that could work in both C and C++ to do what you are suggesting is to define a struct for each type, and then operators between the types. But that's not the language being semantically aware, that's the programmer doing it, and is riddled with problems with misapplication, pointer conversion, etc. Making things overly complex and then asking a human rather than a computer to do this is begging for problems. People are fairly good at simple thing, terrible at precise complex things and very good at pattern recognition. Computers are extremely good at simple things, extremely good at precise complex things, and horrible at pattern recognition. It's probably partially an optimization problem, but it's also our technical limitations. The computers handle a lot fewer transactions/second than do human brains, but the software is more precise.
Still, a simple to use approximation to a semantic analysis could help a lot. E.g., I really appreciate the spell checker that is built into my browser...but I need to be able to override it when a word that it doesn't recognize shows up. The grammar checker, however, is so bad that I have it turned off.
No, actually it isn't. You can easily do a half-assed implementation, but not a real one. A real one wouldn't quite be beyond the state of the art, but pretty close. And it still wouldn't be a full semantic analysis.
As for your currency type, how does it handle conversion between dollars and yen? Does it forbid conversion of dollars to inches? What about hours to dollars? And even that's just talking about matching types, and requiring argument agreement. Yes, I understand that you can do the type matching kind of thing with struct declarations and macros to hide the messiness, but that's syntactic, not semantic.
OTOH, a multi-level template system might approach semantic analysis as closely as we can now manage. Maybe. But you need to distinguish between things that have a fixed conversion and those that have a varying conversion. E.g. dollars to yen conversion depends on when you do it, so it's quite probable that no compiled code could handle it without referring to an external source for the current conversion rate. This still isn't semantic, but it's more than syntactic.
The reason that it's easier to do a half-assed version in C++ than in Ada is that C/C++ allows you to do unchecked conversions without noting an error. Ada is so picky it detects errors even when they aren't there, but C++ just lets them through until they cause a run-time problem. Well, Ada lets you say "This isn't really an error, even though it looks like one", and you can write extra logic in C++ to validate your code...neither approach is very nice. D is closer to ideal in this respect, but it doesn't allow you to specify (at declaration time) what range a variable is allowed to have, only how much storage it uses. This variable is a long int, and that one's a byte and...etc. Ada allows you to specify ranges of permissible values at the time the variable is declared...e.g. this variable must be between 3.1415 and 9.4245 inclusive. It also allows modular types that aren't multiple of 2. Not always useful, and a bit expensive to implement, but sometimes quite useful. (OTOH, I once had to write a program that used a 36 hour day with overlaps between days. It was tracking jobs from when they started rather than by the calendar date.)
Semantics is tricky, and actual semantics is beyond the state of the art, so any approach used would need to allow itself to be overridden. But the default should be to catch errors.
Yi! I'm going to guess that IBM has some sort of technology sharing arrangement with Intel, but that's admittedly a guess. It's hard to believe that IBM would make that kind of tech goof on it's own.
Yes, but the only way to deal with many of those problems is with a language with semantic, as opposed to simply syntactic, validity checking. And we don't know how to do that yet.
The thing is, we can to *parts* of semantic checking, but the languages we use don't facilitate this, and actually act as roadblocks. Languages have types for things like int and float, but not for things like dollars and inches....but it's the dollars and inches that are important. The floats and ints can be represented in any way that's appropriate to the semantics....but we can't handle the semantics. It's not even a question of "Can we handle it efficiently?", as our languages can't handle it at all. Some specialized libraries can handle parts of this, but when they link into our languages, the results come in a ints, floats, strings, or some combination. A few decades ago I started trying to figure out how to do that kind of thing in ADA for units of length (both metric and imperial). It's quite easy to state the rules, but implementing them in a usable way appears impossible. In most languages I can't even specify them in an unusable way that will catch erroneous uses.
This depends on the class of error. Some C errors are blatant, others sneaky. And some are "merely" stylistic, and don't cause a problem until someone else has to deal with the code. One guy I worked with had a passion for macros with names that meant something to him, but not to anyone else. He left. The only way to deal with the code was to run it thorough the preprocessor, and then try to figure out what it was doing without comments to help. (Well, the original code was "sort of" commented, but again, cryptically. And the preprocessor changed things around a lot.) I'd be more explicit, but *I* didn't end up dealing with it, only watching someone else try to deal with it.
Standard Pascal strings were limited to 255 ASCII-7 characters. IIUC FreePascal has a variant kind of string that allows longer strings, and another variant for Unicode. Also a version for binary blocks. The Pascal strings could contain embedded null chars. (Well, so could the C strings, but the utilities would end the string a the first null.)
To say "C is not broken" is to close your eyes to it's real problems. But it's only broken in the same sense that assembler is broken. It has features that tend to lead to code that is unsafe, difficult to debug, and difficult to understand.
C is an excellent design for a computer language, just not an excellent design for a programming language. And arguments about what makes an excellent programming language are never-ending, because different use cases yield different answers. If you need resizable arrays you have a different answer than if you need fixed length strings, and that's different than if you need immutable values to access between different processes.
But for the basic C use case I generally think certain features should be forbidden. Writing beyond the bounds of allocated storage sounds good, but is expensive to check for...and sometimes needs to be allowed in special cases (e.g., and array within a struct that isn't the final element), but in other cases (e.g. when the array isn't the final element) it should be normally forbidden....except that when it's a pointer based overlay on other storage...
C is full of misfeatures that are inherently dangerous. They allow you to do useful things, but those things should be done through some alternate mechanism, that isn't so liable to errors or abuse. I'm really dubious about all the features that allow you to address an indefinite amount of memory. I'm not sure that there IS a safe way to do that that is also efficient. (One way to handle that would be to allow the program to be loaded with a specified amount of reserved RAM, and if you need to exceed that, to do a save state, and then reload it with a larger specified amount...but allocation on the heap is probably less expensive.)
Rust is quite unpleasant to use (when last I checked) and was recently changing rapidly. It's also difficult to properly implement. C is easy to use (with problems), easy to port, and has lots of decent libraries.
FWIW, I don't like C, and consider it unreasonably dangerous, but my use case is very different. I do think that projects should adopt a subset of C rather than full C, and have a strong "super lint" to ensure that casting is done properly and void pointers have proper typing. (A macro preprocessor could be used to handle ensure that void pointers had semantic casts, that would be ignored by C.) This would take a bit of custom work, but not a huge amount....nothing like that required by the Mortran preprocessor for Fortran back in the day, as the notations would be a lot simpler...things like macros that translated into empty replacements, but which were recognized by the preprocessor. The terms would need to be defined by the preprocessor, so you could write something like:
a = func (C_INT_PTR p)
where p is a void pointer, and func requires an int pointer argument. This is something that could be done by convention, but you need the preprocessor to ensure compliance.
How far you want to take this is a matter of taste, but you could have a preprocessor that did a full type check if you wanted to put in the effort, and still have final output that is pure C code.
Perhaps the best way to do it would be to start off with a C to C compiler, and slowly add in additional checks, constraints, pre-defined semantic macros, etc.
Sorry, I didn't mean to include current IBM designs. I know nothing about them. Are you saying that they are vulnerable to Meltdown?
As for the 1967 design problem, I believe that's about when the problem was originally identified...though at the time the exploits were considered only theoretically possible, not actually possible. Still, that was when mitigation measures were first considered.
Yes, but as another comment indicated, only the chips based on Intel designs had the Meltdown problem, so I still tend to think of it as an Intel defect. Were I considering purchasing an ARM, of course, the manufacturer would be more significant.
Since I'm not, to me that's still an Intel defect. Where you draw the line is, in a sense, arbitrary...or at least situational.
There have indeed been times when Intel acted in ways that benefited the Linux community. Of course, they also benefitted Intel.
OTOH, have you ever heard the term "Wintel"? They've acted detrimentally about as much as they've acted beneficially, and arguably more. They've designed systems that intentionally shut Linux out of application. They've refused to publish interface specs that they shared with a different OS vendor. Etc.
The problem with trying to assign a position to the company is that it's not an individual. Different groups have adopted different policies. If they were a person they'd be described as being MPD to an extreme degree, and in need of hospitalization. I find them untrustworthy, and when one of the legal or marketing personalities is in charge, totally untrustworthy. But they aren't the worst company that one must deal with.
I have not encountered any trustworthy references to the effect that any company besides Intel had the Meltdown problem. Spectre, yes, to a small (I'm not sure how small) degree, but not Meltdown. And only some variants of Spectre.
But officially that won't happen next time. Believe it if you want to. Certainly it's proper to trust Intel's honesty and care for users.
And my first thought was "I wonder what *amazing* new holes they've opened in those models.". I don't *know* that they've intentionally introduced new bugs...but their entire process in this last case (which they have "improved" on paper after the fact) causes me to doubt their intentions.
But perhaps AMD just hasn't been caught yet. Any chip that requires a "management engine" is dubious, even if you call it a "trust zone" or some such. It's a sign that they're trying to rent you the CPU rather than sell it to you. The "trust zone" is about the company's trust, not the users.
I this case I'm looking at the proponent of the legislation, and suspecting that it will be much worse if it passes.
When you're trying to prove something you need stronger evidence than when you're trying to assign probability. Particularly if the probability estimate is going to have large error bars. To me the evidence is strongly in favor of the machines being designed to product the votes they are instructed to produce. I'd agree it's far short of proof. I'd agree they they can be operated honestly, and that that is probably the default behavior.
In short, I see no reason to trust the honesty of the machines and many reasons to doubt it. That this is not proof, I'll agree. But it isn't proof either way...including definitely not proof that the machines are honest.
This is not, basically, a problem with capitalism. It exists in every system where those who control payout control their own payout. If the control is indirect, then the feedback is less extreme. E.g., if the payment is decided by the board of directors, then the person paid benefits by being glib in front of the board of directors.
Think of it as a feedback system problem and you'll understand why it happens. And it doesn't only happen under capitalism.
That said, it is inherent in systems where one entity exerts strong control over the rest of the system. And capitalism is often one of those systems. Note that the article mentions that it is more extreme in larger corporations. This is just what this analysis would have predicted. In smaller groups other effects can dominate, particularly is the "boss" is also the owner. So on a small scale capitalism works, or can work, very well. And on the smallest scale there is little to choose from between capitalism, communism, and socialism. In fact, even anarchy seems to work at a small enough scale, unless there are exogenous stresses. (I've been referred to the yk tribe as an example, but I've never tracked this down. The reference was given during the 1940's about anarchy disintegrating under external stresses...but I don't know what kind of external stresses.)
That said, in this case I think your argument is against hierarchical systems with control at the top (i.e., almost all of them).