rotopenguin

I use Ubuntu, which is apparently the least popular distro around.

My favourite part is when it ends with "buy the steam deck on Amazon [affiliate link]"

Yeah, that's the last place where I'll buy it.

Has anybody mentioned yet that tar isn't even a "compression format"?

It's kinda wild that GTK's grandpappy is now the last thing to get updated to the current GTK.

How do you know there isn't a logic bug that spills server secrets through an uninitialized buffer? How do you know there isn't an enterprise login token signing key that accidentally works for any account in-or-out of that enterprise (hard mode: logging costs more than your org makes all year)? How do you know that your processor doesn't leak information across security contexts? How do you know that your NAS appliance doesn't have a master login?

This was a really, really close one that was averted by two things. A total fucking nerd looked way too hard into a trivial performance problem, and saw something a bit hinky. And, just as importantly, the systemd devs had no idea that anything was going on, but somebody got an itchy feeling about the size of systemd's dependencies and decided to clean it up. This completely blew up the attacker's timetable. Jia Tan had to ship too fast, with code that wasn't quite bulletproof (5.6.0 is what was detected, 5.6.1 would have gotten away with it).

The Steam Deck only does VRR over Displayport. Valve has their own engineers working on every part of the software stack. It's their own hardware and their dock. With all that, Valve still can't get VRR over HDMI to work.

Fuck the HDMI forum.

This is the first time I've heard about gluing a cable to the heat shield cover. Oof.

KDE: we have compositor crash recovery in testing

Gnome: we broke the extension interface, again

The actual news is "renews focus on AI bullshit".

My $0.05 reading of it is that they want to hose down the build servers* and start clean, in case if the attacker escaped the sandboxing there.

• (the computers that compile all of the new packages from source, not web servers that are handing out finished deb binaries to the public.)

I'm happy for new buyers getting a better deck that I got. That makes more of us to tell game devs "you will test and tune your game to run well on the Deck". It means more games that work for me.

The more EA breaks their own shitty games, the more powerful Linux becomes

On the plus side, snaps also crap your system log full of petty little AppArmor events. And when snap gets its permissions wrong, you can easily fix it with SnapSeal.

(If Flatpak would just fucking stop rewriting every file path as /var/run/1000/blah, it would be the unquestionably superior package tech)

The xz attack was not a clown show. It's a well orchestrated attack, with a lot of clever techniques to slip a payload into something that is supposed to be fully open and readable source code. Somebody recognized a difference between what people think ssh&systemd's dependency graph looks like, and what it actually was. Fuckery went into disabling some technical defenses (a single dot was snuck into an autoconf file! Try to find it.) and SE went into disabling others. The best malware reversers in the world have been shooting caffeine into their eyeballs for 2 days, trying to make sense of latter-stage payloads.

This attack was damn good. They either got unlucky, or there is a small possibility that our spies out-spied them and dropped the dime. Another angle is that they were running out of time - systemd developers were getting nervous about their own surface area and were working to cut that back. The attacker took the chance on running their play before it was fully bulletproofed, because it was in greater danger of becoming an obsolete exploit.

In the coming weeks, you will know if this attacker recycled any techniques in other attacks. People have furiously ripped this attack apart, and are on the hunt for anything else like it out there. If Jia has other naughty projects out here and didn't make them 100% from scratch, everything is going to get burned.

Nah, I think the next stop is Linux Vista.

Real gangstas also switch their PGUP and PGDN keys to natural scrolling.

Because fuck you, that's why

The reason you can't is "because Intel deliberately designed it that way". Back when USB was just a notion, PDAs were a really cool thing. There was apparently concern at Intel that someday these little things might be all that someone might own. You might connect your PDA directly to the printer, rather than syncing it to your Intel Desktop and printing from there. You might connect your PDA to the modem and collect electronic mailographs directly, instead of syncing with a PC. If you could do enough without the PC middleman, you might even skip on buying an Intel computer altogether.

So, Intel baked into the protocol anything they could think of to make peer-to-peer communications impossible in USB, make life easy for the singular PC communications master, and put a timing onus on devices that forced them to be dumbed-down state machines instead of computers in their own right.

And if there's a circular symlink, we fork bomb

The worst part of flatpaks is that they don't get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.

The existing buttons are made out of a plastic that wears well when rubbing against their contact-points in the case. The plastics are chosen to be compatible, self-lubricating and "not spalling or rubbing eachother to death".

I doubt that these metalized buttons have been tested for their long-term wear characteristics.

Btrfs. Just format as one big partition (besides that little EFI partition of course) and don't worry about splitting up your disk into root and home. Put home on its own subvolume so that root can be rolled back separately from it. You can have automatic snapshots, low-overhead compression, deduplication, incremental backups. Any filesystem can fsck its own metadata, but btrfs is one of the few that also cares if your data is also intact.

apt info xz-utils

Your version is old as balls. Even if you were on Mantic, it would still be old as balls.

Would you know a virus if you saw it?

Installer.exe is still safe af

Has Qualcomm ever been helpful?

"Except when something breaks after an odd update once or twice per year"

You don't need snapshots, except for the moments when you do. The point of snapshots is that they're so cheap that you can let them roll on their own and only care about them the day your system breaks.

So they called it an "Orange Pi", but it is not an ARM SBC.

That's an interesting choice.

Fish for an interactive shell, and I'll often drop back to bash for writing a script. I can never remember how to do basic program flow in fish. Bash scripting is not great, but you can always find an example to remind you of how it goes.

I would get rid of snaps.

I don't think it's going to do a whole lot of good when the whole KMS/DRM falls over.

(okay I haven't had that for a few months now. But i am still traumatized)

If somebody went to the expense of developing a bios implant to target you and your exact micromodel of computer, just give up. Hand yourself over to Mossad now, and get it all over with.

I presume that dusty is mad about being in a country that Valve won't ship to. It's a perfectly fair gripe.

It's the year of Linux on the Linux Desktop.

You only had it for maybe a year. Let it ride. Spend the money on a 2tb upgrade.

You can't "just patch it" to make snap work with another store. Instead what you've done is invented an entirely different store, which you're now going to have to maintain. It is never going to be upstreamed to Canonical. You are going to be in a perpetual tug-of-war with Canonical driving snap development towards their own needs and not your own.

I handle it more like ln -s /var/lib/flatpak/exports/bin/org.inkscape.Inkscape ~/.local/bin/inkscape

.local/bin is a directory that you may have to make, but your shell's startup scripts should automatically add it to the PATH after that.

I made a systemd script that fires when going to / waking up from sleep - it checks how long the sleep was and if it was just a few seconds, it puts the computer back to sleep.

In hindsight, I think the thing that made it work was bluetooth was somehow responsible for the initial failed suspend. The second shot at sleep happened before bluetooth came back up, so it succeeded.

/C: