Only if he uses Linux and insists on anal as a form of contraception. 😂
I’m a computer and open source enthusiast from Toronto, Ontario, Canada.
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?
His analysis and analogies are actually pretty good, except he ruins it all with his cringy intro and outro. That’s disappointing.
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!!!
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:
Note: if you used zfs of btrfs, do not do steps 3 and 4; they are MD RAID specific.
Legacy API and app behaviour support. Ironically replacing the registry with something more straightforward would be relatively easy, unlike adding support for storing home directories on a drive other than C. Technically you can mount a different filesystem under c:/users to achieve this, but AFAIK that’s neither supported nor trivial to do.
I tried doing it, and gave up. Sure, most software will respect the path changes in the user’s registry hive, however, every once in a while a program will just assume that your home dir lives under c:\documents and settings$username - and that’s when it all goes south. Really frustrating this lack of consistency.
All in all, the OS is riddled with hacks and “supports” for legacy runtimes and behaviours. Heck, my username is poking fun at the fact that Windows 7 had support for the 386 (yes, Intel’s 80386 processor from the late 80’s) enhanced API. Windows 7…. My username is a “tribute” to a file called krnl386.exe that implemented a bunch of legacy API calls like how much RAM a system has or whether or not the OS is running in “386 enhanced mode” that were relevant back in Windows 3.x days… and still supported in Windows 7. That pretty much sums up why Windows is, and always will be, a hot mess.
That is how you learn! Actually one of the best ways to learn, IMHO.
Ah, that would break things! Any idea how the incorrect UUID got into the kernel boot parameters?
Windows is difficult to repair mainly because of the registry, IMHO. Microsoft’s claims that it should never require cleanup doesn’t really make sense… it’s the most practical advice given how convoluted it is, but the fact that a database that keeps getting written to constantly doesn’t ever need any kind of maintenance just doesn’t make sense to me.
To be fair, average users would never (or should never) encounter such an issue. The person asking uses Arch (I think?) which is by far not an “average person” distribution.
Weird… the only thing I can think of is that maybe the UUID changes on every boot with live USBs, since the root filesystem is ephemeral …
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??