6 ms·

OpenSUSE Tumbleweed is also a great rolling release distro. For anyone that's never tried rolling release, the main benefit is that it keeps your tools/libs/ker

by umvi 3y ago

OpenSUSE Tumbleweed is also a great rolling release distro. For anyone that's never tried rolling release, the main benefit is that it keeps your tools/libs/kernel updated with the latest upstream. If you use Ubuntu (for example) it ships with some python version (say 3.8), and then it will almost never update again unless you manually install a newer python version or update Ubuntu itself to the next release (which might not exist). With something like Tumbleweed (or Rhino in this case), updates come out every few days, and every time you do an update you'll find python is now on 3.10, then 3.11, etc. It's really nice when every compiler/language is on the latest version by default.

ripley12 3y ago
> the main benefit is that it keeps your tools/libs updated with the latest. For tools you want to be on the latest version of, why not use a package manager like homebrew that isn't tied to your distro? I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.
- bravetraveler 3y ago
  A distribution is a collection of software - if reduced to a certain point, the identity is lost! It makes sense to me for a distribution to find commonly wanted software, package it up, and make it available. There's tailoring to consider! Some go further and introduce patches. Not every distribution is as good at both contributing and being accepted upstream. Now, if you want something newer, then you're obviously welcome to acquire that as you see fit. The distribution will help with that, too -- providing build utils, headers, etc. Enabling third party repositories, ie: PPA/COPR There are also runtimes to avoid building; Flatpak/Snap, Docker/Podman, etc. Though, these also lose some of the 'distribution spirit'
  - ripley12 3y ago
    This is a really good answer, thank you.
- happymellon 3y ago
  For tooling I use something like nvm, Pyenv, or SDKMan. I don't want Python to update from 3.10 to 3.11 silently, but I also don't want to be held back if they decide that they don't want to support Python 4 yet. I also want to be able to pin to particular versions if I want, or at least update in a structured way. I dislike the way that distros purge older packages, so building containers requires me to build my own package repo cache to allow me to have repeatable builds. It might make sense for the distro, but this is where the difference between the base operating systems requirements and mine differ.
- mixmastamyk 3y ago
  Brew has some sketchy practices (re system folders, telemetry). Thankfully there are plenty of alternatives… containers, flatpak, ppa, nix, tgz, etc.
  - sjmulder 3y ago
    I settled on pkgsrc, very portable, configurable, sits cleanly alongside the OS or other packages managers and has a friendly community. Con: building from source, needs some massaging sometimes.
- blablabla123 3y ago
  > I've never understood the Linux culture of tightly coupling OS and package management The ABIs are quite tightly coupled though. There's e.g. a dependency to glibc, so either you make a compromise and use the oldest common glibc or ship packages for various glibc versions. So unless everything is built from source, this approach has its limits. edit: of course it's possible to use static linking but even then there's a residue of calls that are dynamically linked at runtime. (That's why there's flatpak, snap, ... which bundle dependencies redundantly)
- jwells89 3y ago
  Where to draw the line is fuzzy and probably subjective, but to me it seems natural for "system" packages to be updated and managed entirely separately from user-installed packages of all kinds (not just things that get wrapped in flatpaks or shipped with their jungles in Docker), even if that means dependency redundancy. I think for most people trading off some storage for assurance that user packages can never ever influence or worse, break the environment would be worth it.
  - ripley12 3y ago
    That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.
    - ElevenLathe 3y ago
      IMO two tools is reasonable -- something like homebrew or guix plus the system package manager. The frustration sets in when you realize you actually use a dozen: pip, npm, go get, Docker (which has the same problem again, fractally), homebrew, tfenv, gem, rvm, the list goes on. If you are in an environment where there is even cursory review of your dependencies, it can become a nightmare. This is the origin of (also nightmarish) inflexible corporate policies like "we are a CentOS shop: don't use anything that isn't in those repos without a months-long review and sign off from the VP of infosec."
- jcastro 3y ago
  | but I seem to be in the minority. Every time one of these threads comes around it's like the same thing on repeat: "I could either learn how to use a container or dist-upgrade my entire operating system to solve this."
