Wikipedia itself is doing fine but they have a bunch of super interesting side projects that they don’t advertise much, and aren’t doing as well. Wikinews, their news site is shutting down: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Single/2026-03-31#News_and_notes (this is really close to april fools hopefully I didn’t eat the onion. Or hopefully I did?).

My favorite is wikibooks: http://wikibooks.org/ , which are open source texbooks that can be edited wikipedia style. Their programming one’s are really high quality. The idea behind those is that you can export a known good frozen version of them, as a texbook for a class. Related is also wikiversity, which is course curriculum. It’s similar, but different.

But they also have a travel voyage, wikivoyage, and more: https://en.wikipedia.org/wiki/Wikipedia:Wikimedia_sister_projects

This is a message to remind myself to share my config later.

I will state that I a, using cloudnativepg for postgres.

The way forgejo actions works, is that it is not a universal thing for every repo. Each repo, can have it’s own forgejo actions instance connected to it, running stuff.

The big benefit of that, is that you can make users bring their own actions servers, and not bother to deploy your own.

It has newer packages than Debian.

This is not quite true. They have overlapping release cycles. A new Debian release will ship frozen versions of the latest packages, causing it to have newer packages than most ubuntu releases. Then the new ubuntu release comes out, with and it has newer packages. Ubuntu doesn’t universally newer packages than debian. The difference is that Debian ONLY does security updates, and doesn’t do feature updates or even bugfixes over it’s lifespan. Ubuntu, on the other hand, does ship feature updates and bug fixes, incrementing the package version as they go over the lifespan of an Ubuntu release.

Comparing the bash versions of the latest ubuntu stable version versus the current debian stable, and you’ll notice that Debian has a newer bash:

[moonpie@osiris moonpiedumplings.github.io]$ podman run -it --rm debian
root@980ac170ddb4:/# bash --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@980ac170ddb4:/# exit
exit
[moonpie@osiris moonpiedumplings.github.io]$ podman run -it --rm ubuntu
Resolved "ubuntu" as an alias (/etc/containers/registries.conf.d/00-shortnames.conf)
Trying to pull docker.io/library/ubuntu:latest...
Getting image source signatures
Copying blob 817807f3c64e done   | 
Copying config f794f40ddf done   | 
Writing manifest to image destination
root@1486a1c38699:/# bash --version
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

This is Ubuntu 24, the current stable release. 25/questing, the rolling version does have newer/same package versions of debian. But people don’t base distros off of the rolling version of ubuntu, only the stable releases.

Debian Linux, and many other Linux distros, have extensive measures to protect their supply chain. Packages are signed and verified, by multiple developers, before being built reproducibly (I can build and verify and identical binary/package). The build system has layers, such that if only a single layer is compromised, nothing happens and nobody flinches.

Programming langauge specific package repos, have no such protections. A single developer has their key/token/account, and then they can push packages, which are often built on their own devices. There are no reproducible build to ensure the binaries are from the same source code, and no multi-party signing to ensure that multiple devs would need to be compromised in order to compromise the package.

So what happened, probably, is some developer got phished or hacked, and gave up their API key. And the package they made was popular, and frequently ran unsandboxed on devs personal devices, so when other developers downloaded the latest version of that package, they got hacked too. The attackers then used their devices to push more malicious packages to the repo, and the cycle repeats.

And that’s why supply chain attacks are now a daily occurrence.

No, they’re dual licensed. Canonical has users contributing signing a Contributor License agreement, in which they agree to allow Canonical to distribute alternatively licesed, or proprietary versions.

This change was somewhat controversial, and partially why Incus was forked from LXD.

Companies at onferences give 4/8gb out sometimes. They buy branded ones in bulk.

• oauth, and control sign ups via there. Don’t let people sign up via forgejo itself.
• anubis, yeah. Or similar.
• forgejo actions is an optional component… and forgejo users can bring their own actions server. Of course, it’s a risk to them since the server owner could execute code in actions. But yeah.

Void auth, or kanidm look like easier alternatives.

I have installed an OS onto just the btrfs root subvolume, leaving the home directory intact. This is how I originally swapped from Manjaro to Arch. The arch manual install instructions helped.

But this should be a feature of the graphical installers imo.

Transparent fileystem compression and deduplication (btrfs feature not in ext4) compresses data while still having it be accessible normally. This leads to big space savings.

You can use the tool compsize to check it out.

Postgres jsonb?

That’s what I thought too: https://programming.dev/comment/22854391

But it seems to be possible to still do them wrong.

I like ORM’s because they prevent sql injection. Mostly. Sql injection is a really bad vuln that’s nowhere near as ubiqitous as it used to be for every php app, and that’s partly due to ORM’s.

I don’t hate on any language’s syntax tbh, but the tooling for nix is absolutely miserable compared to similar.

People hate on yaml a lot, but I can start typing and then press tab and it completes a whole template for whatever k8s objecy I am trying to make. Having to copy from my other project’s shell.nix/whatever into the new one feels miserable in comparison.

Debian repos are basically guaranteed safe: https://programming.dev/comment/22863237

Flathub is much, much safer than say, the google play store, but it ultimately does follow a model of app developers submitting packages which get reviewed and approved. In theory, someone could sneak malware past that, although there haven’t been any incidents (perhaps flathub’s review is very effective?). But the snap store, which follows a similar model has had malware. But canonical hasn’t been the best steward of that one.

In addition to this, not all stuff on flathub is open source, which is definitely concerning.

Thankfully, flatpak has a built in sandboxing system, which lets you limit what the appps have access to. KDE has a UI for it, and there is also the GUI app flatseal.

malicious code does occasionally sneak into Debian distributed apps

Do you have an example of this? The xz utils backdoor did not make it into debian stable, only unstable.

Debian stable essentially forks every package, maintaining a custom codebase. They then cherry pick security updates only (ignoring feature updates or minor bugfixes), and applying those. This makes it extraordinarily resilient to any form of supply chain attack.

Flatpak’s show up in discover, and aren’t by the distro. Usually it’s flathub.

Journalists communicating with sources in censored regions

Whistleblowers sharing information securely

You and your peer agree on an encryption key (any string).

This is unacceptably unsecure for the usecases you mention. There is a reason why the most secure messaging apps don’t use symetric encryption, don’t use passphrases, and they also possess forward secrecy.

It’s pointless to push this as a censhorship circumvention method when many other methods exist that already do so 10x better, in a secure way, over decentralized, hidden and unblockable infrastructure. (Tor’s meek-azure bridges use microsoft’s infrastructure, which nobody is able to block because everybody depends on it, even China).

I appreciate the project, and I am always happy to see people learning, progressing, and publishing their results, but you need to be honest about the weaknesses of your software compared to established solutions. It’s not impossible for you to one day produce a secure messaging app, but today is not the day. Right now, using this is just a fast way to get killed.

It looks like they are using prepared statements, which prevent sql injection:

https://www.php.net/manual/en/pdo.prepared-statements.php