Hello and sorry about the late post. I’ve been busy moving and other stuff that’s gotten in the way. I will also be idling the beginning of this month, so the next update may be shorter too.

Anyway, let’s get into the changes!

Kensa

I originally wanted to bring some of the “power-user” features from KSysGuard into the new System Monitor. I was rightfully turned down because they were hesitant of there being any use for most people and to prevent feature creep.

They suggested creating a seperate application instead. So Kensa, the detailed process viewer is born! It’s still mostly copy & pasted from old KSysGuard/libksysguard code, but updated for Qt6/KF6. And to make it clear, It’s very clearly modeled after the Window’s Process Explorer.

I have the general tab for viewing some basic information about the process. Said tab also includes an “Open With” so you can quickly open the executable in a hex viewer like Okteta.

The memory maps tab shows what the process has mapped, mostly notably which shared libraries it’s currently using.

The open files tab makes it’s return as well, extremely useful.

And one of my own design, an environment variables tab. In the future I want to add a “Strings” tab for quickly viewing the executable strings and the ones currently in memory.

Note that Kensa is very early in development and not user-friendly. You currently have it give it a PID manually and lacks a process list.

Tokodon

[Feature] The window title now corresponds to the current page. This makes it easier to identify from a task bar, too. We know the title is duplicated inside the application as well (on desktop), but that’s Kirigami’s design decision. [24.05]

[Feature] If your server doesn’t provide a human-readable error message, the network error is displayed instead. This is useful to see if the DNS lookup failed or some other network-related reason the server is inaccessible. [24.05]

[Feature] Support for QtMultimedia has been added in situations where your system lacks or cannot use libmpv. This is preparatory work for a Windows version. [24.05]

[Feature] In the same vein as the patch above, QtWebView is now optional and I included even more authentication fixes. Previously I enforced an in-app web view to facilitate authentication (compared to the external web browser method or auth code in previous versions.) This was only a stop-gap solution until I had more time to flesh out our authentication system, but now I feel much happier about it’s current state. [24.05]

System Monitor

[Bugfix] Fix the column configuration dialog being shown too small on the Overview page. [6.0.4]

[Feature] Add the About KDE page to the hamburger menu. [6.1]

[Bugfix] Made sure cell tooltips shows up more reliably. [6.1]

[Feature] Added a menu item to copy the current column’s text. This makes System Monitor just as usable as the old KSysGuard for me now, because I tend to copy the command line a lot. (And PIDs.) [6.1]

Ruqola

[Bugfix] Use a better fitting icon for attaching files. The previous icon - when viewed at 16px - turned into something completely different. [2.1.2]

PlasmaTube

[Feature] Added support for viewing a channel’s playlists. [24.05]

[Feature] I also added a Craft blueprint for Android. Note that this is only preliminary and the Android version is nowhere near ready yet. I guess this could be used for a future Windows version too.

[Feature] I implemented more functionality in the PeerTube backend, so now it’s possible to log in and perform searching. Subscriptions work too, but I’m running into an issue where yt-dlp fails to pull certain videos. If you know anything about using yt-dlp with PeerTube, please let me know if there’s a workaround. [24.05]

[Feature] Added a new feature to import/export OPML subscriptions. This only works for YouTube channels at the moment, PeerTube support TBA. [24.05]

Gwenview

[Feature] I changed the old save bar to use the standard KMessageWidget widget. This isn’t just for looks, it fixes a lot of odd visual bugs and removes a ton of cruft in the process. [24.08]

NeoChat

[Bugfix] Fixed the share dialog not appearing properly, and improve the keyboard navigation inside of it. [24.05]

Frameworks

[Bugfix] Remove some redundant QML_ELEMENT declarations which in turn reduces runtime warnings. [6.1.0]

[Bugfix] Two KMessageWidget improvements, by fixing handling of color palette changes and making the icon label vertically centered. This is for that Gwenview patch. [6.1.0]

Android

I once again sat down and fixed a ton of build and runtime issues for our Android applications, and started fixing some of the Qt 6.7 fallout. NeoChat and Tokodon build and run again, and spent some time ironing out their issues.

That’s all this month!

A few months ago I was kind of toying with the idea to start contributing to Plasma Mobile because I was getting increasingly fed up with Android and I realized if Linux Mobile was going to be my daily driver before I need to buy a new phone I better help out.

