Considering how poorly “the remarkably well supported ARM” Raspberry Pi is at playing video, I am shocked.

It’s fucking crazy how much work goes into shitting out thousands and thousands of slightly different models of android phone and tablet and chromebook. Slap together a board design based on buying two trays of some SOC. Open up the Android source, slap some NDA drivers in, build an image, burn it into a production run. Don’t bother saving your changes, these devices will never get an update. Two weeks later, change out the whole design for a different chip, repeat.

The vast majority of xz’s blobs are accounted for, too.

I thought this was pretty solid talk on SElinux https://www.youtube.com/watch?v=_WOKRaM-HI4

If you think it’s hard to figure out GPG for yourself, well good luck finding and communicating with someone else who has also figured it out.

You can grab Kate from the Windows Store right now. Get all of the KDE apps, they’re pretty much the only good stuff on there.

It’s a shame that that the list doesn’t translate well into “what device can I go out and buy”? Every shitty manufacturer has to constantly churn design changes, and hide it all behind the exact same model number.

Is there a reason to install one(1) singular OS across multiple partitions? Is it just because that’s how our ancestors did things?

Partitions are crude buckets that tell Operating Systems that “this lump is a filesystem that you know how to read” or “you don’t know how to read this, leave it alone”. Partitions tell UEFI that it should only use this special FAT32 chunk. A partition is not a good mechanism to set quotas, as you can see from how difficult it is to expand. A bunch of partitions that are all mounted together does little to isolate against failures.

If you want to run an OS across two filesystems that provide different characteristics (one provides atomic snapshots, the other provides ??), that would have to live on different partitions. Would you be better served by putting it all on the more modern FS? Is the older filesystem only kept around because it straddles “what my OS knows” and “what my bootloader knows”? If it’s just for the bootloader’s sake, that’s why we have /boot.

First you have to make a new --user remote. Then you can list your current stuff and install it on the --user side one package at a time, (with --no-pull so it sucks the existing install). Then, you delete the --system copy of packages.

Instead of having an efficient chip monitoring the power button, they integrate that job into some 10nm chip. That chip doesn’t get to power off, so it just pisses away power on gate leakage all day long.

Debian Testing.

ARM systems don’t have the whole ACPI thing to describe what hardware is where. Linux has to bodge together its view of the system with a devicetree instead. If you don’t know what device IP blocks are integrated into the SOC (and locked behind an NDA), good luck blindly guessing. You don’t even get EFI booting, you get shit like “the rpi gpu runs its own proprietary bootloader lol”.

Has Qualcomm ever been helpful?

Lobster was an unbelievably buggy distro. I had no end of sleep and compositor problems, and outright system hangs on it. Minotaur was better, but still give me far too much crap.

I would rather run a “crack monkeys with a sourceforce account” nightly distro than go through Ubuntu’s idea of a beta again.

I think “endurance” cards are where you get something reasonably non-self-destructive, for a modest premium.

Ghidra is properly Java, so better luck looking there.

I’m somewhere between Kitty and Ptyxis.

Wait till you see a Mediatek

The PineTab doesn’t even have a wifi/bt radio that’s supported by its own OS. When you’re an OEM and you’re choosing what chips you’re putting in a design, I think you should stick to chips that are usable. Chips where the manufacturer has written specs and maybe even a driver that transforms “a piece of glass with a lead frame” into something with a purpose.

Anyway, that’s just how I feel.

deleted by creator