TermKit - a graphical terminal replacement - <AUTHOR> http://acko.net/blog/on-termkit <comment><USER3> It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information- dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). His "rich display" is actually a display of poverty - it conveys less information than text.

The typing of file / stream data is interesting, but I don't think it's realistic - it requires all tools to change virtually overnight to preserve the headers. And it's not enough just to preserve headers; what if you pump stuff out to a temporary file and read it in a few milliseconds later? What about compound files, with data chopped out of them? If you want pretty pictures, syntax highlighting etc., ISTM better to have an enriched terminal communication protocol along with a couple of viewer programs which can render data formats to it, rather than change the whole world to type every data flow everywhere.

<comment><USER4> On the other hand, ls isn't showing you the file type, and will never show you content. And you're mixing presentation with content, which is poor engineering - see the guys coming up with regexs to handle time because the only way time is presented to them is as text,

Good shells have prompted object pipeline based tools before - PoSH is only a few years old. And it's still possible for older tools to run with no degradation in quality from their previous environments.

This is really compelling.

<comment><USER3> ls shows file type by coloring - check out ~/.dircolors/dircolors/LS_COLORS and ls --color=auto - and kind by extension - ls -F. Showing things like thumbnails seems to me to be of limited use. When I want to see the directory in all its glory, I'll do the moral equivalent of "cygstart/open/whatever .". That'll give me a proper shell window designed for viewing content with thumbnails etc., rather than trying to stick it into the terminal. I've had enough experience with things like dodgy video decoders crashing the shell's thumbnail preview mechanism to know I don't want that stuff anywhere near my terminal unless I specifically ask for it.

Powershell - I do indeed wish Unix shells worked a little more like it for jobs like parsing ps output portably across platforms, but it has poor performance for what I use the shell for, because it doesn't run each pipeline process as a separate process or thread - everything is single-threaded. I frequently run sed, awk, grep, sort over multi-GB files and rely on processes and job control (fork-join through mktemp, & and wait, and xargs -P) to make it work quickly.

But if, as I mentioned, the terminal supported a richer communication protocol - one smart enough to show render full 32-bit images including alpha - then a version of ls could be written that does what his ls command does, without needing to go as far as he does.

<comment><USER5> Consider these bugs to be fixed, not irreparable complaints ;).

</comment></comment></comment></comment><comment><USER6> I had a similar idea about 10 years ago, but never got around to implementing it.

I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scrollbars.

Or, consider filename completion. Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do) ?

Why, when I do 'ls', can I not drag & drop one of the files to another finder window? Why is the terminal forever isolated?

Why when I run 'mvn install', which generates umpteen bazillion lines of output, can the result not be folded into a single line showing the summary, that I could expand if I wished?

There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).

So I think it's an awesome idea.

<comment><USER7> _"I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!"_

Improve it all you want, I'm totally into that. The problem is that once your "terminal" ceases to be a terminal emulator then you lose so much it's pretty unrecoverable.

Most of the things that you suggest are very much technically possible for a shell (perhaps zsh with some extensions) running in xterm. You'd be left with some sort of unholy combination of a rather modernized `mc` and an otherwise modern shell, but it'd be a very interesting product.

tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1) mistaking "improving the terminal" with "improving the shell" and 2) _losing_ the _terminal_.

<comment><USER8> A terminal emulator running on an object-oriented system like Termkit could run vt100-friendly filters to convert everything to text before it is sent down the line to the user. Users who did not know they were connecting to such a system might not notice the difference.

<comment><USER7> Although I am not entirely sure what you are attempting to communicate, what I will say is this:

If you do not provide direct user access to a pseudo terminal through a terminal emulator, then you will undoubtedly lose functionality. You need both the pseudo-terminal and the terminal emulator. If you _do_ provide direct user access to the pty through a terminal emulator, then what the hell is the rest of the crap there for?

</comment></comment></comment></comment><comment><USER9> I love this!

It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this!

Here's the direction I would propose:

It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea.

So why not do it the UNIX-way and how terminals have always done it:

Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back).

This way we have a normal terminal, with a bonus-mode.

A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'.

And on the screen that image would magically be embedded below my command line, just like any text output would.

tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end- esc.

That's the basic architecture that I'd like to see. And from there, sky's the limit.

<comment><USER5> I hear what you're saying, but respectfully I disagree.

To me, it's like suggesting that the iPhone would be better if you added a physical slide out keyboard to make it more old-school; sure, you could do that, and would probably score popularity points with unconvinced customers.

But you would compromise tons of secondary aspects of the device to do so.

If TermKit would have a "traditional" mode of operation, and let you switch back to it, it would mean that TermKit has failed in being a comprehensive tool. I hope I can get around that.

<comment><USER10> You could put the "new" mode of operation directly against the "traditional" one only if you were proposing an actually new paradigm (like the point-and- click interface). And even then you would still want to allow a way to fall back to what's tried and true.

As TK is essentially an _improved terminal_, I don't see a reason to totally break off from the current power of the traditional CLI, especially if alienating current power users in the process.

The biggest limitation are the existing applications. Initially the new features could be opt-in, and as the new idea picks up, you would then have more and more console applications support the new type of terminal.

</comment></comment></comment><comment><USER11> After seeing something about this yesterday, I said on Rstat.us/Twitter that I thought it was pretty but disagreed with the whole premise. I still do, I think, but I'm very impressed with how reasonable Steven's response was. He wrote me and asked pretty much "Why?" I said essentially "Unix philosophy" and attached the link that ended up in his blog post.[1] He wrote back and at some point he wrote this post, probably replying to _all_ the people who were taking snipes at him. So this is a long way around to say, kudos for being gracious and serious in the face of people glibly writing off your hard work.

Having said that, I'm still not sold on the concept - yet. I've played with it a bit this morning. Obviously it's still pretty alpha (more than one seize up or crash), but that's fine. My larger problem is in figuring out how it would fit into my daily work flow. After trying it out now, here are some concrete issues:

\+ No monospace fonts for code. The output of _cat_ looks like teeny-tiny website font. Things are no longer "lined up". That's bad.

\+ I can't use any applications that take over the terminal ( _irssi_ , _mutt_ , _vim_ , _less_ ). Steven says as much - it's not part of his design - <USER2> for me it's a big problem. It means that even if I embrace TermKit, I _still_ need those 1980s terminals.

\+ No scripting language built in. As bad as shell scripting might be, I get an absolute ton done with it. I don't want to give that up unless something will make up for all that "getting shit done".[2]

\+ TermKit (maybe?) forces me to change habits I can't afford to lose. One small, but I think important, example: If you try to run this:

        awk '{print $1}' file.txt

TermKit doesn't echo the single quotes. That is, you can type them, but they don't show up on the screen. I'm not really sure what to do with that. Does that mean I should stop typing them? Does that mean that I still _must_ type them, but TermKit strips them because they aren't pretty? Does TermKit allow me to do it either way? I'm going to need to remember how to quote things when I log into a remote machine over _ssh_ , so if TermKit will force me to change habits, that's a big, big problem. (After a few experiments, it seems like the single quotes are still required. Without them, TermKit tokenizes the stream differently. If that's the case, why refuse to echo them to the screen?)

[1] <http://www.faqs.org/docs/artu/ch01s06.html>

[2] Cf. Ryan Tomayko's Shell Haters talk: <http://shellhaters.heroku.com/>

<comment><USER5> To address some of your concerns:

\- Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one.

\- Regarding vim... I admit I just don't like those tools. I can operate vim just fine, but I hate every second of it. I would much rather be able to type "edit file", have it open up the file in my local editor, and sync back saved changes.

\- No scripting language... except the whole thing is built on Node.js... :) What's not discussed in the article is that the UI is not tied to the shell at all. You can just as easily make a back-end worker for SQL, for SFTP, for a scripting console, etc. I haven't worked out how this works in the UI, but the protocol supports it. Session types can be multiplexed freely over one socket. Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.

\- Regarding habits... it's not my goal to break any without reason, just to reduce the number of keystrokes. Consider it a bug. Regarding quotes... the idea is WYSIWYG. If there is a visual divider, it's a separate argument. Otherwise, it gets passed as a single unit. This may sometimes be buggy, the Unix command support is 1 week old, and I hack on this very late at night.

<comment><USER5> And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable.

I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).

<comment><USER12> It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.

<comment><USER13> Thing is, it's not about the tools being sacred. My problem with this is that he's not just solving problems I don't have -- he's solving them in a way that would make my problems worse!

For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.

Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.

Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)

<comment><USER14> "if I did, I'd probably use Finder instead."

The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.

<comment><USER13> See, here's the thing: I like Finder. It's not perfect, but sometimes it is very handy. Even if TermKit ends up implementing the complete functionality of Finder, I'm not sure why I'd particularly like to have that functionality in my terminal window. And if it's only implementing the one Finder view I virtually never use? Forget about it.

