interesting, how deep could the recursion go...

a browser running a 486 emulator running linux running X11 running a browser running...

Very, very impressive.

Of course, the obvious thing to do now would be to install xwindows and firefox on the virtualised machine, then Firefox. And then run another copy of the virtual machine inside inside that browser...

You don't need to run user-mode linux in the JavaScript 486 emulator -- you can just run linux.

Although getting access to the physical hardware and filesystem from inside the browser sandbox would be a trick...

Virtualization isn't new: IBM's big iron has been doing it since the early 1970s. More recently, circa 1995 at one point I had a Mac on my desk at work -- a 68030 machine, not a PowerPC Mac, and running System 7.5.something, not OSX -- that was running Windows 3.1 (via SoftWindows) and a Mac-hosted UNIX environment (the name of which evades me) simultaneously.

What's interesting is that the mid-to-late 1990s promise of the web browser as the platform seems finally to be coming true, with sufficiently efficient JIT compilers for JavaScript permitting thoroughly optimized browsers to run just about anything inside them. JavaScript isn't just a toy language suitable for validating forms and providing a front-end to server hosted applications these days. Meanwhile Java (ignore the similar name: an utterly different browser-hosted VM) is dying by inches as Oracle attempts to pwn it.

Doesn't run in Chrome 12, but it does in Chrome 11. Bellard says that's because of a bug in Chrome 12.

What's interesting is that the mid-to-late 1990s promise of the web browser as the platform seems finally to be coming true, with sufficiently efficient JIT compilers for JavaScript permitting thoroughly optimized browsers to run just about anything inside them.

This really dates my IT mojo (in fact, I was canned in 1999 along many thousands of others), but what are the advantages of browser-based platforms? Is it just specific to those applications that need 'net connectivity? Or is there something deeper? Hmmm . . . let me give an example here: as a teacher of mathematics, I'm a very firm believer in the maxim that a picture is worth a thousand words. So I write up a bunch of demos in mathematica that I can demonstrate in class or that they can download and run on their own machines as a notebook file. Now, it'd be nice if I could build a web page that had some sort of Java interactivity. However, the only stuff I've found that runs at all fast is stuff like LiveGraphics3D. Which is nice enough, but the interactivity is extremely limited. Otoh, when I've tried to write Java applets (and admittedly, I may not be numbered in the top ranks of Java coders) that allow for a little bit more - say sliders to vary the paramaters on a cubic, or the number of lines that approximate a curve - well, the results have been less than impressive.

Would what you're talking about here allow me in some sense to emulate Mathematica code on someone else's machine? Or rather, would it allow me to do so quickly?

My apologies for asking what may be a rather dumb question - as I said, my IT-foo is very dated and hence very weak.

On a wristwatch, Charlie? Why aim so low? We need this thing implemented on a badger.

http://www.strangehorizons.com/2004/20040405/badger.shtml

At the risk of sounding highly unknowledgeable anybody care to explain what it is for us non-computer folk?

New around here, aren't you?

User mode Linux! What a blast from the past. Is the vt instruction set available on an x86 derivative, or only amd64? If they could implement that, you could use KVM to recurse a layer (but just one).

Damn you! Now I'll have to update my gentoo build...

Unless I put an update inside a virtualbox...

In't the story, tell me three times and it's true?

Nope :) fairly regular. Just not that computer smart

Almost everything has a browser, so it's more appealing to write a browser app than a desktop app if you want to distribute something than is easy to run anywhere. There are some java applets I enjoy out there (Greg Egan's page, for example) but to be honest I hate it when I go to a site and it requires some special applet to run.

For mathematica type behavior, I wonder if people could do some stuff in html5, if not, javascript compilation from processing.js. but this is a very naive suggestion since I have no in depth experience with either. I have more experience with back end web services than any front end stuff.

Interestingly, yesterday I had an interview for a job with a certain big UK book wholesaler who were looking for someone to provide technical support, with the possibility of movement into web development a couple of years down the line. They're a Java shop and they mentioned that they believed Java was pretty much the only practical technology for enterprise web development.

I have to say, though, that I think they were completely and utterly wrong. The impression I get is that Java is declining, and Android is the only technology that has a hope in hell of being able to arrest that decline.

