7 ms·

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is su

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lines of code [2], about a third of the size of Lua.) [1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/index.html https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/... [2]: https://github.com/sharkdp/fd https://github.com/sharkdp/fd

wbl 3y ago
The problem with find is that it tries to put an entire programing language into its arguments.
- pcwalton 3y ago
  I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.
  - comex 3y ago
    That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is ls | where size > 10mb | sort-by modified It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.
    - arp242 3y ago
      zsh solves this with globbing qualifiers: ls -t *(Lm+10) "L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things). The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.
    - maleldil 3y ago
      > Nushell they didn't have scripting yet If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_101/flag.nu https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...
- jrockway 3y ago
  Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem. I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)
  - exitb 3y ago
    Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.
    - SubjectToChange 3y ago
      …we're using insane amount of code and cpu load to solve really simple problems on daily basis. Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code. I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.
      - exitb 3y ago
        > More code doesn’t necessarily imply more resource usage. That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere. Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.
- amstan 3y ago
  Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.
  - e12e 3y ago
    Hard to grep a list of path names for size or last modification date? When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1). And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters. However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell... https://man.cat-v.org/plan_9/1/grep https://man.cat-v.org/plan_9/1/grep https://man.cat-v.org/plan_9/1/du https://man.cat-v.org/plan_9/1/du
- kristopolous 3y ago
  And it makes easy things hard. All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time. Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused. Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)
  - skissane 3y ago
    > and the print0 for pipeline integration The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision. The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator. > Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video" It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format. [0] https://en.wikipedia.org/wiki/CMS_Pipelines https://en.wikipedia.org/wiki/CMS_Pipelines
    - deleted 3y ago
      [deleted]
- didntcheck 3y ago
  Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate<File> to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around, and that resources could implement richer interfaces rather than trying to force the file IO interface on every single one, regardless of how little sense that makes Worse is Better may have been a useful expedience in the 20th century, but we're long overdue repaying that technical dept, to get back some of the rich OS/environment features that other camps had got working almost half a century ago. The first step would be to stop putting "Unix philosophy" on a throne
  - hutzlibu 3y ago
    "That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around ... The first step would be to stop putting "Unix philosophy" on a throne " Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.
    - c00lio 3y ago
      There are still tons of stringly-typed interfaces in powershell.
      - hutzlibu 3y ago
        I did not say I am a big fan of the powershell or windows in general. But I would still like the few good ideas integrated into linux ..
  - iopq 3y ago
    Unix being stringly-typed is a huge problem. For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output https://github.com/hakandundar34coding/system-monitoring-center/issues/168# https://github.com/hakandundar34coding/system-monitoring-cen... the author literally doesn't care since it works with coreutils `ps` it's a culture problem
- salawat 3y ago
  I'd recommend you not look at awk/sed then.
  - wbl 3y ago
    Awk is a real programing language (hint: who are A, W, and K) where short scripts are strings passed in via single arg. That's not find. Sed has a fairly well designed although limited interface you again pass in. By contrast find tries to have separate pieces strung together each as an argument.
floren 3y ago
I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it. On the other hand, the lack of find is not a particularly good rebuttal to the original point. If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?
- pcwalton 3y ago
  > If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched? If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.
  - floren 3y ago
    But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.
    - colonwqbang 3y ago
      It's not about "find" in particular, that was just an example brought up to illustrate the general point. If "find" was the only thing missing to bring Plan9 up to Linux usability standards, that would indeed be easy to fix.
  - randomdata 3y ago
    The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future. In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 and Plan 9 would have not been a necessary break. But then, like Plan 9, maybe Unix would have never rose up to see any widespread use to make that evolution significant. Tradeoffs, as always.
jxy 3y ago
The new kid just learned to walk(1). http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd/walk.c/f.html http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd... 329 lines of code.
- nmz 3y ago
  For nix: https://github.com/google/walk https://github.com/google/walk You can also use dmenu's stest to do the equivalent to find's -type f, { walk $PWD | stest -f }
  - jxy 3y ago
    The walk(1) on 9front seems to have grown up and supports many options: http://man.9front.org/1/walk http://man.9front.org/1/walk
