<unnamed>

Public Key

npub1qehhquj5c86s7juhwa3km9mcx749zy2nx3y6qh8uu3ud2fdtzjjs8pye8a

Profile Code

nprofile1qqsqvmmswf2vrag0fwthwcmdjaur02j3z9fngjdqtn7wg7x4yk43ffgprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntqy2hwumn8ghj7un9d3shjtnwdaehgu3wdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv0vdahm

Publishing to

Last Notes

2026-06-30 19:34:13 CEST

- reply

Seems like this is manufacturers cheaping out
They made a pact that they'd all add these reminders so that people remember to check the seats. The idea was that they'd have sensors to check occupancy. But many manufacturers didn't end up adding the sensors (cost?). So now we have useless alerts that happen on every shutdown instead
Apparently in 30% of these cases the kids are in the car w/o parent knowledge, so a reminder won't help
Source: https://www.kidsandcars.org/news/carmakers-agree-to-add-rear-seat-reminders-to-prevent-deaths-in-hot-cars

2026-03-17 19:21:13 CET

Nature decided to help out my alarm clock this morning by exploding a meteor over my house
https://cdn.fosstodon.org/media_attachments/files/116/245/767/951/418/590/original/091cf214a2c13b8e.mp4

2026-02-15 01:07:22 CET

- reply

Some of these mice are also keyboards, from a USB perspective. Stuff like this ensues

2025-10-30 23:55:38 CET

- reply

Looks cool! I think the scaling factor is a bit low though, no? I think it would make sense to turn on 2x scaling for the screenshot, so that it's more visible
It may look weirdly large on your display, but in other contexts the screenshot from your display is a little too high res and everything looks tiny

2025-09-19 19:28:08 CEST

👀 (still very unfinished though!) #gnome
https://cdn.fosstodon.org/media_attachments/files/115/232/106/737/967/198/original/a911a80643fa24f3.mp4

2025-06-05 18:38:47 CEST

- reply

You'll be happy to hear that this all will be gone in GNOME 49 and things will work much better. Also, this can only ever happen on X11 - try the Wayland session

2025-02-22 02:32:56 CET

- reply

A successful example of this kind of approach, IMO, is Ubuntu. Their name basically means something along the lines of "humanity towards others", and their logo is a ring of people holding hands. In short, the branding quite literally represents community
It would be great if GNOME could iterate on that approach. It'd be a brand I'd be a lot more proud of. It would be more representative of what I'm working for. I suspect others will feel the same.

2025-02-22 02:06:23 CET

So I was thinking about the #gnome logo. Perhaps it's a simplified representation of a human footprint. What might it mean then? How about: "An independent computing platform built for humans, not shareholders"
Reinterpreted that way, maybe we can start to find its connection to the community. And that's the important thing to preserve in a rebrand
Maybe a new brand will be less quirky, but I don't think we've lost anything if it's more serious about the mission that drives the GNOME community

2025-01-14 20:05:17 CET

- reply

Take a look at a Rust crate called Iroh. It does a lot of magic for you already. No fleshed out peer discovery, or directory of devices that you own, but you give it a 32 byte "node ID" and it'll give you a UDP (actually: QUIC) tunnel to the other device. Punching through NAT and whatever

2025-01-14 19:39:32 CET

- reply

Very cool stuff.
Here's a future I'm envisioning for this:
- Built into the OS
- Built with our local-first networking stack (currently an experiment in Aardvark). This will establish a usable UDP connection for you, punch through NAT, etc. Also automatically pairs devices you own
- Copy Apple's trick that uses (ultra)sound + microphones to automatically determine relative positioning of the monitors
This would make it super seamless. On par with Apple

2024-12-10 20:39:33 CET

https://www.howtogeek.com/why-i-want-to-see-an-official-gnome-only-os/

2024-11-11 18:49:39 CET

- reply

Are you aware of https://gitlab.gnome.org/bertob/app-ideas?

2024-10-26 07:49:52 CEST

- reply

