Smalltalk for (Highly Productive) Geezers
on
Too Old To Code?
·
· Score: 2
A number of my friends are Smalltalk enthusiasts. None of them are under 40, and while there aren't a lot of places using it, they seem to all know where to find customers who want their environments radically transformed and highly productive. Age has a couple of effects - some of it's perspective from years of experience, some of it's having been around back when Smalltalk was a fad, before Java became the fad, and some of it's the old value set about knowing lots of programming languages that C/C++/Java replaced.
College co-op jobs are a great deal.
on
Too Old To Code?
·
· Score: 1
You may be able to find a better job on your own, but college co-op jobs are an excellent opportunity to get some real-world work experience while you're still in school. It's a way to get into high-tech and also medium-tech companies that would otherwise ignore you because of lack of work experience, gain some perspective on what the real world looks like that can help you direct your education, and even if you don't end up working there after school, you've got a lot more on your resume than some kid who just studied, or studied and hacked. Having a few well-defined projects you've succeeded at looks good too.
You can be obsolete at 25, or non-obsolete at 65 - it's an attitude thing. A decade or so ago I was commuting (weekly) by train from Jersey to a project in DC. The old guy across the table from me in the dining car had the smallest laptop I'd seen (which back then was about 6 pounds, only available in Japan), an alphanumeric Skypage (those were cool back then), and a cellphone which was small for its day (but still couldn't get a signal while we were crossing the Chesapeake.) We started talking, and it turned out to be Dave Farber from UPenn, who'd just helped start the EFF (I was working on EFF stuff as well). Dave's now the new technology consultant to the FCC, and still running the Interesting-People mailing list and going to technology conferences around the world.
There are two factors that determine whether you can get DSL, and what speeds/flavors are available:
Whether your CO has a DSLAM (and what kind.)
How far you are from your telco central office (CO)
The DSLAM (DSL Access Multiplexer) is the box in the CO that handles your line and forwards your packets to a DSL carrier's ATM switch or router. It may be owned by the Telco (aka ILEC, Incumbent Local Exchange Carrier), or by a CLEC (Competitive LEC) like Covad, Northpoint, Rhythms, or Jato. In the middle of Silicon Valley, there are probably multiple carriers' DSLAMs; in Buffalo Wyoming there probably aren't any. The DSL carrier has some kind of regional concentration network, usually ATM, and connects a feed to whatever ISPs want to buy one. Some carriers, like Covad, have national ATM networks, so an ISP can connect to any Covad DSLAM in the US, probably for a higher price and somewhat higher latency than a local connection. The ISP is responsible for providing the router, IP address space, and most customer support; the ISP is a customer of the DSL carrier, who is a customer of the telco that owns the wire to your house.
Distance to the CO determines what DSL protocols and speeds can be used. For SDSL (the symmetric stuff), you can get about 12000 feet at 768kbps, and 18000 feet at 384kbps. If you want to go a long distance, IDSL uses ISDN electrical formats on the wire, but connects to a DSLAM for full-time packet service instead of connecting to a phone switch for ISDN telephone calls, and it gets smoething like 24000-30000 feet at 144kbps. These distances are equivalent wire lengths - that's how long the wire really is, adjusted for wire quality, and you can't get decent performance if you exceed the lengths. The telco can't always tell how far away you are - my house is supposed to be 11000 feet from the CO, but once when I had phone trouble, they did some tests that suggested it might be 16000, and later when I got DSL service, we gave up on getting 768kbps to work and used 384kbps.
Many of the telcos, such as Pac Bell, also provide DSLAMs and IP service. It's theoretically more likely to be successful than separate carriers, though there are mixed opinions about how well it works in practice (the negative opinions aer usually louder.) Also, ADSL makes it possible to use one pair of copper to carry both a voice circuit and an ADSL circuit, using splitters at the house. This is a big win for provisioning speed, because you can use the customer's existing phone wire pair, rather than installing a new one. It's mostly supported for Telco-provided DSL, though the telcos are supposed to let the CLECs also offer it in most territories, and it'll gradually become available in practice.
Disclaimer: I work for AT&T, which sells DSL service for businesses and consumers. Last year, when we were starting to offer DSL service, I volunteered to be a guinea pig beta user. Pac Bell owns the wires, Covad did the DSLAMs, and AT&T did the ISP portion. It worked quite nicely - installation took a bit longer than it should because I'm in a condo (inside wiring was fun) and because I was the first DSL customer on the ATM switch supporting my DSLAM (extra hour getting it configured correctly) and because my telephone line was either longer or noisier than PacBell told Covad it would be. The Flowpoint router worked well, and has a built-in hub. At the time we started our service, we only supported the business-priced Covad service and not the consumer-priced service, so when the beta period was over and they figured out how to bill me (:-), I disconnected it -- 384kbps is nice, but $180 was a bit much for home use. We've now got several reasonably-priced consumer offers (either 384 SDSL or 608/128 ADSL for $59), but cable modem service is supposed to finally be available in my town now (after 1.5 years of promising it Real Soon), and it gives me a better inside wiring setup.
Some modern operating systems actually keep a stubby ramdisk around all the time, basically as a root drive that they can mount other file systems on. It turns out to be useful in diskless environments and CDROM-based systems, where you don't have a real disk to hang a filesystem on. There are other ways to do it, but it's pretty clean for many kinds of environments. OTOH, you can reasonably view it as an extension of a boot loader ramdisk.
You probably don't count Win 95/98 as modern (:-), but I actually do use a small ramdisk as scratch space for security applications where I don't want the data written to a disk drive. (There is still a risk it'll get written to swap space, but I'm not doing anything at that level of paranoia:-)
It's also useful for stashing web or mail downloaded zip files where I don't have to worry about cleaning them up later, but having a big enough disk drive with a/tmp on that would do as well. Unix/tmpfs file systems would do a better job of that - they avoid writing stuff to disk until necessary, on the assumption that you'll discard most of it pretty soon, which speeds up applications like compiles more effectively than normal caching strategy which assumes you're saving something to a disk because you actually *want* it to be written to the disk.
Bad Patent Pending On Information Delivery
on
Advertising Via GPS
·
· Score: 2
If the press release is to be believed, it's a patent on using a wireless handset to deliver information that's dependent on where you are, such as telling you the nearest MacDonald's. - handset-based services granted now, network-based pending. I'm not sure how broad their patent claims are, as opposed to their marketing PR (:-), but it sounds like it's way over-broad, steps on lots of things that should be obvious enough to anyone skilled in the trade, and sounds like Yet Another Stupid Patent Office Trick.
..."U.S. patent office has conditionally allowed Cell-Loc to claim the delivery of handset-based wireless location content and services over the Internet as its property, regardless of technological method employed."
Unfortunately, after downloading the half megabyte of animated Web Designer Candy that serves as their main web page, it wasn't possible to get to any real information, but YMMV...:-)
GPS - Receive-Only Power Burner; Wireless Synergy
on
Advertising Via GPS
·
· Score: 2
GPS sets are receive-only, and most of them burn lots of power if you want to keep them running continuously. However, if you've got a wireless data link of some kind, you can still have it check where you are occasionally without running it full time. The added accuracy really is nice when you're trying to get street directions - I forget the exact specs, but it changes from ~50meters to ~5, and if _you_ want to find the nearest pizza place, as opposed to it finding you, and you've got some kind of wireless data link, it works well.
There's scarier stuff around, though. Under the guise of better 911 support (emergency services calling in the US; most of the world uses 999), the FBI is pushing the FCC to require the next generation of digital cellphone standards to be able to locate you within ~50 meters. (Some cellphone standards can get pretty close to that by triangulating sites through the network; it's interesting if your phone can do it as well, especially if you don't need to buy GPS to do it. And better GPS makes it easier for cell sites to get precise timing and know where they are precisely so they can do this much more accurately, which is especially important for microcells that you might deploy lots of.) They'd really like to be able to ask your phone where it is without notifying you or asking for permission; there are some people in the cellphone standards committees who are quite annoyed about this, and many who don't see what all this privacy fuss is about and of course it makes it easier for 911 to find you if you're hurt. The interesting trick is that if there's a GPS in the phone, they can ask it where you are without having to leave it on full time, though it does take a little while for the GPS to locate satellites, especially simpler sets that don't locate them in parallel.
A lot of the performance issues depend on your usage statistics, and on the driver implementation qualities (their drivers or yours:-). Many applications do more reading than writing, and ramdisks or operating system disk caching are are a big win for them. But most applications are also very peaked - caching lets you commit writes near-instantly, but the average rate is low enough that you can catch up in between very busy periods.
The caching lets you write to the disk in reasonably optimal order, laying down long bursts of stuff on the same track instead of seeking and rotating in between them. Of course, most modern disk drives too that also, though last I checked the caches were typically small, like 1 MB, though that may be enough for many applications. Having a substantially bigger cache on your computer means that you're much more likely to hand the disk drive orderly stuff to write, and wasting less interface bandwidth on reads and on idle time.
Forgot to mention - Legato used to make an accelerator board for Suns that was basically a meg or two of battery-backed RAM on an S-Bus card, with some appropriate driver support. As with databases, being able to commit a write without waiting 5-10ms for mechanical latency was a big performance win for NFS, and a meg or two was enough buffering to do the job. It could also be used for database journaling files, and similarly helped a lot. Keeping a couple MB of SRAM or DRAM alive doesn't take hulking UPS batteries - a little NiCAD or lithium cell can keep you alive through pretty long power failures, and the drivers were written to write any leftovers to disk at boot time if they hadn't been written already.
Sure, it costs a lot more per GB than rotating machinery, and I wouldn't buy one for home, but in a business context it's a really cheap deal if it works well. You can get a substantial speedup for less than one day's consulting fee for a database wizard. (Of course, if it's not a good match, you might end up spending a few days's consultant time to make it work:-) Also, the performance impact may save you buying another computer, which would cost at least as much for a production server.
Application structure in general - Lots of applications know they're dealing with *files*, not memory, so you've got to give them something that looks like a disk, either by hanging it off a disk controller (using SCSI or IDE-like), or on a PCI bus (imitating a disk controller), or using RAMDISK drivers, or using hybrid memory/disk file systems like TMPFS.
Database-specific needs, particularly committment - DBMSs really need to know that when they've written something to stable storage, it'll stay there unless they change it - crashing the machine or losing power will trash things in regular RAM, and that just doesn't cut it. Sticking a bunch of RAM in a SCSI shoebox with its own stable power supply and maybe an automagic copy-to-builtin-disk gives you the security you need, and 8GB really *did* hold a large database not very long ago:-) Putting it on an imitation disk controller board required being more careful about armoring it, but you might be able to do it. And building a stable storage device that doesn't need to wait 5-10ms to commit data is a big big performance win.
There are also scaling issues - motherboards always have some limit on capacity, whether it's address lines or card slots or whatever. With Ultra-Mega-FooBar-SCSI, you can hang 8-16 of these things on the bus if you need to. Living on a bus lets you design boards for your specific application, and isn't limited by the design tradeoffs and compatibility requirements of a general-purpose computer, just by the size, power, and cooling of a shoebox or 1-2U and the creativity of the designer. Can *your* desktop machine address or even hold 8GB of RAM? Mine can't.
Devices like this have been around for a decade or more, but as memory keeps getting radically cheaper they become more interesting. The big performance win isn't usually how many MB/s throughput you get, though that's nice, but it's the elimination of rotational and seek latency which can be 5-10ms - a long time for a database transaction, and even with journaling filesystems or datastructures you've got to deal with some of it.
Be sure to use a good UPS with the things, and make sure your powerfail shutdown procedures work well.
The Communications Workers of America and the International Brotherhood of Electrical Workers are already around, and it's pretty typical for phone company craft workers to belong to one of them, take advantage of their training and apprenticeship programs, etc. Non-union electrical contractors also do a lot of this sort of installation.
Most of the articles have commented on inside wiring issues, be the article was really about outside wiring - providing reasonably large shared service in a neighborhood. It's an interesting concept, and the first I'd heard of it except for the cable modem business.
But shared internet service for office buildings and apartment buildings is becoming a huge industry, just as wiring apartment buildings for cable TV and telephones is pretty universal. A typical building will use Cat5 or maybe fiber risers, and feed a T1 or maybe a smaller frame relay connection, and higher-tech office buildings may do larger connections. DSL turns out to work very well for large buildings - put a DSLAM in the basement, and use high-speed connections inside the building and whatever amount of upstream the building needs to buy.
The question of who runs the infrastructure has a variety of answers. There are a number of companies like Allied Riser that contract with real estate companies to get access to their customers. Alternatively, the real estate company may do it themeselves or hire somebody to do it. Phone companies and Alternate Access Vendors like Worldcom's MFS and Brooks and AT&T's AT&T Local Services put fiber in large building basements. Cable TV company Hybrid Fiber Coax is also providing similar access. (And a couple friends of mine strung their own Ethernet in a Palo Alto apartment complex a decade ago - several members of their startup were living there:-) Overall, it's starting to resemble the Hosting Center business, where some companies run the real estate, rack space, and network feeds, some companies rent computers in the racks, some provide web hosting services on computers rented in the racks, some ISPs provide additional network feeds, and everybody overlaps.
Buffer overflows in a security product are simply inexcusable for anything written in the past decade. They've been the cause of most of the non-Microsoft security holes since the Morris Worm , and anybody who's building firewall code should not only be using libraries that aren't susceptible to them (e.g. no gets()) or languages that don't allow them (if Java's not too slow), but they should be explicitly looking for them in code reviews, and doing enough code review they don't slip through.
A separate problem is the complexity of the programming interface. I haven't seen it, but the descriptions in the articles sound like NAI had to do a lot of work to interface to it, enough that they did so unsuccessfully. But censorware's designed to be used in firewalls, so the interfaces need to be clean and well-documented, because you can't afford security mistakes here. There should be two or three parts to the interface - one that takes a URL and returns approve/reject, and one that provides administrative control over preferences, which is obviously more complex but should still be easy to do cleanly. The potential third part is processing the returned http itself (looking for dirty words or whatever), which is also hard, and needs to be cleanly designed so you can use it safely.
The reason for brute force attacks isn't to actually crack keys - it's to make people stop using wimpy algorithms, and to make government officials stop forcing us to use wimpy algorithms.
The nice thing about current mathematical cryptography is that many algorithms have strength that's exponentially proportional to key length - so a small increase in the amount of encryption and decryption work radically increases the work that's required to crack it without the keys. Linux clusters and distributed.net and DES cracker boxes are great for brute-forcing DES and RC4-40 and RC5-56, but the planet only has 2*170 atoms on it, 3DES, which has 168-bit keys, takes only about 3 times as much work as DES to encrypt/decrypt. (Ok, the real strength is only about 112 bits, because there's an attack using 2**64 bits of storage and 2**112 cycles, but there's always 5-DES and 7-DES, and algorithms like RC4 and RC5 don't even take extra work to use longer keys - you won't crack RC4-128 or 3DES by brute force in your lifetime unless the Great Nanotech Singularity changes your lifetime a lot - and probably not in the planet's lifetime.
It's MUCH easier to steal keys than crack good algorithms. Decompiled your keyboard ROMs lately? This is Slashdot, so many of you *have* checked out the device drivers for your keyboards:-)
The EU does recognize software / algorithm patents, but there are procedural issues that made RSA not patentable in Europe. An example of a Euro-patented algorithm is the IDEA symmetric crypto used in the RSA versions of PGP. The reason Diffie-Hellman and RSA aren't patentable in Europe is that the US allows a publish-first-then-apply-soon procedure, whereas most European countries require you to apply for the patent before publishing.
The reason D,H,R,S,A and many other US-based cryptographers published first and then apply for patents is that back in the 70s and early 80s, the NSA still had a heavy thumb on the crypto world, and while the good guys were establishing that, yes, they could publish crypto even without permission, there's a bit of American patent law that lets the NSA (and probably other military agencies) seize and classify any patent applications that are critical to national security. So if you published first, it didn't do them any good to steal your patent, but if you applied for the patent first, they could steal it and squelch it. So you published, took your US and Canadian patents if you wanted, and gave up the European patents. Sometimes the dance was more obscure, and you had to carefully time submissions to the patent office and journals to work the time lags in both of them.
Back in the mid-90s, the cat was out of the bag, and I developed a login protocol based on Diffie-Hellman. After some online literature-searching, I was annoyed to find that some guy at Siemens in Germany had also developed it, and patented it in Germany and then the US a couple years before, though I hadn't seen anything about it in print. In US patent law, you can't patent something that would be obvious to anyone skilled in the trade (in spite of all the totally lame and obvious software patents out there, where the patent examiners were clueless about the subject area.) Believe me, if *I* found it, it's pretty obvious (:-) -- it was simple enough I'd expected to see it in the usual references, I was doing the literature search to find if I'd missed some flaw that makes it useless. But the German patent predated the US one, so it wasn't worth pursuing.
Fell apart a few years ago. They wrote nice literature, and made cool T-Shirts and flags, and got people to donate funding for studies about how to do a floating country, but I was never convinced that they were serious about actually deploying anything. In particular, they spent a lot of time talking about a floating hotel somebody had, but instead of getting some funding to go buy it for ~$25M, they went off on some wild scheme to build a $1B huge thing. The problem, of course, is that you're gambling on whether the UN and various countries will treat you as sovereign if your country doesn't have any dirt, and it makes a lot more sense to test this on a cheaper platform than a really expensive one.
Was it always a scam? Or was it a couple of well-intentioned guys who didn't have a clue what they were into? Not sure.
I've used a variety of limited-color-choice displays over the years. Remember CGA? Or 8-bit displays on Suns? Some of the limitations really matter, some don't. The big difference is between true-color displays (which are a bit lame with a limited number of bits) and table-lookup displays (which give you a lot more choices, but tend to flash around when different processes mess with the color tables.) With true-color displays, 12 bits means 4 bits per color; 16 bits usually means 5 bits per color and do something with the leftover bit. That's not a big difference for color photographs, but it's an immense difference for handling gray-scale pictures - 16 grays vs. 32 grays vs. 64 grays makes a lot of difference, though it's less important once you've got at least 64 gray levels (6 bits). I used to work with satellite images, and it made a lot of difference having >=64 gray levels - things went from banded-looking to continuous-looking around that level. The real data was originally from 12-bit A-to-D converters, but usually quite processed by the time we got it.
Table lookup display drivers give you a lot more choices (the 12 or 16 bits can be a lot of gray levels plus a reasonable number of colors, and even 8 bits is a good start as long as you don't mind the non-active windows being all the wrong colors because somebody else has the color table right now.
There are also several different Jornadas - one's Palm-shaped, one's large-Psion-shaped.
St. Brendan's expedition from Ireland, if it wasn't mostly mythical, was probably in the 600s, probably a bit late for Beowulf to get decent French Fries. All of the well-known Viking expeditions to North America were long after Beowulf. Erik the Red got to Iceland in the 900s; Leif Erikson got to Greenland a bit later, and from there down to Vinland, aka Atlantic Canada. There'd also been another expedition of Icelanders or Greenlanders (I forget who..) who'd sailed by some islands that were probably Canada but didn't land. If the allegedly Viking Kensington Stone in Minnesota wasn't a hoax, it was from the 1200s. So even if Leif met some Inuit in Greenland who traded freeze-dried potatoes with their neighbors 6000 miles to the south, that'd be a bit late.
Actually, the critical resource here is probably not the potato itself, but the zinc on the nail getting oxidized. You should be able to reuse the potato as long as you keep changing nails.
Beowulf is set in 6th-Century Scandinavia. Potatoes originated in the Andes and were brought to the new world from Peru by the Spanish conquistatdores in the 1500s/1600s. So Beowulf would have been dead about a thousand years before he could get a potato, and probably a while longer before he could get any French Fries...
Dan Quayle probably couldn't spell Beowulf either...
College students, by the way, usually fall somewhere in between the "independently wealthy" and "working some other job" categories that Meyer proposes, and he seems to think a university falls squarely into the category of a private company that owns the work of its employees, rather than being the confusing hybrid of private company, public institution, student guild for hiring teachers, research lab space rented to professional researchers, monastery, and hiring shop for summer consultants that has evolved from the early medieval university model, Humboldt research-oriented model, teacher training college, post-WWII military-industrial-complex fund sink, and draft-dodger-destination (actually I was a bit after that) that the modern university is in between.
If Meyer thinks watching Stallman and a software developer at dinner is contentious, he should have been there when a friend of mine maneuvered RMS into a discussion on software patents with a patent attorney:-) While RMS dislikes software patents intensely (and I generally agree with him on the topic), he did agree that if software patents were for short periods of time, say 5 years or less, rather than the current near-infinity-in-Internet-years, he could live with them, because programmers could still do their work without too much interference. And just because many of us in the community respect things RMS has done and many of the positions he's taken, that doesn't mean there's either anything resembling universal worship or liking his Whiny Righteous Anger Mode - there are times you put up with it because he has earned lots of Extra Slack points.
If Meyer wants to attack the free software movement by ad hominem attacks against its major players, we really do need to call on the Object Oriented Programming community to reject this person who not only believes that governments should radically outgun their subjects (in spite of the obvious contradiction between this and the last few millenia of experience watching armed governments make wars and oppress their citizens), but who clearly states that they should use the powers they've acquired to help control who has access to what software. (Needless to say, this paragraph is intended as a flame:-).
I've met ESR once or twice, back when I lived on the East Coast, before the Linux revolution happened. He had started doing the printed revised jargon dictionary, and was sharing booth space at the Tre nton Computer Fair with Nancy Lebovitz, the Calligraphic Button maker. Nice guy, and since nobody'd acquired the collection of used 9-track tapes he'd brought (in addition to the book), he decided to be non-attached to property and we frisbeed them into the dumpster.
My organization used to have a crude ugly conference system, which left recent postings at the top and did a little bit of nesting. It was very popular, the sales people could use it to talk to each other, and yeah, it got slower every month as the number of articles grew. They replaced it with a fancy system that pretends to do lots of nesting, keep track of what you read, and everything's sorted by topics. It's flaky, hard to navigate in, forgets what you've read, and (worst) doesn't get used as much as the crude system it replaced. They'd have been much better off leaving it alone and occasionally dragging old articles to another directory (or even just trashing them after 6 months, though archiving would be much better.)
Slashdot Mirror
A number of my friends are Smalltalk enthusiasts. None of them are under 40, and while there aren't a lot of places using it, they seem to all know where to find customers who want their environments radically transformed and highly productive. Age has a couple of effects - some of it's perspective from years of experience, some of it's having been around back when Smalltalk was a fad, before Java became the fad, and some of it's the old value set about knowing lots of programming languages that C/C++/Java replaced.
You may be able to find a better job on your own, but college co-op jobs are an excellent opportunity to get some real-world work experience while you're still in school. It's a way to get into high-tech and also medium-tech companies that would otherwise ignore you because of lack of work experience, gain some perspective on what the real world looks like that can help you direct your education, and even if you don't end up working there after school, you've got a lot more on your resume than some kid who just studied, or studied and hacked. Having a few well-defined projects you've succeeded at looks good too.
You can be obsolete at 25, or non-obsolete at 65 - it's an attitude thing.
A decade or so ago I was commuting (weekly) by train from Jersey to a project in DC. The old guy across the table from me in the dining car had the smallest laptop I'd seen (which back then was about 6 pounds, only available in Japan), an alphanumeric Skypage (those were cool back then), and a cellphone which was small for its day (but still couldn't get a signal while we were crossing the Chesapeake.) We started talking, and it turned out to be Dave Farber from UPenn, who'd just helped start the EFF (I was working on EFF stuff as well). Dave's now the new technology consultant to the FCC, and still running the Interesting-People mailing list and going to technology conferences around the world.
The DSLAM (DSL Access Multiplexer) is the box in the CO that handles your line and forwards your packets to a DSL carrier's ATM switch or router. It may be owned by the Telco (aka ILEC, Incumbent Local Exchange Carrier), or by a CLEC (Competitive LEC) like Covad, Northpoint, Rhythms, or Jato. In the middle of Silicon Valley, there are probably multiple carriers' DSLAMs; in Buffalo Wyoming there probably aren't any. The DSL carrier has some kind of regional concentration network, usually ATM, and connects a feed to whatever ISPs want to buy one. Some carriers, like Covad, have national ATM networks, so an ISP can connect to any Covad DSLAM in the US, probably for a higher price and somewhat higher latency than a local connection. The ISP is responsible for providing the router, IP address space, and most customer support; the ISP is a customer of the DSL carrier, who is a customer of the telco that owns the wire to your house.
Distance to the CO determines what DSL protocols and speeds can be used. For SDSL (the symmetric stuff), you can get about 12000 feet at 768kbps, and 18000 feet at 384kbps. If you want to go a long distance, IDSL uses ISDN electrical formats on the wire, but connects to a DSLAM for full-time packet service instead of connecting to a phone switch for ISDN telephone calls, and it gets smoething like 24000-30000 feet at 144kbps. These distances are equivalent wire lengths - that's how long the wire really is, adjusted for wire quality, and you can't get decent performance if you exceed the lengths. The telco can't always tell how far away you are - my house is supposed to be 11000 feet from the CO, but once when I had phone trouble, they did some tests that suggested it might be 16000, and later when I got DSL service, we gave up on getting 768kbps to work and used 384kbps.
Many of the telcos, such as Pac Bell, also provide DSLAMs and IP service. It's theoretically more likely to be successful than separate carriers, though there are mixed opinions about how well it works in practice (the negative opinions aer usually louder.) Also, ADSL makes it possible to use one pair of copper to carry both a voice circuit and an ADSL circuit, using splitters at the house. This is a big win for provisioning speed, because you can use the customer's existing phone wire pair, rather than installing a new one. It's mostly supported for Telco-provided DSL, though the telcos are supposed to let the CLECs also offer it in most territories, and it'll gradually become available in practice.
Disclaimer: I work for AT&T, which sells DSL service for businesses and consumers. Last year, when we were starting to offer DSL service, I volunteered to be a guinea pig beta user. Pac Bell owns the wires, Covad did the DSLAMs, and AT&T did the ISP portion. It worked quite nicely - installation took a bit longer than it should because I'm in a condo (inside wiring was fun) and because I was the first DSL customer on the ATM switch supporting my DSLAM (extra hour getting it configured correctly) and because my telephone line was either longer or noisier than PacBell told Covad it would be. The Flowpoint router worked well, and has a built-in hub. At the time we started our service, we only supported the business-priced Covad service and not the consumer-priced service, so when the beta period was over and they figured out how to bill me (:-), I disconnected it -- 384kbps is nice, but $180 was a bit much for home use. We've now got several reasonably-priced consumer offers (either 384 SDSL or 608/128 ADSL for $59), but cable modem service is supposed to finally be available in my town now (after 1.5 years of promising it Real Soon), and it gives me a better inside wiring setup.
You probably don't count Win 95/98 as modern (:-), but I actually do use a small ramdisk as scratch space for security applications where I don't want the data written to a disk drive. (There is still a risk it'll get written to swap space, but I'm not doing anything at that level of paranoia :-)
/tmp on that would do as well. Unix /tmpfs file systems would do a better job of that - they avoid writing stuff to disk until necessary, on the assumption that you'll discard most of it pretty soon, which speeds up applications like compiles more effectively than normal caching strategy which assumes you're saving something to a disk because you actually *want* it to be written to the disk.
It's also useful for stashing web or mail downloaded zip files where I don't have to worry about cleaning them up later, but having a big enough disk drive with a
(This was on Dave Farber's list.)
..."U.S. patent office has conditionally allowed Cell-Loc to claim the
:-)
If the press release is to be believed, it's a patent on
using a wireless handset to deliver information that's
dependent on where you are, such as telling you the nearest MacDonald's.
- handset-based services granted now, network-based pending.
I'm not sure how broad their patent claims are,
as opposed to their marketing PR (:-), but it sounds like it's
way over-broad, steps on lots of things that should be obvious enough
to anyone skilled in the trade, and sounds like Yet Another
Stupid Patent Office Trick.
Their Press Release www.cell-loc.com
delivery of handset-based wireless location content and services over
the Internet as its property, regardless of technological method employed."
Unfortunately, after downloading the half megabyte of animated Web Designer Candy
that serves as their main web page, it wasn't possible to get to any
real information, but YMMV...
There's scarier stuff around, though. Under the guise of better 911 support (emergency services calling in the US; most of the world uses 999), the FBI is pushing the FCC to require the next generation of digital cellphone standards to be able to locate you within ~50 meters. (Some cellphone standards can get pretty close to that by triangulating sites through the network; it's interesting if your phone can do it as well, especially if you don't need to buy GPS to do it. And better GPS makes it easier for cell sites to get precise timing and know where they are precisely so they can do this much more accurately, which is especially important for microcells that you might deploy lots of.) They'd really like to be able to ask your phone where it is without notifying you or asking for permission; there are some people in the cellphone standards committees who are quite annoyed about this, and many who don't see what all this privacy fuss is about and of course it makes it easier for 911 to find you if you're hurt. The interesting trick is that if there's a GPS in the phone, they can ask it where you are without having to leave it on full time, though it does take a little while for the GPS to locate satellites, especially simpler sets that don't locate them in parallel.
The caching lets you write to the disk in reasonably optimal order, laying down long bursts of stuff on the same track instead of seeking and rotating in between them. Of course, most modern disk drives too that also, though last I checked the caches were typically small, like 1 MB, though that may be enough for many applications. Having a substantially bigger cache on your computer means that you're much more likely to hand the disk drive orderly stuff to write, and wasting less interface bandwidth on reads and on idle time.
Forgot to mention - Legato used to make an accelerator board for Suns that was basically a meg or two of battery-backed RAM on an S-Bus card, with some appropriate driver support. As with databases, being able to commit a write without waiting 5-10ms for mechanical latency was a big performance win for NFS, and a meg or two was enough buffering to do the job. It could also be used for database journaling files, and similarly helped a lot. Keeping a couple MB of SRAM or DRAM alive doesn't take hulking UPS batteries - a little NiCAD or lithium cell can keep you alive through pretty long power failures, and the drivers were written to write any leftovers to disk at boot time if they hadn't been written already.
Sure, it costs a lot more per GB than rotating machinery, and I wouldn't buy one for home, but in a business context it's a really cheap deal if it works well. You can get a substantial speedup for less than one day's consulting fee for a database wizard. (Of course, if it's not a good match, you might end up spending a few days's consultant time to make it work :-) Also, the performance impact may save you buying another computer, which would cost at least as much for a production server.
There are also scaling issues - motherboards always have some limit on capacity, whether it's address lines or card slots or whatever. With Ultra-Mega-FooBar-SCSI, you can hang 8-16 of these things on the bus if you need to. Living on a bus lets you design boards for your specific application, and isn't limited by the design tradeoffs and compatibility requirements of a general-purpose computer, just by the size, power, and cooling of a shoebox or 1-2U and the creativity of the designer. Can *your* desktop machine address or even hold 8GB of RAM? Mine can't.
Be sure to use a good UPS with the things, and make sure your powerfail shutdown procedures work well.
The Communications Workers of America and the International Brotherhood of Electrical Workers are already around, and it's pretty typical for phone company craft workers to belong to one of them, take advantage of their training and apprenticeship programs, etc. Non-union electrical contractors also do a lot of this sort of installation.
But shared internet service for office buildings and apartment buildings is becoming a huge industry, just as wiring apartment buildings for cable TV and telephones is pretty universal. A typical building will use Cat5 or maybe fiber risers, and feed a T1 or maybe a smaller frame relay connection, and higher-tech office buildings may do larger connections. DSL turns out to work very well for large buildings - put a DSLAM in the basement, and use high-speed connections inside the building and whatever amount of upstream the building needs to buy.
The question of who runs the infrastructure has a variety of answers. There are a number of companies like Allied Riser that contract with real estate companies to get access to their customers. Alternatively, the real estate company may do it themeselves or hire somebody to do it. Phone companies and Alternate Access Vendors like Worldcom's MFS and Brooks and AT&T's AT&T Local Services put fiber in large building basements. Cable TV company Hybrid Fiber Coax is also providing similar access. (And a couple friends of mine strung their own Ethernet in a Palo Alto apartment complex a decade ago - several members of their startup were living there
A separate problem is the complexity of the programming interface. I haven't seen it, but the descriptions in the articles sound like NAI had to do a lot of work to interface to it, enough that they did so unsuccessfully. But censorware's designed to be used in firewalls, so the interfaces need to be clean and well-documented, because you can't afford security mistakes here. There should be two or three parts to the interface - one that takes a URL and returns approve/reject, and one that provides administrative control over preferences, which is obviously more complex but should still be easy to do cleanly. The potential third part is processing the returned http itself (looking for dirty words or whatever), which is also hard, and needs to be cleanly designed so you can use it safely.
Errr, what kind of grass was that, anyway? Do Cheech & Chong have some prior art?
The nice thing about current mathematical cryptography is that many algorithms have strength that's exponentially proportional to key length - so a small increase in the amount of encryption and decryption work radically increases the work that's required to crack it without the keys. Linux clusters and distributed.net and DES cracker boxes are great for brute-forcing DES and RC4-40 and RC5-56, but the planet only has 2*170 atoms on it, 3DES, which has 168-bit keys, takes only about 3 times as much work as DES to encrypt/decrypt. (Ok, the real strength is only about 112 bits, because there's an attack using 2**64 bits of storage and 2**112 cycles, but there's always 5-DES and 7-DES, and algorithms like RC4 and RC5 don't even take extra work to use longer keys - you won't crack RC4-128 or 3DES by brute force in your lifetime unless the Great Nanotech Singularity changes your lifetime a lot - and probably not in the planet's lifetime.
It's MUCH easier to steal keys than crack good algorithms. Decompiled your keyboard ROMs lately? This is Slashdot, so many of you *have* checked out the device drivers for your keyboards
The reason D,H,R,S,A and many other US-based cryptographers published first and then apply for patents is that back in the 70s and early 80s, the NSA still had a heavy thumb on the crypto world, and while the good guys were establishing that, yes, they could publish crypto even without permission, there's a bit of American patent law that lets the NSA (and probably other military agencies) seize and classify any patent applications that are critical to national security. So if you published first, it didn't do them any good to steal your patent, but if you applied for the patent first, they could steal it and squelch it. So you published, took your US and Canadian patents if you wanted, and gave up the European patents. Sometimes the dance was more obscure, and you had to carefully time submissions to the patent office and journals to work the time lags in both of them.
Back in the mid-90s, the cat was out of the bag, and I developed a login protocol based on Diffie-Hellman. After some online literature-searching, I was annoyed to find that some guy at Siemens in Germany had also developed it, and patented it in Germany and then the US a couple years before, though I hadn't seen anything about it in print. In US patent law, you can't patent something that would be obvious to anyone skilled in the trade (in spite of all the totally lame and obvious software patents out there, where the patent examiners were clueless about the subject area.) Believe me, if *I* found it, it's pretty obvious (:-) -- it was simple enough I'd expected to see it in the usual references, I was doing the literature search to find if I'd missed some flaw that makes it useless. But the German patent predated the US one, so it wasn't worth pursuing.
Was it always a scam? Or was it a couple of well-intentioned guys who didn't have a clue what they were into? Not sure.
Table lookup display drivers give you a lot more choices (the 12 or 16 bits can be a lot of gray levels plus a reasonable number of colors, and even 8 bits is a good start as long as you don't mind the non-active windows being all the wrong colors because somebody else has the color table right now.
There are also several different Jornadas - one's Palm-shaped, one's large-Psion-shaped.
St. Brendan's expedition from Ireland, if it wasn't mostly mythical, was probably in the 600s, probably a bit late for Beowulf to get decent French Fries.
All of the well-known Viking expeditions to North America were long after Beowulf. Erik the Red got to Iceland in the 900s; Leif Erikson got to Greenland a bit later, and from there down to Vinland, aka Atlantic Canada. There'd also been another expedition of Icelanders or Greenlanders (I forget who..) who'd sailed by some islands that were probably Canada but didn't land. If the allegedly Viking Kensington Stone in Minnesota wasn't a hoax, it was from the 1200s. So even if Leif met some Inuit in Greenland who traded freeze-dried potatoes with their neighbors 6000 miles to the south, that'd be a bit late.
not the potato itself, but the zinc on the nail
getting oxidized. You should be able to reuse the potato as long as you keep changing nails.
Dan Quayle probably couldn't spell Beowulf either...
If Meyer thinks watching Stallman and a software developer at dinner is contentious, he should have been there when a friend of mine maneuvered RMS into a discussion on software patents with a patent attorney
And just because many of us in the community respect things RMS has done and many of the positions he's taken, that doesn't mean there's either anything resembling universal worship or liking his Whiny Righteous Anger Mode - there are times you put up with it because he has earned lots of Extra Slack points.
If Meyer wants to attack the free software movement by ad hominem attacks against its major players, we really do need to call on the Object Oriented Programming community to reject this person who not only believes that governments should radically outgun their subjects (in spite of the obvious contradiction between this and the last few millenia of experience watching armed governments make wars and oppress their citizens), but who clearly states that they should use the powers they've acquired to help control who has access to what software. (Needless to say, this paragraph is intended as a flame
I've met ESR once or twice, back when I lived on the East Coast, before the Linux revolution happened. He had started doing the printed revised jargon dictionary, and was sharing booth space at the Tre nton Computer Fair with Nancy Lebovitz, the Calligraphic Button maker. Nice guy, and since nobody'd acquired the collection of used 9-track tapes he'd brought (in addition to the book), he decided to be non-attached to property and we frisbeed them into the dumpster.
My organization used to have a crude ugly conference system, which left recent postings at the top and did a little bit of nesting. It was very popular, the sales people could use it to talk to each other, and yeah, it got slower every month as the number of articles grew. They replaced it with a fancy system that pretends to do lots of nesting, keep track of what you read, and everything's sorted by topics. It's flaky, hard to navigate in, forgets what you've read, and (worst) doesn't get used as much as the crude system it replaced. They'd have been much better off leaving it alone and occasionally dragging old articles to another directory (or even just trashing them after 6 months, though archiving would be much better.)