The entire thing. It needs to be completely rewritten in rust, complete with unit tests and Miri in CI, and converted to a high performance microkernel. Everything evolves into a crab /s
The entire thing. It needs to be completely rewritten in rust, complete with unit tests and Miri in CI, and converted to a high performance microkernel. Everything evolves into a crab /s
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://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…
This is not April fools. The submitter did want to mess with people, though.
I wouldn’t place too much faith in the vetting process. As of right now, there are 2,034 members of the packager group of Fedora. None of them are required to have 2FA (or any real account security past a password), and the minimum requirements to join the group aren’t very high (contribute a package, pick up an unmaintained one, etc). Any of those 2,034 people can push malware to Fedora, and within a week, it’d be in stable repos.
Most of these distros are volunteer efforts. They don’t have the manpower to ensure the software supply chain remains secure.
It’s not that they can’t, it’s that people are getting blindsided by updates to a game which supposedly hasn’t received updates for over half a decade, and downgrading on Steam is a surprisingly huge PITA. The Midnight Ride recommends patching, fwiw.
If anyone’s curious, here’s the RHBZ ticket listing the products RH has patched this in: https://bugzilla.redhat.com/show_bug.cgi?id=2262126
By the way, all Fedora packages are scanned with ClamAV as part of bodhi tests. Here’s the test matrix where xz 5.6.0 passed the scan, and would have allowed the exploit in for the F40 beta if it wasn’t obsoleted by another build where the vulnerability’s mechanism was disabled because it triggered valgrind failures in other software.
Sure, there’s more sophisticated AV software out there, but at the end of the day, the F40 beta was temporarily saved because of luck, the beta freeze period, and valgrind. The ecosystem as a whole was saved because “Jia Tan” wasn’t aware that making Postgres run slightly slower immediately raises alarm bells.
This is a great start, but tbh, I’m not fully sold on “verified” flathub apps. Verification requires a token to be placed into a source repo or a website, but there appears to be nothing on actually verifying that the source/site are the original creators. So, for example, if someone packaged a malicious version of librefox and established it under io.github.librewolf-community instead of the canonical io.gitlab.librewolf-community, I’m concerned it’ll still show as verified (though quickly removed). The process can be read about here.
It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:
Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average;
They also conveniently left out the part of Greg KH’s opinion stating that he recommends the use of vendor kernels over stable/LTS branches, too.
I found this particularly funny:
It all comes down to a delicate balancing act between security and stability. Some top Linux kernel developers and CIQ are coming down on the side of security.
Now I know CIQ is “supposedly” different from rocky, but what is CIQ going to do, break bug-for-bug compat and use stable kernels in their supported version of Rocky? This entire article feels like it doesn’t fundamentally understand that not all bugs (especially ones that lead to potential low-ranking CVEs) aren’t worth patching.
The guy replying is a total dick, and for people that like to encourage change to create software that evolves with needs, they sure do refuse to change when needs evolve.
This is definitely just a dangerous cause of that one xkcd. At the very least, Debian unstable caught something before it could reach everyone else. That works, I guess.
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.
So you want to build something like apko (alpine packages/repos, used in chainguard’s images) or rules_oci (used in google’s Debian-based distroless images) but for portage?
I think it’d be cool. Just keep in mind:
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.
The US’s Department of Defense is one of Red Hat’s biggest customers. Other than that, the US government theoretically uses Linux quite extensively, going as far as making significant contributions such as SELinux. It was mentioned already, but academia uses Linux a lot, too. I saw lots of machines at SLAC running CentOS 7.
I’m not sure if anyone said it was the fault of flathub. My point is that, regardless of fault, accessibility to the main instance is an issue for several reasons, and a good way to solve it is to build a system for mirrors.
It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.
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.
It’s not brave, it’s just outright wrong. As in, wrong to use in this situation, and the LLM itself is wrong.
Hah, those are the load times I used to get on my Xbox One with its dinky HDD. At the very least, The Midnight Ride has been updated to post next-gen, and I now get really small loading times (<5 sec) on my SSD. The game feels less rough around the edges, too. Only took 3 hours to set up :,)
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.
But how does this solve the problem of the config files of the various DEs (GTK rc files or other theme stuff) messing with each other in the home directory?
It does not. Your dotfiles will be a bit wrecked when you rebase. See: https://universal-blue.discourse.group/t/why-is-rebasing-between-desktop-environments-bad/690/4 It’ll also cause random issues like: https://discussion.fedoraproject.org/t/flatpak-apps-crashing-after-rebasing-from-silverblue-to-kinoite/83623/2
It’s mostly plasma fighting gnome, though. I haven’t seen any conflicts with say, sway.
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.
GNU/Hurd
I’d really like it if Fedora didn’t discourage packaging static libs, but still discouraged building packages with static libs. It’d be nice to have them for development purposes.
I also wish they made “third party” software a bit easier to access in their installer and distro as a whole. The option to enable Nvidia drivers is buried, and even though flathub is now unrestricted when toggled in the installer, it’s not the first priority when prompted for software to install in gnome software.
A longer support cycle with less releases would also be nice, but would defeat the purpose of the distro. I guess it’d make more sense if CentOS Stream released more frequently and with more packages available in EPEL, similar to Ubuntu.
Afaik yes, the token is keyed to a specific source in the case of verifying through a website, but from what I can tell, that doesn’t stop someone else from creating a separate malicious website (or git repo) that looks similar but contains malware, and publishing that as a verified app with a similar name as the real app to flathub (so there would be multiple versions of an app, with only 1 being the “real” one on flathub).
There are existing mirrors for Fedora and Ubuntu packages in China, which are used because mirrors in other countries are often blocked. I’m sure there are no legality issues—the issue in the case of flatpak and china in particular is that China blocks Fastly because Fastly does not host any POPs in China. This is why Cloudflare, for example, has their own network in China that international users can pay to use. There’s no legal issues here, just logistical. Besides, as previously shown, people do (with great difficulty) managed to bring up their own flatpak mirror without any consequences for a few years now.
Besides, there shouldn’t be legality issues for businesses wanting to host their own mirrors for compliance issues.
Looks like DDG appends “ - Red Hat” to search results under technology topics on RH’s website. Never noticed that, funny.
Fedora has a (disabled) present repo for Nvidia drivers from rpm fusion OOTB. Just open the hamburger in gnome software, go to software repositories and enable “RPM Fusion for Fedora - Nonfree - NVIDIA Driver”, and install akmod-nvidia as usual. For atomic desktops, you’ll want to use something like ublue, though, because rpm-ostree doesn’t support akmods afaik
Hopefully DNF5 gets in for F41, especially since it was supposed to get in as the default for the current release, F39. If anyone’s curious, here’s the vote for deferring: https://pagure.io/fesco/issue/3039
The reasoning for the upgrade: https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Benefit_to_Fedora
And the reasoning given by the DNF5 team for targeting F41 instead of F40: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EYE2JY537OM7GFW46EK7YIBLHJ52USAZ/ (though fesco also wanted to keep it in F41 to not disturb the mass branching from F40 to RHEL 10)
And some things that need fixing before it becomes default: https://github.com/rpm-software-management/dnf5/issues/1057
And some commands that will be/are implemented: https://github.com/rpm-software-management/dnf5/issues/429
Personally, I just hope DNF4’s (what)provides comes back in full.
Also see: systemd-bsod. Generates QR codes, too. I think blue for userspace boot-time errors and black for kernel stuff might be nice.
Graphical environments are just programs just like any other.
They are in Fedora, too. It’s just that installing one DE overtop another can cause config file clashes (ie installing Plasma alongside GNOME means GTK apps will have a minimize button when logged into GNOME)
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.
Config files are still editable. Most of them (rpm-ostree, for example) have a mechanism for managing packages, and subsequently rolling back if anything goes wrong or completely resetting, and leave /usr/local writable. For stuff like development and working with compiler toolchains, you should be using a container. I use vscode exported in a distrobox running Fedora 40, for example.
Yes, all their images are purposefully normal fedora atomic images with stuff tacked on top. Some of that stuff comes in just scripts to make management a bit easier, some of it comes in the form of utilities like distrobox. They also come with zfs or proprietary Nvidia drivers or other things so you don’t have to manage them yourself, alongside tailscale and rpmfusion for nonfree stuff (like codecs). Some of them also have some light configurations, some of them have heavier configurations (especially in the case of bazzite).
You can totally do everything ublue does from a stock Fedora atomic image. Ublue just makes it a little more convenient. A sort of “oh, well I was going to do that anyway”.
Here’s the base dockerfile. As you can see, it confirms all of the above.
It’s immutable (aka. atomic), which means the system files cannot be changed, even by root.
This is a definite “well um actually” moment, but technically immutability can be switched off at any time with chattr, and “true” immutability will not be achieved until full image signing is commonplace. You can see the ideas laid out here: https://github.com/ostreedev/ostree/issues/2867
It does let you do cool things though, like install nix: https://github.com/dnkmmr69420/nix-installer-scripts/blob/main/installer-scripts/silverblue-nix-installer.sh
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.
We might not be as lucky with the next one (or the ones in the past).
Or the ones in the present, for what that’s worth
I think that’s the issue here, but that might just be poor documentation
That’s barely the tip of the iceberg, too. Currently, popular projects sit at:
31M for KDE
25M for GNOME
41M for Chromium
42M for Mozilla Firefox
17M for LLVM
15M for GCC
(Note that this metric includes comments and blank lines, to which Linux would count at 46M lines. Counts with blank lines and comments removed are also in those links)
Even if a package was completely vetted, line-by-line, before it made it into a repo, would the maintainer need to get every update, too? Every PR? Imagine the maintenance burden. This code QA and maintainer burden discussion was the crux of one of the most popular discussions on the Fedora devel list.