AkaSci 🛰️Happy Towel Day.
https://en.wikipedia.org/wiki/Towel_Day
https://www.towelday.org/
I will be the best hacker everrrrrrrr! Also send me pictures of cats. ^u^
Views are my own
Return0
- 9 Followers
- 234 Following
- 43 Posts
Cat 🐈🥗 (D.Burch) 
My conspiracy is that any centralized platform with a "repost" function is not to be trusted.
I feel that the repost function only serves as an easy way for the platform to censor any controversial information with "one click of a button".
I also noticed that with the "save" function, I would not be able to access the things I saved after a period of time if they were of controversial nature, i.e. criticizing big tech or the platform itself.
2somethingJorge Castro, one of the developers working on the next iteration of flatpak, says that "of course" flatpak 2.0 will depend on SystemD. Moreover, he thinks this dependence is so obvious that it was wrong of me to even ask.
https://hachyderm.io/@jorge/116619028047490652
Archive link:
https://megalodon.jp/2026-0523-0312-41/https://hachyderm.io:443/@jorge/116619028047490652
The current version of flatpak does not depend on any init system. This lack of SystemD dependence is one of the advantages flatpak currently has over its rival snap. The "flatpak setup" page on flatpak.org endorses the use of flatpak on distros without SystemD, such as Alpine, Void, Guix, Slack, Pisi, Salix, and Gentoo. Other distros without systemd encourage the use of flatpaks, including Chimera
The decision to add a dependency which cuts off many distros currently using flatpak, including those which the flatpak developers themselves advertise as supporting flatpak, is a surprise. It also seems contrary to the stated mission of flatpak, which is to be a single package format that works on all Linux distros.
Moreover, this decision comes at what seems like the worst possible time. SystemD recently started AI-ifing, and adding plumbing for surveillance age censorship (far beyond what any laws require of them), leading to an increased number of users who want to stop using it, including users like me who previously didn't care about init systems.
EDIT: The develper in question has doubled-down, including claiming that "modern Linux" has "only SystemD."
https://megalodon.jp/2026-0524-0336-55/https://hachyderm.io:443/@jorge/116625264102622684
https://megalodon.jp/2026-0524-0337-21/https://hachyderm.io:443/@jorge/116625260525826470
https://megalodon.jp/2026-0524-0338-32/https://hachyderm.io:443/@jorge/116625256540295585
https://megalodon.jp/2026-0524-0338-49/https://hachyderm.io:443/@jorge/116625308101601470
https://megalodon.jp/2026-0524-0339-06/https://hachyderm.io:443/@jorge/116625329112111399
I should clarify that Jorge is just one person involved in flatpak development. It is currently unclear to what extent his statements reflect the position of the whole flatpak development team.
EDIT 2: And now he's moved to gaslighting.
https://megalodon.jp/2026-0524-1008-26/https://hachyderm.io:443/@jorge/116626198724098296
https://megalodon.jp/2026-0524-1008-40/https://hachyderm.io:443/@jorge/116626278544247845
https://megalodon.jp/2026-0524-1008-55/https://hachyderm.io:443/@jorge/116626299556869473
EDIT 3: I have been told conflicting things about the extent to which Jorge is actually involved in flatpak development.
However, someone else claiming to be a flatpak developer has also weighed in. Adrian Vovk takes a much less hostile tone than Jorge, but he also says he expects Flatpak 2 to depend on SystemD. He notes that it might be possible for distros to patch around the requirement, but that the upstream flatpak project will probably not accept contributions to make it work on other init systems.
https://megalodon.jp/2026-0525-0628-46/https://fosstodon.org:443/@AdrianVovk/116626119745780463
https://megalodon.jp/2026-0525-0628-48/https://fosstodon.org:443/@AdrianVovk/116626156956101933
He also suggests that a SystemD dependency might be added to flatpak 1.x as well.
https://megalodon.jp/2026-0525-0634-23/https://fosstodon.org:443/@AdrianVovk/116629630385486477
However, he stresses that no code for flatpak 2 has actually been written yet, and plans may change.
EDIT 4: Jorge is apparently also a vibe-coder.
https://github.com/castrojo/jorgepilot
-----------------------------------------------------------------------
So now I have to figure out what distro I am going to run. I currently use Debian Trixie, and rely on flatpak to get updated applications. Trixie has a pre-AI version of SystemD. I had considered trying to replace SystemD on Debian with OpenRC, but if I would lose access to flatpak apps then staying on Debian at all seems a lot less appealing.
I had also been seriously considering switching to @alpinelinux , because their native package manager is really fast, stable, and awesome. But their package repository is a lot smaller than other distros, so I'm not sure I'd want to use it without flatpak.
I am now more seriously considering switching to @VoidLinux . I wanted a stable base system with frequently updated applications, but if that's not an option I'd settle for a rolling distro that tries to be somewhat stable.
https://hachyderm.io/@jorge/116619028047490652
Archive link:
https://megalodon.jp/2026-0523-0312-41/https://hachyderm.io:443/@jorge/116619028047490652
The current version of flatpak does not depend on any init system. This lack of SystemD dependence is one of the advantages flatpak currently has over its rival snap. The "flatpak setup" page on flatpak.org endorses the use of flatpak on distros without SystemD, such as Alpine, Void, Guix, Slack, Pisi, Salix, and Gentoo. Other distros without systemd encourage the use of flatpaks, including Chimera
The decision to add a dependency which cuts off many distros currently using flatpak, including those which the flatpak developers themselves advertise as supporting flatpak, is a surprise. It also seems contrary to the stated mission of flatpak, which is to be a single package format that works on all Linux distros.
Moreover, this decision comes at what seems like the worst possible time. SystemD recently started AI-ifing, and adding plumbing for surveillance age censorship (far beyond what any laws require of them), leading to an increased number of users who want to stop using it, including users like me who previously didn't care about init systems.
EDIT: The develper in question has doubled-down, including claiming that "modern Linux" has "only SystemD."
https://megalodon.jp/2026-0524-0336-55/https://hachyderm.io:443/@jorge/116625264102622684
https://megalodon.jp/2026-0524-0337-21/https://hachyderm.io:443/@jorge/116625260525826470
https://megalodon.jp/2026-0524-0338-32/https://hachyderm.io:443/@jorge/116625256540295585
https://megalodon.jp/2026-0524-0338-49/https://hachyderm.io:443/@jorge/116625308101601470
https://megalodon.jp/2026-0524-0339-06/https://hachyderm.io:443/@jorge/116625329112111399
I should clarify that Jorge is just one person involved in flatpak development. It is currently unclear to what extent his statements reflect the position of the whole flatpak development team.
EDIT 2: And now he's moved to gaslighting.
https://megalodon.jp/2026-0524-1008-26/https://hachyderm.io:443/@jorge/116626198724098296
https://megalodon.jp/2026-0524-1008-40/https://hachyderm.io:443/@jorge/116626278544247845
https://megalodon.jp/2026-0524-1008-55/https://hachyderm.io:443/@jorge/116626299556869473
EDIT 3: I have been told conflicting things about the extent to which Jorge is actually involved in flatpak development.
However, someone else claiming to be a flatpak developer has also weighed in. Adrian Vovk takes a much less hostile tone than Jorge, but he also says he expects Flatpak 2 to depend on SystemD. He notes that it might be possible for distros to patch around the requirement, but that the upstream flatpak project will probably not accept contributions to make it work on other init systems.
https://megalodon.jp/2026-0525-0628-46/https://fosstodon.org:443/@AdrianVovk/116626119745780463
https://megalodon.jp/2026-0525-0628-48/https://fosstodon.org:443/@AdrianVovk/116626156956101933
He also suggests that a SystemD dependency might be added to flatpak 1.x as well.
https://megalodon.jp/2026-0525-0634-23/https://fosstodon.org:443/@AdrianVovk/116629630385486477
However, he stresses that no code for flatpak 2 has actually been written yet, and plans may change.
EDIT 4: Jorge is apparently also a vibe-coder.
https://github.com/castrojo/jorgepilot
-----------------------------------------------------------------------
So now I have to figure out what distro I am going to run. I currently use Debian Trixie, and rely on flatpak to get updated applications. Trixie has a pre-AI version of SystemD. I had considered trying to replace SystemD on Debian with OpenRC, but if I would lose access to flatpak apps then staying on Debian at all seems a lot less appealing.
I had also been seriously considering switching to @alpinelinux , because their native package manager is really fast, stable, and awesome. But their package repository is a lot smaller than other distros, so I'm not sure I'd want to use it without flatpak.
I am now more seriously considering switching to @VoidLinux . I wanted a stable base system with frequently updated applications, but if that's not an option I'd settle for a rolling distro that tries to be somewhat stable.
Jorge Castro (@[email protected])
@[email protected] @[email protected] Are you serious? Of course.
Harry Sintonen#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
stux⚡️
da_667
Jay Thoden van Velzen ☁️🛡️
LOL
The reports may throw cold water on the bets tech’s biggest firms have placed on the technology. While some cling to the promise of an AI “renaissance” or “revolution,” the cost of adoption is proving a stubborn bottleneck. These developments also suggest that the economics of replacing or augmenting human labor with AI may be more complicated than some early forecasts originally implied. That echoes what Bryan Catanzaro, vice president of applied deep learning at Nvidia, recently said in an interview with Axios.
“For my team, the cost of compute is far beyond the costs of the employees,” he said.
https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/
Zack Whittaker"I have been a professional tech journalist for nearly fifteen years, and before today, I cannot think of a single time when a Bing search result was more valuable than the Google equivalent. There really is a first time for everything!"
https://techcrunch.com/2026/05/22/you-can-no-longer-google-the-word-disregard/
