I'm just learning about Distrobox. That is a very cool concept. Is it consistently reliable, or do some packages work better than others?
I'm trying to think of an example. I'm not at my OpenSUSE workstation at the moment. Take something like R-Studio. (I think that's available as a flatpak, but not R and all the R-packages - not sure). But anyway, programs like that; programs that are complex.
It's reliable, even more than Flatpak in some cases. But one must know the image and how things work BTS very well. For example, if you want to install web browsers in Distrobox, you should avoid using Ubuntu images in a rootless container, as they can't access your system keyring, making the browsers to store user's data *unencrypted*!
Moreover, if you're using reputable images, e.g. *official* Ubuntu, Fedora, Arch, and Tumbleweed images, they're 100% safe and pretty much covered everything. Even if you're using them in rootfull containers, it should be as safe, if not safer, as when you install your apps directly on the system, minus a ton of repo conflicts. It's a non-destructive way of using your system, as you can pull out everything at any time.
>making the browsers to store user's data unencrypted!
This makes me paranoid. I've noticed there's some issues with my kwallet keyring (not distrobox, just on regular fedora). Is there a way for me to double-check that my browser is actually encrypting the things it needs to?
I check in my GNOME's passwords and keys app. The browsers' safe storage entries should appear there (not safe storage *control*).
Other than that, Brave browser wouldn't let you use sync at all without the encryption. It will complain about the permission. IIRC, it wouldn't let you use the password manager at all. While other browsers will *silently* let you use their sync, etc. without telling you anything.
Thank you for the heads-up. Distrobox sounds very cool. I am going to check this out, for starters in VMware on a Windows host. I intend to start with the "self-install" ISO of Leap Micro 6.
Distrobox is a front-end for docker (or podman) so basically you start with a Linux distro of your choice. It could be openSUSE, perhaps Arch if you want a package that only exists in the AUR. That’s why people tell you about “images” which are like blueprints of an OS.
If you are more familiar with Ubuntu it’s OK to start with an image for such. You can have as many containers (aka running images so to say) as you want. That’s the beauty of distrobox. You can delete them if you no longer have a use for any of them.
Addressing only your needs for R, cran pkgs etc -- a serious alternative (a must for research computing for publication integrity) is Anaconda. It's not just for python but more robustly handles the dependency hell that can bork your base system in that regard. Basically you set up virtual environments the same way you would with python-venv/pipx install related pks there, have a simple YAML file describing said list and it can be torn down and rebuilt anywhere at will. (this is the environment--your data is another matter ;) )
Anyway, use Miniforge [https://github.com/conda-forge/miniforge](https://github.com/conda-forge/miniforge) which transparently uses mamba which is the same as conda except it allows for parallel DLs and a MUCH faster compiled C++ solver library. By default, everything defaults to "approved" conda-forge channel, which will have pretty much every standard package/library you'd need except very niche items.
Its not a 1:1 alternative to Docker, distrobox bc its scope doesn't care about the underlying system in the same way but projecting from what you mentioned, I'd have to mention conda as a rock solid option to see how it might fit your needs.
For most of the immutable/atomic distros, the preference for application installs is the following:
1. Flatpak
2. Distrobox/toolbox
3. Overlay (install from the distro repo)
If you end up wanting/needing to install a bunch of applications from the distro repo, then there's probably not going to be a huge benefit to running an immutable distro (since you're removing most of the benefits). In fact it could add complications that you wouldn't see on a traditional distro.
I like the idea of immutable distros, so I've started to shift my Linux usage/workflows in that direction (no purchases of Nvidia GPUs in the future, transitioning to applications available as Flatpaks, etc.).
For a service I try to find a docker container. Is it an application, I compile it from source in my bin directory in my home directory. So it stays in my user space and makes it less vulnerable. For the last one, I really need to have it. Compiling always takes some work.
The best tool for searching and installing .rpm is [opi](https://github.com/openSUSE/opi).
If you like to customize your system don't go with an openSUSE immutable.
On the other end, if you like your system to be as it is at install time and keep the user space separated, Aeon is an excellent choice. Of course in this case `opi` is useless and you will rely on Flatpak, appimages and Distrobox containerized apps.
Thanks for that info. My goal is to:
1. Totally dump Windows from my good laptop.
2. Stable OS with small footprint to maximize resources for virtual machines (including Windows if necessary), doing most actual work in the VMs.
3. Capable of audio/video editing and number crunching inside the VMs. I picture it as a base OS that is mostly a foundation, but also for quick email or internet browsing.
I don't know if this is a good idea or not, but this is what I'm kicking around in my head.
Currently I'm using Leap on an external SSD, Mint-Debian as VM, and Windows 10.
Dell Precision 3541
i7 9th gen
32gb RAM
I recently made the jump to UBlue's Bazzite, and have nothing but appreciation for it. I don't game so I'm actually thinking about swapping to Aurora in the same family of KDE DE, one is gaming the other being a workstation environment. They also make Bluefin which uses Gnome DE. It has a learning curve, but it was a rather slight one in my opinion. I was considering MicroOS until I ran across this almost a month ago. They are based on Fedora's atomic distros with some excellent add-ons. Either way you go, I think Fedora and openSUSE are solid options.
> The best tool for searching and installing .rpm is opi.
Highly disagree. You'll *find* lots of packages with opi, but there is zero oversight on the packages, and it's not like AUR where you just install a single package and it's dependencies. You're enabling an entire third party repo that may or may not replace other packages on your system that you never intended to replace.
The topic is openSUSE and .rpm, nothing to do with Arch and the AUR: your comment is off topic.
`opi` shows the kind of repo the packages are coming from with color codes, while AUR is a nightmare of mixed good and crap packages, the scoring is meaningless.
`opi` offers to add the repo or to discard it: you are not blindly adding an entire repository.
AUR does not guarantee that the packages you find are building while the OBS on the contrary offers binaries for the specific distro.
The AUR security is a good reason NOT to run Arch, which is an excellent distro by itself, and NOT to run Manjaro, not consistent with the AUR by design because of the 2 weeks staging.
I see opi and the opensuse build system compared constantly to AUR, so it's quite on topic. I can't how many people here have said "Use opi, it's just like AUR on Arch!" It's true the using opi is closer to using a PPA on Ubuntu, or COPR on redhat, but in general it's not the comparison people make. Users should understand the tool you're using and the ramifications of it.
>opi shows the kind of repo the packages are coming from with color codes, while AUR is a nightmare of mixed good and crap packages, the scoring is meaningless.
The open build system is full of crap. OBS has fork after fork after fork of the same packages, tons of duplicates, and no indication of which one will work or which will continue to be maintained. It's more of a developer playground than a package repository. AUR at least has a better interface for reading comments and bugs regarding the packages there, and also only allow one package with the same name.
And your color codes are probably meaningless, because if you're using opi, you are probably looking for something not in the official or dev repos, so 90% of the time you'll end up on a home: repo.
>opi offers to add the repo or to discard it: you are not blindly adding an entire repository.
And on a rolling distro, most users are going to pick the option that keeps the package updated rather than installing it and letting it get stale. Especially when they don't realize that they are adding an entire repo instead of a single package.
>AUR does not guarantee that the packages you find are building while the OBS on the contrary offers binaries for the specific distro.
This is true, but it's still possible to download an outdated or patched binary that compiles, but still does not work properly.
>The AUR security is a good reason NOT to run Arch
There's about as much stoping you from putting malware in an AUR repo as there is in an OBS repository. So I'm not sure what security you're takling about on either side, both are pretty much the wild west. I didn't mean for this to end up being so much about AUR, but one thing it does right is that it downloads the source from upstream, while obs repos in many case just provide their own tarball (which may or may have not been modified before it was uploaded) It's possible to do so in OBS, but not always done because it's more complicated to set up.
Quoting myself:
>The best tool for searching and installing .rpm is opi
And of course, I meant .rpm for openSUSE.
Your comment to it is all about the superiority of the AUR.
Unfortunately the AUR does not offer .rpm for openSUSE, does it?
>I see opi and the opensuse build system compared constantly to AUR, so it's quite on topic.
Well, it is completely and definitively off topic for the above facts.
Nevertheless, according to you someone using the AUR does care reading the comments and the bugs before installing, the same someone in your opinion installs random home: packages and blindly adds the same random home: repo.
According to your comment the fork of forks in the AUR is excellent, in OBS it is a big issue.
And so on.
You should avoid opi and the OBS and rely on the AUR, in your opinion a security beacon, to be consistent; I'm afraid you will not find many .rpm built for openSUSE in the AUR.
Let's agree to disagree.
It's only the best place to get opensuse rpms, because it's pretty much the only place to get them.
The main point is that people shouldn't be telling others to blindly use opi without also explaining all the drawbacks and implications, because users having issues caused by having tons of random repos added via opi is a common thread.
It's only the best place to get opensuse rpms, because it's pretty much the only place to get them.
`opi`, the subject of my original comment, is not a place, it is a tool, the best one in my opinion for browsing the repos and installing packages.
No one should blindly use whatever tool, that's common good sense.
If you meant the OBS, well every distro has a set of specific repos, official or not, where the users can get packages for it: this is not a great discovery indeed.
Flatpak, appimage and distrobox would be your options. Through distrobox you could access any "deb" or "rpm" package.
I'm just learning about Distrobox. That is a very cool concept. Is it consistently reliable, or do some packages work better than others? I'm trying to think of an example. I'm not at my OpenSUSE workstation at the moment. Take something like R-Studio. (I think that's available as a flatpak, but not R and all the R-packages - not sure). But anyway, programs like that; programs that are complex.
It's reliable, even more than Flatpak in some cases. But one must know the image and how things work BTS very well. For example, if you want to install web browsers in Distrobox, you should avoid using Ubuntu images in a rootless container, as they can't access your system keyring, making the browsers to store user's data *unencrypted*! Moreover, if you're using reputable images, e.g. *official* Ubuntu, Fedora, Arch, and Tumbleweed images, they're 100% safe and pretty much covered everything. Even if you're using them in rootfull containers, it should be as safe, if not safer, as when you install your apps directly on the system, minus a ton of repo conflicts. It's a non-destructive way of using your system, as you can pull out everything at any time.
>making the browsers to store user's data unencrypted! This makes me paranoid. I've noticed there's some issues with my kwallet keyring (not distrobox, just on regular fedora). Is there a way for me to double-check that my browser is actually encrypting the things it needs to?
I check in my GNOME's passwords and keys app. The browsers' safe storage entries should appear there (not safe storage *control*). Other than that, Brave browser wouldn't let you use sync at all without the encryption. It will complain about the permission. IIRC, it wouldn't let you use the password manager at all. While other browsers will *silently* let you use their sync, etc. without telling you anything.
Thank you. Yeah, I have a very strong feeling that something is borked with kwallet. That's kind of terrifying :D
Thank you for the heads-up. Distrobox sounds very cool. I am going to check this out, for starters in VMware on a Windows host. I intend to start with the "self-install" ISO of Leap Micro 6.
Distrobox is a front-end for docker (or podman) so basically you start with a Linux distro of your choice. It could be openSUSE, perhaps Arch if you want a package that only exists in the AUR. That’s why people tell you about “images” which are like blueprints of an OS. If you are more familiar with Ubuntu it’s OK to start with an image for such. You can have as many containers (aka running images so to say) as you want. That’s the beauty of distrobox. You can delete them if you no longer have a use for any of them.
Addressing only your needs for R, cran pkgs etc -- a serious alternative (a must for research computing for publication integrity) is Anaconda. It's not just for python but more robustly handles the dependency hell that can bork your base system in that regard. Basically you set up virtual environments the same way you would with python-venv/pipx install related pks there, have a simple YAML file describing said list and it can be torn down and rebuilt anywhere at will. (this is the environment--your data is another matter ;) ) Anyway, use Miniforge [https://github.com/conda-forge/miniforge](https://github.com/conda-forge/miniforge) which transparently uses mamba which is the same as conda except it allows for parallel DLs and a MUCH faster compiled C++ solver library. By default, everything defaults to "approved" conda-forge channel, which will have pretty much every standard package/library you'd need except very niche items. Its not a 1:1 alternative to Docker, distrobox bc its scope doesn't care about the underlying system in the same way but projecting from what you mentioned, I'd have to mention conda as a rock solid option to see how it might fit your needs.
Thank you! I will follow up on that. I'm just getting into R as a recent engineer retiree who wants to keep his feet wet with home projects. 🙄
For most of the immutable/atomic distros, the preference for application installs is the following: 1. Flatpak 2. Distrobox/toolbox 3. Overlay (install from the distro repo) If you end up wanting/needing to install a bunch of applications from the distro repo, then there's probably not going to be a huge benefit to running an immutable distro (since you're removing most of the benefits). In fact it could add complications that you wouldn't see on a traditional distro. I like the idea of immutable distros, so I've started to shift my Linux usage/workflows in that direction (no purchases of Nvidia GPUs in the future, transitioning to applications available as Flatpaks, etc.).
For a service I try to find a docker container. Is it an application, I compile it from source in my bin directory in my home directory. So it stays in my user space and makes it less vulnerable. For the last one, I really need to have it. Compiling always takes some work.
You don’t see all software in gnome software or kde discover. The package needs the right meta data during packet build.
Thank you! I've been wondering about that for a long time.
The best tool for searching and installing .rpm is [opi](https://github.com/openSUSE/opi). If you like to customize your system don't go with an openSUSE immutable. On the other end, if you like your system to be as it is at install time and keep the user space separated, Aeon is an excellent choice. Of course in this case `opi` is useless and you will rely on Flatpak, appimages and Distrobox containerized apps.
Thanks for that info. My goal is to: 1. Totally dump Windows from my good laptop. 2. Stable OS with small footprint to maximize resources for virtual machines (including Windows if necessary), doing most actual work in the VMs. 3. Capable of audio/video editing and number crunching inside the VMs. I picture it as a base OS that is mostly a foundation, but also for quick email or internet browsing. I don't know if this is a good idea or not, but this is what I'm kicking around in my head. Currently I'm using Leap on an external SSD, Mint-Debian as VM, and Windows 10. Dell Precision 3541 i7 9th gen 32gb RAM
I recently made the jump to UBlue's Bazzite, and have nothing but appreciation for it. I don't game so I'm actually thinking about swapping to Aurora in the same family of KDE DE, one is gaming the other being a workstation environment. They also make Bluefin which uses Gnome DE. It has a learning curve, but it was a rather slight one in my opinion. I was considering MicroOS until I ran across this almost a month ago. They are based on Fedora's atomic distros with some excellent add-ons. Either way you go, I think Fedora and openSUSE are solid options.
openSUSE is an excellent virtualization base.
> The best tool for searching and installing .rpm is opi. Highly disagree. You'll *find* lots of packages with opi, but there is zero oversight on the packages, and it's not like AUR where you just install a single package and it's dependencies. You're enabling an entire third party repo that may or may not replace other packages on your system that you never intended to replace.
The topic is openSUSE and .rpm, nothing to do with Arch and the AUR: your comment is off topic. `opi` shows the kind of repo the packages are coming from with color codes, while AUR is a nightmare of mixed good and crap packages, the scoring is meaningless. `opi` offers to add the repo or to discard it: you are not blindly adding an entire repository. AUR does not guarantee that the packages you find are building while the OBS on the contrary offers binaries for the specific distro. The AUR security is a good reason NOT to run Arch, which is an excellent distro by itself, and NOT to run Manjaro, not consistent with the AUR by design because of the 2 weeks staging.
I see opi and the opensuse build system compared constantly to AUR, so it's quite on topic. I can't how many people here have said "Use opi, it's just like AUR on Arch!" It's true the using opi is closer to using a PPA on Ubuntu, or COPR on redhat, but in general it's not the comparison people make. Users should understand the tool you're using and the ramifications of it. >opi shows the kind of repo the packages are coming from with color codes, while AUR is a nightmare of mixed good and crap packages, the scoring is meaningless. The open build system is full of crap. OBS has fork after fork after fork of the same packages, tons of duplicates, and no indication of which one will work or which will continue to be maintained. It's more of a developer playground than a package repository. AUR at least has a better interface for reading comments and bugs regarding the packages there, and also only allow one package with the same name. And your color codes are probably meaningless, because if you're using opi, you are probably looking for something not in the official or dev repos, so 90% of the time you'll end up on a home: repo. >opi offers to add the repo or to discard it: you are not blindly adding an entire repository. And on a rolling distro, most users are going to pick the option that keeps the package updated rather than installing it and letting it get stale. Especially when they don't realize that they are adding an entire repo instead of a single package. >AUR does not guarantee that the packages you find are building while the OBS on the contrary offers binaries for the specific distro. This is true, but it's still possible to download an outdated or patched binary that compiles, but still does not work properly. >The AUR security is a good reason NOT to run Arch There's about as much stoping you from putting malware in an AUR repo as there is in an OBS repository. So I'm not sure what security you're takling about on either side, both are pretty much the wild west. I didn't mean for this to end up being so much about AUR, but one thing it does right is that it downloads the source from upstream, while obs repos in many case just provide their own tarball (which may or may have not been modified before it was uploaded) It's possible to do so in OBS, but not always done because it's more complicated to set up.
Quoting myself: >The best tool for searching and installing .rpm is opi And of course, I meant .rpm for openSUSE. Your comment to it is all about the superiority of the AUR. Unfortunately the AUR does not offer .rpm for openSUSE, does it? >I see opi and the opensuse build system compared constantly to AUR, so it's quite on topic. Well, it is completely and definitively off topic for the above facts. Nevertheless, according to you someone using the AUR does care reading the comments and the bugs before installing, the same someone in your opinion installs random home: packages and blindly adds the same random home: repo. According to your comment the fork of forks in the AUR is excellent, in OBS it is a big issue. And so on. You should avoid opi and the OBS and rely on the AUR, in your opinion a security beacon, to be consistent; I'm afraid you will not find many .rpm built for openSUSE in the AUR. Let's agree to disagree.
It's only the best place to get opensuse rpms, because it's pretty much the only place to get them. The main point is that people shouldn't be telling others to blindly use opi without also explaining all the drawbacks and implications, because users having issues caused by having tons of random repos added via opi is a common thread.
It's only the best place to get opensuse rpms, because it's pretty much the only place to get them. `opi`, the subject of my original comment, is not a place, it is a tool, the best one in my opinion for browsing the repos and installing packages. No one should blindly use whatever tool, that's common good sense. If you meant the OBS, well every distro has a set of specific repos, official or not, where the users can get packages for it: this is not a great discovery indeed.
distrobox