Sebastian Krzyszkowiak @dos@librem.one

Q: And it will continue to work on non-Linux systems like FreeBSD?

A: Also correct.

Q: Why have I been hearing that KDE will force systemd down everybody's throats via Plasma then?

A: There are sad people who will do anything for attention and clicks, and will spread FUD and fake controversies to obtain them, including decontextualising comments on merge requests, stating as facts and official communications what are personal opinions, and finally straight up lie.

Don't believe the FUD.

3/3

@marmarta @dos @camerontw Honestly the right answer to the question of who to disappoint is always going to be "the developers and designers of the thing." Our egos lead us to solve product problems over user problems, to end up with supporting a bunch of "use cases" no real user has.

So, some great conversations at #fossback26 design. And some that really frustrated me. During the "how to bridge the gap between "ultra-nerdy" devs and designers" barcamp, someone said "we have to decide who to disappoint when making design decision", and someone else said "spoiler: it's the power users".

If our attitude towards #uxdesign is "fuck the power users", we'll never have good UX in open source.

current status

He’s so fluffy!!!

this is just ‘Sent from my iPhone’ for gen zalpha

This is why GiovanH's blog article is a must-read.

People assume that accessible hacks of invasive systems will always exist, and users hacking their devices is to be expected.

THIS SHOULDN'T BE A NORM. THIS IS AN ARMS RACE AND WE'RE OUTMATCHED. /7

https://blog.giovanh.com/blog/2025/10/14/a-hack-is-not-enough/

a decade or so ago, I was writing a H.264 decoder (needed a custom one for stupid reasons which of course had to do with hardware reverse engineering).

the first order of business was to implement CABAC: the final entropy coding stage of H.264 (ie. the first layer I had to peel starting from the bitstream), a funny variant of arithmetic coding. the whole thing is quite carefully optimize to squeeze out bits from video frames by exploiting statistics. in addition to carefully implementing the delicate core logic, I also had to copy-paste a few huge probability tables from the PDF, which of course resisted copy-paste as PDFs like to do and I had to apply some violence until it became proper static initializers in C source code.

furthermore, testing such code is non-trivial: the input is, of course, completely random-looking bits. and the way bitstreams work, I’d have to implement pretty much the whole thing before I got to the interesting part.

so, a few hours later, I figured I’m done with CABAC and reconstructing H.264 data structures, and pointed my new tool at some random test videos. and it worked first try! the structures my program spit out looked pretty much as expected, the transform coefficient matrices had pretty shapes and looked just as you’d expect them to, and I was quite happy with that.

and then I moved on to actually decoding the picture from the coefficients, and this time absolutely nothing worked. random garbage on screen. I spent a long time looking at my 2D transform code searching for bugs, but couldn’t find anything.

and then it hit me exactly what “entropy coding” means. I implemented something that intimately knows and exploits the statistical properties of what video transform coefficients and other structures look like, their probabilities and internal correlations, and uses that to squeeze out entropy and reconstruct it on the other end. my “looks good” testing meant absolute jack shit: I could’ve thrown /dev/urandom into the CABAC decoder instead of actual H.264 video, and it would still look like good video data at this stage until you actually tried to reconstruct the picture.

and sure enough, it turned out I fucked up transcribing some rows from the PDF around a page break or something.

10 years later, I think of this experience every time I see a vibecoded pull request, or other manifestation of AI bullshit. all the right shape, and no substance behind it.

and people really should learn to tell the fucking difference.

This is a real time recording of my git server's web access logs. It's a constant stream of requests from "Claude" attempting to access every possible item on the site.

A couple of months ago, I set up a rule to return an error code for every request its user agent makes. It has not retrieved a single valid item for many, many weeks at this point. Every request is immediately and abruptly terminated.

It hasn't even slowed down as a result.

Tell me again how their operation involves "intelligence" of any kind.

sometimes i’m thinking about becoming a vibe coder because i’m lazy as fuck but then i realize the models tend to be even lazier than me

IRCv3 is shaping to be amazingly good!

here's the things it offers, today, right now, on a chat server we just set up in one evening:

you don't need a bouncer (friggin finally). there are moblie clients that work well
you can see backlog when joining a channel
you can browse chat history
you can connect from multiple devices with one account and nickname
if you disconnect, your nickname is still present in a channel you joined, marked as away
you can highlight or DM people who are away and they'll see your message when they join (without crutches like MemoServ)
there is a "last read message" marker and it is synchronized between multiple connections
you don't need to deal with fussy nonsense like NickServ authorization, ghosting, or such; connect with your username and password and that's it
there are typing notifiers, if you want them
there are message reactions, if you want them

here's the things it does not offer:

image, video, or file uploads
stickers
complex onboarding tools

unexpectly, i realized that IRCv3 can completely replace Matrix rooms for my own group chat purposes, and i'm probably not going to set up any Matrix homeservers again; it's just not worth it and frankly I should instead put that effort into coming up with a file upload IRCv3 extension or something