Weekly Edition
Return to the Press page
| |||||||||||
|
| |||||||||||
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)
Free Software Magazine looks
at a new application called Hotwire. "Whenever I first stumbled
across upon Hotwire (released under the GPL 2 for the user interface and a
permissive MIT-style licence for everything else), certain childhood rhymes
sprang irresistibly to mind: Jack of all trades, master of none, Jack
Spratt could eat no fat, his wife could eat no lean, amongst them. The
problem is actually trying to give a pithy and accurate definition of
Hotwire without tripping up yourself, so who better to describe it than its
developer, Colin Walters of Red Hat, who has described Hotwire as "an
object oriented hypershell" and "a modern Python-based extensible
crossplatform shell environment"."
(Log in to post comments)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 24, 2008 21:51 UTC (Tue) by alextingle (subscriber, #20593) [Link] What a completely pointless exercise.
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 24, 2008 22:25 UTC (Tue) by walters (subscriber, #7396) [Link] You think that nothing better than the Unix terminal + shell can ever be created? There are quite a number of advancements over the VT100/Unix paradigm; notably result capture vs dumb display, optional use of the mouse, integrated high level language (in this prototype, Python), use of the modern free desktop, etc.
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 24, 2008 23:21 UTC (Tue) by nix (subscriber, #2304) [Link] I'm interested in how this project will avoid the Emacs Trap (also known as the C++ Trap, Java Trap, et al; perhaps 'VM Trap' is a better word). Namely, my understanding is that Hotwire commands are code written in Hotwire-specific Python... as against a Unix world in which *arbitrary executables* or scripts in arbitrary scripting languages that merely read and write from stdin/stdout can be used, regardless of implementation language. (The real problem here is that Unix has a standard mechanism for exchanging text streams, but none for exchanging objects, so you're necessarily locked into *some* language's object model from the start, and other languages are necessarily second-class citizens from then on. I really like the idea of an OO-based pipeline, because it avoids quoting and serialization problems completely, but I've never been able to figure out a way around this rather killer problem. I'm not satisfied with a one-language shell replacement: no one language is good enough.) Also, I'm afraid I tried using Hotwire for a while earlier this evening and found it intolerable. I thought I'd find it really nifty, and at first it was: but it soon became clear just how many of the commands I type in are elaborate pipelines, and whenever I tried to type one of them in, *wham* cognitive dissonance and quoting hell. The existing sh command seems like it could only work well if you're not using both " and ' quotes in your shell pipeline. I'm not really sure how to fix this, either: perhaps write the command out to a a one-line shell script in a temporary file and execute it, yuck. You could say, sure, use a normal shell for that sort of thing, but that means I'd be hopping between shells every five lines or so, and synching the current directories et al would be very annoying. (Also, did I miss something or is there no analogue of the POSIX-extended backquote operator $(...)? I'm sure I must have missed something here.) (... hm, I just noticed the 'language will be overhauled' thing in the Wiki, in which case I'm moaning about stuff you're already perfectly aware of and should shut up and go to bed before I make any more of an idiot of myself. Yes, what a good idea.)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 25, 2008 1:55 UTC (Wed) by walters (subscriber, #7396) [Link] Thanks for trying it out and for the very thoughtful response! On VMs and Hotwire/Python. So right now, the commands are really nothing more than shortcuts to ordinary Python functions. The idea is basically that nowadays, developers and system administrators code to library APIs, and that a lot of /usr/bin is just wrappers around those APIs (e.g. /usr/bin/GET, /usr/bin/lshal, /usr/bin/gconftool-2, /usr/bin/gvfs-ls, etc.). I chose to prototype Hotwire in Python because Python has for a mix of historical, cultural, and technical reasons had good bindings to various parts of the OS stack up through the desktop. Mono is also doing well there nowadays, and the JVM is catching up fast. But anyways, so the basic idea is that now we have these libraries, what if your shell was more of a *direct* interface to those libraries, and what if it made it easier to transition to using those libraries, just like how you would in a real program? The simple pitch is the same one that's been well known for years; "ps" is easy to type and inspect interactively, but a pain in the butt to try to parse as a robust API from a program. Now there are two problems. 1) Only Python is supported 2) Hotwire is shipping the commands On 1), my long term plan is to switch to either OpenJDK or Mono. The JVM and .NET have been co-evolving for the last few years, and really legacy multi-language capability today on both is pretty good. JRuby on the JVM and IronPython on .NET demonstrate that today; Jython/IronRuby are both gaining steam. And there are several runtime-native new languages like Scala/Clojure for the JVM and Boo/F# for .NET that show fundamentally different languages can run. So yes, the long term idea is that the JVM/.NET bytecode, calling conventions and runtime are *the* system. With the ability to call into legacy external binaries in /usr/bin as unicode streams though. 2) I would like to standardize the command system such that *the library* can ship a command. Here's a post about how you can take an ordinary Python function and add a Hotwire-specific decorator to it to make it callable from the shell: http://groups.google.com/group/hotwire-shell/browse_threa... Java class file annotations or .NET attributes obviously could fill this same role. Now as for the cognitive dissonance/quoting hell...can you give some specific examples? There is sadly no analogue of $() or `` yet. I need to figure that out. I do miss it myself sometimes too. I don't blame you for getting frustrated now; there are a mix of bugs and not-implemented things. To be honest lately what I've been spending time on is trying to "productize" my SSH client that came out of this work (new website is http://www.gnome.org/projects/hotssh/, will make a release soon). But anyways, it is fun to hack on Hotwire and really my end goal is just to push the developer/operating system boundary further. If Hotwire doesn't succeed itself but someone else gets inspired to create something *actually new* rather than just what has been done in the VT100 emulator box, I'll count that as success =)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 25, 2008 2:33 UTC (Wed) by drag (subscriber, #31333) [Link] I don't really see it any different from any other Unix shell in terms of python-specific commands. Every shell has their own set of built-ins. Stuff that conflicts and may break scripts and such. Pointing at some symbolic link vs trapping commands vs wrappers around library functions.. what's the difference? Different ways to accomplish the same goals. The only thing I'd care about is avoiding depending on the mouse for _anything_. My favorite media player is Mplayer for a very good reason (and it's nothing against gstreamer...). Non-use of the mouse == faster + less chance of ruining my wrists. It's beyond just personal bigotry, there is a serious ergonomic issue going on here. Also.. if it was possible to use this hotwire from a virtual console or just a plain xterm, then that would be fantastic. Screen beats the absolute living crap out of any sort of tabbed system I've ever seen in my life. Basically I have nothing against nice friendly gui systems.. that's very good. Even if you still end up requiring a special python gui to run hotwire, I would like to be able to disable the tab bar, menu bar, and the scroll bar and still be able to use it. Just my 10 cents. If you ignore me I am not going to start badmouthing you or anything like that. :)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 25, 2008 10:16 UTC (Wed) by nix (subscriber, #2304) [Link] Every shell has their own set of built-ins. Stuff that conflicts and may break scripts and such. Pointing at some symbolic link vs trapping commands vs wrappers around library functions.. what's the difference? Different ways to accomplish the same goals.Yeah, but this isn't really like that, not yet. This is like it would be if you had a shell with extensible builtins (like bash or zsh) but for which you needed to know if commands were built-in or not, because built-in commands had a different syntax. (As an aside, has anyone ever seen the loadable dynamic builtin stuff in bash used? I've seen loadable builtins in zsh used occasionally, but never the corresponding bash feature.)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 25, 2008 17:56 UTC (Wed) by drag (subscriber, #31333) [Link] It depends on how you look at it. With python you avoid the source --> compile --> linker cycle. You just edit the source code, add your functions to a library or to a directory, and the compiling and that sort of thing is done on the fly. With bash you'd have to get the source code and edit it to extend it, unless you use a plugin or extension feature like you mentioned just now. That being said, I like the idea of a script-based shell. It's very similar to Emacs.. the major difference here is that hotwire isn't going to pretend its a editor to trick programmers into trying it out. :) After playing around with hotwire I've decided that I like the concept very much. If the keybindings can be made to be theme-able then it should be simple to make my own screen-like, vi-like bindings. Any thoughts on a mode-based shell? :)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 26, 2008 12:34 UTC (Thu) by mish (guest, #52694) [Link] > After playing around with hotwire I've decided that I like the concept very much. If the > keybindings can be made to be theme-able then it should be simple to make my own screen-like, > vi-like bindings. > > Any thoughts on a mode-based shell? :) I've typed up some thoughts before in this thread: http://groups.google.com/group/hotwire-shell/browse_threa... I'm hacking on other stuff at the moment though, so don't hold your breath. But new hackers are welcome if you want to help move this forward :)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 30, 2008 19:05 UTC (Mon) by massimiliano (subscriber, #3048) [Link] There is work ongoing on making a free "posh", google for it... It could be nice if the projects cooperated :-)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 26, 2008 12:53 UTC (Thu) by mish (guest, #52694) [Link] > Also.. if it was possible to use this hotwire from a virtual console or just a plain xterm, > then that would be fantastic. Screen beats the absolute living crap out of any sort of tabbed > system I've ever seen in my life. > > Basically I have nothing against nice friendly gui systems.. that's very good. Even if you > still end up requiring a special python gui to run hotwire, I would like to be able to disable > the tab bar, menu bar, and the scroll bar and still be able to use it. I definitely expect that everything should be able to be done without a mouse - I think that is possible now, and I have some other ideas that would extend that (though they're not at the top of my list to do yet ...) http://groups.google.com/group/hotwire-shell/browse_threa... Also, the code is intended to be split so that the core code is separate from, and does not depend on, the UI code. (Note this split is currently not clean - there are dependencies). This would allow other UIs to be written, including a UI that can run inside an xterm. It should also (eventually) allow the core code to run on a remote machine while the GUI runs locally. But don't hold your breath (unless you want to help make the split cleaner and write the xterm UI ;-)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 25, 2008 9:45 UTC (Wed) by nix (subscriber, #2304) [Link] But anyways, so the basic idea is that now we have these libraries, what if your shell was more of a *direct* interface to those libraries, and what if it made it easier to transition to using those libraries, just like how you would in a real program?Aah, right, so rather than writing little tools that just consist of a library call, we can turn it upside down and write tiny library functions that do little more than run a tool :) I suppose that works just as well: the hard part is getting there from here ('cos a lot of stuff, especially older stuff and the filters that are most useful on the command line, are *not* wrappers around libraries --- yet.) Transitioning to a more widely used VM with Python support seems like a good idea. I suppose the historical problems with using the JVM, at least, aren't so significant anymore (the historically enormous JVM startup times are much smaller these days, and it doesn't matter so much because you only take that hit when you start Hotwire as a whole). Your Hotwire-specific decorators are nice enough that expecting people to produce them doesn't seem incredibly harsh: of course it's generally the people who write the language bindings for whatever-library in (Python|Java|C#) who'll need to do that. Regarding ps(1) in particular, it used to be a pain in the butt to handle in days of yore when every system had a radically different ps(1), but even if you have to be portable to systems without libproc, a combination of 'ps -o' and a small wrapper function allows you to inspect output really quite easily. (I long ago wrote a C wrapper which allows you to feed I/O in and out of pipelines directly from functions with persistent state, generator-style, and I'd be amazed if others hadn't written similar things. I should make it public, I suppose, but it barely seemed worth it, and the code, well, it still looks like it was written by a fifteen-year-old). (hotssh looks really quite neat as well.)
OpenJDK + Groovy Posted Jun 26, 2008 2:56 UTC (Thu) by ringerc (subscriber, #3071) [Link] If you're looking to move it onto another language/VM platform for the final version and are considering the JDK, you might want to start with Groovy. It's interactive interpreter features and generally more dynamic structure would be a better fit for building a shell than compiled Java would be. In particular, being able to load and run Groovy scripts (as well as compiled .class / .jar format commands shipped by libraries etc) would be really handy. Libraries could ship fast, precompiled jars that your command classloader could quickly pick up, but users could write groovy snippets and scripts without needing the `javac' step. Handily, groovy can be compiled too, so if you do then want to package your groovy scripts as fast precompiled commands you can. Sounds good to me. I would personally much prefer to see it take the Java path both because the JVM is now GPL and because Java is subject to the JCP. It also has excellent backward compat. Mono, while the codebase is free, is still very tied to Microsoft's language direction, and I'd be a bit nervous about building new core OS infrastructure on it myself.
standard mechanism for exchanging objects Posted Jun 25, 2008 4:57 UTC (Wed) by jreiser (subscriber, #11027) [Link] (The real problem here is that Unix has a standard mechanism for exchanging text streams, but none for exchanging objects ...On the contrary: fork(), then dlopen(). The objects persist, the manipulators come and go, the schema control can be written any way you please. [You need a much better debugger than gdb, but that's nothing new...]
standard mechanism for exchanging objects Posted Jun 25, 2008 10:18 UTC (Wed) by nix (subscriber, #2304) [Link] The problem is that fork()-then-dlopen() gives you objects only in the C sense. There's no standard mechanism for exchanging objects with defined lifetimes and so on (not least because every language defines those differently: they don't define text-stream-exchange differently, because the OS dictates that.)
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) Posted Jun 24, 2008 23:51 UTC (Tue) by gorpon (subscriber, #25040) [Link] While it looks pretty rough, I think it's a neat effort. It's an interesting exploration of the problem of transforming and organizing data from different environments. It is crude, however I suspect that the management and development tools of the future will use some of the more innovative elements of this interface.
Alternatives Posted Jun 24, 2008 23:53 UTC (Tue) by epa (subscriber, #39769) [Link] You might want to compare this against the older project xmlterm, Emacs's eshell, or Midnight Commander.
Alternatives Posted Jun 25, 2008 2:30 UTC (Wed) by walters (subscriber, #7396) [Link] We have a long list of related projects actually: http://code.google.com/p/hotwire-shell/wiki/RelatedProjec... Basically xmlterm was interesting, but realistically XML is rather terrible as a general purpose means of programming. Bulk data transfer between separate security domains, OK - but the JVM/.NET architecture of a shared runtime are a lot more promising. eshell was cool...I should check it out again. But as substantial and cool of a community Emacs has built up, I think Emacs Lisp and its VM are...not the future =) Midnight Commander is just a file manager, no?
MC is my "shell" of choice Posted Jun 25, 2008 8:22 UTC (Wed) by khim (subscriber, #9252) [Link] Midnight Commander is just a file manager, no? Yes and no. It's true that it's just as file manager with command line access, but you can use it for more then that. Want to convert few files with iconv ? Easy: select files and then Easier then any other solution I've seen. MC allows you to COMBINE point-and-click interface with power of command line. VERY handly. And it can be used over ssh over slow link too!
Alternatives Posted Jun 25, 2008 16:12 UTC (Wed) by ejr (subscriber, #51652) [Link] You dismiss Emacs and others as "not the future" too readily. You should not be as interested in the future so much as in the past. Specifically, you want to re-use libraries and code. But you decide to reinvent some of the more painful parts. That seems to be a long-running trend in programming, and I wish it would end. Hotwire seems really cool, but I (for one) would greatly prefer seeing the effort go into extending and perfecting an existing system. Some of the benefits you list don't apply to me; I already *have* re-usable pipes and buffers in Emacs, process and directory editors, image thumbnails, and an interactive D-Bus interface. And a mail and news client, document viewers, web browsers, debuggers, and more. Not everything is perfectly integrated, but that's a byproduct of so many years of success. As your list shows, Emacs isn't the only other project that could use your effort and vision. It is unfortunate that you decided not to help any of those. (And xterm has a GUI portion also: the Tektronix window. It's been there a long, long time, but few programs still can use it.)
Alternatives Posted Jun 26, 2008 22:44 UTC (Thu) by walters (subscriber, #7396) [Link] I've contributed some nontrivial patches to Emacs and was in the past a core committer. Don't get me wrong, Emacs is great and has left a lasting impression on me. However, while it makes sense to have a good relationship between one's interactive shell/toplevel and one's editor, I don't think it necessarily makes sense for them to be the same thing always. Emacs' fundamental architecture at this point is just too limiting; Emacs Lisp is far behind the times. The buffer-oriented display technology lets one easily do some neat things and lends itself very well to a keyboard-oriented control (which is crucial for a good programmer's editor). But Emacs doesn't have anything like GtkTreeView.
dead languages Posted Jun 25, 2008 3:16 UTC (Wed) by sbishop (subscriber, #33061) [Link] I haven't tried Hotwire yet, but I have read every Wiki and Web page accessible from either the project home page or random Google-group postings. ;) It seems that the emphasis has largely been on the GUI<->CLI connection. That's important and could be improved, but it my mind, at least, the language being used is in much more need of attention. If you google for bash programming information, you'll get one of two things: tutorials from people whom I suspect have just finished writing assembly language tutorials, or admonitions to write anything serious in a serious programming language. We need a shell language that people *want* to use. It needs to be scalable, from one-liners to a reasonable-sized script. (Think of your typical Python or Perl script.) I hope Red Hat turns Hotwire into an ET project, but I also hope that someone puts a great deal of thought into the language issue.
dead languages Posted Jun 25, 2008 10:26 UTC (Wed) by nix (subscriber, #2304) [Link] Well, actually you *can* do full-blown parsing and bidirectional pipeline stuff in the shell (I've done it). However, bugs and differences between shells make it agonisingly difficult to do anything really complicated in portable shell. You could decide e.g. to just go with zsh because it's widespread, flexible, only has one consistent implementation and works everywhere useful (that's what I ended up doing) but if you're doing that you might as well go with Python or Perl anyway, as the same things are true of them.
dead languages Posted Jun 26, 2008 12:44 UTC (Thu) by mish (guest, #52694) [Link] The main language being used is python, and the default scripting would be in python (though as with the standard shell, other languages can be used in scripts, and the plan is for perl and ruby to be supported fairly natively, but that will take some time). So the idea is to go beyond bash scripting, but maintaining a level of backwards compatibility. Some relevant links: Ideas on how to do scripting (not implemented yet): http://code.google.com/p/hotwire-shell/wiki/HotwireScripting See "Running Other Languages" in this page for ruby etc support http://code.google.com/p/hotwire-shell/wiki/GettingStarte... And having an object stream pipeline rather than a text based pipeline is also a big advance from bash and similar shells. So a lot of thought is being given to language issues, with many details still to be worked out.
Just change the terminal, no the shell Posted Jun 25, 2008 12:53 UTC (Wed) by endecotp (guest, #36428) [Link] I have occasionally wondered about how the classic "shell + terminal" could be improved. My complaints are few, but when I'm using things like Imagemagick's convert and mogrify tools and wonder whether a more "multimedia" terminal could be useful (with no changes to the shell). Specifically, if I "cat foo.jpeg", wouldn't it be great if the image were displayed inline in the terminal, like "cat foo.txt" would have been? Then I could see it in my scrollback history. At present I have to see foo.jpeg in another window which I have to close at some point, and isn't tied to the place in my history where I launched it. Similarly, a GUI directory browser can show me thumbnails of the images but ls can't. Why not let ls (or an ls-like program) output a mixture of text and graphics to the terminal window and see image thumbnails there? Maybe this has already been done. It's something that I think about from time to time but it has never yet reached the top of my to-do list.
Just change the terminal, no the shell Posted Jun 25, 2008 17:07 UTC (Wed) by ballombe (subscriber, #9523) [Link] Actually you can do that in the Linux framebuffer.
Just change the terminal, no the shell Posted Jun 26, 2008 10:23 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah, but unless you can make it work in an X terminal emulator too it's not going to be terribly widely used. (I don't use fb even though non-fb is almost unreadable on my LCD screen --- it gets the width of the screen radically wrong --- simply because, AIUI, fbdev is pretty much incompatible with accelerated X, and I care much more about accelerated X than I do about the tiny proportion of the time I'm using the console.)
Just change the terminal, no the shell Posted Jun 26, 2008 15:07 UTC (Thu) by endecotp (guest, #36428) [Link] > Actually you can do that in the Linux framebuffer. Hmm, I just tried "cat foo.jpeg" and got the garbage characters that I was expecting. Is there something that I have to enable?
Just change the terminal, no the shell Posted Jun 27, 2008 12:21 UTC (Fri) by nix (subscriber, #2304) [Link] It is *possible* to write code such that that works in the Linux framebuffer (compared to, say, xterm: w3m can display images in that but there's no way it'll work with scrollback or anything because w3m is just blatting images into the same X window: xterm doesn't know anything about it).
|
|||||||||||