You know what would rock my world? A "lsf" command that emulated "ls" as much as possible, but launched a Finder window appropriately sized to display the results.

<comment><USER14> I've always thought Raskin's ZUI held some promise as an alternative UI paradigm. I'm pretty much a quicksilver addict now and use that to kind of combine the command line and GUI desktop worlds a little bit more at least.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> It's a pity that this is so difficult to try. The blog post has so much detail and effort put into it, but all that shine and polish disappears when you try to install it.

Specifically Step 1 of the instructions[1] has a link titled "install node and npm" [2] which has the line 'git clone git://github.com/ry/node.git', which is incorrect. The correct URL (as far as I can tell) would be 'git://github.com/joyent/node.git'.

In addition the linked instructions say nothing of npm, which can be installed quite easily by running 'curl <http://npmjs.org/install.sh> | sh' as root.

Back to the TermKit instructions again, and step 5 says 'git clone email@example.com:unconed/TermKit.git --recursive', which didn't work for me. What worked was 'git clone git://github.com/unconed/TermKit.git --recursive'.

Finally after all that, I just see 'You cannot use this version of the application TermKit.app with this version of Mac OS X.'. Would have been nice to mention that at the start.

[1]: <https://github.com/unconed/TermKit> [2]: <http://howtonode.org/how-to- install-nodejs>

<comment><USER5> I don't mind, the project is in too rough a shape to interest anyone but hackers. Please come back in a month.

<comment><USER15> I get that it's not meant to be release quality yet, it's just a shame that your blog post was so comprehensive and detailed and fell down on that last point. Certainly spending half an hour installing software only to find out I need to upgrade my OS X wasn't fun :(

</comment></comment></comment><comment><USER16> I really think Steven went about marketing this in the wrong way. It really should have been dubbed as a terminal _alternative_. By calling it a replacement he's just inviting a mass of critique which focuses on what it lacks rather than what it offers over an xterm.

<comment><USER5> I really doubt that would have changed people's reaction. Besides, to be taken seriously, I have to believe that TermKit can eventually be a fully functional replacement.

As for being hard to try and not at a useful stage yet... hey, that's not my problem. I wasn't the one who upvoted it all over the internets :).