Back on topic, I can see a lot of handy applications for Fabrice Bellard's JavaScript emulator with some work. Add graphics and sound, and either add DOSBox to the existing Linux image, or replace it with something like FreeDOS, and it'd be a handy way of playing DOS games in the browser (although I believe NaClBox has already gotten much further in achieving this using Chrome's native client capability). Also, even in its current incarnation, it's an incredibly easy way to introduce newcomers to Linux (albeit the command line only) with even less hassle than live CD's, virtualisation or Wubi.

With the addition of networking capability, I could see it being potentially handy for launching quick and dirty virtual machines for specific purposes - I'm not nearly knowledgeable about networking and systems administration to know for sure, but I wondered if it could be handy for creating honeypots on demand.

A/UX, I believe -- Apple/Unix. I knew some of the people involved with it (I know this comes as a complete shock). It was a very impressive thing, given that the Mac environment hadn't been cleaned up to the point that it was when Mac OS X 10.1 came out. The filesystem issues alone were a major undertaking.

I don't think running Linux on an emulated environment is going to be terribly useful (I could be wrong), but... it does show that you can do quite a lot with JavaScript these days. Loading your own VM for a small, embedded OS might end up being the right solution for certain kinds of tasks.

I'd like to see Mr Howard using this somehow in a Laundry novel! I was most impressed with the hello.c file sitting there in the file system, begging you to compile it.

I know a couple of SF writers who might seem unreasonably devoted to ancient software, though some of their reasons are similar. Charlie doesn't have to think about using vi, and that's a powerful advantage. It's also not going to vanish. It is, after all, available as source code.

The other writer I know of has gone to a lot of effort to keep ancient DOS computers running so that she can keep writing. Her choice of program is just too entangled with the hardware, as was common during the microcomputer revolution. This could save her bacon, though I still think she would do better to switch to a program which didn't depend on extreme measures.

From my own experience, I know the perils of depending on obsolete hardware and unsupported operating systems. Consider the BBC Domesday Project, which was almost lost because of hardware dependencies.

My work persona screams "security hole!!!1!One!"

My play persona tells it to STFU and drools at the possibilities. Get a working DOS inside there and web-based playing of old PC games is a distinct possibility.

No, it definitely wasn't A/UX (I know A/UX of old) -- it was a weird third-party BSD-based thing that ran a Mach microkernel as a user-level application under MacOS. Slow as pigshit and prone to crashing: the (small) firm behind it went to the wall in the late 90s, if I remember correctly.

I think you're remembering the Macintosh Application Environment. It emulated a 68030 Mac running System 7 on SPARC and HP PA-RISC workstations. Apple released it in 1994. I was one of the developers.

Is this it?

http://en.wikipedia.org/wiki/MacMach

Nope, wrong again. (This was a third-party BSD-oid UNIX environment sold as a Mac user-space App with some hooks into MacOS 7.x to help its scheduler, sold by a small company other than Apple. I think the name may have begun with Q, but it wasn't QNX.)

-- Charlie

Runs fine in Chrome 13.0.761.0 dev, and in the more recent Canary builds.

If they're talking about Java and "Enterprise" they are surely talking about J2EE - Java as a server-side tool, whereas Javascript is entirely client-side. J2EE isn't going to die any time soon (COBOL and the like certainly haven't died yet) but with the notable exception of Facebook's advanced photo uploader tool, I can't remember the last time I saw a Java applet on the web.

IBM ManyEyes uses both JavaScript and Java to do its sexy embeddable charts.

User mode Linux!

ScraperWiki is essentially made of UML.

Yes, this was J2EE. I agree that Java applets don't appear to have that much of a future, however.

I wasn't suggesting for a second that Java on the server-side was going to die anytime soon - where I work now there are still plenty of legacy applications written in COBOL or Visual Basic in use, and there's been enough companies using Java for server-side programming that it's going to be around for a long time. However, I do think it has probably passed its peak.

Slight nit-pick here - I don't think it's entirely correct to say that JavaScript is entirely client-side anymore, as Node.js seems to be picking up steam. It is decidedly bleeding-edge, however.

:It was a weird third-party BSD-based thing that ran a Mach microkernel as a user-level application under MacOS.

Possibly MachTen? There were both PowerPC and x86 versions of that...

It wasn't the concept of virtualisation that impressed me. Coincidentally I read your posting while building two Win2K3 VMs on a big HP server, so the idea is one I'm used to.

What impressed me, as a developer, was that one guy implemented a fairly complete emulator for a relatively recent hardware platform on his own, and he did it in a freaking scripting language. And the result is fast enough to interpret a modern OS. I'm used to doing virtualisation using serious software like VMware ESX that costs serious money and has to run on the bare hardware, so this was a bit of an eye-opener for me.

Taking this further, if you could emulate a low-end graphics chipset and use it to drive an HTML5 Canvas object the you could have bitmapped graphics for a gui. Combine that with HTML5 Local Storage to persist the disk image and you've got something usable. Potentially a virtualisation environment that needs no effort to deploy, leaves no traces on the host machine, and allows the vm to be thrown away when you're done with it. There must be interesting application in espionage, privacy, etc.

Charlie, after reading up on W3C typed arrays, I decided to check the webkit.org ticketing system for mentions of it, and found some.

Then I downloaded the nightly build... and the emulator works fine in it.

So, the necessary features are already in the open source repository for webkit, and we can perhaps expect to see this work on the iPad within a few months.

As for old school MacOS Unix-in-an-app stuff, I've been at CMU (home of Mach) since the mid-1980s and have at least poked at A/UX, MacMach, and MachTen, and what you're describing sounds more like MachTen than anything else. The internet even seems to think it came in an m68k flavor.

(At home, I've still got an old SE/30 somewhere with Debian/m68k on an external SCSI drive. Was going to build a LocalTalk/Ethernet bridge out of it to connect my several Newtons to the internet... never got around to it.)

Bingo! MachTen it was.

I am ... startled? ... (Yes, that's the right word) that the product is still available and supported!

It occurs to me that if you can run a 486 emulator in Javascript, you can probably run a low end (ARM3?) ARM emulator as well. Which means, in principle, you could emulate a Newton on an iPad inside the iPad's web browser.

Somehow I do not think Steve Jobs would approve of that ...

I don't know how "supported" it can be, given that it says it runs on all Mac hardware -- 68k and PowerPC!

Certainly some disapproving occurred when the Einstein guys tried to get a port of their Newton emulator on the app store.

Heh, there's an open source Newton emulator for the iPad already. It's not in the iTunes store and obviously can't be, but if you've either jailbroken or are an iOS developer (and thus can sign your own apps without jailbreaking), you can find the source on Google Code. But you need to load a ROM from a real device into it, which is why my eMate is on my desk at work right now. (At some point I'll find the USB/serial crap and cabling I need to finish this, they're around here somewhere.)

Oracle Java may be dying, but the future is Google (Android) Java

Yes, Cthulhu exists, and yes the Laundry is real and carrying on the good fight...

http://blogs.discovermagazine.com/badastronomy/2011/05/18/the-galaxy-may-swarm-with-billions-of-wandering-planets/

Charles, there is something strange going on here...

I meant that to read "#include " but something cryptically cut out the

It shouldn't be more (or less) of a security hole than any other Javascript, I wouldn't think.

In particular, browsers don't let Javascript programs send or receive arbitrary network traffic.

Twice in a row...

a 68030 machine, not a PowerPC Mac, and running System 7.5.something, not OSX -- that was running Windows 3.1

The "real" virtualizers ran that on an Atari box, using that cartrige-based Mac emulator whose name escape me today.

The added layer came in the late-90s/early-00s when PC running software-based Atari emulators became powerful enough to emulate that era's hardware (so you had a PC emulating an Atari, emulating a Mac, emulating a PC with an older OS).

At that point, you started to realize that you were living in Vernor Vinge's early ages, where the basic software architecture wasn't a program, but an entire computer system, emulated N times over, which would be still working 10,000 years later in a Qeng Ho spaceship light-years from here.

Note "You may use HTML entities and formatting tags in comments" above the comment box. The flip side of this is that if you do use something that looks like an HTML entity or formatting tags, they get interpreted as HTML.

If you need to type an angle bracket, enter <, as such:

So this would allow me to play all my really old DOS based games then? Groovey. But now I'll need to track down a 5.25" floppy drive and hope to hell that the data has not been wiped from my copy of MegaTraveller 2.

Fat chance I am afraid :(

Something cut off the strange HTML you tried to use?

If you write '#include <string.h>', you get the <string.h> part interpreted as an HTML code. Since it's not a known one, the HTML interpreter just ignores it.

Remember, to write '<', you need to write it as '&lt;'. Ditto for '>', you need to write it as '&gt;'. So to write '#include <string.h>', you need to type '#include &lt;string.h&gt;'

unning on vi Why? vi is SHIT I first encountered it about (erm) 1992, and, even then, it was obviously hopeless, uselss, and a pain in just about everywhere .... I made several attempts to get to grips with proper UNIX - it was so obviously a powerful tool, but kept gettting diverted - by people, maay I say, not the software ......

'#include <curses.h>'

I liked it much more that it was editing that out...

"...whereas Javascript is entirely client-side."

Do try to keep up at the back: Node.js is server-side JavaScript which is getting a lot of attention these days.

This virtualization is just one (somewhat eye-opening) example of the way that the use of JavaScript is expanding wildly. It's likely to be nibbling Python and Ruby's heals pretty soon (well it would if snakes and stones had heals) particularly for code embedded in other applications (see for example CouchDB) or otherwise not simple standalone stuff.

I'm something of a Python fan but still find the idea of server-side JavaScript attractive and it's high on my list of things to look into beyond simple "hello world" web servers under Node.js.

"heals" -> "heels". I proof read it but still only saw my "phonetic" typing after pressing Submit.

Almost everything has a browser, so it's more appealing to write a browser app than a desktop app if you want to distribute something than is easy to run anywhere. There are some java applets I enjoy out there (Greg Egan's page, for example) but to be honest I hate it when I go to a site and it requires some special applet to run.

Egan's applets are exactly the type of math pictures I'm talking about (This really is the golden age of graphics for us math teacher types :-) Look at, for example, his applet for demonstrating the difference between phase and group velocity, and how an ftl phase velocity can't actually send any information at superluminal speeds. How I wish I had something like this to show relativity cranks back in the golden age of Usenet (A lot of those cranks were for some strange reason both libertarian and also programmers of one sort or another. You could argue with them until you were blue in the face, give cites, equations and crude ascii drawings demonstrating the setup, and still they wouldn't believe you. But if you had this sort of applet and made the source code available . . . ah, how different things might have been)!

The problem is that while these graphics are extremely helpful in explaining a mathematical concept, there isn't much in the way of interactivity (look at Egan's applets again for an excellent example of what I mean.) If Charlie means what I think he means, a lot of that sort of problem disappears - I think. Or it could be that that I'm simply reinventing the wheel, and not a very round one at that :-(

I guess basically what I'm saying is, while I knew the old DOS system very well, and how it tied in with stuff like your basic Assembler-type languages, flip-flops, memory, registers, etc., browser-based operating systems and how they work at the logical level are more than a bit of a mystery to me. Magic.

And it is out of that sort of ignorance that I ask my question about the general and particular advantages of this sort of operating system running that sort of code over something more traditional.

For mathematica type behavior, I wonder if people could do some stuff in html5, if not, javascript compilation from processing.js. but this is a very naive suggestion since I have no in depth experience with either. I have more experience with back end web services than any front end stuff.

Interestingly, my daughter's mother just completed a class in web page design[1] where the language du jour was XHTML 1.0 Transitional, a cross between HTML 4 and XML (or so says the accompanying textbook, Felke-Morris.) Naturally she relied on yours truly for some of the more, er, technical bits. And naturally, since the last time I did any real webpage design was before the 21st century had been officially rung in, there were some, er interesting moments. Anyway, near the end of the course, the use of JavaScript was touched upon, with both the teacher and the author of the text thinking it was the bees knees with the potential to replace a lot of the more traditional Java. I wouldn't know, but consider this another data point for what can be done with this sort of setup.

[1]Before Barb can advance any further in the library hierarchy, she has to get a second M.A. (or M.S., I'm not sure which), this one in "library science". Since this is the Information Age (as several syllabi in several classes have informed her), she has to know something about the IT biz. Library science as a hot new up-and-coming profession in the 21st century, huh! None of us back in 1975 saw that one coming. The sf we read about the near and far future was frequently found via the four-ton Card Catalogue system. And when I sent out inter-library requests I did so via an ancient teletype machine, a hulking, green-enameled monster from the 40's complete with special rolls of yellow paper that always seemed to jam up the works.

The other writer I know of has gone to a lot of effort to keep ancient DOS computers running so that she can keep writing. Her choice of program is just too entangled with the hardware, as was common during the microcomputer revolution.

About 5 or 6 years ago at a used computer shop that also did repairs I had stopped by to see what neat stuff (junk?) he had around. He showed me an original IBM dual floppy XT with an MX dot matrix printer. Someone had brought it in as it had just stopped working. Turned out to be the logic board. Rick broke the news that his mailing label system of 25 years was gone and had to be replaced. He was able to transfer all his files over to something used but much newer and with a better printer. The fellow had bought this system they first came out and had been using it for one purpose, his mailing list, ever since.

That is very neat. (And it does emacs, too, which is good because I never could get the hang of vi.) It reminds me of my first brush with Linux, which really was running on a 486 -- dual-booted off a floppy, somewhere around 1994.

I'm not sure whether I'm being paranoid or prudent by not wanting to use it to log in to anything else. Probably paranoid; if it's really running on my local machine it should be fine, no?

I guess basically what I'm saying is, while I knew the old DOS system very well, and how it tied in with stuff like your basic Assembler-type languages, flip-flops, memory, registers, etc., browser-based operating systems and how they work at the logical level are more than a bit of a mystery to me. Magic.

It is old news now, but the above sounds like a good enough excuse for me to mention the Visual 6502 project – perhaps as a "low level" sort of person that is more your flavor of emulation?

They have a transistor level simulation of the MOS 6502 (known to me from the Commodore 64, and known to others from other 8-bit home computers and consoles) that runs in the browser. Also done with Javascript, of course.

I wonder if dosbox would work for whatever program this person is running? It runs most dos games, which tend to be rather hardware specific.

Having trouble with this. Have you actually managed to boot it up?

The chat forums at work have been talking about this. Funky, /proc/cpuinfo claims it's a Pentium MMX complete with f00f bug :-) Clearly a debian derivative running in that instance 'cos "ifup eth0" complains about files found in the Debian derived world :-)

It's an impressive proof of concept, but once you add in permanent storage (you don't want your work to depend on your browser staying running) and sufficient amount of CPU then you might as well run an ssh client (eg mindterm) or terminal console client (ajaxterm) inside your browser and talking to a real instance.

This is definitely a case of "wow, clever!" but I'm not sure it's of any practical use. Definite kudos for making the thing work, though!

"Meanwhile Java (ignore the similar name: an utterly different browser-hosted VM)"

Ah, marketing. Javascript was originally Livescript in the early netscape betas; IMHO it got renamed to Javascript to catch a ride on Java's coattails.

Funny how times have changed; now javascript is more popular than java!

"whereas Javascript is entirely client-side"

The original Livescript was also server side, on the Netscape Commerce Server (am I dating myself?). Predated PHP and other server-side scripting languages by a long way.

Thorne, you get to enter HTML in this form. < and > are parts of HTML entities. If you want those characters, type &lt; or &gt;.

Yes, you're dating yourself. (See also the screen shots of Netscape Navigator 1.14 in some book called "The Web Architect's Handbook" from Addison-Wesley in 1996 :)

The Spectre GCR made by Dave Small of Gadgets by Small. My first Mac was my Atari 1040ST. I used a 6502 based development system to burn copies of the ROMs out of my girlfriend's MacPlus.

Just the other night I was reading Dave's posting of the account of the sad demise of his company. Had to do with an obscure hardware bug in the memory controller he used for the 68030 version of his product.

"Netscape Navigator 1.14"

Hmm. I know I used 1.2; not sure if I used 1.14. I started at the web publishing company in July '95 and used Navigator (and hotjava; we were a Sun shop). I definitely remember the Navigator 2.0 betas 'cos that's where java was introduced and I wrote the first (according to Sun, at the time) UK commercial Java Applet for the launch of the SciFi channel in the UK. Each beta subtly changed how java worked so my backend code had to feed different applets depending on what version of java was in use. Shame I lost the source code.

The 2.0 series was also where livescript was introduced, IIRC, although I think the client side was renamed javascript before non-beta release (the server side remained livescript).

"Interesting times" :-)

The standard software load for that emulator includes emacs, which I certainly approve of. But it does not appear to include ssh. I'm obscurely saddened. Though no doubt it's easily fixed.

Apparently, Javascript is specified as standard ECMA-262 and should be called ECMAscript, which is maybe a good thing in some ways, but probably lags reality a lot.

Now, if you're doing some long-term project, do you use something proprietary, or do you take advantage of having a published standard to work from?

(Answer on one side of the screen only.)

To be fair, there wouldn't be any point in the product for x86 Macs, given that they only run OS X, not Mac OS 9 or earlier ... and that OS X includes a full suite of Unix tools (hooray for Terminal.app!)

It's entirely possible that they're making a decent living off people who are strongly welded to their old machines (if they work, why upgrade?), and hence the product still being supported. They'll probably fade into complete irrelevancy as staff move on, and they lose the built up knowledge on how to maintain it; who's going to want to learn to maintain a package that's built on top of obsolete hardware, after all?

According to the tech notes, there's no network emulation at this point.

On a wristwatch, Charlie? Why aim so low? We need this thing implemented on a badger.

Badgers; we don't need no stinking badgers!

vi knowledge is useful, for those situations where you can't get X running, so can't use a screen editor, your data isn't regular enough to process using *awk, or you need to make irregular edits and the file is just plain too big for your screen editor.

vi knowledge is useful for when you need an editor, period! Because it's hardwired into my fingers at microcode level. (Been using it for more than two decades: it's an amazingly flexible tool once you get used to modal editing.)

