

Ah right, I forgot about the different editions! Been on GNOME for so long.


Ah right, I forgot about the different editions! Been on GNOME for so long.


X11 was completely removed in Fedora 43 I believe
https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOME#Wayland-only_GNOME


I don’t like facebook but there’s this:
A couple of people discussed creating fan sites here:
https://www.mobygames.com/game/991/stuart-smiths-adventure-construction-set/
…but they are all dead links now.


It could if you/future owner ever need to re-enable it:
The trouble is not your present boot; it’s your future boot. If your older PC’s firmware never gets the 2023 keys, and the rest of the world starts assuming those keys exist, you can end up stuck in a weird limbo. While your existing Linux install will still boot, a new or updated distro won’t.
Testing now will help diagnose future problems.
https://www.zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/


That was wonderful thanks for posting!


I’m not familiar with Pikapods but Monica v4 has trouble with notifications. First you need to ensure it’s been configured right to even send a test email, this can be triggered with a command if you have access:
php artisan monica:test-email
Various Monica environment variables must be set to configure this, it should be in the docs somewhere if not I can fish my config out for you.
Even once that’s working you’ll need Monica to run its regular jobs for sending notifications, there’s config for that too. Finally the code has bugs and will often miss reminders in my experience. There are some open bugs still on this and I guess the devs have moved onto their rewritten version (chandler):
We’re also making it possible to add alt text for profile pictures and headers now, making your profile more accessible for blind and visually impaired users.
That’s good!


Ha! I sound keen like an AI cause I was thinking about exactly this problem when I saw your post and have been continuing to research.
The GNOME keyring does not defend against rogue processes for now. However KDE wallet can prompt a user before access (I’ve not tried it):
https://docs.kde.org/stable_kf6/en/kwalletmanager/kwalletmanager/wallet-access-control.html
…this seems a fair bit safer, presuming it works.


Some hints here:
https://wiki.archlinux.org/title/GNOME/Keyring#PAM_step
- Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters, and you should make sure that your system’s real-time clock is set to UTC rather than local time (see [2]). See [3] for more details.
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of
/etc/pam.d/loginas mentioned below.


I think you are absolutely right to examine whether your system defaults to too much convenience versus security for your threat model. For GNOME keyring:
Any application can easily read any secret if the keyring is unlocked. And, if a user is logged in, then the login/default collection is unlocked. Available D-Bus protection mechanisms (involving the busconfig and policy XML elements) are not used by default and would be easy to bypass anyway.
The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.
Applications sandboxed via Flatpak only have filtered access to the session bus.
https://wiki.archlinux.org/title/GNOME/Keyring#Security
So while flatpaks that play the game are ok everything else is on trust. For the average user perhaps this is the right balance, though your Signal example suggests it’s too lax for anyone nowadays.
I would like to see system secrets protected however they are accessed, not just for flatpaks.


F-droid themselves gave an update in April:
https://f-droid.org/en/2026/04/03/twif.html
If you’ve been holding off updating Syncthing-Fork we have two pieces of news for you. First, the original dev continues to collaborate still, we know this was a pain point back then. Second, we’ve just added BasicSync, A simple app for running Syncthing, which just controls Syncthing’s running behaviour as hands off as possible, while the original service hums in the background.
So it seems since the handover things have settled but there is also a new fork which takes a more bare-bones approach.
Have you tried stomach massage? It can help. If he’s spending time sitting on the toilet anyway maybe try a massage instead. Might also help diffuse any mental anxiety/pressure about toileting by adding something new. Could take time and effort to have an effect so approach with patience.
Also I assume your paediatrician has mentioned the usual things that can help: hydration, walking, fiber. Small changes can add up.


Grateful the SFC has got users’ backs!
I mention https://lemmy.ca/c/linuxphones in case you’ve not found it already. It’s not like an authoritive, central forum where everyone goes but maybe it’s a start.


The danger being raised with the licensing is that you can’t license something if you’re not considered to be the author. There are growing examples of courts and lawmakers determining AI output to be public domain:
The US Supreme Court recently refused to reconsider Thaler v. Perlmutter, in which the plaintiff sought to overturn a lower court decision that he could not copyright an AI-generated image. This is an area of ongoing concern among the defenders of copyleft because many open source projects incorporate some level of AI assistance. It’s unclear how much AI involvement in coding would dilute the human contribution to the extent that a court would disallow a copyright claim.
https://www.theregister.com/2026/03/06/ai_kills_software_licensing/
This is an evolving, global situation and hard to know what to do right now. I think what you’ve got is fine though - you’ve made it clear your intention is to license with AGPL. It’s just that depending on the jurisdiction it might be public domain instead.
This is another reason to be clear about the use of AI in the README so your users can make an informed decision.
You’ve made a great start. How much further you go depends on your needs and threat model.
Rsync is ok as a start but there are dedicated backup tools that will give you access to your files at any point in time. This is important if you delete a file and later need it back after an rsync has already run and deleted it remotely too.
Rsync will not encrypt your backups. If a burglar takes your Pi will they have easy access to all your files too?
With rsync+ssh you are also vulnerable to either yourself (more likely) or a rogue process on your own machine deleting the files over ssh (e.g. ransomware attack).
The answer to that is append-only backups. A backup tool like restic has a backend you can host that does exactly this:
https://github.com/restic/rest-server
Take a look at restic to see what else you gain from switching to a dedicated tool versus rsync:
https://github.com/restic/restic#design-principles
There are others too such as borg.