True, git itself can’t prevent people from creating a mess of a commit graph.

TBH, lots of build systems mentioned here I’ve never encountered so far. But this makes it clearer that one can’t reason about how viable a “one big monorepo only” approach mighy be by just considering the capabilities of current git, coming from a “manyrepo” mindset. Likely that was the pitfall I fell into coming into this discussion.

So AFAIU, if a company had:

• frontend
• backend
• desktop apps
• mobile apps

… and all those apps would share some smaller, self developed libraries / components with the frontend and/or backend, then the “no submodules, but one big monorepo” approach would be to just put all those apps into that monorepo as well and simply reference whatever shared code there might be via relative paths, effectively tracking “latest”, or maybe some distinct “stable version folders” (not sure if that’s a thing).

Anyway, certainly never thought to go that far, because having an app that’s “mostly independant” from a codebase perspective be in it’s own repo seemed beneficial. But yeah, it seems to me this is a matter of scale and at some point the cost of not having everything in a monorepo would become too great.

Thanks!

But if not for using submodules, how can one share code between (mono-)repos, which rely on the same common “module” / library / etc.? Is it a matter of “not letting submodules usage get out of hand”, sticking to an “upper limit of submodules”, or are submodules to be avoided entirely for monorepos of a certain scale and there’s a better option?

Regarding tauri: One and a half years ago I looked into it as a potential alternative to using electron.

Back then I had to decide against it for my use case, because when the goal is that it’s a cross platform app, then one has to make sure that whatever “webview version” is used on all target OS, they all have to support the features one needs re one’s own app codebase. Back then I needed some “offscreen canvas” feature that chromium supported (hence electron), but which webkit2gtk (used on Linux) didn’t at the time.

https://tauri.app/v1/references/webview-versions/

So it’s not always easy to give a clear recommendation on using tauri over electron. One really has to get somewhat clear on what kind of “webview requirements” the resp. app will have.

But I do hope this will (or maybe already is) less of an issue in upcoming years (things are moving fast after all).

I went through setting up netdata for a sraging (in progression for a production) server not too long ago.

The netdata docs were quite clear on that fact that the default configuration is a “showcase configuration”, not a “production ready configuration”!

It’s really meant to show off all features to new users, who then can pick what they actually want. Great thing about disabling unimportant things is that one gets a lot more “history” for the same amount of storage need, cause there are simply less data points to track. Similar with adjusting the rate which it takes data points. For instance, going down from default 1s internal to 2s basically halfs the CPU requirement, even more so if one also disables the machine learning stuff.

The one thing I have to admit though is that “optimizing netdata configs” really isn’t that quickly done. There’s just a lot of stuff it provides, lots of docs reading to be done until one roughly gets a feel for configuring it (i.e. knowing what all could be disabled and how much of a difference it actually makes). Of course, there’s always a potential need for optimizations later on when one sees the actual server load in prod.

Assuming one hears their own voice in recorded form enough times, that “strange” feeling it might give at first subsides.

You didn’t mention how big those volumes are and how frequently the data changes.

Assuming it’s not that much data:

• use tar to archive each volume first, while using proper options to preserve permissions and whatever else is important for your usecase
• use restic to backup those archives
• use a proper pruning strategy to not let your backups get too big:
  • I’m not that familiar with restic, but maybe you can backup those archives separately and apply a more aggressive pruning strategy just for them
  • simply might be needed, cause deduplication (AFAIK) might not be that great with backing up archives
  • but maybe if the volume data and the resulting archive doesn’t change that often, deduplication would be sufficient even with a not so aggressive pruning strategy

20 mph (32 km/h) on a regular bike is doable, but yeah, usually that involves a very “flat” road or even a road that has a slight decline. And as you’ve said, maintaining it (e.g. for more than 10 seconds) is a whole different story.

Furthermore, it also requires a certain fitness level and “bodily involvement”. The thing that still catches me off guard at times is how relaxed some people on ebikes look while going that fast. Whatever kind of judgement I could make in the past on how fast someone is approaching based on how much they “visually excert themselves” (e.g. hunching forward or even standing up) kind of has become meaningless with ebikes.

‘Tasks’ (open source android app) can do this. Likely you already knew (others likely don’t). But I agree, a surprisingly uncommen feature.