Halls of Shrewd'm / US Policy
No. of Recommendations: 3
According to what I just read the whole mess was created by a combination of faults at crowdstrike, one of them ignoring the update policies of their clients and rolling an update onto all machines even if a customer's policy did expressively excluded an update with the newest version.
But what baffles me the most is that apparently said update brought windows down because of a NULL pointer exception in a kernel driver that was not handled.
Here are so many former or still privately active programmers. Would that have happened to us old guys? Super-important code without proper error handling? I don't think so. Sometimes "In former times all was better" is not completely wrong 🤣
No. of Recommendations: 13
Here are so many former or still privately active programmers. Would that have happened to us old guys? Super-important code without proper error handling?
Speaking as an old programmer, it's safest to assume there were always (and will always be) bugs, many of them harsh enough to cause a crash.
But at the very least you can have a process that tries to test the software before sending it out, which seems to have been (ahem) lacking here. Testing processes definitely won't catch all the bugs or create reliable systems, but hey, it helps. You have a good chance of detecting bugs that cause fatal crashes almost immediately.
Jim
Fun with bugs:
Run this on a Motorola 68000 processor.
int a,b,sum;
a = 0x2fdedab8;
b = 0x000cd925;
sum = a + b;
printf("%d (%x) + %d (%x) = %d (%x)",a,a,b,b,sum,sum);
Depending on the date range of your CPU chip, it gives the wrong answer every time because of a bug in the silicon. There are certain numbers it just can't add. If your hardware can't reliably add two integers, you are NOT going to be able to ship bug free code.
Incidentally, you'd be amazed at how long it took to find this bug and create a minimal program to duplicate it. It was a very large and complex communications system using checksums which strangely mismatched for no reason once in a while: sometimes the two systems communicating had different shipping dates of CPU, and one in each gazillion packets the checksum calculation would need to do this addition.
No. of Recommendations: 1
schools teach Java and Python nowadays. People who are good c++ programmers are becoming rare.
Also, I don’t know the details but MSFT ‘s OS is too easy to crash. Why this didn’t happen to Mac?
No. of Recommendations: 0
Nadella says they allowed direct access to the kernel to compromise with European regulators
Apple never would have been that stupid
No. of Recommendations: 3
But at the very least you can have a process that tries to test the software before sending it out, which seems to have been (ahem) lacking here. Testing processes definitely won't catch all the bugs or create reliable systems, but hey, it helps. You have a good chance of detecting bugs that cause fatal crashes almost immediately.
This is exactly it! All code has bugs, or at least potential bugs.
But this was a bug PLUS a HUGE process error. They allowed the bad update to go out to "everyone" instead of sending out to 10 units ... and checking if all is well, then 100 units ... and checking if all is well, then 1000 units, then 10,000, then finally "everyone".
No. of Recommendations: 1
Fun with bugs:
Run this on a Motorola 68000 processor.
int a,b,sum;
a = 0x2fdedab8;
b = 0x000cd925;
sum = a + b;
printf("%d (%x) + %d (%x) = %d (%x)",a,a,b,b,sum,sum);
I have a vague memory of an Intel bug in the 1990s, may be FDIV.
I could bring down our school's mainframe by just running
main() { main();}
No stack protection in the CPUs.
CrowdStrike apparently did have an automated test software called content validator, and this so-called fix passed it. So nobody ran it manually.
CRWD deserves to GTZ. Who releases a critical patch on Friday?
No. of Recommendations: 3
Run this on a Motorola 68000 processor.
I loved the Motorola architecture. Sadly the xxx86 architecture won. Writing assembly code for that architecture is physically painful.
No. of Recommendations: 9
I loved the Motorola architecture. Sadly the xxx86 architecture won. Writing assembly code for that architecture is physically painful.
I hear you. And don't get me started on little-endian architectures! It's just plain wrong. I can't live without "od -x", so I just refuse to look at the low level encoding : )
Jim
There is no curmudgeon like an old programmer curmudgeon
"Why, when I was a boy, floppies were floppy! You could read the bits with a teeny tiny compass if you needed to!"
No. of Recommendations: 3
I spent a pleasant summer at AT&T Pixel Machines programming the DSP 32C, which was something like a 32-bit PDP-11 with fast floating point. 68020 was nice, but I actually enjoyed writing some assembly language for the DSP 32C.
No. of Recommendations: 8
I spent a pleasant summer at AT&T Pixel Machines programming the DSP 32C, which was something like a 32-bit PDP-11 with fast floating point. 68020 was nice, but I actually enjoyed writing some assembly language for the DSP 32C. Maybe serious programming
shouldn't be easy. All I ask is that nobody here on the board bid against me for Paul Allen's Cray-1 : )
https://www.christies.com/auction/pushing-boundari...I presume it is now merely a sculpture. As I recall, you need a different model of Cray-built minicomputer just to boot the sucker, and MTBF was about 50 hours even when it was new, assuming you did the two hours a day of preventative maintenance. But I still want it. I've been trying to track down a complete-but-empty original cabinet for sale for 20 years.
Jim
No. of Recommendations: 5
programming the DSP 32C, which was something like a 32-bit PDP-11
One of my earliest jobs was writing assembler for RT-11. It was only 16 bits, but they were all mine...
Rgds,
HH/Sean