doctor_eval 3y ago
Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.
- vbernat 3y ago
  Then you can use "find | grep".
  - doctor_eval 3y ago
    Find works without parameters? I don’t think that’s always been the case, and it doesn’t work on MacOS.
    - vbernat 3y ago
      In this case, "find . | grep".
jabl 3y ago
I would guess the minimalism was a practical choice at the time, given it was a pretty small team making an entire OS. Had Plan 9 ever become some kind of commercial (or even open source) success, I'm sure a find command would eventually have found its way in.
foul 3y ago
Yeah find is a bad example for bloat, compared to GNU echo or GNU yes. find AFAIK is mentioned more for horror stories, Bernstein insults, as an example for alien parts of UNIX-like OSes which prevent from a streamlined, predictable-in-your-head experience. "It isn't windows server", a statement which devoids of meaning sometimes with powershell and with Azure cloud apis, but eh.
lproven 3y ago
« To name one egregious example, omitting find(1) in favor of piping du(1) [...] to grep(1) is not an improvement » I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions. I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use. Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience. But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now. By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!) Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly. Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.) I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is. But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on Plan 9 never got that. It still revels in its 1990s-Unix weirdness. If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today. Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned. The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line. After Plan 9 came Inferno. I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is. Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago. A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented. With Plan 9, all the machines on your network with the same CPU archuitecture were parts of your machine if you wanted. (A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.) But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS. When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges. I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.
deleted 3y ago
[deleted]
rakoo 3y ago
Personal experience: find gets hard to use, and I always have to resort to piping into grep anyway. Maybe I should learn how find works; maybe I should just stick with standard tools. And if `du | grep` gets too long to type, especially with arguments, then that's where I write a script for my common use. > Rust's "fd" implementation is under 7,000 lines of code Not counting the 23.8k files, not even lines of code, of rust (https://github.com/search?q=repo%3Arust-lang%2Frust++language%3ARust&type=code https://github.com/search?q=repo%3Arust-lang%2Frust++languag...). Comparison should happen on a similar baseline

wbl 3y ago

The problem with find is that it tries to put an entire programing language into its arguments.

pcwalton 3y ago
I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.
- comex 3y ago
  That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is ls | where size > 10mb | sort-by modified It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.
  - arp242 3y ago
    zsh solves this with globbing qualifiers: ls -t *(Lm+10) "L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things). The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.
  - maleldil 3y ago
    > Nushell they didn't have scripting yet If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_101/flag.nu https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...
jrockway 3y ago
Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem. I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)
- exitb 3y ago
  Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.
  - SubjectToChange 3y ago
    …we're using insane amount of code and cpu load to solve really simple problems on daily basis. Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code. I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.
    - exitb 3y ago
      > More code doesn’t necessarily imply more resource usage. That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere. Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.
amstan 3y ago
Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.
- e12e 3y ago
  Hard to grep a list of path names for size or last modification date? When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1). And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters. However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell... https://man.cat-v.org/plan_9/1/grep https://man.cat-v.org/plan_9/1/grep https://man.cat-v.org/plan_9/1/du https://man.cat-v.org/plan_9/1/du
kristopolous 3y ago
And it makes easy things hard. All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time. Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused. Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)
- skissane 3y ago
  > and the print0 for pipeline integration The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision. The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator. > Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video" It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format. [0] https://en.wikipedia.org/wiki/CMS_Pipelines https://en.wikipedia.org/wiki/CMS_Pipelines
  - deleted 3y ago
    [deleted]
didntcheck 3y ago
Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate<File> to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around, and that resources could implement richer interfaces rather than trying to force the file IO interface on every single one, regardless of how little sense that makes Worse is Better may have been a useful expedience in the 20th century, but we're long overdue repaying that technical dept, to get back some of the rich OS/environment features that other camps had got working almost half a century ago. The first step would be to stop putting "Unix philosophy" on a throne
- hutzlibu 3y ago
  "That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around ... The first step would be to stop putting "Unix philosophy" on a throne " Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.
  - c00lio 3y ago
    There are still tons of stringly-typed interfaces in powershell.
    - hutzlibu 3y ago
      I did not say I am a big fan of the powershell or windows in general. But I would still like the few good ideas integrated into linux ..
