“do it again, I wasn’t looking”

  • 0 Posts
  • 19 Comments
Joined 1 year ago
cake
Cake day: September 25th, 2023

help-circle




  • If it wasn’t obvious that the Debian box is a parody, here’s what the Japanese Chinese text along the top reads on each box:

    Please read the instructions carefully and use it under the guidance of a physician. It is strictly prohibited to be used in food and feed processing.

    Please read the installation instructions carefully and use it under the guidance of the administrator. It is strictly prohibited to use for server installation.

    so yes, the title is correct-- this is not a coincidence, the Debian box was made explicitly for this joke

    edit: thanks for the correction folks, honestly thought it looked more like Japanese than Chinese at first glance and I am obviously not an expert in either. Appreciate the call-out, very deserved.




  • Red Hat

    No, you’re angry at IBM. When news of the IBM acquisition broke, sector veteran colleagues I’m close with moaned and groaned that IBM was sure to do something to piss everyone off again, which was apparently their habit a couple decades back. Sure enough, they could not have been more accurate in their assessment.

    Turns out IBM is three hot messes in a trenchcoat and always has been. Hence why they have already lost the Quantum wars and likely the GenAI wars as well. One AI vet I know says they’re posed to even lose the AI war altogether, which is pathetic given the groundwork provided by Watson alone.






  • If I were to fully elaborate, I’d be typing for hours, so I’ll sum up:

    • pip - default behavior is to install to system-wide site packages. In a venv, it will try to upgrade/uninstall system packages without notice/consent unless you specify --require-virtualenv. Multiple things can fuck up your ENV to make the python binaries point to system-wide, while your terminal will still show you as in a venv. Also why TF would package metadata files need to be executable? Bad practice, -1/10
    • nix - they acknowledged years ago that they should probably have some kind of package signing and perhaps an SBOM or similar mechanism, but then did nothing to implement it and just said “oh well, guess we’re vulnerable to supply chain attacks, best not to think about it”
    • brew - installing packages parallel to your system packages manager, without containers. My chief complaint here is that brew is a secondary package manager that people might treat as a “set and forget” for some packages, rarely updating them. So what happens when a standard library used by a brew package is vuln? A naive Linux user might update their system packages but totally forget to update brew. And when updating brew, you can easily hit max_open_file_descriptors because kitchen sink

    From there, it’s all extremely nit-picky and paranoid-fueled-- basically, none of the package managers I mentioned are conducive, in my eyes at least, to a secure and intuitive compute environment.

    Unfortunately, there’s not much I can do about it except bang pots and pans and throw maintainers under buses when the issue that has been present for years rears it’s ugly head. Because they are the only ones who can change this, and pressure is the only thing that might motivate them to.