Slashdot Mirror

mMosaic is still available as a buildable package in the NetBSD packages collection (pkgsrc.) Just on a whim, I launched a build a minute ago. *bip* It built, in less than a minute.

Here's a screen capture of mMosaic.

And here's a screen capture of the Slashdot homepage in mMosaic.

Why bother with 9.0 when 9.1 is already available, and a preview version of 9.2 just came out.

DougWebb covered half your problem. a2ps is the other half. That'll let you take a text file and convert it into a PostScript (printable) file, and if anything, it has too many options. Printing something nicely foldable with as small a font as your printer and eyes can handle is just fine.

I've used it for long walkthroughs for RPGs; most recently, FFX-2 100% completion. That squeezed a 120+ page document, printed naively, down to four sheets of paper (with a bit of manual editing to remove silly whitespaces in the walkthrough; the author accidentally left some form feeds in, I don't even know how they'd do that, but there it was...).

It's easy to use, it just takes a while to wade through the options.

Even without cryptographic jiggery-pokery, ..... Say, wha?????

The cryptographic jiggery-pokery in question would be a camera which digitally signed its output. It could use a key built in on a tamper-proof chip.

It wouldn't be impossible to fool such cameras, for example you could use rear projection on a screen in front of the camera to make up a faked image. But it would be more difficult.

As an example see this academic paper on the "trustworth camera", http://www.tsi.enst.fr/~maitre/tatouage/icip96/100 7.pdf (warning PDF).

Richard Stallman please note: this is a genuinely GNU project, so I'm calling it "GNU a2ps" with pleasure and satisfaction, but the Linux I use is either "Mandrake Linux 9.2" after the distributors who do some much work to get it all packaged and integrated right, or "GNU/SGI/BSD/KDE/Apache/Sun/IBM/{blah,blah,cows come home}/OSF/Linux", or just plain "Linux".

If you have something like gv (or ghostview) that'll read postscript documents, a2ps does a wonderful job of pagenating and formatting text of all kinds ready for printing to a Postscript printer or viewer. However, that doesn't solve your bookmarking problems. It should relieve some of the eye-strain, though.

• Opera
• Konqueror
• Mozilla
• Galeon
• Skipstone
• Netscape

The article did not review a number of browsers. Here are a some more that you may want to try:

• Arena
• Amaya
• Chimera
• MMM
• Emacs/W3
• Lynx (text based)
• Links (text based)
• Debris (text based)
• w3m (text based)
• Libwww (text/line based)
• HowJava
• Express
• Armadillo (was Gzilla)
• Mnemonic
• Kde (file manager with builtin browser)
• mMosaic
• QtMozilla
• QWeb
• Mosaic
• Arachne
• Beest
• Beonex
• BrowseX
• Grail
• Dillo
• NetRaider

And how the disclaimers: The list above by no means complete. The browers above were listed in j-random order. Some browsers are in early alpha stage, some in Beta and others are in full release. Some of the browsers may suck, some are OK and some are good. Your mileage may vary. Sorry If I left out your favorite browser. IE was left off the list for obvious reasons. Good while supply lasts or until Bill Gates takes over. I'm not a member of the FCIA. Void where cast as (void).

There was a distributed computing project called PiHex that lasted several years for computing the five trillionth, 40 trillionth, and the quadrillioth bit of Pi, using a variant of the Plouffe discovery, Bellard's formula.

A proof that digits of Pi are random would indeed be news, albeit not exactly a surprise; I'd comment on it but the article's link seems bad or swamped at the moment.

--LP

P.S. Google has a nice list of Pi links.

Don't underestimate the capabilities of the consumer grade stuff. I haven't tangled with those since the USR Sporster Voice was brand new and vgetty was Zyxel only (IIRC); but it gave sound as good as a direct phone to recorder connection through a professional adapter (Gentner microtel; overpriced gadget if ever there was one). It had DTMF recognition too, that worked under my limited usage.

The point I failed to articulate clearly is that there's only so much you can do to stuff real audio down this thin little straw which is a telephone line. There's little difference perceptible to the listener between ultra expensive, "Do it Right"(TM) harware on the provider's end vs. what can be hacked up on a real budget by someone who might suddenly be taken with the idea.

