[-] Spore@lemmy.ml 11 points 2 weeks ago

mindlessly chanting “tools”

That's what you were doing in the first place. Instead of evaluating and trying new things, you are putting them in an imaginary cycle, ignoring any actual value that they brings.

Also Rust has been on your "stage 2" for 10 years. It's now widely used in multiple mainstream operating systems for both components and drivers, driving part of the world's internet stack, and is used to build many of those "shiny and new tools".

[-] Spore@lemmy.ml 10 points 2 weeks ago

I assume that you do know that tools improve objectively in the cycle and are making a joke on purpose.

[-] Spore@lemmy.ml 45 points 9 months ago* (last edited 9 months ago)
  1. breaks compatibility
  2. breaks compatibility
  3. breaks compatibility
  4. hard to add without breaking compatibility

Then we arrive at Rust as a natural outcome.

And it's of course possible to migrate to Rust from C or C++ progressively, fish has almost got it done.

[-] Spore@lemmy.ml 22 points 10 months ago* (last edited 10 months ago)

Honestly I'm surprised that so many people don't know how git can be used without those repository hosting sites. That's one way to use it, not the only way. And it's not even the way it was originally designed for.

Checkout git format-patch.

[-] Spore@lemmy.ml 22 points 10 months ago* (last edited 10 months ago)

Git and Email are not mutually exclusive. In order to collaborate with git, you need and only need a way to send your commits to others. Commits can be formatted as plain-text files and sent through emails. That is how git has been used by its author from literally the first release of it.

[-] Spore@lemmy.ml 67 points 10 months ago* (last edited 10 months ago)

This reminds me of a similar experience.

The first release of WSL(2) 1.0 (this versioning alone is worth another post here, but let's not talk about it) have its CLI --help message machine translated in some languages.
That's already evil enough, but the real problem is that they've blindly fed the whole message into the translator, so every line and word is translated, including the command's flag names.

So if you're Chinese, Japanese or French, you will have to guess what's the corresponding flag names in English in order to get anything working.
And as I've said it's machine translated so every word is. darn. inaccurate. How am I supposed to know that "--分布" is actually "--distribution"? It's "发行版" in Chinese and "ディストリビューション" in Japanese.

At last I had to switch my system language to English to set a WSL instance up. From then on I never use any display language other than English for Microsoft products. Sometimes "translated" is worse than raw text in its original language.

Related links if you like to see people suffer:
https://github.com/microsoft/WSL/issues/7868
https://github.com/microsoft/WSL/issues/4111

PS: for the original post, my stance is "please don't make your software interface different for different languages". It's the exact opposite of the author has claimed: it breaks the already formed connection by making people's commands different.
It's the CLI equivalence of scrambling every button to make sure they are placed differently in different languages in GUI. I hope this sounds stupid enough so that no one will try it.
A not-so-stupid way that I can think of is to add a "translation" subcommand to the app that given any supported flags in any language it converts them to the user's language. Which is still not so useful and is not any better than a properly translated documentation, anyway.

[-] Spore@lemmy.ml 33 points 11 months ago* (last edited 11 months ago)

Compared to btrfs it's claimed to be faster and having working RAID support. Its unique feature is using a fast device as cache to speed up access to slower, larger disks, I think.

[-] Spore@lemmy.ml 19 points 11 months ago

Some have better ux, some support more platforms out of the box. I don't find it a good idea trying to replace everything though.

[-] Spore@lemmy.ml 10 points 1 year ago

So why not just use the lean and maintainable wlroots

wlroots can't be used (comfortably and idiomatically) in Rust because it's too hard (if not impossible) to provide a memory-safe interface for it.

we can move to another implementation of the Wayland protocols.

So unfortunately this has already happened.

[-] Spore@lemmy.ml 16 points 1 year ago

the developer chooses to work with these publishers beforehand

What kind of paradise are you living in?

[-] Spore@lemmy.ml 9 points 1 year ago

Any stream content. Any subscription. Anything that I can't access because of my nationality.

I'd pay for other things.

[-] Spore@lemmy.ml 10 points 1 year ago* (last edited 1 year ago)

I'm looking forward to it.

On the technical side, they are using pure Rust to build the DE, and the Rust GUI ecosystem has been greatly improved by their hard work. If their product turns out to be successful, Iced may eventually become "the Qt of Rust".

As a user I like their design shown in current demos, and a Wayland-first DE with first class nvidia support is really needed.

view more: next ›

Spore

joined 1 year ago