• 0 Posts
  • 23 Comments
Joined 10 months ago
cake
Cake day: June 25th, 2024

help-circle
  • 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



  • Der war noch länger hab schon was abgeschnitten 😬 Irgendwann hatte ich keine Lust mehr noch länger rum zu probieren ab wann die Streetview-Perspektive kaputt geht. Geil an dem Link ist auch dass da drin noch ein zweiter Link zu ner API encodiert ist, manchmal denkt man echt Google sei kein Techkonzern sondern ne Startup Frickelbude



  • 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




  • Genau genommen genauso super wie irgend eine andere Software auszuführen die bei dieser url runter geladen wurde. Der einzige kleine Bequemlichkeits-Unterschied besteht darin, dass wenn man ein Paket für den Paketmanager runterlädt man noch eine Chance hat das ganze wieder sauber zu deinstallieren. Es gibt ja so einen weit verbreiteten Mythos, dass curl in bash zu pipen pauschal unsicherer wäre. Aber die Sicherheit steht und fällt allein mit der Quelle aus der du ungeprüften code ausführst. Entweder du vertraust example.com oder nicht, ob du das mit curl in bash pipest oder auf irgend einem anderen Wege ausführst ist egal. Entweder die shippen malware dann haben sie dich so oder so, oder sie tun es nicht und curl | bash hinterlässt im schlimmsten Fall ein paar unaufgeräumte Dateien irgendwo.

    (Der einzige Weg ohne verifizierierung der Quelle Sicherheit herzustellen ist eine sandbox, also z.B. als Flatpak installieren und alle kritischen Berechtigungen wegnehmen)







  • Nobody gets forced to port kernel stuff to rust. Also the rust compiler takes a lot of burden from maintainers by the safety it enforces.

    The whole conflict ist not a technical one, it is entirely human. Some long-term kernel developers don’t like people turning up and replacing the code they wrote. Instead of being proud that the concepts they built get to be elevated in a superior implementation, they throw tantrum and sabotage.


  • Be cautious with the answers when asking things like this. In discussion boards like here many are (rightfully) very excited about selfhosting and eager to share what they learned, but may (“just”) have very few years of experience. There’s a LOT to learn in this space, and it also takes a very long time to find out what is truly foolproof and easily recoverable.

    First of, you want your OS do be disposable. And just as the OS should be decoupled, all the things you run should be decoupled from one another. Don’t build complex structures that take effort to rebuild. When you build something, that is state. You want to minimize the amount of state you need to keep track of. Ideally, the only state you should have is your payload data. That is impossible of course, but you get the idea.

    Immutable distros are indeed the way to go for long term reliability. And ideally you want immutability by booting images (like coreOS or Fedora IoT). Distros like microOS are not really immutable, they still use the regular package manager. They only make it a little more reliable by encouraging flatpak/docker/etc (and therefore cutting down on packages managed by the package manager) and a slightly more controlled update-procedure (making them transactional). But ultimately, once your system is in some way defect, the package manager will build on top of that defect. So you keep carrying along that fault. In that sense it is not immune to “os drift” (well expressed), it is just that drift happens slower. “Proper” immutable distros that work with images are self healing, because once you rebase to another image (could be an update or a completely different distribution, doesn’t matter), you have a fresh system that doesn’t have anything to do with the previous image. Furthermore the new image does not get composed on your computer, it gets put together upstream. You only run the final result with you know is bit for bit what was tested by the distro maintainers. So microOS is like receiving a puzzle and a manual how to put it together, and gluing it in a frame is the “immutability”. Updates are like losening the glue of specific pieces and gluing in new ones. In coreOS you receive the glued puzzle and do not have to do anything yourself. Updates are like receiving an entire new glued puzzle. This also comes down to the state idea: some mutable system that was set up a long time ago and even drifted a bit has a ton of state. A truly immutable distro has a very tiny state, it is merely the hash of the image you run, and your changes in /etc (which should be minimal and well documented!).

    Also you want to steer clear from things like Proxmox and generally LXC-containers and VMs. All these are not immutable (let alone immune to drift), and you only burden yourself with maintaining more mutable things with tons of state.

    Docker is a good way to run your stuff. Just make sure to put all the persistent data the belongs together in subfolders of a subvolume and snapshot that, and then backup these snapshots. That way you ensure that you meet the requirements for the data(base)'s ACID properties to work. Your “backups” will be corrupted otherwise, since they would be a wild mosaic from different points in time. To be able to roll back cleanly if an update goes wrong, you should also snapshot the image hash together with the persistent data. This way you can preserve the complete state of a docker service before updating. Here you also minimize the state: you only have your payload data, the image hash and your compose.yml.


  • When you’re maintaining a product that is based on linux, you’re surely qualified to port that thing to your platform yourself.

    Open source developers are thanklessly giving away their work for free already, and for the many things where there’s just a github page it is just a one man show run in spare time. Don’t demand them to give away even more of their time to cater for whatever distro you’re using, just because you are not willing to invest the time to learn how linux works and also not willing to give a way a few megabytes for the dependencies they’re developing against.

    All the discussions about things like distrobox and flatpak where linux novices express their dissatisfaction due to increased disk space are laughable. In the linux universe sole users have no power in deciding what goes, they do not pay anything and at worst pollute the bug tracker. Developers are what make up the linux universe, and what appeals to them is what is going to happen. Flatpak is a much more pleasant experience to develop for than a gazillion distros, hence this is where it is going, end of story. As a user either be happy with wherever the linux rollercoaster goes, or - if you want to see change- step up and contribute.