

…the rest of it explains the context, and then briefly says that some people will disagree with the decision, but those people should just use a different distro. What are you complaining about?
…the rest of it explains the context, and then briefly says that some people will disagree with the decision, but those people should just use a different distro. What are you complaining about?
You could also just alias find
back to ^find
. I don’t use nushell as my daily driver for other reasons, and I agree with the comment above that it’s a bit questionable for them to have a built-in with that name, but I don’t understand why you’d even try out a new shell, let alone one that’s radically different from POSIX-style shells, much less complain online about the shell you just tried, when you’re already happy with the shell you’re using and are not willing to adapt any habits or explore the configuration options to match your needs.
I genuinely can’t tell if you’re being sarcastic or not.
I really don’t think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.
Busybox ls
has 26 flags. GNU ls
has 60.
From the busybox “about” page:
The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts… BusyBox has been written with size-optimization and limited resources in mind.
Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.
Sure, Old English. But the commenter isn’t writing in old or even middle English.
That’s fine, just please don’t spread misinformation about a language you don’t use.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
I think you’re making some poorly-researched assumptions.
In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print
Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.
If your goal is small binaries, it’s possible to get them with Rust, too: https://github.com/johnthagen/min-sized-rust
There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.
It’s actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.
Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ’ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.
Looks like it wasn’t even a bug, just a missed opportunity to use SIMD.
Oh, I thought by “already” you meant right now. I would expect that you can use any Wayland-compatible compositor once their Wayland support is complete, yeah.
Not sure about Steam.
No; Wayland is also a protocol, and Niri relies on that protocol, so Niri doesn’t bypass the need for Wayland support.
I understand having severe philosophical disagreements with the Rust project, with the majority of Rust users, or with the uutils
project specifically. What I don’t understand is this part:
If you go to the website of the Rust programming language nowadays, one of the first things you’ll notice is that their primary communication platform is Discord. Yes, you read it right - their primary communication platform is Discord, a proprietary spyware program that is owned by a Chinese investment company and has backdoors to various other national intelligence agencies too.
Rust did have an official Discord, years ago, before switching to Zulip (alongside other official communal hubs, most prominently the Discourse forums that the author complains about next). But this was written in March and specifically says “nowadays”, and I cannot find any mention of Discord on the Rust website.
If you drive a car, have you read the entire owner’s manual for every car you’ve owned? If you’re a homeowner, how about your hvac system? What about your system shell? Your compiler(s)?
At some point you need your tools to be intuitive enough that you don’t need to read an entire manual in order to do your work.
What’s wrong with the explanation given?