The author has a Master’s in informatics. That’s pretty much like an MBA. I wouldn’t expect more than buzzword-bingo from someone like that.

Python? This will require “specialized hardware” just due to the interpreter overhead taking continuous screenshots of everything you do and indexing/storing them. Why bother implementing something like this using an interpreted language??

Only if he uses Linux and insists on anal as a form of contraception. 😂

Well, as a feminist, I’m choosing the wolves.

That’s a decent workaround for a laptop with a broken keyboard.

If you’re that worried, why not run chmod -R u+w .git inside the project dir to “un write-protect” the files, then just ascend to the directory containing the project dir (cd …) and use rm -r without -f?

The force flag (-f) is the scary one, I presume?

Whoah, isn’t FUTO the non-profit that Louis Rossmann works for? This is great news!!

His analysis and analogies are actually pretty good, except he ruins it all with his cringy intro and outro. That’s disappointing.

If this is their attitude to a clear self-inflicted fuckup, then that’s plenty reason for me to avoid them and their services. It’s not like their services were distinct in any way… just a dime in a dozen cloud provider.

Google reminds me more and more of Microsoft of the 90s. That’s exactly the kind of compatibility breaking asinine move MS would do 30 years ago. Sigh…

I think descriptive and useful error messages are OK to report as enhancements. They don’t have to be functional bugs.

Good old git blame lol! Not only can you determine when the change was made and where, it’s trivial to look up the author of the commit: https://github.com/iputils/iputils/commit/562e0d570d93cfcfdebab1215a2f04efa64a24f8

To be fair, the author’s first language may not be English…

Is anyone interested in submitting a pull request? Looks like Github contributions are accepted.

Who knows anymore with these youngsters’ vernacular?

Classic! Love this clip!!!

Better late than never and I responded! Check your DM. :)

I have the whole series as DRM-free MP3. Let me know if you want it.

Actually grub 0.x series had much more useful rescue shell tab completion than the latest release. You could easily list all boot devices, partitions, and even filesystems and their contents. All from the rescue shell. Consequently, you could boot into Linux and reinstall grub in the MBR to fix it. All that without using a boot CD/USB! Good luck doing that with the latest version of grub and UEFI.

Also getting into the BIOS on legacy firmware was also very simple. On most machines it’s the three finger salute followed by either F1, Delete or rarely F11 or F12.

The boot process was simple, and the BIOS had just one simple task: load and execute the first 512 bytes of the disk that was designated as the boot device. That’s it.

Ah yes, simplicity. MBR, with all its limitations had one killer feature: it was extremely simple.

UEFI, as powerful as it is, is the opposite of simple. Many moving parts, so many potential failure points. Unfortunately, it seems like modern software is just that: more complex and prone to failure.

Good point! I assumed the worst; but it’s possible the array is rebuilding or even already rebuilt and just needs to be mounted.

Assuming you were using a Linux software RAID, you should be able to recover it.

The first step would be to determine what kind of RAID you were using… btrfs, zfs, mdraid/dmraid/lvm… do you know what kind you set up?

To start the process, try reconnecting your RAID disks to a working Linux machine, then try checking:

1. The sudo lsblk command will help you get a list of all connected disks, sizes and partitions.
2. The partition tables on the disks, eg: sudo fdisk -l /dev/sda (that’s a lowercase L and /dev/sda is your disk)
3. Assuming you use a standard Linux software RAID, try sudo mdadm --examine /dev/sda1. If all goes well, the last command should give you an idea of what state the disk is in, what RAID level you had, etc.
4. Next, I would try and see if mdadm can figure out how to reassemble the array, so try sudo mdadm --examine --scan. That should hopefully produce output with the name of the RAID array block device (eg, /dev/md0), RAID level and members of the RAID array (number of disks). Let me know what you discover…

Note: if you used zfs of btrfs, do not do steps 3 and 4; they are MD RAID specific.