Simon Repp

Very neat feature in KDE's Dolphin file manager that I didn't know about (until just now): In the properties dialog for a file you can generate standard checksums, or check against one you got. Nice! \o/

TIL (Mastodon/Hometown): When someone privately mentions you in a post by accident, then edits/removes your mention from the post, that post still stays visible for you (at least in v4.5.7+hometown-1.2.0). Consequently I guess in these cases it's better to "Delete & re-draft" rather than edit the post.

(NB: I'm aware that "what's federated is federated and can't be un-federated", this is merely about what "forthcoming behavior" Mastodon/Hometown offers/doesn't offer (just as deleted posts are only "deleted" remotely based on the good will of the federated-to server software))

I'm now some 68 hours into rewriting faircamp's internal architecture for handling manifests, to accomodate (a) continuous reading and writing of settings at runtime, simultaneously from the outside (e.g. in a text editor) and in the desktop application (with live updates in the interface!), and (b) an entirely new settings inheritance system (actually a bit like the one that existed pre-1.0, just without the footguns [fingers crossed :D], and streamlined and redesigned for the new data model in 2.0).

Truthfully this hasn't been my favorite part of the project so far '^^ - constantly too many things to trip over that can instantly turn into a productivity sink if you're not 100% on guard, fighting between uncomfortable levels of boilerplate/repetition and uncomfortable levels of abstraction (on the upside I've collaterally picked up a mad amount of new rust generics skills these last days).

But ... I'm beginning to see the light at the end of this tunnel, and if the end result of this is roughly what I imagine it to be, faircamp 2.0 will be standing on one hell of a solid foundation for the coming months and years. (˶′◡‵˶)

#faircamp

Just another perfectly normal day working on faircamp 2.0. This is fine. '^^

In about one hour (22:00 CET) the third "Music from the Faircamp's" radio special on @fadimat@social.servus.at is going live!

We selected some fine tracks from the faircamp universe (which gets harder every year - so many good things out there! <3), and I'll again be talking a bit about what's going on with faircamp these days. :)

Live on the air the talking parts will be german (it's local radio from around where I live!), but later on there will be a chance to re-listen to the recorded Q&A in english as well!

Tune in at: https://www.fro.at/fadimat105-march26/

#faircamp #radio #linz

Is there some trick for the official mastodon web client for how I can browse my own posts (and replies) from oldest to newest, rather than the default newest to oldest ordering?

(Scrolling to the beginning is do-able, but tedious. :))

Linz folks: Tomorrow, Sunday, 15:00-18:00 there is a chance to begin (or continue) your personal transition from Big Tech to democracy-aligned digital alternatives, together with the helpful people from servus.at (tomorrow: @aderieg@post.lurk.org, @joak@post.lurk.org et al):

"Where would you like to start? By switching from Whatsapp to Signal or from Gmail to an ethical email provider? By installing Linux? Do you want to find out what the Fediverse is and how you can join? Are you looking for alternative software for certain tasks?

Come by and join us, bring your friends, and we will start taking the first steps together."

https://termine.di.day/events/a040cde5-0dea-4fff-b213-29c3a244c0ae

(This is part of the monthly Digital Independence Day organizing – see https://di.day for the larger context)

TIL that in #rust you can do ...

my_vec
.iter()
.map(|x| something_returning_result(x))
.collect::<Result<Vec<_>>()?;

(also works with Option<Vec<_>>!)

How could I have missed this omg. (;´༎ຶٹ༎ຶ`) Now I finally also understand why type inference is so funky around .collect() :)

https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.collect

I can now tentatively say that there will be speed-ups - and possibly quite significant ones - in #faircamp 2.0.

For one, if you're using the graphical interface, faircamp will¹ "pre-preprocess" (= analyze audio and generate waveforms for) your entire catalog in the background while you're just still exploring the interface and fiddling with texts and settings. I'm planning to also expose this as a `faircamp --warmup` (or so) option in the CLI, so that you can let this pre-preprocessing run while you're still editing things in the manifests (way before building). So in both cases, when you finally request a build, a considerable portion of the required processing might already be ready and waiting in the cache.

Then, because of the graphical user interface, I needed to make all internal data shareable across threads (that's pretty much done by now), and in turn we can reap the benefits in the form of concurrent processing.

I just now naively parallelized decoding, peak generation and encoding, testing with a single album with 17 tracks, and I'm seeing a ~5.5 times faster completion, or in other words, on my machine², a build that took one hour could be done in roughly 12 minutes now, if these figures hold in the larger picture.

(¹) implementation pending but I see zero blockers to that

(²) 16 cores, average i7

For everyone who manually builds and uses #faircamp from the git repository (main branch), an important notice regarding 2.0 development:

"Heads-up: From late february to late summer 2026 (tbd) there will be heavy work and restructuring happening on the main branch. Please expect bugs and undefined behavior when building and using faircamp from main in that period. Until announcement of the first 2.0 release candidates it is also not recommended to report bugs observed on main alone - breakage is likely intentional and/or known for the time being."

Another #faircamp 2.0 feature update: "Publishing source audio as-is (without transcoding)" is definitely coming! \(^ヮ^)/

I already expected this to get tricky, but the final ~20 hours tally (plus probably some 5-10 more hours coming in the longer aftermath) still caught me off guard. 8) Either way I think this is well invested, super useful option and I'm happy to have it in.

The final implementation even allows for two variants: Using the source files verbatim (without any processing at all) or using the original audio stream while rewriting the tags (which is a processing step, but finishes pretty much instantly, it only copies the audio stream payload).

And with this I think I'm finally moving on to get all of this architectural work commited, and then move on to sketching out the first graphical user interface bits. ʕ◜0ᴥ0ʔ (ok the launcher is actually already sketched out hehe)

Today my latest #faircamp 2.0 build rendered some first faircamp sites whose homepages were _not_ the default catalog homepage, but 1) an artist page, 2) a release page, 3) a track page :unwanted_happy: Yesssss.

I started the first base rewrite for #faircamp 2.0 about a month ago. Today, after 120 hours (across 20 work days), faircamp compiled again for the first time. ⸜(˃ ᵕ ˂ )⸝ That now leaves about 160 hours budgeted exclusively for the architectural changes – from a planning perspective this looks very good so far, yay!

The even larger part (over 400 hours of desktop application and graphical interface development) is still ahead, and will be done in parallel with the remaining architectural work, to ensure the revised data model works both from a text-based and a graphical interface perspective (these aren't easy to reconcile, especially in specific areas like settings inheritance ... this has become kind of my nemesis x))).

Fun fact: Asides certain omissions in functionality (which are on me), the first build after 20 days of rewriting (= turning half of the internals into speculative code prose, completely devoid of semantic coherence, and then putting it back together) worked ... just fine (no crash, no nothing, output as expected). I never cease to be amazed by Rust. (*_ _)人