![](https://lemmy.ca/pictrs/image/6a8e7cae-3764-4d7f-b5e9-bc756de7f7b3.jpeg)
![](https://lemmy.ml/pictrs/image/h1ChnLuBHr.png)
Wow, beautiful analogy! I’m going to use that in my professional career if you don’t mind. Also with your permission I’d like to give you credit with a link to this comment, if that’s OK with you, of course.
I’m a computer and open source enthusiast from Toronto, Ontario, Canada.
Wow, beautiful analogy! I’m going to use that in my professional career if you don’t mind. Also with your permission I’d like to give you credit with a link to this comment, if that’s OK with you, of course.
I wonder if this has anything to do with Apple’s CSAM scanning. You know, hang on to the photos as evidence, and, for an added bonus, sell more iCloud storage because the “System Data” now exceeds the free iCloud data storage quota. Win-win!
If it is indeed a boneheaded mistake, then it’s probably because of over reliance on RPC-type calls from the front-end that displays the data, to the back-end that actually handles the data. User deletes photo, and the front-end, instead of actually deleting it, tells the backend to do it… and then hides the photo from view, maybe updates its index of photos marking them as “deleted” regardless of whether the backend actually deleted the photo.
Then an OS update comes along, and rescans the filesystem, and report a bunch of new photos to the front-end, that then happily add them to the GUI to the user’s surprise.
Modern APIs and software architectures are a bloated, unnecessarily complex mess, and this is the result.
Actually the ad matches the article. To me the ad is “fringe” and it has infested the “mainstream” (CNN).
Wasn’t Google Plus used to be called Circles? Man, I feel old!
You should see/try socialist/communist toilet paper. Not only is it thin like this, it will also no-so-gently exfoliate your anus.
Source: Cuban resorts and lived experience in the former Soviet Union during the 80’s and early 90’s.
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 …
I think the key would be figuring out where this extra UUID is coming from. Maybe next time you try this, make a note of all the UUIDs on your system (including the bootable USB) and see which one ends up in the bootloader config.
Knowing what’s happening can help guide your Googling to find out why it’s happening and how to fix it.
Gentoo and Arch docs in general are amazing.
Congrats! I bet you learned a lot along the way…
I presume these are filesystem UUIDs. I also presume from your other post, that you used a live USB to fix nvidia drivers? Note that nvidia driver installers/packages trigger a initrd rebuild, and if you do that in a live environment, it’s possible that you will get the UUID of your live USB filesystem and not your actual boot drive… at least that’s my guess.
If you booted into a live USB you need to make sure that you chroot into your install on your disk whenever doing any operations on the boot loader. That involves mounting your actual disk (eg, /dev/nvme0p1) somewhere on the live USB (eg, /mnt/example), then bind-mounting the proc, sys, dev, tempfs filesystems under /mnt/example/proc, /mnt/example/sys, etc. You may also need to mount /efi under /mnt/example/efi or boot/efi (wherever you have it in your system). Next, chroot to /mnt/example. You should now have a fully functional install you normally boot into, with the only difference being that the kernel booted off the USB drive. Now you can try reinstalling drivers, rebuilding initrd, reconfiguring the bootloader, etc. Since you’re chrooted, the system should see the proper UUIDs, in theory…
If you want a more comprehensive tutorial on how to do this, look for bootloader fixing tutorials.
Librewolf is probably a safer choice.
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?