I haven't looked at QNX in 5 years or so, so I don't know the current status, but it was a cool system when it was new. It used a microkernel that fit in something like 8KB, with a message-passing operating system on top. Besides fitting in the cache on a 486 (:-), and generally being designed to support embedded systems.
QNX was also a real-time OS; not many Unixes could do that. For lots of applications, just being fast is fine, but if you're trying to control hardware that wants its interrupts handled in N microseconds so you can tweak physical behavior, it takes lots of support from the interrupt handlers and schedulers. Masscomp was one of the early players in the field, and some of the later System V releases had optional real-time schedulers. There were POSIX real-time specs around 1990, but I got the impression nobody much cared about supporting them. It's nice to see that there's some real-time Linux work going on as well.
Remember working on a Sun, and installing expensive non-free software packages that key off the machine's serial number? And Macintoshes supposedly have serial numbers also. This isn't much different. And Microsoft has serial numbers hidden various places in their OS's as well - they don't need to use the one in the CPU.
The big issue is what gets done with the number; for that you'll need to blame Microsoft, if for some reason you're running their operating systems instead of Linux or *BSD (yeah, I am on most of my machines:-) Intel did come out with a patch to turn off the serial number feature, though of course Ian or somebody came up with a program to turn it back on without rebooting, demonstrating that Intel's patch was lame.
In a world of desktop computers using file servers for most common software, MSSingleInstance isn't necessary. But that's not the world I work in.
Laptops need this! The hundred or so people who work in my building use laptops, so we've got our office with us whether we're at our desks, out at customers, working from home, or on the road/train/airplane. That means I really *do* need my own copies of most of my software on my own machine, and I need to be able to back my stuff up on a file server so that when my laptop's disk gets crashed, I can restore all my stuff, and restore it efficiently rather than reinstall &^%*^% MSOffice and all my other software, and so I've got the version of everything that's on *my* laptop, not some server that may have newer or older stuff.
Would this be easier if MSOffice and other popular software packages had the decency to keep all their static content in one place (e.g. C:\readonly) and their changeable stuff somewhere else (ideally, somewhere else *standard*), so you only need to back up the changeable parts? Sure! But that ain't gonna happen, especially at Microsoft, but not with a lot of the other software vendors out there today. It's much easier to build an interesting and occasionally useful admin tool that to fix corporate culture.
A lot of the non-software on my computer is training material and presentations in MSPowerBloat format - many of my coworkers have copies of identical material, but we really need them for portability.
Would all of this be easier if we used vi + LaTeX or HTML editors for word processing and GIFs/JPGs or Really Good Postscript for pictures, so the standard software was 5% as large and the presentations were browseable? Yup. But this is Corporate America:-)
The term "X.25" really refers to multiple things, all of them annoying. The Layer 2 part is LAP-B or whatever, but the definition of the layers doesn't line up cleanly with either TCP/IP's worldview or OSI's. There's also the X.3/X.28/X.29 terminal+host protocols that give telnet-like functionality. It's also possible to run the IP protocol stack on top of X.25 instead of using point-to-point private line protocols like HDLC, and various parts of the Arpanet did that, but that's not what most people mean. Some people even ran the Evil OSI Layer 3 and Layer 4 protocols on top of X.25 Layer 2. (CLNP/CONS/8473...)
The most common X.25 environments I saw in the US used these for terminal emulation, so you could take your 3270 controller or your dumb-paper-terminal controller and log on to a mainframe or timesharing host, sort of a bondage-oriented version of async-dialing to a Unix host. Unlike frame relay networks, where each customer has their own permanent virtual circuits between their own locations, X.25 was designed for telcos and PTTs who could connect you to any of their customers, if you knew their network address (equivalent to knowing a phone number. To add some security, there were features like Closed User Group.) This basically meant that anybody within France, or anybody within Germany, could set up an X.25 connection to anybody else there, and could sometimes do international sessions as well. It doesn't matter that there's no Internet protocol if everybody you want to talk to is on the same Layer 2 network, so this was how computers at European universities talked to each other.
The canonical book on why all of this is a bad idea and TCP/IP is better is M. A. Padlipsky's The Elements of Networking Style and Other Essays and Animadversions on the Art of Intercomputer Networking. Prentice--Hall, Inc., Englewood Cliffs, NJ, 1985. I don't totally agree with him - X.25 did error-checking at Layer 2 because it was designed to run over French barbed-wire, and while it might have been faster to restrict those functions to Layer 4, that mainly became true when fiber-optic long-haul networks made bit error rates many orders of magnitude lower than the original facilities X.25 ran on. But he's mostly right on.
BTW, calling ISDN a "layer 2 protocol" is pretty dodgy. The D channel does run X.25, with whatever features the telco feels like supporting, but the Bell Labs and Nortel telephone switch developers never really had the clue about what data users want (:-), and computers had gotten faster by the time ISDN was priced for consumers, so what everybody really uses are ISDN B Channels (which provide Raw Bits at 64 or 56kbps) with the end-user's choice of Link Layer framing protocols (I forget if that settled down on V.110 or V.120?).
The US relaxed their rules on Supercomputer exports specifically so that the Playstation 2 wouldn't be banned - though they missed a bit and the highest-speed G4 Mac is still regulated. (There are leftover Cold War regs against selling big computers to Commies.)
I don't know if the US talked Japan into regulating supercomputer exports, but they did talk them into crypto export regs, primarily in response to the (NTT or NEC?) development of an RSA chip.
"Can't Export Without A Permit" doesn't mean you can't export it - it just means you need to get a permit. If the motivation here really is restricting gray-market sales of Japanese versions of the product to the US, Sony probably can manipulate the permit process to prevent it.
Steve Jackson not only made his saving throw against the FBI, but also against the business environment - staying in business 10 years is an accomplishment in and of itself.
http://www.sjgames.com/
--- Bill, partially responsible for the One of Disks...
Gibson's previous uploading-into-the-machine episode was quite good. This one stunk. The plot depended on dumbness - the physical players are getting killed, yet nobody stuck around or even camera'd the room where their bodies really were - they only watched the game viewpoint at the control room, which was also not built with a camera in the room with the bodies, though it did have heartrate monitors.
I strongly agree with Malign's article. I hope this doesn't end up as the pilot for the Lone Gunmen series - they'd do much better forking off of the Lone Gunmen at Defcon or some of the Lone Gunmen Help Mulder Sneak Into Places episodes.
And Scully was wearing too much gear -- Mulder did a better job of loking like beefcake in the gamer suits:-)
Fortify.net is a UK site with software that fixes Netscape 40-bit browsers so they'll do 128-bit. One useful feature the web page has is an SSL checker https://www.fortify.net/sslcheck.html which tells you what level of encryption you're running.
www.openssl.org has an Open Source implementation of SSL. I think their latest version is 0.95.
There have been machines that almost worked that way. One of the early hypercube machines (N-Cube? IIRC) had a master node, and 2**N small nodes with a CPU, RAM, and communication connectors. It took care of virtual memory by assigning each process as many nodes as it needed, rather than assigning blocks from a shared memory space.
Carpal Tunnel, Good User Interfaces and Designs
on
Voice-Op Linux PDA
·
· Score: 3
I know people who would _kill_ to get Dragon Dictate running on Linux, so they can get their work done without having to dictate into a Windoze box and transfer files over to Linux. No, voice isn't the ideal interface for all problems, but for a lot of people it's better than not being able to type because their wrists hurt too much even with that trendy Silicon Valley fashion accessory, bondage-style black leather wrist supports.
Do you want the new user interface applications developed in open source on Linux, or only on MSWin3K and the occasional Macintosh? Yeah, I thought so... There's also the PDA-like devices that will come from the cell-phone makers, and it'd be nice to have good programming interfaces to them. Some things will be killer apps, others will be toys we get bored with quickly, but open development environments will make it easier for everybody to try things out.
Some user interfaces are just dumb replacements for keyboards on machines that have conventional-sized screens. There are a lot of problems for which this is adequate, including the typing-impaired but also applications where you want hands-free but don't need to be eyes-free, such as information kiosks ("mirror, mirror on the wall, where can I find beer in this airport?"), reference-finders for workers in messy environments ("zoom in on the picture of the carburetor"), etc.
Voice commands can also be mouse/menu substitutes, for people who like them. A long-known safety principal is to limit the commands to a relatively short set of very safe commands. You don't want to have "rm -fr *" there, but "mail" and "phonebook bob smith - yes - dial" are pretty safe. (Ok, there are still risks like that web site with the background sounds saying "phonebook 1-900-RIP-OFFF - dial", but you can decide how much risk management you want. And you want it to ignore almost anything after the keyword "Daddy".) One of my coworkers had a PC-based application; we'd be on a conference call, and he'd occasionally interrupt to tell his computer to fetch a file. He doesn't use it much any more - I'm not sure if the novelty wore off or if he decided to cut down his weirdness quotient on the phone.
If you're willing to do voice input and output, portability becomes more practical, and computers can be a lot smaller because they don't need screens and keyboards, and more flexible because you can stick them in a pocket or backpack and use a headset. Sure, people will look at you funny walking down the street talking to yourself, but here in San Francisco, half the people on the streets are either talking to their cellphones or their liquor bottles, and society has adjusted to it. A hands-free voice portable makes an interesting combination with a GPS system and datacomm; it can give you while you're driving, tell you about nearby restaurants and traffic jams, and maybe let you call nearby cars ("Hey, CA123456, use your &^%&^% turn signal!").
MP3 Players can also benefit from voice interfaces, since it mainly requires adding a bit of storage to the computer you're already carrying. ("Computer, play Dark Side Of The Moon three times, volume low, speakers, order large pizza from Foobaros.").
It's nice to see the President bitten by the consequences of the Adminstration's anti-encryption policies. Digital signatures are not tough to implement, but their deployment in chatware has been impeded by the FBI's wiretap-everything demands and the NSA's leftover Cold War mentailty, just as the deployment of encryption and signatures in email, routing, firewalls, and other networking systems have been.
Yes, it's possible to do signatures without also adding encryption capability - the laws have been relatively explicit about that on paper, if not in practice. But the most common signature algorithm, RSA, also does encryption, so it's only usable by software that ignores the encryption regulations. And one prominent authentication system - John Gilmore's export request for DNSSEC name servers, which can protect the Internet from the forgery that's commonly used to attack systems - was refused export permission (retroactively, after the permission had initially been granted.)
Developing a good interface for authentication on chatware takes work - you don't want to hang five lines of "---BEGIN PGP SIGNED MESSAGE--" on every line of chat. Cooperative development is an important method for developing good interfaces - but it's one of the areas hardest hit by the encryption regulations, especially cooperation between Americans and Non-Americans (not only Non-Americans outside the US, but foreign college students here in the US as well.)
There are a few projects for secure chat that I'm aware of - GALE, at www.gale.org, is a relatively sophisticated system that's inspired by MIT's Zephyr system. It's an open architecture with several different clients developed by several different people. And of course, people are always developing new IRC clients, but patching security on to things can be tough.
140GB is a nice start, but it's not really that big:-)
My building has about 70 people on our LAN, typically using laptops with 2GB disks. A 140GB disk would let us get _one_ backup for everybody; you'd need another for incrementals. (Realistically, compression helps a lot, and half of that capacity is identical copies of Microsoft officeware. But lots of buildings have more than 70 people.)
A few years back a network architect at a Weapons Lab That Shall Remain Nameless tried to figure out how big a LAN would be enough, so they could install a secure LAN once and not have to replace it like the previous few. You can do this by making the user's I/O devices the bottleneck - not their computers, but their eyeballs. 2048x2048 pixels, 32 bits deep, times two eyes, times 30 frames/sec is about 1 Gbps. You might need more horsepower back on the supercomputer, but if it's all their eyeballs can handle, it's Enough. So a 140GB disk gets you about half an hour of uncompressed video - it's Not Enough. (Of course, if you don't mind lossy video compression, it's plenty big enough...)
I understand the need not to use lossy compression for professional-quality video storage, but that's not the only option. Even non-video-oriented compressions like Lempel-Ziv or the things in gzip can work decently on a wide variety of data, using lossless modes that let you reconstruct the exact original bitstream. You should be able to do much better by taking advantage of video's properties (e.g. lossless encoding of differences from frame to frame or row to row.) If you can even get 3:1, that takes your 20 minutes of video to 60, which starts to be useful.
The last time I worked on this stuff was doing meteorological imagery a decade ago - good-resolution satellite pictures compressed about 3:1 using "compress" (the LZW-based predecessor to gzip), which was enough that I didn't need to do anything fancier. (Radar images got into trouble, because they compressed about 50:1, so my first cut at the software compressed the stuff faster than the input across the network:-)
Bill Gates, reacting to the threat of a Beowulf cluster of Canadian companies and wanting to use Vancouver as an extension to the Seattle housing market, announced that Microsoft is buying Canada.
"It's also a convenient way out of our US anti-trust problems - rather than being subject to the Justice Department, we're now dealing with the State Department and the Pentagon, who are much more flexible. It's possible we'll still have to divest Quebec, but c'est la guerre."
Ah, the good old days - if you want a real rant on X, ask Hugh Daniel some day:-). But yes, having some network-based window system is infinitely better than having none, even if it's as clunky as X is. When you want to get work done, you just open another window on your screen and go do it.
The windowing system part of NeWS didn't survive - Postscript was evil and unsafe and insecure and undebuggable, but what you saw really was what you'd get - stuff looked good on the screen, and great on paper, and it was really the same fonts, not some different font for different printers and different size because it's paper, and the stuff aliased when it should and aligned when it should - Windows still feels like looking at a fax of your real screen image.
But what did survive was Gosling's experience of making processes work together across different pieces of hardware - giving you the flexibility to split work between client and server any way that makes sense, which involves sending code from the client to the server to get it run there. This let NeWS do most mouse handling on the server (that's the machine that draws stuff on the screen near your face, for you non-X folks who think the server is the big box in the back room.) And it lets your web browser run Java programs in cooperation with applications back on a web server somewhere, without needing to install plugins in your browser. Security is one of the obvious lessons from NeWS, which would run any Postscript you handed it, if it didn't crash in the process, and adopting the p-code sandbox approach makes that sort of model possible, if not necessarily blazingly fast. (And lots of tools for making things fast have been added later.)
There's a lot of spectrum out there - think 5-50 GHz short-distance line-of-sight. (There isn't enough technology development up there yet for really general applications, but it can happen if FCC stays out of the way, which it won't, or if it's too hard to avoid interference with other people in that range.) Some of the Ultra WideBand stuff may also be effective.
and the web page doesn't say what FOOBAR IS - it only says that it's better than FOOBAR 6.3.7 because the frobulatror is now tweakable and the incompatibility with ZORGLOB 2.1 or FooBSD has been fixed, along with that annoying memory leak.
So we know that MANDRAKE has a new Graphical Installer. That's Nice (or Not Nice, as some respondents prefer), but there's no mention in the lead story about WHAT MANDRAKE IS. It's possible that it IS a graphical installer, but it's pretty tough to tell from the download page.
So, folks, remember that your new version announcements will not only be read by people who are intimately following your cool developments, but by people who've never heard of your project. A good sentence or two of background and maybe a home page pointer can work wonders.
This seems fair enough - Red Hat Linux installation instructions include options for keeping old stuff and options for blowing away everything on the disk and starting from scratch; I found the latter was simple and reliable:-)
As far as fdisk goes, MS probably still thinks they own fdisk - after all, it came with MSDOS, and the Linux version is merely a superior imitation.
Not strictly open-source, since what they provide are certificates, not code that has a source to open, but what they provided is an alternate set of policies and prices for certificate service. Anybody else could do the same - they basically di d a good sales job as a second-source certifier, and appealed to the small market by lower prices and more flexible policies, and got the big browsers to include them.
PGP doesn't do a hierarchical certification; it does a web of trust instead, where everybody can certify anybody else's key. The browsers don't use it, but the obvious way to adapt it would be to let you include your own PGP key as a certifier and trust anybody who's key you've signed.
The US Export Controls, annoying as they are, sate that they don't restrict export of authentication products, only privacy-protection products. This means that a program that only signs and verifies keys, but doesn't generate them, is perfectly exportable, and a service that certifies keys can operate cross-border with no harassment.
In reality, it's a bit more restrictive than that - the RSA algorithm uses the same routines for encryption and signature verification, and for decryption and signature, so export of source code for RSA-based certification systems, which should be legal, might not be (or at least might have trouble getting permits if you apply for them; John Gilmore's permit for DNSSEC was granted and then yanked). But export of binaries still should be fine, assuming they're only designed to do signatures and verifications well, and that's enough to run a business on.
Digital Signature Algorithm/Standard (DSA/DSS) signatures only provide signing/verification, not encryption, so a system using them should be exportable without a permit, even in source code. (In reality, the "subliminal channel" misfeature means you can use it for slow symmetric-key encryption by hiding bits in your choice of random numbers, but that's ugly and the Feds like to pretend it's not built-in - at least if you don't add subliminal-channel support to your crypto source code.)
Online purchases of tangible goods are no different than mailorder purchases - they're interstate commerce, and there've been laws either on the books or emerging for the past many years. Legislators would like to pretend they're different (another chance to tax stuff), but the real difference is just convenience and speed - it's faster to use Barnes&Noble.com than to get them to mail you a catalog and order stuff the old-fashioned way, though specialized publishers like Laissez-Faire Books did ok at it.
Some states, like New York and New Jersey, have reciprocal sales tax agreements that encourage collection of sales tax for mail-order across state lines; others don't. My wife used to do programming for a mail-order shop which was deciding whether to get involved or not, and New York is Obnoxious to deal with - sales taxes vary by town, township, county, etc., not always on zipcode lines.
The new issue with online sales is sales of non-tangible goods. The classic examples are software (big money from the big vendors who are easy to locate and tax, mostly-small money from shareware which is usually harder to locate), sound recordings (emerging non-pirated MP3 business) and pictures mostly in the (ahem) adult entertainment business. What's the taxable location, if any, of a performance viewed across state lines? Local governments could have sales taxes on movie and concert tickets, but they usually don't, though they may be hidden in the ticket price; what if you're listening to the concert from somewhere else?
Libras tend to believe that stuff....
on
Geek Horoscopes
·
· Score: 1
Gullibility runs high for most signs....
The life of an onion not knowing up from down
on
Sex in Space
·
· Score: 1
There was a research paper by that title* a couple decades ago. As a trial on the ground, they kept turning the growing dish over constantly; the onions weren't able to figure out which way to send roots and which way to send stems, and didn't do very well.
Perhaps animals are more adaptable, but perhaps not. I'd say that pregnancy without at least _some_ spin-based gravity would be a seriously bad idea - the risk of bad fetal development is compunded by the difficulty of medical care during pregnancy and birth. Certainly not safe to do it until tests on monkeys have worked, and we shouldn't do them until lower animals like guinea pigs have worked.
On the other hand, sex in space sounds just fine:-)
Lots of this stuff works by gravity, which should continue to operate fine even in the new millenium:-) But how much do typical municipal water systems depend on electricity, and how many of them have adequate backup power? I'm not too worried about the control systems (as you say, most of it has manual overrides, and I can boil water on a gas stove if I need to), and you can power computers with little diesel generators if you're prepared, but what about Big Motors? Does that stuff run on electricity, or mostly diesel?
Losing the water system is really much more annoying and hard to prepare for than losing power, in spite of how many systems need power. It's easy to store enough drinking and cooking water for a week or two, and you can skip showers if you want, and a gasoline-powered camping stove can last a long time. Keeping enough water for toilets is more annoying, and some of us apartment-dwellers don't have shovels around to dig latrines with.
While Inktomi http://www.in isn't made to run on zillions of coordinated home machines, but it's made to be scalable and run on a network of spider machines. They've since branched out to cache servers and other businesses, but the search engine was their initial project.
Slashdot Mirror
QNX was also a real-time OS; not many Unixes could do that. For lots of applications, just being fast is fine, but if you're trying to control hardware that wants its interrupts handled in N microseconds so you can tweak physical behavior, it takes lots of support from the interrupt handlers and schedulers. Masscomp was one of the early players in the field, and some of the later System V releases had optional real-time schedulers. There were POSIX real-time specs around 1990, but I got the impression nobody much cared about supporting them. It's nice to see that there's some real-time Linux work going on as well.
The big issue is what gets done with the number; for that you'll need to blame Microsoft, if for some reason you're running their operating systems instead of Linux or *BSD (yeah, I am on most of my machines
Laptops need this! The hundred or so people who work in my building use laptops, so we've got our office with us whether we're at our desks, out at customers, working from home, or on the road/train/airplane. That means I really *do* need my own copies of most of my software on my own machine, and I need to be able to back my stuff up on a file server so that when my laptop's disk gets crashed, I can restore all my stuff, and restore it efficiently rather than reinstall &^%*^% MSOffice and all my other software, and so I've got the version of everything that's on *my* laptop, not some server that may have newer or older stuff.
Would this be easier if MSOffice and other popular software packages had the decency to keep all their static content in one place (e.g. C:\readonly) and their changeable stuff somewhere else (ideally, somewhere else *standard*), so you only need to back up the changeable parts? Sure! But that ain't gonna happen, especially at Microsoft, but not with a lot of the other software vendors out there today. It's much easier to build an interesting and occasionally useful admin tool that to fix corporate culture.
A lot of the non-software on my computer is training material and presentations in MSPowerBloat format - many of my coworkers have copies of identical material, but we really need them for portability.
Would all of this be easier if we used vi + LaTeX or HTML editors for word processing and GIFs/JPGs or Really Good Postscript for pictures, so the standard software was 5% as large and the presentations were browseable? Yup. But this is Corporate America :-)
The most common X.25 environments I saw in the US used these for terminal emulation, so you could take your 3270 controller or your dumb-paper-terminal controller and log on to a mainframe or timesharing host, sort of a bondage-oriented version of async-dialing to a Unix host. Unlike frame relay networks, where each customer has their own permanent virtual circuits between their own locations, X.25 was designed for telcos and PTTs who could connect you to any of their customers, if you knew their network address (equivalent to knowing a phone number. To add some security, there were features like Closed User Group.) This basically meant that anybody within France, or anybody within Germany, could set up an X.25 connection to anybody else there, and could sometimes do international sessions as well. It doesn't matter that there's no Internet protocol if everybody you want to talk to is on the same Layer 2 network, so this was how computers at European universities talked to each other.
The canonical book on why all of this is a bad idea and TCP/IP is better is
M. A. Padlipsky's The Elements of Networking Style and Other Essays and Animadversions on the Art of Intercomputer Networking. Prentice--Hall, Inc., Englewood Cliffs, NJ, 1985. I don't totally agree with him - X.25 did error-checking at Layer 2 because it was designed to run over French barbed-wire, and while it might have been faster to restrict those functions to Layer 4, that mainly became true when fiber-optic long-haul networks made bit error rates many orders of magnitude lower than the original facilities X.25 ran on. But he's mostly right on.
BTW, calling ISDN a "layer 2 protocol" is pretty dodgy. The D channel does run X.25, with whatever features the telco feels like supporting, but the Bell Labs and Nortel telephone switch developers never really had the clue about what data users want (:-), and computers had gotten faster by the time ISDN was priced for consumers, so what everybody really uses are ISDN B Channels (which provide Raw Bits at 64 or 56kbps) with the end-user's choice of Link Layer framing protocols (I forget if that settled down on V.110 or V.120?).
I don't know if the US talked Japan into regulating supercomputer exports, but they did talk them into crypto export regs, primarily in response to the (NTT or NEC?) development of an RSA chip.
"Can't Export Without A Permit" doesn't mean you can't export it - it just means you need to get a permit. If the motivation here really is restricting gray-market sales of Japanese versions of the product to the US, Sony probably can manipulate the permit process to prevent it.
http://www.sjgames.com/
--- Bill, partially responsible for the One of Disks...
I strongly agree with Malign's article. I hope this doesn't end up as the pilot for the Lone Gunmen series - they'd do much better forking off of the Lone Gunmen at Defcon or some of the Lone Gunmen Help Mulder Sneak Into Places episodes.
And Scully was wearing too much gear -- Mulder did a better job of loking like beefcake in the gamer suits
https://www.fortify.net/sslcheck.html
which tells you what level of encryption you're running.
www.openssl.org has an Open Source implementation of SSL. I think their latest version is 0.95.
There have been machines that almost worked that way. One of the early hypercube machines (N-Cube? IIRC) had a master node, and 2**N small nodes with a CPU, RAM, and communication connectors. It took care of virtual memory by assigning each process as many nodes as it needed, rather than assigning blocks from a shared memory space.
Do you want the new user interface applications developed in open source on Linux, or only on MSWin3K and the occasional Macintosh? Yeah, I thought so... There's also the PDA-like devices that will come from the cell-phone makers, and it'd be nice to have good programming interfaces to them. Some things will be killer apps, others will be toys we get bored with quickly, but open development environments will make it easier for everybody to try things out.
Some user interfaces are just dumb replacements for keyboards on machines that have conventional-sized screens. There are a lot of problems for which this is adequate, including the typing-impaired but also applications where you want hands-free but don't need to be eyes-free, such as information kiosks ("mirror, mirror on the wall, where can I find beer in this airport?"), reference-finders for workers in messy environments ("zoom in on the picture of the carburetor"), etc.
Voice commands can also be mouse/menu substitutes, for people who like them. A long-known safety principal is to limit the commands to a relatively short set of very safe commands. You don't want to have "rm -fr *" there, but "mail" and "phonebook bob smith - yes - dial" are pretty safe. (Ok, there are still risks like that web site with the background sounds saying "phonebook 1-900-RIP-OFFF - dial", but you can decide how much risk management you want. And you want it to ignore almost anything after the keyword "Daddy".) One of my coworkers had a PC-based application; we'd be on a conference call, and he'd occasionally interrupt to tell his computer to fetch a file. He doesn't use it much any more - I'm not sure if the novelty wore off or if he decided to cut down his weirdness quotient on the phone.
If you're willing to do voice input and output, portability becomes more practical, and computers can be a lot smaller because they don't need screens and keyboards, and more flexible because you can stick them in a pocket or backpack and use a headset. Sure, people will look at you funny walking down the street talking to yourself, but here in San Francisco, half the people on the streets are either talking to their cellphones or their liquor bottles, and society has adjusted to it. A hands-free voice portable makes an interesting combination with a GPS system and datacomm; it can give you while you're driving, tell you about nearby restaurants and traffic jams, and maybe let you call nearby cars ("Hey, CA123456, use your &^%&^% turn signal!").
MP3 Players can also benefit from voice interfaces, since it mainly requires adding a bit of storage to the computer you're already carrying. ("Computer, play Dark Side Of The Moon three times, volume low, speakers, order large pizza from Foobaros.").
Yes, it's possible to do signatures without also adding encryption capability - the laws have been relatively explicit about that on paper, if not in practice. But the most common signature algorithm, RSA, also does encryption, so it's only usable by software that ignores the encryption regulations. And one prominent authentication system - John Gilmore's export request for DNSSEC name servers, which can protect the Internet from the forgery that's commonly used to attack systems - was refused export permission (retroactively, after the permission had initially been granted.)
Developing a good interface for authentication on chatware takes work - you don't want to hang five lines of "---BEGIN PGP SIGNED MESSAGE--" on every line of chat. Cooperative development is an important method for developing good interfaces - but it's one of the areas hardest hit by the encryption regulations, especially cooperation between Americans and Non-Americans (not only Non-Americans outside the US, but foreign college students here in the US as well.)
There are a few projects for secure chat that I'm aware of - GALE, at www.gale.org, is a relatively sophisticated system that's inspired by MIT's Zephyr system. It's an open architecture with several different clients developed by several different people. And of course, people are always developing new IRC clients, but patching security on to things can be tough.
140GB is a nice start, but it's not really that big :-)
My building has about 70 people on our LAN, typically using laptops with 2GB disks. A 140GB disk would let us get _one_ backup for everybody; you'd need another for incrementals. (Realistically, compression helps a lot, and half of that capacity is identical copies of Microsoft officeware. But lots of buildings have more than 70 people.)
A few years back a network architect at a Weapons Lab That Shall Remain Nameless tried to figure out how big a LAN would be enough, so they could install a secure LAN once and not have to replace it like the previous few. You can do this by making the user's I/O devices the bottleneck - not their computers, but their eyeballs. 2048x2048 pixels, 32 bits deep, times two eyes, times 30 frames/sec is about 1 Gbps. You might need more horsepower back on the supercomputer, but if it's all their eyeballs can handle, it's Enough.
So a 140GB disk gets you about half an hour of uncompressed video - it's Not Enough. (Of course, if you don't mind lossy video compression, it's plenty big enough...)
The last time I worked on this stuff was doing meteorological imagery a decade ago - good-resolution satellite pictures compressed about 3:1 using "compress" (the LZW-based predecessor to gzip), which was enough that I didn't need to do anything fancier. (Radar images got into trouble, because they compressed about 50:1, so my first cut at the software compressed the stuff faster than the input across the network
"It's also a convenient way out of our US anti-trust problems - rather than being subject to the Justice Department, we're now dealing with the State Department and the Pentagon, who are much more flexible. It's possible we'll still have to divest Quebec, but c'est la guerre."
The windowing system part of NeWS didn't survive - Postscript was evil and unsafe and insecure and undebuggable, but what you saw really was what you'd get - stuff looked good on the screen, and great on paper, and it was really the same fonts, not some different font for different printers and different size because it's paper, and the stuff aliased when it should and aligned when it should - Windows still feels like looking at a fax of your real screen image.
But what did survive was Gosling's experience of making processes work together across different pieces of hardware - giving you the flexibility to split work between client and server any way that makes sense, which involves sending code from the client to the server to get it run there. This let NeWS do most mouse handling on the server (that's the machine that draws stuff on the screen near your face, for you non-X folks who think the server is the big box in the back room.) And it lets your web browser run Java programs in cooperation with applications back on a web server somewhere, without needing to install plugins in your browser. Security is one of the obvious lessons from NeWS, which would run any Postscript you handed it, if it didn't crash in the process, and adopting the p-code sandbox approach makes that sort of model possible, if not necessarily blazingly fast. (And lots of tools for making things fast have been added later.)
There's a lot of spectrum out there - think 5-50 GHz short-distance line-of-sight. (There isn't enough technology development up there yet for really general applications, but it can happen if FCC stays out of the way, which it won't, or if it's too hard to avoid interference with other people in that range.) Some of the Ultra WideBand stuff may also be effective.
"NEW VERSION OF FOOBAR - 7.0.2! DOWNLOAD HERE"
and the web page doesn't say what FOOBAR IS - it only says that it's better than FOOBAR 6.3.7 because the frobulatror is now tweakable and the incompatibility with ZORGLOB 2.1 or FooBSD has been fixed, along with that annoying memory leak.
So we know that MANDRAKE has a new Graphical Installer. That's Nice (or Not Nice, as some respondents prefer), but there's no mention in the lead story about WHAT MANDRAKE IS. It's possible that it IS a graphical installer, but it's pretty tough to tell from the download page.
So, folks, remember that your new version announcements will not only be read by people who are intimately following your cool developments, but by people who've never heard of your project. A good sentence or two of background and maybe a home page pointer can work wonders.
As far as fdisk goes, MS probably still thinks they own fdisk - after all, it came with MSDOS, and the Linux version is merely a superior imitation.
PGP doesn't do a hierarchical certification; it does a web of trust instead, where everybody can certify anybody else's key. The browsers don't use it, but the obvious way to adapt it would be to let you include your own PGP key as a certifier and trust anybody who's key you've signed.
In reality, it's a bit more restrictive than that - the RSA algorithm uses the same routines for encryption and signature verification, and for decryption and signature, so export of source code for RSA-based certification systems, which should be legal, might not be (or at least might have trouble getting permits if you apply for them; John Gilmore's permit for DNSSEC was granted and then yanked). But export of binaries still should be fine, assuming they're only designed to do signatures and verifications well, and that's enough to run a business on.
Digital Signature Algorithm/Standard (DSA/DSS) signatures only provide signing/verification, not encryption, so a system using them should be exportable without a permit, even in source code. (In reality, the "subliminal channel" misfeature means you can use it for slow symmetric-key encryption by hiding bits in your choice of random numbers, but that's ugly and the Feds like to pretend it's not built-in - at least if you don't add subliminal-channel support to your crypto source code.)
Some states, like New York and New Jersey, have reciprocal sales tax agreements that encourage collection of sales tax for mail-order across state lines; others don't. My wife used to do programming for a mail-order shop which was deciding whether to get involved or not, and New York is Obnoxious to deal with - sales taxes vary by town, township, county, etc., not always on zipcode lines.
The new issue with online sales is sales of non-tangible goods. The classic examples are software (big money from the big vendors who are easy to locate and tax, mostly-small money from shareware which is usually harder to locate), sound recordings (emerging non-pirated MP3 business) and pictures mostly in the (ahem) adult entertainment business. What's the taxable location, if any, of a performance viewed across state lines? Local governments could have sales taxes on movie and concert tickets, but they usually don't, though they may be hidden in the ticket price; what if you're listening to the concert from somewhere else?
Gullibility runs high for most signs ....
Perhaps animals are more adaptable, but perhaps not. I'd say that pregnancy without at least _some_ spin-based gravity would be a seriously bad idea - the risk of bad fetal development is compunded by the difficulty of medical care during pregnancy and birth. Certainly not safe to do it until tests on monkeys have worked, and we shouldn't do them until lower animals like guinea pigs have worked.
On the other hand, sex in space sounds just fine :-)
* Or maybe it was "down from up"....
Losing the water system is really much more annoying and hard to prepare for than losing power, in spite of how many systems need power.
It's easy to store enough drinking and cooking water for a week or two, and you can skip showers if you want, and a gasoline-powered camping stove can last a long time. Keeping enough water for toilets is more annoying, and some of us apartment-dwellers don't have shovels around to dig latrines with.
And other posters have pointed out Harvest.