As with the recent pumpkin-based computer case, it's nice to have articles about Sparcbooks because they're cool. However, it's even nicer to have Sparcbook articles, because the things are in fact useful if you're a developer or user in the Sun Sparc world, which many people still are (alas, not me any more:-) (It's also surprising to hear that these guys are not dead yet - I haven't seen one of their machines in a long time.)
If *you* want to carry a pizza-box Sun on Caltrain and use one of the few cars that still have electric outlets, go ahead...
Getting hustled by the table...
on
Smart Pool Table
·
· Score: 2, Funny
Great, just what we need. The pool table automated assistant James suggests you try the shot and draws little laser pictures about how easy it will be for you to make it. It's worked the last 10 times, but this time you've gotten overconfident on your betting abilities, and the table has just hustled your wallet.
In poker, they say the first thing you should do is look around the table and find the sucker, and if you can't find them, then it's you. Now you've got the *table* playing against you....
They never wanted public participation; it was always pretty much for show, and the way they treated Karl was partly because they never wanted public participation and partly because he'd not only been elected by the public to push them into letting *actual*Internet*users* have some influence over ICANN's directions, which (as I believe I may have mentioned) they didn't want, but went beyond that to actually *try* to have some influence over ICANN, or at least force some shadow of openness or accountability onto ICANN, which they also didn't want. So when they got rid of him, they made it clear they didn't want him to be replaced; this is just formalizing it.
PayPal is not a bank - it's a payment system. Some people comment that it looks like a bank, quacks like a bank, and has a bank attached to the back end somewhere, but they're missing the point - the important issues in banking regulation systems are to make sure that the bank doesn't rip you off, and handles your money in a stable non-risky fashion, unlike a stockbroker account, where the investments are inherently recognized to be risky, but where there are still regulations to discourage the stockbroker from ripping you off.
A payment system is different from a bank or an investment broker - its main job is to move money around, not store it except temporarily, so unlike a bank, if your money earns interest that's pure gravy, and unlike a stockbroker, if your money loses value other than the documented fees, that's highly unexpected, but in all three cases, they've got basic fiduciary responsibility to not rip you off, and to not give your money to other people without permission. It's *your* money, not theirs.
Regulation may discourage this, and money-handling services benefit very strongly from trusted independent regulators and auditors, because that makes customers more willing to deal with them (and if they didn't have regulators bullying them around for free or insuring them for a subsidized price, they'd go out and buy equivalent services themselves), but fundamentally anybody who doesn't run their business competently will find Darwin kicking them out of the gene pool whether there are regulators helping them or not.
FreeS/WAN has been a major player in the IPSEC interoperability field since their first quasi-releases, back when almost nobody talked to much of anybody else. Because they weren't a commercial product, and because they were trying hard to get as much compatibility as possible, they served as a useful neutral reference point for other vendors and developers to talk to.
The two big interoperability problems for FreeS/WAN have been explicit non-support for Aggressive Mode (they don't support it, mainly because there are security problems that affect the general user that don't affect most commercial applications), and lack of support for various proprietary authentication systems (not that I've been thrilled with their Opportunistic Encryption work, since the versions I've seen assume levels of control over reverse DNS space that most people don't have.)
Their concerns for user-friendliness have been legendary ("First recompile your Linux kernel cleanly, then you can start to install the IPSEC stuff....":-) It's not the same goals as other parts of the IPSEC vendor community ("First find the end of the brown wire with the two little prong-thingies and plug it into the electric socket in the wall. See Figure 37 if this is difficult for you.") Not surprising, because while they really do want everybody in the world to be able to communicate securely, they also had a lot of research to do on how to make things work well, and the world around them that they've had to support has been changing rapidly while they were working - it's been a lot like changing the tires on a moving truck, while your users are rebuilding the truck and other people are rebuilding the road or inventing chemistry for vulcanizing rubber. If it's not always obvious why their work has been so critically important and valuable, well, it has been anyway.
There are lots of ways to work around the US export regulations (and the export regulations of other countries that the US bullied into supporting us by protecting the world from Communist access to cryptography.):
Sue the Feds to make them change (Gilmore, Bernstein, EFF, others have done this.)
Lobby the government (mainly Congress) to get the laws changed.
Ridicule the government loudly about their policies - T-Shirts, RSA Tattoos, etc. had a big impact.
Ignore the regulations and export your products quietly.
Ignore the regulations and export your products AS LOUDLY AS POSSIBLE. (Variation: do this anonymously.)
Put your software on the net with a README warning that only Americans are allowed to download it. Lots of people did this. Some people added scary-copyright-lawyer words. Nobody actually usd the copyright lawyers to sue foreigners who downloaded it, though.
Put your software on the net with some trivial verification that requires anyone who downloads it to make some pretense of being in the US. (MIT did this.)
Find loopholes such as printing your source code on dead trees and exporting it to libraries and to people who OCR it and put it on the web, like PGP did with several versions.
Export products that obey the limits, but are easily fixed. Netscape's 40-bit versions could be restored to 128-bit capability using the UK-distributed "fortify.net" patching program. Some of the versions could be fixed with a 1-line Javascruft patch that you could include in a signature line.
Convince the NSA to try to foist some blazingly offensive and stupid product on the US, like Clipper, and get 50000 people to sign petitions beating them up about how blazingly offensive and stupid their proposals were. (No, I don't think Dorothy Denning had pro-crypto-export ulterior motives....)
Develop your software outside the US, with Open Source or public-domain licensing, and put it on the net so anybody in the world can download it. John Gilmore's FreeS/WAN project has always worked this way, but for a number of years before that, there was free DES software available from an ftp software at a university in Finland.
Develop commercial software outside the US and sell it everywhere in the world. Loudly taunt the Happy Fun Ball\\\\Feds about how their crypto export ban is helping create jobs in Australia, Finland, Netherlands, Switzerland, and Russia. Lots of people did this.
There are several different limits you'll encounter, which will have different effects on the programs you write as well as on the machines you can afford to use...:
Physical RAM limits - at ~$100/GB, commercial applications can easily afford a TB of RAM, but it's not that simple putting it into one computer - with 4GB RAM boards, that's 256 boards, which won't fit on your average PC ATX motherboard.... Solid-state disks can do the job, with obvious differences in performance from RAM or cache, but they usually lead the CPU-memory market by a couple of years. By the time you can get a normal machine with 1TB of RAM, that Power4/970 will be an antique, and you'll be complaining about the lame 48 bits in your wristwatch's address space.
Virtual Address space you can mmap() or put in a single array - this makes a lot more difference, because it affects whether your programs can view the large space as a segmented or unsegmented thing, and whether you need visibility into the memory structure, and whether you can get the visibility if you want it. For most scientific applications, it's not a big deal, because you seldom need it all in a big 1-D array; more commonly, anything that needs a huge address space is working in 2-D or 3-D, so you run an ugly setup thing to get your array pointers initialized and then return to normal programming.
Virtual memory for files and databases, though, is more of a problem. It's convenient to be able to treat the disk as one big flat virtual array, even if you do a certain amount of explicit management on the relationship of disk and RAM rather than leaving it all up to the VM system. A terabyte of disk is under $2K these days, though if you want faster disks and faster busses you might pay a bit more, but the costs of disk have been diving faster than CPUs for a few years, and anything below about 47 bits of address space for disk starts to heavily eat into the programming effort for products that are meant to work for a few years.
Almost two decades ago, I was supporting a network modelling application that needed 12MB, and our computer was a VAX with 4MB of RAM, but fortunately 4.1BSD and System 5.2p were able to give it enough virtual memory to scrape along. Our typical runs took about a week, until a couple years later when the price of RAM dropped to the point that we could afford to upgrade to 16MB, at which time it dropped to an hour per run.
One thing we found out was that as you approach the limits of a machine's capacity, all the details of the architecture that you were able to ignore on smaller problems become visible, like how the TLBs work and what the memory page sizes are; things became somewhat clunky at 6MB and much more clunky at 22MB (or maybe 24MB), and some of that may have been the OS rather than the hardware. The extra 12MB RAM cost us approximately one person-year's salary, but unfortunately corporate accounting rules made it much harder to buy capital equipment than to make our study take a year longer.
At this point, I'm supposed to include the obligatory old-geezer rant about walking to the mainframe, five miles in the snow, uphill both ways, carrying punch-cards and hand-winding magtape, but that was back when I was an undergrad, and we didn't actually go to the mainframe, just the card-reader/printer/keypunch room which was half a mile away (still snow and hills), and the reason I handwound the magtape was because the professor's only copy had a cracked reel, though we did use hand-cranked papertape tools to do it, and I really _did_ wind papertapes by hand:-)
I haven't dealt with these problems lately - Moore's Law has long passed the limits of any problems I solve in practice, laptop diskdrive sizes have gotten two jumps ahead of Microsoft bloatware (though fitting backups onto CD-Rs feels a lot like fitting them onto floppies used to), and the only practical application I've got that could think about pushing the terabyte disk boundary is Tivo, if I'm willing to devote that much resources to something that makes me watch more television... The reason it took so long to get the 120GB drive on my 233MHz Pentium wasn't cost, it was BIOS upgrades:-), and if I decide to rip all my CDs onto the disk, it'll mainly be just because I can.
The IETF's SIP / SIMPLE protocol work may be more important, depending on which press release you read about whether AOL is cooperating with them this month. Instant messaging systems and voice-over-IP systems both need to solve the problem of finding users who are connected (typically using a presence server of some kind) and also communicating between the endpoints (typically directly, but potentially through a relay.) The SIMPLE project proposes some extentions to SIP, which means that integration between instant messaging systems and VOIP become easier (because you can reuse code and also reuse management systems.)
My mother's new Mac is a Performa 630, genuine Motorola, none of this new-fangled PowerPC stuff. It would work just fine, except the video board's fading, (and her eyesight is at the point that a 15 inch monitor doesn't cut it, but she doesn't want to take the desk space for a 21 incher, and doesn't want to spend a couple thousand bucks to get one of those gorgeous giant flat screens with a new enough computer to power it.) She's also still got her old Mac, I forget if it's 512KB or 1MB, because there are some applications that never did port from 6.x to 7.x. I bought a used machine at Weird Stuff for $50 so I could have something to do remote tech support with. Meanwhile, since the original 68000 Mac isn't much different from a Palm Pilot with a keyboard, I'm waiting for somebody to port MacOS to the Palm or PalmOS to the Mac.
Meanwhile, a couple of years ago I gave my brother my then-8-year-old 386 machine. It worked just fine for Telnet and Netscape 2.x, and he wanted a machine that he wouldn't mind if somebody stole, as long as they didn't get injured carrying the 60-pound thing out the door.
A USB device can perfectly well be a router - the issue is whether the IP addresses on the two sides of the device are the same (in which case it's bridging) or different (in which case it's routing). The addresses may be on physical interfaces, or they may be on virtual interfaces of some sort.
If you're running PPPoA, your box is probably doing som e variation on bridging - taking your Layer 2 packets and shoving them over the PVC, which is a perfectly silly thing to do with an ATM connection. The alternative would be to terminate the Layer 2 connection and route the packets over the ATM PVC, saving a layer of protocol wrapper overhead and making the whole thing a lot simpler.
[Lots of disclaimers about this being my own opinions, not AT&T's...] AT&T's business DSL service does routing. Some of the services are static address, some are dynamic address, and it's possible we've introduced something else recently that does bridging, but for a while it's been routing. (Cable modem is an entirely different game, and depending on your local distributor, it's often an ugly and stupid game as well....)
We're running Win2000 Pro, and it seems to figure out that whenever you unplug / replug the cable it should renew or replace its dhcp lease. MS may still be clueless about how networking should work, but the stuff really is getting friendlier.
With Win98 and its relatives like Win98 SE, if your TCP/IP is set for DHCP (as opposed to having a static address), and you've got a DHCP lease that hasn't expired, you need to use the WinIPcfg tool to release the DHCP lease and renew it. If your PC is a laptop that you carry between two offices and your home LAN, you end up doing this a lot.... If one of your operating modes is to set the PC for static addressing (as opposed to using DHCP where your DSL router's dhcpd always gives you the same address), then of course you've got to go through the Control Panel, change the settings, reboot, yadda yadda.
There's no good reason for DSL to use PPPoE - the underlying technology is usually ATM, which uses Permanent Virtual Circuits (ISO protocol layer 2 connections that let you multiplex multiple connections on a point-to-point wire), and they can use ATM switches to deliver either ATM or Frame Relay connections to the ISP. Works just fine, and you can do either static or dynamic routing with no problem, though it tends to use a bit more IP address space than bridging solutions.
The two things that PPPoE seems to accomplish are to give the telcos (or other CLECs) and ISPs a bit more flexibility about where to put routers - it makes it easier to terminate the PVC on a shared router at the telco POP instead of requiring either an ATM connection to the ISP or an ISP-owned router at the POP. The authentication features also makes it a bit easier to turn off service to people if they haven't paid their bills, for the case where the telco/CLEC is providing a shared router at the POP. (If the ISP has a PVC all the way back to their router, they can do the same thing by disabling the PVC in their router.)
Just a comment on the technology levels of the author (or at least of his audience) - If Auerbach has something he considers to be a "work station", it's probably a Sun, not the desk that the Sun is sitting on.
On the other hand, I mostly stopped bitching about bureaucrats using this terminology when I built a lab a couple of years ago - we had $900 desks, with $400 PCs on them, so if the Furniture Mafia are getting more of the money, they can decide which stuff gets the title. (Of course, the reason we had $900 desks and $1500 racks that arrived six months and eight procurement review meetings after we started the project instead of $100 desks and $200 Metro shelves that the furniture store on the next block said they could deliver on Tuesday was because the Building Furniture Mafia told us that furniture procurement was An Offer We Couldn't Refuse, and that we would only be allowed to install racks that were Officially Earthquake-Bolted to the floor, and the only way to get Official Earthquake-Bolting was to order furniture from people the Building Furniture Mafia had deals with...)
ICANN is *NOT* a massive bloated moribund bureaucracy - unfortunately, it's quite the opposite. It's a lean mean collaboration of special interests -- accountable to no one -- who are able to do things they want because nobody's making them behave. There are some proposals out there to turn management of the DNS over to the ITU, who *are* a bloated moribund bureaucracy, accountable to so many people that it's even harder for them to get work done, and while I'd rather not see them in charge, at least they'd be moving slowly enough that they wouldn't be in the way of engineers doing engineering things because they'd be largely ignored.
As far as the DNS DDOS attack goes, the relationship between ICANN and the root servers is pretty fluid - it doesn't own or control them, though the Feds fund some of them, and it's more concerned with the master databases of who owns what names than the implementation issues of what IP address currently is attached to the names. Remember, ICANN are not engineers - they're intellectual property policy wonks. ICANN does encourage the root servers and the registries and registrars to follow security / reliability standards, and the recent DDOS attack means that there'll be some changes in the way things are run. There's an RFC 2870 on Root Name Server Operational Requirements, so if you've got opinions on how they can do a better job, go Comment.
ICANN's work on the top-level domains deserves mixed reviews. Moving slowly is usually ok; the big reasons for expanding the space are "because it gives us more cool names to sell", and one of the big reasons for going slowly is that you can only sell each TLD once, so you'd better get it right. Unfortunately, their definitions of getting it right strongly involve letting them stay in control, and are biased against any experimentation except along very narrow lines that they can stay in control of. But the IETF Ad-Hoc committee couldn't crack the political layer either. One thing both groups did right is pick a bunch of boring TLD names for the first batch, because they're going to make mistakes and discover unexpected problems in the first batch or two, and it's much better to mess up the market for.MUSEUM or.FIRM which nobody cares too much about than to mess up commercially valuable names like.INC or.LTD or.SEX or anything that overlaps with the voice telephone business.
IPv6 is Not ICANN's Job. It's the industry's, and the carriers', and Cisco's. ICANN does have the responsibility for coordinating the root servers' transition to support for IPv6 name lookups, and for making sure the Reverse DNS Lookup space (today's 1.0.0.127.in-addr.arpa PTR queries) gets managed correctly, though the standards work is probably the IETF's job, or maybe ISOC's. The one thing they've done in the IPv6 space that was Blatantly Evil (but probably reversable) was to claim that all your address bits are belong to them and set an unacceptably high price for the smallest routable address block. This not only delays widespread implementation until a major carrier either decides to pay them or ignore them, it nails down some assumptions about the shape of the hierarchy and organizational relationships that may be hard to repair, and increases the brittleness of the net without obviously benefitting the routing table situation (which is probably a more important IPv6 issue than the supply of address bits.) This delay gives them more time to try to finish grabbing power before IPv6's virtually-unlimited address space escapes from their ability to steal it from the world and sell it, but it also gives the industry more time to figure out what we're going to do with IPv6 and how to manage it, which is not a Bad Thing - there's a lot we really need to learn about how to use it before it's ready to replace IPv4.
The US government isn't in charge of the world Internet. Neither is the UN. The IETF would have been a much more appropriate group to manage the relatively small set of legitimate tasks that ICANN manages - they manage several other sets of address spaces without controversy, and they're more representative of the people who actually run and use the internet.
There have been some recent proposals saying that the ITU should be in charge - as somebody who's been in the telecom business for 25 years, I view them as better than ICANN, because some of them are engineers and because they're a slow bureaucratic multilateral committee rather than a cabal, but they're still the kind o f bureaucratic telecom who brought you E.164 names, X.25 as their best example of data networking, and OSI protocols and high European telecom settlement costs, and the best thing about them has been that you could usually ignore them and use whatever interesting tools came out of the vendor and developer community...
They tried very hard to eliminate the publicly elected seats before the election, and it was pretty clear when Karl managed to get elected anyway that they didn't want him there and were going to try to prevent any "representative of the public" from interfering. While Karl is definitely on the cantankerous side, that had a lot to do with why *he* got elected - it was obvious before the election that ICANN was trying to railroad the public, and the public responded by electing a representative who was not only articulate and aggressive but also very clearly committed to trying to get ICANN to behave properly, work openly, and make policies that were responsive to the public. He started off his term as pretty much the lone member of The Opposition, with his major support base being the people that the rest of ICANN wanted to ignore - it's a tough spot for someone who's really good at politics.
Actually, the plans for DNS are rather like the Force - they pervade the net, in every resolv.conf file and fill-in-your-DNS-server menu item, and while they don't exactly have a light side and a dark side, they do hold the Internet together. DNS, however, was really designed for a hierarchical environment with the Emperor at the top, because there's One Root To Rule Them All (oops, wrong genre... There Can Be Only One!... closer....).
Some of us were skeptical about the concept at the beginning, but the immense practicality of a common naming system compared to...ucbvax!ihnp4!here!there!them!username rapidly dominated the non-Microsoft-non-Novell parts of the email world in spite of the limitations that became glaringly obvious after the Web commercialized. The big problem with having a Root is that somebody has to be in charge of it, so there has to be some conflict resolution process, and the fact that Jon Postel was funded by the Feds as opposed to the IETF or ANSI has unfortunately led to the Feds thinking that it belongs to them, not to everybody.
So you've got your nanotech computing surface paint, why not put it to work? The processors are presumably a lot slower than modern CPUs, but so what, they don't have much better to do other than decide what color to be (What color is a chameleon in a mirror?) So give it some solar power source and let it compute things in its spare time.
The other problem is what kind of computation a system like that would do "Why am I here?" "How do I get somewhere else that nobody will shoot at me?" "I smell paint remover! Run away! Run away!"
Getting the heat out won't be a problem if you can't get the electricity in to power them. If you're using your own real estate, it's one thing, but if you're actually using 60KW of electricity in one rack, that's about how much power a typical colo center provides for 10-40 racks of servers, depending on how you're counting redundant power feeds. If you're trying to fit that many processors in one rack, and using heavy-power Xeons instead of low-power Transmetas, you need to start looking at room airflow and not just in-box airflow. The obvious solution is to imitate a Cray-2, and use Fluorinert or some other liquid fluorocarbon coolant piped in from a big honking Air Conditioner outside your building, possibly combined with some kind of gas turbine to turn some of that waste heat back into electricity.
If you're using your own real estate, it's pretty easy to power the things, but if you're buying commercial hosting space, blade servers and 1U rack servers quickly start running into problems with electricity. The problem is that Intel/AMD CPUs are fairly power-intensive, and increasing the density by a factor of 5-20 over traditional PC designs also increases the amount of power that a rack of servers needs to levels beyond what the typical hosting center is designed for. If you're getting a rack with 2 20-amp circuits, you've got 4KW to play with - doesn't go very far if you've got to feed 200 or 336 Xeon chips, and for that matter, isn't really ideal for 42 1U rack-mounted boxes, if you want to have redundant power supplies and you're burning 75W per CPU plus some more power for the disk drives. And of course, all those watts of heat require cooling. If you're planning to do it, have a serious talk with your real estate suppliers.
It'd be nice to ditch the ATX, but there are a number of mini-ITX and PC104ish form factors out there. The big problem with blade servers for desktop use is that they don't have video or audio - if you don't mind quiet, you could use one with an X terminal, but for a typical office, you could do just as well with a big blade server in the back room somewhere. Also, blade servers usually run wimpy little disk drives - for a server machine, I'd rather have a row of removable 3.5s in a RAID configuration.
The other problem with adapting current blade technology to the desktop is price - most of them are too expensive per blade compared to an equivalent-speed ATX.
Kids these days don't know cultural references. The article refers to Curious Yellow and Curious Blue, and also to cryptography. The late Martin Minow, one of the Cypherpunks cryptography community, lived in Sweden for a number of years working for DEC, later moving back to North America. During that time, he did a number of things, including the English translations of the movies "I Am Curious (Yellow)" and its followon, "I Am Curious (Blue)".
You can still see remains of them around 4th & Harrison (SouthEast corner), and around 4th & Folsom. They cleaned up a lot of them, but some of it just didn't come off.
Side Effects of ClimatePrediction.net
on
ECCp-109 Solved
·
· Score: 2
So Oxford University is planning to study changes in climate - by feeding large quantities of electricity (mostly generated by burning fossil fuels) to large numbers of heat-generating CPU chips, contributing to global warming. Sounds like a Heisenbug to me....
Slashdot Mirror
If *you* want to carry a pizza-box Sun on Caltrain and use one of the few cars that still have electric outlets, go ahead...
In poker, they say the first thing you should do is look around the table and find the sucker, and if you can't find them, then it's you. Now you've got the *table* playing against you....
They never wanted public participation; it was always pretty much for show, and the way they treated Karl was partly because they never wanted public participation and partly because he'd not only been elected by the public to push them into letting *actual*Internet*users* have some influence over ICANN's directions, which (as I believe I may have mentioned) they didn't want, but went beyond that to actually *try* to have some influence over ICANN, or at least force some shadow of openness or accountability onto ICANN, which they also didn't want. So when they got rid of him, they made it clear they didn't want him to be replaced; this is just formalizing it.
A payment system is different from a bank or an investment broker - its main job is to move money around, not store it except temporarily, so unlike a bank, if your money earns interest that's pure gravy, and unlike a stockbroker, if your money loses value other than the documented fees, that's highly unexpected, but in all three cases, they've got basic fiduciary responsibility to not rip you off, and to not give your money to other people without permission. It's *your* money, not theirs.
Regulation may discourage this, and money-handling services benefit very strongly from trusted independent regulators and auditors, because that makes customers more willing to deal with them (and if they didn't have regulators bullying them around for free or insuring them for a subsidized price, they'd go out and buy equivalent services themselves), but fundamentally anybody who doesn't run their business competently will find Darwin kicking them out of the gene pool whether there are regulators helping them or not.
The two big interoperability problems for FreeS/WAN have been explicit non-support for Aggressive Mode (they don't support it, mainly because there are security problems that affect the general user that don't affect most commercial applications), and lack of support for various proprietary authentication systems (not that I've been thrilled with their Opportunistic Encryption work, since the versions I've seen assume levels of control over reverse DNS space that most people don't have.)
Their concerns for user-friendliness have been legendary ("First recompile your Linux kernel cleanly, then you can start to install the IPSEC stuff...." :-) It's not the same goals as other parts of the IPSEC vendor community ("First find the end of the brown wire with the two little prong-thingies and plug it into the electric socket in the wall. See Figure 37 if this is difficult for you.") Not surprising, because while they really do want everybody in the world to be able to communicate securely, they also had a lot of research to do on how to make things work well, and the world around them that they've had to support has been changing rapidly while they were working - it's been a lot like changing the tires on a moving truck, while your users are rebuilding the truck and other people are rebuilding the road or inventing chemistry for vulcanizing rubber. If it's not always obvious why their work has been so critically important and valuable, well, it has been anyway.
Almost two decades ago, I was supporting a network modelling application that needed 12MB, and our computer was a VAX with 4MB of RAM, but fortunately 4.1BSD and System 5.2p were able to give it enough virtual memory to scrape along. Our typical runs took about a week, until a couple years later when the price of RAM dropped to the point that we could afford to upgrade to 16MB, at which time it dropped to an hour per run.
One thing we found out was that as you approach the limits of a machine's capacity, all the details of the architecture that you were able to ignore on smaller problems become visible, like how the TLBs work and what the memory page sizes are; things became somewhat clunky at 6MB and much more clunky at 22MB (or maybe 24MB), and some of that may have been the OS rather than the hardware. The extra 12MB RAM cost us approximately one person-year's salary, but unfortunately corporate accounting rules made it much harder to buy capital equipment than to make our study take a year longer.
At this point, I'm supposed to include the obligatory old-geezer rant about walking to the mainframe, five miles in the snow, uphill both ways, carrying punch-cards and hand-winding magtape, but that was back when I was an undergrad, and we didn't actually go to the mainframe, just the card-reader/printer/keypunch room which was half a mile away (still snow and hills), and the reason I handwound the magtape was because the professor's only copy had a cracked reel, though we did use hand-cranked papertape tools to do it, and I really _did_ wind papertapes by hand :-)
I haven't dealt with these problems lately - Moore's Law has long passed the limits of any problems I solve in practice, laptop diskdrive sizes have gotten two jumps ahead of Microsoft bloatware (though fitting backups onto CD-Rs feels a lot like fitting them onto floppies used to), and the only practical application I've got that could think about pushing the terabyte disk boundary is Tivo, if I'm willing to devote that much resources to something that makes me watch more television... The reason it took so long to get the 120GB drive on my 233MHz Pentium wasn't cost, it was BIOS upgrades
The IETF's SIP / SIMPLE protocol work may be more important, depending on which press release you read about whether AOL is cooperating with them this month. Instant messaging systems and voice-over-IP systems both need to solve the problem of finding users who are connected (typically using a presence server of some kind) and also communicating between the endpoints (typically directly, but potentially through a relay.) The SIMPLE project proposes some extentions to SIP, which means that integration between instant messaging systems and VOIP become easier (because you can reuse code and also reuse management systems.)
Meanwhile, a couple of years ago I gave my brother my then-8-year-old 386 machine. It worked just fine for Telnet and Netscape 2.x, and he wanted a machine that he wouldn't mind if somebody stole, as long as they didn't get injured carrying the 60-pound thing out the door.
If you're running PPPoA, your box is probably doing som e variation on bridging - taking your Layer 2 packets and shoving them over the PVC, which is a perfectly silly thing to do with an ATM connection. The alternative would be to terminate the Layer 2 connection and route the packets over the ATM PVC, saving a layer of protocol wrapper overhead and making the whole thing a lot simpler.
[Lots of disclaimers about this being my own opinions, not AT&T's...] AT&T's business DSL service does routing. Some of the services are static address, some are dynamic address, and it's possible we've introduced something else recently that does bridging, but for a while it's been routing. (Cable modem is an entirely different game, and depending on your local distributor, it's often an ugly and stupid game as well....)
With Win98 and its relatives like Win98 SE, if your TCP/IP is set for DHCP (as opposed to having a static address), and you've got a DHCP lease that hasn't expired, you need to use the WinIPcfg tool to release the DHCP lease and renew it. If your PC is a laptop that you carry between two offices and your home LAN, you end up doing this a lot.... If one of your operating modes is to set the PC for static addressing (as opposed to using DHCP where your DSL router's dhcpd always gives you the same address), then of course you've got to go through the Control Panel, change the settings, reboot, yadda yadda.
While you're at it, might as well run the Blue Screen of Death screensaver just so everything looks normal.
The two things that PPPoE seems to accomplish are to give the telcos (or other CLECs) and ISPs a bit more flexibility about where to put routers - it makes it easier to terminate the PVC on a shared router at the telco POP instead of requiring either an ATM connection to the ISP or an ISP-owned router at the POP. The authentication features also makes it a bit easier to turn off service to people if they haven't paid their bills, for the case where the telco/CLEC is providing a shared router at the POP. (If the ISP has a PVC all the way back to their router, they can do the same thing by disabling the PVC in their router.)
Mostly it's ugly.
On the other hand, I mostly stopped bitching about bureaucrats using this terminology when I built a lab a couple of years ago - we had $900 desks, with $400 PCs on them, so if the Furniture Mafia are getting more of the money, they can decide which stuff gets the title. (Of course, the reason we had $900 desks and $1500 racks that arrived six months and eight procurement review meetings after we started the project instead of $100 desks and $200 Metro shelves that the furniture store on the next block said they could deliver on Tuesday was because the Building Furniture Mafia told us that furniture procurement was An Offer We Couldn't Refuse, and that we would only be allowed to install racks that were Officially Earthquake-Bolted to the floor, and the only way to get Official Earthquake-Bolting was to order furniture from people the Building Furniture Mafia had deals with...)
As far as the DNS DDOS attack goes, the relationship between ICANN and the root servers is pretty fluid - it doesn't own or control them, though the Feds fund some of them, and it's more concerned with the master databases of who owns what names than the implementation issues of what IP address currently is attached to the names. Remember, ICANN are not engineers - they're intellectual property policy wonks. ICANN does encourage the root servers and the registries and registrars to follow security / reliability standards, and the recent DDOS attack means that there'll be some changes in the way things are run. There's an RFC 2870 on Root Name Server Operational Requirements, so if you've got opinions on how they can do a better job, go Comment.
ICANN's work on the top-level domains deserves mixed reviews. Moving slowly is usually ok; the big reasons for expanding the space are "because it gives us more cool names to sell", and one of the big reasons for going slowly is that you can only sell each TLD once, so you'd better get it right. Unfortunately, their definitions of getting it right strongly involve letting them stay in control, and are biased against any experimentation except along very narrow lines that they can stay in control of. But the IETF Ad-Hoc committee couldn't crack the political layer either. One thing both groups did right is pick a bunch of boring TLD names for the first batch, because they're going to make mistakes and discover unexpected problems in the first batch or two, and it's much better to mess up the market for .MUSEUM or .FIRM which nobody cares too much about than to mess up commercially valuable names like .INC or .LTD or .SEX or anything that overlaps with the voice telephone business.
IPv6 is Not ICANN's Job. It's the industry's, and the carriers', and Cisco's. ICANN does have the responsibility for coordinating the root servers' transition to support for IPv6 name lookups, and for making sure the Reverse DNS Lookup space (today's 1.0.0.127.in-addr.arpa PTR queries) gets managed correctly, though the standards work is probably the IETF's job, or maybe ISOC's. The one thing they've done in the IPv6 space that was Blatantly Evil (but probably reversable) was to claim that all your address bits are belong to them and set an unacceptably high price for the smallest routable address block. This not only delays widespread implementation until a major carrier either decides to pay them or ignore them, it nails down some assumptions about the shape of the hierarchy and organizational relationships that may be hard to repair, and increases the brittleness of the net without obviously benefitting the routing table situation (which is probably a more important IPv6 issue than the supply of address bits.) This delay gives them more time to try to finish grabbing power before IPv6's virtually-unlimited address space escapes from their ability to steal it from the world and sell it, but it also gives the industry more time to figure out what we're going to do with IPv6 and how to manage it, which is not a Bad Thing - there's a lot we really need to learn about how to use it before it's ready to replace IPv4.
There have been some recent proposals saying that the ITU should be in charge - as somebody who's been in the telecom business for 25 years, I view them as better than ICANN, because some of them are engineers and because they're a slow bureaucratic multilateral committee rather than a cabal, but they're still the kind o f bureaucratic telecom who brought you E.164 names, X.25 as their best example of data networking, and OSI protocols and high European telecom settlement costs, and the best thing about them has been that you could usually ignore them and use whatever interesting tools came out of the vendor and developer community...
They tried very hard to eliminate the publicly elected seats before the election, and it was pretty clear when Karl managed to get elected anyway that they didn't want him there and were going to try to prevent any "representative of the public" from interfering. While Karl is definitely on the cantankerous side, that had a lot to do with why *he* got elected - it was obvious before the election that ICANN was trying to railroad the public, and the public responded by electing a representative who was not only articulate and aggressive but also very clearly committed to trying to get ICANN to behave properly, work openly, and make policies that were responsive to the public. He started off his term as pretty much the lone member of The Opposition, with his major support base being the people that the rest of ICANN wanted to ignore - it's a tough spot for someone who's really good at politics.
Some of us were skeptical about the concept at the beginning, but the immense practicality of a common naming system compared to
So you've got your nanotech computing surface paint, why not put it to work? The processors are presumably a lot slower than modern CPUs, but so what, they don't have much better to do other than decide what color to be (What color is a chameleon in a mirror?) So give it some solar power source and let it compute things in its spare time.
The other problem is what kind of computation a system like that would do "Why am I here?" "How do I get somewhere else that nobody will shoot at me?" "I smell paint remover! Run away! Run away!"
Getting the heat out won't be a problem if you can't get the electricity in to power them. If you're using your own real estate, it's one thing, but if you're actually using 60KW of electricity in one rack, that's about how much power a typical colo center provides for 10-40 racks of servers, depending on how you're counting redundant power feeds. If you're trying to fit that many processors in one rack, and using heavy-power Xeons instead of low-power Transmetas, you need to start looking at room airflow and not just in-box airflow. The obvious solution is to imitate a Cray-2, and use Fluorinert or some other liquid fluorocarbon coolant piped in from a big honking Air Conditioner outside your building, possibly combined with some kind of gas turbine to turn some of that waste heat back into electricity.
If you're using your own real estate, it's pretty easy to power the things, but if you're buying commercial hosting space, blade servers and 1U rack servers quickly start running into problems with electricity. The problem is that Intel/AMD CPUs are fairly power-intensive, and increasing the density by a factor of 5-20 over traditional PC designs also increases the amount of power that a rack of servers needs to levels beyond what the typical hosting center is designed for. If you're getting a rack with 2 20-amp circuits, you've got 4KW to play with - doesn't go very far if you've got to feed 200 or 336 Xeon chips, and for that matter, isn't really ideal for 42 1U rack-mounted boxes, if you want to have redundant power supplies and you're burning 75W per CPU plus some more power for the disk drives.
And of course, all those watts of heat require cooling. If you're planning to do it, have a serious talk with your real estate suppliers.
The other problem with adapting current blade technology to the desktop is price - most of them are too expensive per blade compared to an equivalent-speed ATX.
Kids these days don't know cultural references. The article refers to Curious Yellow and Curious Blue, and also to cryptography. The late Martin Minow, one of the Cypherpunks cryptography community, lived in Sweden for a number of years working for DEC, later moving back to North America. During that time, he did a number of things, including the English translations of the movies "I Am Curious (Yellow)" and its followon, "I Am Curious (Blue)".
You can still see remains of them around 4th & Harrison (SouthEast corner), and around 4th & Folsom. They cleaned up a lot of them, but some of it just didn't come off.
So Oxford University is planning to study changes in climate - by feeding large quantities of electricity (mostly generated by burning fossil fuels) to large numbers of heat-generating CPU chips, contributing to global warming. Sounds like a Heisenbug to me....