Geg, vi may be shit, but it is shit installed on most server-grade unix boxes out there. As a (former) travelling unix sysadmin, knowing vi was a life-saver, as that meant I didn't need to start a troubleshooting session at a customer site with "untar editor sourde; build editor" and could go directly to "diagnose and fix problem(s)".

The customers that already had my editor-of-choice installed were far and few between, but much cherished.

vi has other advantages that novices overlook. It was designed to work passably well over a 300 baud terminal where a screen refresh takes about ten seconds; you might think this an obsolete requirement, but if you've ever had to ssh into a server on another continent via a satellite link where the speed-of-light lag between hitting a key and seeing what it does is measured in seconds you'll realize that it's not obsolete at all.

Again, you can operate vi using the standard QWERTY key block plus escape and control keys which are present on almost all computer keyboards (although Apple are trying to do away with escape on iOS, it seems). It's got macros and regular expressions and automatic backup files in case you do something stupid in mid-edit. It lets you pipe arbitrary bits of text through a shell or other external program. It's terse, which means most edit mode operations can be applied using only a few keystrokes, and you can script it if necessary.

Yes; to a modern bells-and-whistles and drop-shadow-under-the-mouse-pointer aesthetic it's ugly as hell. But it's an incredibly effective tool, which is why we're still using it (or descendants like vim) 25 years later.

