I'm reminded of a quote from "Soul of a new machine" where another vendor (IBM?) 'legitimized' minicomputers. Data General ran an ad that said, "The Bastards say 'welcome'!"
I haven't... Do the vendors offer any warranty/assertion of 'fitness for use'? Or do they follow most of the rest of the software industry with license terms that basically say "We will not warrant this software does what it's supposed to do, so you can't sue us for any problems."
Your point about "know there's a failure" is relevant. But if the two sensors don't agree, then the '3rd factor' is the pilot. System reports "sensor failure" and the pilot turns off that anti-stall system. The rules as I understood them (I am not a safety engineer, but I've had some training in this area) is to use voting to detect the failure. For an engine, there are other ways to detect the failure than seeing if the engines are all turning at the same RPMs:-)
Well, there's an obvious fix: Turn off the the control system that handles the anti-stall provisions that are likely at fault. Talking to my neighbor (AA pilot who's been trained on 737 Max 8), that was his comment. "It's pretty obvious the pilots need to be trained to turn off the system when they see that behavior."
But to an earlier comment: From the bit I know about commercial avionics safety, if there really is a single sensor that feeds into a control system, that does feel like a violation of safety design standards (for triple redundancy).
I'm betting this is at least in part a 'supplier management' problem on the part of Boeing. That's what led to the Dreamliner battery fires. And the current CEO of Boeing was PM for the big Army FCS program (that I was part of, on the government side.) Boeing did a piss-poor job of supplier/subcontractor management there, and it seems that Dennis Muilenberg took that problem with him when he moved over to the lead for the Dreamliner.
... The people reviewing the publications are often other researchers in the field who aren't paid for their services. These journals aren't employing anyone who understands whether or not the articles are good....
Actually, in my experience, the editors-in-chief (EiC) (who usually do get paid) are chosen from researchers in the field and do understand the basic technology/science/topci, even if they aren't an expert on the specific article in question. Several times I was asked to review an article by an EiC, because he knew if the article wasn't good, I'd do a thorough job skewering it (and he suspected the article was not good.) I finally got mad and said, "You know these are junk. Can't you send me something good to review?" He laughed and said, "OK. It's just you're so good at the negative review. I have problems finding people who will take the time to fully critique a bad article."
My friend who's EiC for a journal in another field (chemistry) and I debated this. He points out, as do other posts here, there are legitimate costs that have to be covered, and being EiC takes A Lot of time. So we need a means for covering that, either by user/reader fees or by writer/contributor fees. My response is "OK, but (1) PROFIT is not a legitimate cost to be covered. (2) Administrative costs need to be minimized, and a for-profit organization has no particular incentive to do that." At that point, we pretty much agreed-to-disagree, but we did agree that the current model was not working well.
We're working off of computer models of climate. Those get validated by taking past data and running them into the models which are built on past data. The idea of messing with the weather on a planetary level scares the bejezzus out of me. See "Law of Unintended Consequences."
Part of the attraction for OSS over proprietary software is the possibility of (competitive) contracting out support. Outside of RedHat for Linux, where are the support shops? I've worked on many (large) projects where they would be happy to let a contract for product support, but we couldn't find anyone to contract with. The expectation would be that we'd pay someone to fix bugs that got reported (with priority for those bugs we reported as significant), while contributing those fixes back to the OSS project (in accordance with the OSS project's rules.) If necessary, that might mean forking the project because we needed some fix/feature that was not accepted by the "rulers"/community at large. Again, though, the ability to do that is supposed to be A Feature, not A Bug (tm).
Not all users, even of infrastructure components, are going to be qualified to maintain those projects. And from a company's perspective, they'd rather invest developer resources in their own projects, and let the experts in the OSS components maintain that software.
That depends, of course, on finding competent workers and companies (even body shops) to contract with. For my project, that included all the overhead and pain of doing contract work for the US government. Usually, defense work requires be performed in the US by US citizens, so that rules you out:-(
I worked on a large program (that you probably heard about) with a lot of embedded and command & control software. We made extensive use of both COTS products and open source.
Here are some of the impediments to using OSS we observed
1. The plethora of licenses! We kept 2 lawyers (one government, one prime contractor) busy nearly full-time for several years evaluating open source licenses. Each project had a different license, that needed to be understood for its impacts on procurement, use, distribution and maintenance, and how the licenses work together in a deployed system.
2. There was a big fight on the GPL. Many believed GPL would require the government to reveal all of its source code for this (weapon system) project. We never really did resolve this, and some GPL projects were disqualified from consideration due to license issues.
3. Maintenance was a key concern. For a commercial product, you can negotiate maintenance with the vendor. For OSS, you -might- be able to negotiate a support contract with a vendor (e.g. RedHat). But the government also might need to assume the maintenance burden if it couldn't buy support.
4. Related to #3: control of the evolution. With COTS products, there's a commercial entity that you can influence (including pay) to get the changes you need. With OSS, there's no guarantee the OSS product would migrate the direction you needed.
5. Related to #4: Complexity of integration. If you have N products, you have N! ways those could fail to integrate:-)
That being said, we used a lot of OSS in the project. We also took advantage of government site licenses on COTS, negotiated specific COTS contracts, and in some cases ended up writing our own code where we couldn't find an alternative. The project had a formal process for each significant component that required government and prime contractor concurrence. OSS tended to win in cases where there was a solid user community, some options for support (including training, by the way), and we understood the life-cycle risks. COTS won where there was an established product with clear maintenance costs (and things that the government already had site licenses for were obviously at a significant advantage.)
And I still remember the one government group that showed up with a 1.2m line application written in Visual Basic, who were totally pissed when we told them "We have no provision for Microsoft Windows in our computing environment. If you want to use a Windows application, your group will be responsible for the life-cycle costs to buy WIndows licenses where you need them, install/provision Windows and the associated software such as Anti-Virus, pay for the support costs including software maintenance and the people costs to maintain a Windows environment, and the training for the users and administrators for Windows applications."
I'd like to see a law requiring disclosure of vulnerabilities with penalties for non-compliance.
But first, I want a law that makes companies liable for bugs and vulnerabilities, i.e. one that outlaws most of the terms in shrink-wrap licenses. When companies actually pay damages, they'll start being A Lot More Careful.
This link should take you to your Ad Preferences. Be sure to click on both "Interests" and "Advertisers" - and check the sub-tabs.
The shit that shows up there is bizarre. Today FB decided one of my interests was "brake shoes". And in the Advertisers section, I see a significant (literally hundreds) of non-local real estate agents and car dealers. Not sure why I'd be interested in either a car dealer or a realtor several thousand miles from where I actually live. But then, FB decided a couple months ago I live near Fargo ND. (If they really had their shit together, it would be obvious which county I live in NH, given some of the groups I subscribe to.)
I've been using GraphicConverter and DefaultFolder since Mac OS 7 on PowerPC (and I think even back to 68000.) DefaultFolder, in particular, had to be redesigned from the ground up a couple years ago not because of change of processor, but due to changes in how Mac OS X handles security features and system extensions.
Although it's not old enough to make "the old guard", I'm a huge fan of Aquamacs, a very well done EMACS port/reworking to be consistent with the Apple user interface. (Real EMACS beats BBEdit any day, IMHO.)
I worked on a major DoD acquisition program in the previous decade, where the prime contractor and the government both kept a lawyer busy nearly full-time evaluating Open Source licenses.
We did overcome a lot of the resistance to the GPL, but that was a significant set of both legal and business arguments that went up to the executive levels.
The worst was packages with a mix of commercial and Open Source licenses, when we had to figure out not just what we could do with the their code and our code, but also how we would maintain the resulting system.
(And as a side comment, one big problem we had was incompatible/obsolete version of OSS components. I think an audit of one of our builds found something -20 different- versions of SSL libraries, some with really bad security vulnerabilities.)
One suggestion for motivation is to drive prices of Super Micro, and tech in general, down. That certainly happened for Super Micro. Another is to cast doubt on tech, particularly Big Tech (and cloud vendors) in general. That could be for financial reasons, or it could be for propaganda/'engendering distrust" reasons.
I'm not saying I necessarily believe either suggestion, but they're worth considering if one concludes the Bloomberg story was a deliberate plant, rather than just particularly shoddy journalism. (Hanlon's Law may well apply here.)
On this story, and the previous stories on this topic, a lot of posters have doubted the denials from Super Micro, Apple, Facebook and the various government agencies. I suspect this independent audit won't convince them, either.
So my question for the assembled multitude is this: What would be -sufficient proof- this didn't happen? Or is this one of those things where you won't accept any explanation from "the deep state"/"vested interests"/etc?
This is a significant issue for tech in general, as we need some widely accepted way to show systems are free from hidden vulnerabilities.
What we'll get from programs like this are "coders who know the latest buzz-technology", but not "designers who know how to think and learn." But that's exactly what Industry wants. They don't -invest in human capital-, they just look for disposable staff who happen to know this year's fad.
How many of these labels are existing companies that were bought by Amazon? Small Parts, for example, was bought by Amazon a couple years ago. (I remember ordering from them before they were part of Amazon.) At one level, it doesn't make a difference, the profits got to Bezos. But it seems to me a legitimate business strategy for Amazon to buy successful companies that add to their portfolio of things they sell directly.
There is a legitimate concern -if- these acquisitions and private labels have an impact on competition.
Slashdot Mirror
The SPARK community has been doing this for A Long Time. https://en.wikipedia.org/wiki/...
I'm reminded of a quote from "Soul of a new machine" where another vendor (IBM?) 'legitimized' minicomputers. Data General ran an ad that said, "The Bastards say 'welcome'!"
Many mug shots are taken with a height scale behind the perp.
I haven't... Do the vendors offer any warranty/assertion of 'fitness for use'? Or do they follow most of the rest of the software industry with license terms that basically say "We will not warrant this software does what it's supposed to do, so you can't sue us for any problems."
Mod parent up, please. This is directly on the mark.
Your point about "know there's a failure" is relevant. But if the two sensors don't agree, then the '3rd factor' is the pilot. System reports "sensor failure" and the pilot turns off that anti-stall system. The rules as I understood them (I am not a safety engineer, but I've had some training in this area) is to use voting to detect the failure. For an engine, there are other ways to detect the failure than seeing if the engines are all turning at the same RPMs :-)
Well, there's an obvious fix: Turn off the the control system that handles the anti-stall provisions that are likely at fault. Talking to my neighbor (AA pilot who's been trained on 737 Max 8), that was his comment. "It's pretty obvious the pilots need to be trained to turn off the system when they see that behavior."
But to an earlier comment: From the bit I know about commercial avionics safety, if there really is a single sensor that feeds into a control system, that does feel like a violation of safety design standards (for triple redundancy).
I'm betting this is at least in part a 'supplier management' problem on the part of Boeing. That's what led to the Dreamliner battery fires. And the current CEO of Boeing was PM for the big Army FCS program (that I was part of, on the government side.) Boeing did a piss-poor job of supplier/subcontractor management there, and it seems that Dennis Muilenberg took that problem with him when he moved over to the lead for the Dreamliner.
... ...
The people reviewing the publications are often other researchers in the field who aren't paid for their services. These journals aren't employing anyone who understands whether or not the articles are good.
Actually, in my experience, the editors-in-chief (EiC) (who usually do get paid) are chosen from researchers in the field and do understand the basic technology/science/topci, even if they aren't an expert on the specific article in question. Several times I was asked to review an article by an EiC, because he knew if the article wasn't good, I'd do a thorough job skewering it (and he suspected the article was not good.) I finally got mad and said, "You know these are junk. Can't you send me something good to review?" He laughed and said, "OK. It's just you're so good at the negative review. I have problems finding people who will take the time to fully critique a bad article."
My friend who's EiC for a journal in another field (chemistry) and I debated this. He points out, as do other posts here, there are legitimate costs that have to be covered, and being EiC takes A Lot of time. So we need a means for covering that, either by user/reader fees or by writer/contributor fees. My response is "OK, but (1) PROFIT is not a legitimate cost to be covered. (2) Administrative costs need to be minimized, and a for-profit organization has no particular incentive to do that." At that point, we pretty much agreed-to-disagree, but we did agree that the current model was not working well.
We're working off of computer models of climate. Those get validated by taking past data and running them into the models which are built on past data. The idea of messing with the weather on a planetary level scares the bejezzus out of me. See "Law of Unintended Consequences."
Part of the attraction for OSS over proprietary software is the possibility of (competitive) contracting out support. Outside of RedHat for Linux, where are the support shops? I've worked on many (large) projects where they would be happy to let a contract for product support, but we couldn't find anyone to contract with. The expectation would be that we'd pay someone to fix bugs that got reported (with priority for those bugs we reported as significant), while contributing those fixes back to the OSS project (in accordance with the OSS project's rules.) If necessary, that might mean forking the project because we needed some fix/feature that was not accepted by the "rulers"/community at large. Again, though, the ability to do that is supposed to be A Feature, not A Bug (tm).
Not all users, even of infrastructure components, are going to be qualified to maintain those projects. And from a company's perspective, they'd rather invest developer resources in their own projects, and let the experts in the OSS components maintain that software.
That depends, of course, on finding competent workers and companies (even body shops) to contract with. For my project, that included all the overhead and pain of doing contract work for the US government. Usually, defense work requires be performed in the US by US citizens, so that rules you out :-(
I worked on a large program (that you probably heard about) with a lot of embedded and command & control software. We made extensive use of both COTS products and open source.
Here are some of the impediments to using OSS we observed
1. The plethora of licenses! We kept 2 lawyers (one government, one prime contractor) busy nearly full-time for several years evaluating open source licenses. Each project had a different license, that needed to be understood for its impacts on procurement, use, distribution and maintenance, and how the licenses work together in a deployed system.
2. There was a big fight on the GPL. Many believed GPL would require the government to reveal all of its source code for this (weapon system) project. We never really did resolve this, and some GPL projects were disqualified from consideration due to license issues.
3. Maintenance was a key concern. For a commercial product, you can negotiate maintenance with the vendor. For OSS, you -might- be able to negotiate a support contract with a vendor (e.g. RedHat). But the government also might need to assume the maintenance burden if it couldn't buy support.
4. Related to #3: control of the evolution. With COTS products, there's a commercial entity that you can influence (including pay) to get the changes you need. With OSS, there's no guarantee the OSS product would migrate the direction you needed.
5. Related to #4: Complexity of integration. If you have N products, you have N! ways those could fail to integrate :-)
That being said, we used a lot of OSS in the project. We also took advantage of government site licenses on COTS, negotiated specific COTS contracts, and in some cases ended up writing our own code where we couldn't find an alternative. The project had a formal process for each significant component that required government and prime contractor concurrence. OSS tended to win in cases where there was a solid user community, some options for support (including training, by the way), and we understood the life-cycle risks. COTS won where there was an established product with clear maintenance costs (and things that the government already had site licenses for were obviously at a significant advantage.)
And I still remember the one government group that showed up with a 1.2m line application written in Visual Basic, who were totally pissed when we told them "We have no provision for Microsoft Windows in our computing environment. If you want to use a Windows application, your group will be responsible for the life-cycle costs to buy WIndows licenses where you need them, install/provision Windows and the associated software such as Anti-Virus, pay for the support costs including software maintenance and the people costs to maintain a Windows environment, and the training for the users and administrators for Windows applications."
I'd like to see a law requiring disclosure of vulnerabilities with penalties for non-compliance.
But first, I want a law that makes companies liable for bugs and vulnerabilities, i.e. one that outlaws most of the terms in shrink-wrap licenses. When companies actually pay damages, they'll start being A Lot More Careful.
And that same standard says that FirstNameLastName is different from firstnamelastname
dave
The standard that says FirstNameLastName is different from FirstName.LastName!
so that commercial companies like Google can ignore them, to achieve "a competitive advantage."
Sorry, here's the link: https://www.facebook.com/ads/p...
This link should take you to your Ad Preferences. Be sure to click on both "Interests" and "Advertisers" - and check the sub-tabs.
The shit that shows up there is bizarre. Today FB decided one of my interests was "brake shoes". And in the Advertisers section, I see a significant (literally hundreds) of non-local real estate agents and car dealers. Not sure why I'd be interested in either a car dealer or a realtor several thousand miles from where I actually live. But then, FB decided a couple months ago I live near Fargo ND. (If they really had their shit together, it would be obvious which county I live in NH, given some of the groups I subscribe to.)
I've been using GraphicConverter and DefaultFolder since Mac OS 7 on PowerPC (and I think even back to 68000.) DefaultFolder, in particular, had to be redesigned from the ground up a couple years ago not because of change of processor, but due to changes in how Mac OS X handles security features and system extensions.
Although it's not old enough to make "the old guard", I'm a huge fan of Aquamacs, a very well done EMACS port/reworking to be consistent with the Apple user interface. (Real EMACS beats BBEdit any day, IMHO.)
I worked on a major DoD acquisition program in the previous decade, where the prime contractor and the government both kept a lawyer busy nearly full-time evaluating Open Source licenses.
We did overcome a lot of the resistance to the GPL, but that was a significant set of both legal and business arguments that went up to the executive levels.
The worst was packages with a mix of commercial and Open Source licenses, when we had to figure out not just what we could do with the their code and our code, but also how we would maintain the resulting system.
(And as a side comment, one big problem we had was incompatible/obsolete version of OSS components. I think an audit of one of our builds found something -20 different- versions of SSL libraries, some with really bad security vulnerabilities.)
Fucking Brilliant!
One suggestion for motivation is to drive prices of Super Micro, and tech in general, down. That certainly happened for Super Micro. Another is to cast doubt on tech, particularly Big Tech (and cloud vendors) in general. That could be for financial reasons, or it could be for propaganda/'engendering distrust" reasons.
I'm not saying I necessarily believe either suggestion, but they're worth considering if one concludes the Bloomberg story was a deliberate plant, rather than just particularly shoddy journalism. (Hanlon's Law may well apply here.)
On this story, and the previous stories on this topic, a lot of posters have doubted the denials from Super Micro, Apple, Facebook and the various government agencies. I suspect this independent audit won't convince them, either.
So my question for the assembled multitude is this: What would be -sufficient proof- this didn't happen? Or is this one of those things where you won't accept any explanation from "the deep state"/"vested interests"/etc?
This is a significant issue for tech in general, as we need some widely accepted way to show systems are free from hidden vulnerabilities.
What we'll get from programs like this are "coders who know the latest buzz-technology", but not "designers who know how to think and learn." But that's exactly what Industry wants. They don't -invest in human capital-, they just look for disposable staff who happen to know this year's fad.
IANAL, but the inability to cross-examine Snowden might well make this inadmissible.
(And that's without expressing my highly unfavorable opinion of the author.)
How many of these labels are existing companies that were bought by Amazon? Small Parts, for example, was bought by Amazon a couple years ago. (I remember ordering from them before they were part of Amazon.) At one level, it doesn't make a difference, the profits got to Bezos. But it seems to me a legitimate business strategy for Amazon to buy successful companies that add to their portfolio of things they sell directly.
There is a legitimate concern -if- these acquisitions and private labels have an impact on competition.