Then, after a few trivial commits I've seen that for the Plasma 6 release the navigation gestures were (at least temporarily) turned off - and since I am a very big fan of navigation gestures because they are objectively the best way to interact with a phone I just couldn't have that and I went about fixing them.

A bit of context

Why did the gestures even break by the upgrade to Plasma 6? Well, in Plasma Mobile 5 the navigation gestures were implemented in quite a hacky way - an invisible panel at the bottom screen edge that captured finger touches and handled the gesture and visual effect. While this worked this required a bunch of data moving around from KWin to the shell to show the window thumbnails which is unnecessary overhead.

So for Plasma 6 Devin Lin rewrote the entire task switcher, including the navigation gestures, to be a KWin effect which should make it perform better and use more of its infrastructure to need less bespoke code.

This went mostly quite smoothly, with few hiccups along the way. Unfortunately one of those hiccups was gestures (which now moved to KWin's EffectTogglableTouchBorder interface) simply not working anymore.

Fixing gestures

The fix was surprisingly simple: In the constructor for setting up the task switcher, including all shortcuts and gestures for it, the reconfigure function was simply never called which in turn meant the KWin::EffectTogglableTouchBorder::setBorders function was never executed. As you might imagine "setting the border" is quite a crucial part of having working gestures and one function call later gestures worked again!

Or did they

Disclaimer: I'm shuffling around the timeline a bit to make this post easier to follow, this part actually didn't happen until quite late.

Turns out the gestures did work - but oddly enough only after opening the Action Drawer at least once after every screen geometry change (eg: screen rotation). But the Action Drawer doesn't have anything to do with the task switcher and its gestures, how did it have an effect on them?

Well the reason is-... Honestly, I have no freaking clue. It makes no sense, but I also didn't really investigate it all that much, because I stumbled on the cause by accident quite quickly.

It turns out that the KWin people have done a good job at making the setBorders function quite safe to use and before reserving a touch border for an effect they first un-reserve anything that used to be on that border beforehand so two effects don't have to argue about who is allowed to react to the gesture. The problem is that for some reason in the reconfigure function in the task switcher effect logic also unreserved and reserved the borders, kind of doing setBorders job already before calling it.

Now why exactly that interfered with reserving the border I don't know, in theory setBorders should unreserve our previous stupidity and set us up properly - but evidently it didn't and when I removed our unnecessary border shenanigans in reconfigure suddenly gestures magically started working again. Either way, it's fixed now.

But define "working"

Well, it turns out that while KWin's border gesture infrastructure is quite nice, it also... doesn't allow customizing the distance a user needs to move their finger for a gesture to be "completed". It also turns out that on the PinePhone (and probably quite a few other phones) this lead to the gesture being... pretty much impossible to use. You just had to move your finger waaaaaayyyy too far (on the PinePhone about 3/4 of the screen height, see MR linked in next paragraph for video examples) to invoke the gesture. That's just unacceptable!

Luckily the fix is quite easy and a quick MR to KWin allowed us to set custom gesture distances-... or so I thought.

I mean, it did allow us to set the gesture distance, but that didn't mean the gestures were much better, so I went for another approach.

The rabbit hole.

(I'm talking about this monster of an MR from here on out, it also contains a video example of the almost-final product)

Ooooooh boy.

I'll have you know that I have quite strong feelings towards what navigation gestures need to be able to do to be a nice user experience.

One very crucial part of this for me is being able to "flick away" an app and go to the homescreen. The old navigation gestures didn't support that - to go to the homescreen you needed to open the switcher, then tap on the side to close it. That's TWO WHOLE FINGER TAPS - UNACCEPTABLE (Well, one drag and one tap, but let's not be pedantic).

And while we're at it, having "quick task switch" gestures would also be really nice - but I'll keep those for followup MRs, first I need to just revamp the task switcher backend to support tracking gesture velocity to discern between a drag with a pause at the end or a quick flick.

Velocity Tracking

I'm gonna gloss over a lot of the details, but for a quick too-long-didn't-care-enough-to-write-it-all-down: KWin's gesture system doesn't expose gesture positions, just percentage based activation factors so I had to do some work to massage that into giving me the right data.

After said massaging we now magically get the "primary" and "orthogonal" gesture position from KWin we can sit down to create velocity tracking

Moving average

My first gut reaction was to implement a normal moving average calculation and after chatting a bit with Devin it seems other projects went for a similar approach. But then I looked at the moving average calculation in other places and... it looked so complicated and bloated and over the top to store all the past values and iterate through the entire list of them to average them out and doing all that every frame and ...

As someone who initially learned programming by working with microcontrollers this was unacceptable (I see, this word is becoming a recurring theme). Now let's step back a bit and figure out what we actually need. The moving average is just there to filter out spikes in movement speed, be it due to inaccurate sensor touch screen readings, frametime spikes or accidentally slipping with the finger. We only want to filter, we do not actually care about receiving a mathematically accurate moving average. In fact we couldn't care less about getting a mathematically accurate moving average for our velocity.

We only want to filter

Damn. Now if only someone knew how to choose and design filters.

Looks at Uni curriculum

Oh would you look at that! Signal theory, control technology and filter design this semester. I can finally procrastinate AND study for a course at the same time!

Exponentially Weighted Moving Average

Even though I have a course on filter design at Uni, I never said I was any good at it. I mean, I'm okay enough, but not good enough to explain this filter better than Wikipedia does. The upshot of it is: It is a filter that does not need to store the entire history it tries to filter (no ugly array of values to iterate through: check), it is essentially a low pass filter (filters out transient spikes in movement speed: check) and it can be implemented in essentially 30 lines of code in a single function without any loops (not overcomplicated and bloated: check).

In fact, the EWMA filter is just a single formula that takes the previous filtered velocity, the current speed in the last time step (~frame) and a magic smoothing factor and spits out the filtered velocity updated with the newest sensor values. So that's just two lines for the actual filter (1 per axis) and some boilerplate. Neat!

Magic smoothing factor

Usually you'd pick a smoothing factor based on the sampling rate of your system and your desired time constant. To emulate the behavior of moving averages I found elsewhere I picked a time constant of 30ms. This (very roughly) means, when starting from 0, a sudden input value is applied to the filter, it will reach ~63% of the input after 30ms - and after another 30ms it will have reached ~90%. This is roughly in line with an "proper" moving average with a window of 60-70ms.

The problem we now have is that we don't have a fixed sampling interval - we get new gesture positions whenever KWin deems fit to give us some (which might be seconds apart if the user doesn't move the finger for a while). Sooooo what now? If we get a very long timescale our "roughly equivalent to a 60ms moving average" goes right out of the window.

Well, luckily with one simple formula we can calculate our smoothing factor based on a desired time constant and a certain sampling interval which we can call every time we get a new value:

smoothing_factor = 1 - exp(-delta_time/desired_time_constant)

(Maybe someday I'll add a LaTeX parser to the blog. Or I just copy in a screenshot. We'll see)

Now there is one remaining problem: As a self-respecting microcontroller dev who absolutely knows he is not restricted by a 16MHz CPU without a floating point arithmetic unit, but still cannot shake old habits that having e to the power of a floating point number in that formula hurts.

Luckily there is an approximation formula that is a bit cheaper

smoothing_factor = delta_time/desired_time_constant

That approximation formula should only be used when the delta time is a lot smaller than the desired time constant, which we

checks notes

Oh. We don't really satisfy that condition. Eh. Whatever. We only need it to filter out super high weird spikes and be roughly in the right ballpark, we don't need to propulsively land a rocket.

Some manual checks later show we'll not be all that far off the "correct" formula and we need to put a clamp on it anyways to always do a bit of smoothing so we'd deviate from the right formula anyways.

Do our "recalculate smoothing factor on every new value" shenanigans interfere with the stability or correctness of our filter? Probably, I dunno. But it's probably fine and throughout all of my testing, both throwing in arbitrary test values and empirical testing while using the gestures it all felt nice, so I give it my seal of approval!

Now... where were we? Right!

Flick!

And now with a simple check on if speed > threshold we can detect flicks! And voila - an upwards flick goes to homescreen!

2D gestures

Well, I know I said I'll replicate the old gesture behavior without touching any functionality and keep any extra features for followup MRs, but the gesture feels kinda bad when it only goes up and down and doesn't follow the finger left and right as well - and thanks to our previous excursion into KWin it also magically exposes the orthogonal gesture position, so we can just really quickly hook that up and have X and Y tracking.

States?!?!?!

As a remnant from Devin's move to a KWin effect there was a bit of a mess of what keeps state where - he simply didn't have enough time to refactor the entire thing while also updating the rest of the shell to KF6 and all the fun API breakages and so there were several places that kept track of the same-ish state that made things confusing and hard to work with.

No problem, I can refactor that and take some work off of Devin.

Quick task switch gesture

But you know what, now the task switcher code feels really clean and nice and it would be so easy to just add a few lines of logic to discern between an upwards flick and a diagonal flick to switch to neighboring tasks.

Ah to hell with it, let's add that as well!

Task Scrub

Remember how I said I have opinions on what good gestures are?

Well, I really really really dislike what Android does with their task switcher where it uses some heuristic to only reorder the tasks based on recency after you have been in a task for a while. This allows you to use the quick task switch gesture several times in a row to go "further back" in the task history.

But it's also kind of a black box as to when that happens and it really annoys me a lot - besides, the quick task switch gesture is neat for one switch, but gets very tiring to use when you have to use it several times in a row.

So how about a bespoke "task scrub" gesture that activates on a mostly-horizontal gesture invocation and allows to scrub through a large number of recent tasks.

Right.

I've skipped over a lot of detail and some entire sidequests in this story (with a lot of potential for more jokes) for the sake of brevi-WOW HOW IS IT OVER 2000 WORDS ALREADY?!

Uhm.

Wrapping Up

There's still some bugs to fix, some tasks for later MRs (though much fewer than I thought there would be) and some decisions to make, but for now this has been my small odyssey about first fixing then slightly extending then completely rewriting the task switcher and navigation gestures for Plasma Mobil

So, it’s been a while since I’ve last blogged. A lot has happened in the mobile Linux world since I made the post sharing the State of Linux on mobile. We’re 5 years further now, some distro options have disappeared and others have popped up, and although I’ve always been really optimistic about what Linux on mobile promises and can become I’ve never actually used it as my daily driver. Even though I work on postmarketOS and would say I know a fair bit about it’s shortcomings and possibilities, I’ve been relying on an Android phone for all this time to get me through life. And I’ve noticed that this is the case for a lot of people and especially developers in the Linux world.

Recently I decided this should change. How can we ever get Linux on mobile up to a state where we can use it as a proper replacement for the duopoly that is Android and iOS if nobody, including the developers, actually use it even though it’s already out there and available? I’m of course a KDE fan and would love to use Plasma Mobile specifically but it has a ton of papercut issues that could easily be solved if the developers actually noticed them by using it! So about two weeks ago I decided to get myself a new, second-hand, phone to actually daily drive postmarketOS with Plasma Mobile on and I’ll tell you about my experiences with it so far.

My setup

Although a lot of people still seem to think Pine64’s PinePhone (Pro) or Purism’s Librem 5 are the best options for a Linux phone out there, I would argue this is not the case any more. Besides the PinePhone being awfully slow hardware it is suffering from a lack of software support, the kernel is maintained by a single person in their spare time and has a ton of things not actually upstreamed to mainline, and the Librem 5 is way too expensive for what it offers and is made by a company that currently seems to have severe financial problems (they recently layed off most of their developers). Instead I would recommend a well supported (former) Android device, the postmarketOS wiki has a good list of well supported devices and specifically I would recommend getting a SDM845 device, namely the OnePlus 6/6T, SHIFT6mq (you can buy these brand new even) and the Xiaomi Pocophone F1. These are fully mainline supported and are easily buyable second-hand through platforms like eBay for not too much.

I however decided to get a Pixel 3A. This device is also fully mainline supported and I think it’s good to not have all attention focused on a few specific devices but get broader support available. The Pixel 3A was a popular phone when it was still newly sold so a lot of people might actually still have one laying around.

postmarketOS also supports a bunch of tablets which would actually be a really good use-case for Plasma Mobile.

Software

So as I mentioned earlier I’m a KDE fan, so of course I opt to run Plasma Mobile. I maintain a (semi-)nightly repository of all KDE packages that tries to build the entirety of KDE from git master every day. This has been proven very useful for Plasma Mobile development as newly merged changes can be quickly tested by consumers and also reduces the need to compile the entirety of Plasma on your phone if you want to change just a few lines in the code. It was made to support the transitioning to Qt6 but I find it so useful that I’ll keep it around in the future. So on my new phone I enabled this repository, executed the upgrade and rebooted into a fresh Plasma 6 installation straight from git master the day before.

It is good to note that although I’m definitely daily driving postmarketOS now, my sim-card is actually still in my Android phone. I do not currently trust the stability of phone calls, mostly when it comes to audio. We (postmarketOS) are working hard to improve the situation, especially by switching to PipeWire for audio hopefully soon, but for now I’m carrying two devices around having my Android phone share a hotspot to postmarketOS. The camera also currently doesn’t work so for that having the Android phone around for now is also still very useful. The camera however is making good progress with projects like libcamera making it possible to create camera applications and use it in browsers like Firefox.

So, what do I actually use this phone for? These are some of the use-cases I have and the applications I use for them:

• browsing the web with Angelfish
  • I would actually prefer to use Firefox to not support Google’s monopoly on the web by using a Chromium-based browser but I currently think Angelfish’s experience is better than the Firefox one on mobile
• make and keep track of notes with Marknote, for example shopping lists
• watch YouTube with PlasmaTube
• sync files and pictures from my NextCloud server with GhostCloud
  • I actually used this years ago when I still used SailfishOS. I was very glad to see it’s still around and even supports Ubuntu Touch and regular desktop Linux (and thus Plasma Mobile) as well nowadays. A Kirigami based-UI for this so it fits in better would be nice but it’s very usable as is
• chat on Matrix with NeoChat
• listen to my music with Elisa
• manage my local files with Index
• manage my calendar with Merkuro
• do offline turn-by-turn navigation with Osmin
  • I find this application incredible. In my mind navigation is a difficult to create app but Osmin works well and calculates routes very quickly (completely offline!). It’s not yet as feature-full as say OSMand on Android but it’s very usable
• browse the fediverse (Mastodon) with Tokodon
• check the weather with KWeather

This actually covers a huge part of what I would do on Android as well, now I just do these on postmarketOS instead using almost exclusively KDE applications! I’m still missing a few (for me) important things, most notably a Keepass-compatible client to get the passwords needed for aforementioned applications. I worked around that however by using KDEConnect to share my clipboard from my desktop where I just use KeepassXC. And of course the few Android applications that just don’t have FOSS-replacements like WhatsApp or my bank app, but I’m hoping either Waydroid or even the in my opinion more promising android-translation-layer (basically Wine for Android apps) can be used for that in the future.

Now although this is a very usable setup for me, when actually using this you’ll quickly notice a lot of small but annoying issues. These are all small in size and would easily be fixed if there were developers to experience them but accumulating together they make the whole experience a bit frustrating still. I’ve been reporting everything I could find so far (for example see all the issues I’ve made on just the Plasma Mobile shell). A few examples:

• several applications have multiple actions on the same button press, like NeoChat both opening a room and opening a context menu for it when pressing on a room in the room list, BUG: 486545
• Angelfish automatically switches to a newly opened tab which is unlike any other mobile browser, unexpectedly throwing the user off whatever they’re reading, and shows an unnecessary message telling the user the new tab has been opened which is blocking the button to go back to the previous tab, BUG: 486463
• QMLKonsole (the mobile alternative to Konsole) for some reason has it’s own button to open and close the keyboard but pressing it has various buggy behaviours, BUG: 355
• various applications have context hints that are meant to be shown on desktop when hovering an element but show up when pressing buttons or input fields on mobile, BUG: 360
• various desktop widgets are completely broken, BUG: 354
• sometimes (not often) the shell just crashes, I haven’t been able to find a good reproducer yet

Development

To a lot of KDE developers developing for Plasma Mobile is an unknown (and possibly scary) territory and they might not know how to do it easily. Will you compile everything on your device or cross-compile from your desktop instead, use kde-builder or do it manually? Of course this all comes down to personal preferences in the end but let me tell you how I do it.

Like I mentioned earlier I’m maintaining a nightly repository shipping the entirety of KDE from git master. I highly recommend using this repository so you can quickly test and use new features and bug fixes. Instructions to set this up are on the postmarketOS wiki.

Although compilation on device (e.g. using kde-builder) is most definitely possible, this is just regular good ol’ Linux after all, it’s a slow process due to the limited performance of a phone and might warm it up more than is safe for the device. Instead I would recommend using the lovely pmbootstrap tool we use for postmarketOS development and build on your way more performant PC instead. This tool builds software using Alpine’s simple APKBUILD format. You don’t have to worry too much about learning this format, these APKBUILDs already exist for basically every KDE package out there and you can just reuse these. After setting up pmbootstrap (pmbootstrap init) you can get such an APKBUILD for a KDE package either by manually downloading it from the upstream repository and placing it in the location pmbootstrap expects or run pmbootstrap aportgen --fork-alpine <package name>. This makes pmbootstrap get the APKBUILD from Alpine Linux and put it in your local checkout of postmarketOS packages.

The APKBUILD just downloaded can be used as is and you can now build the package with pmbootstrap build --arch <CPU architecture of the target device> but you probably want to use your local checkout of the code with your changes instead. For this pmbootstrap supports the --src argument which makes it build the same APKBUILD but with the source replaced for your local checkout. If your changes require any dependencies changed from what is currently provided by the package you can edit either the $makedepends or $depends (build dependencies and runtime dependencies respectively) variables in the APKBUILD ($depends might not exist, just create it if it doesn’t).

When you’ve successfully built the package you can send it to your device using pmbootstrap sideload <package name>. This will send it to a device running postmarketOS and let the packagemanager APK install it. Restart the application in question and your changes will be ready to test! pmbootstrap supports way more fancy features and I recommend you read it’s documentation to see what you can do.

Conclusion

In my opinion Plasma Mobile on postmarketOS is very usable right now but at the moment suffers from a lot of papercuts. I hope that since I now daily drive the system I can find all these papercuts, report them and possibly even fix one or two of them. But even more so I hope I can convince KDE developers to pick up a phone themselves and start using the system they’re in fact already developing for (95% of the Plasma Mobile stack is the same as Plasma Desktop and all the applications used were made to be used on desktop as well!). The system has a lot of potential and is already great to use, it just needs developers! Get a cheap second hand phone, flash postmarketOS on it and start using it!

I’m dreaming of a day where I’m not the only one at Akademy that not only has Plasma on their laptop but also their phone!

Our friends at postmarketOS hosted Plasma Mobile's lead developer Devin Lin on their podcast. You can find it on the postmarketos website

Akademy 2024 (the annual world summit for KDE) is happening in Würzburg, Saturday 7th – Thursday 12th September. (I hope you knew that)

First of all, if you're reading this and thinking, "Should i go to Akademy?" 

The answer is [most probably] YES! Akademy has something for everyone, be it coders, translators, promoters, designers, enthusiasts, etc.

Now, with this out of the way, one of the many things that makes Akademy is the talks on the weekend, and you know who has something to say? *YOU*

Yes, *YOU*. I'm sure you've been working on something interesting, or have a great idea to share.

*YOU* may think that your idea is not that great or the things you work on are not interesting, but that's seldomly the case when someone explains me their "boring" thing they've been working on, i always think "Wow that's great".

Ok, so now that I've convinced you to send a talk proposal, when better than *TODAY* to send it?

Yes I know the Call for Participation is open until the 24 of May, but by sending it today you make sure you don't forget sending it later and also [more important for me] you help those of us in the Program Committee not to worry when the final date starts approaching and we don't have lots of talks yet because you all prefer sending talks on the very last minute.

So stop reading and send your talk today ;-)

Let’s go for my web review for the week 2024-18.

Radio Free Fedi - Sounds from the Fediverse to the Universe

Tags: tech, fediverse, streaming, culture

I’ve been listening to these radio channels the past few weeks. It’s quirky, it’s weird, it’s wild. I definitely recommend them to get out of your usual music bubble.

https://radiofreefedi.net/

We can have a different web

Tags: tech, internet, web, culture, history

Very nice account of how the Internet is nowadays and how it got there. I like the gardening metaphor which works nicely here. And yes, we can go back to a better Web again. It’s a collective decision though, that’s what makes it hard.

https://www.citationneeded.news/we-can-have-a-different-web/

Save the Web by Being Nice

Tags: tech, blog, web, social-media

Definitely this. Get the content you like known, send appreciation messages to the authors. This should keep the moribund web alive.

https://sheep.horse/2024/4/save_the_web_by_being_nice.html

Google Made Me Ruin A Perfectly Good Website: A Case Study On The AI-Generated Internet

Tags: tech, web, advertisement, google, criticism

Ever wondered why the quality of websites seems to go down? Well, here is a case study of what you end up needing to do if you try to fund a website through ads (like most websites).

https://theluddite.org/#!post/google-ads

Latest Google layoffs hit the Flutter and Python groups | Ars Technica

Tags: tech, google, flutter

Looks like Flutter’s days are counted. It seems it has peeked and announcements like this are likely to move people away from it. Time will tell of course.

https://arstechnica.com/gadgets/2024/04/latest-google-layoffs-hit-the-flutter-and-python-groups/

The walls of Apple’s garden are tumbling down - The Verge

Tags: tech, apple, vendor-lockin

Indeed there are more and more signs of the Apple vendor lock-in to be in trouble. And that’s a good thing.

https://www.theverge.com/24141929/apple-iphone-imessage-antitrust-dma-lock-in

Having a machine room can mean having things in your machine room

Tags: tech, hardware, funny

Sure you can expect mice, but raccoons? This is a funny finding… well scary if you’re responsible of this machine room.

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/MachineRoomRaccoon

pyinfra automates infrastructure super fast at massive scale

Tags: tech, tools, infrastructure, deployment, python

Looks like an interesting tool for infrastructure automation. It’s all Python based which is an interesting departure from yaml files in that space. Could be a nice alternative to Ansible. I might take it out for a spin.

https://pyinfra.com/

run0

Tags: tech, security, tools, command-line, systemd

An alternative to the venerable sudo coming with systemd. Looks like it has interesting properties.

https://www.freedesktop.org/software/systemd/man/devel/run0.html

Practical parsing with PEG and cpp-peglib - Bert Hubert’s writings

Tags: tech, parsing, c++

Time to leave Lex and Yacc behind? This is definitely a nice approach to make parsers nowadays.

https://berthub.eu/articles/posts/practical-peg-parsing/

Bytecode VMs in surprising places

Tags: tech, bytecode

Bytecodes everywhere! Really it’s a very widespread trick, I didn’t expect some of those.

https://dubroy.com/blog/bytecode-vms-in-surprising-places/

Reflectively constructing enums at runtime - Highly Suspect Agency

Tags: tech, java

Probably shouldn’t do this in most case… but if it’s really needed and you can bare the pain, Java has solutions for you. This is an interesting dive in lower parts of the APIs.

https://highlysuspect.agency/posts/enum_reflection/

Brane Dump: The Mediocre Programmer’s Guide to Rust

Tags: tech, programming, rust, funny

Funny read, it has lots of good advice for starting up with Rust.

https://www.hezmatt.org/~mpalmer/blog/2024/05/01/the-mediocre-programmers-guide-to-rust.html

A Free-Space Diffraction BSDF

Tags: tech, 3d, physics, mathematics

Very cool BSDF. Should lead to better diffraction rendering in real-time 3D.

https://ssteinberg.xyz/2024/04/05/free_space_diffractions_bsdf/

Keep Out! — Little Workshop

Tags: tech, web, 3d

Good demonstration of what you can do with WebGL nowadays.

https://www.littleworkshop.fr/projects/keepout/

CC0 Textures & Models | Share Textures

Tags: tech, 3d, foss

Another great resource for nice models and textures for your 3D needs.

https://www.sharetextures.com/

Shader post-processing in a hurry

Tags: tech, shader, graphics

A nice list of little tricks to improve the image quality of your renders.

https://30fps.net/pages/post-processing/

Software Friction

Tags: tech, project-management

Interesting musing about the concept of friction in strategy. There are indeed a few lessons to learn from it in the context of software projects.

https://www.hillelwayne.com/post/software-friction/

Bye for now!

Or FOFAFOSS. Rolls right off your tongue.

Like in many families, there's always a bit of.. turmoil and drama in FOSS. Something breaks (either on purpose or by accident), people get frustrated.. The usual. It is kind of to be expected when it comes to very social projects, like let's say, Linux desktop environments.

People have their own visions and ways to see things. They often clash. That's normal. It's quite human. I do like to think that Linux desktop environments especially are like siblings that have rivalries.

But we got to remember that it's not "us vs them" here. We don't have the resources to fight each other. We need to work together even with our incompatible visions sometimes. Otherwise things will keep fracturing and get even worse.. And nobody gains from that. Well, except the proprietary platforms. :P

In the end we all want to make good software for everyone to use and enjoy. Let's help each other to do that as well as we can.

Nothing wrong with "Oh you made that? Well watch this!" type of friendly rivalry however, it keeps us doing what we do best. :)

