My first computer was an IBM 403, which was really a big hulking printer that was programmed by a plugboard full of wires on the side which controlled what fields from the punch-card reader went into what fields on the printout and a paper-tape with holes in it that controlled when the print hammer hit and when the printer shifted the paper up a line. The printing mechanism was 133 vertical bars with the entire character set on each - they'd slide up and down to line up a line of characters and the hammer would hit them so they'd print a line of text. Paper slides, bars shift hammer hits, and usually each punch card would correspond to three lines of printout (address labels, etc.) plus a three-line blank shift.
We weren't allowed to mess with the plugboard, only with the paper tape and the keypunches, so our programming mainly consisted of mapping fields between punchcard columns and the printout based on what the current plugboard did, programming keypunch drums to make it easier to get the right inputs into the card fields, and finding creative ways to use the card sorter to get the information we wanted while minimizing the number of times you ran the deck of data cards through the sorter. (That wasn't just because it's cool to be algorithmically efficient - it was primarily because if you put 1000 punch cards into the sorter, you'd usually get about 998-999 of them back intact and have to dig the pieces of the torn ones out of the mechanism and then retype them:-)
A punch card sorter is an interesting beast on its own. It's basically a stable bucket sort - you pick what card column to sort on, and it sorts the cards into bins based on the letter or number in that column of the card. So to sort a deck of cards alphabetically based on a given field, you'd sort them by the last column in the field, restack into one deck, sort by the n-1th column, restack,... until you've sorted by the first column in the field. So laying out fields on the card corresponding to the behaviour of the plugboard and figuring out how to structure the data you put in it was more complex than it sounded, because it interacted with the sorting you'd do on the card sorter (Do you want to sort the deck by zip code for mailing? Or alphabetically by name so you can check off people who attended or voted at a meeting? Or do you want to sort by town so people can do local meetings, or sort by skill set to tag people for committees or projects, etc.)
My next computer after that was in high school - a PDP-11 running RSTS-11 and BASIC that we accessed by timesharing on an ASR-33 teletype, complete with paper-tape. Then the first couple years of college were a step back into punchcard-land, though at least there was a mainframe behind it and not just a mechanical smart-printer. *It* finally had JCL, which was rabidly lame after using the PDP-11s:-)
It was a couple of years before I got back to terminals (whew! VM/CMS!) And the summer job with an IBM System/34 (48K of RAM and a disk drive and an operating system that was a dim ancestor of the AS/400). And then there was the Plato nationwide computer system, which had graphics terminals with a "notesfiles" system that later influenced Usenet and had really cool spacewar games. And then in grad school there was Unix and microcomputers running APL and all sorts of cool stuff. And then I used mainframes again, but seldom with punchcards, then Unix again for a couple of decades. Eventually I used this MS-DOS thing - it wasn't as primitive as JCL - looked more like VMS without the HELP system or any of the useful commands, which felt enough like RSTS-11 to wade around in.... And eventually there was Windows, which was sort of like a Macintosh implemented really badly on an unreliable operating system that didn't have enough resources and had applications that all worked differently and couldn't operate with each other, so there was none of the friendliness and knowing-what-to-do-ness of the Mac and none of the ease of use or power of Unix shell pipes and scripts. But at least it didn't feel like JCL. /*END
The only latency inherent in a radio service is the extra latency from copying a packet onto the radio at the speed of your radio channel (depending on the service speed and packet size, that might be large or small.) The real issues are how many hops the connection has to take, and how much queuing occurs at each hop, e.g. how much time do your packets spend waiting for somebody else's packets, which depends a lot on the total bandwidth available vs. the bandwidth per individual subscriber.
The Metricom Ricochet network had occasionally significant latency issues, because some radio poletops were directly connected to frame relay data feeds, while other poletops relayed data to each other until they reached a wired poletop, which incurred latency for queuing and copying and CPU processing at each poletop. So not only did you get affected by how many users were sharing a wired poletop directly or indirectly, but also by how far away you were from a wired poletop. Especially in their initial deployment in the Silicon Valley area, the real bandwidth was down near San Jose / Santa Clara, and the farther you went up Route 101, away from the core area, the more relay hops you had to suffer through. But it was still cool to be able to get email on your laptop from where you were, even if it wasn't always good enough for telnet.
Google's job is to do interesting indexes of things. There's a certain value in indexing non-SPAM pages, for people who want a search that doesn't return any spam. But for that purposes, downrating spam will do. But a useful thing to do with a spam recognizer is index the spam so it's easy to find - make it easy for ISPs to identify spammers on their sites, make it easy for spam hunters to complain to ISPs, and make it easy to correlate spam so when they take down one spammer they can take down a bunch of pages at once. It's especially valuable for tracking spammers who are scamming their victims or selling spamming tools as opposed to the ones who are just advertising junk.
I had a DSL line in my lab, and several machines on it, including out-of-the-box Redhat 6.2 and somewhat-modified Win95 or Win98 (running an out-of-date virus scanner, but not running a MS mail client). Nobody appears to have bothered the Windoze machine, probably because there's not much useful you can do with it. Meanwhile, I named the Linux box "Kenny" because every week it was killed brutally and senselessly:-) Some weeks it was just installing DDOS clients, but at one point they wiped the machine after I'd thrown them off a couple of times in a row.
Later I upgraded Kenny to a recent Redhat release, either 7.1 or maybe 7.2, running in a medium-security configuration. I didn't notice any problems after that - whatever the popular security holes were had been patched or they were in services I hadn't turned on. I had some other serious problems with those distributions - basically they're not made to be installed on small machines unless you do one big partition or a lot of hand-tuning, and you can't netinstall from a single CDROM drive any more, so you'd better have at least one machine with a lot of disk space. But the security was much improved.
By the way, a couple of the intrusion detection techniques I used were:
Keep a machine on the lan running tcpdump and look at it occasionally. That's how I noticed all the ping-responses to a university in Sweden during the first DDOS round.
Don't trust ls or ps to tell you about all of your files or processes. Crackers with rootkits will install friendly replacements - but somehow they didn't think to change/proc, so there were processes that/proc showed that weren't in ps, and there were files that "find" found that ls didn't list. I don't remember if they replaced "top", but the hidden processes were using some hidden files as well as CPU time.
If a given network or tcp/udp port keeps bothering you, it's easy to set a router to filter it out.
The usual Peer-to-Peer tools (ICQ/IM/etc, Napster/Gnutella/etc.) achieve much of their usefulness by using presence servers or index servers to keep track of who has what information, so you can find something you want, across a fairly wide part of the network, and then download it directly from somebody who has it, preferably nearby. That way the indexing system carries a relatively light load, while the heavy lifting is done peer-to-peer.
This walkabout version wouldn't have the same advantages:
You can only exchange files with people near you, so it's only useful if you like what they've got.
There's no persistent communication, so if you keep an index of what somebody else has, it doesn't do much good after they walk away, unless you bump into them later.
You can only exchange indexes with people near you, and indexes about other people's data aren't very useful, unless the people near you run into the same people you run into. This is most likely to happen if you know each other, in which case you could trade your files directly:-)
Since indexes aren't very useful without persistent communications, you could just pass all your files along, using a flood-routing sort of system; in that case the indexes just prevent copying duplicates.
At that point, the system becomes a slow-moving parody of Usenet. But Usenet is already a slow-moving parody of itself
Once upon a time there was a way-cool research lab called DECWRL, though they're now known as "Compaq Western Research Laboratory". They did a number of cool projects, including little things like AltaVista and the Linux-based Itsy PDA.
One toy they built was the Factoid, a Peer-to-Peer information exchanging keychain dongle. It's about the size of a stick of gum, runs for a long time on watch-batteries, uses a short-range radio link, and trades things it knows with other Factoids, typically with data objects up to about 200 bytes long - business cards and that sort of thing.
Codecon was recently announced on Slashdot. It's a conference on P2P and crypto code, taking place Feb 15-17 at the DNA Lounge in San Francisco. Unlike the more commercial/marketing flavor of conference, presenters need to have actual working code.* There's now a Schedule as well as a Program.
In addition to the code presentations, there are also several panels on legality, security, and business models by a number of usual suspects.
So be there or be square!
* ok, or at least well-rigged demos:-)
Importance of 64-bit architectures
on
Intel's Big Chip
·
· Score: 2
The computer world is increasingly reaching the point that we need 64-bit addressing - the price of memory has reached the point that computers with more than 4GB of RAM are not only feasible, but becoming common, and for a couple years we've had disk drives bigger than 4GB. This means that 32-bit addresses are no longer enough - and with the 36-bit and 48-bit segment-based things that allow machines to address more memory, we're rehashing all the ugly tricks we had to play with 20-bit and 24-bit addressing on 16-bit-addressed 8086/80286 machines. Ugly, ugly, ugly!
For most people, 64-bit arithmetic isn't critical - most applications don't deal with ints larger than a billion, though us crypto people who do lots of bignum math are happy to get a 4x speedup. Otherwise, the quality of floating point implementations is likely to be more important. So it would be possible to get by with 32-bit arithmetic and 64-bit addresses, like we did with the Motorola 68000's 16-bit-ints and 32-bit registers and addresses - but that was also somewhat tacky, and led to *lots* of bugs in code that assumed ints and pointers were the same size, though perhaps we've evolved enough past K&R C that newer software won't make that mistake as often.
A real problem this time around is that the C language and its relatives really do like 32-bit integers, and many of the Unix system calls also assume 32 bits. If you make the native int/pointer sizes 64 bits, there's a lot of stuff that will probably break. What kind of experience have people had running code on DEC Alphas and other real-64-bit chips?
I liked it, even though somebody apparently thought it was redundant. It doesn't directly apply to Google, but the principles of trading off speed and cost are still relevant even though the problem's a bit different. One thing I'd find interesting is knowing how much of Google's index data is replicated - one master copy (which might be backed up on disk) kept on N search engine boxes - vs. how much do queries get spread across multiple boxes? Does it make sense to cache the spidering on disk (probably, because rerunning spidering takes a long time, and because the article caches probably don't get hit as often, and don't need the same response speed as the indexing.)
For about $20-30, you can get disk drive drawers that turn a 3.5" drive into a 5" removable drive. Nothing active; it's just a bunch of mounting hardware. (About $20 for the part that stays in your machine and $10/disk for the removable drawer parts.)
This makes it easy to use disk drives as backup media, which is good, because they're much faster than tape. It also makes it easy to upgrade your disk capacity when you want to do that.
NAT / ipmasq / etc. are one approach to hiding large private address spaces behind small numbers of IP addresses, but they're not the only one. Another approach is proxy-type firewalls and DMZs. In a typical corporate network, to get to the web you use a proxy server (which also does some caching), and to send email you go through an SMTP server at the firewall, and to receive email you go to a corporate server which actually gets the mail from outside and either forwards it to your internal mail server or else provides the mailbox service itself. NAT can be useful if you want to run other protocols, and ftp can either be handled by NAT or by proxies.
He said that you wouldn't be able to tell the difference for a Megadeth concert. He's not talking about the New York Philharmonic here, or Pavarotti, or even a live Phish show. He's talking about stuff that was megadistorted *before* recording, where the real issue is how much volume you can get during playback and how much beer you've got around...
256MBytes / 128kbits/sec = 2*1000*8 = 16000 seconds. = 266 minutes = 4.4hours. So assuming you buy enough memory, at the best sound resolution the doggy thing can give you, that's 4.4 hours. According to the blurb, the battery life in recording mode is 4 hours, with presumably big honking batteries, though they'll support 8 hours of playback. Presumably you'd only use the lower recording speeds if you didn't buy the maximum memory, or if you've got an AC adapter to keep the thing charged during an all-day recording session.
Assuming the MMC format of memory adjusts in price to match the other flash formats (CF, Smart-Media, etc.), the price will lag a bit but gradually become affordable. The real questions are whether the box can use bigger memory cards when they become available/affordable, or whether 256MB is the most it'll ever accept, and whether the software is flash-upgradable so you can do 192kbps or 256kbps once you can afford the extra memory, or whether you'll decide that 18-bit A/D converters aren't good enough to bother encoding at higher speeds.
There are proprietary MS formats, like Word or Powerpoint, that add lots of junk at the beginning and also inflate the space taken by the text.
But HTML doesn't add much overhead - a few dozen characters of headers and trailers, plus however much decorative formatting you want to add. At minimum, most HTML text uses "p" tags for paragraphs (an extra three characters), and "b","/b" and "i","/i" tags around bold/italics (an extra 7 characters per word/sentence/whatever.) That's seldom more than about 10%.
If you insist on creating HTML by converting from a proprietary word processing format using a badly broken format converter, you can inflate things a bit more (using lots of "FONT=longbogusname SIZE=+2" junk and using font-change tags instead of paragraph-type tags), but it's still not usually that inflationary.
The article mentions the problem that it really needs a transparent reinforcing material to work well. So obviously transparent aluminum is what you want for rebar....
That *was* one of the cool features of DV/X - it meant that you could have one machine running DOS, and all of your Unix machines could run DOS applications in an X window (or at least N of them at a time could.) I don't remember if that was just DOS, or some of the primitive Windows modes, but either way it was potentially really useful for its time.
Unfortunately, the spare 486 walked out of my lab before I could implement it.
It's much easier to suggest simple toys than to make deeply thought-out contributions to educational technology use. So here's my favorite toy:-) Whiteboards that make copies of their contents used to be large expensive things that rolled flexible surfaces through scanners and printed copies. Now there's a low-cost computer-integrated alternative - Mimio. It's a ~$400-500 device that uses special pen holders and an ultrasonic position-detector bar that clamps on the side of your whiteboard, which tracks the position of the pens and transcribes it to a computer. You can do simple applications like copying the whiteboard, and they've got some extra software for OCR text recognition, streaming audio correlation, etc. It's useful for simple transcriptions, and also useful for multi-location meetings (admittedly, that's more of a business application than a school application.)
I think there's also some competitor in the $300 range.
Tuition and Fees - that's your money - if they subsidize $X of the price of the card, it's by charging you $X plus administrative overhead
Grants and Donations - occasionally they can get corporate grants for this sort of thing, but it's usually tough. It's easier to get a grant for the school's side of the wireless network, from a company that hopes the students will buy their own cards.
Taxes, if they're government-funded - aside from the morality of forcing other people to subsidize your wireless card, in practice the university's already getting as much money as it's going to be able to get, unless they can get a major realignment in priorities (prisons vs. universities vs. good elementary schools vs. highways).
As other people have said, if you've got the wire, using wire is cheaper, but running wires costs money. The big change with some of the newer wireless technologies is that they're starting to go fast enough and far enough to be useful. 10kbps connections are fast enough to run voice on, and paging, and sometimes email, but not something you'd run real computing over. Metricom's ~30-100kbps was better - but the tradeoffs of how many users fit in a given area, how far it goes, and how many microcells it needs didn't quite work for them. But 802.11b, at "11" Mbps, is really fast enough for many networking applications, and distance-limited enough that lots of people in a city can use it without overly stepping on each other's bandwidth needs - you can use it for typical office data applications and voice phones, though you'll still need a feed to the outside world that's usually wired. Inside an office building, run by the end users, it's a win; adapting it to be a public wide-area service is a different game economically, with different competition, and perhaps folks like BAWUG or Starbuck's Coffee will succeed. But those applications still require an upstream feed, and the cost of using a wired feed is enough that the economics are still dodgy for free service, and the market for paid service hasn't taken off quite fast enough. 802.11a, at 55Mpbs, is even more useful for office LANs; we'll see if it can provide upstream feeds for WANs.
What UWB technologies can offer is that they increase the number of users and amount of bandwidth that can operate in the same space without interfering with each other, and they also have sufficiently entertaining options for directional data and longer distances that it might be possible to build a meshed distribution network that's got enough horsepower to be self-sustaining without lots of wired access points. That not only makes it more viable for wireless users to access services on each others' machines, but also to get better economies of scale sharing upstream bandwidth - N users on a 45Mps T3 connection get much more effective capacity than N/28 users on a 1.544Mbps T1 connection, plus you save the costs of running lots of small connections to lots of individual cells (the access costs for a T3 are typically about 10 times the access costs for a T1, and you get 28 times the bandwidth, plus you also have more users who'll be sending data to each other instead of to the outside world.)
There's a longer article on Hendricks's work in This month's Wired, talking about UWB, unwiring Tonga, and using Indian Reservations to try out radio technology because their sovereign nation status may be a useful regulatory hack as well as because they need better communications on the rez.
Oh, there are definitely mushrooms that the US gov't would bust your grocer for ordering for you:-) But they're pretty much listed, though the entry for "and anything else that turns out to be too much fun" is a bit vague... My local grocery store recently had a "Buy 1, Get 1 Free, Maximum 2 Free" sale on Sudafed - but when I got the the cash register with my four packages, they said they couldn't sell me more than three of them, because four packages exceeds the "people could make Speed with this stuff" limit.
Yes, there has been some missing the point, on the issues of how much it's intended to filter expression by Australians vs. filtering Australian access to expression by other people. And it's certainly not the attemptedly-all-pervasive Great Firewall Of China.
But filtering speech by Australians, and deciding which speech is "appropriate", is still an outrage in a free society - it's basically saying "if you say things we don't like, we'll send you a Threatening Letter, and if you ignore that we'll send a bunch of armed policemen to beat you up and haul you away to jail", no matter how polite a face they try to put on it. Sturgeon's Law does usually apply to censored publications as well as uncensored ones - 90% of the stuff they shut down is crap, and almost nobody will miss it, but shutting it down is still wrong.
As far as "accountability" goes, refusing to publish the list of banned material is deliberate evasion of accountability. If they do an effective job of censorship, you *won't* become aware of political sites being shut down, but that won't be because they aren't shutting them down. I doubt they'll be that successful, but they'll still reduce access to material they dislike, and reduce the public's awareness of what they're censoring. The Internet has its own methods for providing accountability, which are that speech is cheap enough that if you disapprove of some web site, you can put up your own web site disagreeing with that other site, or insulting it, or disproving it, or just telling people that it's bad stuff they shouldn't read. The remedy for bad speech isn't policemen, it's more speech, and the Internet makes more speech cheap and easy.
Slashdot Mirror
We weren't allowed to mess with the plugboard, only with the paper tape and the keypunches, so our programming mainly consisted of mapping fields between punchcard columns and the printout based on what the current plugboard did, programming keypunch drums to make it easier to get the right inputs into the card fields, and finding creative ways to use the card sorter to get the information we wanted while minimizing the number of times you ran the deck of data cards through the sorter. (That wasn't just because it's cool to be algorithmically efficient - it was primarily because if you put 1000 punch cards into the sorter, you'd usually get about 998-999 of them back intact and have to dig the pieces of the torn ones out of the mechanism and then retype them :-)
A punch card sorter is an interesting beast on its own. It's basically a stable bucket sort - you pick what card column to sort on, and it sorts the cards into bins based on the letter or number in that column of the card. So to sort a deck of cards alphabetically based on a given field, you'd sort them by the last column in the field, restack into one deck, sort by the n-1th column, restack,
My next computer after that was in high school - a PDP-11 running RSTS-11 and BASIC that we accessed by timesharing on an ASR-33 teletype, complete with paper-tape. Then the first couple years of college were a step back into punchcard-land, though at least there was a mainframe behind it and not just a mechanical smart-printer. *It* finally had JCL, which was rabidly lame after using the PDP-11s :-)
It was a couple of years before I got back to terminals (whew! VM/CMS!) And the summer job with an IBM System/34 (48K of RAM and a disk drive and an operating system that was a dim ancestor of the AS/400). And then there was the Plato nationwide computer system, which had graphics terminals with a "notesfiles" system that later influenced Usenet and had really cool spacewar games. And then in grad school there was Unix and microcomputers running APL and all sorts of cool stuff. And then I used mainframes again, but seldom with punchcards, then Unix again for a couple of decades. Eventually I used this MS-DOS thing - it wasn't as primitive as JCL - looked more like VMS without the HELP system or any of the useful commands, which felt enough like RSTS-11 to wade around in.... And eventually there was Windows, which was sort of like a Macintosh implemented really badly on an unreliable operating system that didn't have enough resources and had applications that all worked differently and couldn't operate with each other, so there was none of the friendliness and knowing-what-to-do-ness of the Mac and none of the ease of use or power of Unix shell pipes and scripts. But at least it didn't feel like JCL.
/*END
The Metricom Ricochet network had occasionally significant latency issues, because some radio poletops were directly connected to frame relay data feeds, while other poletops relayed data to each other until they reached a wired poletop, which incurred latency for queuing and copying and CPU processing at each poletop. So not only did you get affected by how many users were sharing a wired poletop directly or indirectly, but also by how far away you were from a wired poletop. Especially in their initial deployment in the Silicon Valley area, the real bandwidth was down near San Jose / Santa Clara, and the farther you went up Route 101, away from the core area, the more relay hops you had to suffer through. But it was still cool to be able to get email on your laptop from where you were, even if it wasn't always good enough for telnet.
Google's job is to do interesting indexes of things. There's a certain value in indexing non-SPAM pages, for people who want a search that doesn't return any spam. But for that purposes, downrating spam will do. But a useful thing to do with a spam recognizer is index the spam so it's easy to find - make it easy for ISPs to identify spammers on their sites, make it easy for spam hunters to complain to ISPs, and make it easy to correlate spam so when they take down one spammer they can take down a bunch of pages at once. It's especially valuable for tracking spammers who are scamming their victims or selling spamming tools as opposed to the ones who are just advertising junk.
Later I upgraded Kenny to a recent Redhat release, either 7.1 or maybe 7.2, running in a medium-security configuration. I didn't notice any problems after that - whatever the popular security holes were had been patched or they were in services I hadn't turned on. I had some other serious problems with those distributions - basically they're not made to be installed on small machines unless you do one big partition or a lot of hand-tuning, and you can't netinstall from a single CDROM drive any more, so you'd better have at least one machine with a lot of disk space. But the security was much improved.
By the way, a couple of the intrusion detection techniques I used were:
This walkabout version wouldn't have the same advantages:
One toy they built was the Factoid, a Peer-to-Peer information exchanging keychain dongle. It's about the size of a stick of gum, runs for a long time on watch-batteries, uses a short-range radio link, and trades things it knows with other Factoids, typically with data objects up to about 200 bytes long - business cards and that sort of thing.
The Research Paper ;
recently announced on Slashdot. It's a conference on P2P and crypto code, taking place Feb 15-17 at the DNA Lounge in San Francisco. Unlike the more commercial/marketing flavor of conference, presenters need to have actual working code.* There's now a Schedule as well as a Program.
In addition to the code presentations, there are also several panels on legality, security, and business models by a number of usual suspects.
So be there or be square!
* ok, or at least well-rigged demos :-)
For most people, 64-bit arithmetic isn't critical - most applications don't deal with ints larger than a billion, though us crypto people who do lots of bignum math are happy to get a 4x speedup. Otherwise, the quality of floating point implementations is likely to be more important. So it would be possible to get by with 32-bit arithmetic and 64-bit addresses, like we did with the Motorola 68000's 16-bit-ints and 32-bit registers and addresses - but that was also somewhat tacky, and led to *lots* of bugs in code that assumed ints and pointers were the same size, though perhaps we've evolved enough past K&R C that newer software won't make that mistake as often.
A real problem this time around is that the C language and its relatives really do like 32-bit integers, and many of the Unix system calls also assume 32 bits. If you make the native int/pointer sizes 64 bits, there's a lot of stuff that will probably break. What kind of experience have people had running code on DEC Alphas and other real-64-bit chips?
Actually, there is a company Isher Artifacts which makes some really *fine* looking energy weapons.
...after the franchise wars of the last decade, all restaurants have been Taco Bell....
I liked it, even though somebody apparently thought it was redundant. It doesn't directly apply to Google, but the principles of trading off speed and cost are still relevant even though the problem's a bit different. One thing I'd find interesting is knowing how much of Google's index data is replicated - one master copy (which might be backed up on disk) kept on N search engine boxes - vs. how much do queries get spread across multiple boxes? Does it make sense to cache the spidering on disk (probably, because rerunning spidering takes a long time, and because the article caches probably don't get hit as often, and don't need the same response speed as the indexing.)
For about $20-30, you can get disk drive drawers that turn a 3.5" drive into a 5" removable drive. Nothing active; it's just a bunch of mounting hardware. (About $20 for the part that stays in your machine and $10/disk for the removable drawer parts.)
This makes it easy to use disk drives as backup media, which is good, because they're much faster than tape. It also makes it easy to upgrade your disk capacity when you want to do that.
NAT / ipmasq / etc. are one approach to hiding large private address spaces behind small numbers of IP addresses, but they're not the only one. Another approach is proxy-type firewalls and DMZs. In a typical corporate network, to get to the web you use a proxy server (which also does some caching), and to send email you go through an SMTP server at the firewall, and to receive email you go to a corporate server which actually gets the mail from outside and either forwards it to your internal mail server or else provides the mailbox service itself. NAT can be useful if you want to run other protocols, and ftp can either be handled by NAT or by proxies.
obviously the Nerf projectiles can substitute for avian carriers. You can also use the Legos as a reconfigurable version of clay tablets...
He said that you wouldn't be able to tell the difference for a Megadeth concert. He's not talking about the New York Philharmonic here, or Pavarotti, or even a live Phish show. He's talking about stuff that was megadistorted *before* recording, where the real issue is how much volume you can get during playback and how much beer you've got around...
Assuming the MMC format of memory adjusts in price to match the other flash formats (CF, Smart-Media, etc.), the price will lag a bit but gradually become affordable. The real questions are whether the box can use bigger memory cards when they become available/affordable, or whether 256MB is the most it'll ever accept, and whether the software is flash-upgradable so you can do 192kbps or 256kbps once you can afford the extra memory, or whether you'll decide that 18-bit A/D converters aren't good enough to bother encoding at higher speeds.
But HTML doesn't add much overhead - a few dozen characters of headers and trailers, plus however much decorative formatting you want to add. At minimum, most HTML text uses "p" tags for paragraphs (an extra three characters), and "b","/b" and "i","/i" tags around bold/italics (an extra 7 characters per word/sentence/whatever.) That's seldom more than about 10%.
If you insist on creating HTML by converting from a proprietary word processing format using a badly broken format converter, you can inflate things a bit more (using lots of "FONT=longbogusname SIZE=+2" junk and using font-change tags instead of paragraph-type tags), but it's still not usually that inflationary.
The article mentions the problem that it really needs a transparent reinforcing material to work well. So obviously transparent aluminum is what you want for rebar....
Unfortunately, the spare 486 walked out of my lab before I could implement it.
I think there's also some competitor in the $300 range.
What UWB technologies can offer is that they increase the number of users and amount of bandwidth that can operate in the same space without interfering with each other, and they also have sufficiently entertaining options for directional data and longer distances that it might be possible to build a meshed distribution network that's got enough horsepower to be self-sustaining without lots of wired access points. That not only makes it more viable for wireless users to access services on each others' machines, but also to get better economies of scale sharing upstream bandwidth - N users on a 45Mps T3 connection get much more effective capacity than N/28 users on a 1.544Mbps T1 connection, plus you save the costs of running lots of small connections to lots of individual cells (the access costs for a T3 are typically about 10 times the access costs for a T1, and you get 28 times the bandwidth, plus you also have more users who'll be sending data to each other instead of to the outside world.)
There's a longer article on Hendricks's work in This month's Wired, talking about UWB, unwiring Tonga, and using Indian Reservations to try out radio technology because their sovereign nation status may be a useful regulatory hack as well as because they need better communications on the rez.
Oh, there are definitely mushrooms that the US gov't would bust your grocer for ordering for you :-) But they're pretty much listed, though the entry for "and anything else that turns out to be too much fun" is a bit vague... My local grocery store recently had a "Buy 1, Get 1 Free, Maximum 2 Free" sale on Sudafed - but when I got the the cash register with my four packages, they said they couldn't sell me more than three of them, because four packages exceeds the "people could make Speed with this stuff" limit.
But filtering speech by Australians, and deciding which speech is "appropriate", is still an outrage in a free society - it's basically saying "if you say things we don't like, we'll send you a Threatening Letter, and if you ignore that we'll send a bunch of armed policemen to beat you up and haul you away to jail", no matter how polite a face they try to put on it. Sturgeon's Law does usually apply to censored publications as well as uncensored ones - 90% of the stuff they shut down is crap, and almost nobody will miss it, but shutting it down is still wrong.
As far as "accountability" goes, refusing to publish the list of banned material is deliberate evasion of accountability.
If they do an effective job of censorship, you *won't* become aware of political sites being shut down, but that won't be because they aren't shutting them down. I doubt they'll be that successful, but they'll still reduce access to material they dislike, and reduce the public's awareness of what they're censoring. The Internet has its own methods for providing accountability, which are that speech is cheap enough that if you disapprove of some web site, you can put up your own web site disagreeing with that other site, or insulting it, or disproving it, or just telling people that it's bad stuff they shouldn't read. The remedy for bad speech isn't policemen, it's more speech, and the Internet makes more speech cheap and easy.