Slashdot Mirror

The problem is that for firearms you need metal for the part that handles the bullet and the hot gasses in exess of 2000 degress K . So the idea that one can print ALL the components needed for a firearm is ridiculous. You can print the composite parts that do not see much heat but where the bullet goes will need machining not printing.

If that will help you sleep at night go on believing it. In reality, though, other than a barrel, which is not controlled by the ATF, you don't need any machining. It is the barrel which is subject to heat and needs cooling, not the receiver which contains the loading and firing mechanism.

Don't get me wrong, this is a really bad idea. Until now, most at home users could make zip guns which weren't accurate past a few feet. These receivers, however, are fitted with real barrels and are every bit as lethal as commercial made guns. For a two to three thousand dollar investment, you can start cranking out all the receivers you want. Just add your own stock and barrells and nobody is the wiser.

The problem is that for firearms you need metal for the part that handles the bullet and the hot gasses in exess of 2000 degress K . So the idea that one can print ALL the components needed for a firearm is ridiculous. You can print the composite parts that do not see much heat but where the bullet goes will need machining not printing.

Maybe, but these objects are an order of magnitude faster than an RPG round. And they work by firing off a charge to intercept the incoming round. You think the debris problem is bad not? Try setting off a few of these in the ISS's orbit. "Cleanup in aisle 5"...

