Can’t believe he figured it out. What a shame. Guess we’ll have to go provoke another country to invade our fellow flourishing independent democracies, who play a key role in the world’s trade.

Seriously though, I hope he’s just giving himself an easy out here. There’s always too much war going on.

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.

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://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

This is not April fools. The submitter did want to mess with people, though.

https://joshuastrobl.social/@me/112197672362783955

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.

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.

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

Not all docker containers contain a shell binary.. You can still propose an issue to moby, the upstream of docker, though.

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.

FWIW, gitlab-runner exec and earthly exist for running tests locally, with others things like nektos/act for GHA as a 3rd party solution. I’ll never get used to yaml, though, all my pipelines are mostly shell scripts. Using a markup language as a programming language was definitely one of the decisions of all time.

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:

1. Container scanning tools (like trivy), afaik, tend to look for a package db. Going distroless breaks them. I believe this is why chainguard generates a SBOM (software bill of materials).
2. Container images are already de-duplicated, and often, the gains in pull times aren’t worth the additional debugging effort (for example, you won’t be able to have dig/curl installed without rebuilding and deploying the whole image, or even a bash prompt in most cases). They’re even more not worth it because lazily pulling OCI images is now a thing, though it’s in its infancy. See: eStargz and I believe dragonfly which uses nydus. More generally though, zstd:chunked will probably eventually become mainstream and default, which will all but eliminate the need for “minimal” starting images.
3. If you wanted to go really small, there’s stuff like slim which makes tailor made images.
4. Gentoo, afaik, doesn’t really do LTS releases, making it undesirable for server use, which is the main place containers are.
5. Distroless containers don’t share common base images because they are normally scratch-built. This breaks image deduplication, leading to increased disk usage instead of decreased disk usage, and why I personally swapped off chainguard’s images.

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.

In the back of my mind I know this is there, but the cat | grep pattern is just muscle memory at this point

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.

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.

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.