- michaelmrose 3y ago
  If you peel off the layers that have accrued in some distros centralized package management is incredibly simple to implement and effective and met the performance,security, stability, and storage needs at the time of implementation. Think of it like manual transmissions. Consider the package management system of Arch or Void for instance. As in all cases where one technology supplants another its not enough to be superior in one dimension it's a hard sell unless its not only better but substantially better for all concerns without substantial cost or downside or foisted on users from on high by someone that can't fire by switching brands. For instance app images have been a thing for a while but nobody formalized it with a store with standards, security, testing for actual not theoretical compatibility etc so its a tool you can pick up rather than an actual ecosystem a user can rely on. Nix/guix are cool as heck but they are also complicated and difficult to understand. They can also have issues not present in the source software VMs are of course unwieldy App vms are restricted to Qubes Snap relies on a proprietary backend and starts slow among many and varied flaws. Flatpak still starts slower than native, doesn't have most software, isn't suitable for libraries or software that will be consumed by non flatpaks, doesn't have most software. Homebrew is mostly used by expats from Apple land because its virtues are moreso leveraging existing know how and work flows. Docker/Podman are more like developer tooling than user tools. Bedrock Linux is for crazy people who wish arch and ubuntu were one distro Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo
  - doubled112 3y ago
    > Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo It already has the exported .desktop files, right? I wonder why they didn't just (ab)use that mechanism and add it to the default path on install
    - michaelmrose 3y ago
      It has desktop files. You could trivially add scripts named foo but you can't stick them somewhere global because the flatpaks actually exists in the users home dir but having a ~/bin is not standard either. It doesn't exist because it doesn't aesthetically fit. You can create it for yourself of course.
- rlpb 3y ago
  > I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority. It allows one side of your artificial divide to specify dependencies on the other. I can conceive of a packaging system that is designed with your split in mind and can cross that gap, but today no such system exists.
joseph 3y ago
I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.
- mixmastamyk 3y ago
  Python made a deliberate choice to do that, thankfully not too common.
  - joseph 3y ago
    How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.
    - mixmastamyk 3y ago
      As mentioned, they weren't bugs but multiple planned breakages. IMHO, Python devs learned the wrong lesson from the 2 --> 3 transition. Should have been, "minimize big breaks." Instead they learned, "make lots of small breaks spread out evenly and avoid X.0 releases." The result is that planning around deprecation (always be breaking) is untenable for enterprise-style development.
thewataccount 3y ago
> It's really nice when every compiler/language is on the latest version by default. I've seen breaking changes in my dependencies from 3.7 -> 3.8 -> 3.9 -> 3.10, both at work and at home. I've also had constant issues with both GCC and CUDA being too new. The reverse is true too of course - I use a rolling release specifically because of a new CUDA version that no stable distro has (or will have for many months)
zdragnar 3y ago
I found opensuse tumbleweed's swaywm pattern to be completely broken, and from what I saw in forum posts it has happened several times in the past few years. I know opensuse is vaunted for its stability, but I have yet to find a setup that I liked better than sway-flavored Manjaro, given my proclivity for tinkering. Debian +kde also seem reasonably solid, even if kde still has odd occasional bugs or inconsistencies (last I tried, I had to reboot twice after installing to get the battery icon to work in the tray).
- EnigmaCurry 3y ago
  EndeavourOS sway edition (community) [1] has been a pretty great start for preconfigured wayland+sway+waybar and various integration. I added some more stuff to my ~/.config in my own repo [2], but it was a good place to start, and EndeavourOS is basically just rolling Arch Linux with some extra niceties. The included EnvyControl [3] switcher between nvidia to integrated is nice (yea you do have to reboot tho to switch), so I have used the regular i3 config with Xorg for playing some games (nvidia hardware graphics), but use sway for my day to day use (integrated graphics on wayland). [1] https://github.com/EndeavourOS-Community-Editions/sway https://github.com/EndeavourOS-Community-Editions/sway [2] https://github.com/enigmacurry/sway-home https://github.com/enigmacurry/sway-home [3] https://discovery.endeavouros.com/hardware/envy-control/2023/03/ https://discovery.endeavouros.com/hardware/envy-control/2023...
wink 3y ago
counterpoint: Let's assume you develop a software written in Python for $dayjob and you're targeting Python 3.8 because that's where your deployment target is. It's Monday morning, you fire up your work machine and the code that was working fine on Friday doesn't run anymore. Now you're scrambling to get some version of Python 3.8 installed to /opt. TLDR: There are a million circumstances where you don't want things to auto-update (even if auto-update means: "I run `apt/yum/foo upgrade" every morning". It's a story as old as time, if you're not only a user, upgrades are (and should be) often a deliberate choice, more important the more you go from patch level towards major version. (waiting for the people to chime in that this broken anyway and you should never work without Docker, etc.pp - I know, I know. It's just a real example why I run Arch on my personal machine but am more than happy with Ubuntu LTS on my work machine. I change minor/major version when I want.)

