Are there any important-ish programming/scripting languages missing from U7? There is support for PHP, Python, Node, Ruby, go, rust, .NET, Erlang/OTP, Perl, Clojure, Java, GCC, Lua, and a few smaller ones.

Today in Uberspace 7 development: let's commit -----BEGIN RSA PRIVATE KEY----- πŸŽ‰πŸ˜ (really don't try this at home!)

Show thread

Today in Uberspace 7 development: let's commit -----BEGIN CERTIFICATE----- πŸŽ‰πŸ˜ (don't try this at home!)

thanks for all the feedback ❀️ our fediverse presence is really evolving into a valuable platform to gather ideas and make decisions! πŸ‘©β€πŸ”¬

Show thread

So, what do we do to get rid of EOLd python versions in a way that doesn't cause a couple thousand python users to scream at us?

Bonus: a dependency installed using "pip3.6" cannot be used by "python3.7" (very reasonable, but not helpful in this case.)

Show thread

There is one problematic case, though: python. Instead of relying on our own "uberspace tools version" tool, we provide all the versions as python3.x binaries, so there is a python3.7, a python3.8 and so on. This is fairly standard and expected among python users. There is just one catch: we cannot easily bump users onto 3.7 once 3.6 gets EOLd, because we do not know all the places users might reference the binaries: service configs, hashbang lines, shell histories cronjobs,...

Show thread

Our general software version policy on U7 is to remove EOLd versions (like node.js v13) and bump users to another, reasonable version. Most of the time the nearest LTS release. Works great for node, ruby, and all the other languages which utilize the "uberspace tools version use [tool] [version]" mechanism. Users just type "node" and get whatever version they configured. Just bumping them also produces _way_ fewer broken sites than one might expect.

This drives Arch Linux (and probably others) to just keep a separate _srcver=3330000 alongside the pkgver=3.33.0 and hardcode the /2020/ in URL. Works fine, if you touch that file manually. But I'd like to automate ours.

Anyway, I now take 3.33.0, convert it to 3330000 using python and assume the current year to be the right one. Breaks, if you want to build an old version, but should work for almost all future builds. good enough.

</sqlite-rant> (sorry!)

Show thread

(of course, I know why. Having 3XXYYZZ makes it sort nicely with tools like "ls", having the year in there makes sure the directories on their server stay nice and small. still, it bugs me :( especially the unknowable year.)

Show thread

sqlite has the most annoying tarball URLs: 2020/sqlite-autoconf-3330000.tar.gz

Assume you know a version number R.X.Y.Z, e.g. "3.33.0" and you'd like the URL. First, convert it to XXYYZZ, adding zeroes. Keep in mind that the final .0 (ZZ) is left out for most (all?) published versions. Once you got that part, prepend the major version (e.g. "3") _without_ adding a zero. Finally you.. guess(?) the release year of that version and add that too.

why? :(

Show thread

our poor build server has to compile six packages all at once πŸ˜… new nodejs & python versions coming soon πŸŽ‰

We just had the meeting concluding our backup adventures. While both borg and restic offer advantages compared to our crusty rsync backup, the performance is equally good/bad. Since performance is our primary paint point, we'll not switch to either of them for now. Instead, @ops will have a look at backup solutions one layer down: inside ceph/proxmox. After that we'll try to make a new plan.

They are both very nice tools, though! Can recommend either of them.

Thanks for following along! :) πŸŽ‰

Show thread

soo, the next release is gonna be Uberspace v7.7.7! βœˆοΈπŸŽ‰

Even though restic's user interface seemed much nicer at first (I still like their command names better!), borg's appears to be more practical.

Figuring out your deduplication ratio, storage usage, and other facts is much easier and considerably faster: " info" (takes 6s) vs. " stats --mode restore-size" + "raw-data" (20 minutes total! wow.). The latter also gives a much more bare bones looking output.. :/

Show thread

The results of running both and after 24 hours of actual user activity are in! Around 2GB of a total of 300GB changed, which took ...

restic 0:47 hours and
borg 1:03 hours

... to sync.

The numbers are interesting, because they don't match the small scale test done yesterday: When running both tools on just 13GB of data, borg was twice as fast as restic. That's the cost of handling actual data and sharing the CPU/storage access with actual users, I guess.

Show thread

Below you can see the load and traffic restic produces as it creates a backup. The initial sync seems to be mostly network or disk constrained, the 2nd sync is CPU constrained. Memory usage is negligible. (Annotations: restic initial start, restic 2nd sync start, restic stop / borg start.)

Show thread

the first run with took 7 whole hours (vs. 3:45h ), the 2nd one 51m (vs. 45m restic). Borg without compression to make the tools more comparable. Let's see how they compare tomorrow after a full 24 hours worth of user activity.

Show thread

turns out, the user was using to send requests. using curl on their local machine yields a 301 (and a POST on HTTPS) - both as expected. I used postman before and it worked great, no idea what's going on exactly.

in any case, when in doubt, don't trust anything but "curl -v", apparently m)

Show thread
Show more
Uberspace Mastodon

This server is for internal use only at the moment