skilltheamps

joined 2 years ago
[–] skilltheamps@feddit.org 1 points 5 months ago

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.

[–] skilltheamps@feddit.org 7 points 5 months ago

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.

[–] skilltheamps@feddit.org 9 points 6 months ago (6 children)

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

[–] skilltheamps@feddit.org 2 points 6 months ago (1 children)

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?

[–] skilltheamps@feddit.org 4 points 6 months ago

That's what I thought, but last time I looked I only saw a "release" tag, no "v2" tag. Did I miss something?

[–] skilltheamps@feddit.org 3 points 6 months ago

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

[–] skilltheamps@feddit.org 2 points 6 months ago

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.

[–] skilltheamps@feddit.org 8 points 6 months ago (2 children)

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.

[–] skilltheamps@feddit.org 1 points 6 months ago* (last edited 6 months ago)

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.

[–] skilltheamps@feddit.org 3 points 6 months ago* (last edited 6 months ago)

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.

[–] skilltheamps@feddit.org 2 points 6 months ago

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.

[–] skilltheamps@feddit.org 6 points 6 months ago* (last edited 6 months ago) (2 children)

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.

view more: next ›