Comment by bmitc | Hacker News Reader

Comment by bmitc | Hacker News Reader

Parent Full thread

This article just keeps repeating the two concepts of Unix technology and Unix ideas but doesn't clarify what they mean by either. The links, seemingly complaining about iOS or Android, don't really seem to clarify.

It seems many want Unix technology or ideas to be about what Unix meant in the 70s and 80s and don't have much interest in moving things forward from that plateau. (To be clear, I think all the major operating systems of today leave a lot to be desired, but each one has their own pros and cons.)

Aside from the file system parts, my understanding of the idea of Unix is that it is a bunch of small utilities interacting with each other. I think almost anyone agrees with that idea, see functional programming and node based tools that link up data between dedicated functions and nodes, respectively. This idea is quite pervasive, and I don't think it was necessarily Unix that conceived of it. But in reality, the implementation of this idea in Unix leaves a lot to be desired. The collection of utilities that have very few standards in interfacing, documentation, naming, usability, and more importantly, data structures leaves one wanting. The idea that everything should be text is implicit and highly limiting. This is why programming languages that are somewhat OS-like and have their own scripting are so well liked, becuase it removes the need to worry about the various OSes' implementation of these ideas, leaving one to stay at a virtual machine level. For example, Elixir and the BEAM.

It's typically viewed as blasphamous, but I think the PowerShell model is the more powerful one if we're just considering OS-level provided interactions. But even then, restricting oneself to the terminal is limiting. I find the ideas in Smalltalk to be much more powerful and forward thinking, despite being as old as Unix itself.

The communal spirit of Unix as described by Ritchie back in the day revolves around minicomputers (aka PDP-11) shared in a single organisation, accessible via multiple terminals. A close community of users would log into the system and would eventually come up with their own small tools for a particular purpose. Those oddly-named tools would be adopted by the small community without need for extensive documentation. This is the "Unix spirit" of the 1970s that everyone seems to be referring to.

I agree, PowerShell does the same thing better.

And I'm disappointed that things have stagnated so much. I mean, cool, a commandline is an useful concept that sometimes fits a given task excellently well. But why in the hell are we still emulating a VT100? How is a modern Linux console sticking to a 50 year old level of functionality?

And why are we scripting in something as painful as Bash?

I agree with what you've said here and in other comments. Terminals are useful, to a degree, but there's so much fruit to be had. And I don't see why we need to be stuck in terminals (I guess terminal emulators is more accurate) as the primary mode of interaction.

Warp is interesting enough, but it's a shame it isn't cross-platform to begin with, and I'm dubious about the business model of a terminal product. I think the best hope is that they're purchased by Microsoft, and it gets integrated into VS Code. It also continues to lean into the terminal idea, although it does approach it from scratch, which is nice.

https://www.warp.dev/

I think the idea of notebook type interfaces is perhaps underrated for scripting purposes. Microsoft's Polyglot Notebooks and .dib format addresses this.

Terminals are a central idea affecting Unix process control and hierarchy, and signal delivery. Emulating them was the easier decision that didn't require any changes to the rest of the system. You introduce a virtual terminal device and the rest stays the same. We are still trapped in those basic abstractions of the 1970s without even noticing them, building shiny stuff on top.

I mean, sure, terminals make some sense.

But why are we in 2023, and people are still coming up with fancier versions of "top" that try to draw graphs in text? Every modern computer boots to a graphical console. Every terminal emulator in a GUI runs in a graphical environment. Wouldn't be be much nicer and much less awkward to actually use pixels?

Reducing everything to a monospaced text character is a beautiful and simplifying constraint, IMO. It gives me as a user a sense of predictable consistency that I really appreciate.

Because the UNIX terminal model is mostly "good enough" (and with a recent incarnation like zsh plus Fish-style autosuggestion-plugin the user experience is very different from a plain VT100 terminal from the 70's).

PowerShell isn't such a big revolution in user experience that it justifies switching IMHO (and FWIW I don't agree that objects are better than a plain text stream, at least not when the whole thing stops in the terminal - it would probably be different if every Windows application - including all UI applications - would expose their internals as "PowerShell-scriptable objects", then we could probably get an actual productivity jump by glueing small, specialised UI apps together - this was a central idea in the last days of the Amiga which didn't make the jump to other platforms before its demise).

Same for the concept of a hierarchical filesystem. Sure, there may be better ideas floating around, but when confronted with reality they are usually not so much better than the "good enough" status quo that current operating systems have arrived at.

TL;DR: long-term incremental progress usually beats revolutionary ideas that are poorly executed.

Powershell is immensely better. It takes what Unix promises and delivers it, without all the pain.

Eg:

    C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate.Subject
    CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
    C:\Windows>

Think of doing that in classic Unix. How does that command output a tree shaped structure, where items have sub-items? How do you parse that? How do you make sure that your parsing doesn't get confused by the presence of an unexpected = or :? How do you deal with that maybe some certificates have extensions?

Oh, we actually have commands that do that sort of thing, GPG does it.

    $ gpg --with-colons --list-keys \
          --with-fingerprint --with-fingerprint wk@gnupg.org
    pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
    fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
    uid:f::::::::Werner Koch <wk@g10code.com>:
    uid:f::::::::Werner Koch <wk@gnupg.org>:
    sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
    fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
    sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
    fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:

And it's awful. It's colon separated, so I'm not sure what happens if somebody puts one in their name. And you have to count fields. And it's completely non-extensible, good luck inserting an extra column. But hey, you can parse that with AWK.

Point taken, but there's nothing prohibiting commands from outputting their data in a different text format that's better suited for tree-like data (like JSON), and another set of minimal commands which processes JSON-formatted data - easy extensibility by the user is also part of the "UNIX philosophy".

That's also the point where I'd reach for Python or Deno/TS to write such command line tools, because both Bash and C are not really well suited for text processing - and neither are the traditional UNIX tools like sed or awk IMHO.

JSON would be better, true, but PowerShell actually has objects, so dates are actually dates and not just a string containing a date. So you can actually do timezone conversions and calculations on what you get directly, rather than having to feed the date string into a parser.

But yeah, JSON would be a good start. But for some reason there seems to be little interest even in that. Wouldn't it be nice to have `df --json` or `mount --json`?

And that makes me sad, because the system could be so much better if it moved forward a bit instead of being stuck in the 80s.

Honest question: How do you do discovery on PowerShell objects?

That is, with the Unix approach, when I'm trying to do something ad hoc I can do one step of a pipe, read the results on the terminal, see what the format is, and figure out how I have to set up the next step of the pipe. How do I do that with PowerShell?

Pipe it through Format-List:

    C:\Windows> Get-Item .\explorer.exe | Format-List

This gives you the generally useful view of what Get-Item returned. You can ask to see everything with:

    C:\Windows> Get-Item .\explorer.exe | Format-List -Property *

Tab completion also completes these. Some of what you get can be subdivided further if you look, eg:

    C:\Windows> (Get-Item .\explorer.exe).VersionInfo.FileVersionRaw | Format-List -Property *

Use Get-Member. For example, to find all available properties of the service object:

     Get-Service | Get-Member

Also, Format-List and ConvertTo-Json can show you a lot of details

This is the downside of organic growth.

It gave me the "What did I just read?" feel.

Reply on news.ycombinator.com