btrbk ... && curl https://uptime.my.domain/api/push/... is exactly what I do in a systemd service with nightly timer. Uptime Kuma sends a matrix message (via a bot account on matrix.org) if it doesn’t get a success notification in 25h. I have two servers in different locations that do mutual backups and mutual uptime kuma monitoring. Should both servers go down at the same time, there’s also some basic and free healthcheck from my dynamic-ipv6 provider https://ipv64.net/, so I also get an email if any of the two uptime kumas cannot be reached anymore.

You need to ask yourself what properties you want in your storage, then you can judge which solution fits. For me it is:

• effortless rollback (i.e. in case something with a db updates, does a db migration and fails)
• effortless backups, that preserve database integrity without slow/cumbersome/downtime-inducing crutches like sql dump
• a scheme that works the same way for every service I host, no tailored solutions for individual services/containers
• low maintenance

The amount of data I’m handling fits on larger harddrives (so I don’t need pools), but I don’t want to waste storage space. And my homeserver is not my learn and break stuff environment anymore, but rather just needs to work.

I went with btrfs raid 1, every service is in its own subvolume. The containers are precisely referenced by their digest-hashes, which gets snapshotted together with all persistent data. So every snapshot holds exactly the amount of data that is required to do a seamless rollback. Snapper maintains a timeline of snapshots for every service. Updating is semi-automated where it does snapshot -> update digest hash from container tags -> pull new images -> restart service. Nightly offsite backups happen with btrbk, which mirrors snapshots in an incremental fashion on another offsite server with btrfs.

This is about contributing code that was co-created with an llm like copilot. Not about adding “AI” features to fedora.

Rootless podman cannot bind ports <1024, only root can by default (on pretty much any distro I guess). Have you done something like sysctl net.ipv4.ip_unprivileged_port_start=80 to allow non-root processes to bind to port numbers >=80?

That server is also a homeserver I manage for family (in another city). The two homeservers then mutually back up each other.

They show images from the same day in past years. So if your library has no images >= 1 year old I’m not sure if anything shows up.

The same way as all other services: all relevant data (compose.yml and all volume mounts) are in a btrfs subvolume. Every night a snapshot gets made and mirrored to a remote server by btrbk.

Hier sind nicht Fehler in der Software gemeint, sondern dass die Software Fehler im Fahrrad erkennt, und die kann man auslesen um den Fehler zu finden. Zum Beispiel sowas wie einen Wackelkontakt weil ein Kabel oder Stecker beschädigt ist. Und auch die Aktualisierungen sind nicht unbedingt um Fehler zu beseitigen, da geht es auch um neue Features wie Unterstüzungsmodi, Kompatibilität zu neuer Zusatzelektronik wie zum Beispiel GPS-Tracker oder die Unterstützung elektronischer Schaltungen.

Das was wirklich grußelig an der Software ist ist, dass vor allem Bosch ein extrem abgeschottetetes, proprietäres und kundenunfreundliches Ökosystem erschaffen hat. Im Grunde gehört einem ein gekauftes Fahrrad garnicht, denn über alles was mit der Elektronik zu tun hat kann man nicht verfügen. Ein paar wenige unkritische Einstellungen kann der Fahrradladen vornehmen, wenn man einen findet der gewillt ist das zu tun (was nicht alle sind). Aber das meiste ist den OEM’s vorbehalten. Früher hatte Bosch ein System mit Lizenzschlüsseln, was man teilweise umgehen konnte um als Eigentümer seines Fahrrads zumindest bis zum Fahrradladen-Level damit zu machen was man will. Mittlerweile gibt es nur noch ein Internet-gebundenes System, und damit hat man keine Chance mehr. Dazu kommt, dass Bosch Reparaturen von Komponenten so weit wie möglich unterbindet. Es gibt lediglich ein einziges Set zur Reparatur der Dichtung/Lager auf einer Seite der Kurbel (selbstverständlich nur für Fahrradläden), sonst nichts. Man will lieber neue Motoren und sonstige Komponenten verkaufen.

That is one issue. The next is that software support on phones is generally poor because there’s lots of proprietary drivers and they don’t have a common base system like computers do (bios). So building custom roms is difficult, doesn’t scale well over the number of different devices and they often don’t work great in the areas of camera, accelerated graphics and wireless networking. Also installing custom roms is also too difficult for the majority of people, and requires bootloader unlock which is either not possible at all or at a minimum cancels the warranty.

Eh naja, “versucht” ist da harmlos ausgedrückt. Einfach Maintainer aussperren ist weder nett noch förderlich für so ein Projekt. Man hätte auch einen soft fork machen können der upstream trackt und Änderungen nach einer Prüfung übernimmt. Wenn man sich mit upstream gut stellt könnte man auch eine doppel-Lizenz Strategie umsetzen, indem Lizenzen für den CRA-kompatiblen soft-fork an andere kommerzielle Konsumer des Projekts verkauft werden, welche sich dafür das Review plus Risiko sparen können. Daraus wiederum könnte man die Reviews und generelle Projektunterstützung finanzieren.

Nicht-kommerzielle open-source Projekte sind von CRA ausgenommen. An der Stelle wo zuerst kommerziell verkauft wird fängt CRA an zu greifen. Wenn eine Firma in ein kommerzielles Produkt nicht-kommerzielles open-source einbaut muss sie selbst sicher stellen, dass das Produkt und damit auch seine Komponenten die CRA Anforderungen erfüllen.