Just don't go mad and sing the praises of edlin...

edlin? Pah.

George 3 EDIT.

Hey, don't diss edlin. And just as vi is ubiquitous on *NIX, edlin is is also still around under Windows (at least, it's on this XP box).

Unlike many other options, you can run edlin from a response file.

Seriously; it's horses for courses. I've done stuff in vi in munutes that would take several hours with a screen editor, but I wouldn't like to attempt some of the stuff I've done with screen editors in vi.

For example, I've recently had to reverse the direction a series of figures (not all the same shape, and all in the same file) that were described by a syntax like "from Point1 ; line to Point2 ; arc to Point3 via Midpoint1 ;..."

Whilst also negating all the y coordinates. It took me about 2 hours with a screen editor, and I think would have needed about 6 with vi.

At the end of time, the battle of Armageddon will be fought. Jehovah and Lucifer will stand there shouting, "Come on lads, get into your teams!" No-one will pay any attention. Two great armies will form. One will hold aloft the banner of vi, the other that of emacs.

That's not a job for a text editor, that's a job for a hand-rolled parser written in Perl!

Exactly, even a script ninja would need longer to write and test a script than I needed to do the job mandraulically as a one-off. It will be a one-off too, if only because I kept the opposite handed file I wrote first. There was nothing wrong with it, except that the client had drawn their requirement document opposite handed to what they wanted.