- iopq 3y ago
  Unix being stringly-typed is a huge problem. For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output https://github.com/hakandundar34coding/system-monitoring-center/issues/168# https://github.com/hakandundar34coding/system-monitoring-cen... the author literally doesn't care since it works with coreutils `ps` it's a culture problem
salawat 3y ago
I'd recommend you not look at awk/sed then.
- wbl 3y ago
  Awk is a real programing language (hint: who are A, W, and K) where short scripts are strings passed in via single arg. That's not find. Sed has a fairly well designed although limited interface you again pass in. By contrast find tries to have separate pieces strung together each as an argument.

floren 3y ago

I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it. On the other hand, the lack of find is not a particularly good rebuttal to the original point. If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

pcwalton 3y ago
> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched? If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.
- floren 3y ago
  But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.
  - colonwqbang 3y ago
    It's not about "find" in particular, that was just an example brought up to illustrate the general point. If "find" was the only thing missing to bring Plan9 up to Linux usability standards, that would indeed be easy to fix.
- randomdata 3y ago
  The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future. In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 and Plan 9 would have not been a necessary break. But then, like Plan 9, maybe Unix would have never rose up to see any widespread use to make that evolution significant. Tradeoffs, as always.

jxy 3y ago

The new kid just learned to walk(1). http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd/walk.c/f.html http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd... 329 lines of code.

nmz 3y ago
For nix: https://github.com/google/walk https://github.com/google/walk You can also use dmenu's stest to do the equivalent to find's -type f, { walk $PWD | stest -f }
- jxy 3y ago
  The walk(1) on 9front seems to have grown up and supports many options: http://man.9front.org/1/walk http://man.9front.org/1/walk

doctor_eval 3y ago

Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.

vbernat 3y ago
Then you can use "find | grep".
- doctor_eval 3y ago
  Find works without parameters? I don’t think that’s always been the case, and it doesn’t work on MacOS.
  - vbernat 3y ago
    In this case, "find . | grep".

jabl 3y ago

I would guess the minimalism was a practical choice at the time, given it was a pretty small team making an entire OS. Had Plan 9 ever become some kind of commercial (or even open source) success, I'm sure a find command would eventually have found its way in.

foul 3y ago

Yeah find is a bad example for bloat, compared to GNU echo or GNU yes. find AFAIK is mentioned more for horror stories, Bernstein insults, as an example for alien parts of UNIX-like OSes which prevent from a streamlined, predictable-in-your-head experience. "It isn't windows server", a statement which devoids of meaning sometimes with powershell and with Azure cloud apis, but eh.

lproven 3y ago

« To name one egregious example, omitting find(1) in favor of piping du(1) [...] to grep(1) is not an improvement » I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions. I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use. Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience. But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now. By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!) Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly. Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.) I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is. But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on Plan 9 never got that. It still revels in its 1990s-Unix weirdness. If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today. Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned. The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line. After Plan 9 came Inferno. I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is. Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago. A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented. With Plan 9, all the machines on your network with the same CPU archuitecture were parts of your machine if you wanted. (A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.) But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS. When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges. I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.

deleted 3y ago

[deleted]

rakoo 3y ago

Personal experience: find gets hard to use, and I always have to resort to piping into grep anyway. Maybe I should learn how find works; maybe I should just stick with standard tools. And if `du | grep` gets too long to type, especially with arguments, then that's where I write a script for my common use. > Rust's "fd" implementation is under 7,000 lines of code Not counting the 23.8k files, not even lines of code, of rust (https://github.com/search?q=repo%3Arust-lang%2Frust++language%3ARust&type=code https://github.com/search?q=repo%3Arust-lang%2Frust++languag...). Comparison should happen on a similar baseline