I have a request for all the #GNOMEOS users: please update to the latest version, and try to get your system to lock up because it's running out of memory. Report back how it went, compared to the usual experience on the same hardware. #GNOME
Remote
Sebastian Wick
@swick@hachyderm.io
mastodon 4.7.3828 Followers
521 Following
47 Posts
Joined June 07, 2025
Website:
GitHub:
GNOME OS on an ePaper panel driven by @modos@fosstodon.org glider at 75hz over USB C. The cursor feel smoother than on some shitty 60hz LCD displays and scrolling around works surprisingly well. Absolute game changer for working on the balcony.
Trying to answer a question no sane person ever had to ask: How Hard Is It, To Open a File?
This one is about the great POSIX idea of a filesystem, and why you could not play your games and open chrome for a few days.
https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-a-file/
Ach was, haben wir also doch ne sirene hier
Instead of taking any part in the monthly wayland bashing bullshit, you could just read about how electron, one of the last X11 bastions, has adjusted to wayland. Super important work!
Someone wrote a postmortem on the security issues uncovered in uutils, "the Rust reimplementation of GNU coreutils"
https://corrode.dev/blog/bugs-rust-wont-catch/
It is an interesting read on its own. The author praises Rust for managing to entirely eliminate memory safety issues in uutils. My view here is unfortunately closer to that of Lennart: the remaining class of bugs are to a large part the fault of the Rust stdlib, and entirely avoidable.
(see also my last blog post @swick@hachyderm.io)
LTS is a scam and always has been
Wrote a bit about some of my work around the definition of wayland content updates, which recently landed in the core protocol.
https://blog.sebastianwick.net/posts/wayland-content-updates/
Replying to
Now that libdex supports dbus, and I could play around with it for a while, I thought it's a good time to talk about ownership in GLib, and specifically about how fibers affect it.
https://blog.sebastianwick.net/posts/glib-ownership-best-practices/
I felt bad for having written a blog post that says that pidfd's are basically useless, because they definitely are not anymore. So a wrote a follow up where I explain how they solve a pretty big architectural issue for (sanboxed) apps, when combined with modern cgroup features.
https://blog.sebastianwick.net/posts/so-peerpidfd-gets-more-useful/
Replying to
Replying to
Replying to
@decathorpe @nathandyer do you still have the page around? The wayback machine never indexed it.
Replying to
Replying to
Also why the fuck is no one even talking about how he fucked over the Kurds again?
Usually it takes decades for the fucked up US ops to get public but this time they admitted to trying to send small arms to Iran after the deadly protests like two month later, helping both the Iranian regime with their propaganda and giving Turkey, Syria and Iran even more reasons to crack down on the Kurds.
Replying to
@132ikl I honestly don't know the impact on longevity but from what I gathered it should not be a problem. I guess I'll find out. The reason why the panels are usually not driven with high frequencies is that most epaper devices are designed for low power and thus are driven by ASICS in SoCs like the i.MX. The modos glider is a beefy FPGA instead.
Replying to
@federicomena Just like all the memory issues where blaming beginners and having them screw up totally lead to people learning how to prevent them.
Replying to
@pid_eins oh, and with varlink and appd it can be exactly two because no more dbus-proxy, no more frontend/backend split, and no call for the creds/permissions.
Replying to
@jimmac@mastodon.social I remember listening to tomorrow's harvest like 10 years ago and it was magical. The older stuff I listened to afterwards never quite gave me that feeling. Super excited to see where this is going!
Replying to
@spyke So you read it, and the part where they are now migrating because Chromium, which they depend on, turned on wayland by default. You presumably also used a Chromium based browser in the last few years which is obviously using CSD.
Yet you uttered those absolutely deranged sentences thinking that they might in any way shape or form be true?
Replying to
@zeenix If there is a database library with an API based on string manipulation instead of prepared statements, you would never touch the project. You could equally argue that lots of people write software which uses databases but never have to care about malicious inputs.
Why would you provide an unsafe API when you could just provide a safe API?
Opaque handles to filesystem objects are not particularly hard to abstract in a cross-platform manner. In the worst case that handle is internally just a path.
The argument that a crate exists is missing the point. People use what is in the stdlib and they do not even know that they should look for something else.
That would be fine if that code is never used by anyone else, but realistically re-using code is a necessity.
So if you try to re-use code, you either can't because you notice at the API boundary that e.g. a function call requires a path, or you don't notice that you can't because the security issue is somewhere hidden in the implementation.
For example glib uses paths for everything. If you want to trash a file the API requires you to pass a file path. I cannot use the code to trash a file and had to re-implement all of it. glib could have made it secure, we have a library for it: libglnx. It didn't help at all.
The issue here is that code does not compose.
Replying to
@pid_eins FWIW, I have a change for glnx_chase which adds a strategic callback for every path segment that gets resolved, so we can, for example, build the path without adding more complexity to glnx_chase itself. I also hinted at a new cross-platform API in GLib/Gio where we would want to have an opaque handle, which for posix would contain the fd, but it could also contain the path as well. So yeah, I agree that it's the right design, but I think it's something we should do on top of glnx_chase.
Replying to
@federicomena object capabilities are a really good concept and fd passing is just that, but this kind of path traversal is something a service is doing internally and maybe even after having received a fd. so I don't reaaaly think that this is about ocaps.
Replying to
@ryanabx well, appd would allow us to go from unix socket to app identity.
I am a bit worried about people exposing all kinds of varlink interfaces to sandboxed apps. the nice part about portals is that it forces everyone through one place where we make sure everything functions correctly together without poking holes in the security. we really have to retain that.
Replying to
@pid_eins should have counted the context switches of a portal call for maximum effect :p
@rmader also just boarded my first train!
Replying to
@wingo@mastodon.social Somehow I feel the urge to just point you at this: https://modal.cx/principles/
Replying to
@zygoon file an issue: https://github.com/uapi-group/kernel-features It does help sometimes :)
Replying to
@jessica If you don't have multiple processes with different capabilities you really don't have to care. But really, this should all be handled by the stdlib so you never even have to figure out if you have to care.
Replying to
@uis@pone.social @vtrlx@mastodon.social > yet it misses important part: the discussion was instalocked on GNOME side.
I wonder why