7 ms·

There's literally nothing about this I like. A terminal with a gradient background might look pretty for screenshots, but for long sessions it just adds to fat

There's literally nothing about this I like. A terminal with a gradient background might look pretty for screenshots, but for long sessions it just adds to fatigue and makes text harder to read. "Saving your favorite commands" in a normal terminal involves writing an alias into your rc file, not a bunch of button clicks. Same goes for the whole "interactive flags" thing. Whoever made this clearly hates the terminal and wanted to bring a hipstery web 2.0 approach to the terminal. My question is, WHY? Oh, and it's PAID? Fuck that. Learn to use a proper terminal or don't bother, simple as that. That isn't me being a crotchety old timer, that's me giving you serious life advice. You will always be faster in the terminal if you learn to use it properly. a 2 hour tutorial in shell scripting and learning to use `man` is worth far more to your career than 10 bucks. Learn it the right way if you're going to bother. </rant>

benbenolson 10y ago
I agree with each and every one of your comments; in addition, I would like to know how this project was created: what language it was made in, why the author found it necessary to create it, etc.
- guessmyname 10y ago
  > what language it was made in HTML + JavaScript + Electron Just download that archive, extract its content, and you will find the "goterminal" script that is basically an ASAR archive [1] with a copy of CEF [2] as the webview for the web application that they (for some unknown reason) decided to create. [1] https://github.com/electron/asar https://github.com/electron/asar [2] https://bitbucket.org/chromiumembedded/cef https://bitbucket.org/chromiumembedded/cef
  - mrmondo 10y ago
    Oh god, the last software I'd want to be running a terminal in!
  - placeybordeaux 10y ago
    Yikes. Thats a great way to make a terminal into a memory hog and unresponsive under load.
    - KirinDave 10y ago
      Oh? Historically most terminal implementations have been fraught with performance issues. We'd moved off xterm to aterm and then back. We'd been hesitant to adopt gnome-terminal because of the GTK+ chrome then saw its font kit actually rendered faster. What most people don't get is how absurdly well-optimized the text rendering and reflowing is for web browsers. With care, people can get modern cellphone browsers to hit 60fps animations and reflows while pushing huge volumes of text through them. Take any 3 GUI toolkits you can name and ask yourself, "Do all three of these combined have a maintenance budget that equals that of even Firefox by itself, let alone any TWO modern web browsers?" Hell, some of the most cutting edge research into interpreters and garbage collectors is coming out of Google making V8 fast. Quite frankly, I'd bet that with care and foresight this could be faster than iTerm.
      - placeybordeaux 10y ago
        Maybe I am wrong, but I have yet to see a modern browser take anywhere near as little memory of CPU as a modern terminal emulator. There is also the matter that no matter how much optimization you put into something you can't recoup the cost of the fundamental design choices you went with. Choosing something with less power can solve a lot of headaches.
        KirinDave 10y ago
        > little memory of CPU as a modern terminal emulator. Browser instances can be quite svelte. But uh... I mean... shared lib pages tend to be actually shared pages. That's why the physical memory for multiple browser instances is a lot lower. What's more, I'd gladly pay a higher price for a richer experience. We no longer need to or should rely on ANSI interfaces. In fact, they're becoming increasingly awkward in a world that really wants endpoints to be stateless by design rather than stateful sockets. Many people have already discarded the single socket model oh SSH in favor of Mosh. Let's also ditch the console for all but the most basic of tasks. It's not 1997, the lingering stink of proprietary rich client environments is cleansed. Web browsers have annihilated that assumption and made something truly open and pretty amazing. I use a web browser as my core text editor and I miss emacs not a whit and quite honestly it feels more responsive than my emacs setup. I don't notice any tangible performance differences from Vim in a terminal. We can do better.
  - jackmott 10y ago
    > HTML + JavaScript + Electron flips over table
    - KirinDave 10y ago
      Actually, let me unflip that table. I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should. Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command line entry were a small flexible webview. Imagine if you typed netstat and it showed the results, but there was also a field where you could key in text narrowing queries as part of the standard presentation for all very long input. No more appealing to grep or more and losing context or blasting your scrollback buffer. Consider for a moment if we could move away from trivial line interfaces for SSH and towards a protocol that actually handles sessions and works over SSL in every conceivable network environment. Hell, most people I know have migrated to mosh and only type ssh when they're provisioning fresh cloud instances (usually to get mosh on there as fast as humanly possible). The entire idea that "text is a superior interface" is correct as an input mechanism, but not necessarily as a data presentation mechanism. HTML and some basic es2015/typescript/whatever isn't just flat out better than bash for this sort of thing, but it flows from a long history of tools like tcl/tk trying to make the shell a more efficient and effective place to visualize trivial data. I've been using terminals since 80 characters was a luxury and amber was the fancy new color, and for at least 20 of those years I've been hoping we'll see something that keeps the composability of shell scripting but introduces a non-line oriented protocol that could also offer presentation logic when appropriate. We could preserve all of that if we just pretend all existing shell commands return a (forgive the templating syntax, it'll be understandable by a wide audience) Map<Stream<Text>> where {'stdout': <stdout>} and additional data can be offered around that with trivial API additions. Please, let's not pretend we'd not benefit massively from richer tooling here.
      - 59nadir 10y ago
        > Please, let's not pretend we'd not benefit massively from richer tooling here. Absolutely nothing about this project or the way they went about building it shows any tendency towards richer tooling. A web interface also does not inherently enable richer tooling. You could implement this non-line oriented protocol entirely without 500+ MB of JS and the interpretation of that data could obviously be done without it too. Edit: While I understand your rants all over these threads (it doesn't inherently have to be inefficient and bloated), you've picked a strange submission to take these fights in. The software in question is in fact bloated, not compliant and is really only an interface to aliases. Also, I would add: The proof is in the pudding. You seem to have made this a personal crusade, so I would urge you to make a decent PoC with these ideas to show the world.
  - andrepd 10y ago
    I'm cringing.
  - andrepd 10y ago
    I'm cringing at that entire paragraph.
  - Myrmornis 10y ago
    > that they (for some unknown reason) decided to create. That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
    - erlehmann_ 10y ago
      I see at least two possible reasons to create such a terminal: One: The author might have problems with how other terminals work. The other: The author just wanted to create something, without providing a superior value proposition. If it is indeed the latter scenario, it just wastes others' time.
      - Myrmornis 10y ago
        > If it is indeed the latter scenario, it just wastes others' time. What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way. You should really reconsider your position. One point is that, while you may have the skills and experience to only work on projects that improve the status quo, many of us do not; and even those who do, as beginners had to pass through the stage where they did not.
        erlehmann_ 10y ago
        If a project does not improve the status quo, I think it should not be presented as something one “should have”. The time wasted is exactly the time it takes to find out that “elegant and efficient” is at best hyperbole, at worst a lie.
        Myrmornis 10y ago
        Have you ever met a novice programmer?
  - aphextron 10y ago
    >HTML + JavaScript + Electron This was my creeping suspicion the moment I saw the screenshots. Utter garbage.
- Myrmornis 10y ago
  > why the author found it necessary to create it That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
themartorana 10y ago
I have several devs in the office that have to use the terminal a grand total of 2 times a month, and even then I installed some shortcuts for them to make using adb easier. Being able to build a simple interface on top of the few commands they use, so they don't have to remember flags, argument orders, etc., would be advantageous to us all (and require less support on my part). Also, what is possibly wrong with someone trying to make some money for their work??
- nameless912 10y ago
  There's nothing inherently wrong with wanting to make money for your work. The problem, honestly, is that a good terminal is a solved problem (c.f. urxvt, which is perfect in every way). Charging people for one would be like charging people for a vim clone. Why charge for an inferior product when someone's already created perfection? ;) Second of all, learning shell scripting is an almost ridiculously important skill. Wouldn't it be better that you sit those devs down and have them go through a couple hours of intensive shell boot camp so they don't need your help anymore? Anyone who's a halfway-decent dev can learn the basics of shell (simple scripting, variables, redirection, piping) within a couple of hours, easy.
  - themartorana 10y ago
    It's not that simple. The shell for you and me is muscle memory. For someone who takes a "boot camp" and then doesn't use what they've learned for 3 weeks, the boot camp was a waste of time. Haven't you ever come back to a piece of code from a month ago and had to reacquaint yourself with it? (I know I can't be unique in that... ;) ) We cram an awful lot into our heads as devs, there's no room for things we barely use from a month ago. To you, the shell may be perfect. For someone else, it's a severely antiquated method of input that was outdated after Windows 3.1. I love me some shell, but that's you and me. Not all devs. Edit: reminds me of CPR class. After a month or so, you better brush up lest you actually need to use it!
    - nameless912 10y ago
      Here's what you do: in the middle of the night, sneak into all of your devs' offices and fuck with their xorg.conf's. Make them drop to command line only for a couple weeks (because we all know it takes at least that long to diagnose an xorg.conf....) and they'll learn. Oh they'll learn ;)
ksk 10y ago
You seem to have made this about you, which is fine, but why should we care what _you_ like? Are you a person whose opinion is deeply valued and sought after? Because if you are, then certainly a subjective statement will be weighted by the knowledge, experience and the expertise of the person saying it. So my question is, why does it bother _YOU_ if someone, somewhere, finds value in this and prefers this to whatever other way you think other people should do it?
- fapjacks 10y ago
  This isn't Facebook or Reddit. This is HN. Anybody trying to pass that thing off in this community has got some criticism coming.

benbenolson 10y ago

I agree with each and every one of your comments; in addition, I would like to know how this project was created: what language it was made in, why the author found it necessary to create it, etc.

guessmyname 10y ago
> what language it was made in HTML + JavaScript + Electron Just download that archive, extract its content, and you will find the "goterminal" script that is basically an ASAR archive [1] with a copy of CEF [2] as the webview for the web application that they (for some unknown reason) decided to create. [1] https://github.com/electron/asar https://github.com/electron/asar [2] https://bitbucket.org/chromiumembedded/cef https://bitbucket.org/chromiumembedded/cef
- mrmondo 10y ago
  Oh god, the last software I'd want to be running a terminal in!
- placeybordeaux 10y ago
  Yikes. Thats a great way to make a terminal into a memory hog and unresponsive under load.
  - KirinDave 10y ago
    Oh? Historically most terminal implementations have been fraught with performance issues. We'd moved off xterm to aterm and then back. We'd been hesitant to adopt gnome-terminal because of the GTK+ chrome then saw its font kit actually rendered faster. What most people don't get is how absurdly well-optimized the text rendering and reflowing is for web browsers. With care, people can get modern cellphone browsers to hit 60fps animations and reflows while pushing huge volumes of text through them. Take any 3 GUI toolkits you can name and ask yourself, "Do all three of these combined have a maintenance budget that equals that of even Firefox by itself, let alone any TWO modern web browsers?" Hell, some of the most cutting edge research into interpreters and garbage collectors is coming out of Google making V8 fast. Quite frankly, I'd bet that with care and foresight this could be faster than iTerm.
    - placeybordeaux 10y ago
      Maybe I am wrong, but I have yet to see a modern browser take anywhere near as little memory of CPU as a modern terminal emulator. There is also the matter that no matter how much optimization you put into something you can't recoup the cost of the fundamental design choices you went with. Choosing something with less power can solve a lot of headaches.
      - KirinDave 10y ago
        > little memory of CPU as a modern terminal emulator. Browser instances can be quite svelte. But uh... I mean... shared lib pages tend to be actually shared pages. That's why the physical memory for multiple browser instances is a lot lower. What's more, I'd gladly pay a higher price for a richer experience. We no longer need to or should rely on ANSI interfaces. In fact, they're becoming increasingly awkward in a world that really wants endpoints to be stateless by design rather than stateful sockets. Many people have already discarded the single socket model oh SSH in favor of Mosh. Let's also ditch the console for all but the most basic of tasks. It's not 1997, the lingering stink of proprietary rich client environments is cleansed. Web browsers have annihilated that assumption and made something truly open and pretty amazing. I use a web browser as my core text editor and I miss emacs not a whit and quite honestly it feels more responsive than my emacs setup. I don't notice any tangible performance differences from Vim in a terminal. We can do better.
- jackmott 10y ago
  > HTML + JavaScript + Electron flips over table
  - KirinDave 10y ago
    Actually, let me unflip that table. I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should. Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command line entry were a small flexible webview. Imagine if you typed netstat and it showed the results, but there was also a field where you could key in text narrowing queries as part of the standard presentation for all very long input. No more appealing to grep or more and losing context or blasting your scrollback buffer. Consider for a moment if we could move away from trivial line interfaces for SSH and towards a protocol that actually handles sessions and works over SSL in every conceivable network environment. Hell, most people I know have migrated to mosh and only type ssh when they're provisioning fresh cloud instances (usually to get mosh on there as fast as humanly possible). The entire idea that "text is a superior interface" is correct as an input mechanism, but not necessarily as a data presentation mechanism. HTML and some basic es2015/typescript/whatever isn't just flat out better than bash for this sort of thing, but it flows from a long history of tools like tcl/tk trying to make the shell a more efficient and effective place to visualize trivial data. I've been using terminals since 80 characters was a luxury and amber was the fancy new color, and for at least 20 of those years I've been hoping we'll see something that keeps the composability of shell scripting but introduces a non-line oriented protocol that could also offer presentation logic when appropriate. We could preserve all of that if we just pretend all existing shell commands return a (forgive the templating syntax, it'll be understandable by a wide audience) Map<Stream<Text>> where {'stdout': <stdout>} and additional data can be offered around that with trivial API additions. Please, let's not pretend we'd not benefit massively from richer tooling here.
    - 59nadir 10y ago
      > Please, let's not pretend we'd not benefit massively from richer tooling here. Absolutely nothing about this project or the way they went about building it shows any tendency towards richer tooling. A web interface also does not inherently enable richer tooling. You could implement this non-line oriented protocol entirely without 500+ MB of JS and the interpretation of that data could obviously be done without it too. Edit: While I understand your rants all over these threads (it doesn't inherently have to be inefficient and bloated), you've picked a strange submission to take these fights in. The software in question is in fact bloated, not compliant and is really only an interface to aliases. Also, I would add: The proof is in the pudding. You seem to have made this a personal crusade, so I would urge you to make a decent PoC with these ideas to show the world.
- andrepd 10y ago
  I'm cringing.
- andrepd 10y ago
  I'm cringing at that entire paragraph.
- Myrmornis 10y ago
  > that they (for some unknown reason) decided to create. That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
  - erlehmann_ 10y ago
    I see at least two possible reasons to create such a terminal: One: The author might have problems with how other terminals work. The other: The author just wanted to create something, without providing a superior value proposition. If it is indeed the latter scenario, it just wastes others' time.
    - Myrmornis 10y ago
      > If it is indeed the latter scenario, it just wastes others' time. What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way. You should really reconsider your position. One point is that, while you may have the skills and experience to only work on projects that improve the status quo, many of us do not; and even those who do, as beginners had to pass through the stage where they did not.
      - erlehmann_ 10y ago
        If a project does not improve the status quo, I think it should not be presented as something one “should have”. The time wasted is exactly the time it takes to find out that “elegant and efficient” is at best hyperbole, at worst a lie.
        Myrmornis 10y ago
        Have you ever met a novice programmer?
- aphextron 10y ago
  >HTML + JavaScript + Electron This was my creeping suspicion the moment I saw the screenshots. Utter garbage.
Myrmornis 10y ago
> why the author found it necessary to create it That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?

themartorana 10y ago

I have several devs in the office that have to use the terminal a grand total of 2 times a month, and even then I installed some shortcuts for them to make using adb easier. Being able to build a simple interface on top of the few commands they use, so they don't have to remember flags, argument orders, etc., would be advantageous to us all (and require less support on my part). Also, what is possibly wrong with someone trying to make some money for their work??

nameless912 10y ago
There's nothing inherently wrong with wanting to make money for your work. The problem, honestly, is that a good terminal is a solved problem (c.f. urxvt, which is perfect in every way). Charging people for one would be like charging people for a vim clone. Why charge for an inferior product when someone's already created perfection? ;) Second of all, learning shell scripting is an almost ridiculously important skill. Wouldn't it be better that you sit those devs down and have them go through a couple hours of intensive shell boot camp so they don't need your help anymore? Anyone who's a halfway-decent dev can learn the basics of shell (simple scripting, variables, redirection, piping) within a couple of hours, easy.
- themartorana 10y ago
  It's not that simple. The shell for you and me is muscle memory. For someone who takes a "boot camp" and then doesn't use what they've learned for 3 weeks, the boot camp was a waste of time. Haven't you ever come back to a piece of code from a month ago and had to reacquaint yourself with it? (I know I can't be unique in that... ;) ) We cram an awful lot into our heads as devs, there's no room for things we barely use from a month ago. To you, the shell may be perfect. For someone else, it's a severely antiquated method of input that was outdated after Windows 3.1. I love me some shell, but that's you and me. Not all devs. Edit: reminds me of CPR class. After a month or so, you better brush up lest you actually need to use it!
  - nameless912 10y ago
    Here's what you do: in the middle of the night, sneak into all of your devs' offices and fuck with their xorg.conf's. Make them drop to command line only for a couple weeks (because we all know it takes at least that long to diagnose an xorg.conf....) and they'll learn. Oh they'll learn ;)

ksk 10y ago

You seem to have made this about you, which is fine, but why should we care what _you_ like? Are you a person whose opinion is deeply valued and sought after? Because if you are, then certainly a subjective statement will be weighted by the knowledge, experience and the expertise of the person saying it. So my question is, why does it bother _YOU_ if someone, somewhere, finds value in this and prefers this to whatever other way you think other people should do it?

fapjacks 10y ago
This isn't Facebook or Reddit. This is HN. Anybody trying to pass that thing off in this community has got some criticism coming.