Nicht-kommerzielles open-source ist keine Lieferkette. Es wird immer so geredet als gäbe es da einen “Lieferant”, das ist nicht der Fall. Das ist einfach nur ein Projekt das herumschwirrt, und wenn ich mich daran bediene um das in ein kommerzielles Produkt verwandeln will um damit Geld zu verdienen, dann muss ich auch selbst dafür sorgen dass es den Regeln des Marktes entspricht.

I’m afraid this is impossible. This is most likely part of Gnome Shell itself.

Go on and keep using your distro another few years, and you’ll recognize the patterns of what keeps breaking. And then try some others for some years, and you’ll find that you can at most pick between smaller issues on a regular base on rolling ones, or larger batches of issues on release based ones. And some point you’ll find that every user creating a custom mix of packages that are all interdependent on another is quite the mess, and the number of package combinations times the number of configuration option combinations is so large that you can guarantee some of them will have issues. On top you have package managers rumaging around in the system while it is in use, and with a mix of old code that is still loaded in ram and new code on disk behaviour for these transients is basically undefinded. Ultimately you’ll grow tired of this scheme at some point, and then running a byte-to-byte copy of something that has been tested and doing atomic updates is quite attractive. And putting a stronger focus on containerized applications not only enables immutable distros for broad adoption in the first place, but also cuts down the combinatorial complexity of the OS. And lastly, to be honest, after so many years of the same kinds of issues over and over again, the advent of immutable+atomic distros + containerized desktop apps brought a couple of new challenges that are more interesting for the time being…

Take a look from this perspective: with distro packages, a separate person (the package maintainer) has to build a piece of software against the versions of dependencies the distro offers, which are not the ones the developer of the software uses and tests against. Then you have users that encounter bugs with this build of the software, and the developer of the software receiving bug reports against all kinds of dependency matrices, whose combinatorial complexity is overwhelming. With the different paces of distros in terms of package versions this is inevitable. On top you have overworked package maintainers which leads to sparingly updated distro packages or even orphaned ones.

For no party in the linux ecosystem this is a great experience.

Either it is this, or giving packages the opportunity to not share dependency versions, which can cost a bit of disk space. With the low price of storage, I think it becomes quite clear why flatpaks are so popular. Also in the end, users do not shape the linux landscape like they would with commercial products, as distros do not rely on sales to users. Developers and maintainers shape the landscape, and so what floats their boat is largely what happens.

For linux as a whole, flatpak is one of the greatest things that ever happened. For the first time, one can treat it as an actual platform, and that makes it a strong ecosystem.

Von den 202 a-d trifft in diesem konkreten Fall für meine Begriffe wenn dann nur a zu, davon Abs. 1:

Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.

Von “gegen unberechtigten Zugang besonders gesichtert” kann man aber hier ja wohl nicht sprechen…

(Ich bin kein Jurist. Ich will auch keine Lanze für die Hackerparagraphen brechen, die gehören sehr dringend reformiert)

Nothing is bug free, but that doesn’t mean everything is sort of the same just different flavor.

The last couple days I dealt with Windows, which is out of the ordinary for me. I had to build a little thing and chose PowerShell and that is quirky but ok at a glance. Now we are in 2025 and PowerShell is a modern thing, and kid you not you install a thing using Module-Install and then you uninstall it using Module-Uninstall and what happens? The thing is only gone partially and some broken remains stay. And then another curiosity comes up where after long rummaging it turns out that one user (Admin) simply cannot see another user’s mounted share - has microsoft ever heard of the concept of “permission denied”?

That’s not a differently flavored bag of bugs, that is like decades of computing and software engineering hadn’t taken place

Only if the application source code fits the API of the library versions on your system. Otherwise you also need to port the application to your available library versions. Also using different dependency versions might surface bugs that you have to sort out yourself.

I only want to point this out because it often seems that the people that complain about flatpak do not grasp what maintaining a package entails, and your suggestion effectively puts you in the position of being a package maintaier for your specific distro. (But the upshot is that with open source software you are always free to do this, and also share it with other people through (community-) repositories)

Ich habe mir letztens gedacht, das ganze Ding mit wählen reicht irgendwie nicht. Der Gedanke in eine Partei einzutreten schien mir aber nicht vielversprechend, und so machte sich ein Gefühl von Hilflosigkeit breit. Dann kam aber der 38C3, und einige Vorträge haben sehr deutlich gemacht, dass kleine Gruppen findiger Menschen viel disruptiver sein können als eine Partei. Insofern ist meine Einstellung gerade eher, dass ich (neben Wählen zu gehen) mich in Richtung von Organisationen und Vereinen bewege, die unabhängig von Wahlen und den ganzen Parteien-Terz meine Interessen vertreten. Bis jetzt sind das der CCC, Correctiv und das Zentrum für politische Schönheit

Wesentlich in dieser Wahl ist den Anteil der Bundestagssitze für die Afd klein zu halten, und da helfen alle Parteien die unter die 5% Hürde fallen nicht. Insofern würde eine Stimme für die Piraten ohnehin nicht zur Verteidigung der Demokratie beitragen.

This is not practical for a home setup. Not because it would be expensive for more hardware or whatever, but because as soon as you have multiple systems doing the same thing, their state diverges and for pretty much anything that is popular for selfhosting you cannot merge them again or mirgrate users between them without loosing anything. Distributed databases alone are a huge pita, and maintaining such redundant setups would be a million times more effort than just making sure that you can easily and quickly atomically roll back failed updates