And just to throw a link out in support of "you can do anything in software": the generic Linux Soft Modem is educational about alternate uses for the silly winmodems... They seem less silly in this context.

I have been programming for the last 10 years. I am pursuing a PhD in computer science. I have installed Linux networks, and even have coded some Linux device drivers. I can thus be called fairly familiar with computers.

• Linux is not yet ready for the desktop. Installing fonts is a pain; printer support is pitiful (I have yet to see how to get colors right for the Deskjet 690C); decent desktop applications are not yet there (Gnumeric is still fairly weak and still has quite a few bugs etc...)
• Windows automates everything and tries to think instead of the user. I do not appreciate it when a computer tells me what to do, even less when it does something stupid. Furthermore, the desire to make things simpler for the casual user had them not to include any diagnostic tool. The icing on the cake is the absence of protection, which favors the spread of a myriad of viruses.
• The Macintosh is even worse. You just can't order it to do something if it is not proposed in the standard choices. Some system options, for instance in PPP, are hidden in some obscure dialog boxes and no documentation is available. I have just spent some time trying to get a Mac to export a drawing into PostScript: impossible, or there is yet another obscure choice to make.

It is a pity that with the power of current computers, nobody is able to make a system that is truly user-friendly; that is, that does what the user wants instead of getting him to do stuff in obscure command lines described in even more obscure documentation (Linux) or pissing him off with silly restrictions and railroaded choices (Windows).

I have seen the Eazel presentation at Guadec. I have hopes that it will be a bit more like what I'd like. Yet I am a bit afraid that it is going to be the next step of evolution of the current interfaces: more eye candy and gizmos, but little actual change.

Andy did a demostration at the Guadec conference a few months ago of Nautilus and people were pretty impressed.

We saw his prototype last summer, and back then it was already very interesting, it already was a testbed for new ideas (things that I had not seen before). Describing them is hard, as they were very smoothly integrated into the system, things just "worked".

Miguel.

Fabrice Bellard wrote LZEXE, which transparently compressed executables under DOS, as well as the 486 mpg123 patch -- yes, MP3 playback on a 486, which I used on a 33Mhz box. Thanks to both of them, we all squeeze more efficiency out of hardware.

Fabrice Bellard wrote LZEXE, which transparently compressed executables under DOS, as well as the 486 mpg123 patch -- yes, MP3 playback on a 486, which I used on a 33Mhz box. Thanks to both of them, we all squeeze more efficiency out of hardware.

With a traditional modem, there are three main sources of latency.

First, usually PPP is used for dialup IP connections. Unlike sync ppp over ISDN (or leased lines), it has to run asynchronous because it has no way of sending packets with the traditional command set. It can only send bytes. SyncPPP, on the other hand, sends whole packets delivered directly to the HDLC link layer. I know of no Hayes command extension that allows direct access to individual V.42 packets.

Second, with external modems, the data needs to get converted to serial and back to parallel. This adds less latency with higher port speeds, but even at 115200 bps, a byte still takes ~0.1ms to even get to the modem. This is less of a problem with newer internal modems, which just look like a 16550 to the software, but have no serial data path because what's looking like a 16550 is a clever interface for the modem chip itself.

Third, the modem needs to do error correction, which involves receiving a whole block (of 256 bytes usually) before it can be sent on to the computer. Anything without error correction could sometimes deliver low latency, but the first need for retransmission would ruin average latency, because the need for retransmission is not detected by the modem, but by the PPP layer above. (Imagine a 1500 byte packet that needs to be retransmitted because of a transmission error. Could take a whole second with older modems, at least 250ms with decent ones)

The real key to low latency modems would be implementing a direct packet access scheme for the PPP driver, or implementing PPP on the modem itself (ideally with some kind of link level compression). Then, with the other side properly tuned as well, a packet could be transferred with no more latency than is needed for the transmission itself, because PPP would eliminate the need for V.42 and CCP would eliminate the need for V.42bis. And - implemented either in hardware or in software with a broad data path to the actual line interface - these would be pretty fast.

There is some work on Linux-Softmodems underway. These should excel in latency, when finished and properly supported by pppd, because they implement most of the ideas above. They still need help, but there is source code already available here.

Holger