this post was submitted on 13 Jun 2024
50 points (100.0% liked)
Linux
48287 readers
627 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
uBlue f**ed up their site a while ago, they had a huge list of images.
You can just use their
kinoite-mainimage, which is what I do. It has Distrobox, homebrew and a few more things.Here is an archived site
Use
kinoite-main:latestand you will even get automatic version upgrades without a problem.You can still rebase, you know? I tried Aurora and it was not for me, back on normal Kinoite.
But for sure it is a bit annoying to layer. But no issue. I layer 20 packages or so, 300 with dependencies, and all is fine.
I dont know about ROCM, their hardware enablement to my knowledge is just about NVIDIA, Asus and other proprietary stuff.
The developer image, dx, includes rocm-hip and rocm-opencl:
https://github.com/ublue-os/bluefin/blob/main/packages.json
The packages under “dx” are the main reason I’m considering it over stock Fedora
Interesting.
Give it a shot, Aurora is fine. May have some packages you dont need, but it is fine.
They remove Firefox for whatever reason, which makes no sense. The Librewolf and Firefox Flatpaks are probably okay, the Librewolf RPM is completely broken
We remove Firefox because having it on the image is a security hazard. You want your browser to update more often than your operating system.
We prefer the flatpak, but if for some reason you need the RPM I would suggest installing it with distrobox.
Okay?
Then why do you base on Fedora and have daily auto updates by default?
I shutdown my laptop every day and update every day. That is fine for me.
Fedora Firefox has some hardening flags that official Firefoxn has not. It is built for Fedora and works really really good.
I did benchmarks some time ago and it is also actually very performant.
Flatpak Firefox does not have the ability to create user namespaces for tab process isolation. This is due to all Flatpaks using the same badness-enumerating seccomp filter, there is no additional hardening possible and they still block userns creation.
Firefox can still isolate tabs via seccomp-bpf but this means it has 1 of its 2 security barriers removed when using a flatpak.
Seeing browsers as an app, it is good to have additional security from the browser to the OS, by sandboxing via flatpak.
But seeing the browser as a platform, passwords, bookmarks, credit card details etc may all be stored in there and a sandbox escape not necessary to steal peoples stuff.
Removing Firefox prevents people from reinstalling it (due to the rpm-ostree bug), and apart from the tarball (which has no desktop integration and is some random binary ran from some random location, likely without SELinux protection (unconfined users)) it is the best browser on Fedora.
This makes no real sense.
Pro
Con
Using the tarball and placing it in
/var/usrlocal/bin/may be better. But still cumbersome.The solution, even if you want to remove it, is having these issues solved, or this rpm-ostree bug fixed.
Distrobox updates automatically on Bluefin and Bazzite.
In this case we disagree with Fedora, Atomic Fedora should not have Firefox in image. It does not matter to us what they do, we explicitly remove it.
If you like the way Fedora builds their Firefox RPM, that's all the more reason for you to use a fedora distrobox.
Irrelevant. Not everybody does. Some people pin an old image due to a bug and sit on a far older image. If you had it your way, they'd be using a week or month old build of Firefox -- that's unacceptable.
Good. I can promise you if that gets fixed and I have a way to continue to prevent it, I will.
This is an issue for Mozilla. They are happy enough with the state of the Flatpak to not only verify it, but list it on their website. Unless you've got a CVE for the Flatpak version of Firefox I don't see any point in even engaging with this argument.
True, forgot that you use topgrade
There are many relevant issues and it is not a clear choice.
Yeah and nobody knows about user namespaces or seccomp filters. This is about at least 2 user groups and one is not necessarily more important than another.
It is again not a clear choice.
* in your opinionated images, I hope.
You start to sound like a GrapheneOS dev. It makes no sense to prevent users from reinstalling removed packages.
Which btw also include the Fedora Flathub repository.
We no longer touch the repos as Fedora is now in agreement with using Flathub.
It's for user security. I have no interest in debating this decision, my reasons are outlined.
As said, this has pros and cons. I will try the Distrobox method though.
You also didnt answer to the security issue of removing an entire sandboxing layer, or to the point about not being able to upgrade Distroboxes.
Do you solve the second problem by building a
latestdistrobox container following the uBlue releases?We solve this problem by treating distroboxes as cattle and not as pets. Blow them away at any time.
So what happens to the apps installed?
And what about running different distros in the same homedir, and dotfile clashes?
Use the distrobox assemble command, that'll let you have an ini file with all the stuff you want and then when the assemble command runs it'll remake the entire thing. Then just toss the assemble in cron and you'll always have a fresh container with your exact setup.
Interesting, never used that, thanks!