Dumb things to do with your FreeBSD

I had the MVS consoles of three virtual machines open in three windows, and the production console, which I only had read-only access to, in a fourth. Went to shut down a virtual machine, but accidentally typed my command in the production window. Production system came down. Operations was cool. They said “I didn’t know you had command access to the production system.” I said “I didn’t, either. Please take it away.”

Did that as a grad student, on a MVS system. We had a weird setup, using IBM's base MVS, libraries and linker, but Fujitsu's Fortran compiler (because it was better). Note that I was a completely normal unprivileged user. One day I decided to organize my code better, by breaking up the main program into subroutines. The most important one I called "main()", which seemed to make sense to me. Compile, link, and the MVS system that serves 500 people crashes. Oh well, that happens occasionally. Come back half hour later, edit my code a little bit, compile, link, and computer crashes again.

The next time I went to the big terminal room that was after lunch, and right after I logged in, one of the operators (in the usual white lab coat) came over and tapped me on my shoulder: they had tracked down whose actions had crashed the machine. So a few systems programmers came over, and asked me to show them exactly what I had done. So I showed them, and (as to be expected) the machine crashed a third time. They were amazed, and told me to stay off the computer completely for a day or two.

Ultimately, it was easy for them to debug: in MVS, the linker is a privileged system program, and as such it is not bound to resource limits (such as how much memory it can consume). There was a slight incompatibility between the IBM linker and the Fujitsu compiler, which lead to the following: The Fujitsu compiler already quietly creates a subroutine called "main()", which contains the entry point of the program. The linker knows that main() is special, and is where the program is to be started. But then when trying to link in all the required subroutines, it found my own copy of main(), which has the same name (which can not happen!) but a subtly different calling sequence (it is not an entry point). So the linker added a copy of my main to the executable it was building in memory (you can see where the story is going). Then it noticed that the subroutine called main() was calling another subroutine called main(), but confused the two of them, and added another copy of my main(). And it repeated that last step, until it had consumed all memory on the machine, even the memory reserved to the OS itself, leading to an instantaneous crash. If the linker had been a normal user-level program, it would have crashed cleanly and the other 499 users wouldn't even have noticed, but because it was exempt from resource limits, it could "eat the whole thing".

The fix is trivial: Never write a subroutine called main() in Fortran, call it central() or work() or master() or use a German word instead.
 
...But they didn't support MS-DOS (which in those days could use TCP/IP by buying an Ethernet card and installing some bizarre hacky software (either commercial from FTP software or K9something). So one grad student decided to do it himself, and brought the whole network down by using the address of the gateway as his address.
I managed to get a DOS machine on to a TCP/IP network using Novell ODI drivers. I even managed to make it be dual-homed. I still consider that one of my best hacks.

The second time was in the late 90s, and I was working at a company that sold big industrial equipment to semiconductor fabs. One of our machines got shipped to the biggest and most influential chip maker of the time, in spite of having failed QA testing in house (we needed the revenue, and the QA director who wanted to veto sending the machine to a customer was overruled). It brought down the whole network in the fab, and it took <insert famous chip maker here> 3 days to restart chip fabrication. Not going to discuss all the fallout from this, but it was a blood bath.
Yeah, I tried to get us to not ship broken software to a large financial services company, but I was only a lowly CPE (Current Product Engineer.) At least I had a patch ready when they complained.
 
Once I had the newest backboard , dual core.. But it was another voltage not 220. This board only give fume.
My boss told , this can happen.
 
Dumbest thing I did, huh... Some of those qualify as 'learning experiences' that simply took up a LOT of my time - like trying to compile a few compilers like GCC on weak processors like a Sandy Bridge i5 2467M. Or another time, I wanted to assemble a computer from aftermarket parts (so that I could install FreeBSD on it). Bought a cheap $20 USD Apevia PSU. It fried the motherboard, so I had to get a replacement, which was over $100 USD... in addition to a ~$50 USD EVGA PSU. Lesson learned from that experience - don't cheap out on components from unusual brands.
 
Dumbest thing I did, huh... Some of those qualify as 'learning experiences' that simply took up a LOT of my time - like trying to compile a few compilers like GCC on weak processors like a Sandy Bridge i5 2467M. Or another time, I wanted to assemble a computer from aftermarket parts (so that I could install FreeBSD on it). Bought a cheap $20 USD Apevia PSU. It fried the motherboard, so I had to get a replacement, which was over $100 USD... in addition to a ~$50 USD EVGA PSU. Lesson learned from that experience - don't cheap out on components from unusual brands.

