| |||||||||||||
|
| |||||||||||||
Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)Posted Jun 25, 2008 1:55 UTC (Wed) by walters (subscriber, #7396)In reply to: Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) by nix Parent article: Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)
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 =)
(Log in to post comments)
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.
|
|
||||||||||||