Somewhat recently I caused a failed kernel update by accident:

Ran system update in tmux session (local session on desktop). But problem was that tmux itself got also updated, which crashed the tmux session and as a result crashed the kernel update. Only realized it upon the following reboot (which no longer worked).

Your described solution re “live ISO, chroot, run system update once more, reboot” was also what got me out of that situation. So certainly something worth learning for “general troubleshooting” purposes re system updates.

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?

Have a ZOWIE EC2 for quite a while now:

• gaming mouse, 5 buttons
• USB compliant
• no special vendor drivers needed to use all mouse features (has buttons on bottom side for settings)

Works well on all OS.

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).