by umvi 3y ago

ripley12 3y ago

> the main benefit is that it keeps your tools/libs updated with the latest. For tools you want to be on the latest version of, why not use a package manager like homebrew that isn't tied to your distro? I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.

bravetraveler 3y ago
A distribution is a collection of software - if reduced to a certain point, the identity is lost! It makes sense to me for a distribution to find commonly wanted software, package it up, and make it available. There's tailoring to consider! Some go further and introduce patches. Not every distribution is as good at both contributing and being accepted upstream. Now, if you want something newer, then you're obviously welcome to acquire that as you see fit. The distribution will help with that, too -- providing build utils, headers, etc. Enabling third party repositories, ie: PPA/COPR There are also runtimes to avoid building; Flatpak/Snap, Docker/Podman, etc. Though, these also lose some of the 'distribution spirit'
- ripley12 3y ago
  This is a really good answer, thank you.
happymellon 3y ago
For tooling I use something like nvm, Pyenv, or SDKMan. I don't want Python to update from 3.10 to 3.11 silently, but I also don't want to be held back if they decide that they don't want to support Python 4 yet. I also want to be able to pin to particular versions if I want, or at least update in a structured way. I dislike the way that distros purge older packages, so building containers requires me to build my own package repo cache to allow me to have repeatable builds. It might make sense for the distro, but this is where the difference between the base operating systems requirements and mine differ.
mixmastamyk 3y ago
Brew has some sketchy practices (re system folders, telemetry). Thankfully there are plenty of alternatives… containers, flatpak, ppa, nix, tgz, etc.
- sjmulder 3y ago
  I settled on pkgsrc, very portable, configurable, sits cleanly alongside the OS or other packages managers and has a friendly community. Con: building from source, needs some massaging sometimes.
blablabla123 3y ago
> I've never understood the Linux culture of tightly coupling OS and package management The ABIs are quite tightly coupled though. There's e.g. a dependency to glibc, so either you make a compromise and use the oldest common glibc or ship packages for various glibc versions. So unless everything is built from source, this approach has its limits. edit: of course it's possible to use static linking but even then there's a residue of calls that are dynamically linked at runtime. (That's why there's flatpak, snap, ... which bundle dependencies redundantly)
jwells89 3y ago
Where to draw the line is fuzzy and probably subjective, but to me it seems natural for "system" packages to be updated and managed entirely separately from user-installed packages of all kinds (not just things that get wrapped in flatpaks or shipped with their jungles in Docker), even if that means dependency redundancy. I think for most people trading off some storage for assurance that user packages can never ever influence or worse, break the environment would be worth it.
- ripley12 3y ago
  That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.
  - ElevenLathe 3y ago
    IMO two tools is reasonable -- something like homebrew or guix plus the system package manager. The frustration sets in when you realize you actually use a dozen: pip, npm, go get, Docker (which has the same problem again, fractally), homebrew, tfenv, gem, rvm, the list goes on. If you are in an environment where there is even cursory review of your dependencies, it can become a nightmare. This is the origin of (also nightmarish) inflexible corporate policies like "we are a CentOS shop: don't use anything that isn't in those repos without a months-long review and sign off from the VP of infosec."