</comment></comment><comment><USER17> I'd like to offer a slightly different perspective on this. As someone who is a hybrid hacker/biologist, I welcome something like TermKit. I have invested a good chunk of time learning unix commands and the shell because lots of scientific applications require it. Furthermore, as a data wrangler, the unix tools are a necessity for quickly processing and pumping files around. I _require_ unix to efficiently do my job. I often think, "Gosh, what do all these other people _do_ when they need to do X?" where "X" is some ugly task that I can hack some grep and sed commands together to accomplish. I don't think most programmers understand the sheer number of exceptionally well- educated, genuinely smart people who spend huge chunks of their day doing menial "copy/paste" in Excel (because it's the only real tool they can use) when they should be designing bridges, curing diseases, analyzing data, etc...

If you're a unix sysadmin or a full-time hacker, you can justify the cost in time and effort of learning and memorizing all this stuff. In fact, you'd be foolish not to. But there are a lot of people who don't spend all day in a terminal. Nevertheless, they frequently _need_ the unix terminal to get something done. A tool like TermKit could be a huge boost for those people allowing them to bootstrap their knowledge without having to dive into the deep end all at once.

There are legions of people out there who are smart enough to learn some bits of unix if only the learning curve wasn't a sheer brick wall. If you need evidence that man pages and "-h" don't cut it, start typing common unix commands into google (xargs, tar, grep, etc...) and you'll almost always find one of the top suggestions is "command_name examples" or something like that. Why is that? My grandma isn't trying to use "xargs" I assure you. Someone with enough knowledge of the unix command prompt to know they need xargs reads a man page and they _still_ don't know how the hell to use the command properly. That's a usability problem and there are modern ways to help with it (as is demonstrated by all the things IDE's do to help programmers all the time).

I'm really excited to see where this goes. There are all sorts of possibilities it opens up.

</comment><comment><USER18> Excellent exploration of alternatives to the old 'terminal' application. It would probably help for context to explore the Bell Labs 'BLIT' terminal and the Digital Equipment Corp VT340 (color graphic terminal) and the Tektronix 4010/4014/4064 terminals. These had capabilities that augumented the basic terminal stuff and made it prettier at least to use them.

The humorous thing for me is seeing the discussion which essentially devolves into creating a new windows type metaphor but with a lot of keyboard shortcuts.

It may sound pedantic but consider that the terminal is the terminal because terminals define a keyboard driven user interface. A user interface is a 'vocabulary' which describes actions. Its vocabulary scales from a communication channel that is 300 baud to one which has multi-megabaud connectivity. You can create a different vocabulary (which is what the other terminals above did) and get additional features.

And you can create an entirely new vocabulary if you're willing to change the minimum connectivity channel bandwidth as well (I doubt TermKit would work well over 300 baud for example). There was some good work done on this in the 80's with 'visual shells' on the PC and of course there is a ton of work that IBM did in creating optimized terminal environments (with visuals no less) on 3270 terminals which were in many ways a pre-cursor to todays IDE tools, although perhaps more like Eclipse. Their environment which ran airline reservations was a good example of optimizing the vocabulary (key strokes) against the variety of tasks an agent might need to do.

So rather than calling this a graphical terminal replacement (which it isn't) calling it a visual UI which can be driven entirely by the keyboard might be better. I think that fundamentally the "thing" about terminals that everyone sort of 'gets' is that you don't have to use a mouse, you always know where your 'focus' is, and there are millions of key combinations which you can use to express certain actions. For some, that is simply 'living in emacs' for others it could be something like this.

<comment><USER19> I bet TermKit would actually work awesome over 300 baud. The two-tier approach -- a backend that executes commands and a frontend that displays stuff -- is going to be pretty efficient (if you are only running the backend remotely). Well... perhaps the chattiness of something like filename completion will be a bit of a problem, but it'll still probably work better that more directly interactive systems because it's working with a more abstracted protocol than a terminal does.

</comment></comment><comment><USER20> _"At the end of the day, Unix just has bad usability"_

I have to say I highly disagree with this statement but, I also disagree that there is anything wrong with the classic terminal. I find a full screen terminal with nothing but text as a thing of beauty. They remove all but the most essential details and work on a very simple common format (text).

In a way this kinda makes me think of Windows Power Shell, which is trying to replace the classic shell with a more object oriented shell, it has a lot of good ideas but in ways it brings more complexity to the issue than most Unix users are looking for. Seems like this project could probably take some ideas from Power Shell though.

I certainly have nothing against this guys work but it is not really a classic unix shell replacement and should probably not strive to be such a thing.

<comment> DanI-S Text is a simple format, but text with intrinsic formatting is most definitely not a simple format.

<comment><USER20> yeah thats true, thats why I get why Power Shell took an approach of passing object around as apposed to just text. I think I was thinking more from a visual standpoint when I said that text is simple.

</comment></comment></comment><comment><USER21> Maybe I'm an old fogey but I'll stick with xterm and iterm. Having a terminal where I can have the same experience whether logged into a *nix box, on osx, or sshed into a remote server is far more appealing than being able to cat images or having a pretty progress bar. If I want to make json more readable I can just pipe it through one of the many json formatting scripts.

It might just be me but I find cocoa to be a bit boring and dated looking. Unix terminals are timeless. A nice tiling windows manager with 5 terminals is still one of the most beautiful set ups.

<comment><USER5> Note: the goal is to be able to run TermKit transparently over SSH. Maybe even do an "apt-get install termkit-backend" for you if you wish.

</comment></comment><comment><USER22> The first thing to realise is that the existing UNIX data processing tools deal fall into two categories - those that process (including generate or consume) an ordered sequence of text records (eg. sort, comm, uniq, awk, sed, grep, tr, cut, find, xargs, ls...) , and those that process arbitrary binary data (cat, dd). Most fall into the first category.

Now, while it might make sense to use a better interchange format than "newline-separated text" for those ordered text records, I don't think that adding other arbitrary data types is particularly useful, unless a way can be found to make these arbitrary data types self-describing. This is because there's little to no commonality in the types of processing that you do on different data types: the article shows the example of "cat termkit.png", but what does it mean to concatenate two images ("cat foo.png bar.gif"), or concatenate an image with a text file? Making some assumptions, we can certainly define arguably useful semantics for those, but what does it mean to "sort" an image?

And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?

<comment><USER23> _And how do we write "cat" to deal sensibly with currently unknown data types, that will be defined in the future?_

Progressive enhancement. You get magic for the obvious things and standard behavior for the non-obvious. I still want the power and flexibility of my vanilla terminal, but I want it to do more when it can.

I want to open up a remote terminal to another server, on the other side of the planet, and do a "cat foo.png" so that I can see it. Better yet, I want to do an "ls -la" and have it show me the standard output, plus all the thumbnails of the images in the folder. I want to do a ton of other stuff too. At the same time, if load up some esoteric weird 30-year-old thing I found on the internet that I just compiled ... well, I expect that to work too. That's a must.

Of course, wanting and having are two different things.

</comment></comment><comment><USER24> This comment thread, both here and on the blog post, is the best example of stop energy being directed at forward motion I've seen in a long, long time:

<http://www.userland.com/whatIsStopEnergy>

Kudos to unconed for doing something remarkable. I look forward to seeing where it goes from here.

<comment><USER25> that's just a marketing site talking about a marketing term probably invented by a marketing guy, I'm okay if this gets as widespread as apple devices (and btw I really love my macbook pro) but I find it totally useless for the people working day by day with terminals, time will have the last word

<comment><USER26> Think of this as empowering people who will not use vi or emacs, but prefer Eclipse or Visual Studio, to have a visually appealing arsenal of tools which can be chained in a pipelined fashion.

What is wrong with that? Yahoo pipes for example provided pointy clickety interface to mashing up data. Lot of people used it to do useful work.

It really does not matter if a even single sysadmin who already uses the shell does not start using this. It just needs to have its OWN users that is all. If you just consider ALL Eclipse users + ALL Visual Studio users, that is a HUGE user base... Now the vi/emacs user may _feel_ superior to the others...

but in reality anyone in this world can have their own reasons to create products and use various tools. All the best to the author of this tool for taking the pain to code this...

If it works out and gains users... awesome... else it shows we still find Old tools useful. We have not stopped using Fire or Wheels today though they very OLD technologies. Whether the shell is as important as fire or wheels OR transitionary like Hydrogen blimps or something in between only time will tell...

</comment></comment></comment><comment><USER27> Many times you need to look beneath the veneer of abstractions that is the modern GUI, to work with speed and flexibility. However you don't want to strip away all the abstractions. That would yield the system very unwieldy. (example: Programming in C vs Programming in Assembly) The Unix command prompt is just the right amount of abstraction for me, and for many other users. What the project proposes is certainly novel, and this level of abstraction may work for some people.

<comment><USER28> Exactly, I think if you are a hacker you will stick with the shell the way it is, because knowing how stuff works with "zero" abstractions is power.

Reminds me of this: <http://i.imgur.com/jqIcv.jpg>

Also I mean as a hacker, not as an entrepreneur.

<comment><USER5> I think my point is that we've all been so locked into these tools that we've become blind as to where their failing are. I wanted to start TermKit from a fresh slate and only slowly add bits of existing Unix to it, so I could make sure the resulting whole still made sense.

<comment><USER29> For me, as someone that does all his work in Windows and stays away from consoles as much as possible, this entire discussion is hilarious.

I think your project is cool, it certainly is a fresh take on the console, but the minority of people that like the unix console will be very resistant to anything graphical, and the majority of people that prefer graphical interfaces will just wonder why the hell you still need to do all of that typing. :-)

The fundamental problem with consoles is that it's impossible to explore the interface. You can only use it by knowing the possible commands beforehand.

Hmm.. Perhaps that's something you could explore with Termkit? With the added graphical output, is it possible to show hints for what I can/want to do, given what I've already typed? I dunno, just an idea.

<comment><USER28> The power is in knowing the shell. You can do things quickly and do exactly what you want if you know how to use it. No GUI can give you with the same speed and efficiency.

The learning curve is steep, I like your suggestion of 'exploring' the interface. I think this deserves more merit than making the shell glossy.

</comment></comment></comment></comment></comment><comment><USER30> The terminal hasn't changed much in 40 years because it very good at what it does, that is, allowing experts to _get stuff done_. One of the usability lessons of modern computing is that the mouse is a productivity killer. Having transitioned back to vi from TextMate, I have certainly found it to be true.

The author talks about how its a shame to give 2MM pixels to an 80 column terminal, but from what I've seen, developers are perfectly capable opening multiple terminal windows to view things like log files and running quick commands. Try that on a WYSE.

While I don't think I'd ever use this as a replacement for my terminal, I do think the "server" part of the architecture is interesting. What if you built a native OSX app to replace finder. That is something I'd use.

<comment><USER31> «One of the usability lessons of modern computing is that the mouse is a productivity killer.»

Actually, one of the usability lessons of modern computing is that the mouse makes you faster, but the keyboard makes you _think_ you're faster.

reference: <http://www.asktog.com/TOI/toi06KeyboardVMouse1.html>

<comment><USER30> Here is Atwood's response

[http://www.codinghorror.com/blog/2008/03/revisiting- keyboard...](http://www.codinghorror.com/blog/2008/03/revisiting-keyboard-vs- the-mouse-pt-1.html)

</comment></comment></comment><comment><USER32> This a cool project, albeit not my cup of tea. Sure, the terminals out there need a little work, but I'm skeptical about bringing too much of the "gui world" in.

There are, however, some concepts that are worth copying and that are in fact doable in current terminal environments. What I would like to see is more innovation in the world of console programs. There are lots of things to do in terms of auto-completion, navigation and integration etc.

Take a look at ranger [1] and sup [2] for examples of new neat console applications.

[1] <http://ranger.nongnu.org/> [2] <http://sup.rubyforge.org/>

<comment><USER33> "Notmuch is an answer to Sup. Sup is a very good email program written by William Morgan (and others) and is the direct inspiration for Notmuch. Notmuch began as an effort to rewrite performance-critical pieces of Sup in C rather than ruby. From there, it grew into a separate project. One significant contribution Notmuch makes compared to Sup is the separation of the indexer/searcher from the user interface."

<http://notmuchmail.org/>

<comment><USER34> why should indexer/searcher be coupled to email files in particular, instead of dispatching on MIME types? why should the datamodel be something ad-hoc instead of RDF?

[http://blog.whats-your.name/post/2011/02/14/sifting-thru- you...](http://blog.whats-your.name/post/2011/02/14/sifting-thru-your-IRC- logs-w/-examine)

<comment><USER35> That's something that they are working on. One example of a useful application is a text ebook collection.

</comment></comment></comment></comment><comment><USER19> I played around with what I think is a very similar idea a while back: <https://github.com/ianb/jsshell> \-- I think the basic architecture is the same, but this is much more advanced; I never really got past the point of displaying all output as literals.

In both cases I think this is really as much a replacement for the shell (e.g., bash) as for the terminal. The truly fundamental verb in a Unix system is executing something with a set of string parameters, an environment, and a cwd, and passing stdin in, with stderr and stdout coming out. That's pretty much everything, so there's a lot of flexibility about how you can present that to a person -- all the stuff like &, if statements, file redirection, shell quoting, etc., is part of the shell UI, it isn't really core to the OS or any of the commands.

There's a lot of graphics and icons in this particular implementation, but IMHO that's not really the important part. Taking out the statefulness of the shell is the more interesting part to me. "cd" seems magic, but it's just setting an internal variable in the shell. Foreground and background processes seem core, but they are just a way of handling the inability for a terminal to handle more than one thing at once. Variable substitution, redirection, backticks... these are all abstractions; and they are useful abstractions, but they might deserve a bit of rethinking.

</comment><comment><USER36> I find Unix usability standards generally pretty insane. Funny he should post this, as on the train today I was thinking of making a program I'd call 'SmartTerm' or something which would basically be a more usable, graphically augmented terminal for beginners (or people who just can't stand interfaces which depend on memorization and patience).

Some things I find nuts about the current terminal is OS X (at least the default behaviour) are:

\- half the line which you need to write in is taken up by repetitive info like User, Time, and Directory

\- put the currend directory somewhere useful like the title bar

\- when i start to type a command, give me graphical autocompletion automatically (unless i switch it off), along with a note/tooltip explaining what the command does

\- after i've typed command, give me a pane somewhere which explains what all the stupid flag options are and what they do

\- give me another pane with an audit trail in plain english of what my commands have accomplished, and then give suggestions on how these could be accomplished using simpler shortcuts (especially in something like Vim. give me some help to learn the shortcuts as i work, FFS. on a GUI you look at the keyboard shortcuts beside the menu items, and get to know them naturally. this would also give you some confirmation that your command worked as expected, rather than just a blank prompt staring back at you

\- let me highlight text with shift and arrow keys

<comment><USER37> > especially in something like Vim. give me some help to learn the shortcuts > as i work, FFS. on a GUI you look at the keyboard shortcuts beside the menu > items, and get to know them naturally.

This. I hate both vi and emacs for not having a usable menu system that lets me browse through and learn the commands as I go.

I also think bash-completion, while a huge step forward in usability, really should have focused on integrating command option help from the beginning. So, in addition to a man page, each command line utility would need to bundle a machine readable key-value list of (option, help string). Then when I type <command> -<TAB>, it would show me that help.

<comment><USER38> Pretty sure Emacs has menus:

<http://jrock.us/emacs-menus.png>

<comment><USER37> It does. The problem is, the terminology in the menus is completely inscrutable (i.e. many commands are named unintuitively), the menus are poorly organized, they have a small subset of all the commands, etc. I've never been able to learn any of the shortcuts from the menus.

<comment><USER38> In the end, it's your fault because you don't want to learn. Emacs does not have "cut" and "paste", it has "kill" and "yank". They are different terms because they have different semantics.

Enjoy programming in Notepad.

</comment></comment></comment></comment></comment><comment><USER39> I love the idea of experimenting with graphical output on the console. I've seen images and vidoes running on the terminal (not a terminal emulator) using "framebuffer" consoles.

Sadly that typically only worked in full-screen mode.

If somebody wrote an ordinary terminal emulator that allowed pixel graphics as part of the normal text flow, and created an easy API for programs to use it, I'd be very happy.

TermKit looks cool, but I fear I'm too old-fashioned to move away from ordinary shell in such large steps.

<comment><USER40> I think this guy should look into implementing something like this as a compromise.

<comment><USER41> No, he shouldn't be making compromises at all. He's rightfully aiming at making the shell of the future. Features to comfort people that are stuck in their current ways can easily be backported in later, as we know how they work since the 70's.

</comment></comment></comment><comment><USER42> As much as the prospect of Webkit in my terminal makes me uncomfortable, I think this is amazing. The terminal is probably my most used application and any effort towards making it better is awesome.

(P.S. - Apart from this, unconed has also been a prolific Drupal contributor and done some amazing visualization work for Winamp. Awesome hacker.)

</comment><comment><USER43> This has been tried before with the XUL-based xmlterm around the turn of the century, but it was very slow:

<http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html>

Interesting to see someone pick this up again.

</comment><comment><USER44> There's actually a lot that can be done to improve current shells even without breaking the current set of abstractions and tools: <http://en.wikipedia.org/wiki/Fish_shell>

</comment><comment><USER45> On windows have a look at <http://poshconsole.codeplex.com/>

Same idea, with powershell as the base.

<comment><USER5> Interesting. I stayed away from powershell because it does the opposite of what I want to do: it makes the shell more like a programming language, and it still limits the output to text.

Thanks for the tip.

</comment></comment><comment><USER46> None of the examples really sound all that exciting. I see the Unix shell more of a text file manipulation toolkit, so apart from some corner cases I'm not sure if adding MIME types etc really would add much value for the usual tasks. If you're adding too much structure to things, you might as well go all the way and base everything around a programming language or framework (cf. Oberon, Powershell, Lisp Machines).

I agree that emulating a terminal from the late 70s isn't exactly the peak of programming. Character-addressed terminals are just another way to get (cheap) WIMPy GUIs.

</comment><comment><USER47> Ironically enough, this reminds me a lot of eshell, the shell implemented in Emacs lisp. Since it runs in a rich environment, it can augment a lot of standard unix functionality with really useful features, and you can extend it in a language that's not insane.

For example, grep/find results are hyperlinked, you can pipe commands directly to buffers (or even lisp functions) rather than just files, and such. In fact, now I'm tempted to add the ability to cat an image and have it display inline; should be pretty easy to implement in elisp.

</comment><comment><USER48> As far as I can tell you have to rewrite all your applications to use this. So he's not really advocating "a cool new terminal," he's advocating a "new Unix programming toolset, with accompanying terminal, to replace the BSD/GNU tools." This is great, and I wish you all the best of luck, but it looks like you're just rewriting Applescript.

Also, the reason Unix tools don't toss around JSON/XML/MIME is for sheer simplicity. It's a zen thing, something you OSX guys wouldn't understand.

Catting a png and getting a picture is nice though.

<comment><USER49> Instead of 'cat image.png', if I want to see the image, I just 'image.png' (zsh's "alias -s" magic).

</comment></comment><comment><USER50> I've toyed around with similar concepts, but went the way of trying to middle- man the input and display of a standard console instead of trying to recreate one. Admittedly that creates some limitations to how integrated things can look without extra work, but it allows for normal interactive programs and really only enhances what was already there. Plus there's the added benefit of being able to run commands even while something interactive is up.

In any case, these kinds of hybrids are inevitable due to the vast room for improvement that exists in desktop and system apps combined with how powerful the web standards have become for UI and interactivity.

Really though, while I think TermKit is a decently executed attempt at this, it alienates some of its audience for obvious reasons. It completely throws away the charm of a shell with visual style choices and breaks powerful features that people expect. That's fine, because even with those departures it can suffice as a casual mode with certain conveniences for times when it makes sense.

Visual styles can be fixed or customized, so that's just shortsightedness by others.

As far as expected features like interactivity and whatever else people feel TermKit lacks, it seems like any hybrid terminal that takes this route should really try to implement a quickswitch that lets you fade between a rich terminal and a standard text console, already at your working directory with the same permissions.

Sure, people could just task switch to another running console, but that segments the whole experience a bit more.

</comment><comment><USER41> I just looked at this through the github link. Looks very nice and useful.

Too bad it's very much bound to MacOSX/Cocoa, so this kind of rules it out as general nextgen UNIX/Linux shell.

<comment><USER51> From the article it sounds like most of the heavy UI is implemented using webkit and HTML/CSS/JS. Wouldn't this make it reasonably easy to port to *nix?

<comment><USER41> I have no clue, I looked in the github repos very quickly and saw all kind of scary .m files and I gave up :)

If it's mainly HTML/js/webkit based then it would not be hard to port it to a portable window toolkit such as Qt4 (which has a QWebKit widget...).

<comment><USER4> Doesn't the article say it's TK? Which means it's already got X bindings.

<comment><USER5> TK just means TermKit, sorry.

</comment></comment></comment></comment></comment><comment><USER52> This has a lot of great ideas, and I like the idea of an enhanced terminal in general, but I think it goes too far. Having to reimplement a large number of commands to support this concept of separate view and data streams is complex.

A few ideas I'd like to see integrated into an existing shell/terminal in a backwards compatible way:

* Syntax highlighting/tokenization of the command as you type. Show the different parts of the command you're typing: the executable, the arguments, the pipes, the IO redirects, shell constructs like loops and conditionals, quoted strings.

* Maybe command-specific syntax awareness like highlighting the flags and file arguments differently, regular expressions for sed/grep, awk syntax, etc. This would require descriptors for each command, similar to how autocomplete works?

* Enhanced output formatting, like the clickable paths, displayable images, etc. But rather than modifying/rewriting the program, have a way to describe how to display the output of certain commands. The shell should be able to figure out what the final command in a pipeline is, right?

* Detect and display binary file formats based on the content rather than the filename so support existing commands.

</comment><comment><USER53> Post about TermKit: <http://axisofeval.blogspot.com/2011/05/termkit.html>

</comment><comment><USER54> As a UI designer, even though I've just begun working with terminal, I can't say I like this too much. Don't get me wrong, it looks GREAT, but much as I expected, it goes against a lot of ideas and based on some of the comments, strips a bit of functionaity (a huge no no). I think Steven's intentions are solid, but he's sort of playing with fire on this one. Cool idea, though.

<comment><USER55> Of course he is playing with fire, that's the only way to do real innovation. Remember that this is just a proof of concept, and a very compelling one.

</comment></comment><comment><USER56> it's curious this is on the front page at the same time as oh (or was that on reddit? - can't seem to find it now). <https://github.com/michaelmacinnis/oh>

both allow the shell to use structured data. i like the idea of using json myself (not that keen on the gui parts of the implementation, but moving pipes to something with more structure seems like a good idea). did plan 9 do anything similar?

<comment><USER57> Here's the link to the comments:

<http://news.ycombinator.com/item?id=2559361>

</comment></comment><comment><USER58> Only his response to the AVS question in <http://acko.net/blog/on- termkit#comment-4240> made me realise exactly how powerful this premise is.

TermKit could become my OS of choice.

</comment><comment><USER59> >monospace text just doesn't cut it anymore

Maybe in _your_ terminal world, but not mine buddy.

<comment><USER60> Seriously. But I wish all fonts included a monospaced variant. Why shouldn't I use Helvetica in my terminal?

<comment><USER61> Did you even _try_ to find it?

Google "helvetica monospaced".

</comment></comment></comment><comment><USER62> Very cool. I'm always amazed at how much one can do with a properly composed pipeline and a Makefile or two. The power of pipes + the interactivity of a spreadsheet -- that's what I want in my next gen shell. I'll be interested in seeing how this experiment plays out.

And I do see it as an experiment, not a threat to our way of life. I like to think that the UNIX command-line environment is a local minimum.

</comment><comment><USER63> My god, this looks terrible. There's a reason we're still using text terminals from the 70s-- they work!

I sincerely hope i won't ever have to work with this.

</comment><comment><USER64> This is interesting, but I have doubts. He wants to fix the terminal by 'separating the "data" part from the "human" part'; in practice, using separate visualizers for human display. This puts me another degree of separation away from my raw data and forces me to trust the accuracy of the visualizers.

<comment><USER5> You already trust the accuracy of your visualizers: your eyes. Is it space or a delimiter? Is that a quote or a backtick?

</comment></comment><comment><USER65> TermKit could really help unix overcome the problem of discovery.

On the command line it takes extra steps to discover the switches and arguments that a given command presents. It's easy to miss a specific incantation that will bring forth the full power of a given command in a given situation. Git, for example, has an amazingly rich command. It's hard to discover what you can do so most people end up using just the few commands that they absolutely need.

Just as TermKit offers a selectable list of directories when one types a path, it would be great if it could provide a structured way to build commands invocations, that presents options and perhaps help content as you go.

In addition to helping newbies dive in and get stuff done, it would help more experienced users continually advance their knowledge of how to get the most out of the tools they use.

</comment><comment><USER66> Some interesting ideas there. He doesn't link to discussion of similar projects: I was reminded of Commander S: [http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.p...](http://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.pdf)

I've not been able to build Termkit yet, mind.

<comment><USER5> Shouldn't need to build it, there is a zipped .app included. You do have to build node.js though.

</comment></comment><comment><USER67> I'm just curious if he has to re-write essentially every unix tool in javascript.

I can't really say whether most unix developers would appreciate this. I don't like it and I exclusively use tiling window managers, xterm, and emacs. Though if I wanted fancy features I might try rxvt-unicode or some such.

</comment><comment><USER68> This is interesting and a cool proof of concept. I don't believe that, as you show it, it is something I'd want to live in.

I virtually live in a full-screen emacs (on CLI or GUI). Emacs provides a somewhat nicer shell world than straight up Terminal.app. Emacs has copy & paste, a fully editable window display and its own command history.

Why do I bring this up? Because I feel that your application as currently demoed is not going to help me. I don't want to see GUI icons in general.

What I do like is your connection to the OS display layer. The ability to render out a PDF-inshell is pretty nice. Without having to go grub around for the right configuration, I can't just go "load foo.pdf" and have it pop up automatically.

So I really look forward to see what kind of cool explorations you do.

</comment><comment><USER69> Can't really say this or that about the project. It _looks_ cool but I have no idea whether the user interface would lessen the friction between myself and the computer; it might just as well increase it.

But that's okay. We're not supposed to decide whether the prototype points to the right direction or not; we're just supposed to rant and ramble a bit about it.

However, the question of whether this turns out to be a good idea will be evident when and if TermKit delivers. In this context it means that TermKit or some of its derivatives turn out to be actually more useful than the standard Unix shell.

The indicator would be that instead of a traditional Unix shell, people start using TermKit in order to get more things done more easily and in shorter time.

</comment><comment><USER70> Excellent shortcut for previewing files from the terminal:

      #!/bin/bash
      qlmanage -p "$@" >& /dev/null

Opens any file in Quicklook, ctrl-c to close, or use the mouse. If you want it to stay open, just add final &.

<comment><USER5> Added to my todo list. Thanks, didn't know about this one.

</comment></comment><comment><USER71> I really hope this guy gets hired by Apple. There are some really great ideas here.

</comment><comment><USER72> Looks pretty cool. The problem with the vast majority of these 'rethinking' projects though is they never get finished. That's the hard part.

The classic unix toolset remains because it is finished--that is most major problems and workflow have been ironed out.

Unfortunately I'm time-constrained these days so I'll give it a go when it version five is out and all major issues have been addressed and ported to Linux. For now I'll use fish locally and bash over ssh on my servers. Also, as I can use nautilus to manage and edit remote files using gvfs. So I've already got most of what the project offers working today.

</comment><comment><USER73> It looks like you've re-invented Midnight Commander, which was a re-invention of Norton Commander, which was probably a re-invention of something else.

Which is a good thing! I look forward to downloading and trying it out.

</comment><comment><USER74> Awesome project.

Browser technology is on a tear recently, and terminals are ripe for innovation. For a newborn project, this is an impressive mashup.

The number of dismissive people in this thread shows how disruptive this idea is!

</comment><comment><USER75> I tried to start a discussion on reddit with a very basic version of this idea, which was met with a lot of criticism.

In the end, I'm thinking it would be enough to have espace characters : for embedded graphics, and for some kind of terminal hyperlink. An exemple is file names in grep listings, which I would like to be able to click to get the filename pasted on my next command line.

</comment><comment><USER76> I like the overall idea a lot and am working on something vaguely related (though more like Quicksilver/Gnome-do).

I doubt that a modern approach is going to be able to satisfy the entire historical legacy of the Unix terminal and it probably shouldn't. Everyone who's happy running vi in an ordinary terminal should probably continue to do so.

</comment><comment><USER77> I'd like to see it be able to run a program in the background with the -h flag or --help flag to find at run-time what the available options are to help auto-completion. This way it would be able to support even programs that it doesn't know a priori.

This looks like a fantastic direction to experiment in. Kudos to the author.

</comment><comment><USER78> Looks really good (haven't tried it yet though). The concept is great. I'd like to see some TextMate/CommandT style functionality for file and path completion (I've been thinking cd'ing around in shells has been cumbersome ever since trying commandT).

Some other inspiration could be taken from zsh autocomplete.

</comment><comment><USER79> awesome, my kids and the touch generation would now start using termkit as their terminal in this natural way

</comment><comment><USER80> 主意很棒,十分佩服作者所做的工作,之前我也有过类似的想法

为了不说错太多,我不知道这里是不是允许用中文?

.

图形化取得的成功有目共睹,而偏偏终端保持纯文本的简单

从学习linux的经历和这么久接触互联网看

.个人用户接触到的图形视频信息远多于文字

命令行有着天生的优越性,图形界面的鼠标操作完全显得累赘

同时另一方面命令行却难以控制界面又显得苍白了太多

即便是掌握了多数常用的快捷键也难以足够高效

对于一个整天上网并且忙碌于控制各种信息的人来说

.不能获得快速的操作方式是非常纠结的一件事情

.

在思考当中我期待着命令行可以和图形界面深度的结合

.就像是语音搜索和移动平台漂亮的界面结合那样

显然,命令行更精确,能做更多的事情,效率更高

期间关注了Ubiquity和Vimperator这类在浏览器的实现

.从效果上说,功能实在不足以让人将日常的操作迁移上去

.总归是一个好的尝试,我期待这更多

.

所以我认为作者的方向与上文两个插件走在同方向不同的路上

最终也许图形与命令深入契合之后便利更加明显

.也有可能此类产品难以被普通用户接纳

有点像从js console里面直接抓去和操作界面元素的意思

我想那么的未来总是会被不同的各种创意实现

.最终图形和命令的合作亲密无间

.

youtube的搜索参数也有点这意思

我附上Ubiquity和Vimperator的视频吧

[http://www.youtube.com/watch?v=r54O47ZR64A&hd=1](http://www.youtube.com/watch?v=r54O47ZR64A&hd=1)

<http://youtu.be/XI1XwdtmtQY?hd=1>

</comment><comment><USER81> It is pretty (and I want it for linux so I could use it!), but I think the real useful idea here is the separation of data out, and display out. If we could have that on a regular shell it would add a lot of usability. For this idea alone, my hat is off to you sir.

</comment><comment><USER82> The problem with this fancy terminal is that the standardized tools, like cat and ls get abused in very bad ways...

What's the problem with ImageMagick's display for example? Or defining a new command that does pretty printing of images, like, say pls.

Don't fuck with our tool-chain buddy!^_^

</comment><comment><USER83> Great. Looks awesome and is much needed.

It should be possible to map the output for the Current Working Host too.

So:

      home> ssh Server1
      Server1> ls
         server1file.bin

that

      server1file.bin

should be mapped to

      scp Server1:server1file.bin

<comment><USER5> I'm not sure what you mean. If you like, you can describe your idea in more detail and open an issue on github: <https://github.com/unconed/TermKit/issues>

</comment></comment><comment><USER84> The author talks about the hazards of parsing text streams, then talks about parsing ls, which is impossible to parse because there is no way of differentiating a newline in a filename from one that delimits the end of a line of output.

</comment><comment><USER85> This is just fantastic. Great work. I look forward to see how it evolves further.

</comment><comment><USER86> Amazing work. This kind of API has potential to be a real game changer. Imagine what this style interface could do for things like Image, Audio and Video processing. Can't wait to watch see this progress.

</comment><comment><USER87> This will replace the terminal as much as the microwave replaced metal over fire for cooking or as much as synthesizers replaced real instruments in music.

<comment><USER62> Have you listened to the radio recently? ;)

<comment><USER87> Off and on in the car, but that's irrelevant. I'm not claiming every technology is irreplaceable, but that not all evolutions or supposed improvements of technologies REPLACE their predecessors.

</comment></comment></comment><comment><USER88> Hmmmm. It's pretty, but sort of limited at the moment. I think it could be used sort of like training wheels for unix newbies.

</comment><comment><USER89> OH MY GOD! THIS GUY WANTS ME TO CHANGE THE WAY I WORK!

I"VE BEEN WORKING THE SAME WAY FOR 20 YEARS

YOU CAN"T MAKE ME CHANGE!

CHANGE SCARES ME!

20 YEARS AGO MY TERMINAL DIDN"T HAVE LOWERCASE, COLOR, OR WINDOWS. WHY HE WANT ME TO CHANGE!!?!?

(Damn, I've never seen a group of people so change-adverse and closed minded about trying new things as the software developers that are in the business of making new stuff! Geeze! Download it and give it a try before you post a comment!)

</comment><comment><USER90> Wow this is awesome. This project basically just showed me everything I never knew I wanted.

</comment><comment><USER91> Awesome highly recommended Linux terminal, allows GUI splitting and has very almost 100% key-shortcut coverage: <http://www.tenshu.net/terminator/>

</comment><comment><USER92> Inspiring! And gorgeous look and feel to the site.

</comment><comment><USER93> More proof that people who don't understand UNIX are condemned to reinvent it, poorly.

<comment><USER5> People keep saying that, and then fail to tell me any solid reason why I'm wrong.

</comment></comment><comment><USER94> one word: genius!

</comment><comment><USER95> it kind of defeats it's own purpose.

cat a.png -- show the image in a tiny terminal, but I have a billion pixel screen.

why not just open it on the image viewer window?

you advocate this even for editing plain text in vim!

think that if you had learned to use X your days would be more productive... maybe not as cool...</comment>


UnblockOz: Helps Australians reclaim their unfiltered Internet access - <AUTHOR> https://unblockoz.org <comment><USER3> Much, much more frightening than website blocking in Australia is this:

[http://www.abc.net.au/news/2017-01-05/telco-industry- pushes-...](http://www.abc.net.au/news/2017-01-05/telco-industry-pushes-for- metadata-collection-changes/8162896)

Our esteemed government told us universal metadata collection was for fighting terrorism. Then, over the Christmas period when the public is disconnected from politics, a sham enquiry was held to open up metadata to civil courts (i.e. for copyright, divorce cases etc).

Needs a bit more than router DNS changes to protect one's self from this. VPN at a minimum. Given our already rubbish speeds, it's really annoying to cop a further speed and latency hit from a VPN (along with the $$$ it costs).

<comment><USER4> Australians simply don't care about this shit. They've lived in an industrialised colony, with all its rewards, for too long - as long as they're still able to live the good life, who cares what the government gets up to ..

Its a shame, because Australia has, in many ways, a culture that could produce great things. But its still ham-strung by its dependence on colonialist thinking in the halls of power.

<comment><USER5> What do you mean by 'colonialist thinking'?

<comment><USER6> Only a guess, but I think it means "the government knows what is best for its citizens".

<comment><USER7> That is hardly unique to Australia. Britain, Canada, NZ all have no problem at all with censorship, so much that they will even censor fiction.

These countries, one of whuch I am a citizen of, have not a single strand of libertarianism in government nor populace, and it's a shame.

<comment><USER8> Others would disagree that libertarianism is absent, and that its absence is a shame, e.g. [1]. Indeed, they say that the influence of libertarianism is responsible for some of Australia's governmental problems, most conspicuously on display this past week.

[1] [https://www.crikey.com.au/2016/06/01/rundle-the-liberal- part...](https://www.crikey.com.au/2016/06/01/rundle-the-liberal-partys- inevitable-decay/)

<comment><USER9> Liberals are not very libertarian; especially under Malcolm Turnbull. There is a small strand of libertarianism and that's the Liberal Democratic Party.

Australia has an unsustainable property bubble that has made a large chunk of the middle class very wealthy. This has shifted the culture from self reliance to 'don't rock the boat.' This alone is an anti-innovation tragedy.

The bubble will pop eventually and the taxes will go up. Aus can't print new money and we have an untouchable entitlement culture. If you can't pay the new taxes they will use the firewall to block your site. It's going to be a mess and I wish them the best of luck.

<comment><USER4> You nailed the entitled thing. I'm a born and bred sand groper .. So .. After quite some time abroad, getting to know the species, my sojourns back home to Australia led me to truly cringe at just how entitled folks are, down under. It was a bit humbling to have been driven off the edge of the continent by the culture, even though the land itself pulled me with much gravity, wave by dune by storm ..

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Something very unsettling about a government mandating ISPs block/sniff/track your internet traffic on behalf of the film industry.

If only the government was equally motivated to remedy injustices incurred by those who aren't already filthy rich.

<comment><USER11> Don't worry this isn't a concerted effort to actually block things. Its a pretty weak effort to go through the motions.

If your tuned into this debate at a federal level there are a vocal bunch of senators bemoaning the Australia tax that our geography puts on us. These guys put out info on how to use vpns and avoid geoblocking and such for the masses.

Best in show example: Adobe software and Game of thrones.

Australians want to work, trade and play in the free first world. And until we get that we'll steal everything that isn't nailed down.

<comment><USER12> A bunch of convicts the lot of us.

<comment><USER5> For the record, we stopped being a penal colony about 15 years before the US stopped being a slave-using nation...

<comment><USER13> So, not yet then ... ah, you meant a _legal_ slave using nation ...

<comment><USER14> Article is about Australia yet people still have to take jabs at the US.

I'm not really sure what you mean anyway.

<comment><USER15> Probably talking about things like this: [https://www.theatlantic.com/business/archive/2015/09/prison-...](https://www.theatlantic.com/business/archive/2015/09/prison- labor-in-america/406177/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> As an Aussie I find this pretty funny. Since they passed the law to make ISPs store your data ( which was a warning shot to piraters from my POV ) not many people's behaviours changed. Ie people still pirated. The difference between simply logging traffic and blocking certain sites means instead of being able to watch what I do, I'll be sign up to a VPN and they won't see any of my traffic. If anything blocking these sites is great as it will force lazy people to use VPNs.

Good work to these guys making it easier to get started.

<comment><USER4> As an Aussie, I find your lack of distrust over this issue, disturbing. We Australians have a long history of letting government get away with heinous actions; as long as the "she'll be right mate" meme still holds our brains under the tap, we'll never get the right kind of mad required to break the chains of the colony. Honestly, this isn't something to laugh about.

<comment><USER17> agreed - there is a kind of socially enforced apathy here as well as a separation of 'us' and 'them' when it comes to politicians and government - <USER2> let them get away with murder and never hold them accountable because raising a ruckus and making a big deal out of a thorny problem that requires a nuanced solution is seen as a sort of intellectualism. and your average Australian fucking hates an upstart know-it-all wanker.

</comment></comment></comment><comment><USER18> Wow, I didn't realise this had started. If I go to [http://thepiratebay.se](http://thepiratebay.se) I get this message:

Copyright Notice ACCESS TO THIS WEBSITE HAS BEEN DISABLED BECAUSE THE FEDERAL COURT OF AUSTRALIA HAS DETERMINED THAT IT INFRINGES OR FACILITATES THE INFRINGEMENT OF COPYRIGHT.

Please access the content you are seeking via licensed sites – www.digitalcontentguide.com.au provides information about many sources of licensed content.

<comment><USER19> I think it only affects certain ISPs. I am with SkyMesh and thepiratebay.se resolves fine.

<comment><USER20> Escapenet (small provider) works fine as well.

</comment></comment></comment><comment><USER21> For those that are interested, the blocks were ordered in early December by Australia's Federal Court.

The court was given the powers when the Australian Copyright Act was amended in 2015.

The case was heard over several days, and while it was inevitable that it would order the sites blocked (there was no opposition to the blocking application, as such) - the copyright holders didn't get everything they wanted.

They wanted an injunction that they could effectively add to or amend over time (such as when mirror sites pop up), but the Federal Court didn't go that far. The blocking orders require a certain level of oversight.

It seems that new domains will require either a new case, or another affidavit to be filed. We're yet to see what the process will be.

Also there's a multi year timer on the domains that are blocked. Rights holders will need to file an application to keep the blocks in place.

Many people have discovered the blocks aren't really that effective. It seems for many ISPs a simple DNS change will get around it. The court didn't order a specific technical means to achieve the blocks, leaving it up to ISPs to choose. They've obviously chosen methods which aren't all that effective.

<comment><USER22> Additionally, the copyright holders were ordered to pay costs incurred by the ISPs in implementing the block.

I think the case was a good balance between upholding the law and making it clear that it wouldn't be a system over which the copyright holders have total control.

</comment></comment><comment><USER23> This is a world wide issue in the free world at this point, but Australia is stuck in the 90's when it comes to the internet.

We have some business there and find everything about Australia ridiculous: ISP monopoly; hosting costs; licensing and internet related law... We ended up hosting in Singapore to serve our Australia needs.

AU needs a major revamp on everything internet.

<comment><USER4> I'm Australian, and I decided 3 decades ago to not live there any more, because of what I saw was happening with the Internet and the way the country was crippling itself in comparison with the rest of the world. No amount of cheap plastic shit from China can keep me interested in a country so self- absorbed, and at the same time so utterly ignorant of the clear repression holding the nation back.

<comment><USER5> What wonderland did you move to?

<comment><USER4> Didn't matter, just moved. (I've lived all over the world.)

</comment></comment></comment></comment><comment><USER24> I've helped a half-dozen friends and family members in the past couple of weeks fix their net filtering. I usually do it by logging into their routers and setting their DNS servers to OpenDNS or Google.

A few things i've noticed. Most people don't know this is something that can be fixed. I think that will change in the same way adblocking has spread (ublock is a well-known brand amongst my non-tech family and friends).

Second is that the DNS change will likely only be a temporary solution for this first stage of blocks. It is only a matter of time before more sophisticated blocks are put in place - and there are other methods mandated by the law available after DNS filtering (including IP blocks)

I've also noticed an irony in this situation. The Australian government passed legislation for the copyright protection internet filtering at around the same time they passed their ISP level metadata retention laws.

The irony is that because of the copyright blocks Australians are seeking and learning about solutions such as Tor and VPN's, which make the second set of metadata retention laws less effective.

One of the positive side effects of the laws is that it doesn't address the demand for content (Australians are well known pirates) and users will seek out workarounds which will have the effect of increasing awareness of privacy issues and technical workarounds.

I tend to agree with Ed Snowden when he says that solutions to privacy are in encryption and technology - not in politics. Unfortunately governments are going to do what governments do - either in the open, or in secret.

</comment><comment><USER25> At this point in time, ISP's are just doing DNS redirection. You can get around the restrictions by setting your browser's or router's DNS to Google's on 220.127.116.11 and 18.104.22.168.

</comment><comment><USER26> The easiest is just changing your DNS servers to 18.104.22.168.

I wish iOS allowed you to change DNS for celluar networks.

<comment><USER10> Can someone confirm that this actually works? Seems like a pretty weak attempt at a block if true. I think the real problem is them sniffing your traffic.

> I wish iOS allowed you to change DNS for celluar networks.

Are you torrenting from your iPhone?

<comment><USER27> Confirm, it's just a DNS block like previous attempts by the AU Gov to block stuff.

If you're on a Apple device you probably need to use VPN to specify an alternate DNS and either route your traffic through that VPN as well or just use it for DNS.

</comment></comment></comment><comment><USER28> Awesome to see this is an informative and helpful guide rather than a cash- grab service. Well done and keep up the good work!

<comment><AUTHOR> Thanks for the kind comment, this is what keeps us running

</comment></comment><comment><USER29> Same deal in the UK. I wonder how long until the US goes down the same route.

I'm quite surprised that they've gone down the DNS based filtering route. I'd expect that to change in a few years time.

I recommend investing in a VPN service. They're relatively cheap. And if you pick the right one, the bandwidth is generally pretty good.

<comment><USER28> At some point all the interesting/useful countries to exit the VPN will be censored. Then it's game over.

<comment><USER30> No - then it's a business opportunity for smaller countries, with "looser" copyright rules and enforcement, to build a world-class VPN industry. The Switzerland of VPNs is a historical inevitability: even the rich and powerful need it.

<comment><USER13> And then we'll get countries being strong armed by "Western Democracies" to ensure top-flight talent and media execs still get paid 200x what the poor schmucks doing the actual work get paid.

</comment></comment></comment></comment><comment><USER31> It's been like this in the UK for ages, now people have to google 'pirate proxy' instead, it's at least 3 extra clicks - when will this horror end...

<comment><USER30> Well, from this year you also need a VPN, because all your traffic is logged. I'm looking forward to Comrade "Shared Society" May to force a proper Great Firewall any day now.

<comment><USER32> The porn blocking is the first step towards that. First they came for the porn...

<comment><USER33> Seeing these block pages come up in Australia, a free country, is awfully troubling. I shudder everytime I had to see this: [https://4.bp.blogspot.com/-3G10OAwNPgw/VD- Kzl_coHI/AAAAAAAAA...](https://4.bp.blogspot.com/-3G10OAwNPgw/VD- Kzl_coHI/AAAAAAAAAkQ/CBlC7mzckKI/s1600/Block%2Bsite%2Bmanagement.PNG)

</comment></comment></comment></comment><comment><USER34> I think that government censorshop is bad for free speech.

If you have two dns services one normal and one with blacklisted ip, then you can loop over the domain names in both dns services compare the result and find the blacklist. Easier for reverse dns loopups, but not impossible if you have a list of forward dns names.

</comment><comment><USER35> This is what it looks like when your government is beholden to Rupert Murdoch.

</comment><comment><USER36> My ISP (TPG) is using DNS and IP blocking, had to use a VPN to get around the block. The site mentions DNS as a way to unblock, this doesnt work anymore

</comment><comment><USER37> So, what are numbers I can call to leave messages of international support?

</comment><comment><USER38> this is really a bad news. Yes ok tpb can be used to download pirated content but there's also some content that are not pirated content on the site too. Nobody should be allowed to shutdown site or flag as illegal without true charge. It sad where in 2017 we still live and lose time with people that don't wont go forward and do 5 step back. What next? blocking bitcoin because this ruin the bank economy?

<comment><USER39> Doesn't matter that much. This move was to deter the mainstream downloaders who have TPB saved as a bookmark and don't know how, or can't be bothered to learn how to access it other ways.

Blocking the "click to download this new release movie" users probably did prevent a few downloads.

</comment></comment><comment><USER40> Why do they like to call it "censorship" when they just mean "piracy websites"? It's not like they're keeping you from publishing your thoughts about the government and the establishment, you just want to download series for free.

I don't mean to say you shouldn't be able to download your favourite series for free, but please don't use words such as "censorship" that make it look like the gov is threatening to send you to a gulag if you say the prime minister likes golden showers.

<comment><USER12> Do you understand censorship? This clearly fits within censorship as it's considered politically unacceptable.

censorship, noun: the suppression or prohibition of any parts of books, films, news, etc. that are considered obscene, politically unacceptable, or a threat to security.

<comment><USER40> This is not about the government "suppresing part of a film that is considered obscene" or "removing news articles that are politically unacceptable".

This is about you wanting to download movies or series without paying money to the people who made them. Movies or series that are completely legal to watch and sell in Australia, as long as you pay the people who worked to make them.

Too many people masquerade their freeloading as political activism to feel superior. Sticking it to the man, eh?

And once again I respect the right to download or upload whatever you want, but making it look like you're fighting the big brother censorship when you just want to watch game of thrones, a show that is completely legal to watch in Australia, without paying for it is... childish

<comment><USER41> > This is not about the government ... "removing news articles that are > politically unacceptable".

That's actually part of the problem. The government should close down illegal establishments, and not just be blocking access to them.

The other part of the problem: Once the gov can tell the ISPs what to block (a) the block list must be secret and (b) the process can be very easily abused, with 'overblocking' being the standard excuse.

<comment><USER40> Your government can't close down illegal websites in other countries, that's why they're blocking them.

<comment><USER39> There are no "illegal websites", only some illegal activity on legal websites. Just like there's some illegal activity on legal roadways, but we don't block the roads do we?

<comment><USER40> Roads are used for a legal purpose by >99% of their users, and even though you could upload Creative Commons content to The Pirate Bay, most of it is illegally shared software/entertainment.

The same they would not block Telegram nation-wide just because some users are using it to upload movies to public gruops (yes, it happens) because most of the users just use it to talk to their friends.

<comment><USER39> > _" most of it is illegally shared software/entertainment"_

I prefer to think of it as "conveniently shared". Here in Australia we have a problem with lack of convenience around legal avenues of digital entertainment, so there's not exactly an equivalent legal alternative to something as easy as downloading. It's a fragmented mess of services if you choose to play by the rules.

Regional restrictions, lock-in contracts, and free-to-air "rights" to particular programs exclusively means every platform plays a tug-of-war with viewers, trying to get their subscription dollar or eyeballs on advertising.

People will find the path of least resistance when the commercial interests around them close in with deals and promotions and hype we can't possible keep up with or remain in tune with. So we turn to the internet.

Not everyone is "illegal" all the time. I buy blu-rays of shows I really liked that I previously downloaded. Exposure to content otherwise never discovered has a value we are not seeing factored in to these arguments.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> VPN is another option.

</comment><comment><USER43> The ones who need help are the Aboriginal people. Stop with the aboriginal genocide!

<comment><USER40> Aboriginal genocide? In Australia? Is this even a thing?

<comment><USER44> It wasn't far off.

<comment><USER40> I am asking because the Wikipedia article about "List of massacres of Indigenous Australians" claims that hasn't happened in about a century.

<comment><USER45> It's a common trope of the far left in Australia.

People aren't actually being killed.</comment></comment></comment></comment></comment>


Computer Science in the DPRK [video] - <AUTHOR> http://media.ccc.de/browse/congress/2014/31c3_-_6253_-_en_-_saal_2_-_201412292115_-_computer_science_in_the_dprk_-_will_scott.html#video

<comment><USER2> Good talk, but I wish there was a deeper dive into what it was like living and working in the DPRK. For folks more interested in that, check out this great talk from HOPE last year: [https://www.youtube.com/watch?v=v_HXPm- PN1g](https://www.youtube.com/watch?v=v_HXPm-PN1g)

</comment><comment><USER3> For me the interesting part was the tablet he brought back from DPRK. It contained 70+ books with their leader' speeches, but they somehow customized the Android so it is not possible to extract them :D

</comment><comment><USER4> It was interesting to hear he never saw red star OS. From the recent link, I was under the impression that red start was the defacto OS of DPRK.

And the have their won TLDs. (top level domains) .web sounds cool

<comment><USER5> I don't think you watched too far into the talk :)

He spends a while demonstrating Red Star OS in a virtual machine.

<comment><USER6> No you misunderstand. He's referring to not seeing RedStar in use DPRK.

<comment><USER5> Yeah, fair enough. Though I seem to recall (I was at the talk) that the speaker didn't get to see much of North Korea anyway.. but I'd have to re- watch the talk to be sure!

</comment></comment></comment></comment><comment><USER7> a probably very different person from the speaker has since released RED STAR OS 3 as a torrent.

[http://pastebin.com/cHAzyTE7](http://pastebin.com/cHAzyTE7)

[http://www.northkoreatech.org/2014/12/30/red- star-3-0-deskto...](http://www.northkoreatech.org/2014/12/30/red- star-3-0-desktop-the-install/)

</comment><comment><USER8> "uhhh".

Makes it really hard to watch this.</comment>


The two types of people who cause the biggest grief in open source - <AUTHOR> http://sayspy.blogspot.com/2010/07/two-types-of-people-who-cause-biggest.html <comment><USER2> Although this submission was first, a later submission has got the comments (all 2 so far):

<http://news.ycombinator.com/item?id=1482950>

TANJ</comment>


Show HN: Create your own HN style site (for business or any online community) - <AUTHOR>

This is a project I just launched - would love to get any feedback and see how/if it would be useful for people.  Thanks!<p>http://ribbot.com <comment><USER2> Nice!

Feedback:

\- You should link to a demo page and/or have screenshots. As you mention in the HN comments, the Support page is a demo page, but that's not obvious from the site itself. Also, the demo page should have a decent amount of sample content, comments, etc; the Support page currently has one entry and zero comments.

\- There should be a sign up button on every page (e.g. the Pricing page). The header is one possible location.

\- On the one hand it makes sense that Ribbot Support's Home page is Ribbot Support, on the other hand it feels weird that after I click on Ribbot Support, there's no way to go back to Ribbot.com without hitting the back button.

\- On the pricing page, change "Num Users" to "Number of Users".

\- The pricing seems a little excessive at the upper tiers, but that's just a personal opinion. Usually when prices go above a few hundred dollars, pricing charts will say something like "call us!"

\- For ad-supported vs paid, it's not clear what kind of ads there are, how obtrusive they are, etc.

\- Nice domain name. It's screaming for a cute frog logo =)

\- Just a personal opinion, but you should add a little background color to the site. Nothing glaring... but there's too much white right now, IMO.

<comment><AUTHOR> This is great advice, thanks!

</comment></comment><comment><USER3> I can suggest some features(I need them for one of my site) :

1\. Wordpress/buddypress integration through some plugin. I want it to use my wordpress site accounts for login.

2\. own domain/sub domain support(like tumblr)

3\. Custom theme(like tumblr)

4\. User role and authorization(make some users moderator)

5\. I feel pricing is too high for ad-free versions. Paying $49/month for 1000 users look like too much investment without enough returns. You may want to reconsider pricing.

</comment><comment><USER4> Very nice. Not really related to what you've created but I'm really liking the use of Bootstrap in many of these kinds of projects. Back to ribbot, I created an account but my name is "New User" and I see no way of changing this.

Edit: I see going to profile shows an option to change the user name. You should consider sending the user there to set a user name upon first sign in.

</comment><comment><USER5> Nice!

Bug report: Submitting a new post with just a title, and without the text gave me a 500 error. When I clicked back to fill in the text, the submit button was still disabled showing the "Submitting" text. So I had to reload the page.

</comment><comment><AUTHOR> Clickable <http://ribbot.com>

The support page on the site is also a demo of the product: <http://support.ribbot.com/></comment>


Visual Studio Tools for Git - <AUTHOR> http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/30/getting-started-with-git-in-visual-studio-and-team-foundation-service.aspx

<comment><USER2> This looks really good. At work we're using Git with GitHub Enterprise, and while training has solved most problems there's still the occasional complaint about the tools.

I hope this works well in the VS workflow, Microsoft are making some really great steps in the dev tools space.

</comment><comment><USER3> I have to see yet good SCM (I use mainly P4 at work, with little git) integration in Visual Studio. I've tried two or three different Perforce ones, and over the time they stop working.

Checking out from the command line, or simple shortcut to do it.

<comment><USER4> There are no good source control integrations for Visual Studio. The whole system is just fundamentally broken. If you're not convinced - I mean you in general, dear reader, malkia clearly has this figured out ;) - all I have to say to you is, "LOL binding root".

Over the years, I've managed to convince several people to give up Visual Studio source control integration, and, without fail, it takes them two days, at most, to realise that this one small step has made their lives MEASURABLY BETTER. After weeks, maybe months of laughing at my Alt+Tabbing to Alien Brain to check files out, or fumbling with p4v, they find out that this is still better than dicking about with whatever crap Visual Studio is pulling on you today.

<comment><USER5> I find "Git Source Control Provider" to be a very decent plugin to work with. What's so wrong about it ?

<comment><USER4> Well, I'm guilty of shooting my mouth off about something I haven't revisited recently, so perhaps things are better these days. I haven't used source control integration with VS2010 or VS2012. Sometimes, when I find something to suck, I still revisit it every now and again, just in case it's since improved. The Visual Studio source control integration experience was just so reliably, hellishly awful that I never saw the need.

(The experience could well be better if you have a distributed system. Much of the plugins' flakiness seemed to be come from having to talk to a server (downtime or network connectivity problems always caused issues), and from the maintenance of accurate check in/check out information - both non-issues with a distributed system.)

<comment><USER6> Have used both ankhSVN [1] w/ VS2008 extensively over the last few years and lately using Git Source Control Provider [2] w/ VS2010. Both tools have been excellent for me, have very rarely needed to drop down to external tools. YMMV

[1] <http://ankhsvn.open.collab.net/> [2] <http://gitscc.codeplex.com/>

</comment></comment></comment></comment></comment><comment><USER7> I wonder how this will work with SSH keys. I've been using Git Extensions (<http://code.google.com/p/gitextensions/>) with VS 2010 for a while now and have been pretty happy with it, but it has taken a long time for the SSH key support to get to a usable place.

<comment><USER8> (Libgit2 contributer here.) Currently, SSH support is in-progress in libgit2 (what all of this is built on), so there _is_ no dealing with keys right now. :) Once the API is in place, it should be fairly straightforward for the VS team to deal with keys in a user-friendly way.

</comment></comment><comment><USER9> Now we have git, MVC 4 (now open source) and better unit testing support. Makes me think these are the results of some kind of long fought battle by a small group of progressives inside Microsoft.

Of course, that's just my imagination.

</comment><comment><USER10> In my opinion in git commit history is central and file tree is secondary. Something like GitExtensions serves me better than Git SourceControl Provider or TFS until they reallize about it.

</comment><comment><USER11> I'm not smart enough to understand most of this, but it looks neat. Does this mean you can use Git from VS without paying for Team Foundation Server?

<comment><USER2> Yes

<comment><USER11> That's awesome. Thanks!

</comment></comment></comment><comment><USER12> nice!</comment>


Microsoft to devs: Whatever you're doing in Linux, Windows will soon do it too - <AUTHOR> http://www.techrepublic.com/article/microsoft-tells-devs-whatever-youre-doing-in-linux-windows-10-will-soon-do-it-too/ <comment><USER2> "Pay for our OS, we promise you'll be able to do all the stuff you can already do for free real soon now at only a minor performance penalty!" seems like a really peculiar advertising approach. Don't get me wrong - it's a _good_ thing on net, but it still doesn't provide the kind of justification that happens in other computing sectors (for instance: "I want to play games only available on Windows").

</comment><comment><USER3> I'm a sysadmin/system programmer. I need to do weird stuff to my operating system, like setting up software RAID or NIC aggregation or IP routing. I doubt I could do the same to Windows. All at the expense of spying on me and showing me advertisements.

</comment><comment><USER4> LOL no it won't:)</comment>