4 ms·

Is it fair to say "ls" is dead? No commits in 15 years Not at all. Commits are for changes and fixes. If something is working, don't fix it no matter how tem

Is it fair to say "ls" is dead? No commits in 15 years Not at all. Commits are for changes and fixes. If something is working, don't fix it no matter how tempting it may be. Millions of people use "ls" hourly. If it was broken we would be hearing about it.

Miner49er 3y ago
This a parody. It's a comment on the expectation of code to be constantly updated.
- xattt 3y ago
  Has it been rewritten in Electron? It doesn’t use enough RAM so I don’t if ls is actually doing anything. /one_joke
  - ryandrake 3y ago
    It needs a new UI, so it can be "fresh" and "modern" looking. And notifications.
ryanschaefer 3y ago
It’s extremely dead! Its header file hasn’t been touched in 30 years. SMH my head that anyone would believe that a project that doesn’t get nightly updates would NOT be instantly declared dead.
o11c 3y ago
`ls` has definitely had changes and fixes in the last 15 years. The quoting fix I definitely remember. I vaguely recall maybe some sort/time thing? No doubt there is more I don't remember.
- randomdata 3y ago
  Which `ls`?
jodrellblank 3y ago
[flagged]
- wutwutwat 3y ago
  Got you bruh `ls -alsh`
  - nickelcitymario 3y ago
    I think they know that and their point, rightly or wrongly, is that `ls` should, by default, show everything. I don't think they're saying they're unaware of the available flags. (I'm not sure where I would stand on this topic. Just saying that I think they're fully aware of the flags.)
    - jodrellblank 3y ago
      Why don't you know where you would stand on the topic, there can hardly be simpler questions: when I ask my computer for a list of directory contents, should it hide some of them from me or not? At least DOS/Windows has a concept of a 'hidden file' attribute, although I don't like the concept (because they still take up disk space and affect the way programs run, so I the user/admin need to deal with them) at least that's a tag in the filesystem associated with the file which is clearly intended to 'hide' the file. Unix/Linux has no such tag, there's nothing about the file which is hidden. What there is, is a broken directory listing tool which doesn't show some names, but other tools will because they are just ordinary files. Originally a tool which showed the . and .. directories for current/parent, modified to hide those and accidentally hiding 'dotfiles' as well. I can deal with "you have to make choices which details to show, like size or modified time, and which format to show them in". I can't deal with "tool to list files actually hides files from me unless I ask it twice". (Obviously I can deal with it, but having to deal with a broken tool and remember that the tools is broken, is annoying. And the people are Stockholm syndromed to it; it would be easy to 'hide' files by putting them in another directory. That's what we do with /etc, we put config files somewhere we aren't looking so they won't bother us. Why not ~/etc/ for per-user config files?).

Miner49er 3y ago

This a parody. It's a comment on the expectation of code to be constantly updated.

xattt 3y ago
Has it been rewritten in Electron? It doesn’t use enough RAM so I don’t if ls is actually doing anything. /one_joke
- ryandrake 3y ago
  It needs a new UI, so it can be "fresh" and "modern" looking. And notifications.

ryanschaefer 3y ago

It’s extremely dead! Its header file hasn’t been touched in 30 years. SMH my head that anyone would believe that a project that doesn’t get nightly updates would NOT be instantly declared dead.

o11c 3y ago

`ls` has definitely had changes and fixes in the last 15 years. The quoting fix I definitely remember. I vaguely recall maybe some sort/time thing? No doubt there is more I don't remember.

randomdata 3y ago
Which `ls`?

jodrellblank 3y ago

[flagged]

wutwutwat 3y ago
Got you bruh `ls -alsh`
- nickelcitymario 3y ago
  I think they know that and their point, rightly or wrongly, is that `ls` should, by default, show everything. I don't think they're saying they're unaware of the available flags. (I'm not sure where I would stand on this topic. Just saying that I think they're fully aware of the flags.)
  - jodrellblank 3y ago
    Why don't you know where you would stand on the topic, there can hardly be simpler questions: when I ask my computer for a list of directory contents, should it hide some of them from me or not? At least DOS/Windows has a concept of a 'hidden file' attribute, although I don't like the concept (because they still take up disk space and affect the way programs run, so I the user/admin need to deal with them) at least that's a tag in the filesystem associated with the file which is clearly intended to 'hide' the file. Unix/Linux has no such tag, there's nothing about the file which is hidden. What there is, is a broken directory listing tool which doesn't show some names, but other tools will because they are just ordinary files. Originally a tool which showed the . and .. directories for current/parent, modified to hide those and accidentally hiding 'dotfiles' as well. I can deal with "you have to make choices which details to show, like size or modified time, and which format to show them in". I can't deal with "tool to list files actually hides files from me unless I ask it twice". (Obviously I can deal with it, but having to deal with a broken tool and remember that the tools is broken, is annoying. And the people are Stockholm syndromed to it; it would be easy to 'hide' files by putting them in another directory. That's what we do with /etc, we put config files somewhere we aren't looking so they won't bother us. Why not ~/etc/ for per-user config files?).