But the Soviet Union was not a member of NATO, and this was explicitly at a NATO conference.
The contributions of the western Allies, not just US but also UK, in providing supplies, vehicles, etc to the Soviet Union shouldn't be discounted. It may not have been the margin of victory, but it certainly allowed the Soviets to exploit their successes, and definitely contributed to ending the war in '45.
Don't know if this is true, but it's a damn good story:
At a NATO military conference, the French admiral was complaining, "Why do we have to speak English at all of these events?" The Dutch admiral replied, "Because the British, Canadians, and Americans made sure we don't have to speak German."
I'm using Vienna, and I have probably 100 subscriptions that I monitor at least daily. I find RSS a good way to look for things of interest. And yes, I did see this post pop up on the Slashdot RSS feed and that's how I got here.
For those of you who accuse RSS users of being Luddites, bite me! It's one thing to say "That's not a tech I use," or even "That's a technology that is showing its age." It's another thing to insult people who don't happen to use your favorite tool/technique. That's particularly true for those of you who have less than 20 years experience with the Internet. (Says the guy who uses the same email address for the last 30+ years.)
Well... I'm sure there are some promising technologies, but I'm looking for something that has been -demonstrated- at "city scale" or larger. Answering what "could be" is not the same as answering "here today." (Otherwise, I could make an argument for "clean coal of tomorrow";-) )
The problem with dams is that fresh water is an increasingly scarce resource. But there's several thousand years of history using dams and collection ponds to ensure uniform water flows for both consumption and power purposes.
Batteries, particularly those used in electric vehicles, have their own problems such as rare earth production and battery disposal.
I'm definitely not saying "it can't be done", nor am I advocating for coal or fossil fuels in the long run. But I am saying that renewable sources will have significant limits until the storage problem is solved -at scale-.
Is there a solution for bulk storage of large amounts of energy? Most renewable sources aren't "uniform", e.g. you need wind to make wind energy, sun to make solar energy, etc. The advantage of fossil fuels and nuclear energy is they don't have that same limitation.
This wasn't the first personal computer I used, though. We had a couple IBM 5100 in college, and there were the programmable desktop calculators before that.
Purchased at Lawton OK Radio Shack, Oct 1978. I paid an extra $350 for 12k of RAM, so the machine had a huge 16kb of RAM. But I couldn't afford the additional $1000 for the floppy drive and enclosure, so that loaded software from a cassette recorder.
"=" vs "==", the presence or absence of commas or semicolons that substantially change meaning, the mess that is #include in large systems...
Just look at any "obfusticated C" contest entry for egregious examples!
Sure, you can learn and code around them. But at best that's a risk. And we have plenty of examples where those risks have made it to deployed systems. What was the Apple bug on certificates where a semicolon introduced a significant bug in certificate validation that was there for years?
And this highlights the difference between C and C++, and better specified/more tightly defined languages.
Two C programmers will ask, "What will this program do?" Two Ada programmers will ask, "Will this program compile?" Because if it does compile, they both know (and agree on) exactly what the legal program will do.
35 years in industry, most of that in "millitary/aerospace" where the consequences are large and often fatal.
Perhaps more importantly, my father, a Structural Engineer with a PE license, and I discussed professional liability many times. He was involved in some court cases as an expert witness when a building fell down. (He said there was blame to go around. Bad design by the architect, incorrect/incomplete specification of materials by the architect and engineer, and the materials that were used failed to meet their own documented capabilities.)
So yes, I think this is not just doable, but also needs to be mandatory, in commercial environments, particularly where the costs of failure are significant (financial and/or human/property damage.) The disclaimer of any warranty, including that the software does what you pay for it, should be made totally illegal.
The core question for the engineering community is whether they get in front of this problem, or they wait for enough catastrophes that the lawyers, courts and particularly the legislatures decide to solve it for us.
Well first, the techniques for high confidence software (such as safety-critical) show that -substantial- improvements in software reliability are possible. For commercial avionics, the verification costs are much more (maybe even an order of magnitude) than the development costs. The ROI for verification (such as MCDC) has been questioned (whether the additional surety gained is worth the cost to get it.)
What's most important is the culture of assurance, i.e. 'think before you write', at least anecdotally doing code annotations without associated verification/proof gets you most of the benefits for relatively low costs. (The one thing I liked about Extreme Programming was its emphasis on pair coding and reviews.)
With respect to AI, I think what would work is an axiomatic approach that specifies Must Do/Must Not Do, and verification against those axioms. That's not the same level of verification as line-by-line/instruction-by-instruction avionics code, but it's a heluva lot more than we get now.
Structural engineers (my father was one) don't have a union and they don't get their degrees from trade schools.
The do have a professional society that is fully engaged in licensing, educational standards for engineering curriculum, and a career path that leads to the necessary experience to qualify for a license, along with testing. They also collaborate with the state Engineering licensing agencies.
On the other hand in computing, at least some of the professional societies have actively argued against licensing. I remember one debate that went something like, "Beauticians are required to have licenses. Should we be like beauticians?" To which the response was, "Doctors have licenses. Should we be like doctors?"
Actually, I have developed software applying DO-178B (although not to Level B/A) for air traffic control, and to Mil-Std 882D for a project that included networked fires and autonomous potentially armed vehicles. On the latter project, I was the lead software safety person for a while.
And to the follow-on comment: Yeah, there's a lot of work to get the hazards and the requirements down to the level that verification against those has real impact. That's part of the job.
and I've been calling for professional licensing and liability for software engineers for at least 30 years. That should follow the approach for other Professional Engineers, including the use of 'engineering practices' as a defense.
The software community has done an appallingly shitty job with software reliability. (Exhibit 1: CERT database of software vulnerabilities.) It's way past time they get held accountable. And yeah, this will slow things down and require people do things right the first time, and it will put a serious dent in the management approach to "throw the cheapest bodies at the software problem, and damn the bugs!" Product liability needs to include both corporate and individual liability.
Email outsourcing companies don't seem to place much value on following rules like SPF and DMARC. A lot of the false positives we get in quarantine are from senders using email outsourcing or "relationship management" companies. After all, the company gets paid by their customer for sending the mail, and has no real accountability whether the customer's email is properly formatted and delivered.
And with large institutions (particularly universities) moving to outsource email and other IT services, this problem will get worse.
(By the way, the same concept applies to phone spam: reliable/unforgeable Caller ID would probably shut most of that down. Of course, that would require the Telephone Companies to make changes. Caller ID should either be 'guaranteed' or the incoming call marked as "no Caller ID" when the caller's phone number can't be verified.)
Well, some research shows you have to download some code, install it on your machine as an RPC server, and then use the command line to get to "LBRY://"
Does this strike anyone else as fraught with IA concerns?
I'm all in favor for open repositories for Creative Commons and Public Domain content, but not if I have to breach my own machine to get to it!
That's not my experience, over the last 15 years where I was required to exchange PKI encrypted emails with both DoD users and other contractors (Fortune 50 company through 1 person security consulting shop). I've had problems setting up/loading certificates, particularly handling root and intermediate certificates (from DoD PKI). When a certificate expires, Mail has real problems with the email. And recently I was sent a short encrypted message where it took order a couple of minutes to decrypt and display.
Those problems, I believe are a combination of flaws in Mail.app, in the underlying Mac OS X PKI support, and with PKI in general. I had similar problems with Thunderbird, which depended on little or no Mac PKI infrastructure.
Hence my posting elsewhere in this thread that it's the underlying PKI infrastructure at the OS level that is at least partly at fault, and I think the complexity of the PKI design explains much of the reason why PKI infrastructure is so messy. What looked good on paper didn't scale and had real usability problems even for relatively sophisticated users. It's certainly not ready for the casual user!
Slashdot Mirror
But the Soviet Union was not a member of NATO, and this was explicitly at a NATO conference.
The contributions of the western Allies, not just US but also UK, in providing supplies, vehicles, etc to the Soviet Union shouldn't be discounted. It may not have been the margin of victory, but it certainly allowed the Soviets to exploit their successes, and definitely contributed to ending the war in '45.
Don't know if this is true, but it's a damn good story:
At a NATO military conference, the French admiral was complaining, "Why do we have to speak English at all of these events?"
The Dutch admiral replied, "Because the British, Canadians, and Americans made sure we don't have to speak German."
I'm using Vienna, and I have probably 100 subscriptions that I monitor at least daily. I find RSS a good way to look for things of interest. And yes, I did see this post pop up on the Slashdot RSS feed and that's how I got here.
For those of you who accuse RSS users of being Luddites, bite me! It's one thing to say "That's not a tech I use," or even "That's a technology that is showing its age." It's another thing to insult people who don't happen to use your favorite tool/technique. That's particularly true for those of you who have less than 20 years experience with the Internet. (Says the guy who uses the same email address for the last 30+ years.)
Well... I'm sure there are some promising technologies, but I'm looking for something that has been -demonstrated- at "city scale" or larger. Answering what "could be" is not the same as answering "here today." (Otherwise, I could make an argument for "clean coal of tomorrow" ;-) )
The problem with dams is that fresh water is an increasingly scarce resource. But there's several thousand years of history using dams and collection ponds to ensure uniform water flows for both consumption and power purposes.
Batteries, particularly those used in electric vehicles, have their own problems such as rare earth production and battery disposal.
I'm definitely not saying "it can't be done", nor am I advocating for coal or fossil fuels in the long run. But I am saying that renewable sources will have significant limits until the storage problem is solved -at scale-.
Is there a solution for bulk storage of large amounts of energy? Most renewable sources aren't "uniform", e.g. you need wind to make wind energy, sun to make solar energy, etc. The advantage of fossil fuels and nuclear energy is they don't have that same limitation.
This wasn't the first personal computer I used, though. We had a couple IBM 5100 in college, and there were the programmable desktop calculators before that.
Purchased at Lawton OK Radio Shack, Oct 1978. I paid an extra $350 for 12k of RAM, so the machine had a huge 16kb of RAM. But I couldn't afford the additional $1000 for the floppy drive and enclosure, so that loaded software from a cassette recorder.
Makes sense, I've sworn a streak of oaths at Verizon, Yahoo and even AOL at various points in the past.
dave
True. It's because they turned off the checking provided by the language.
But PERL is explicitly built on C syntax. QED!
"=" vs "==", the presence or absence of commas or semicolons that substantially change meaning, the mess that is #include in large systems...
Just look at any "obfusticated C" contest entry for egregious examples!
Sure, you can learn and code around them. But at best that's a risk. And we have plenty of examples where those risks have made it to deployed systems. What was the Apple bug on certificates where a semicolon introduced a significant bug in certificate validation that was there for years?
And this highlights the difference between C and C++, and better specified/more tightly defined languages.
Two C programmers will ask, "What will this program do?"
Two Ada programmers will ask, "Will this program compile?" Because if it does compile, they both know (and agree on) exactly what the legal program will do.
On the other hand, monkeys prefer C, because the programs they generate by jumping on the keyboard have the best chance to compile.
At some point, the developer community will wake up to just how evil C -syntax- is, and how much it has contributed to bugs and security holes.
And all those users who you inconvenienced, or worse, in the middle of the day with an update, loved you for this....
or even "My code is correct, so I don't need to test."
35 years in industry, most of that in "millitary/aerospace" where the consequences are large and often fatal.
Perhaps more importantly, my father, a Structural Engineer with a PE license, and I discussed professional liability many times. He was involved in some court cases as an expert witness when a building fell down. (He said there was blame to go around. Bad design by the architect, incorrect/incomplete specification of materials by the architect and engineer, and the materials that were used failed to meet their own documented capabilities.)
So yes, I think this is not just doable, but also needs to be mandatory, in commercial environments, particularly where the costs of failure are significant (financial and/or human/property damage.) The disclaimer of any warranty, including that the software does what you pay for it, should be made totally illegal.
The core question for the engineering community is whether they get in front of this problem, or they wait for enough catastrophes that the lawyers, courts and particularly the legislatures decide to solve it for us.
Well first, the techniques for high confidence software (such as safety-critical) show that -substantial- improvements in software reliability are possible. For commercial avionics, the verification costs are much more (maybe even an order of magnitude) than the development costs. The ROI for verification (such as MCDC) has been questioned (whether the additional surety gained is worth the cost to get it.)
What's most important is the culture of assurance, i.e. 'think before you write', at least anecdotally doing code annotations without associated verification/proof gets you most of the benefits for relatively low costs. (The one thing I liked about Extreme Programming was its emphasis on pair coding and reviews.)
With respect to AI, I think what would work is an axiomatic approach that specifies Must Do/Must Not Do, and verification against those axioms. That's not the same level of verification as line-by-line/instruction-by-instruction avionics code, but it's a heluva lot more than we get now.
Structural engineers (my father was one) don't have a union and they don't get their degrees from trade schools.
The do have a professional society that is fully engaged in licensing, educational standards for engineering curriculum, and a career path that leads to the necessary experience to qualify for a license, along with testing. They also collaborate with the state Engineering licensing agencies.
On the other hand in computing, at least some of the professional societies have actively argued against licensing. I remember one debate that went something like, "Beauticians are required to have licenses. Should we be like beauticians?" To which the response was, "Doctors have licenses. Should we be like doctors?"
Actually, I have developed software applying DO-178B (although not to Level B/A) for air traffic control, and to Mil-Std 882D for a project that included networked fires and autonomous potentially armed vehicles. On the latter project, I was the lead software safety person for a while.
And to the follow-on comment: Yeah, there's a lot of work to get the hazards and the requirements down to the level that verification against those has real impact. That's part of the job.
and I've been calling for professional licensing and liability for software engineers for at least 30 years. That should follow the approach for other Professional Engineers, including the use of 'engineering practices' as a defense.
The software community has done an appallingly shitty job with software reliability. (Exhibit 1: CERT database of software vulnerabilities.) It's way past time they get held accountable. And yeah, this will slow things down and require people do things right the first time, and it will put a serious dent in the management approach to "throw the cheapest bodies at the software problem, and damn the bugs!" Product liability needs to include both corporate and individual liability.
Email outsourcing companies don't seem to place much value on following rules like SPF and DMARC. A lot of the false positives we get in quarantine are from senders using email outsourcing or "relationship management" companies. After all, the company gets paid by their customer for sending the mail, and has no real accountability whether the customer's email is properly formatted and delivered.
And with large institutions (particularly universities) moving to outsource email and other IT services, this problem will get worse.
(By the way, the same concept applies to phone spam: reliable/unforgeable Caller ID would probably shut most of that down. Of course, that would require the Telephone Companies to make changes. Caller ID should either be 'guaranteed' or the incoming call marked as "no Caller ID" when the caller's phone number can't be verified.)
Well, some research shows you have to download some code, install it on your machine as an RPC server, and then use the command line to get to "LBRY://"
Does this strike anyone else as fraught with IA concerns?
I'm all in favor for open repositories for Creative Commons and Public Domain content, but not if I have to breach my own machine to get to it!
Huh? Not recognized by my browser.
That's not my experience, over the last 15 years where I was required to exchange PKI encrypted emails with both DoD users and other contractors (Fortune 50 company through 1 person security consulting shop). I've had problems setting up/loading certificates, particularly handling root and intermediate certificates (from DoD PKI). When a certificate expires, Mail has real problems with the email. And recently I was sent a short encrypted message where it took order a couple of minutes to decrypt and display.
Those problems, I believe are a combination of flaws in Mail.app, in the underlying Mac OS X PKI support, and with PKI in general. I had similar problems with Thunderbird, which depended on little or no Mac PKI infrastructure.
Hence my posting elsewhere in this thread that it's the underlying PKI infrastructure at the OS level that is at least partly at fault, and I think the complexity of the PKI design explains much of the reason why PKI infrastructure is so messy. What looked good on paper didn't scale and had real usability problems even for relatively sophisticated users. It's certainly not ready for the casual user!