There is no networking.

vi has other advantages that novices overlook. It was designed to work passably well over a 300 baud terminal where a screen refresh takes about ten seconds; you might think this an obsolete requirement, but if you've ever had to ssh into a server on another continent via a satellite link where the speed-of-light lag between hitting a key and seeing what it does is measured in seconds you'll realize that it's not obsolete at all.

Again, you can operate vi using the standard QWERTY key block plus escape and control keys which are present on almost all computer keyboards (although Apple are trying to do away with escape on iOS, it seems). It's got macros and regular expressions and automatic backup files in case you do something stupid in mid-edit. It lets you pipe arbitrary bits of text through a shell or other external program. It's terse, which means most edit mode operations can be applied using only a few keystrokes, and you can script it if necessary.

Yes; to a modern bells-and-whistles and drop-shadow-under-the-mouse-pointer aesthetic it's ugly as hell. But it's an incredibly effective tool, which is why we're still using it (or descendants like vim) 25 years later. EMACS is also installed on pretty much all LINUX systems out there AND it doesn't have VI's head-fuck mode switching bullshit. It even works great on this pathetic little 486 emulator, try it.

As an aside, the version of tcc that's installed on the emulator doesn't seem to understand for-loops, weird.

"EMACS is also installed on pretty much all LINUX systems"