I just wanted to write this down as somekind of reminder that we got to remember to work together if we want to succeed. Even when frustrated.

And no I am not any high and mighty person to really say this, I have had my own share of frustrations and quips. This post serves also as a reminder for myself.

So let's try to work together as well as we can.

How it shall look…

#

Linux & BSDs

#

Windows

#

macOS

#

State on Fedora 40 Workstation & XFCE Spin…

#

Screenshots taken from the GNOME bugtracker, copies to not stall their GitLab instance.

I think that is rather unpleasant and for e.g. the left icon-only border just an unusable insult.

Why? The Adwaita Icon Theme no longer follows the FDO icon naming spec

#

There was no information that they want to break away from the icon naming ’the world’ does assume (given there is a spec). And now we have that state for our users there, at least on these spins.

That is not that nice, we did spend a lot of work to get our applications working cross-desktop and even cross-platform and now that…

I feel rather infuriated, finding this before going to sleep, even more after reading the feedback in the GNOME bugtracker and that this is just closed as ‘so be it’.

They added now at least a hint to the README:

Private UI icon set for GNOME core apps.

Ok, I assume that is then all fine.

No, it is not.

Then please don’t install it as FDO icon theme and break all FOSS apps that rely on the naming spec…

If you care for non ‘GNOME core apps’ to work per default properly on distributions like that, please either get them to fix it (hints are given in the linked issue) or get the distributions to install a compliant theme.

