[–] 1 point 1 month ago

Basically you want something that will hash the file contents and compare hashes, this gets around filename differences.

Define where your "final" location will be and compare each drive to that (the 1st one will be the starting point, so pick the best , largest drive

fdupes / rmlint will get you most of the way there.

Then you'll want to compare similar files, so maybe something like meld or beyondcompare might help.

This will take a loooong time, but will be worth it

  • source
  • [–] 10 points 1 month ago (1 child)

    You picked a particularly rare example. Meaning it was a combination of unexpected use case and 10+ years of deprecation happening to coincide at the wrong time and place.

    Even if you had your supposed compatibility layer in place human error or misunderstanding is still going to cause issues like this from time to time.

    The DT_HASH issue was specifically NOT an api breakage. It was some apps consuming some internals without keeping track of changes. Yes, they technically broke backwards compatibility. But those apps weren't supposed to be using that field for a long time.

  • source
  • parent
  • context
  • [–] 11 points 1 month ago

    I think you’ve gotten a really bad read of my article. We know the typical Linux stack has problems with libraries failing to maintain backward compatibility

    We do? I certainly don't. Which libraries? That's likely not a generic Linux issue. That's more probably a specific issue with those specific libraries or distros.

  • source
  • parent
  • context
  • [–] [S] -3 points 1 month ago (1 child)

    I think you’ve gotten a really bad read of my article. We know the typical Linux stack has problems with libraries failing to maintain backward compatibility and even when they do, the guarantees are nowhere near as strong or long-lasting as on Windows.

    The problem is ultimately cultural. My article is essentially an appeal to anyone willing and capable of building a sane userspace through a single distribution. If that distribution adopts the stack, others can copy it or diverge at their own cost.

    As for separating the userspace from regular applications, the point is that the OS shouldn’t treat system packages and user packages as the same thing. That’s separation of concerns, not a contradiction.

  • source
  • parent
  • context
  • [–] 7 points 1 month ago* (2 children)

    That's OOP: https://xkcd.com/927/

    If I understand OOP correctly, the NT compatibility promise is the idea that not only the kernel but also the userspace is standardized, backwards compatible and stable.

    OOP really doesn't seem to understand how Linux works under the hood and what the issue is.

    The main problem is not that e.g. installed libraries are in different paths under different distros, but that installing libraries is different between different distros, and that different versions are available.

    A library package might be called libXYZ-dev in one distro and libXYZ-devel in another, and in the third distro it's not even available or available in the wrong versions. That's the real problem, and OOPs approach of splitting package distribution from the stability of the user space is completely contrary to their proposed solution.

    They just assumed two contradicting goals would somehow make a coherent whole.

    That author just saw Windows and didn't understand why that system works, saw Linux and didn't understand why there's fragmentation problems there and thought that applying the Windows model to Linux somehow magically works.

    Edit: I just noticed that the OP and the author of the blog post have the same user name and thus likely are the same person.

  • source
  • parent
  • context
  • [–] [S] -2 points 1 month ago* (last edited 1 month ago) (4 children)

    Why has there been recent issues with compatibility with the userspace then? from systemd to even not so distant news of glibc failing? The article goes a bit more in depth about what needs to be done, it describes a different packaging and distribution model as well that is simpler and more convenient in design.

  • source
  • parent
  • context
  • [–] 25 points 1 month ago (16 children)

    At least skip the Reddit link and post the source...

    https://parallel-minds0.github.io/An-Open-Letter-on-Linux-Compatibility/

    From a quick skim, I think the author doesn't really know that much about how Linux and its various components and libraries actually work. Though it seems they are loosely proposing somebody new compatibility layer?

    And what is this supposed NT compatibility promise?

    The Linux kernel has maintained strict backwards compatibility at the user space level for ages.

    Individual libraries are versioned and can be kept around for as long as anyone likes.

    Package management and dependencies might be a bigger problem, but I would guess a manageable one?

  • source
  • [–] 15 points 1 month ago* (6 children)

    Nah that kid was just autistic.

    These slop kiddies "sold out" in the way that every generation before them knew was categorically deplorable.

    The real concern about younger generations isn't just that they're low key dumb af; it's how conditioned they are to see the world as a lottery you win and not a challenge you overcome. An entire generation planning their life around capitalizing on their 15 minutes of fame and willing to be owned by whoever will give them a luxury dog house.

  • source
  • parent
  • context
  • [–] 12 points 1 month ago* (last edited 1 month ago)

    I've contributed to free software projects in some capacity or other since the 80s. I've done my bit. I don't owe anyone anything.

    But yeah you're right: if AI turns every Tom, Dick and Harry like me away from computers, it'll kill free software. Yeah it's sad, but like I said, fuck computers. I don't really give a turkey.

  • source
  • parent
  • context
  • [–] 14 points 1 month ago

    Problem 1 is also largely solved by ditching GitHub in favor of an environment where you control who is allowed to submit a PR. GitHub is convenient but if you have problems with vibe code volume, choosing to host with a company who heavily incentivizes it and has a commercial interest in doing so is self-defeating. Treat it the same as any other free service that enshittified after several years of market capture on the basis of being free and convenient.

    Problem 2 is the actual reason the project tanked and your take is spot on.

  • source
  • parent
  • context
  • [–] 7 points 1 month ago

    I've already done this myself 🙂

    This is not the first time I find software engineering utterly stupid and decided to do something totally different. I did this once in 2002 already, when I figured web "development" - which seemed to be what everybody would be doing soon at the time - was so damned dumb I'd better leave the field of computers altogether.

    And I did: I quit my job and enrolled at my local community college to retrain as an adjuster / machinist.

    And you know what? That was the best thing I ever did in my life. Even when I started doing programming professionally again a few years ago, I found having both blue and white collar skills is highly sought after by employers.

    So yes, I wish you luck, and I'm sure you'll enjoy your career move every bit as I did mine.

  • source
  • parent
  • context
  • [–] 14 points 1 month ago (1 child)

    So this is one of those subject myself and my coworkers talk about all the time now. So many of these younger coders just use LLMs to code shit and it's bleeding into commercial products now.

    We talk about when all this shit comes crashing down due to all of these new programmers having no grasp on programming or software architecture and we can charge out the ass like when Y2K came.

  • source
  • parent
  • context
  • [–] 33 points 1 month ago

    Don't blame the guy for having to work with idiots that have no clue about the system, about the code base, how it's used, and fucks over everyone in the project because a LLM told them to just to get a thank you email by a corporation, if that.

  • source
  • view more: ‹ prev next ›