I think you didn't get all of my ideas. I know both ncurses and screen and for me they are signs that the basic concept (layers upon layers) is flawed. I think I'm too young to say I remember DOS well, but I've been playing with toy kernels and writing directly into memory under 0xb8000. I even wrote some kind of a very dumb terminal emulator.
So, look, for example. If such "splitted terminal" would be the primary interface provided by Linux right after boot, in the text mode, we could ask the user for login credentials while the rest of the system is booting (like starting XDM before any other services, but come on, XDM (and other DMs) sucks). This of course would need lots of changes in the kernel, and then probably a new/bin/login. On the other hand, the shell wouldn't need any changes (maybe except spawning it with a "run non-interactively" flag, so that it doesn't display prompts or load the command completion code). Well, and yes, command completion, editing, etc would need to be provided by a plugin in the input buffer, not by the shell itself.
> It's the command interpretor shell that does IO with the terminal, > and it doesn't have to be re-written: It can be wrapped in another > layer and/or extended to add even more features.
Nyet, I don't think so. In my opinion, it breaks the "one tool for one job" rule of Unix, and features should be *removed* from it. So it provides a language for scripting and for command execution, AND provides completion, editing, etc. Ever tried to switch to a less-mainstream shell, like Plan9's rc? rc as a language is superior to sh in almost every aspect (save for backwards compatibility), but its line-editing, history and completion capabilities are severally lacking. But let's say you move all of that functionality to the terminal's input widget. The widget would just look at the grammar of the shell (you still need to tell HOW to complete stuff...) and that's it. If somebody is willing to spend some time hacking a completer for it, you could even run Perl as your login shell, with zero changes to the executable.
> Well... Get to Coding!
I will, not kidding.
I like the suckless.org philosophy. They create lots of very small, neat, high quality software, while taking care to keep the design simple and the source code understandable. Never thought I'd be running a window manager with my own patches, but here I am with dwm (http://dwm.suckless.org/). Oh, and they have a terminal emulator in under 2000SLOC of C (http://st.suckless.org/). I guess the "rip out the VT100 emulation and see where can we go from there" part is one boring evening away (not tonight - we're gonna drink vodka).
> However, if you did start out on such a project (as I did) > you would realize why there are so many messed up layers -- > it's for backwards / forwards / cross-terminal compatibility.
One nice thing is that every well-written program should already support this kind of terminal. If it knows what TERM=dumb means, and if it uses standard isatty(3), there's nothing more to be done to get it working. Actually I just ran "aptitude update|cat" to see if it behaves properly when it can't assume it's OK to update something it already printed, and it ran just fine. Even "aptitude dist-upgrade|cat" behaved like a good citizen when it had to ask questions interactively.
Moreover, Unix seems to be a very flexible toy. You'd think that using svscan (http://cr.yp.to/daemontools/svscan.html) as a drop-in init replacement shouldn't work, right? Well, there's a guy that just hacked some additional initialization&shutdown scripts and it seems to work (http://code.dogmap.org/svscan-1/). Regarding terminal-oriented programs, I recently wrote a simple script that would use Google to translate its stdin into another language. Then wrote a simple GTK program with three buffers, one to type in a command, one which's contents are sent to command's stdin, an
Well, not exactly, but it's been a long time since I've suspected that there is something fundamentally flawed about the idea of having a cellular grid of glyphs trying to pretend that it is a teletype.
The first problem is that no input (no new commands) is accepted while a previous one is still being executed. Of course shells allow the user to place a job in the background, but if it outputs any text (or does some tricks to update text that is already on the screen), your input and output are melding into a mess.
Another thing is that there are layers of abstraction over the raw terminal emulator interface, like readline or curses. The first tries to make editing a command a smaller pain, the other one's role is essentially to turn the terminal emulator running on top of a grid of character cells... back into a grid of character cells.
I think it's time to get rid of terminal emulation. It's 2011. I consider myself a Unix geek (of a younger generation), and I haven't seen a real serial terminal even in a museum. Of course I'm sure that some of you guys have one at home, maybe even hooked up to your box's serial port. But hold on, because what I'd like to propose would be backwards compatible - it could easily be emulated on top of curses, and still would be able to be interfaced with via stdin/stdout/stderr.
Well, the idea is to take our 80x25 grid of characters and provide a completely raw, low-level API to it. API like, "put glyph 0x41 in position 0,0". curses can do that, but it's two unnecessary layers of abstraction, so better just take an X terminal emulator, rip out all the terminal emulation code, and provide THAT api over it. Now, the second step is to let a library manage this area - if you want to emulate a VT100, just put a VT100 widget in there. If you want to run a curses-based program, it would make sense to port ncurses to use this backend. But the most interesting thing (IMHO) is the new (old) text user interface that I've conceived.
Basically you have your cellular grid split into two non-overlapping areas, one short at the bottom, and one tall, taking up the rest of the vertical space. The bottom one is an input buffer, the other one holds the output. Seems familiar? Of course, that's how all chat programs and IRC clients have been looking like since the beginning of the time. Also, this resembles how Emacs handles its minibuffer, or if you stretch the idea even further, that's the relationship between dmenu and the rest of your X display. So it's a well-tested paradigm.
So, what else exactly does it change? As I said before, you can run all of your commands automatically in the background, and they could keep updating the output with useful information as they go. No more need for readline - or rather, it would get integrated with the input buffer. Or possibly something else, I suspect that it would be quite possible to embed an Emacs or Vi buffer in there. Also, as the output buffer is just a widget reading commands' stdout&stderr, we could let it interpret the output and format it in various ways.
There is lots of lots of really fancy stuff that one could possibly do with such an UI. The raw grid area could be split into more areas, so that you could have all sorts of statusbars or sidebars displaying realtime stats (like screen or tmux do). If the terminal window is running over a graphical display, I would dare to say that doing what TermKit does would be even funny&profitable (although I'd probably do many things differently than TermKit... I have a deep hate for all things web). It could be abstracted to let software run unchanged both under graphical and text-based displays.
I have lots of other funny ideas in my mind, but can't really shape them into words (or code) yet.
You're my hero. I browse with noscript, adblock, cookiesafe, greasemonkey, skipscreen and perspectives. They all together make the web more usable and somewhat safer.
If you run Debian, or a derivative, you can grab debian-goodies package, and use checkrestart. I use this command to restart whatever needs to be restarted:
$ sudo checkrestart | grep "/etc/init.d/" | sudo sh
Just remember to first check WHICH services is it going to restart.:)
This is all true what you've said about all the techniques that you can use with real strings, and all of these things are almost exactly what I am missing when I'm playing piano (I started playing guitar long before keyboards). However, a piano is a very different instrument from a guitar, and has a lot of its own strenghts. Same thing with Misa.
That should be easy, shouldn't it? Two proximity sensors and a microcontroller to translate that to midi messages. Or maybe just send raw data via serial port and let a real computer chew it.
I am a "real guitar player", and I want one of these. I've been doing a lot of experiments with music lately: alternative tunings, inserting weird things between strings, building my own strange instruments, defretting an electric guitar, experimenting with touchpad as a controller, etc. This "guitar" is on my wishlist.
1. JWs don't believe in any kind of hell. The closest thing is just simply dying and having no chance of being resurrected by Jehova. That's it! If you'll be bad, when you die, you'll just die!
2. My username is actually more evil than you think. First, I'm a masked Harry Potter fan, you see, occult black magic and shit. You just have to add "er" to the end of my username, and replace "666" with "pot". And yes, I do smoke pot too! And if you read it backwards, it will sound pretty fucking demonish: "eetksiskiskisyrraahhh"; almost like some kind of Cthulhu spawn. How much more evil can you get with the least possible amount of people noticing?
Hm, can you tell me. Does any serious real-world project actually use GNUStep? Is the whole environment a viable alternative to KDE/Gnome/rest of the crowd? Where does it fit anyway, is it a widget library like Qt or Gtk+, or something more high-level, like KDE or Gnome? All I have ever seen is WindowMaker and a few toy apps on screenshots that looked like 1989. I've heard a lot of good words about GNUStep, dunno. Maybe I am missing something.
Strength is irrelevant. Resistance is futile. We wish to improve ourselves. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service ours.
> I think this product is great even if for nothing more > than the conversations it can generate that will bring > more awareness about the needs in developing countries.
These so-called "developing" countries were doing just fine, and had a lot less problems *before* we had *any* awareness of their existence.
Slashdot Mirror
Hi, first, thanks for your reply :D
I think you didn't get all of my ideas. I know both ncurses and screen and for me they are signs that the basic concept (layers upon layers) is flawed. I think I'm too young to say I remember DOS well, but I've been playing with toy kernels and writing directly into memory under 0xb8000. I even wrote some kind of a very dumb terminal emulator.
So, look, for example. If such "splitted terminal" would be the primary interface provided by Linux right after boot, in the text mode, we could ask the user for login credentials while the rest of the system is booting (like starting XDM before any other services, but come on, XDM (and other DMs) sucks). This of course would need lots of changes in the kernel, and then probably a new /bin/login. On the other hand, the shell wouldn't need any changes (maybe except spawning it with a "run non-interactively" flag, so that it doesn't display prompts or load the command completion code). Well, and yes, command completion, editing, etc would need to be provided by a plugin in the input buffer, not by the shell itself.
> It's the command interpretor shell that does IO with the terminal,
> and it doesn't have to be re-written: It can be wrapped in another
> layer and/or extended to add even more features.
Nyet, I don't think so. In my opinion, it breaks the "one tool for one job" rule of Unix, and features should be *removed* from it. So it provides a language for scripting and for command execution, AND provides completion, editing, etc. Ever tried to switch to a less-mainstream shell, like Plan9's rc? rc as a language is superior to sh in almost every aspect (save for backwards compatibility), but its line-editing, history and completion capabilities are severally lacking. But let's say you move all of that functionality to the terminal's input widget. The widget would just look at the grammar of the shell (you still need to tell HOW to complete stuff...) and that's it. If somebody is willing to spend some time hacking a completer for it, you could even run Perl as your login shell, with zero changes to the executable.
> Well... Get to Coding!
I will, not kidding.
I like the suckless.org philosophy. They create lots of very small, neat, high quality software, while taking care to keep the design simple and the source code understandable. Never thought I'd be running a window manager with my own patches, but here I am with dwm (http://dwm.suckless.org/). Oh, and they have a terminal emulator in under 2000SLOC of C (http://st.suckless.org/). I guess the "rip out the VT100 emulation and see where can we go from there" part is one boring evening away (not tonight - we're gonna drink vodka).
> However, if you did start out on such a project (as I did)
> you would realize why there are so many messed up layers --
> it's for backwards / forwards / cross-terminal compatibility.
One nice thing is that every well-written program should already support this kind of terminal. If it knows what TERM=dumb means, and if it uses standard isatty(3), there's nothing more to be done to get it working. Actually I just ran "aptitude update|cat" to see if it behaves properly when it can't assume it's OK to update something it already printed, and it ran just fine. Even "aptitude dist-upgrade|cat" behaved like a good citizen when it had to ask questions interactively.
Moreover, Unix seems to be a very flexible toy. You'd think that using svscan (http://cr.yp.to/daemontools/svscan.html) as a drop-in init replacement shouldn't work, right? Well, there's a guy that just hacked some additional initialization&shutdown scripts and it seems to work (http://code.dogmap.org/svscan-1/). Regarding terminal-oriented programs, I recently wrote a simple script that would use Google to translate its stdin into another language. Then wrote a simple GTK program with three buffers, one to type in a command, one which's contents are sent to command's stdin, an
Having a somewhat similar idea.
Well, not exactly, but it's been a long time since I've suspected that there is something fundamentally flawed about the idea of having a cellular grid of glyphs trying to pretend that it is a teletype.
The first problem is that no input (no new commands) is accepted while a previous one is still being executed. Of course shells allow the user to place a job in the background, but if it outputs any text (or does some tricks to update text that is already on the screen), your input and output are melding into a mess.
Another thing is that there are layers of abstraction over the raw terminal emulator interface, like readline or curses. The first tries to make editing a command a smaller pain, the other one's role is essentially to turn the terminal emulator running on top of a grid of character cells... back into a grid of character cells.
I think it's time to get rid of terminal emulation. It's 2011. I consider myself a Unix geek (of a younger generation), and I haven't seen a real serial terminal even in a museum. Of course I'm sure that some of you guys have one at home, maybe even hooked up to your box's serial port. But hold on, because what I'd like to propose would be backwards compatible - it could easily be emulated on top of curses, and still would be able to be interfaced with via stdin/stdout/stderr.
Well, the idea is to take our 80x25 grid of characters and provide a completely raw, low-level API to it. API like, "put glyph 0x41 in position 0,0". curses can do that, but it's two unnecessary layers of abstraction, so better just take an X terminal emulator, rip out all the terminal emulation code, and provide THAT api over it. Now, the second step is to let a library manage this area - if you want to emulate a VT100, just put a VT100 widget in there. If you want to run a curses-based program, it would make sense to port ncurses to use this backend. But the most interesting thing (IMHO) is the new (old) text user interface that I've conceived.
Basically you have your cellular grid split into two non-overlapping areas, one short at the bottom, and one tall, taking up the rest of the vertical space. The bottom one is an input buffer, the other one holds the output. Seems familiar? Of course, that's how all chat programs and IRC clients have been looking like since the beginning of the time. Also, this resembles how Emacs handles its minibuffer, or if you stretch the idea even further, that's the relationship between dmenu and the rest of your X display. So it's a well-tested paradigm.
So, what else exactly does it change? As I said before, you can run all of your commands automatically in the background, and they could keep updating the output with useful information as they go. No more need for readline - or rather, it would get integrated with the input buffer. Or possibly something else, I suspect that it would be quite possible to embed an Emacs or Vi buffer in there. Also, as the output buffer is just a widget reading commands' stdout&stderr, we could let it interpret the output and format it in various ways.
There is lots of lots of really fancy stuff that one could possibly do with such an UI. The raw grid area could be split into more areas, so that you could have all sorts of statusbars or sidebars displaying realtime stats (like screen or tmux do). If the terminal window is running over a graphical display, I would dare to say that doing what TermKit does would be even funny&profitable (although I'd probably do many things differently than TermKit... I have a deep hate for all things web). It could be abstracted to let software run unchanged both under graphical and text-based displays.
I have lots of other funny ideas in my mind, but can't really shape them into words (or code) yet.
He does this on almost every gig.
Lake Karachay?
I call bullshit on this. This couldn't be real Stallman. Where is the GPL'd source, huh?
> that's not the kind of world I want to live in
He's dead, so his problem seems to be solved.
You're my hero. I browse with noscript, adblock, cookiesafe, greasemonkey, skipscreen and perspectives. They all together make the web more usable and somewhat safer.
If you run Debian, or a derivative, you can grab debian-goodies package, and use checkrestart. I use this command to restart whatever needs to be restarted:
$ sudo checkrestart | grep "/etc/init.d/" | sudo sh
Just remember to first check WHICH services is it going to restart. :)
> The syntax is different than Oracle's though.
We're talking about SQL. The world would end if the syntax wouldn't be different.
I was camping in a middle of a fucking forest with a herd of hippies, that's what I did.
So, how can you improve the quality of my life, mr. Gates? Can you give me a bigger forest? More hippies? Less villagers with pitchforks?
...in order to help humanity's evolution and thus save it from being destroyed/enslaved by an evil AI.
OK, cool, this is all very true. Would you care to roll out an extension that'd change the policy to something along what you've described?
You seem to be the dinosaur here.
> http://mansons.co.uk/shopping/categories/manson-signature-guitars/manson-signature-guitars/mb1-standard/
A sustainer! :D
This is all true what you've said about all the techniques that you can use with real strings, and all of these things are almost exactly what I am missing when I'm playing piano (I started playing guitar long before keyboards). However, a piano is a very different instrument from a guitar, and has a lot of its own strenghts. Same thing with Misa.
You can hack this baby and make it do whatever you want. Duh.
That should be easy, shouldn't it? Two proximity sensors and a microcontroller to translate that to midi messages. Or maybe just send raw data via serial port and let a real computer chew it.
I am a "real guitar player", and I want one of these. I've been doing a lot of experiments with music lately: alternative tunings, inserting weird things between strings, building my own strange instruments, defretting an electric guitar, experimenting with touchpad as a controller, etc. This "guitar" is on my wishlist.
1. JWs don't believe in any kind of hell. The closest thing is just simply dying and having no chance of being resurrected by Jehova. That's it! If you'll be bad, when you die, you'll just die!
2. My username is actually more evil than you think. First, I'm a masked Harry Potter fan, you see, occult black magic and shit. You just have to add "er" to the end of my username, and replace "666" with "pot". And yes, I do smoke pot too! And if you read it backwards, it will sound pretty fucking demonish: "eetksiskiskisyrraahhh"; almost like some kind of Cthulhu spawn. How much more evil can you get with the least possible amount of people noticing?
Hm, can you tell me. Does any serious real-world project actually use GNUStep? Is the whole environment a viable alternative to KDE/Gnome/rest of the crowd? Where does it fit anyway, is it a widget library like Qt or Gtk+, or something more high-level, like KDE or Gnome? All I have ever seen is WindowMaker and a few toy apps on screenshots that looked like 1989. I've heard a lot of good words about GNUStep, dunno. Maybe I am missing something.
I am a Jehovah's Witness, you insensitive clod!
And yes, I do play D&D!
This is original research.
welcomes you, dear sir.
Strength is irrelevant. Resistance is futile. We wish to improve ourselves. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service ours.
> I think this product is great even if for nothing more
> than the conversations it can generate that will bring
> more awareness about the needs in developing countries.
These so-called "developing" countries were doing just fine, and had a lot less problems *before* we had *any* awareness of their existence.