We can plan to work around this mess in the future on our side, but that will not un-break the application versions that are now already shipped to our users and non-KDE frameworks based stuff that will just run into the same issues.

Feedback

#

You can provide feedback on the matching KDE Social, reddit or Hacker News post.

Last week, like many other people, I was in Berlin for the Mega^WGoals sprint. Natually the three goals (Sustainability, Accessibility, and Automatability; the three abilities) attracted a diverse crowd of people that brought also other topics, so it turned into a proper megasprint.

Being interested in all three goals made it a bit callenging to follow all relevant discussions unfortunately, but on the flip side it never got boring.

Most of my goal-related work was towards the automation goal. One thing I was working on is a CI job that checks for spelling mistakes in the code, so that those can be caught when doing a MR. A while ago I create a website that tracks which KDE projects are ported to Qt6. What started out as a joke for a talk turned out to be a useful tool for planning porting work. During the print I fixed the site to actually work correctly again and, most importantly, changed the text from “No” to “Yes” since most projects actually use Qt6 now. For a while the site also has auto-generated reports for other things, like showing which projects don’t yet have clang-format applied to them or which projects don’t enforce passing test in the CI. I used the latter list to enable this for the remaining projects that don’t have failing tests right now and prepared a change to the CI system that enforces passing tests by default. In the same spirit others and I also fixed some currently failing tests. We also discussed the idea of extending the site with more checks and turning it into a proper KDE site that isn’t hosted on my personal infrastructure.