My lesson about the perils of cheap components was learned back when Donald Becker wrote drivers for NICs at NASA.

An easy failure occurs when a part no longer powers-on. A hard failure occurs when a part works 99.9% of the time. It took eighteen months of intermittent failures to diagnose a hard failure with a recently bought, bespoke but cheaper than 3Com NIC. Never again!
 
I purchased ten 4G SCSI drives in ~1994 (when they were $1K/each). I was using them as *external* drives on which to store archives.

Instead of relying on some likely-to-be-unsupported-in-the-future RAID card (or software solution), I opted to simply make duplicate copies of each drive. As such, I had two copies of a ~20G of archive.

Shortly after an upgrade, I mounted one of these -- and watched the volume crash! "Yikes! Good thing I have a duplicate copy of that!"

And, of course, when I mounted the duplicate copy, *it* crashed, as well.

In hindsight, there was a bug in the SCSI driver that this make/model drive happened to tickle. So, if I had continued with other drives from the archive, they also would have crashed. :mad:

I rolled back the OS to the previous version (which obviously did not have this problem as I had used it to create the drives). Then, restored each of them from a THIRD copy that I had on MO media.
 
Yeah, I tried to get us to not ship broken software to a large financial services company, but I was only a lowly CPE (Current Product Engineer.) At least I had a patch ready when they complained.
An employer I worked for had one of its divisions pack up all of the PIECES of a product they were designing and ship it to their (first) customer, just prior to the end of the year to get the sale "on the books". After the New Year, the customer returned to work and unpacked the boxes. And, promptly shipped them BACK ("What is this sh*t???"). So, the banner year earlier was immediately followed by a dismal year thereafter.

This sort of thinking seems to be commonplace in American businesses -- "let the NEXT guy worry about it!" I suspect one simple fix would be to pay executives HEAVILY with stock options (and a modest "salary") -- that can't be exercised for MANY YEARS into the future! So, short term decisions that end up having long term repurcussions affect them, personally!
 
  • Like
Reactions: bjs
An employer I worked for had one of its divisions pack up all of the PIECES of a product they were designing and ship it to their (first) customer, just prior to the end of the year to get the sale "on the books". After the New Year, the customer returned to work and unpacked the boxes. And, promptly shipped them BACK ("What is this sh*t???"). So, the banner year earlier was immediately followed by a dismal year thereafter.

This sort of thinking seems to be commonplace in American businesses -- "let the NEXT guy worry about it!" I suspect one simple fix would be to pay executives HEAVILY with stock options (and a modest "salary") -- that can't be exercised for MANY YEARS into the future! So, short term decisions that end up having long term repurcussions affect them, personally!
Yeah, nice story, but what does that have to do with FreeBSD? This story is pretty independent of any OS...
 
Yeah, I tried to get us to not ship broken software to a large financial services company, but I was only a lowly CPE (Current Product Engineer.) At least I had a patch ready when they complained.

<story>

Yeah, nice story, but what does that have to do with FreeBSD? This story is pretty independent of any OS...
The same thing the quoted text that I was replying to does.
 
I have increasing git problems. Repeated instances of:

Build world without updating src first.

Make a new branch but forgot to check it out and commit to the wrong branch.
 
This example is Linux, but it could work like that with BSDs, too.

Just installed Arch Linux into some partitions on a USB SSD. When in a Thinkpad T14 gen2 intel it boots into this arch install. So far so good. Connecting the same USB drive to a z390 desktop it suddenly boots into Devuan. No changes made to disk or bios and no manual selection.

Anybody wants to guess?
 
Just installed Arch Linux into some partitions on a USB SSD. When in a Thinkpad T14 gen2 intel it boots into this arch install. So far so good. Connecting the same USB drive to a z390 desktop it suddenly boots into Devuan. No changes made to disk or bios and no manual selection.

Anybody wants to guess?

the arch setup is maybe an EFI-only boot and the z390 has a higher priority on a legacy BIOS-based boot? try to disable CSM boot on the z390. also try to unplug other internal drives just to double check.
 
Back
Top