Yeah, I enjoyed when fish shell did their rewrite and people were arguing whether it makes sense technologically, like it’s a mature codebase, so it’s not likely to reduce the number of bugs and yadda yadda yadda.

None of this mattered, because fish is developed by a group of hobbyists. They didn’t want to continue developing in C++, because it was a pain in the ass. And for sure, one of the reasons they wanted to switch to Rust is because it’s new and exciting.
These reasons are perfectly valid, because they’re volunteers. If they’re not having fun, then they will just developing.

Yeah, computationally intensive stuff is going to be slow when implemented in Python. You will find lots of data science libraries for Python that do computationally intensive stuff, but they’re then generally implemented in C/C++ or Rust, with only a thin API layer written in Python.

Expecting the runtime/browser to ship a native implementation of virtually everything you might want to do in a turing-complete language, is also really not sustainable, though.

“Oven is going to be a grind, especially the first nine months or so. If work-life balance means a lot of time spent not working, it’s probably not a good fit.”

Oh man, someone here recently shared a blog post on startup culture in software companies, which likened software to an oven, where you’d add a specific button for a customer and that fucks up your whole architecture for years to come etc…

For just a moment, I thought this was a direct quote from that blog post.

I also like how they claim it’s completely different to KRunner and then, save for OCR and whatever “circle to search” is, these are all features in KRunner.

Yeah, some colleagues from India expressed their concern last week, because they heard how hot it was here.

Felt really weird to have that be actual concern and not just them mocking us, because they’re used to + equipped for worse temperatures.

I mean, my first 30 seconds of experiencing Windows 11 was watching a coworker wait for the file manager to open + render its toolbar, so I don’t think I could’ve really come to a different conclusion…

Also funny: Bosnia and Herzegovina has almost exactly a 100th of the population of the USA.

3,412,000 vs. 341,784,857

Hmm, I’m not sure you do. It’s a pun. “Just dua lipa” sounds like “just do a leap-a”, like someone with an Italian accent might sound like.

Took me a moment to get it, too, though…

Looks like a typo: !datahoarder@selfhosted.forum

df only shows partitions, whereas du adds up the file sizes in the directory you specify.

So, in particular, if you want to find out what’s taking up so much space, you can repeatedly run du -sh * and cd into the largest directory.

It just isn’t easy at all. If someone editorializes a Wikipedia article, they can:

• make claims without citation,
• cite a source which does not support the claims,
• misrepresent a source by citing it out of context, and
• perhaps most devious of all: Just not talk about aspects that they don’t like.

You could write an entire Wikipedia article on Adolf Hitler with perfectly cited sources, which never mentions the genocide, the warmongering, that he lost the war etc…

You can use Wikipedia as an entrypoint for research, but you have to actually read the sources and find additional sources, independently from that.

The atoms are there for sure, but we could argue, whether it is a thing/object without an animal being aware of it, since it’s us that define things to be objects.

The universe doesn’t care whether a pile of atoms behind Pluto happens to be chair-shaped. It’s only when we look at it, that we declare it an object.

https://en.wikipedia.org/wiki/VK_(service)

(“Russian Facebook” is pretty accurate.)

From what I understand, on Debian and therefore presumably also Devuan, the system-wide default shell is dash. So, sh symlinks to dash.

But dash is virtually unusable for interactive use, so they configure the terminal emulator to launch bash on start-up.

In effect, scripts get executed with dash by default, but commands you type into a terminal get run by bash.

https://community.kde.org/Schedules/Plasma_6#Future_releases

Their point is that the maintainer did not sign a contract that requires them to perform maintainer duties. They can choose to stop doing it at any point. They can choose to axe a feature that you deem essential. They can choose to rewrite the project in COBOL for the fun of it.

You may not like it, but that is how it is.
The only legal document involved is the license and any open-source license I’ve seen so far, has stated that the program is provided as is.

This is the license under which rsync is provided: https://www.gnu.org/licenses/gpl-3.0.en.html
See sections 15 and 16.

The only way you get to have a say in the matter, is by forking and becoming a maintainer yourself.

Clap has an entry in their cookbook for a REPL:

• Derive-API: https://docs.rs/clap/latest/clap/_cookbook/repl_derive/index.html
• Builder-API: https://docs.rs/clap/latest/clap/_cookbook/repl/index.html

Of course, this works best for simple stuff, where you just have individual commands to parse.

For a Python-style REPL with a full-fledged language attached, I would not use that approach.
There’s probably some REPL languages implemented in Rust already out there, where you can look at their approach.

Coming at it from the Rust ecosystem, I’d primarily opt for uploading release binaries somewhere. You don’t particularly need a setup script, since Rust programs are generally self-contained.

Publishing a package in addition to that really isn’t hard, but would be my secondary choice, since users are not likely to have cargo on their system.
Well, and cargo compiles on the target machine, which is great for supporting unusual architectures, but you may have C libraries included where it’s just a gamble whether you can compile them on a given target system.