PhD student in Neuroscience by day, free software developer by night. Debian Developer, KDE and GNOME member; working at @purism
Opinions are my own.
| Blog | https://blog.tenstral.net |
| GitHub | https://github.com/ximion |
I tried this AI thing - it very helpfully found a bug in my code and suggested a fix...
It is a damn helpful tool sometimes, but it really feels so strange to me when people say the machines are "understanding" or "thinking". They aren't (yet...). Humans just gained a new tool to help them problem-solve, but they will still have to do that work, instead of giving up control to the statistics machine.
Thanks to everyone who’s contributed to improving our app centre and updater!
Merge request contributions are always welcome, there are plenty of UI papercuts which you could help to fix — https://gitlab.gnome.org/GNOME/gnome-software/-/issues?label_name%5B%5D=User%20interface 😁
I fixed it by adding some heuristics to libappstream to explicitly quote something we know should be a string if it starts with a digit/punctuation (for performance reasons).
I would just like to simply quote every string and be done with it (it's also more JSON-like). But keeping the more minimal style instead of changing how the emitted AppStream YAML looks like (breaking tests) was the better, more conservative fix. - For now.
Fun times in AppStream and Debian land: GNOME 2048 dropped the "GNOME" part from its app name, so that it is now just named "2048". Nobody expected app names to be plain integers, so when this value is written to a JSON/YAML file by libappstream's C code, it writes/reads a str, but type-aware parsers (in Python) parse it as int. In Debian's downstream tooling, something that should be str is suddenly an int and fails validation.
This in turn halted package publishing on the Debian archive...
...so, therefore, huge shoutout to MSYS2 which was my salvation in so many ways! Automating Windows builds was really easy, and for the actual build steps I could even use a familiar UNIX-y environment, while still getting a fully native Windows binary out. Not sure why I didn't use this sooner for past projects!
Of course, the Linux builds of the same app were up and running in seconds, thanks to distro packages and great CI 😉 2/2
I had to build a Windows app (for scientists...) and while we do love to complain a lot about fragmentation and all the issues we have on Linux: Windows is a different kind of hell, with fragmentation just being at a different spot!
Creating CI for Windows was absolute hell, vcpkg is nice, but without caching slows down automation a lot, trying to build an MSI package was a very bad idea (what a crazy design from a Linux perspective!), getting anything reproducible isn't easy... 1/2
The protocol is still experimental, so no client should expect it to be present in a compositor (and there are for certain compositors which will never have it).
Also, the xx-zones protocol now only addresses xy-positioning, the z-positioning was spun out into `xdg-toplevel-groups`[1] prior to the merge and may get wider support.
In any case, all of this is positive news for complex professional or multiwindow apps on Linux/Wayland!
2/2
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/471
The xx-zones #Wayland protocol for client window-positioning hints has been merged as experimental protocol into w-p a few days ago! 🎉
This means toolkits and compositors are now able to implement it and experiment with it, and we will see how the protocol fares in the wild and is actually used by toolkits (which was a matter of great debate). It also permits all the prototype implementations to converge on one protocol, instead of shipping incompatible snapshots. 1/x
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
Here's the third published video of my FOSDEM talks, about the Varlink IPC system:
https://video.fosdem.org/2026/ub2147/NFNKEK-varlink-ipc-system-keynote.av1.webm
This was the last one of the three. Enjoy!
Philip Withnall
Lennart Poettering