Ah... "the whole world is linux" philosophy. 20 years ago it was "the whole world is Sun".

FWIW, the Linux machine I'm typing on here doesn't have emacs, neither do any of the virtual machines I run on the internet... it's possible my Ubuntu machine does; oh! I just checked; no, it doesn't.

And, as it happens, neither does this mini-Linux install. It has a "lookalike", developed by the Bellard, called QEmacs.

Not a vi vs. emacs war...each has it's uses... (and when does a person only ever use one of them?)

but look, if it doesn't have block copy and paste using a mouse, then what good is it? (nedit should at least get a mention here...)

:)

There's no reason to poorly quote the whole post that you're responding to, luser.

Random all-capping your words makes you look even more clueless and early-teenaged.

If I might be permitted a brief diversion? I've just come upon this ...

http://www.bbc.co.uk/news/technology-13453497

" A fake security program for Apple computers called MACDefender has racked up a significant number of victims. "

Bloody hell! I thought that immunity from this sort of thing was part of the Joy of Apple ?

And now back to wondering where I put the floppy disks that hold the early releases of 'DOOM '. I've just managed to find the usb Floppy Disk Drive that I once thought would be useful but which has never been used ... the disks just have to be somewhere in the cargo bay along with Windows dos disks and such like stuff since I wouldn't have thrown them away - bound to be useful one of these days type stuff.

" Random all-capping your words makes you look even more clueless and early-teenaged."

And mentioning this does make You look rather Smug and Middle Aged.

Every time I tried emacs I got shooting pains in my wrists after a couple of weeks of using it. Have you noticed how most of the FSF's programmers wear wrist-splints? Emacs is an ergonomic nightmare on a PC or Mac keyboard -- to work properly without cripping its users it needed the kind of keyboard found on an early 80's lisp machine.

This is your yellow card, Kevin. He may be an emacs user but there's no need to start throwing random abuse at him. Do it again and you'll be moderated.

MacDefender isn't malware as such -- rather, it's a phishing-like scam: you (the notional mug) download it, it runs, it says you've got a virus and the free edition can't remove it, so please to go to this web page (in Russia) and enter your credit card details to pay for the full version. Then the virus mysteriously "goes away".

This is social engineering, pure and simple, and relies on the fact that of any large number of people a certain percentage, be it in single or double digits, are idiots who will click on a link to malware after being explicitly told DO NOT UNDER ANY CIRCUMSTANCES CLICK LINKS LIKE THAT.

It's malware that seems to request an admin password to install, which makes it terribly polite malware by my standards.

I'm not too encouraged by what the Arstechnica coverage suggests about Apple's response to it though.

