This AISLE benchmark is interesting in this matter: https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jag...

And the recently discovered Copy Fail by Xint code is another proof that the gating is overblown: https://xint.io/blog/copy-fail-linux-distributions

I agree.

> A sacred cow is called a sacred cow because there is no reason for it to be sacred.

Here we diverge. Linux earns sacred cow status when people interpret legitimate criticism of it as an attack that must be debunked or dismissed. And there's plenty of that happening in this forum; you may not be treating it as a sacred cow, but plenty of people are.

And to expound on why it even matters, it does a disservice to Linux to treat it this way: if you can't engage with its flaws, you'll never help fix them, and instead attack people who try.

There are only 2 words in this term, and neither one even slightly applies.

A sacred cow is called a sacred cow because there is no reason for it to be sacred.

Linux is perfectly subject to criticism, and so not at all sacred.

Linux has earned a stunning amount of respect and gratitude by actually providing stunning utility and quality. IE, it's not just a random object like a cow that everyone decided to worship for no reason.

Spoken as a freebsd user who has plenty of critiques of the entire linux ecosystem.

Surprisingly Windows audio stack is a mess. I have a mini keyboard with Bluetooth and it was an adventure to get it working in Windows. In Linux it was pretty much plug and play.

Low latency audio drviers are also messy in Windows when not using an audio interface with well written ASIO drivers. Pipewire in Linux is much easier to configure. Looks like MacOS also does not have this driver problem.

It is surprising. Because most audio plugins and DAWs support only Windows and MacOS.

I don't have to tweak my usage of the terminal depending which platform I'm on.

I just have to remember to use Ctrl+Shift for copy/paste on Windows/Linux.

I'd start with Greg's on words. You can probably find more on it from Spender/grsecurity's blog.

A Linux LPE is a nothingburger unless you’re relying on the Linux kernel to enforce internal security boundaries, which would simply be foolish.

Imposing requirements on the reporter? No.

> Note that for Linux kernel vulnerabilities, unless the reporter chooses > to bring it to the linux-distros ML, there is no heads-up to > distributions.

so, no, `linux-distros` list don't solve the problem.

Feels like the more sensible process would be for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability and for distro maintainers to pay attention to that. Could be done without revealing what the vulnerability actually is in most cases, trusting the kernel maintainer's judgement. There does seem to be a public linux-cve-announce mailing list.

https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux

> allows the use of a Linux environment from within Windows, foregoing the overhead of a virtual machine and being an alternative to dual booting.

WSL2 isn't a Windows subsystem by definition as far as I can tell.

And try to define "major distros" in a way that actually means anything viable.

If you just want to count users, then that would only be Android (everything else is a rounding error.) After Android, that would be Yocto, and then Debian. All distros after that are mere fractions of overall users compared to those 3 by number of running systems alone.

If you want to count it as "$ spent on Linux" then that cuts out Android and Yocto and Debian as those distros are free, and would focus purely on the tiny installed base of paid Linux systems, and cut everyone else out.

So what is a fair way to do this other than "we notify no one, and tell everyone to always update their systems to the latest stable releases that we support."

Especially as there is no way for us to determine your use case (i.e. if a specific bug is a vulnerability for you or not.)

But single-number outputs like that are useless. Is the number ~10% higher because it's consistently ~10% faster at everything, or because it's 100% faster on a minority of things and slower at everything else? The first one is pretty unlikely when comparing processors with different designs, and indeed that isn't it:

https://www.phoronix.com/review/apple-m4-intel-amd-linux/4

https://www.phoronix.com/review/apple-m4-intel-amd-linux/5

https://www.phoronix.com/review/apple-m4-intel-amd-linux/6

https://www.phoronix.com/review/apple-m4-intel-amd-linux/7

The CPU in those charts with a similar TDP to the M4 is the Ryzen HX 370. You can see that the M4 is ahead of it in a few of the tests (C-Ray, DuckDB, PyBench, FLAC) but in even more of them the M4 is at the bottom of the stack. (Only a third of those charts are actually performance; each performance chart is followed by two power consumption charts.)

And the ~20W TDP is a nice parlor trick (the HX 370 is the only one on the list that competes with it there) but in a desktop CPU that's pretty irrelevant. Whereas if you compare it to the CPUs that can be had for a similar price (e.g. Ryzen 9700X, 65W), it's only ahead in C-Ray and FLAC while losing quite badly in most of the others and subjecting you to unupgradable soldered memory that the PC hardware doesn't.

Meanwhile doing ray tracing on a CPU instead of a GPU isn't much fun, and FLAC is an audio codec so a ~10% improvement there is probably not going to be a big part of your day if you're not a full-time sound engineer. So does averaging those kinds of things in to make a single benchmark number make sense? Or should you be looking at the results on applications you actually use?

A couple of years ago I got really sick and tired of cPanel, and started trying all these alternatives. I'm not an Arch Linux SSH freak, I need a GUI. And none of the panels had old school functions like setting up FTP and such.

So good luck to the Estonian (I think?) developers of Fastpanel and good riddance to that bloated slug cPanel.

Something involving socat, an any-IP / TCP routing rule, a VPS or other machine with a ipv6 /64 and plenty of duct-tape.

You'd get an application sitting on port 80 accessible via some unique ipv6 address (in the /64) on a tcp port 80. They needn't be the same port number but it would make it easier.

Any suggestions for a vm/container setup that works on a Linux host, provides the safety net you describe, and is still capable enough to try out all these things that people are talking about?