The law makes no distinction between employees of banned companies working on their own time versus on company time. That's the legal basis of the move.
And frankly, I wouldn't want that distinction. The companies on the list are there for a reason: they're the ones building the tech used to commit the war crimes. The drones and missiles used run Linux. They can, b/c it's FOSS. But allowing the same people who make the weapons killing Ukrainians participate in our communities is on us.

2024-10-25 03:26:22 CEST

Time to make it official! I want to turn #GNOME OS, GNOME's home-grown distro for testing and development of the GNOME Desktop, into a real production-ready general purpose OS. I finally blogged about it: https://blogs.gnome.org/adrianvovk/2024/10/25/a-desktop-for-all/

2024-09-02 23:18:31 CEST

Fedi moderation idea: UEFI Secure Boot.
We have a big circle of trust. We switch from denylists of known bad servers to allowlists of known good ones. You can join the trusted network if some existing member vouches for your instance, and the network effect takes over. Participation requirements include moderation, failure to moderate = removed from the allowlist. List is centralized but maintained by consortium of sufficiently big instances.

2024-08-25 01:31:27 CEST

- reply

(removed extra pings for the tangent).
Ok I see where you're coming from now.
So something like a "KernelUX" blob (eBPF program?) loaded in by the bootloader, similar to initrd? It's fed all potentially "user visible" events (panics, printk, various loading progress, coming/going of FB) to be handled. Then once userspace exists and DRM initializes it can take over the framebuffer and continue pretty logging.
Boot splashes would be split across a KernelUX blob and a userspace daemon

2024-08-25 00:25:49 CEST

- reply

For that short period of time, I wonder if it can just log straight onto EFIFB without any formatting or anything. No ~~VT~~ TTY emulation. Just text on framebuffer. Doesn't have to be pretty, just enough to get the data out. Then stop doing that when SinpleDRM is init'd
Presumably that's how it would have to work anyway, right? DRM isn't initialized right at kernel start. Though it scrolls by so fast it's hard to tell if you're seeing all the log messages 🤷‍♂️

2024-08-25 00:23:38 CEST

- reply

Is the intent to let distros customize the appearance of DRM panic?
My point, ultimately, is that the kernel already shovels data into places the user can see. The features you're proposing exist, at least if I'm understanding what you're asking for. Panics will soon be shown to the user via DRM Panic. Userspace can already get early pre-initrd boot logs up to the kernel starting.
The one case that the kernel cannot cover is between ExitBootServices() and PID1

2024-08-25 00:03:30 CEST

- reply

on kernel panic the entire OS is considered a lost cause, kernel included. DRM Panic is likely safe enough because ultimately it just dumps data onto a buffer in memory. Launching a userspace process, however, is infinitely more dangerous: it goes through the VFS layer, does arbitrary IO, can call arbitrary syscalls, etc... disk corruption is a lot worse than not telling the user about a panic
Most OSs just insta reboot on panic because of this... see: pstore

2024-08-24 23:38:29 CEST

- reply

re: kernel panics. I think running processes would be deemed too unsafe. Anyway, there's already a DRM panic handler being worked on in the kernel. systemd-bsod needs a functional VT, btw. Eventually it can be integrated into Plymouth too.
In general, the kernel magically spawning processes ("callout binaries") causes headaches for init, and ultimately the goal is to do less of that not more.

2024-08-19 22:11:19 CEST

- reply

Finally, the FHS probably isn't as relevant today as it once was.
If you're an app dev, you can package up a Flatpak (where FHS need not apply) instead of making dozens of distro packages.
If you're a library upstream, you already have to expose configure knobs for paths because each distro does a slightly different thing.
If you're a distro packager, you've already been doing your own thing forever. Again, FHS need not apply
It's a useful convention, but that's it IMO
2/2

2024-08-19 22:06:22 CEST

- reply

As you said. The FHS seems somewhat defunct.
systemd documents the "new" FHS most distros (through systemd) have been following in recent years: https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html. I think this is an appropriate starting point
The appropriate standards body to do this through is probably the UAPI Group: uapi-group.org. It's a standards body created to standardize OS-plumbing-level things (bootloader config, discoverable partitions, etc) across distros.
1/2

2024-08-14 22:46:35 CEST

- reply

it's the ultimate test