Harald, Carl, and I worked on a dashboard to show the CI status for our project. This is something we haven’t really had since switching to Gitlab CI but is very useful e.g. as part of the release checklist. We do have a working prototype, but some things remain to be ironed out. As part of this we also fixed some of the currently failing builds.

My main contribution to the systainability goal was debugging why Nate’s NeoChat is using too much CPU. With a team effort we eventually pinpointed this to an invisible animation constantly repainting the window, which was then promptly fixed.

In terms of accessibility I was mainly involved in discussions about challenges and new developments with accessibility on Wayland. Expect to hear more on this soon.

In “off-topic” topics there were plently of discussions about visions, ideas, and challenges for our application development story. This included discussions on visions for design/UX, theming, API design, and software distribution. Being KDE’s Software Platform Engineer it is part of my responsibilities to facilitate these kinds of discussions. Later this year I want to host a sprint dedicated to application design to discuss and establish our vision there. If you are interested do reach out to me.

All in all it was a fun few days with great people. Thanks to MBition and Aleix for hosting us, and thanks to those donating to KDE to make these sprints possible.

I'm happy to have been able to attend my first in-person KDE event, the Automation & Systematization Sprint in Berlin. Previously, my contributions to KDE have consisted of submitting and triaging bug reports. During this weekend, I was able to meet some of the KDE team in person, and become more involved. I've started working with the Bugzilla Bot code, and plan to start digging into the automated test code.

The Bugzilla product list had fallen out of date, so first I updated that (yay, my first accepted MR!). I also started working on using the GitLab API to automate these updates. In the near future, I'll be tackling some requested improvements to the Bugzilla Bot. This will lessen the amount of boring manual bug chores and free people up to do more valuable work.

Thanks to the KDE team for being so friendly and willing to help me learn the development environment. I'm happy to have found more ways to contribute that I enjoy, and will be valuable to the project.