Forgot your password?
typodupeerror
GUI OS X Unix Technology

Imagining the CLI For the Modern Machine 317

Posted by CmdrTaco
from the now-that's-cool dept.
scc writes "TermKit is a re-think of the storied Unix terminal, where human views, input and data pipes are separated. Output viewers render any kind of data usefully. It may not be a new idea, but it's certainly a new take on it." I know you are quite comfortable in your shell of old, but this sort of thing sure gets my juices going. The best of both worlds.
This discussion has been archived. No new comments can be posted.

Imagining the CLI For the Modern Machine

Comments Filter:
  • Mac only. (Score:4, Interesting)

    by The MAZZTer (911996) <megazzt.gmail@com> on Thursday May 19, 2011 @01:30PM (#36181736) Homepage
    This saddens me, I would so want Windows and Linux ports. There's a brief mention that it should work with a normal web browser, and it appears to use node.js, but I am unsure what exactly to do. I haven't done any coding with node.js.
    • Re:Mac only. (Score:5, Informative)

      by The MAZZTer (911996) <megazzt.gmail@com> on Thursday May 19, 2011 @01:39PM (#36181896) Homepage
      Addendum: I think I figured it out. After reading the instructions more carefully I assume there are client and server portions, and it's the client portion that is mac-only, and that a WebKit browser should work there. The server portion is pure node.js stuff and the node.js runtime is cross-platform.
      • by fusiongyro (55524)

        That's my understanding as well. Furthermore, we should be able to take it and run the backend on remote servers with differing OSes.

  • Advantages of CLI (Score:4, Insightful)

    by Ironchew (1069966) on Thursday May 19, 2011 @01:36PM (#36181836)

    The big pros of a command line:
    -Very low resource usage
    -Automation via scripts

    I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing. If you need interactivity, the GUI can handle that. It seems to me like this new interface will suck up too many resources doing something that admins won't be staring at.

    But it's worth a shot. ;)

    • This looks cool when everything works, but what happens when you try to `cat` a JSON file with a syntax error? Terminal is already lowest common denominator. If you want a better/easier/user-friendlier way, they're out there, but it seems like doing it in the terminal layer is wrong.

    • by gstoddart (321705)

      I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing.

      Not so much that I don't have to look at it, as that it lends itself very well to scripting and automation ... automation is good because it removes human error from it. The tools were modular enough that you just build what you needed as you went.

      Once it's automated, you don't need to look at it I guess. But, certain kinds of chaining of operations based on the output of the previous

      • by socz (1057222)
        I also think he's onto something great. I've written scripts to add color to my console and found out after doing it for every program that you can handle that all in a few files. What he's done though, is done that for text and everything else. It looks very promising and I would be willing to give it a go when it's ready.
    • by immakiku (777365)
      It's also speedier than the full blown mouse-driven GUI. This retains that one. Also ls/grep for navigating is sometimes better/sometimes worse than folder with icons for navigating. This seems to allow you to mix the two. I think the idea is very nice and can probably be tweaked to make it a viable default CLI.
    • It's not a question of whether or not the command line terminal can do the same things, it still could, it's a question of how you build those terminal scripts.

      SQL Queries for instance are pretty obtuse but there are some great tools to help you build them with interactive results.

      Why I can't for instance just type ' Move "//path/file.ext" to "//newpath/" instead of mv etc... boggles my mind.

      Sure mv is shorter. But why not offer an 'easy' path for those who don't have the shortened commands memorized? Is

      • by gstoddart (321705)

        So, you'd like someone to write a natural language shell where you can describe what you'd like to happen, possibly badly, and the shell would magically know what you mean and do the right thing?

        I can imagine such a system either completely failing to do what you wanted, or completely getting it wrong and messing things up ... so far, we're not so good at writing natural languages to tell computers how to do things.

        It actually really is hard to just ignore the "to" and assume that you meant to type "move" (

        • Re:Advantages of CLI (Score:4, Interesting)

          by gilleain (1310105) on Thursday May 19, 2011 @02:25PM (#36182518)

          So, you'd like someone to write a natural language shell where you can describe what you'd like to happen, possibly badly, and the shell would magically know what you mean and do the right thing?

          COMPUTER : ENHANCE!

          Also, applescript is where people should go for "move file 'myfile.txt' to directory 'somedirectory'". Ok, so not exactly that syntax, but still.

      • why not offer an 'easy' path for those who don't have the shortened commands memorized?

        Because you would be encumbering every one with a verbose syntax. After just a few times you'll feel it quite easy to remember that 'move' is 'mv'.

        Once you learn the short way to do it you don't want to spend the extra effort in the long command. You may think it only takes one second to type, but you forget how many thousands of times you'll be using the same command again in the future.

      • by camcorder (759720)
        How do you plan to i18n that thing than? It's ok for English, and even English might lack form in some phrases. Shell has its own language, and it's not a natural language. Whatever tongue you have, you can learn this language, but if you add natural languages into the equation, then you create a big chaos, since you need to implement syntax differently for vast majority of nations. Otherwise while it wouldn't boggle your mind, it would boggle mind of someone else.

        I hope this explains it for your.
      • by arth1 (260657)

        Is it really so hard to ignore the "to".

        Without breaking millions of existing scripts, yes, it is.

        Remember that files and folders may be named to too.
        "mv 2 to tutu" means move "2" and "to" into "tutu".

        What you need is your own command set, and nothing stops you from making that. Just don't name them the same as existing utilities.

      • "Sure mv is shorter. But why not offer an 'easy' path for those who don't have the shortened commands memorized? Is it really so hard to ignore the "to". It helps people interact with the computer more naturally and it takes an extra 1 second to type. It takes me more than a second to remember mv.

        But what if your two files are named "move" and "to"? Then you'd have :

        move move to to

        And that would just be confusing.

      • Two historical thoughts:

        There was a bunch of related research done at Bell Labs (around the same time that UNIX was coming out of the research organization) about command line interfaces. The conclusion was that there were two largely incompatible demands. Beginners wanted verbose languages and menus from which they could pick options. Experts (eg, those who had to use the system for hours every day to do their job) wanted minimalist interfaces that used as few keystrokes as possible.

        Many of those ear
    • I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing

      Some people (like me) prefer it because they can type known commands faster than they can navigate a series of menus. This would be a great addition to currently available terminals for folks like me. I would enjoy the extended graphical capabilities while still being able to type commands.

      Note I said 'addition' - I sure as heck want my old-school terminal around at times. The densi

    • I think the whole point from the author is to value all these pixels on his screen. That is the rational behind his article. Personnally, I just don't care wasting pixels on my screen as long as the job is done efficiently, what the command line most often does just fine with great flexibility and many options for those with enough knowledge of the Unix shell and all the powertools coming with it.

      So, my recommendation to this guy would be to buy himself a cheap dumb ASCII terminal and stop whining about w

    • by seifried (12921)
      Other advantages are that the CLI works well over serial lines and SSH, especially low bandwidth and/or high latency connections (you can cut and paste a set of commands and just wait for them to return). Graphic interfaces suck really bad over low bandwidth/high latency (mouse jitter, did I click where I meant to click? did it register the click?). Plus the whole automation bit.
    • by Alef (605149) on Thursday May 19, 2011 @02:55PM (#36182936)

      You missed the biggest pro of them all, central to the Unix philosophy: Composition of simple tools to do complex tasks.

      With a GUI, you are bound to whatever the GUI designer has included, and basic features are replicated endlessly in different GUI:s. For example: If I want to process five files with some program in a command line, I can list them with ls or find, type them manually, or cat the list from a file, just to name a few ways. With a GUI, you often have only the Open File Dialog, built right into the processing program, and that's it. In that case, creating the list of files is not separated from processing them.

      • +1 for you

        And it is written in/uses java/javascript?

        Let me get this straight. He doesn't like wasting pixels. So, he re-imagines a time tested tool that uses MORE pixels to display the same data. Now it does display non-text in the terminal, but why? If you already have a GUI (which you must for this CLI) why not "xdg-open FILENAME" instead of "cat FILENAME"? And it wastes CPU cycles with a pointless java abstraction when it could run on the bare metal.

        All I see is it doing is the exact opposite
  • Style over Substance (Score:4, Interesting)

    by spun (1352) <loverevolutionary@@@yahoo...com> on Thursday May 19, 2011 @01:36PM (#36181840) Journal

    RAM and bandwidth are cheap, why not add tons of bells and whistles? They may not make anything more functional, but they make it more fun, and that's what counts, right? Oh, it's only for Mac? Well that makes perfect sense.

    • by outZider (165286)

      If you read carefully, it runs on WebKit, but uses OS X to show it off. They've already got it working in a browser, some enterprising soul will just need to generate a small WebKit component to run it on another OS.

  • ...can I just get ncurses capability in my bash shell, so it will respond to mouse clicks?
    • by Aladrin (926209)

      That sounds like a good project... If you spec'd out the usage, you could probably get someone to hack it in.

  • Forgive me, but I just don't see the "usability" aspect. How is this more "usable" than what I have now? What the author calls "raw" data, I call data. To me, that is WAY more usable than what the author has posted.
    • by Tikkun (992269)
      But they can cat an image and see a picture of a cat with a caption! That is totally more usable! ;)
    • by grumbel (592662)

      What the author calls "raw" data, I call data.

      I call it a mess of in-band-signaling. Simple example, how many files do you see here:

      $ ls
      test test test

      That are two files, not three, one is called "test test". The "data" contains no actual information to tell you that, that information got lost while converting it to plain text. With an advanced shell those wouldn't just be letters on the screen, but actually objects that you can click with your mouse, pipe into other applications, pipe into a file and do other things with it, while still have the she

  • by MarcQuadra (129430) on Thursday May 19, 2011 @01:37PM (#36181850)

    I like some of this idea, but frankly, it doesn't go far enough. Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

    I would pay good money for a PowerShell implementation on Linux, and even more if Linux internals were exposed in the same way that WMI objects are on Windows.

    And this is from a thirteen-year Linux veteran.

    • by Microlith (54737)

      Or instead of implementing a new language on Linux, how about doing something like a ruby or python shell, with a linux-specific library?

      I mean, if you really want to hide all the information in an unbrowseable, non-human-readable object space instead of via a filesystem (where you can at least poke around manually,) there are ways to do so with existing technologies (since it's nothing new on Linux, but shiny new on Windows.)

      • by hedwards (940851)

        I'm trying to figure out what precisely is wrong with the "everything is a file" philosophy. Seems to me that it's still around here after all these years and still works well, that it's probably doing something right.

        • Seems to me that it's still around here after all these years and still works well

          That argument doesn't work though. I assume most people here think Windows doesn't "work well." Well, it's still around here after all these years, too... ;)

          "Everything is a file" may be fine. Who is to say something better can't be made? Maybe everything-is-an-object allows for something better... that doesn't mean everything-is-a-file is wrong. Just maybe it can be improved or a new paradigm can be used.

          • by hedwards (940851)

            The argument works, Windows for a long time wasn't as good as the competition and it was very clear to anybody that had used anything else. The only people who thought that it worked well were individuals who didn't actually have to fix it. I remember times when the CDROM would inexplicably disappear or the monitor resolution could only be changed via a registry tweak which would have to be applied every time the computer loaded. Fixing those sorts of problems shouldn't even be necessary. Consequently, I ha

          • by jbengt (874751)
            Everything is a file, including every object.
            Everything is an object, including every file.
            No difference, except in syntax .
        • by fusiongyro (55524)

          You should see it under Plan 9 [bell-labs.com], where literally everything is a file, even things like windows, hardware, network connections, etc.

    • Agreed... PowerShell is how a consistent command line interface should be done. Piping objects it's a joy instead of dealing with spacing and grep-everything...
      You can even have them being human readable for all those object-scared-people out there. Or hey, lets implement the same thing in python or ruby. Lets begin from 0. If you want all to be a file, so lets be it but at least that the commands have options and structures consistent between them. I hate all those arcane command line options that are not

      • by profplump (309017)

        What happens in PowerShell when that object you're piping out of program 1 isn't one of the supported object types in program 2?

        • by jandrese (485)
          You have to convert them down to text or octet streams I think.

          I tried Powershell a few times, but it seems like if you're not already up to your nose in .NET it is pretty hard to use and wildly verbose. It also seems like it was a little painful on the commandline, more of a scripting language than a shell. I felt like I would need an IDE with autocomplete to really get anywhere in it.
      • by oakgrove (845019) on Thursday May 19, 2011 @03:27PM (#36183322)

        Piping objects it's a joy instead of dealing with spacing and grep-everything...

        I like grepping. Its regular expression syntax gets me exactly what I need everytime and since I actually took the time to learn how to use it, it's like second nature.

        I hate all those arcane command line options

        They may be arcane to you that doesn't mean they are arcane to somebody else. PowerShell is extremely verbose compared to Bash. That seems pretty arcane to me.

        ("ps aux" and "ps -aux")

        Kind of a silly quibble there.

    • Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'

      The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them. With plain text you can see the data structure at a glance, you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

      Plain text is output to the screen and input from the keyboard. Any program that writes text to the console can send data to any program that reads text from the keyboar

      • Re: (Score:2, Informative)

        by Anonymous Coward

        'Objects' have this terrible problem that you always need a specific program to read and write them.

        Except that in PowerShell all of the objects are reflective and automatically have a textual representation, even if one is not provided by the author.

        With plain text you can see the data structure at a glance, you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

        Being reflective you can also see the data structure instantly, clearly defined by type, even if t

      • by benjymouse (756774) on Thursday May 19, 2011 @03:27PM (#36183316)

        The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.

        Not true. Objects can be rendered on the terminal as well. PowerShell does this all the time. For some object types a certain format/method has been registered, but for all other types PowerShell just falls back to default rendering - which is to render the properties. You don't need *any* specific program to write objects in PowerShell. Never. One distinct advantage of this is that you can actually *choose* exactly how you want the objects written without relying on each and every little CLI tool to include a whole battery of output options.
        ls|ft lists files/dirs in a table (ft is alias for Format-Table): Each property in its own column.
        ls|fl lists files/dirs in a list (fl being an alias for Format-List): Each property on its own line.
        ls|fw lists files/dirs in "wide" format (fw is an alias for Format-Wide): Multiple columns with just the name.
        The cool thing is that ps|fl works similar: It lists processes with properties on separate lines.

        you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

        PowerShell builds upon .NET, COM and WMI, which are all models which supports discoverable objects. One of the first cmdlets a powersheller learns is the gm cmdlet. gm is an alias for Get-Member. This cmdlet reflects and documents the types with properties, methods, events etc of the objects piped to it on the command line. No need for external out-of-date documentation.

        This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.

        Well, that is the same way with PowerShell. Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal using the default or registered format (or you can control the format). But PowerShell takes it a few steps further, e.g. defining common infrastructure for transactions as well as risk control such as executing all cmdlets in simulated "whatif" or "confirm" mode in a unified way and based on context so that cmdlets executing within a script will inherit the mode from the script invocation. The fact that *all* cmdlets support the -WhatIf parameter lets you try out even potentially state-changing scripts and cmdlets before actually executing them.

        I don't think powershell offers any advantage over the way Unix has been working for forty years.

        Frankly, based on the above it doesn't seem like you know enough about PowerShell to pass that judgement. And having worked for forty years doesn't mean that it cannot be improved. I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.

        • by mangu (126918) on Thursday May 19, 2011 @04:18PM (#36183990)

          Objects can be rendered on the terminal as well

          Rendering them is different from the object itself.

          Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal

          Again, rendering is not the object. I can have a list of different operation I need to do, passing things from one program to the other. If all I can see is the rendering of the last command I cannot see what is actually being passed from one command to the next one.

          Developing is incremental. The power of Unix is that this simple fact is everywhere. I need to see all the processes:

          ps aux

          Which ones are owned by boris?

          ps aux | egrep '^boris'

          What are the process numbers and creation time?

          ps aux | egrep '^boris' | awk '{print $2, $9}'

          OK, sort that by process number

          ps aux | egrep '^boris' | awk '{print $2, $9}' | sort -n

          In Unix I build up my commands step by step. What I learn in one place can be used somewhere else. The same sort command I use for process numbers is the one I use for my phone book.

          If I can't remember exactly how awk works I can test it by typing

          echo "1 2 3 4 5 6 7 8 9 10 11" | awk '{print $2, $9}'

          It would not work if 'echo' showed a representation on the terminal that is not exactly the same thing it pipes to 'awk'

          I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.

          That's a shortcoming of windows, not an advantage of powershell.

          • by wasabii (693236) on Thursday May 19, 2011 @04:58PM (#36184508)

            Every example you just posted requires you to actually examine the output of each of the commands, and apply brittle and convolted text parsing structures like grep and awk. All of if these break when the author alters the output text format. PowerShell has none of those limitations. If an author of ps adds a new property to each object, he does not need to be concerned with previous users of his cmdlet, because nobody is actually parsing his output. His output is strongly typed objects. If a previous user didn't consume his new property, it doesn't matter, they'll continue to not consume it.

            Instead of building scripts based on brittle text parsing, they are built on a self documenting model that provides. There is no text parsing. That's extra work. Why do it?

    • I'll continue this because powershell cmdlets have a general standard.

      The whole verb-objectype syntax is pretty cool...but not really needed in the linux community, but what is cool is that they all behave the same way.

      Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

      It

      • by jpate (1356395)

        Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

        here you go [debian.org]. Try typing "ls -" then push tab twice. magic!

    • by fusiongyro (55524)

      I agree that that would be cool, though I consider this fundamentally different. But I don't think we're going to see a useful PowerShell for UNIX simply because in UNIX the only thing you can rely on is files. There is no inherent object model underneath everything that you can tie everything together with. On Windows, particularly since reinventing everything with .NET, there is usually an object model underneath, so it makes sense to reimagine the shell from an OO perspective (not too OO though, or it wo

    • by waveclaw (43274) on Friday May 20, 2011 @12:31AM (#36188196) Homepage Journal

      . Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

      It is pointing out the obvious that a file is kind of object, with a certain defined behavior, strong namespaces and associated methods?

      Systems like Plan9 [bell-labs.com], where everything literally is a file make the painfully obvious. The only changes would be to make file properties be just more files that appear to live bellow the filename as if it were a directory and get rid of completely foreign namespaces like the network interfaces.

      There is some extra syntatic sugar with object systems. The 'object' systems use dot delimited dereferencing for system enforced sub-classing - runtime resolution of the thingy being talked about. The file system's path separators are only meaningful on the filesystem meta-level for object...er...file isolation. Otherwise we are dithering over path separators to namespaces: /path/to/thingy instead of container.subelement.thingy.

      Of course, PowerShell has the advantage of an actual design and uniform implementation. Even the traditional Unix utilities produce completely unique output formats that often require regular expressions to pull out meaningful data or at least massage the pipe. This is a possible consequence of unregulated organic growth.

      Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output. Instead make STDOUT,STDERR (FD 1 and FD 2) machine-only and FD 3 and 4 be used for human-consumable output. This could be much more flexible. (Of course, like most standards, nobody would have used it in the sake of rolling the next great thing.)

      But this highlights that trivially parsable output combined with pure file semantics gives you the benefits pure 'object' environments like Powershell gives to users. So it appears the inconsistency between terminal applications is the real issue, not some mythical object-ness that Powershell proponents claim files don't have. And TermKit's plugins / adapters "fix" that.

      After all, what are programing languages but syntactic sugar in our heads, mere mental layers on top of high and low voltages running through some hardware?

  • by Haedrian (1676506) on Thursday May 19, 2011 @01:44PM (#36181932)

    The Simple solution in my opinion is to simply have the GUI windows, with a section at the side for terminal.

    Whenever the user ls (or dir)'s from the terminal, the GUI changes. If you click on something in the GUI, the terminal automagically puts in the exact path to the object in the GUI.

    Best of both worlds, might be fun to do.

    • I'm fairly certain you can (could?) do this in KDE, but it may have been a Konq feature that never made it to Dolphin
  • But if we moved to this model, how would I give tips on climagic [twitter.com]? I'd start having to post links to screen shots. I kid. Sounds like this guy is trying to turn the command line into the multilayer net with protocols between the programs.

  • WHOOOOSH! (Score:3, Insightful)

    by blair1q (305137) on Thursday May 19, 2011 @01:54PM (#36182074) Journal

    "You can cat a PNG and have it just work."

    Uh, no, Doctor Disorthogonality, you broke it. When I cat a PNG I want to see the bytes, not a picture. If I want to see the picture I'll firefox or gimp the PNG, then it will just work.

    And fixed-width fonts for data are ideal. Using a variable-width font and trying to od anything is a freaking nightmare.

    • by he-sk (103163)

      Especially, when you can simply `open` it on a Mac (opens in Preview.app) or `display` it on Linux (using ImageMagick). I just tried it, by catting a PDF file and that turned out to be rather annoying, because it broke scrolling in the terminal window.

      Some of the features are nice, for example the filename completion (way better than pressing tab). But it's missing automation, so basically it's useless.

    • by yarnosh (2055818)
      I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.
    • by bobetov (448774)

      Whoosh back at you. cat a png, and the *data* is bytes. The *ui* is a display based on the type of data being shown - in this case, an image.

      That's really the core idea - separating what data-centric tools see, and what users see.

    • by Guy Harris (3803)

      When I cat a PNG I want to see the bytes, not a picture. If I want to see the picture I'll firefox or gimp the PNG, then it will just work.

      And fixed-width fonts for data are ideal. Using a variable-width font and trying to od anything is a freaking nightmare.

      If by "od" you mean the od command, trying to od anything involves piping it to od. When I cat a PNG I usually type ^C pretty quickly; if I want to see the bytes I'll pipe it to, err, umm, od.

      But, yes, there are places where variable-width fonts are suboptimal, even in pure GUI apps; Wireshark would have to do a bit more work to ensure, for example, that the entries for bitfields within a byte/word/etc. line up when using a variable-width font. In a world with variable-width fonts in the terminal emulato

    • by mr_da3m0n (887821)

      Just being devil's advocate here, but did you actually read the article? Only the view intereprets the bytes which makes sense. If you pass it over a pipe, bytes are sent. I think that is what you meant, because no one actually like cat'ing a PNG in their terminal to see a bunch of garbage that may even break the terminal until you reset it. Or maybe that is a very obscure use case you have?

      He separates view from data. Which is okay. Not something I particlarily like or find it useful, being a unix greybear

    • Re:WHOOOOSH! (Score:5, Interesting)

      by Novus (182265) on Thursday May 19, 2011 @04:11PM (#36183916) Homepage

      In practically any sane terminal emulator, you're not seeing the bytes, you're seeing a picture generated from these bytes by interpreting it as text with embedded control codes. This is merely an extension of that concept; instead of just "clear the screen" and "switch text colour to red" you also have "display the following PNG". Considering that there are tons of different sets of escape sequences in use, one more would hardly be a problem. Since the author suggests that the metadata identifying the data type (MIME-style) would be separate from the actual data, legacy programs would presumably just ignore the additional information and behave like they used to.

  • by VortexCortex (1117377) <VortexCortexNO@S ... t-retrograde.com> on Thursday May 19, 2011 @02:16PM (#36182384)
    From TFA, (WRT why terminal interaction is flawed):

    This has lead to "somewhat parseable text" being the default interchange format of choice. This seems like an okay choice, until you start to factor in the biggest lesson learned on the web: there is no such thing as plain text. Text is messy. Text-based formats lie at the basis of every SQL injection, XSS exploit and encoding error. And it's in text-parsing code where you'll likely find buffer overflows.

    ?
    Thus says the guy who's implementing a HTML5 + CSS + JS client / server terminal wrapper. Hey, FYI, your whole TermKit stack is made of parsed text. Indeed, the only way to access your API is via parsed text. As if Webkit (that TermKit is build on) never has any "buffer overflows". Pffffft. Added complexity, more surface for bugs to appear, 'nuff said.

    Also -- No thanks. I already have a window manager. I agree that occasionally mouse input is the right choice, and an environment that embraces both text terminal and GUI elements is neat, but I just couldn't stand to read any more of the Hypocritical remarks...

    He talks about displaying objects and passing them around as JSON objects -- Yeah, JSON is a textual representation of an object that must be parsed to be displayed.

    P.S. Only available on Mac? What the duce? It's just a HTML / CSS + JS interface -- If the guy had any brains you could just point any browser at it and he'd have saved the time of writing a complete client... unless... the goal is to take some elitist (noob) stance regarding UI.

    More "Text is Sloppy" hypocrisy:

    TermKit's input revolves around tokenfield.js, a new snappy widget with plenty of tricks. It can do auto-quoting, inline autocomplete, icon badges, and more. It avoids the escaping issue altogether, by always processing the command as tokens rather than text. Keys that trigger special behaviors (like a quote) can be pressed again to undo the behavior and just type one character.

    The behaviors are encoded in a series of objects and regexp-based triggers, which transform and split tokens as they are typed.

    Uhhhggg.

  • I don't understand why there is such a push to use grids to display sorted lists. Unity, Gnome 3, Android, Windows Explorer, iOS, MacOSX, etc. (even posix CLI commands such as ls): all of them have default settings to take a list of elements and then break the list up into meaningless rows and display a grid. I find it far too easy to miss important elements in these grids and I observe this behavior in others. Why are grids so damn popular?

    Note that in this instance I am not complaining about grids where t

    • by Hatta (162192)

      This is absolutely correct. It is easier to find an object in a 1d list than a 2d matrix. With a list, you start at the top and move down. You are guaranteed to find your item. With a matrix, you have to reposition your eyes frequently.

      Sorted lists are objectively better for usability. Period.

  • by bl8n8r (649187) on Thursday May 19, 2011 @02:24PM (#36182506)

    I like the simplicity of Xterm. It works well with SSH, can talk to endless serial devices (like console terminal login on headless stuff) and can run over a modem. All I need is twm and Xterm and I have a nice lightweight X desktop on a server for installing Oracle. There aren't a lot of dependencies so I can keep the software footprint small. Updates are faster and few.

    Now in KDE on a desktop, something like Termkit might be more practical. Don't forget though, eye-candy comes at the expense of resources. You can't have all that bling without giving up cpu or ram. In the end, is the payoff worth it to be able to run a screensaver in your terminal?

    All the work that went into the Compiz bling; it's cool but I just don't use it. The exploding windows are neat, I just don't see the point in having a desktop that contributes to my distractions.

  • This seems to be completely the wrong crowd for this development (it is hugely upvoted on Reddit, though), but one reason this may be an improvement is simply that it can combine the speed of writing a command-line program with the visual appeal of a web or GUI application. Speaking personally, there are many times I write a command line program simply because I don't want to invest the time and effort in a GUI program and a web app just isn't appropriate for the task. With this system, I could just output

  • Unix is meant to be difficult - it keeps idiots out of the datacentre.

    Ha ha, only serious.

  • The reason terminals are so useful is because they have greater usable information density than really any other interface. The article desperately misses this in its lead about the 2.3 megapixels of display space, and the presumed potential information content. But a terminal has quite a lot of information in it! Far more information--from a human usability POV--than the oversized icons this TermKit uses to adorn every small bit of textual information.

    For example, on my MacBook Pro, using a pretty large

  • by gilgongo (57446) on Thursday May 19, 2011 @05:22PM (#36184774) Homepage Journal

    I've often wanted to have a CLUI that works with my GUI. Imagine I'm in Photoshop, mousing or tablet-ing away, and I have a layer on my canvass. Rather than trying to remember where in the menu structure a bunch of commands are in order to manipulate that layer, I just bring up my CLUI and type something like "resize 50%, flip, gamma -20" Or how about in Word: "Find foo replace bar, insert header from page 2-", and so on?

    Why are we forced to find commands in mouse-driven menu bars (of worse, "ribbons" and whatnot) when they could be available any time in the app you are using?

"Of course power tools and alcohol don't mix. Everyone knows power tools aren't soluble in alcohol..." -- Crazy Nigel

Working...