lsr: ls with io_uring

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

`ls` is in C, `lsr` is in Zig. The `lsr` programmer probably doesn't want to make new code in C.

> Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring?

Good luck getting that upstreamed and accepted. The more foundational the tools (and GNU coreutils definitely is foundational), the more difficult that process will be.

Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions.

You don't have to install it. You can modify ls yourself too.

In addition, the author might not want to sign away their rights to the FSF.

> Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions.

which certainly is a valid way or prioritizing. similarly, distros/users may prioritize stability, which means the theoretical improvement would now be stuck in not-used-land. the value of software appears when it's run, not when it's written

In the history of Unix its also a common way to propose tool replacements, for instance how `less` became `more` on most systems, or `vim` became the new `vi` which in its day became the new `ed`.

> the value of software appears when it's run, not when it's written

Have you ever tried to contribute to open source projects?

The question was why wouldn't someone writing software not take the route likely to end in rejection/failure. I don't know about you, but if I write software, I am not going to write it for a project whose managers will make it difficult for my PR to be accepted, and that 99% likely it never will be.

I will always contribute to the project likely to appreciate my work and incorporate it.

I'll share an anecdote: I got involved with a project, filed a couple PRs that were accepted (slowly), and then I talked about refactoring something so it could be tested better and wasn't so fragile and tightly coupled to IO. "Sounds great" was the response.

So I did the refactor. Filed a PR and asked for code review. The response was (after a long time waiting) "thanks but no, we don't want this." PR closed. No feedback, nothing.

I don't even use the software anymore. I certainly haven't tried to fix any bugs. I don't like being jerked around by management, especially when I'm doing it for free.

(For the record, I privately forked the code and run my own version that is better because by refactoring and then writing tests, I discovered a number of bugs I couldn't be arsed to file with the original project.)

What on earth are you talking about? Why would this be the case?

Depending on the implementation (and I don't know which `ls` is being referred to), modifying `ls` might mean modifying an FSF project which require copyright assignment as a condition of patch submissions.

> instance how `less` became `more` on most systems

How `more` became `less`.

The name of 'more' was from paging - rather than having text scroll off the screen, it would show you one page, then ask if you wanted to see 'more' and scroll down.

'less' is a joke by the less authors. 'less is more' etc.

The author answered on lobster thread [1]. This is more of an io_uring exercise than an attempt to replace ls.

[1] https://lobste.rs/s/mklbl9/lsr_ls_with_io_uring

> Have you ever tried to contribute to open source projects?

yes, and it was often painful enough to make me consider very well wether I want to bother contributing. I can only imagine how terrible the experience must be at a core utility such as ls.

> The question was why wouldn't someone writing software not take the route likely to end in rejection/failure

Obviously they wouldn't - in my comment I assumed that the lsr author aimed for providing a better ls for people and tried to offer a perspective with a different definition of what success is.

> I don't like being jerked around by management, especially when I'm doing it for free

I get that. The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute. But you can try to see it from the maintainers perspective too: They have actual people relying on the program being stable and are often also not paid. Noone is forcing you to contribute to their project, but if you don't want to deal with existing maintainers, you won't have their users enjoying your patchset. Know what you want to achieve and act accordingly, is all I'm trying to say.

Are you unfamiliar with contributing to GNU projects (ls is part of GNU corutils)?

https://www.gnu.org/prep/maintain/maintain.html#Copyright-Pa...

Yes and no. We don't really have the equivalent of comp.sources.unix nowadays, which is where the early versions of those occurred, and comp.sources.unix did not take just anything. Rich Salz had rules.

Plus, since I actually took stevie and screen and others from comp.sources.unix and worked on them, and wasn't able to even send my improvements to M. Salz or the original authors at all, from my country, I can attest that contributing improvements had hurdles just as large to overcome back then as there exist now. They're just different.

> The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute.

Newer ones can be just as braindead, if they came out of some commercial entity. CLAs and such.

For a while there was a less competitor named most.

It hasn't gone away.

* https://freshports.org/sysutils/most/

* https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/misc/most/i...

* https://packages.debian.org/sid/most

One can even get pg still, with Ilumos-based systems; even though that was actually taken out of the SUS years ago. This goes to show that what's standard is not the same as what exists, of course.

* https://illumos.org/man/1/pg

* https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

That's only the case if the author would want to upstream their changes. If they wanted to only fork ls then they would only be required to comply with the license, without assigning copyright over.

That may be the case but then why bother modifying ls when you can just write your own exactly as you want it?

That CLA is a curious take, as the old, avowedly non-commercial, GNU foundational tools such as the ones we're talking about like "ls" in coreutils, have always required a kind of strong CLA to be signed from the very beginning, even when they wee new, nimble and fun to contribute to.

Their kind of CLA was designed to uphold community and openness values more strongly than GPL alone, by helping GNU to pursue GPL violators through the law, to fource vendors to release source code when GPL code was shipped in products..

So I've never understood the blanket "don't like regardless of what it says" attitude to CLAs and such.

Surely it should depend on what the CLA says?

Some people object to CLAs that grant upstream less rights than BSD/MIT/Apache licenses grant upstream by defaut. ("No way, the CLA lets them make. a private, commercial fork of my code!"). Yet the same people contribute enthusiastically to BSD/MIT/Apache projects with exactly the same upstream property ("I don't mind that the license let's them make a private, commercial fork of my code!").