It comes packaged in a regular app installer, hence the ask-for-permission-to-install. That's why it's arguably not malware as such, but merely app-assisted phishing. (I still wouldn't give it my credit card number, though, however politely it asks.)

Has anyone been able to install a compiler and compile the hello.c program under this?

The compiler is tcc instead of the usual gcc. These 3 lines will do it:

tcc hello.c -o hello chmod 777 ./hello ./hello

I've never used emacs. I installed and tried it, years ago, but it kept saying 'garbage collecting' and coming to a halt. On a X-windows PC (or Windows one) people nowadays use gvim, which provides a GUI interface, and fall back on vim if they're working in an x-term. So at Armageddon, I'll have to stand under the vi banner:-)

All but one of the words that were all-capped are accurately all-capped.

"All but one of the words that were all-capped are accurately all-capped."

Not really; "EMACS" is incorrect because these are not the TECO Editor MACroS, but a different editor. I believe "Emacs" is the preferred method of writing it.

"VI" is clearly wrong; it's just "vi" (for the "visual mode" of ex; "ex" itself was "extended" from ed; "ed" is for "editor", the default line editor on Unix).

And, of course, "LINUX" is wrong as well; it's "Linux".

I'll let the "AND" go by as a form of emphasis :-)

It's not so much that you can run a 486 emulator in a browser, as what this implies about browser speed.

I was recently blown away by this genome browser: http://www.biodalliance.org/

The front end is pretty mundane, but behind the scenes: It's fetching files from multiple domains and displaying them together (CORS). It's parsing binary files. It's decompressing gzipped files. It's fetching just the parts it needs from the server, from a weird seekable gzipped file format called BAM. In javascript. All clientside. All the servers need to do is serve files.

See, reaching up to hit esc bothers me more than curling my left pinky under to hit ctrl. But again, different strokes for different folks. And my vi skills have improved considerably since I started adminning at a mainly Solaris office - emacs is only on a bare handful of servers here but vi is everywhere. Necessity being a mother and all that.

Actually, I suspect my ctrl/esc issue boils down to the halfassed method I "learned" to touchtype with. The home row is just a row with bumps on it for me to return to occasionally after my hands get too far afield, which means that ctrl is comfy but esc means shifting my whole hand up and out of position. I wonder how universal that is - trained typists use vi while us floaty typers prefer emacs. Hrm.

There isn't much I can be bothered to get all religious about these days, to be honest. Except maybe keyboards, I'm very definite about those. (Buckling springs for life!)

On the subject, I got to playing around with the javascript machine the other day and I'm still amazed at how well (and complete!) busybox works. I'm sort of tempted to see about compiling it into my environment for those nooks and crannies that GNU hasn't yet reached. df -k was fine back in the day, but even on 8 gig disks I start wanting -h.

I wonder how universal that is - trained typists use vi while us floaty typers prefer emacs. Hrm. That's actually quite true, I'm a floaty typer and hitting e.g. CTRL-X a lot doesn't bother me one bit.

About those other issues, yeah, I forgot that this message board doesn't support quote tags, as far as the EMPHASIS is concerned, I just think it's convenient in a non WYSIWYG environment like this comment box and I can't be assed to put b tags or something similar every single time. I really don't see why people get so worked up about it.

This really dates my IT mojo (in fact, I was canned in 1999 along many thousands of others), but what are the advantages of browser-based platforms?

For one thing, Java was an attempt to break Microsoft's operating system near-monopoly by circumventing the applications barrier to entry. It failed, in part due to the steps MS apparently took to hobble it.

As can be seen from the comments above about the iPad and Steve Jobs, a similar reason exists today with respect to the Apple app store.

For another thing, the browser-based platform is a part of the "cloud" model, which is (as a whole) advantageous to the providers and their customers but not so much to the users. However, while there's money in it, it will continue to be promoted.

The whole Javascript PC emulator is a nice thing, I like it.

As for editors, as long as I don't need to use Edlin or TECO I'm probably fine. Every day at work I use Emacs, vi, vim and QtCreator as editors, and each one of them has good and bad features.

vi(m) is especially good while editing something on a mobile device - my n900 likes it.

At a previous job we had a MicroVAX running VMS, controlling the radio telescope. On some lonely observation night I realized that the VMS manuals were there on a nearby shelf and I spent most of the spare time that night trying to learn TECO from the manuals. That was fun, in an Intercal way.

The VMS also had Emacs, so that was what was used for most of the time.

Who knew that in 2011 I could still find a fresh steaming emacs vs vi fight.

Fun to watch but I do feel like I'm in a time warp.

Oh maybe it has something to do with the world ending tomorrow.

Anyway I prefer vi.

Consider my hat thrown in :)

Haha, there's not much to do besides compiling and running a c++ program, but there is one thing that's fun: watching it crash (a kernel panic, from the worlds smallest virus).

That's right. I fork bombed it.

Always wanted to see what that looked like, so this seemed like a good place to try it.

If you're serious about DOOM It works fine under DosBox, I've been keeping it (and DOOM 2 -and about 300Mb of other DOS games) 'live' on several machines since new. They currently run on two machines including an Acer netbook running Ubuntu (desktop not UNR), but you ought to use a mouse; trackpad and gaming on a netbook doesn't cut it!

Aside from that I'm a dabbler rather than tech.

Yep. Most of those also apply to the other editor I spend a lot of time in.

I might, possibly, quibble with Bill Joy's characterisation of "vi as a modal editor". To me it makes more sense to see vi as an editor that has a few commands that take arbritrarily long arguments, terminated by pressing Esc.

Try something like: oHello!<ESC>

Then press . (repeat last command). That doesn't look like a mode switch, that looks much more like a command with indefinite argument length.

I think that's only part true. If you use vi in direct mode, it's a modal editor (at least if I understand what is meant by a modal editor correctly), but if you use it in scripted mode, then it's "an editor that has a few commands that take arbritrarily long arguments, terminated by pressing Esc".

I make sure I can work in both vi and emacs, myself. I tend to prefer emacs for large files and source code, and vi for small edits of config files, but I make sure I remain familiar with both, as well as "sed" and the like for when I don't even have an addressable screen to work with.

