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.

Coincidentally, I happen to have been reading into SEO more in depth this week. Specifically official SEO docs by google:

https://developers.google.com/search/docs/fundamentals/seo-starter-guide

To be clear, SEO isn’t about tricking search engines per se. First and foremost it’s about optimizing a given website so that the crawling and indexing of the website’s content is working well.

It’s just that various websites have tried various “tricks” over time to mislead the crawling, indexing and ultimately the search engine ranking, just so their website comes up higher and more often than it should based on its content’s quality and relevancy.

Tricks like:

• keyword stuffing
• hidden content just visible to crawlers
• …

Those docs linked above (that link is just part of much more docs) even mention many of those “tricks” and explicitely advise against them, as it will cause websites to be penalized in their ranking.

Well, at least that’s what the docs say. In the end it’s an “arms race” between search engines and trickery using websites.

Depends on the specific plugin. I’ve been doing music production on Linux for several years now. Back then things looked a lot worse than now. Most popular bridge solution for Windows plugins on Linux is yabridge atm. The README is well worth a closer read, cause it will answer many questions on how to get even more modern plugins to display correctly (i.e. JUCE based ones).

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.

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

Nobody can tell you in advance how far your interest in game dev will take you. Only one way to find out: start small (some tutorials, build some crappy first) and see if your interest sticks around as you up the challange.

Maybe game dev in Godot will end up being a significant chapter in your life, maybe it will just be a small sidequest. But once you’ve given it an honest try, no matter the outcome, you at least will know if it’s something for you or not. That in itself is already worth something.

And who knows: maybe Godot is just your entry gateway to something else you discover along the way, which you wouldn’t have discovered if you hadn’t taken on the challange in the first place.

Also called the rubber duck debugging effect.

But yeah, articulating your thoughts, be it by talking or even by writing down your train of thoughts (which is a good habit to have while debugging complex issues) really helps spotting the holes in your own thinking.

To add, edge functions (powered by deno) are one of the bigger pain points of supabase. At least that’s my own practical experience and the experience of quite a few others on their github (discussions and issues).

In my current project, I started of optimistically (“Should be doable, they say you feel right at home coming from nodejs!”), tried rewriting some existing nodejs code and use edge functions just like your average nodejs powered serverless functions.

But in the end, things just didn’t work out:

• deno’s crypto module just wasn’t up to scratch yet re nodejs compatibility (for my rather humble needs)
• supabase uses --no-npm flag re its use of “deno deploy runtime”, which means node: specifiers for imports aren’t supported
• the fact that unlike for serverless functions, which update their runtime only once you yourself trigger a new deployment (e.g. nodejs on vercel), “deno deploy runtime” is continously being updated to latest version, which to me still feels pretty strange for production use, considering how serverless functions handle runtime updates.

In the end I changed my architecture yet again, moved most of the code to an expressjs backend and only use edge functions as a kind of “tender” proxy layer with minimal dependencies (mostly just deno and some esm.sh imports; e.g. supabase-js).

Don’t get me wrong, supabase overall is a great thing and they do many things well! I’m still using them going forward. But edge functions just have the potential for being such a pain point in a project and many have already wished for also having the option for “classic” serverless functions.

I additionally mapped that latter one to F2, because being able to repeatedly copy from VIM and paste into another application without having to move your hand between mouse and keyboard is nice.

Of course, that’s VIM. If you meant “vim mode” in shell, then that’s a different story.

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.

Yeah, truely! There’s plenty of “data written” that will outlast beyond his “departure”.

Yeah, context very much matters for numbers like this!

Just thought that maybe one could get a better impression by calculating bug count / star count ratio. But not every active user that is happily using a project without issues will give a star. Still, this seems the best option there is to my knowledge.

But it’d be nice at times to have more stats on GitHub. Something like a “total clones” number. Then again, that can also likely end up inflated for some projects.

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