Du könnstest mal in openstreetmap nachsehen. Man kann Treppen recht detailiert kartiern (Anzahl der Stufen etwa), ich weiß aber nicht wie flächendeckend das zumindest für außergewöhnliche Treppen eingetragen ist.
skilltheamps
joined 2 years ago
Going by the screenshots in Github, this is another case of molesting the high-level Python interpreter with low level code riddles. Look at this, are you fucking kidding me?
Importing numpy and then this fucking list comprehension? You need AI telling you that this code is absolute garbage? Well, you're an imbecile then.
And even having the audacity to fuel the Python-is-slow theme with claims like "its 60000 times slower than other languages". You're writing just incredibly stupid code, asshat
Use a systemd-service + systemd-timer. You can then run "systemctl start myjob.service" to check that it runs as you expect. If it works "systemctl enable --now myjob.timer" to kick it off as scheduled
Für sowas kann ich empfehlen mit ner großen Styroporbox bei nem Restaurant aufzuschlagen. Da bekommt man zum Teil für 5€ so viel Eis dass man es fast nicht mehr tragen kann
I built a small tool that does that for me now and published it: https://feddit.de/post/2909288 maybe you'll find it useful, no guarantee that it doesn't break something though :D
I only keep track of the sha256, compose happily uses those. I published the tool https://feddit.de/post/2909288 :)
I think problems that turn up with time are also things like dependencies moving on, people with a slightly different setup which unfortunately breaks the thing or at least surfaces bugs, or that the author doesn't even use the software anymore because it was hardware specific and they have other hardware now etc... Yes they are not obliged to anything, that's what I think too. I was more thinking in the direction of taking some precautionary measure that makes the project stay more useful (and maybe more maintained) when the original author has long abandoned it.
Ahhh that looks very interesting! It seems to commit on actuall maintaining the projects that make it in there, hence of course trying to keep the number small and only letting relevant high quality projects in. That's of course more than gifting ownership of a project to the public for somebody to grab, but a rather nice concept nontheless!
I like your second point, and already started polishing the thing more than I would have for just my own purposes. It's a good way to make it easier for somebody to take it on in the future. And it's also a measure that the original creator more likely has the will to implement while focusing on building the thing, i.e. before they moved on to other things. Also for my current project I try to keep it simple. It may not be the prettiest, most configurable or universal tool. But it has a short code and minimal dependencies. Thank you for your comment, that made me think about how traits like this can become very valuable for others.
Your first point I do anyways, and the third I'm not sure about yet. Maybe documenting such things as issues preserves them decently.
Do you do some sort of versioning/snapshotting of your services? I'm on the compose route as well, and have one btrfs subvolume per service that holds the compose.yml and all bind-mounted folders for perstistent data. That again gets regularly snapshotted by snapper.
What leaves me a bit astounded is, that nobody seems to version the containers they are running. But without that, rolling back if something breaks might become a game of guessing the correct container version. I started building a tool that snapshots a service, then rewrites the image: in compose.yml to reflect what ever the current :latest tag resolves to. Surprisingly, there doesn't seem to be an off-the-shelf solution for that...
The learning curve of NixOS is also what keeps me from trying it out, hence I prefer the "take it or leave it" mantra of the immutable fedoras, and try to keep the amount of packages I have rpm-ostree layer on top minimal.
As for Distrobox, yes there's ways it can fail, altough that happened rarely to me. What happens mostly is that the distro inside distrobox goes kaput because that's just what mutable distros beared with a plethora of questionable tooling installed with "curl something | bash" does. But for me that's the point of distrobox: separate all that shady cruft one may need for work/developing/etc from the host os. It's a place for messing about without messing up the computer and with it the bits that need to keep working
But it should not need write access to those files.
I bet it is due to different UID. Nextcloud runs with the www-data user, and UID 1000 is likely whatever user OP set up on the host machine. Make Duplicati run with the same UID as nextcloud and it will have the permission to read the files.