Charlie, if you find yourself on a system that has emacs but not vi, do not fear -- there's a vi emulation mode for emacs that you can turn on. I used to use it in order to drive fanatics of both camps crazy: the emacs people because I was discarding its "superior UI", and the vi people because I was discarding its "comparatively minuscule memory usage and resource requirements". It was funny to watch them all turn red in the face.

Yeah, I know about viper mode and I know enough emacs to get stuff done; it's just that if I want vi I might was well use vim for real rather than lose most of emacs' functionality, and emacs without the lobotomy makes my wrists hurt.

scentofviolets, my brain keeps coming back to this conversation because I keep thinking, "if only scentofviolets knew about matplotlib. I bet scentofviolets would really like that". So I am linking to it in the url field in the comment here.

I really agree with you that trying to make UI widgets in java looks painful. I don't enjoy making UI things, but when I did work related to it, I liked tk. Python and tcl both have devoted scientific followings, and I'm more familiar with python these days. I still like pure tk more than the tk for python, or wxWidgets for that matter. but I still think they are better than java swing.

Anyway, re Greg Egan applets and source code. I am a fan type of person towards my favorite authors, but not an artist, so I don't make fan art. I have been tempted to do fan programming though. maybe re-implementation attempts of those applets in other languages for fun.

I have friends and acquaintances who share dot files on github and elsewhere. Would you consider sharing your dot files? I am interested to see what you have in your .vimrc. (you use vim?)

Nothing interesting in my .vimrc, alas. I believe in stock vi behaviour -- comes of changing machine frequently.

The links works on an iPad2 though. Compiled hello.c with the attached tcc compiler.

I was about to say "oh no it doesn't", but it seems I didn't give it enough time.

I am now running Linux on my non-jailbroken iPad. Don't tell Steve.

(1) I have just booted this on my Kindle. It runs as slow as a frozen dead dog with no legs, but it runs. Yes, even the C compiler.

(2) I always remap Caps Lock --- that big, convenient, and other wise utterly useless key on the home row --- to Control. It makes doing anything Unixy so much nicer.

(3) People who like old school word processors may want to check out WordGrinder: http://wordgrinder.sourceforge.net It's a keyboard-driven terminal-based word processor (note, not a text editor) designed for first drafts and basic prose editing. It does bold, italic, and a few character styles, and if you turn off the status bars it will give you a screen that contains your text and nothing else.

Looks at wordgrinder ...

Boggles!

Dammit, that's neat. I now have a use for the Psion 5 I picked up at the car boot sale the other week -- stick Linux on it and use it to run wordgrinder, then use latex2rtf to turn the results into something useful. (I am not going to roll my own troff macro parser. Gack.)

NOTE Apparently the Safari support came in during a relatively silent update. (It really didn't run in my iPad the first time I tried it.)

What I'd like to see?

(In other words: you can edit files on a designated filesystem, then "save" the VM webpage and the copy of the filesystem in question will be saved with your edits.)

At the end of which, you'd then have a single file on a memory stick (or cloud-based file store) containing (a) a hypertext documentation system and (b) a command line Linux environment.

I would ... well, "killing" is too strong a word; but I'd probably move into it for good, using vi and MultiMarkDown for book production and TiddlyWiki to keep track of ideas and notes.

Alas, WordGrinder is almost certainly too slow to be usable on a Psion 5 (I've run it on a 266MHz ARM box and it can barely keep up with my typing). That's the price for writing it in an interpreted language, unfortunately. There is a really cool fast JIT for Lua that's beating the socks off everything else (on x86, people are actually calling into Lua from C for numerical code because Lua is faster), but it's not quite out yet for ARM and it's probably non-trivial to use.

As for RTF export... working on it.

Alas, WordGrinder is almost certainly too slow to be usable on a Psion 5 (I've run it on a 266MHz ARM box and it can barely keep up with my typing). That's the price for writing it in an interpreted language, unfortunately. There is a really cool fast JIT for Lua that's beating the socks off everything else (on x86, people are actually calling into Lua from C for numerical code because Lua is faster), but it's not quite out yet for ARM and it's probably non-trivial to use.

As for RTF export... working on it.

heh, I think I've only ever used vi interactively and (perhaps obviously) think of it as having text-insertion comands taking arguments of indefinite length, terminated by pressing ESC.

That way, it conforms with ed, the first unix editor I learned (although I was pretty proficient with the WordStar keys at that time).

Ok, I found an error in #194; it should end "...terminated by pressing '/' ". Given that I'd agree about interactive mode, but still say vi's a modal editor because you need to switch between cursor movement mode, edit mode...

In batch mode, it starts to become useful for doing things like adding configuration headers to 240 files at once, including things like their catalogue numbers!

From the source:

function testtypedarrays() {       return (window.Uint8Array &&             window.Uint16Array &&             window.Int32Array &&             window.ArrayBuffer); } if (testtypedarrays()) {       include("cpux86-ta.js"); } else {       include("cpux86.js");       document.write(''); }

I guess they found a way around those non-typed arrays.