@GrapheneOS @kuketzblog I would archive to archive.org and in addition take screenshots if that's a concern. The advantage w/ screenshots also is that, assuming you just post them here, they will never go down unless your infra does (or you remove them)

@GrapheneOS @kuketzblog I'm asking just because I genuinely want to know how easy it is for someone harassing to do such a thing.

@GrapheneOS @kuketzblog When did that happen, on what URL, by whom, and why?

@GrapheneOS @kuketzblog (also, I recommend against linking to archive.is since that website and the whole family of archive.ph websites are involved in a harassment/DDoS campaign: https://arstechnica.com/tech-policy/2026/02/wikipedia-might-blacklist-archive-today-after-site-maintainer-ddosed-a-blog/)

@GrapheneOS @kuketzblog Okay, Duval (and Rossmann/FUTO) are attacking you publicly.

Are individual (previous or not) users attacking your developers personally?

@GrapheneOS @kuketzblog I'm not saying it is inaccurate info.

Who is attacking your developers personally? Where? How? Why?

@GrapheneOS @kuketzblog I think criticism, while valid, doesn't have its place in a project account. It should probably be in some developer's fedi account, or if that's not possible, in CW in your project account. People sometimes want to read your account to learn about GrapheneOS news, not to learn about other people saying inaccurate stuff about it. By talking a lot about them you're (unintentionally) basically advertising for their content, giving them attention, and I'm not sure that's what you want.

You just can't fix every single article talking about GrapheneOS. But you can recommend reading the official documentation to users confused about them, or even you can get in touch with people writing about it to gently suggest corrections. Inaccurate claims aren't necessarily intentional.

We really, really, really need to stop using oil. It's destroying the planet, causing neverending wars, eroding countries' independence and crippling the world economy.

It's no longer just an ecological priority, it's a national security priority and an economic priority. People of any political persuasion ought to be doing everything they can to replace fossil fuels with other energy sources ASAP.

• Claude code source "leaks" in a mapfile
• people immediately use the code laundering machines to code launder the code laundering frontend
• now many dubious open source-ish knockoffs in python and rust being derived directly from the source

What's anthropic going to do, sue them? Insist in court that LLM recreating copyrighted code is a violation of copyright???

Looks like exactly the kind of AI abuse I feared could happen in the kernel is happening.

Now you can see why I pushed back so hard on the automated tooling docs to make it clear we should reject this crap out of hand, being attacked in various publications online for saying so.

Wonder if they will talk about this or?

And yes I told you so.

https://lore.kernel.org/linux-mm/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/

@hexaheximal Blame ASUS then not U-Boot

@hexaheximal just use efi

RE: https://econtwitter.net/@TimHarford/116375811993176529

And this is what #LLMs s destroy.

The human joy of just figuring shit out.

Doesn't matter if it's useful now. Someday it could be invaluable. Or it may not.

Like how people studied bees and ants to understand how they decided on the best routes between their homes and their food.

That understanding ended up embodied in how packet routing happens on the internet.

You would not be reading this if people had not studied the social behaviour of ants.

One of my favorite features of the Baochip-1x is the BIO. It's an I/O coprocessor that is based on the PicoRV32, with custom register extensions to allow direct access to GPIOs from the ISA.

Read more about the BIO at this blog post: https://www.bunniestudios.com/blog/2026/bio-the-bao-i-o-coprocessor/ I go in-depth into the architecture and its trade-offs relative to the PIO, and conclude by working through a couple of coding examples.

POV: we’re all living on the most beautiful tiny blue dot in the universe… and a handful of greedy nature-wrecking billionaires are ruining it for all of us.

Earth could be the perfect place, with a future that works for everyone, not just a few.

@moses_izumi @elly @justsoup @noisytoot @stilic @weirdtreething (compositor requires at least GLES2 iirc, else it does sw rendering and yes that'll be slow)

@moses_izumi @noisytoot @elly @weirdtreething @justsoup @stilic It could also very well be broken GPU drivers or something

@noisytoot @moses_izumi @elly @justsoup @stilic @weirdtreething Latest GNOME with wayland runs completely fine on HD4000 (while being quite slow on GNOME+X11) so I'm not sure how KDE wayland would run this badly

@moses_izumi @elly @weirdtreething @justsoup @stilic

> The security thing kinda comes down to postmarketOS prioritizing hardware support above all else: for better or worse.

What do you mean by that? Hardware may be our priority but it isn't the *only* priority.

> - packaging more applications for APK, instead of falling back on the Flatpak ecosystem
> [shipping gobs of libraries doesn't make sense on phones, especially if there's no microSD slot]

apk is the main way of getting apps installed in postmarketOS. Many postmarketOS maintainers also maintain a few packages in Alpine aports and some of them are even Alpine developers. Things like the GNOME and KDE stacks have some postmarketOS folks involved. KDE was originally packaged by a postmarketOS developer.

If you feel there's a lack of apps in apk, then the Alpine folks certainly wouldn't mind more people getting involved packaging :)

Unless you're talking about the immutable version, Duranium, which does currently prioritize Flatpak, however it is still in its very early days and much more WIP than "classic" postmarketOS.

> - pairing KDE Plasma with a more lightweight window manager and/or compositor
> [Wayland backend runs like crap on my Intel HD 4000 and UHD 620 laptops]
> [X11 backend is fine, but XFCE is still faster]
> [Discover takes an annoying amount of time to load on my i5-3320M]

We won't alter desktop environments beyond what is officially supported upstream. These are things you can do yourself. You can even use different desktop environments like XFCE4, LXQt, MATE, sway, and plenty more :)

That being said, Plasma Mobile runs quite well on my ancient tablet, which only has 4x Cortex-A9 + Mali400, and that is Wayland-only. I've heard lots of progress towards making KDE more lightweight, and I've been told it can even run on ancient 20 year-old hardware mostly fine.

> - shipping images with a non-UEFI bootloader

80% of device ports ship images without UEFI support, so I'm also not sure what you're talking about, unless maybe you mean the generic-x86_64 device port.

No one has added BIOS to that port yet, you're welcome to step in and do it. But I will say that I'm writing this from a 2011-era laptop booted to postmarketOS over UEFI, so UEFI is not *that* new either (I even have a 2006 MacBook which also supports EFI)

> - providing a dedicated pmbootstrap liveCD
> [as a recovery thing]

There's os-installer for that I think, would that be enough for you? A bunch of other prebuilt x86_64 images are available too which can be used for recovery, though changes are persistent (maybe we could support nonpersistent livecd).

> - making a Wine frontend, just to have one last laugh at the Windows RT and Mobile situations

apk add wine and have some fun ;)