It’s not about funding. Many prefer mirrors because the main instance isn’t globally available (the GitHub issue I linked, for example, is all about people trying and failing to access flathub in China) or because they can’t for compliance reasons (many businesses already mirror stuff like epel, too, which is what throws off Rocky’s stat counters). Neither of those issues can be assessed by throwing more money at a CDN.

To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go:

https://github.com/flathub

https://docs.flatpak.org/en/latest/hosting-a-repository.html

Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…

https://github.com/flathub/flathub/issues/813

Why are you being inflammatory for no reason? I’m just saying I don’t think it’d be correct for an OS 3 years in the past to be neck and neck with modern stuff. Log off the computer and go outside lmao

Mfw CentOS Stream 9, using a kernel, compiler, and glibc version from 3 years ago, still manages to pull ahead of software released a few weeks ago on hardware released years after Stream 9’s original release.

I’m not sure how much I’d buy into phoronix benchmarks in this case. CentOS Strea, 9 was performing as good, if not better than, the recently released Ubuntu 24.04 and 2 week old FreeBSD 14.1 despite having a 3 year old kernel and being compiled with an equally old version of GCC. Linux is currently suffering from a pstate bug with AMD, too.

There’s a reason the BSDs are hardly used in HPC.

It’s not brave, it’s just outright wrong. As in, wrong to use in this situation, and the LLM itself is wrong.

So basically ostree deploy fails if you have an existing populated ESP (EFI System Partition), so you’ll have to partition manually atm (in my case, I just made another ESP on the same disk). Other than that, I haven’t run into any problems with Win11 + Fedora on the same disk, mostly because I don’t boot into windows.

You can read about the issue here: https://github.com/fedora-silverblue/issue-tracker/issues/284

Here’s the docs on manual partitioning: https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/#manual-partition

It’s definitely a pain. One of many papercuts you’ll find with an “emerging” desktop edition on a distro already known to push new stuff before the Linux ecosystem is ready.

Just be sure to make a backup of your windows data in a separate disk, keep boot drives for normal fedora (in case this ends up being too difficult), windows (in case you give up), and Fedora Kinoite (because duh), and ffs, don’t trust ChatGPT with your sensitive data on your main PC :)

From what I gather, it’s very similar.

They are both just wrappers for podman(/docker). Distrobox is more feature rich, and is far better documented, but is closer to a collection of bash scripts rather than a fully cohesive program. Toolbx is… definitely something. Their only real claim to fame is being less “janky”? IDK, it reeks of NIH, and in my experience, it’s a lot more fragile than distrobox (as in, I’ve had containers just become randomly inoperable in that I can’t enter them after a bit).

If you want to be pedantic, technically, distrobox is a fork of toolbx before it was rewritten.

Also see: systemd-bsod. Generates QR codes, too. I think blue for userspace boot-time errors and black for kernel stuff might be nice.

It’s a good thing for the owners of the codebase, but often, a bad thing for the community (even if the community contributes to said codebase).

For example, FOSS maintainers sometimes will (want to) relicense to protect their income stream:

https://github.com/CaffeineMC/sodium-fabric/issues/2400

https://github.com/LizardByte/Sunshine/pull/150

While corporations might literally have maintainers sign away their rights so they can take the work from their own community:

https://lwn.net/Articles/937369/ (canonical requires a CLA, though this + the subsequent re-license might have happened anyway)

https://lwn.net/Articles/935592/ (RPM spec files are MIT licensed at the Fedora level. There are likely chnages to RPM files contributed by the community that are now source-restricted in RHEL)

https://networkbuilders.intel.com/docs/networkbuilders/accelerate-snort-performance-with-hyperscan-and-intel-xeon-processors-on-public-clouds-1680176363.pdf (See section 2.2. Previously, this work was BSD)

Mixed bag, really.

I’ve learned exactly 0 useful things at community college.

Funnily enough, this is why I left my university and went to a CC. The opportunities for me at a CC have been much greater (especially when it comes to part-time employment positions). The smaller course sizes in my digital design classes in Quartus Prime (which were not present in the lower division curriculum at my original university) allowed me to excel so much that I ended up as a TA for my class. In addition, because I wasn’t asphyxiating myself in a tiny auditorium of 400 people, I found it much easier to approach my professors 1 on 1 to talk about physics outside my course curriculum, which has helped me network and prepare to line up REUs next year. I feel as though the people at my CC are also more down to earth and hardworking than those at my university. The student leadership there didn’t feel as daunting, and felt action-oriented (as opposed to being a pure popularity contest), so I was able to join student government. What I have been achieving over the course of 6 months at a CC is infinitely better than what I was getting at a full university, and I am no longer depressed.

Everyone’s experience is different. In my case, my original university was highly hyped, and very expensive, but left me sorely disappointed, and I was not happy with what I’d be learning according to my course roadmap.

Go for FreeBSD: this might require a learning curve, because this is an OS I’ve never used. Are commands that different from debian?

Both of them are, at the very least, unix-like, so the core command set is mostly the same, albeit with sometimes large functional differences.

Simply install debian 12.5 again, the easiest choice.

You are familiar with Debian. This is probably the choice I’d go with.

Kernels are also updated more often than with debian as far as I know.

That’s why Debian has backports.

If a new user installs malware from flathub while trying out mint for the first time, they’ll probably blame mint instead of flathub. Nobody will say “damn, I should have listened to that warning” while their “discrod” app rm -rf’s their entire PC away, they’ll instead claim Linux is crap and go somewhere else. Doing this helps keep mint safe, and definitely encourages unverified FOSS apps to hurry up and get verified.

ostree is based on OCI images, the basis for containers and the like. “Rebasing” just refers to swapping out the OCI image containing your root with another.

I know ssh -X works fine in a rootless podman container, and so does waypipe. I’d be shocked if xpipe didn’t.

Not everything should be flatpak’d. In your case, xpipe (and in the future, waypipe) should always be installed in a docker container containing your normal “mutable” OS. It’s why Fedora is evaluating Ptyxis: when you open a terminal, instead of defaulting to your immutable root, it can be set up to go to a container which has your home mounted but a traditional, mounted root.

Don’t feed the trolls :)

I think a true arch linux experience can be done with immutable distros by modeling themselves after something like a nixos config or an rpm-ostree treefile. Like, during bootstrapping, you’d feed in a config file which would install everything into a future RO root. Would definitely be a lot of work, though, since pacman does (and probably will never) have the capability to manage multiple read-only roots.

You don’t have to install everything as a flatpak if you don’t want to. You can totally install most things in a rootless distrobox container, then use distrobox export (if you’re using distrobox instead of toolbx) to get a nice desktop entry. It’s how I run VSCode and Quartus Prime, for example.

There have been at least 1 PoCs for arch linux based on ostree: https://wiki.archlinux.org/title/User:M1cha/Install_Arch_Linux_inside_OSTree

In addition, VanillaOS’s ABRoot has been packaged through the AUR

SteamOS3 is immutable and arch-based. You can see a fan-recreation of the image builder here

Otherwise, you can use the alpine linux immutable root with atomic upgrades guide.

Generally speaking, though, pacman is really basic, and the majority of the atomic/immutable magic happens in the package manager. That’s why only existing, complex package managers such as rpm-ostree (which shares a code base with DNF) have full support for it.