I’m a computer and open source enthusiast from Toronto, Ontario, Canada.

  • 1 Post
  • 73 Comments
Joined 1 year ago
cake
Cake day: July 3rd, 2023

help-circle






  • 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.












  • 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.



  • 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.