Yes, the anti-missile grenade systems (like Russia's and Ukraine's ARENA and Drozd, and Israel's Trophy) are not a very good fit. These systems cannot deflect anything moving faster than a few hundred meters per second. I was thinking more in terms of the Electric Effect armor, Explosive Reactive armor, and "spoiler screens" which utilize the Edge Effect (these could be very useful when used in conjunction with whipple shields, since they induce tumbling in the threat, which means part of the threat is moving faster and is therefore interacting more energetically with the whipple shield).

I don't buy the argument (which has been posed all over this discussion) that firing projectiles makes the debris problem worse. The projectiles are moving very fast (and we can make them move as fast as we need), and will therefore be boosted into a significantly different orbit than the spacecraft firing them. The hubble is moving at about 7000 m/s, so let's use this as an example. Explosively-forged projectiles can be fashioned to launch its penetrators at this velocity easily. If you adopt a policy of just firing them towards the fore and aft of your orbit, then the penetrator will be boosted to either zero orbital velocity (in which case it will plummet straight down to the Earth), or to twice your velocity (in which case it's way the hell out there).

That's an extreme case, but projectiles launched using more conventional means (powder propellant) can still be made to move 2000 m/s or so, which should also be enough to put it in a sufficiently different orbit to not be a worry.

We'd need to be careful to make it work, but that's why engineers are paid to do careful work.

-- TTK

qv: Whipple Shields

The idea behind whipple shields is that you put several thin barriers in front of a hypervelocity threat, and the shock waves induced inside the moving body (from rapidly loading and unloading it with compressive forces) tears it apart. What emerges from the other side of the whipple shield is a cloud of dust rather than a rock (or steel bolt, or whatever), and this cloud of dust is incapable of penetrating the side of your spacecraft.

The document linked above describes research which demonstrates that the strength and thickness of the individual barriers is much less important than the number of barriers, and the ratio of barrier thickness vs space between the barriers. Thus whipple shields can have extremely high mass efficiency against hypervelocity threats, equivalent to 0.6 of the same thickness of hardened steel. A foamed polystyrene solution (where the cell foam wall thicknesses are tuned to the correct ratio of foam cells' widths) could therefore provide the same level of protection as ~135 times its weight in hardened steel plate.

This technology is being actively developed for protecting battletanks from shaped charges (which generate explosively-formed penetrators moving at high hypervelocity speeds of 8,000m/s and more), but its relatively low thickness efficiency (0.6x, as opposed to ~3x-4x for some modern composite armor systems) limits its usefulness in this role, as battletanks have limited space to play with. Spacecraft are much less limited in this respect.

Other so-called "Active Defenses" developed for battletanks might also be applicable.

-- TTK

qv: Whipple Shields

The idea behind whipple shields is that you put several thin barriers in front of a hypervelocity threat, and the shock waves induced inside the moving body (from rapidly loading and unloading it with compressive forces) tears it apart. What emerges from the other side of the whipple shield is a cloud of dust rather than a rock (or steel bolt, or whatever), and this cloud of dust is incapable of penetrating the side of your spacecraft.

The document linked above describes research which demonstrates that the strength and thickness of the individual barriers is much less important than the number of barriers, and the ratio of barrier thickness vs space between the barriers. Thus whipple shields can have extremely high mass efficiency against hypervelocity threats, equivalent to 0.6 of the same thickness of hardened steel. A foamed polystyrene solution (where the cell foam wall thicknesses are tuned to the correct ratio of foam cells' widths) could therefore provide the same level of protection as ~135 times its weight in hardened steel plate.

This technology is being actively developed for protecting battletanks from shaped charges (which generate explosively-formed penetrators moving at high hypervelocity speeds of 8,000m/s and more), but its relatively low thickness efficiency (0.6x, as opposed to ~3x-4x for some modern composite armor systems) limits its usefulness in this role, as battletanks have limited space to play with. Spacecraft are much less limited in this respect.

Other so-called "Active Defenses" developed for battletanks might also be applicable.

-- TTK

Normally I don't feed the trolls, but taken at face value your request is reasonable, so ..

http://www.petabox.org/ (note contributors list on left)

http://www.ciar.org/ttk/images/petabox/

http://workstation20.archive.org/ttk/tools/manifes ting

http://workstation20.archive.org/ttk/tools/researc h

http://workstation20.archive.org/ttk/wp/

http://workstation20.archive.org/ttk/wp/software/2 006-04-11/

My Resume

-- TTK

Normally I don't feed the trolls, but taken at face value your request is reasonable, so ..

http://www.petabox.org/ (note contributors list on left)

http://www.ciar.org/ttk/images/petabox/

http://workstation20.archive.org/ttk/tools/manifes ting

http://workstation20.archive.org/ttk/tools/researc h

http://workstation20.archive.org/ttk/wp/

http://workstation20.archive.org/ttk/wp/software/2 006-04-11/

My Resume

-- TTK

It's been almost exactly two years since we put together the first petabox rack, and both the technology and our understanding of the problem have progressed since then. We've been working towards agreement on what the next generation of petabox hardware should look like, but in the meantime there are a few differing opinions making the rounds. All of them come from very competent professionals who have been immersed in the current system, so IMO all of them are worthy of serious consideration. Even though we'll only go with one of the options, a different option might be better suited to your specific needs.

One that is a no-brainer is: SATA. The smaller cables used by SATA are a big win. Their smaller size means (1) better air flow for cooling the disks, and (2) fewer cable-related hardware failures (fewer wires to break, and more flexibility). Very often when Nagios flags a disk as having gone bad, it's not the disk, but rather the cable that needs reseating or replacing.

Choosing the right CPU is important. The VIA C3's we started with are great for low power consumption and heat dissipation, but we underestimated the amount of processing power we needed in our "dumb storage bricks". The two most likely successors are the Geode and the (as-yet unreleased, but RSN) new low-power version of AMD's dual-core Athlon 3800+. But depending on your specific needs you might want to just stick with the C3's (which, incidentally, cannot keep gig-e filled, so if you wanted full gig-e bandwidth on each host, you'll want something beefier than the C3).

It has been pointed out that we could get better CPU/U, disks/U, $$/U, and power/U by going with either a 16-disks-in-3U or 24-disks-in-4U solution (both of which are available off-the-shelf), compared to 4-disks-in-1U (our current hardware). This would also make for fewer hosts to maintain, and to monitor with the ever-crabby Nagios, and require us to run fewer interconnects. Right now it looks like we'll probably stick with 4-in-1U, though, for various reasons which are pretty much peculiar to our situation.

I heartily recommend Capricorn's petabox hardware for anyone's low-cost storage cluster project, if for no other reason than because a lot of time, effort, brain-cycles, and experimentation was devoted to designing the case for optimizing air flow over the disks (and figuring out which parts of the disks are most important to keep cool). Keeping the disks happy will save you a lot of grief and money. When you're keeping enough disks spinning, having a certain number of them blow up is a statistical certainty. Cooler disks blow up less frequently. Most cases do a really bad job of assuring good air flow across the disks -- the emphasis is commonly on keeping the CPU and memory cool. But in a storage cluster it's almost never the CPU or memory that fails, it's the drives.

Even though the 750GB Seagates appear to provide less bang-for-buck than smaller solutions (400GB, 300GB), the higher data storage density pays off in a big way. Cramming more data into a single box means amortizing the power/heat cost of the non-disk components better, and also allows you better utilization of your floorspace (which is going to become very important, if you really are looking to scale this into the multi-petabyte range).

When dealing with sufficiently large datasets, silent corruption of data during a transfer becomes inevitable, even using transport protocols which attempt to detect and correct such corruptions (since the corruption could have occurred "further upstream" in the hardware than the protocol is capable of seeing). We have found it necessary to keep a record of the MD5 checksums of the contents of all our data, and add a "doublecheck" step to transfers: perform the transfer (usually via rsync), make sure the data is no longer being cached in memory (usually by performing additional transfers), and then recompute the MD5 checksums on the destination host and c

Just a little nit to pick: Drozd has been deployed on T-55 and T-80 family tanks, but T-90 uses the newer ARENA system. Also, using ARENA precludes mounting Explosive Reactive Armor modules, the latest versions of which are useful against APFSDS threats (which Drozd and ARENA are not), so it's not exactly a silver bullet.

ObPlug: more on various kinds of active defense systems can be found on this page.

-- TTK

Google on "tank armor" and my site pops right up. I spend a lot of time researching tank technology, especially composite armors, both online and in print. Much of my effort is spent on Russian, Ukranian, and German websites, patent filings, and company brochures. The International Journal of Impact Engineering is great when I can get it, but there's a wealth of information to be mined from analyzing the latest German innovations, or the flood of ex-Soviet designs previously hidden behind the iron curtain, now revealed to the west for the very first time.

German defense engineers are masters of the composite armor arrangement. Being a western country, they have access to highly precise fabrication facilities and the most advanced technical materials money can buy, and they have the money to buy it. Seeing what they buy, how they shape it, and how much they put where is invaluable to my interests.

Russia and Ukraine, on the other hand, faced the prospect of fighting NATO on a shoestring budget. Their materials were modest, and they couldn't rely on their manufacturing facilities to consistently produce high-precision machining of components, but their engineers were (and continue to be) top-notch. They accepted the limitations of the materials and tools they had to work with, and found ways to arrange relatively humble metals, ceramics, and plastics such that they synergistically produced very advanced composite armor effects. They designed their armor systems such that they would continue to provide high levels of protection even if the factory mass-producing them couldn't weld a straight line to save their lives. While engineers in the west pushed the limits of what factories were capable of producing, often with disasterous results (qv the failed joint German/American MBT-70 project) their eastern counterparts made damn sure their own designs could be churned out quickly, cheaply, and in vast numbers (exceptions like the T-64/T-80 family notwithstanding). This holds special appeal to me because these are armor effects that can be replicated in a humble home workshop, using inexpensive commodity plastics and ceramics. If I don't measure it perfectly well, or the edges don't line up quite right, hey! It still works! That is more valuable to me than some super-advanced design that would take $1000/lb and a bunch of unobtainable federal licenses before I could even consider putting tab A into slot B.

Besides lots of oil, orphans, and bodybags, one of the things Americans found in our latest tragic military misadventure was a bunch of tanks which had been upgraded with armor modules purchased from Russia and welded into place in Iraq. These modules had been encountered in the 1991 war, but for some reason detailed analysis of these modules' composition didn't see the light of public attention until now. These "Enigma" armor modules repeatedly resisted the shaped charge warheads of Dragon and Milan anti-tank missiles and the depleted uranium projectiles issuing from 30mm Bushmaster autocannons, though they did not fare so well against Abrams' 120mm main guns. Still, that's not bad at all for a relatively lightweight steel box welded onto the turret of a forty year old tank (the T-55). Enigma modules were pried loose and cut open, and do you know what was found inside? Simple layers of steel, natural rubber, and construction-grade aluminum, with airgaps between each three-layer array. Some boxes were missing a layer or two here and there, and the adhesion between layers was sloppy at best. This was an example of the soviet bulging armor, doing what it does best, on the cheap. The effect this combination produces belongs in the realm of rocket science, but putting the boxes themselves together hardly takes a highschool diploma.

American armor engineering s

I would use this to connect 10Ge switches together, not to connect directly to individual servers in the network. Three 32-port 100Ge switches, linked to 32 32-port 10Ge switches by three links (ie, so each 10Ge switch had three links to different 100Ge switches and one link to each of 29 hosts) would allow any two hosts in a 928-node cluster to communicate at full 10Ge capacity (or, more likely, communicate with any number of hosts in that cluster at 10Ge aggregate capacity).

Something like this: 928 node network

-- TTK

Have you ever heard of the term "circumstantial evidence"? Google it.

Or, even better, Research It! :-)

-- TTK

Capricorn pre-installs our setup (archive.org) on the redboxes they sell us (slightly customized Debian, reiserfs3 on each disk, no filesystem abstraction, wrapped in rsync modules for access and Alexa UDP locator for indexing), but last I heard they will negotiate with customers to install whatever OS they want, and I presume with any abstraction solution they want (RAID at the per-node level, or not; OpenAFS for cluster-wide abstraction, whatever). So if you want FreeBSD/OpenAFS, that's doable, or if you want Windows, I'm sure they'll accomodate you there too.

The disks in the redboxes may appear to miss the optimal space-per-unit-price ratio, but really when you factor in physical compactness, data-per-unit-heat, these disk's robustness, and data-per-complete-system, they're very very good for a mass data warehousing solution, where physical space and power/cooling requirements count. The VIA C3's and VIA motherboards are extremely low-power systems, but iirc the disks make up the majority of each node's wattage appetite. It's a good system, and CR (the chief hardware engineer, and founder of Capricorn) has reason to be proud.

BTW, if someone has the desire and money to build a data warehousing cluster, but not the expertise, I'm available for contracting gigs.

-- TTK

lack of good automatic package management, [..] lack of all the advanced stuff like Project Utopia

By omitting nonessential bells and whistles, Patrick Volkerding doesn't have to waste his time and energy QA'ing them. He puts more QA hours into features essential to the operation of a production server, instead. This is of critical importance. QA effort cannot entirely eliminate the bugs and incompatabilities within and between packages, but the more hours are spent doing it the closer the distribution can get to this ideal form. Stability and security are the most essential characteristics of a production server.

lack of newbie-friendly administration tools

Don't need them. You may be right that their absence has prevented newcomers from adopting Slackware, though. It would be nice if more companies based their services on Slackware machines -- their services would be more robust, my skills would be more in demand :-) and it would result in more third-party QA'ing of Slackware packages. But I can't bring myself to care too much because the more popular Slackware has become over the years, the more packages Patrick has agreed to incorporate into the distribution to satisfy a wider audience. "More packages" is bad because ...

the relatively small selection of official packages

"More packages" is bad because the number of relations between packages increases in proportion to the square of the number of packages, and the number of incompatabilities between packages is proportional to this number of relations. The smaller the package set, the more effective Patrick's QA hours are at weeding out incompatabilities in the distribution as a whole. In fact I think Slackware has gotten somewhat overbloated with packages, and would welcome a little trimming of the fat. (Of course, what I consider fat might be necessary to someone else's business, so perhaps it's best that this is left up to Patrick, who gets a more gestalt picture.)

As an aside, I suspect what is hurting Slackware's wider adoption the most are its de-emphasis on desktop environments (it actually does pretty well at this, just not as well as some other distributions) and the popular misconception that the newest possible version of software is necessarily the best. In my experience, the decision to press a distribution into production service is often driven by what the IT elite at the company have running on their desktops. (This is more true in small companies, and less true in larger companies, where issues like availability of support by contract are more important. Though, here too Slackware comes up short.) Since Slackware holds little appeal to the desktop user, it does not take advantage of this vector. Also, since Patrick follows the sound, traditional practice of selecting for inclusion only those versions of software which are stable, the software which ships with Slackware is usually not the newest. If you look at the Slackware changelog, you can see various notes of the form "foo version x.y.13 exhibited such-and-such problems, reverted back to foo version x.y.12". Which is the way it should be done.

Inserting gratuitous plug here for my Code of Engineering.

-- TTK

December 1994
Apple Computer sues San Francisco Canyon Company for using Apple Computer's QuickTime code to speed up Microsoft's Video for Windows product.

Interesting comments regarding RAID. They seem to defy common sense, but common sense is not always correct.

Yeah, though I'm not necessarily correct, either. There are plenty of smart IT professionals who disagree with with The Archive's conclusions regarding RAID. It may just be a contextual thing -- our data storage clusters are friggin' huge, and we only have three sysadmins, two of whom work part-time. A smaller system with more manpower and better discipline about following good procedures may fare better with RAID than we have.

Just out of curiosity, why did you end up going with your third choice for OS (Debian) rather than your first or second choices?

What I listed were my personal choices. At my own company (which only has two employees, one of them me) we use Slackware, and I periodically make sure all our software will "just work" on FreeBSD and Solaris, just in case we need to switch. But the PetaBox program at The Archive is/was very much a group effort. What I said about "go with what you know, go with what your supporting friends know" applies to business use as well. Joerg, our chief sysadmin, knows and likes Debian a lot, and had already put in a good chunk of effort on his own time tweaking a Debian box to play nicely in The Archive's larger framework. Our other sysadmins liked Debian okay, and at least knew a little more about it than Slackware (which is very old-school BSDish in ways). Brewster and Jon, two very important individuals at The Archive, were very much enamored of Debian's apt-get packaging system. FreeBSD wasn't even on the map; The Archive is very much Linux-centric.

Given all that, when I was told to go make the architectural decisions on this new cluster, Debian seemed like a no-brainer. I didn't even waste our time trying to convince anyone that we should go with anything else. I'm fairly nonpolitical about technology, but a lot of people feel very strongly that their choices are the only good choices. Debian was acceptable to everyone who needed to be able to work on the new systems, and choosing it meant that everyone could slide easily into development and administration without kicking up any fuss. I hate it when engineers argue, and am very much willing to suppress my own ideas about what constitutes a "best direction" and throw my support behind someone else's good idea, if it means the team can pull together and do what engineers are supposed to do. (qv this page outlining my philosophies on engineering.)

All in all, Debian was not a bad selection. It is a good, solid distribution, and it has served us very well.

-- TTK

When we developed the PetaBox at The Archive, the idea was to use off-the-shelf PC hardware and maximize GB/buck, while keeping cooling and power costs low. It's worked out pretty well. See also my unofficial PetaBox web page.

It turns out that you really don't need much of a PC to serve files. We underclocked the cheap little Via C3 processors to 800MHz to reduce power and heat, and they still troop along nicely. SATA is not necessary, since you're going to be bottlenecked on the network connection anyway. We used 512MB of RAM per node, but only because our system runs a gaggle of perl scripts to provide a variety of services (file searches, XML-based metadata updates, etc). If you're just going to be running NFS or Samba, 256MB is probably plenty (unless you choose to run Gigabit over a mere 32-bit PCI bus, in which case 512MB or 1GB would be better, so that you're reading more from filesystem cache and pounding the hard drives over your overloaded bus less). Gigabit ethernet is a must (we used 100bT for the PetaBox, which is annoying at times, but the cheaper 100bT 48-port switches were instrumental in keeping the overall price of the system low). We stuck four hard drives in each case, mostly from previous bad experiences trying to work with eight-disk machines. I can't say too much about the disk failure rate statistics which incited us to switch to Hitachi Deskstars, but I will say that I'm glad our PetaBox is using Deskstars and I will only use Deskstars in my workstation at home.

If you really, really want to keep the gigabit pipe full while pounding on your disks, then a newer bus like PCI-Express is necessary. Otherwise, I'd be tempted to go with an older, cheaper (and imo, more reliable) Pentium-II or -III based PC. You can get solid, reliable, well-cooled and well-dustfiltered early model VA Linux servers with 500MHz Pentium-III's for $200 or less. I must stress the importance of buying a really solid, rigid case. Over time, normal computer cases get all bendy-wendy, turning every part into a moving part, including parts you don't want to have moving at all. Fans will start sticking, motherboard traces will start breaking, etc. Most of the rack-mountable cases are made of good thick solid steel panels, which makes them heavy as f**kall, but IMO that's a small price to pay for a system that will run forever.

For operating system, the most important thing is to get something you know how to run and maintain, or can get help running and maintaining. If you have geek friends who are willing to provide technical assistance, find out what they know best and use that. A well-known operating system will probably be of more use to you than a technically better, but less well understood, operating system.

Having said that, my personal preference is Slackware Linux, because I appreciate its philosophy of keeping things simple, and preferences for packages which are the most stable, as opposed to newest versions or lots of features. My second choice would be FreeBSD. Third would be the OS we decided to use at The Archive for the PetaBox nodes, Debian Linux. But if all you know is Windows, then go ahead and use Windows.

Regarding RAID, it's been my experience working at The Archive that RAID is often more trouble than it's worth, especially when it comes to data recovery. In theory, recovery is easy, you just replace a bad disk and it will rebuild the missing data, and you're good to go. In practice, though, you will often not notice that one of your disks are borked until two disks or borked (or however many it takes for your RAID system to stop working), and then you have a major pain in the ass on your hands. At least with one filesystem per disk, you can attempt to save the filesystem by dd'ing the entire raw partition contents onto a different physical drive of same make + model, skipping bad sectors, and then running fsck on the good drive. But if you have

Hopefully he changed some hardware in those 9 years, It'd be painful to run WinXP on a Pentium 75MHz...

How many bits worth of unpredictable information, exactly, is in a fingerprint? I know it's "a lot", but is it enough? 48 bits is "a lot" too, but it has been demonstrated to be not enough for protection against a simple brute-force attack.

Ultimately, it's all just bits. This fingerprint-recognition device ultimately must convert your fingerprint into a binary key, and use that key to perform the encryption/decryption. If someone can get a copy of your encrypted data, they could run it through software which tried binary keys until it found the right one. If the adversary could lift your fingerprint from something you've touched, that might give them information which helps them narrow down the search.

Until I found out just how many keys they'd have to try before exhausting the keyspace, I wouldn't trust this to be secure. A good mixed-case/numbers password with a - or ! (et al) thrown in can easily have 67**8 > 48-bit strength. A 5-word english passphrase can have up to 38619 ** 5 > 76-bit strength (38619 words in /usr/dict/words, and that's assuming no case variations). For very secure stuff, I'll keep a 1024-bit RSA keypair on a floppy disk in my lapel (no, I'm not just being a smart-ass, I already do this.)

Seriously, though, does anyone know the strength of a key generated by Acer's gizmo? And how much it might be narrowed down with a sample fingerprint to work from?

-- TTK

As you point out, UNIX worms have existed in the past which (at a very high level) looked and behaved similarly to these recent Windows worms. Such a thing could easily happen again; while the quality of UNIX security (and Linux security, too) is heads and shoulders above that of Windows, there are still root exploits for various UNIXes being posted regularly to security mailing lists, and in fact recently our local geek community over here in the bay area noted a slew of attacks (manual, it looked like, not by worm) on Linux systems, trying to exploit a known buffer overflow bug in identd.

That is not to say, however, that we cannot learn from the more recent worms. If nothing else, the sheer scale of the traffic and number of hosts involved puts fighting these beasties into a different domain. Mainstream use of the internet is at an all-time high, and the average competence of those running the internet is at an all-time low. Look, for instance, at @Home's incompetent response to Code Red, and at all of the hosts which still do not have the IIS security hole plugged, months after the attacks commenced, despite a security patch having been offered by Microsoft for any and all to use. This is what we can learn from, and we'd better do it quick before we find ourselves having to learn on the fly.

-- TTK

I keep a bunch of articles and other documents of topics related to this article's here:

http://www.ciar.org/~ttk/techsing/

I'm doing my part -- here .

I hope others in the audience will do their part as well.

-- Guges --

There are good reasons for using smaller address words, caching efficiency chief among them. On systems which run their filesystems fully-asynchronously (like linux), filesystem caching efficiency is a primary factor in limiting performance for filesystem-intensive applications. When your file data set exceeds main memory's ability to cache it, performance can plummet like a stone. If your filesystem cache metadata takes up 25% more space because you are using 64-bit address words instead of 32-bit (64 bits is 100% larger than 32 bits, but metadata records contain a lot more than just address words), then your maximum cacheable filesystem is only 80% (1.0/1.25=0.8) what it could have been.

Even with small data set sizes, this can mean a lot, because you see performance degradation when you spill L1 cache, and another when you spill L2. It's a lot easier to get 25% more compact metadata than it is to get 25% larger L1 and L2 caches!

What makes the most sense is to design our operating systems to be able to treat filesystems as large (2+ TB) or small (2- TB), and use cache data structures to match. That way we'll have higher performance in the "common case", and corporations who need to be able to support (eg) huge databases will be able to do so.

For the past few years, hard drive data density per dollar (in best density per dollar products, not top or bottom of the line products) has been increasing exponentially at a rate of 2.15x per year. If we project that naively and assume it holds steady (which is unlikely, so take this with appropriate salt) then we should expect to bump into the 2 TB limit on our home desktop computers in about 10 years. To me, that makes filesystem-segmented 32-bit sector addressing "good enough" for a good long time.

(I have been tracking hardware trends since the early 90's; the past two years' worth has been collected automatically via web-bot from the same vendor, so it is easily indexable .. I hope to enter my hard-copy data some day as well, but what a pain! I have made parts of it, from 1999-01-05 to 2000-09-12, available on my web site here. Collection is ongoing, and I'll refresh the web site from the master records sometime too.)

-- Guges --

If you only ever read one paper about gun control, it really should be this one !

It is an excellently researched, formal, academic study of the data in support of both sides of the gun control debate, from the University of Chicago law school.

-- Guges --

Those statistics were contrived by gun control advocates, and have been pretty thoroughally debunked .. qv:

debunking the "43 times" fallacy

-- Guges --