Niri + QuickShell (e.g. DMS) is already better than what you can get on Windows and Mac. Manual window dragging should die off already (GNOME and KDE; looking at y'all. Linux needs to leave it behind too)
Even tools like PaperWM.spoon can only mimic a fraction of the grace of Niri (no offense to the PaperWM.spoon team; macOS is holding them back)
I wonder how many Arch haters have actually used Arch and ever ran into a breaking issue.
In my 8 years of daily driving Arch, I have had 1 ever, and it was only bad bc I didn't know of BTRFS yet.
That happened 3 years in, and I went on a new distro-hopping spree in between, trying Fedora, NixOS, and others, and they had actual problems. Not "oh an update broke my system and was fixed in a day."
So now I've been back on Arch for more years.
This whole "Arch is always breaking and takes so much maintenance" is a myth. In reality, Arch is the most stable, because it packages everything Vanilla. Everything works the "standard" way. On Debian, things decay, and then some stuff that's new breaks with some stuff that's old. On Fedora, there is a Red-Hat tax: configs in weird places, strange scripts, software missing from main repos (COPR sucks btw). On Arch, it's just "normal" Linux; and that works
I'm not really talking about teaching and guiding though.
If you look at the meme, one of the responses is something like "PRs welcome."
I think that's appropriate in certain circumstances.
You are correct, there is nothing wrong with a lack of knowledge or dumb questions. I'm referring more to how they ask their dumb questions.
Some newbies come with hostility, pride, and entitlement, not ignorance.
They request new features, say something sucks bc of blah blah blah, and then get mad at people responding rudely back. But what else should we respond with in this kind of situation? They aren't looking to learn. They are looking to degrade projects, users, and maintainers.
They aren't looking for answers; they're looking to be mad about something and confirm their opinion that "Linux sucks" or some other such bias.
So yeah, when someone comes humbly even with bad assumptions, absolutely correct and guide, but there's no point guiding people who don't actually want guidance, ya know? Pearls before swine
Tbf, those are sometimes valid responses, the new user just doesn't realize what they're asking is dumb, and it's exhausting to deal with when a bit of reading would solve the problem or show them what they're asking is impossible.
It's not really 130-150 words per min though bc mostly the words we say are nonsense, "uhms" and saying the wrong thing and starting over and pausing and such.
Not to mention, when we speak to a computer, it's not like to a person, as others have pointed out. The 130-150 wpm number comes from in context speaking where we already know what we're going to say. That isn't the case when doing things on a computer such as responding to a comment, anything requiring thinking, coding, etc.
Also, speech-to-text systems do not immediately recognize the speech we say, adding further delay.
So it's not actually 130-150 words a minute.
In terms of meaningful day-to-day use, I maintain that it's far slower and less precise than a keyboard, especially if you're a proficient typer.
And this makes sense as everyone I've ever met who likes to use speech-to-text (excluding those who MUST use it for disability reasons) are simply those who are bad at typing. Cope harder. slow-mo. This comment was written using a keyboard
EDIT:
so what they’re saying is true for that one use case
This doesn't follow. Both of us are talking about inputing in english. Vibe-coding with a keyboard is also superior there
The ARM nature of the Pi could make it difficult depending on Engine. Might be better to look at an x86_64 SBC to build a platform on. Those tend to be more expensive tho
This is why I really want to make my own open-source console platform.
Indie developers can target it, it can have some kind of cartridges (probably flash based) which people can sell directly, and complete open-source and hackable (but with simple ways to customize, so people can buy accesssories instead of making them, if they're not maker inclined).
If enough people could use this console, then even AAA devs might consider it.
But the problem is it has to be decently powerful while staying affordable. Traditionally consoles lose money (recouped when people buy first party titles). It's a failed business model as evident by all these major studios moving away from it. First SEGA leaving the console market, then Nintendo making Game Key Cards, and now Sony removing physical all together.
I mean tbh, people could simply target the Raspberry Pi 3B as a standard platform for gaming. Those still go for $35, unlike the Pi 4 and Pi 5, and are capable of 2D games and limited 3D games (perfectly fine for Indie). It runs Linux which is easy enough to develop for both in direct code and from game engines (except Unreal which is annoying about it). Add some sort of "card hat" like those readers a few people have made, and it could be great for that world at least. Wrap it up into a product for like $50 with a controller and it could be something
But idk, the AAA world is gonna continue to shift from these models. At least PC is a bit better with its digital storefronts, but it's not perfect either, and you still don't "own" anything.
Are they using any original GNU coreutils code as reference? My understanding is nothing is 1:1. They're trying to build, from the ground up, a totally new codebase that has the same user-facing functionality but under the hood is idomatic Rust code (so nothing like the GNU C code)
They are recreating something that matches behavior not using licensed GPL code. Which is the same way the GNU coreutils were a recreation of the proprietary Unix tools in an effort to provide open source alternatives.
Like you wouldn't say "An appropriate amount of work to slap a GPL license on somebody else's work" in reference to GNU recreating the Unix tools, so why say it here?
I'm not suggesting containers but rather running binaries natively, just as separate users. No cgroups or overhead. Just normal binary access, just you won't have access to all files (and since everything is a file, "all files" includes hardware as well)
I'm in stage 2
Niri + QuickShell (e.g. DMS) is already better than what you can get on Windows and Mac. Manual window dragging should die off already (GNOME and KDE; looking at y'all. Linux needs to leave it behind too)
Even tools like PaperWM.spoon can only mimic a fraction of the grace of Niri (no offense to the PaperWM.spoon team; macOS is holding them back)
Wow that's like over double in 2 months
I wonder how many Arch haters have actually used Arch and ever ran into a breaking issue.
In my 8 years of daily driving Arch, I have had 1 ever, and it was only bad bc I didn't know of BTRFS yet.
That happened 3 years in, and I went on a new distro-hopping spree in between, trying Fedora, NixOS, and others, and they had actual problems. Not "oh an update broke my system and was fixed in a day."
So now I've been back on Arch for more years.
This whole "Arch is always breaking and takes so much maintenance" is a myth. In reality, Arch is the most stable, because it packages everything Vanilla. Everything works the "standard" way. On Debian, things decay, and then some stuff that's new breaks with some stuff that's old. On Fedora, there is a Red-Hat tax: configs in weird places, strange scripts, software missing from main repos (COPR sucks btw). On Arch, it's just "normal" Linux; and that works
I'm not really talking about teaching and guiding though.
If you look at the meme, one of the responses is something like "PRs welcome."
I think that's appropriate in certain circumstances.
You are correct, there is nothing wrong with a lack of knowledge or dumb questions. I'm referring more to how they ask their dumb questions.
Some newbies come with hostility, pride, and entitlement, not ignorance.
They request new features, say something sucks bc of blah blah blah, and then get mad at people responding rudely back. But what else should we respond with in this kind of situation? They aren't looking to learn. They are looking to degrade projects, users, and maintainers.
They aren't looking for answers; they're looking to be mad about something and confirm their opinion that "Linux sucks" or some other such bias.
So yeah, when someone comes humbly even with bad assumptions, absolutely correct and guide, but there's no point guiding people who don't actually want guidance, ya know? Pearls before swine
So sometimes these aren't bad responses
Tbf, those are sometimes valid responses, the new user just doesn't realize what they're asking is dumb, and it's exhausting to deal with when a bit of reading would solve the problem or show them what they're asking is impossible.
It's not really 130-150 words per min though bc mostly the words we say are nonsense, "uhms" and saying the wrong thing and starting over and pausing and such.
Not to mention, when we speak to a computer, it's not like to a person, as others have pointed out. The 130-150 wpm number comes from in context speaking where we already know what we're going to say. That isn't the case when doing things on a computer such as responding to a comment, anything requiring thinking, coding, etc.
Also, speech-to-text systems do not immediately recognize the speech we say, adding further delay.
So it's not actually 130-150 words a minute.
In terms of meaningful day-to-day use, I maintain that it's far slower and less precise than a keyboard, especially if you're a proficient typer.
And this makes sense as everyone I've ever met who likes to use speech-to-text (excluding those who MUST use it for disability reasons) are simply those who are bad at typing. Cope harder. slow-mo. This comment was written using a keyboard
EDIT:
This doesn't follow. Both of us are talking about inputing in english. Vibe-coding with a keyboard is also superior there
Keyboards are way more efficient than voice tho
Fallout 67 let's go
It's going to be a sad day when Linus finally leaves the kernel
The ARM nature of the Pi could make it difficult depending on Engine. Might be better to look at an x86_64 SBC to build a platform on. Those tend to be more expensive tho
This is why I really want to make my own open-source console platform.
Indie developers can target it, it can have some kind of cartridges (probably flash based) which people can sell directly, and complete open-source and hackable (but with simple ways to customize, so people can buy accesssories instead of making them, if they're not maker inclined).
If enough people could use this console, then even AAA devs might consider it.
But the problem is it has to be decently powerful while staying affordable. Traditionally consoles lose money (recouped when people buy first party titles). It's a failed business model as evident by all these major studios moving away from it. First SEGA leaving the console market, then Nintendo making Game Key Cards, and now Sony removing physical all together.
I mean tbh, people could simply target the Raspberry Pi 3B as a standard platform for gaming. Those still go for $35, unlike the Pi 4 and Pi 5, and are capable of 2D games and limited 3D games (perfectly fine for Indie). It runs Linux which is easy enough to develop for both in direct code and from game engines (except Unreal which is annoying about it). Add some sort of "card hat" like those readers a few people have made, and it could be great for that world at least. Wrap it up into a product for like $50 with a controller and it could be something
But idk, the AAA world is gonna continue to shift from these models. At least PC is a bit better with its digital storefronts, but it's not perfect either, and you still don't "own" anything.
To stop cheaters is the reason lol
When did they shell out "real work" to C?
There is no C in the repo: https://github.com/uutils/coreutils
They aren't wrapping the GNU coreutils in a Rust shell; it's a total unaffiliated reverse-engineering
Are they using any original GNU coreutils code as reference? My understanding is nothing is 1:1. They're trying to build, from the ground up, a totally new codebase that has the same user-facing functionality but under the hood is idomatic Rust code (so nothing like the GNU C code)
They are recreating something that matches behavior not using licensed GPL code. Which is the same way the GNU coreutils were a recreation of the proprietary Unix tools in an effort to provide open source alternatives.
Like you wouldn't say "An appropriate amount of work to slap a GPL license on somebody else's work" in reference to GNU recreating the Unix tools, so why say it here?
Here's how it's gonna go down:
Really? I quite enjoy the UI system of Godot.
Stacking Margin, HBox, and VBoxes together feels quite intuitive to me
What did you not like?
Overhead
And for a number of reasons this isn't like flatpak at all.
I'm not suggesting containers but rather running binaries natively, just as separate users. No cgroups or overhead. Just normal binary access, just you won't have access to all files (and since everything is a file, "all files" includes hardware as well)