This week, the developer of the popular npm package 'node-ipc' released sabotaged versions of the library in protest of the ongoing Russo-Ukrainian War. The 'node-ipc' package, which gets downloaded over a million times weekly, began deleting files on developer's machines, in addition to creating new text files with "peace" messages.

Lmao

Hate the government yadda yah

    • mittens [he/him]
      ·
      3 years ago

      Rolling release distro packages are not thoroughly tested and usually offload some of that testing work to the end user. That's why rolling release distro users are expected to be savvy enough to work their way around a command line to at least downgrade packages if needed.

      • captcha [any]
        ·
        3 years ago

        rolling release systems do test their packages before they release but its usually just that package in particular. They don't always test how packages that depend on it will work. So if library A updates from version 1.1 to version 1.2 application B which depends on library A might start having bugs if it wasn't developed against libA 1.2.

        That said, they still will do cross compiling so if libA updates to 2.0 and appB no long compiles anymore they'll usually hold off releasing libA2.0 until all core apps that depend on it are upgraded, as with major libraries like GLIBC. Or release libA1.0 and lib2.0 separately.

        For community or user submitted stuff its wild west though.

    • PorkrollPosadist [he/him, they/them]
      ·
      3 years ago

      Debian does have a glacial release cycle, but it is not a requirement for releases to be so far apart. Fedora follows a similar model but cuts releases every 9 months, for instance. Ubuntu falls somewhere in the middle and cuts releases every year or two.

      Rolling release distros like Arch, Gentoo, Fedora Rawhide, etc. abandon the idea of having discrete release versions but they still track the versions and stability of individual packages. They still follow a similar trajectory from unstable to testing to stable. In Gentoo this takes the form of non-keyworded version 9999 packages (straight from git HEAD, masked by default), ~arch keyworded packages (tagged releases with version numbers, but which still require testing, masked by default), and ordinary arch keyworded packages that can be installed without flipping any switches. ArchLinux maintains separate repositories for stable and testing packages as well (though I'm not as familiar with their workflow).

      The main point though, is that all these packages are still hosted on the distribution's infrastructure (or in the case of Gentoo, the upstream source code must match a cryptographic hash which is hosted on Gentoo's infrastructure). There is one organization (the distributor) which is responsible for "certifying" packages as stable, and the contents of those packages cannot be changed arbitrarily by the tens of thousands of upstream sources. No distribution could possibly function if that were the case.

      Rolling release distributions still only install stable packages by default. You still need to go out of your way and explicitly tell it to install a testing package or the completely untested code that got committed five minutes ago. Stable packages are still not allowed to depend on testing/unstable packages. The main difference is that packages can have new releases tagged, and those releases can have their status upgraded from testing to stable at any time, rather than once every 9 months/years. Every distribution is different, but in Gentoo (and any sane distribution), unmaintained packages get removed, rather than having updates promoted blindly. If no one is willing to sign off on it, there's probably a reason you gotta figure out how to do it yourself.

      Since collection of installed package versions changes continuously, rolling release distributions don't get the same kind of holistic release testing that something like FreeBSD or Debian or Fedora does, but the packages do receive testing as individual units.