Removed by mod

There was nothing in the question about jellyfin.

I’m on the jellyfin side, but you people have to chill, this is becoming Ford vs Chevy in here.

As others have mentioned

Yes, well, thanks for telling me again. For the 5th time.

Migrated my storage from an old xeon-d to an arm SBC w 4GB ram and a sata hat. Performance is great, ZFS keeps up with all tasks, and less than a third of the power consumed. Backup scripts are running nightly without issue.

I am continually astounded by how well ZFS performs, even 15 years after I starting working with it. 4GB is enough for a mirror.

Yes, I’m seeing that now, thank you. Makes sense.

Yes, acknowledged. I see the point some ppl were trying to make.

But we don’t have enough information here; it says “CVE fixes per release”, we don’t know anything about them. Are these long-standing? Is some new process introducing security issues? We also have ongoing conversions of modules to rust, and lots of ongoing work.

We can say AI tools are helping find these, and that may be true, but but this graph doesn’t say that, it just says “CVE Number Big”.

Yes, this is the point I was trying to make, there is no context.

Thanks for this, I think I now understand what others are sating about this.

I don’t understand what you’re saying… Those aren’t major releases, those are dot releases, and they cross a major release.

It shows that the CVE fixes were consistent during the last 2.5 years and 14 releases.

Right, yes. But if the transitions from 4.x to 5.0 and 5.x to 6.0 were also shown, we’d be able to see that the bump itself isn’t significant, and that this happens after every major version release.

The magnitude of the bump is what’s important, and we can’t see that without comparing to pre- and post- AI tooling.

Why 5.0 and 6.0, those are ancient. This goes back to 6.9 from May 2024, where Ai usage in the Kernel wasn’t a thing until the recent few releases.

That’s the whole point.

Minor versions go up according to a certain pattern based on how the change mgmt is handled for the kernel, but major releases are marked when the kernel team “feels it’s the right time”.

From lwn: https://lwn.net/Articles/871989/

To kernel developers, version numbers continued to have no meaning other than as a measure of where things were on the timeline, he said; users were encouraged to run the latest version. But if you tell customers they need to move from 3.20 to 4.0, they will consider it a multi-year effort that requires planning and paperwork; “so they will only do it when they have time, which is never”. Going from 3.20 to 4.0 seems like a big jump, and 4.0 to 4.2 seems much smaller, even though the latter brings roughly double the number of changes.

As I mentioned, all kernel major releases have cve bumps, because (also mentioned) new kernel releases have new features and drivers.

The bump itself doesn’t show that ai is associated with more CVEs, because that bump is present after every kernel major release. It would have been better to show the bumps from previous releases to demonstrate the volume ai tools are helping to find.

The meaningful data would have been to show the amplitude of the commit frequency bump compared to 5.0 and 6.0 releases, because, as I mentioned, they have bumps just after release also.

This just shows a bump after a release, which doesn’t really show “AI” anything.

This is misleading.

Edit: “misleading” was the wrong word. I was just pointing out that showing data from 4.x to 5.x, 5.x to 6.x also would have made this post more meaningful.

Linux kernel full releases always have CVEs shortly after them because new features, drivers, memory handling tuning, and other capabilities arr introduced, and people (or ai) hammer away at them as soon as they appear.

I acknowledge that the bump has more amplitude because ai tools accelerate this, but this graph isn’t the shocker you think it is.

Apt v3 comes with some quality-of-life stuff that apt has been direly missing for years, and one of those is apt sources that make sense to a human.

So the new apt source files have local key location, components, suites, and Uris.

The sources from the before-time just had a one-liner with a uri and some components.

Edit:also the modernize command makes a backup of the source files it touches.

Most of my infra is Debian, and I did it without serious incident:

#Update everything to latest
apt update && apt upgrade && apt full-upgrade && apt --purge autoremove
reboot

#Verify that debian_version is 12.x (STOP IF NOT 12!)
cat /etc/debian_version

#Check for any pinned or held packages
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-mark showhold

#Swap bookworm for trixie in repo files
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*

#Carry out update
apt update
apt upgrade --without-new-pkgs -y
apt full-upgrade -y
reboot

#Verify that debian_version is 13.x
cat /etc/debian_version

#Modernize apt sources to v3
apt modernize-sources -y

And then maybe apt update to make sure the updates still work OK.

Sometimes you have to make changes to certain repos that don’t have Trixie manifests, but that’s easy enough to roll back.

There are two kinds of self-hosters: those who backup, and those who will start testing em after their first failed restore.

Congrats on becoming one of the 5% of ppl who backup, but actually also test them.

Well, these things come in cycles. In the 90s everything had it’s own tool, then tools like Drupal and WordPress, office and image editing suites came along… And we went back to using simpler tools with app stores. And then we got orchestration with K8s. And so on.

We’re going through another a big change in software, and we’ll see more. The big, complex swiss army knife software suites again.