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:
crypto module just wasn't up to scratch yet re nodejs compatibility (for my rather humble needs)--no-npm flag re its use of "deno deploy runtime", which means node: specifiers for imports aren't supportedIn 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.
That's one of the reasons why the more modern fd is a nice alternative: it accepts command line args as you'd expect.
The past doesn't necessarily dictate the future. If the people in charge of SUSE's direction going forward think way differently than the one's back in regards to your comment, then the outcome can be different / better for the Linux community, can't it?
I've been using Manjaro (XFCE edition) as my daily driver, both on a laptop and a desktop system for more than 6 years now. I've tried many others beforehand: Ubuntu and its variations, Arch, Fedora, Tumbleweed, ...
But Manjaro was what made me stop hopping around. While it's true that it has some pitfalls (e.g. cert issues, AUR incompatibility at times), to this day it's working well enough for me that I don't feel like switching away.
I'm not just browsing web on it either. Software engineering, music production, image and video processing, etc.
Then again, I don't consider myself a beginner at this point and can troubleshoot a fair amount of issues now that I simply couldn't when I started using Linux more than a decade ago.
I also try to:
I also always appreciated the fact that I could get away with not doing a system update for like six weeks and then do a big one (as mentioned, in combination with reading their update announcement). That's always something that didn't quite work for me on Arch in the past (then again, I still was a beginner back then, so most "reinstall to solve this problem" situations back then were on me).
What if Manjaro really would get worse enough so I'd want to switch? I guess EndeavourOS would be an option, because it's very close to Arch, but at the same time, it seemingly offers a graphical installer that hopefully will set itself up properly on a laptop. Then again, I haven't installed Arch in quite a while now. Maybe the install experience has gotten much nicer.
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.
Git for projects
I assume the original comment meant code based projects, for which git, if repo is pushed to a remote, is a very sane choice.
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.