I believe comma is more widespread per country

it looks like you might be right… I’m surprised to learn that https://en.wikipedia.org/wiki/Decimal_separator#Conventions_worldwide lists 83 countries who use comma as decimal separator, and only 59 who use dot (and presumably the thousands separator is usually the opposite of the decimal separator). However there are enough countries which aren’t on either list that it isn’t entirely clear from that page which convention is actually used in more countries.

Also, it’s much more complicated than the . vs , binary… among other oddities:

• Historically, in Germany and Austria, thousands separators were occasionally denoted by alternating uses of commas and points, e.g. “1.234,567.890,12” (or “1.234,567.890·12” in Austria-Hungary and Austria prior to 1938) for “eine Milliarde 234 Millionen …”, but this is not seen today and contemporary German readers would require an explanation to understand it.
• In Switzerland, there are two styles. Currency values use an apostrophe (') as a thousands separator along with a dot (.) as the decimal separator, like “1’234’567.89”. For other values, the SI-style “1 234 567,89” is used, with a comma (,) as the decimal separator. The apostrophe is also the most common thousands separator for non-currency values, like “1’234’567,89”.

Yes, probably not all but certainly most bugs being found now are.

If the PS5 is based off of Linux

I don’t think it is though? After a few seconds searching I don’t see anything conclusive but PS4’s OS was based on FreeBSD so I would guess PS5’s probably is also. (I see that if you have a PS5 with old enough firmware you can put Linux on it yourself…)

Sony does have some experience shipping Linux-based products though (probably first with Linux for PS2 in 2002, and more recently various android devices) and surely knows how to comply with the GPL.

But still listing year’s old vulnerabilities that got fixed long ago because they are still supporting ancient stuff like 5.10LTS is Debian-specific.

The advisory this meme is about only relates to the 6.12 kernel in Debian 13 “trixie” (Debian’s current stable release), and 1,295 of these 1,313 CVEs are from 2026.

Linux 6.12 is the SLTS (“super long-term support”) release from 2024, so the Linux Foundation’s Civil Infrastructure Platform plans to continue backporting security fixes to it until 2035.

Debian stopped supporting Debian 11 “bullseye” (the one with a 5.10 kernel) in August, but that kernel is also an SLTS which CIP plans to support until 2031.

So, no, continuing support for these kernels is not something Debian-specific.

Here are the versions of linux-image-amd64 in Debian currently:

    bullseye (oldoldstable) (kernel): Linux for 64-bit PCs (meta-package)
    5.10.262-1 [security]: amd64
    bookworm (oldstable) (kernel): Linux for 64-bit PCs (meta-package)
    6.1.187-1 [security]: amd64
    bookworm-backports (kernel): Linux for 64-bit PCs (meta-package)
    6.12.95-1~bpo12+1: amd64
    trixie (stable) (kernel): Linux for 64-bit PCs (meta-package)
    6.12.111-1 [security]: amd64
    trixie-backports (kernel): Linux for 64-bit PCs (meta-package)
    7.1.13-1~bpo13+1: amd64
    forky (testing) (kernel): Linux for 64-bit PCs (meta-package)
    7.2.8-1: amd64
    sid (unstable) (kernel): Linux for 64-bit PCs (meta-package)
    7.2.8-1: amd64

Debian problems I guess

Not really; the Linux kernel has had 8500 CVEs so far this year (according to this).

Most of them aren’t actually known to be definitely-exploitable security bugs, but some are. You can read more about how Linux issues CVEs from this post on Greg Kroah-Hartman’s website: Linux CVEs, more than you ever wanted to know (and/or watch one of his talks on the subject which is linked from there).

See also this article from July: Linux kernel team publishes 432 CVEs in two days: Sunday-to-Monday onslaught fuels speculation over AI-assisted bug reports.

DSA 6528-1

This might be useful for some Linux users who want (but don’t need) to run Microsoft 365 occasionally, but actually relying on this kind of hack is a terrible idea.

Once fully implemented, this will help draw in people into Linux, as many shudder at the thought of switching to the platform because their preferred office suite doesn’t work here.

I certainly hope this doesn’t “help draw in people into Linux”. It’s sad to think about people and organizations switching to Linux on the basis of someone misleading them into thinking that relying on this kind of thing is a good idea because when it breaks it will give them a bad impression and they’ll blame “Linux” instead of Microsoft (or Bottles or whoever told them it was a good idea).

When the lack of a Linux version of a specific proprietary program is the blocker preventing someone from switching to Linux, relying on a workaround which remains unsupported by the proprietary/adversarial software vendor is… a recipe for a bad time.

Even if this mostly works today, it is extremely likely that (either intentionally or inadvertently) Microsoft will break it in the future.

So, although I do see how this can be useful for some people when/while it works, in my opinion Linux and the world at large would be better off if this software didn’t exist. I hope Microsoft breaks it sooner than later!

iirc the Linux kernel dropped support for pre-Pentium x86 in the last few years, so any distro with 486 support now would be using an unmaintained kernel.

I think if you want a maintained operating system for your 486 today, NetBSD is probably the thing to run.

strace cat

man cat

AUR is bad, actually

But why rewrite programs that existed for decades and have proven their stability and safety? Rewriting them to Rust won’t make them safer, it will just introduce the kind of issues original versions have got fixed long ago.

Of course rewriting them will introduce some new issues, but it will also eliminate classes of bugs from which there are definitely still a great many in old “stable” C code (bugs which are now being discovered and will presumably continue to be discovered at a much faster pace due to LLMs).

The whole project is about abolishing GPL. And Rust is just an excuse.

I don’t think it is just an excuse; I believe that improving security is also a goal… but removing GPL code is clearly also part of their motivation :(

No, it is not a good time. A project like Ubuntu should now be in freeze as they had about 3 months before release

This bug was reported (and resolved by rolling back to the GNU coreutils version of cp) on June 30, a little over 15 weeks prior to the scheduled release date.

Which distros have a feature freeze that far in advance?

Ubuntu hasn’t even scheduled theirs for this release yet; if you edit that url to look at previous releases’ schedules you can see their feature freeze and debian import freezes are typically about 2 months prior to release. (See here for descriptions of all of the different types of freezes…)

What an absolute shitshow

I’d say the month of June is actually a good time to be breaking and fixing things in a release that is due to come out in (checks notes) October.

sydney morning herald my head

i concur, but a lot of people do start out with Arch afaict

Wait but that means your computer will stay on if the update fails, right?

If it was && then the second command would only run if the first command was successful.

But @vodka@feddit.org wrote only one & which instead means the first command will run in the background and the second will execute at the same time… which does not seem like a good idea in this case 😅