bellsDoSing @ bellsDoSing @lemm.ee

Posts

0

Comments

61

Joined

2 yr. ago

Oh, it's still going!

Nah, one is enough. ^^ Curiosity got the better of me thinking about how squished the UI might end up looking.

Let the streak continue...

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

Yeah, such a simple, but still killer feature. Really sad that JSON doesn't support them.

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

On top of that, 20 kHz is quite the theoretical upper limit.

Most people, be it due to aging (affects all of us) or due to behaviour (some way more than others), can't hear that far up anyway. Most people would be suprised how high up even e.g. 17 kHz is. Sounds a lot closer to very high pitched "hissing" or "shimmer", not something that's considered "tonal".

So yeah, saying "oh no, let me have my precious 30 kHz" really is questionable.

At least when it comes to listening to finished music files. The validity of higher sampling frequencies during various stages in the audio production process is a different, way less questionable topic,

Yeah, if one really wants obfuscation for JS, then it requires an extra build step. E.g. this: JavaScript-obfuscator

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.

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.

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:

• not overdo the amount of AUR stuff I use
• read the official forum post BEFORE whenever I run a system update

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

I'm in the same boat as you. But considering there's this thing called the "ad industry", there's bound to be a considerable portion of people that are influenced enough by ads, even just at a subconcious level, that investing money into ads is a worthwhile thing to do for businesses selling products and businesses offering ad platforms.

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

AFAIK, if you want disk encryption on Arch, you gotta set it up yourself (i.e. follow the wiki).

And last time I installed manjaro (couple years ago), the installer would let you decide whether you want disk encryption or not. So nobody is being forced to use it.

Then again, if you are tired of it, there likely is a way to effectively disable it for your current install. But most likely that will be quite a bit more involved that just unchecking it during install.