I believe that the number of worthwhile applications that can be developed at a given price point is increasing exponentially, and that the pool of talented man-hours with which to develop interesting applications is only increasing polynomially, worldwide. Thus there is an exponentially increasing set of worthwhile applications which will never be developed.
This conviction has led me to view development decisions as exercises in dooming some applications to never be developed, ever, in the entire future history of humankind, as I choose to develop other applications.
I'd like to scrape together a formal proof of this someday, but until then it is only a theory.
Unixes and the services that run on them can be configured to be very verbose in their errors and warnings, and error messages can be used as triggers to check various logs and system states for additional information, but in a nontrivial cluster there are major problems with humans trying to digest this flow of information and make sense of it all.
Better tools help, but beyond a point it just makes sense to try and make the tools themselves react correctly to the symptoms and correct the problems.
This Sun guy's article overlooks the existing mechanisms and methods already available for implementing self-healing systems (though, he's spot-on regarding the need for better abstraction). Hmmm, I write these kinds of tools at The Archive, maybe I should write my own article?
Regarding the "how do you know the monitor is healthy?" issue: you never really know, but you can have the monitor monitor itself and fairly reliably diagnose many of its own problems, and/or have pools of monitoring peers (qv keepalived), and start with "gentle" solutions which won't hurt anything (much) in the case of a misdiagnosis, and ramp up from there.
My wife likes the show, so I've seen a lot of half-episodes.
What I don't like about it is that it depicts police as honest and hard-working, and our justice system as competently run and fair.
Too many people are unable to differentiate between reality and fiction, so the popularity of this show is generating a lot of false faith in our system, which is chronically corrupt, incompetent, oppressive, and unfair.
Today, ftp is not considered p2p, because of the strong delineation between servers and clients, but this delineation was not always so strong.
Once upon a time, almost any computer connected to the internet could be expected to have ftp, and an ftp daemon which allowed others to upload/download files. There was not this "a few servers run ftpd / many clients run ftp" asymmetry. It was a de facto peer-to-peer environment.
In a sense, the surge of p2p technology is a reclosing of the client/server gap, using more up-to-date user interfaces and protocols (eg, incorporating now the ability to search for interesting hosts; it sure beats grepping 'w' on the school server and trying IP's at random).
-- TTK
It sounds like a crock
on
Replacing TCP?
·
· Score: 3, Interesting
I'd still like to see a good protocol that doesn't require in-order packet receipt in addition to the changes that they mentioned; when transfering large volumes of data, why not?
This is exactly why FTP uses UDP for its data transfer. So use FTP. In the last decade, though, improvements to TCP stacks have mostly mooted this difference. Once upon a time, when one end of a TCP transfer NACK'd a packet, it meant that packet and every packet after it would need to be re-sent (even those which had been sent already). So if you send packets 100, 101, 102 and then get a NACK for 100, you'd have to send 100, 101, 102, 103, etc. But with modern implementations, the receiver would keep packets 101 and 102, so the sender only needs to re-send packet 100, and then proceed to packet 103. This has made TCP much more efficient over lossy networks. Deferred NACKs also deal well with the problem of out-of-order packet arrival, when tardy packets show up before the deferred NACK is transmitted.
I'm very dubious that these folks' protocol can realistically replace TCP; it simply doesn't add any must-have qualities. The only place where I see an advantage is transmitting audio and video, where you don't necessarily want to retransmit lost data, and are willing to put up with minute gaps in the data stream.
A transport protocol that really deserves more attention is TTCP (TCP for Transactions). It abbreviates the TCP connection handshake, which makes it much more efficient / better-performing for very short transactions (like typical HTTP usage).
This post really deserves to be modded up. Kudos, Jtheletter!
-- TTK
(Slashdot needs a function for transferring points from one of my own posts to someone else's.)
Re:Except Animals are more likely to be right.
on
Good Bad Attitude
·
· Score: 5, Insightful
Maybe it will not be the same, but this "slippery slope" falicy that so many
people call upon when they look at the compramises that are made in our name
will not be our end. As long as we're alive, there's hope that things will
get better, and there is always something we can do, even if it's small, to
make the world a better place.
I think you've put your finger right on it. If we value freedom, if we love
liberty, then every year should see more freedoms, less restriction on our liberty,
than every year preceeding it. There is far too much oppression in our society as
it is. We aren't on a "slippery slope", we're already here! The situation is
intolerable right now, and has been for some time!
And yet we are regressing! Despite our hopes for improvement, life in
America is worse than it was last year, and worse still than the year before that!
Compromises? That is putting all too pleasant a face on the degeneration that has
afflicted our lives. The politicians are leading us to hell by our noses, and all
we do is try to be polite about it.
The best thing we can do to make the world a better place is strike their hand
from our face, turn around, and walk the other way into a better future.
How hard would it be to have web + database content on an encrypted filesystem, unlocked on demand by application of a password via SSH connection from a privately owned computer (say, in someone's bedroom in the United States)? It seems doable with a simple perl script. (And a short perl script, at that.)
There are lots of ways to approach it, but I'd do it this way:
On startup, each web server runs an rc script which contains the line: "wget [url_of_homebase]/unlock_me.cgi". Maybe there's also a cron job which periodically checks to see if the encrypted filesystem has been mounted yet, and runs that command when it is not.
On the CTO's home machine,/var/www/cgi-bin/unlock_me.cgi makes an SSH connection back to the requesting host, runs the command that decrypts the filesystem, mounts it, and erases its command history. Perl's SSH module, and sshd's passwordless authorized_keys mechanism, make this pretty trivial.
Encrypted filesystems have been available for a while now. They're strictly off-the-shelf technology.
The first reply to your post lacked references to civil forfeiture informational sites. Here's a good site: Civil Forfeiture Laws
Unfortunately, what there is to learn about civil forfeiture, you have already surmised: the government has granted itself free license to steal anything you have, with very little justification. If a law enforcement officer thinks you're carrying too much cash, they can take it (on the assumption that the only thing large sums of cash are good for is illegal purchases). They can take your house, your car, your computers, and anything else which might have been involved in a hypothetical illegal transaction.
They need no proof, since technically it is your property which is being accused, and not yourself (I am not making this sh!t up), and while you are not without recourse (some people have actually regained their property, after much hard work and expensive legal action), your chances for recovering anything are slim.
This is just one example of civil rights being in free fall in America, and it all happened years before 9/11 and the PATRIOT Act. Don't bother telling anyone the sky is falling; the sky has fallen, kaput, finis, it's all over.
IRC always seemed overflowing with juvenile h4xx0r wannabes. All the "cool kids" (the FreeBSD development group, UNM geeks, Santa Cruz geeks, etc) hung out on Internet Citizen Band servers. ICB was also developed in the 1980's, but never took off like IRC did. ICB geeks generally agree that this is a good thing -- a high quality clientele makes for a more pleasant experience than high quantity.
ICB's ease-of-use and relative simplicity was also a huge win, over IRC's poorly-implemented oodles of features, IMO.
The folks developing the next-generation ICB have also been going with an XML-based protocol. I guess that's the trend these days; people seem to think this syntactic sugar is the best thing since sliced bread.
Actually, hard drive storage densities are increasing much more quickly than that.
I've been tracking hardware price trends for a few years, and hard drive data densities have increased exponentially, but on a changing exponent.
From the late 1980's to the mid 1990's, the rate was about 1.6x per year. Around 1996 the annual rate of increase climbed to 1.8x, then 2.0x, to a peak of about 2.2x/year until the "dot bomb" around 2001, which knocked it down to 1.4x for a while. It has since climbed back up to about 1.6x/year. (I'm not sure why the dot-bomb had this effect.)
If we assume, naively, that it will continue to increase at a mere 1.6x/year, then we should be seeing 6+ TB hard drives by the year 2010, easily. That is, imho, a conservative estimate.
On the other hand, there are any of a number of things which might change the commodity hard drive market (for instance, the advent of thumbdrives which are "good enough" for the masses, leaving only the corporate market for hard drives). So pop some popcorn and pull up a lawnchair, and we'll see what hapens.
> Stakes ? What stakes ? Democracy isn't a lottery. You don't get > a prize if you happen to vote for the guy that wins.
Yes, you do. The way politics works in this country is that a political party panders to the interests of certain demographics in return for political and financial support. In return, the politician who gets elected into the office uses their position of power to benefit those who put them there.
In the case of executive officers, payback includes granting of contracts (such as those to halliburton), reforming agencies responsible for giving or taking resources (such as the SSD or IRS), refraining from enforcing select laws (such as environmental protections), and rigorous enforcement of other laws.
In the case of legislative officers, payback consists of drafting and passing laws which would benefit the supporters, if enforced.
If you vote in Bush and other republicans, you "win" things like bigger defense contracts granted to companies like GM GDLS Defense Group and Firestone, the gutting of social security, the neglect of environmental protections, elevation of christian charities to federally sanctioned institutions, and the overenthusiastic enforcement of drug control laws.
If you vote in Kerry and other democrats, you "win" things like larger subsidies to automobile manufacturers, the glutting of social security at the expense of taxpayers, elevation of minority races and noncitizens to preferred status, increased funding of public education, aggressive erosion of the right to keep and bear arms, cuts in defense spending, and increases in the minimum wage.
"To the victor go the spoils" -- today as much as always.
Games is why I use FreeDOS on my laptop (dual-boot with Slackware 9.1).
What I have on it now, which works: Boloball, Bridge, Checkkers, Civilization, Hexjump, Texas Hold'em, Battle for Atlantis, VGA Joust, Larn, Bugs, Othello, Starcon-1, Wari, WarZone, XCom, XCom Terror from the Deep.
What doesn't work: Warcraft-2.
What I have somewhere but haven't installed/tried under FreeDOS yet: Warcraft-1, Descent-I/II/III, Quake
-- TTK
Re:Difference between GFS, NFS and AFS?
on
Red Hat announces GFS
·
· Score: 3, Informative
I don't know much about AFS, but two significant differences between NFS and GFS:
GFS supports a global file locking interface; NFS does not. So for instance you can have a farm of web servers whose cgi scripts access/update shared files atomically, or multiple database servers which share the same database file, locking individual records to perform simultaneous INSERT/UPDATE transactions.
GFS supports host-granularity redundancy and failover; NFS does not. So if your NFS server bursts into flame, the filesystems it was exporting go away everywhere on your network, but your GFS systems can have two or more hosts exporting the same filesystem. This provides security not only against spontaneous combustion and other disasters, but also scheduled down-times. IT can power down one GFS server to replace a hard drive or move it to a different room, and the backup GFS servers will keep the exported filesystem available without interruption.
If GFS is more scalable/reliable than NFS, that would be nice, but I don't yet know if it does.
NFS also has some scalability problems. It is not a suitable mechanism for several hundred hosts to make their filesystems simultaneously available to each other. (Though, admittedly, I haven't seen anything that indicates that GFS does this either.)
It says the *license* under which you distribute it must make it available to third parties. The GPL does not require you to *distribute* the source code to anyone except those who receive the product in executable form. But because it is licensed to third parties, anyone in possession of the source code *may* distribute it to third parties.
Many of history's more excellent weapons were developed by individuals or small teams, not by corporations. John M Browning personally developed several weapons for the US Military. The Neostead combat shotgun was the work of two individuals not working for any company. The AK-47 was developed personally by Kalashnikov, and the Uzi was designed by Uziel Gal while staying in a Yagur prison.
Corporate arms manufacturers have not been a significant source of innovation in the past century. The US Army has tried to replace Browning's M2.50-BMG twice now with corporate models, and failed because the corporate teams could not get it right. Abrams tanks stationed in Iraq today still mount Browning's 60+ year old design (qv).
It is significant, I think, that the more advanced firearm designs of the last fifty years come from countries where individuals are free to develop new technologies, while America has remained stagnant under the shadow of draconian government regulations which make it nearly impossible for any individual to legally tinker with weapon design in the privacy of their own homes.
Do not underestimate the power of individual initiative and innovation.
It could definitely be made to work better than the current DNS system, albeit incrementally rather than revolutionarily (since DNS already incorporates some elements of P2P -- P2P isn't a new idea, it's just reverting back to the older client/server internet when most nodes running clients were also running servers.
We could use a system such that authority for a domain belonged to the holder of a hash value range, where the MD5 hash value of the domain fell between the bounds of that range. Hash ranges could be distributed and/or sold securely using public key authentication, so that internet users knew who the "real" owner of a hash range was. The hash owner would be both, the registrar for domains hashing into their range, and the source of authorative name resolution.
The initial distribution could spread the 64-bit hash range across say 128 servers, across multiple countries and independent of government or other institutional authority. From there it would be up to the hash range holders how much to charge for registration and/or access, and to sell or give away subranges of their hash range, or not, under whatever license they like. It would make for a more libertarian/anarchic solution than the current top-heavy politically authoratorian system.
> The only organizations affected by this are those who chose
> to use a service that acts as a single point of failure.
And that "organization" can be as fine-grained as you want it to be. If your desktop PC is running a *nix, setting it up to act as its own caching DNS server is a fifteen minute process. If your desktop PC is not running a *nix, then old 586's can be had for $20 which can run a *nix and sit on your LAN, functioning as your local caching DNS server.
This one-page HOWTO tells you exactly what you need to do (in the cases of RedHat and Debian, down to the baby steps), with the exact contents of your configuration files:
If you are disallowed from having another dynamic IP by your draconian IT department, you can give the $20 *nix box a static 10.x.x.x and add it to your desktop's routing table and sidestep the entire issue.
You now have no excuse. Go make your internet more robust.
PetaBox v1.0 would have a formatted capacity of 937.4732544 * 10**15 bytes, but the first PetaBox is not going to be 10 PetaBox-v1.0 racks. It will probably be either 1 or 2 v1.0 racks and 8 or 9 v1.1 racks.
I cannot say for certain, but it is my understanding that PetaBox v1.1 will use slightly different models of hard drives than the ones used in this rack here. It would have a formatted capacity of about 1094 * 10**15 bytes.
(We've been putting this first rack through its paces, and have learned a lot. v1.1 will reflect that experience with a few minor tweaks.)
Fortunately, you are mistaken. The PetaBox employs ReiserFS (which would not have been my first choice, but I will work to any specification given to me), which is a fully journaled filesystem. It does very well recovering from unscheduled downtimes.
ReiserFS has thusfar shown itself a robust solution to this problem, but so would Ext3, and probably XFS (which I know little about, but Joerg here at the Archive likes a lot). You are thinking of Ext2.
> * the cooling system should be built into the structure, like > existing refigerant containers
There's been discussion/research at the Archive regarding exactly this:-)
> * not just data storage, but also computing facilities
Each petabox node is a completely functional ITX PC, running Debian Linux, so it is already also a computing cluster. It's not a very good one, unfortunately, because in the interest of keeping the heat and power down a very low-power processor was used, an 800MHz Via C3, which is marginal as an integer-intensive processor.
Also, the storage nodes (which comprise 796 of the 800 nodes) only have 100bT ethernet, which would limit the petabox's ability to efficiently make use of what processing power it does have (in the data distribution phase).
Nonetheless, 796 800MHz processors is nothing to sneeze at. When the PetaBox is being a PetaBox, its processors are mostly idle. I'm sure folks will figure out something to do with those spare cycles (or perhaps not, considering that exercising the processors noticeably increases the power and cooling burden).
Unlikely to be quite that soon.. there are 3200 disk drives in a completed petabox system. It would take about 12 doublings of disk drive density to put that much storage into a single drive.
Just before the dot-bomb went boom, hard drive storage was doubling at about 2.1x per year. A few years ago it was about 1.6x per year. So if we naively assume that improvements will continue as a geometric function of time, figure it will take between 12 and 18 years for a petabyte-sized hard disk drive to come to market.
We have a little experience with hard drive failures at the Archive:-)
The solution we've settled on is to make the data self-repairing, and make the hard drives fast and easy to swap in/out (but without driving up the per-node cost too much.. so no hot-swappable SCSI). So as disks blow up, a sysadmin replaces it with a new one, which gets re-filled with its previously-stored data.
As you might imagine, our investigations into the lifespans of different models of hard drives is ongoing:-) but I'm not sure of just how much I should say.. if I said "oh yeah, wee-dae-yung's WetTissuePaper-100 really sucks", would wee-dae-yung's lawyers show up and sue me (or the archive!) into oblivion?
I'm sure the information will get out there somehow, though.. if nothing else, there are anonymous channels.. (whistling an innocent tune)
Slashdot Mirror
I believe that the number of worthwhile applications that can be developed at a given price point is increasing exponentially, and that the pool of talented man-hours with which to develop interesting applications is only increasing polynomially, worldwide. Thus there is an exponentially increasing set of worthwhile applications which will never be developed.
This conviction has led me to view development decisions as exercises in dooming some applications to never be developed, ever, in the entire future history of humankind, as I choose to develop other applications.
I'd like to scrape together a formal proof of this someday, but until then it is only a theory.
-- TTK
That is more or less how things have evolved here at The Internet Archive.
Unixes and the services that run on them can be configured to be very verbose in their errors and warnings, and error messages can be used as triggers to check various logs and system states for additional information, but in a nontrivial cluster there are major problems with humans trying to digest this flow of information and make sense of it all.
Better tools help, but beyond a point it just makes sense to try and make the tools themselves react correctly to the symptoms and correct the problems.
This Sun guy's article overlooks the existing mechanisms and methods already available for implementing self-healing systems (though, he's spot-on regarding the need for better abstraction). Hmmm, I write these kinds of tools at The Archive, maybe I should write my own article?
Regarding the "how do you know the monitor is healthy?" issue: you never really know, but you can have the monitor monitor itself and fairly reliably diagnose many of its own problems, and/or have pools of monitoring peers (qv keepalived), and start with "gentle" solutions which won't hurt anything (much) in the case of a misdiagnosis, and ramp up from there.
-- TTK
My wife likes the show, so I've seen a lot of half-episodes.
What I don't like about it is that it depicts police as honest and hard-working, and our justice system as competently run and fair.
Too many people are unable to differentiate between reality and fiction, so the popularity of this show is generating a lot of false faith in our system, which is chronically corrupt, incompetent, oppressive, and unfair.
-- TTK
Before there was Napster or IRC, there was ftp.
Today, ftp is not considered p2p, because of the strong delineation between servers and clients, but this delineation was not always so strong.
Once upon a time, almost any computer connected to the internet could be expected to have ftp, and an ftp daemon which allowed others to upload/download files. There was not this "a few servers run ftpd / many clients run ftp" asymmetry. It was a de facto peer-to-peer environment.
In a sense, the surge of p2p technology is a reclosing of the client/server gap, using more up-to-date user interfaces and protocols (eg, incorporating now the ability to search for interesting hosts; it sure beats grepping 'w' on the school server and trying IP's at random).
-- TTK
I'd still like to see a good protocol that doesn't require in-order packet receipt in addition to the changes that they mentioned; when transfering large volumes of data, why not?
This is exactly why FTP uses UDP for its data transfer. So use FTP. In the last decade, though, improvements to TCP stacks have mostly mooted this difference. Once upon a time, when one end of a TCP transfer NACK'd a packet, it meant that packet and every packet after it would need to be re-sent (even those which had been sent already). So if you send packets 100, 101, 102 and then get a NACK for 100, you'd have to send 100, 101, 102, 103, etc. But with modern implementations, the receiver would keep packets 101 and 102, so the sender only needs to re-send packet 100, and then proceed to packet 103. This has made TCP much more efficient over lossy networks. Deferred NACKs also deal well with the problem of out-of-order packet arrival, when tardy packets show up before the deferred NACK is transmitted.
I'm very dubious that these folks' protocol can realistically replace TCP; it simply doesn't add any must-have qualities. The only place where I see an advantage is transmitting audio and video, where you don't necessarily want to retransmit lost data, and are willing to put up with minute gaps in the data stream.
A transport protocol that really deserves more attention is TTCP (TCP for Transactions). It abbreviates the TCP connection handshake, which makes it much more efficient / better-performing for very short transactions (like typical HTTP usage).
-- TTK
This post really deserves to be modded up. Kudos, Jtheletter!
-- TTK
(Slashdot needs a function for transferring points from one of my own posts to someone else's.)
Maybe it will not be the same, but this "slippery slope" falicy that so many people call upon when they look at the compramises that are made in our name will not be our end. As long as we're alive, there's hope that things will get better, and there is always something we can do, even if it's small, to make the world a better place.
I think you've put your finger right on it. If we value freedom, if we love liberty, then every year should see more freedoms, less restriction on our liberty, than every year preceeding it. There is far too much oppression in our society as it is. We aren't on a "slippery slope", we're already here! The situation is intolerable right now, and has been for some time!
And yet we are regressing! Despite our hopes for improvement, life in America is worse than it was last year, and worse still than the year before that! Compromises? That is putting all too pleasant a face on the degeneration that has afflicted our lives. The politicians are leading us to hell by our noses, and all we do is try to be polite about it.
The best thing we can do to make the world a better place is strike their hand from our face, turn around, and walk the other way into a better future.
-- TTK
How hard would it be to have web + database content on an encrypted filesystem, unlocked on demand by application of a password via SSH connection from a privately owned computer (say, in someone's bedroom in the United States)? It seems doable with a simple perl script. (And a short perl script, at that.)
There are lots of ways to approach it, but I'd do it this way:
On startup, each web server runs an rc script which contains the line: "wget [url_of_homebase]/unlock_me.cgi". Maybe there's also a cron job which periodically checks to see if the encrypted filesystem has been mounted yet, and runs that command when it is not.
On the CTO's home machine, /var/www/cgi-bin/unlock_me.cgi makes an SSH connection back to the requesting host, runs the command that decrypts the filesystem, mounts it, and erases its command history. Perl's SSH module, and sshd's passwordless authorized_keys mechanism, make this pretty trivial.
Encrypted filesystems have been available for a while now. They're strictly off-the-shelf technology.
-- TTK
The first reply to your post lacked references to civil forfeiture informational sites. Here's a good site:
Civil Forfeiture Laws
Unfortunately, what there is to learn about civil forfeiture, you have already surmised: the government has granted itself free license to steal anything you have, with very little justification. If a law enforcement officer thinks you're carrying too much cash, they can take it (on the assumption that the only thing large sums of cash are good for is illegal purchases). They can take your house, your car, your computers, and anything else which might have been involved in a hypothetical illegal transaction.
They need no proof, since technically it is your property which is being accused, and not yourself (I am not making this sh!t up), and while you are not without recourse (some people have actually regained their property, after much hard work and expensive legal action), your chances for recovering anything are slim.
This is just one example of civil rights being in free fall in America, and it all happened years before 9/11 and the PATRIOT Act. Don't bother telling anyone the sky is falling; the sky has fallen, kaput, finis, it's all over.
-- TTK
IRC always seemed overflowing with juvenile h4xx0r wannabes. All the "cool kids" (the FreeBSD development group, UNM geeks, Santa Cruz geeks, etc) hung out on Internet Citizen Band servers. ICB was also developed in the 1980's, but never took off like IRC did. ICB geeks generally agree that this is a good thing -- a high quality clientele makes for a more pleasant experience than high quantity.
ICB's ease-of-use and relative simplicity was also a huge win, over IRC's poorly-implemented oodles of features, IMO.
The folks developing the next-generation ICB have also been going with an XML-based protocol. I guess that's the trend these days; people seem to think this syntactic sugar is the best thing since sliced bread.
-- TTK
Actually, hard drive storage densities are increasing much more quickly than that.
I've been tracking hardware price trends for a few years, and hard drive data densities have increased exponentially, but on a changing exponent.
From the late 1980's to the mid 1990's, the rate was about 1.6x per year. Around 1996 the annual rate of increase climbed to 1.8x, then 2.0x, to a peak of about 2.2x/year until the "dot bomb" around 2001, which knocked it down to 1.4x for a while. It has since climbed back up to about 1.6x/year. (I'm not sure why the dot-bomb had this effect.)
If we assume, naively, that it will continue to increase at a mere 1.6x/year, then we should be seeing 6+ TB hard drives by the year 2010, easily. That is, imho, a conservative estimate.
On the other hand, there are any of a number of things which might change the commodity hard drive market (for instance, the advent of thumbdrives which are "good enough" for the masses, leaving only the corporate market for hard drives). So pop some popcorn and pull up a lawnchair, and we'll see what hapens.
-- TTK
> Stakes ? What stakes ? Democracy isn't a lottery. You don't get
> a prize if you happen to vote for the guy that wins.
Yes, you do. The way politics works in this country is that a political party panders to the interests of certain demographics in return for political and financial support. In return, the politician who gets elected into the office uses their position of power to benefit those who put them there.
In the case of executive officers, payback includes granting of contracts (such as those to halliburton), reforming agencies responsible for giving or taking resources (such as the SSD or IRS), refraining from enforcing select laws (such as environmental protections), and rigorous enforcement of other laws.
In the case of legislative officers, payback consists of drafting and passing laws which would benefit the supporters, if enforced.
If you vote in Bush and other republicans, you "win" things like bigger defense contracts granted to companies like GM GDLS Defense Group and Firestone, the gutting of social security, the neglect of environmental protections, elevation of christian charities to federally sanctioned institutions, and the overenthusiastic enforcement of drug control laws.
If you vote in Kerry and other democrats, you "win" things like larger subsidies to automobile manufacturers, the glutting of social security at the expense of taxpayers, elevation of minority races and noncitizens to preferred status, increased funding of public education, aggressive erosion of the right to keep and bear arms, cuts in defense spending, and increases in the minimum wage.
"To the victor go the spoils" -- today as much as always.
-- TTK
Games is why I use FreeDOS on my laptop (dual-boot with Slackware 9.1).
What I have on it now, which works: Boloball, Bridge, Checkkers, Civilization, Hexjump, Texas Hold'em, Battle for Atlantis, VGA Joust, Larn, Bugs, Othello, Starcon-1, Wari, WarZone, XCom, XCom Terror from the Deep.
What doesn't work: Warcraft-2.
What I have somewhere but haven't installed/tried under FreeDOS yet: Warcraft-1, Descent-I/II/III, Quake
-- TTK
I don't know much about AFS, but two significant differences between NFS and GFS:
GFS supports a global file locking interface; NFS does not. So for instance you can have a farm of web servers whose cgi scripts access/update shared files atomically, or multiple database servers which share the same database file, locking individual records to perform simultaneous INSERT/UPDATE transactions.
GFS supports host-granularity redundancy and failover; NFS does not. So if your NFS server bursts into flame, the filesystems it was exporting go away everywhere on your network, but your GFS systems can have two or more hosts exporting the same filesystem. This provides security not only against spontaneous combustion and other disasters, but also scheduled down-times. IT can power down one GFS server to replace a hard drive or move it to a different room, and the backup GFS servers will keep the exported filesystem available without interruption.
If GFS is more scalable/reliable than NFS, that would be nice, but I don't yet know if it does.
-- TTK
NFS also has some scalability problems. It is not a suitable mechanism for several hundred hosts to make their filesystems simultaneously available to each other. (Though, admittedly, I haven't seen anything that indicates that GFS does this either.)
-- TTK
Re-read what you just posted.
It says the *license* under which you distribute it must make it available to third parties. The GPL does not require you to *distribute* the source code to anyone except those who receive the product in executable form. But because it is licensed to third parties, anyone in possession of the source code *may* distribute it to third parties.
-- TTK
Many of history's more excellent weapons were developed by individuals or small teams, not by corporations. John M Browning personally developed several weapons for the US Military. The Neostead combat shotgun was the work of two individuals not working for any company. The AK-47 was developed personally by Kalashnikov, and the Uzi was designed by Uziel Gal while staying in a Yagur prison.
Corporate arms manufacturers have not been a significant source of innovation in the past century. The US Army has tried to replace Browning's M2 .50-BMG twice now with corporate models, and failed because the corporate teams could not get it right. Abrams tanks stationed in Iraq today still mount Browning's 60+ year old design (qv).
It is significant, I think, that the more advanced firearm designs of the last fifty years come from countries where individuals are free to develop new technologies, while America has remained stagnant under the shadow of draconian government regulations which make it nearly impossible for any individual to legally tinker with weapon design in the privacy of their own homes.
Do not underestimate the power of individual initiative and innovation.
-- TTK
It could definitely be made to work better than the current DNS system, albeit incrementally rather than revolutionarily (since DNS already incorporates some elements of P2P -- P2P isn't a new idea, it's just reverting back to the older client/server internet when most nodes running clients were also running servers.
We could use a system such that authority for a domain belonged to the holder of a hash value range, where the MD5 hash value of the domain fell between the bounds of that range. Hash ranges could be distributed and/or sold securely using public key authentication, so that internet users knew who the "real" owner of a hash range was. The hash owner would be both, the registrar for domains hashing into their range, and the source of authorative name resolution.
The initial distribution could spread the 64-bit hash range across say 128 servers, across multiple countries and independent of government or other institutional authority. From there it would be up to the hash range holders how much to charge for registration and/or access, and to sell or give away subranges of their hash range, or not, under whatever license they like. It would make for a more libertarian/anarchic solution than the current top-heavy politically authoratorian system.
Anyway, just my 2c.
-- TTK
> The only organizations affected by this are those who chose
> to use a service that acts as a single point of failure.
And that "organization" can be as fine-grained as you want it to
be. If your desktop PC is running a *nix, setting it up to act
as its own caching DNS server is a fifteen minute process. If
your desktop PC is not running a *nix, then old 586's can be had
for $20 which can run a *nix and sit on your LAN, functioning as
your local caching DNS server.
This one-page HOWTO tells you exactly what you need to do (in the
cases of RedHat and Debian, down to the baby steps), with the exact
contents of your configuration files:
http://www.tldp.org/HOWTO/DNS-HOWTO-3.html
If you are disallowed from having another dynamic IP by your
draconian IT department, you can give the $20 *nix box a static
10.x.x.x and add it to your desktop's routing table and sidestep
the entire issue.
You now have no excuse. Go make your internet more robust.
-- TTK
PetaBox v1.0 would have a formatted capacity of 937.4732544 * 10**15 bytes, but the first PetaBox is not going to be 10 PetaBox-v1.0 racks. It will probably be either 1 or 2 v1.0 racks and 8 or 9 v1.1 racks.
I cannot say for certain, but it is my understanding that PetaBox v1.1 will use slightly different models of hard drives than the ones used in this rack here. It would have a formatted capacity of about 1094 * 10**15 bytes.
(We've been putting this first rack through its paces, and have learned a lot. v1.1 will reflect that experience with a few minor tweaks.)
-- TTK
Fortunately, you are mistaken. The PetaBox employs ReiserFS (which would not have been my first choice, but I will work to any specification given to me), which is a fully journaled filesystem. It does very well recovering from unscheduled downtimes.
ReiserFS has thusfar shown itself a robust solution to this problem, but so would Ext3, and probably XFS (which I know little about, but Joerg here at the Archive likes a lot). You are thinking of Ext2.
-- TTK
> * the cooling system should be built into the structure, like
:-)
> existing refigerant containers
There's been discussion/research at the Archive regarding exactly this
> * not just data storage, but also computing facilities
Each petabox node is a completely functional ITX PC, running Debian Linux, so it is already also a computing cluster. It's not a very good one, unfortunately, because in the interest of keeping the heat and power down a very low-power processor was used, an 800MHz Via C3, which is marginal as an integer-intensive processor.
Also, the storage nodes (which comprise 796 of the 800 nodes) only have 100bT ethernet, which would limit the petabox's ability to efficiently make use of what processing power it does have (in the data distribution phase).
Nonetheless, 796 800MHz processors is nothing to sneeze at. When the PetaBox is being a PetaBox, its processors are mostly idle. I'm sure folks will figure out something to do with those spare cycles (or perhaps not, considering that exercising the processors noticeably increases the power and cooling burden).
-- TTK
Unlikely to be quite that soon
Just before the dot-bomb went boom, hard drive storage was doubling at about 2.1x per year. A few years ago it was about 1.6x per year. So if we naively assume that improvements will continue as a geometric function of time, figure it will take between 12 and 18 years for a petabyte-sized hard disk drive to come to market.
-- TTK
We have a little experience with hard drive failures at the Archive
The solution we've settled on is to make the data self-repairing, and make the hard drives fast and easy to swap in/out (but without driving up the per-node cost too much
As you might imagine, our investigations into the lifespans of different models of hard drives is ongoing
I'm sure the information will get out there somehow, though
-- TTK
I'm not at the liberty to say too much, but we do already have a few entities asking for them (either full petaboxes, or fractional petaboxes).
It turns out that more than a few national libraries have been looking for something like this.
-- TTK