jcastro 3y ago
| but I seem to be in the minority. Every time one of these threads comes around it's like the same thing on repeat: "I could either learn how to use a container or dist-upgrade my entire operating system to solve this."
michaelmrose 3y ago
If you peel off the layers that have accrued in some distros centralized package management is incredibly simple to implement and effective and met the performance,security, stability, and storage needs at the time of implementation. Think of it like manual transmissions. Consider the package management system of Arch or Void for instance. As in all cases where one technology supplants another its not enough to be superior in one dimension it's a hard sell unless its not only better but substantially better for all concerns without substantial cost or downside or foisted on users from on high by someone that can't fire by switching brands. For instance app images have been a thing for a while but nobody formalized it with a store with standards, security, testing for actual not theoretical compatibility etc so its a tool you can pick up rather than an actual ecosystem a user can rely on. Nix/guix are cool as heck but they are also complicated and difficult to understand. They can also have issues not present in the source software VMs are of course unwieldy App vms are restricted to Qubes Snap relies on a proprietary backend and starts slow among many and varied flaws. Flatpak still starts slower than native, doesn't have most software, isn't suitable for libraries or software that will be consumed by non flatpaks, doesn't have most software. Homebrew is mostly used by expats from Apple land because its virtues are moreso leveraging existing know how and work flows. Docker/Podman are more like developer tooling than user tools. Bedrock Linux is for crazy people who wish arch and ubuntu were one distro Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo
- doubled112 3y ago
  > Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo It already has the exported .desktop files, right? I wonder why they didn't just (ab)use that mechanism and add it to the default path on install
  - michaelmrose 3y ago
    It has desktop files. You could trivially add scripts named foo but you can't stick them somewhere global because the flatpaks actually exists in the users home dir but having a ~/bin is not standard either. It doesn't exist because it doesn't aesthetically fit. You can create it for yourself of course.
rlpb 3y ago
> I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority. It allows one side of your artificial divide to specify dependencies on the other. I can conceive of a packaging system that is designed with your split in mind and can cross that gap, but today no such system exists.

joseph 3y ago

I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.

mixmastamyk 3y ago
Python made a deliberate choice to do that, thankfully not too common.
- joseph 3y ago
  How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.
  - mixmastamyk 3y ago
    As mentioned, they weren't bugs but multiple planned breakages. IMHO, Python devs learned the wrong lesson from the 2 --> 3 transition. Should have been, "minimize big breaks." Instead they learned, "make lots of small breaks spread out evenly and avoid X.0 releases." The result is that planning around deprecation (always be breaking) is untenable for enterprise-style development.

thewataccount 3y ago

> It's really nice when every compiler/language is on the latest version by default. I've seen breaking changes in my dependencies from 3.7 -> 3.8 -> 3.9 -> 3.10, both at work and at home. I've also had constant issues with both GCC and CUDA being too new. The reverse is true too of course - I use a rolling release specifically because of a new CUDA version that no stable distro has (or will have for many months)

zdragnar 3y ago

I found opensuse tumbleweed's swaywm pattern to be completely broken, and from what I saw in forum posts it has happened several times in the past few years. I know opensuse is vaunted for its stability, but I have yet to find a setup that I liked better than sway-flavored Manjaro, given my proclivity for tinkering. Debian +kde also seem reasonably solid, even if kde still has odd occasional bugs or inconsistencies (last I tried, I had to reboot twice after installing to get the battery icon to work in the tray).

EnigmaCurry 3y ago
EndeavourOS sway edition (community) [1] has been a pretty great start for preconfigured wayland+sway+waybar and various integration. I added some more stuff to my ~/.config in my own repo [2], but it was a good place to start, and EndeavourOS is basically just rolling Arch Linux with some extra niceties. The included EnvyControl [3] switcher between nvidia to integrated is nice (yea you do have to reboot tho to switch), so I have used the regular i3 config with Xorg for playing some games (nvidia hardware graphics), but use sway for my day to day use (integrated graphics on wayland). [1] https://github.com/EndeavourOS-Community-Editions/sway https://github.com/EndeavourOS-Community-Editions/sway [2] https://github.com/enigmacurry/sway-home https://github.com/enigmacurry/sway-home [3] https://discovery.endeavouros.com/hardware/envy-control/2023/03/ https://discovery.endeavouros.com/hardware/envy-control/2023...

wink 3y ago

counterpoint: Let's assume you develop a software written in Python for $dayjob and you're targeting Python 3.8 because that's where your deployment target is. It's Monday morning, you fire up your work machine and the code that was working fine on Friday doesn't run anymore. Now you're scrambling to get some version of Python 3.8 installed to /opt. TLDR: There are a million circumstances where you don't want things to auto-update (even if auto-update means: "I run `apt/yum/foo upgrade" every morning". It's a story as old as time, if you're not only a user, upgrades are (and should be) often a deliberate choice, more important the more you go from patch level towards major version. (waiting for the people to chime in that this broken anyway and you should never work without Docker, etc.pp - I know, I know. It's just a real example why I run Arch on my personal machine but am more than happy with Ubuntu LTS on my work machine. I change minor/major version when I want.)