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.

IMO (neo)VIM is great for writing text as well, when all you need is markdown level formatting. Personally I use vimwiki a lot (many years by now).

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

And it will find you the most answers online in case you have a git related question.

Just looked it up a bit: https://microsoft.github.io/monaco-editor/

AFAIU, monaco is just about the editor part. So if an electron application doesn’t need an editor, this won’t really help to improve performance.

Having gone through learning and developing with electron myself, this (and the referenced links) was a very helpful resource: https://www.electronjs.org/docs/latest/tutorial/performance

In essence: “measure, measure, measure”.

Then optimize what actually needs optimizing. There’s no easy, generic answer on how to get a given electron app to “appear performant”. I say “appear”, because even vscode leverages various strategies to appear more performant than it might actually be in certain scenarios. I’m not saying this to bash vscode, but because techniques like “lazy loading” are simply a tool in the toolbox called “performance tuning”.

BTW: Not even using C++ will guarantee a performant application in the end, if the application topic itself is complex enough (e.g. video editors, DAWs, etc.) and one doesn’t pay attention to performance during development.

All it takes is to let a bunch of somewhat CPU intensive procedures pile up in an application and at some point it will feel sluggish in certain scenarios. Only way out of that is to measure where the actual bottlenecks are and then think about how one could get away with doing less (or doing less while a bunch of other things are going on and then do it when there’s more of an “idle” time), then make resp. changes to the codebase.

Yeah, that browser zoom. And I too used / use Firefox. I’m not saying these kind of sites are common, but nevertheless I’ve encountered them occasionally. Back then, the most pragmatic workaround was to use desktop zooming of Xfce.

My intention on the previous comment was simply to give some examples of desktop zooming that go beyond the typical accessibility viewpoint (e.g. vision impairment).

That’s why regular backups are advisable.

Yeah, AFAIR, the issue of “windows messing up grub” could happen when it’s installed on the same disk (e.g. on a laptop with one disk). Something about it overwriting the “MBR sector”. At least that was a problem back before UEFI.

I too have been dual booting Windows 10 and Linux for many years now, each having their own physical disk, Linux one always being first in boot order. Not once did a Windows 10 update mess up grub for me with this setup.

Not the same as “on demand zooming”, which let’s one stick with a high, native resolution, but zoom in when required (e.g. websites with small text that can’t be zoomed via browser’s font size increase; e.g. referencing some UI stuff during UI design, without having to take a screenshot and pasting + zooming it in e.g. GIMP).

Honestly, if all you’ve ever experienced in regards to terminals is windows CMD, then you really haven’t seen much. I mean that possitively. Actually, it will give you a far worse impression on what using a Linux / Unix terminal can be like (speaking as someone who spent what feel’s like years in terminals, of which the least amount in windows CMD).

I suggest to simply play around with a Linux terminal (e.g. install VirtualBox,.then use it to install e.g. Ubuntu, then follow some simple random “Linux terminal beginner tutorial” you can find online).

Great read, certainly had more relatable things in there than I’d expected.

Yeah, basically anything that rewrites already pushed history and is then (force-) push is bound to create problems (unless it’s a solo dev only ever coding on a single device, who uses the remote repo as a mere backup solution).