The disk formats are not always interchangeable. The most compatible writeable hardware format is DVD-R (DVD-ROMs use this).
DVD-RAM seems to be pretty much incompatible with anything else.
The others are a mix of "it might work, depending on your player or DVD-ROM drive".
Check out VCDHelp for a nice, concise summary. (Despite several typos and grammatical errors.) In particular they make the DVDForum vs. DVD+RW Alliance division clear.
For data archiving standards are VERY important. I would say the MOST important thing. What good is a 10-year-old archive if there are no more readers available?
Jones would spend the next two weeks rescuing the data off them. Not only was the tape technology rapidly becoming obsolete -- just try to find a working tape-reader today -- but the tapes themselves do not have anything like a 10-year shelf life.
These were 9-track magnetic tapes, inarguably the most widely used tape format in those days. If this standard can fall into such disuse after a measly 10 years, what chance does DVD-<flavor-of-the-month> have?
Also be very careful to choose a compatible software layout. If you're using SuperWhammyDyne Backup(tm) 1.0 because it's fast and came with your DVD-<flavor-of-the-month> drive prepare to be disappointed when you need to read those disks even just a few years from now. Will SuperWhammyDyne Backup(tm) 1.0 run for the OS that you have later?
Fortunately, this wasn't a concern with the UNIX systems. "dump" and "tar" are both open standards (no need to reverse engineer the data bits off tape) and often open source as well (just port and recompile for the current UNIX world).
I suspect that reasonably "safe" software formats are:
tar
cpio
ISO9660 (CD-ROM) w/Rock Ridge and Joliet extensions (just don't rely on the extensions)
UDF [maybe] (DVD-ROM, CD-RW)
I suspect that reasonably "safe" hardware formats are:
CD-R
DVD-R
Barring these, any open source software format is probably OK, so long as source is archived along with the data using one of the above formats.
IRA: Max $2000/year contribution allowed. Insufficient.
This is very true. However, it was finally realized by our esteemed lawmakers and the limits are going up starting this year.
401K: Only sponsored by an employer. Thus the original problem
I don't see how this is a problem. After all, people are going to be employed in between bouts of unemployment.;-) Throwing money like mad into a 401(k) while you are employed will make retirement that much more comfortable.
If your employer doesn't offer this, maybe you should find one that does. Remember that your compensation is salary + benefits not just salary. By failing to provide a decent tax-advantaged benefit, that company is going to (rightfully) lose out on savvy employees who insist on benefits like this.
Remember the Karma Whores? People would compete to see who could come up with the most Karma points for the sheer joy of saying "my score is bigger than yours".
I say let's ressurrect this annoying facet of human nature and turn it to Slashdot's advantage. Why not include a symbol along with each subscriber's comments that represents his/her "devotion" to Slashdot, as measured in US Dollars. (Kind of like the "community supporter" program on EZBoard, and similar "marks of recognition" found on other discussion boards.)
The catch-- these are not earned, they're bought! People could mindlessly compete to see who could get the most impressive widget associated with their name. Hemos could spend hours thinking up new and more interesting associations.
They would give no special privileges, just bragging rights (and revenue for OSDN).
For example: $10 gets you "open source leech" $100 gets you "linux bigot" $1000 gets you "kernel hacker" $10000 gets you "alpha geek" $100000 gets you "better than Hemos" $1000000 gets you "new owner of Slashdot"
First I laughed. Then I thought how simple it would be to use a Slashdot ad instead of the default "Junkbuster" image.
The trick would be to simulate or retrieve the proper context for the ad retrieval (referer, page ID, etc.) Maybe just do a GET on http://slashdot.org and parse out the "... " code section and insert it into your current page.
I'll also give SpamAssassin a thumbs-up. My "real" E-mail address doesn't get much spam since I never give it out. However, it hasn't changed in five or six years (predating the really bad spam) so people can still harvest it from various patch contributors' lists.
SpamAssassin has only let one spam through with no false positives yet (though I'm told that it does give false positives from time to time, mostly based on people who are unfortunate enough to have a source address or mail software associated with spammers.) The one that got through was a pretty unobtrusive spam, too.
All in all, the effort to pull those few false positives out of the spam bucket is pretty minor compared with seeing the massive spam flow every day.
Nuts. Looks like they responded pretty quickly to the hordes of nerds all trying to grab 400MB for their own viewing pleasure.
Large File Access
The file you have selected is approximately 410.41 MB. At this time we are providing access to these files on a restricted basis. If you would like access to this file (#11662), please contact Tara Hess, eobweb@eob.gsfc.nasa.gov
Time to post the mirrors? Or is it time to collectively spam poor Tara?
I suspect that a lot of tech jobs are sufficiently vague in their scope that working on OSS could fall under the definition of "work".
For example, suppose a sysadmin needs to implement a method to check disk space on a bunch of systems remotely. No problem, most SNMP agents report this kind of thing. So he/she grabs UCD SNMP off the web.
In the course of implementing the system monitor he/she runs into a problem with part of UCD SNMP. (Say for example that the API isn't returning what it should.) The time spent investigating and fixing that API had to happen anyway in order for the goal he/she is being paid for (getting the system monitor working) to be reached, so why shouldn't he/she do it on company time?
The company gets what they want (the system monitor). The employee gets his/her job done (same monitor) and the OSS folks (UCD SNMP) get a patch for a bug in their API.
Best of all, this only has to happen once. Anywhere. Now everyone (potentially) has a working API.
However, if someone is being paid to write a game engine and they're really coding on their new OSS web chat board software, that's another issue. (And it's not an OSS issue so much as a management oversight/motivation issue.)
Don't ever expect your degree to be relevant to your job.
I'll second this. So long as it's a technical subject (i.e. any of the sciences) and you get a Bachelor of Science degree out of it, the actual topic matters little in my experience. FAR more important are basic business skills (showing up on time, delivering what you promise, communicating your progress back to your bosses, helping coworkers when they need it, accepting help when needed, etc. etc.)
If you plan on doing hard-core development, (i.e. acoustic analysis, cryptography, writing an OS/database, or other computationally challenging work) then a good collection of CS courses will probably help. If you're just going to be adding purple icons to MegaCorp(TM)'s newest brain spasm then you really don't need to have a complete understanding of the optimal algorithm to sort massive arrays of data.:-)
Excellent observation, and thanks for the pointer to the "real" Terms of Service.
Now for me to go pick through my current provider's (revised WAY too often to keep up with) Terms of Service to see how nastily I violate them without knowing...
Nothing in their Terms of Service seems to suggest that they have any anti-NAT policies.
As others have observed, if you want another IP they charge you for it. So does AT&T, @Home, and many other cable modem providers. If you can cram all your systems into one IP through NAT, they don't seem to have any problems with it.
The idea is that if you have a secure OS it's MUCH harder to install the keystroke logger in the first place. The article spoke about the FBI using known holes in browsers, E-mail, etc. to install their logging utilities.
If these holes have been plugged, they'll need physical access which then requires (I hope!) a warrant.
One good solution for us linux-heads with home networks is to set up a caching-only DNS server. This is as simple as installing the "caching-nameserver" RPM (along with the bind RPM, of course). Then just configure all your servers to point to your caching nameserver host for DNS and you won't be at the mercy of AT&Ts nameservers any more.
This let me bypass the AT&T nameservers that were having problems and get back online in no time.
Non-authoritative answer:
www.yahoo.com canonical name = www.yahoo.akadns.net
Name: www.yahoo.akadns.net
Address: 216.115.102.77
... and so on...
> exit $
-----
As I mentioned in a posting under the old article, static IP allocations are on hold until AT&T sorts out which networks go where in their internal network configuration databases. Those of us with static IP allocations will just have to wait a few weeks. (However, I've been told by DHCP users that generally AT&T does not aggressively recycle IPs, so even DHCP-based IPs tend to be fairly stable.)
I should also add that the new AT&T DHCP equipment seems to work with linux's "pump" DHCP client, whereas the old Excite@Home equipment in my area did not.
AT&T's support lines are swamped, even though it's the middle of the night. I managed to get through on chat much more quickly than the support number. (Though the person I spoke with on the phone was much friendlier than the one in chat...)
Here's what I found out:
+ The chat person said flat-out that AT&T does not support static IPs and that I was basically hosed. She referred me to the Win32 "configurator" executable on the http://newuser.attbi.com website. I didn't bother asking for a linux version.;-)
+ The phone person said that since everything was so new that they didn't have their act together for static IPs yet and to run dynamic for a couple weeks until things settle down.
Either way, I'm stuck on DHCP for a while, but the phone support seemed to imply there was some light at the end of the tunnel once the initial rush of problems are sorted out. For me, this is only an issue for remote access since my internal network is all NATted anyhow.
My guess is that the Excite --> AT&T transition would be completely transparent to those on DHCP who renew their leases after midnight.
And of course, if they try to force me to stay on DHCP, there's always DSL...
Soft padding simply won't work through the mail. I made this mistake once, thankfully on far less expensive items. It's especially pathetic when combined with hard, heavy objects like books (for me) or computers (for you).
Although I've seen several "you should have known better" postings, I disagree. Most packing guidelines are very poorly and/or ambiguously written. Just what does "adequate padding" mean? What could be more adequate than padding with several pillows, right? Wrong.
The packing material must not compress or else your packing is useless and you get "exploded" boxes that look, well, like yours. This is why computers are packed by the factory suspended in the middle of the box by styrofoam holders. The holders transfer the load of the other boxes stacked on top through to the boxes stacked underneath without collapsing. Bubble wrap is great for a thin protective layer around individual items, but it won't hold them in place within a box.
It's unfortunate that your lesson was so expensive. I wish you luck in your attempts at getting some reimbursement, however next time be sure to use professional packing materials (sounds like you did-- bubble wrap), leave absolutely zero air space, and plan for several hundred pounds to be sitting on top of whatever you ship.
Discounting special environments such as Tandem (which require a LOT of rewriting applications to work) there is no way to get "high availability" out of any single system, for just the reasons you describe. Patches, hardware/software upgrades, OS panics, sysadmin stupidity, leaky roofs, twitchy circuit breakers, fiber-seeking backhoes, and a myriad of other minor and major catastrophes can't simply be put on hold. Hence, any single system is likely to have availability in the 80-95% range in a typical environment.
If you beef up things with advanced monitoring, very reliable hardware, well trained staff, good vendor support, and are generally very careful you can get a single system up to about the 99% range. This is about about 87 hours of downtime per year-- enough for quarterly patches, bi-annual hardware work, and the ocassional problem. Most of this is scheduled, and we're likely to only see about 12 hours of "surprises" a year, even if it's not a good year.
Yes, I'm pulling most of these numbers out of my ass, but my ass has been around the block a couple times. Feel free to fudge the numbers if your experience varies. Changing the 12 hours around won't make that much difference in the later calculations. (below)
Assuming 365.25 days per year, that 12 hours means we have a "no surprises" uptime of roughly 99.8 percent. Not hard if you're running things in a stable environment.
The only way to get those extra two nines is to start running things with spares. If you have a spare system and are careful not to build an environment where both can fail simultaneously (i.e. on the same power grid), the chance of running into a simultaneous surprise becomes 1 - (0.002 * 0.002) or.999996 (99.9996%). Voila! five nines. (You don't multiply the original 99% since I'm assuming that you're smart enough not to schedule patches for the same day on both primary and standby systems.) In order to be able to multiply the probabilities together they do need to be truly independent of one another-- again, not on the same power grid, in the same building, etc.
In short-- there's no way to get five nines from a single system. You need clusters of independent systems.
This would work best in conjunction with a link to show detailed ad information, in particular the "classifications" the ad company has supplied to reach their target market. (i.e. "perl", "hard drives", "CPUs", "php", "developers wanted", "snack foods", etc.)
Classifications are usually created not by technicians, but by some marketing drone who probably has a hard time spelling CPU. A discussion forum and the ability to moderate up well-classified, interesting ads would help good ads get a better clickthru.
The big problem with moderation like this is that each company pays for a certain number of impressions. If their ad sucks, and gets moderated down, the OSDN may not be able to meet their stated number of impressions before the end of the ad campaign.
There needs to be some way to provide positive motivation for companies to put up "good" ads. Rather than fiddling with the ad frequencies, perhaps OSDN could just create a "showcase" page which shows the ads in order of their moderation totals. "Good" ads could be recognized and "bad" ads would also be recognized.;-) Another thought might be to give the highest-rated ads additional run time for no charge. Perhaps the best ads could go on the front page and all the others would only be shown deeper in?
Ahh, to be able to do some Cruel Brutal Damage again! I miss the days.
Anyone else like to go for the "massive overkill" victory where you kept the last race cooped up on a small, ultra poor planet until you maxxed all the technology levels and started pumping out stacks of 32000 ultra large ships just bristling with miniaturized weapons?
I'm surprised the planet survived.
I also hope they don't try to get too fancy with it and abandon the addictive simplicity involved. I dread the thought of them turning MOO3 into something like Star Control 3. Ugh. That would suck.
Frighteningly, MOO2 is still in my CD pouch of games I always take when I travel. Even if I'm tired of all the others, I know I can pull that out an be amused.
... but AtariDatacenter may be right. I'm posting only because I have an established history on Slashdot and absolutely zero connection to AtariDatacenter or redir.
Consider this a neutral third party observation to document something before it can be changed.
The Sun E4500 is not a cheap machine, base configuration usually comes in at around $75k and when configured to suit its usual purpose (enterprise class transaction servers) the bill sometimes tops $100k.
The Sun E4500 is not a cheap machine, base configuration usually comes in at around $75k and when configured to suit its usual purpose (enterprise class transaction servers) the bill sometimes tops $100k.
The Epinions date is listed as Aug 8 2000. No date was available for the reviewboard article. The Epinions author (nightfall) is not the same author as the disputed E10000 article (jmccorm).
This topic comes up in virtually all intelligent virus discussions. In summary, it is not a good idea to use viral properties, even for something useful. I refer you to item F7 in the comp.virus FAQ (circa 1995):
A very hotly debated topic that has flared-up dramatically several times in Virus-L/comp.virus. The answer to this is not simple and largely hinges on your definition or interpretation of the term computer virus.
By definition (see B1), viruses do not have to do something "bad" (although many people argue that the uninvited "resource wasting" that is almost inherent in viral activity is necessarily bad). From this point (and based on his somewhat esoteric definition of the term computer virus) Fred Cohen has argued that "good" or "useful" computer viruses are a serious possibility. In fact, Dr. Cohen offered a reward of $1000 for the first clearly "useful" virus--despite several potential claimants, however, he hasn't paid up.
Although there has never been a position that was widely agreed upon as a result of any of these discussions, many contributors to this forum believe that there are serious problems with the idea of implementing useful computing functionality through self-replicating programs. Vesselin Bontchev's paper originally delivered at the 1994 EICAR conference, titled "Are `Good' Computer Viruses Still a Bad Idea?", is available by anonymous FTP from ftp.informatik.uni-hamburg.de (IP = 134.100.4.42), as pub/virus/texts/viruses/goodvir.zip. *Anyone* wishing to raise this discussion in Virus-L/comp.virus again should read and carefully consider this paper before posting. It contains many strong arguments against the idea of "good computer viruses", and some prescriptions of how good viruses would have to be implemented and distributed to deserve the label "good". To date no strong arguments countering the points in this paper or otherwise arguing in favor of the concept of good viruses have been posted to the group.
The summary of points made in this paper are:
Lack of Control Even features such as defined lifetimes, central verification, etc. can't control self-replicating code perfectly. It is very easy for viruses to "get away". A great number of the viruses in the wild started out as merely research projects and were never intended to be released.
Recognition Difficulty Allowing one program which has viral properties through one's defenses makes it easy for other programs to exploit the same hole. It's hard to tell when a "good" virus is doing its work versus a "bad" virus.
Resource Wasting The process of infection will use up system resources-- what happens when the program hits a host that has few resources to spare?
Bug Containment What happens if you discover a bug in the viral code? How do you update all the installed copies?
Compatibility Problems The software could break certain systems while it works fine on others. This could make for difficult-to-track problems.
Effectiveness There are always increased risks with viral code, and they can't do anything that nonviral code couldn't do with lower risks.
Vesselin even goes so far as to describe some mechanisms to help mitigate the above problems, but the crux of the story is that it's still simpler and safer to rely on non-replicating code.
There are some examples of failed attempts at "good" viruses in Vesselin's brief. They include The "Anti-Virus" Virus, The "File Compressor" Virus, The "Disk Encryptor" Virus, and The "Maintenance" Virus. Some of these same ideas have been brought up in this very Slashdot discussion.
Amazing what history can teach. Damn, I'm starting to feel old...
Slashdot Mirror
DVD-RAM seems to be pretty much incompatible with anything else.
The others are a mix of "it might work, depending on your player or DVD-ROM drive".
Check out VCDHelp for a nice, concise summary. (Despite several typos and grammatical errors.) In particular they make the DVDForum vs. DVD+RW Alliance division clear.
For example, the USENET archives resurrected by Google had two big problems:
These were 9-track magnetic tapes, inarguably the most widely used tape format in those days. If this standard can fall into such disuse after a measly 10 years, what chance does DVD-<flavor-of-the-month> have?Also be very careful to choose a compatible software layout. If you're using SuperWhammyDyne Backup(tm) 1.0 because it's fast and came with your DVD-<flavor-of-the-month> drive prepare to be disappointed when you need to read those disks even just a few years from now. Will SuperWhammyDyne Backup(tm) 1.0 run for the OS that you have later?
Fortunately, this wasn't a concern with the UNIX systems. "dump" and "tar" are both open standards (no need to reverse engineer the data bits off tape) and often open source as well (just port and recompile for the current UNIX world).
I suspect that reasonably "safe" software formats are:
- tar
- cpio
- ISO9660 (CD-ROM) w/Rock Ridge and Joliet extensions (just don't rely on the extensions)
- UDF [maybe] (DVD-ROM, CD-RW)
I suspect that reasonably "safe" hardware formats are:- CD-R
- DVD-R
Barring these, any open source software format is probably OK, so long as source is archived along with the data using one of the above formats.This is very true. However, it was finally realized by our esteemed lawmakers and the limits are going up starting this year.
401K: Only sponsored by an employer. Thus the original problem
I don't see how this is a problem. After all, people are going to be employed in between bouts of unemployment. ;-) Throwing money like mad into a 401(k) while you are employed will make retirement that much more comfortable.
If your employer doesn't offer this, maybe you should find one that does. Remember that your compensation is salary + benefits not just salary. By failing to provide a decent tax-advantaged benefit, that company is going to (rightfully) lose out on savvy employees who insist on benefits like this.
Score: 5,Funny
;-)
Hmmm. I was only *partly* joking.
Remember the Karma Whores? People would compete to see who could come up with the most Karma points for the sheer joy of saying "my score is bigger than yours".
I say let's ressurrect this annoying facet of human nature and turn it to Slashdot's advantage. Why not include a symbol along with each subscriber's comments that represents his/her "devotion" to Slashdot, as measured in US Dollars. (Kind of like the "community supporter" program on EZBoard, and similar "marks of recognition" found on other discussion boards.)
The catch-- these are not earned, they're bought! People could mindlessly compete to see who could get the most impressive widget associated with their name. Hemos could spend hours thinking up new and more interesting associations.
They would give no special privileges, just bragging rights (and revenue for OSDN).
For example:
$10 gets you "open source leech"
$100 gets you "linux bigot"
$1000 gets you "kernel hacker"
$10000 gets you "alpha geek"
$100000 gets you "better than Hemos"
$1000000 gets you "new owner of Slashdot"
First I laughed. Then I thought how simple it would be to use a Slashdot ad instead of the default "Junkbuster" image.
... " code section and insert it into your current page.
The trick would be to simulate or retrieve the proper context for the ad retrieval (referer, page ID, etc.) Maybe just do a GET on http://slashdot.org and parse out the "
I'll also give SpamAssassin a thumbs-up. My "real" E-mail address doesn't get much spam since I never give it out. However, it hasn't changed in five or six years (predating the really bad spam) so people can still harvest it from various patch contributors' lists.
SpamAssassin has only let one spam through with no false positives yet (though I'm told that it does give false positives from time to time, mostly based on people who are unfortunate enough to have a source address or mail software associated with spammers.) The one that got through was a pretty unobtrusive spam, too.
All in all, the effort to pull those few false positives out of the spam bucket is pretty minor compared with seeing the massive spam flow every day.
I didn't have this problem even though two DVDs never arrived during the three months I was subscribed.
Interesting perception on OSS development.
I suspect that a lot of tech jobs are sufficiently vague in their scope that working on OSS could fall under the definition of "work".
For example, suppose a sysadmin needs to implement a method to check disk space on a bunch of systems remotely. No problem, most SNMP agents report this kind of thing. So he/she grabs UCD SNMP off the web.
In the course of implementing the system monitor he/she runs into a problem with part of UCD SNMP. (Say for example that the API isn't returning what it should.) The time spent investigating and fixing that API had to happen anyway in order for the goal he/she is being paid for (getting the system monitor working) to be reached, so why shouldn't he/she do it on company time?
The company gets what they want (the system monitor). The employee gets his/her job done (same monitor) and the OSS folks (UCD SNMP) get a patch for a bug in their API.
Best of all, this only has to happen once. Anywhere. Now everyone (potentially) has a working API.
However, if someone is being paid to write a game engine and they're really coding on their new OSS web chat board software, that's another issue. (And it's not an OSS issue so much as a management oversight/motivation issue.)
Don't ever expect your degree to be relevant to your job.
I'll second this. So long as it's a technical subject (i.e. any of the sciences) and you get a Bachelor of Science degree out of it, the actual topic matters little in my experience. FAR more important are basic business skills (showing up on time, delivering what you promise, communicating your progress back to your bosses, helping coworkers when they need it, accepting help when needed, etc. etc.)
If you plan on doing hard-core development, (i.e. acoustic analysis, cryptography, writing an OS/database, or other computationally challenging work) then a good collection of CS courses will probably help. If you're just going to be adding purple icons to MegaCorp(TM)'s newest brain spasm then you really don't need to have a complete understanding of the optimal algorithm to sort massive arrays of data. :-)
Excellent observation, and thanks for the pointer to the "real" Terms of Service.
Now for me to go pick through my current provider's (revised WAY too often to keep up with) Terms of Service to see how nastily I violate them without knowing...
As others have observed, if you want another IP they charge you for it. So does AT&T, @Home, and many other cable modem providers. If you can cram all your systems into one IP through NAT, they don't seem to have any problems with it.
The idea is that if you have a secure OS it's MUCH harder to install the keystroke logger in the first place. The article spoke about the FBI using known holes in browsers, E-mail, etc. to install their logging utilities.
If these holes have been plugged, they'll need physical access which then requires (I hope!) a warrant.
Here are some excellent step-by-step instructions on securing Linux, Solaris, and NT.
One good solution for us linux-heads with home networks is to set up a caching-only DNS server. This is as simple as installing the "caching-nameserver" RPM (along with the bind RPM, of course). Then just configure all your servers to point to your caching nameserver host for DNS and you won't be at the mercy of AT&Ts nameservers any more.
...
This let me bypass the AT&T nameservers that were having problems and get back online in no time.
-----
To test it first use this:
$ nslookup
> lserver
Default server:
Address: #53
> www.yahoo.com
Server:
Address: #53
Non-authoritative answer:
www.yahoo.com canonical name = www.yahoo.akadns.net
Name: www.yahoo.akadns.net
Address: 216.115.102.77
... and so on
> exit
$
-----
As I mentioned in a posting under the old article, static IP allocations are on hold until AT&T sorts out which networks go where in their internal network configuration databases. Those of us with static IP allocations will just have to wait a few weeks. (However, I've been told by DHCP users that generally AT&T does not aggressively recycle IPs, so even DHCP-based IPs tend to be fairly stable.)
I should also add that the new AT&T DHCP equipment seems to work with linux's "pump" DHCP client, whereas the old Excite@Home equipment in my area did not.
AT&T's support lines are swamped, even though it's the middle of the night. I managed to get through on chat much more quickly than the support number. (Though the person I spoke with on the phone was much friendlier than the one in chat...)
;-)
Here's what I found out:
+ The chat person said flat-out that AT&T does not support static IPs and that I was basically hosed. She referred me to the Win32 "configurator" executable on the http://newuser.attbi.com website. I didn't bother asking for a linux version.
+ The phone person said that since everything was so new that they didn't have their act together for static IPs yet and to run dynamic for a couple weeks until things settle down.
Either way, I'm stuck on DHCP for a while, but the phone support seemed to imply there was some light at the end of the tunnel once the initial rush of problems are sorted out. For me, this is only an issue for remote access since my internal network is all NATted anyhow.
My guess is that the Excite --> AT&T transition would be completely transparent to those on DHCP who renew their leases after midnight.
And of course, if they try to force me to stay on DHCP, there's always DSL...
I bet when it's all fixed they have a new sign in 1000-point lettering which says:
;-)
NO FLASH PHOTOGRAPHY
Whoops.
Soft padding simply won't work through the mail. I made this mistake once, thankfully on far less expensive items. It's especially pathetic when combined with hard, heavy objects like books (for me) or computers (for you).
Although I've seen several "you should have known better" postings, I disagree. Most packing guidelines are very poorly and/or ambiguously written. Just what does "adequate padding" mean? What could be more adequate than padding with several pillows, right? Wrong.
The packing material must not compress or else your packing is useless and you get "exploded" boxes that look, well, like yours. This is why computers are packed by the factory suspended in the middle of the box by styrofoam holders. The holders transfer the load of the other boxes stacked on top through to the boxes stacked underneath without collapsing. Bubble wrap is great for a thin protective layer around individual items, but it won't hold them in place within a box.
It's unfortunate that your lesson was so expensive. I wish you luck in your attempts at getting some reimbursement, however next time be sure to use professional packing materials (sounds like you did-- bubble wrap), leave absolutely zero air space, and plan for several hundred pounds to be sitting on top of whatever you ship.
I'm sure one person who gets the CD will immediately make it available on a website someplace. Then everyone else can get it for free.
;-)
After all, that's what "freely redistributable" is all about. Only one poor chum has to eat the media costs.
Discounting special environments such as Tandem (which require a LOT of rewriting applications to work) there is no way to get "high availability" out of any single system, for just the reasons you describe. Patches, hardware/software upgrades, OS panics, sysadmin stupidity, leaky roofs, twitchy circuit breakers, fiber-seeking backhoes, and a myriad of other minor and major catastrophes can't simply be put on hold. Hence, any single system is likely to have availability in the 80-95% range in a typical environment.
.999996 (99.9996%). Voila! five nines. (You don't multiply the original 99% since I'm assuming that you're smart enough not to schedule patches for the same day on both primary and standby systems.) In order to be able to multiply the probabilities together they do need to be truly independent of one another-- again, not on the same power grid, in the same building, etc.
If you beef up things with advanced monitoring, very reliable hardware, well trained staff, good vendor support, and are generally very careful you can get a single system up to about the 99% range. This is about about 87 hours of downtime per year-- enough for quarterly patches, bi-annual hardware work, and the ocassional problem. Most of this is scheduled, and we're likely to only see about 12 hours of "surprises" a year, even if it's not a good year.
Yes, I'm pulling most of these numbers out of my ass, but my ass has been around the block a couple times. Feel free to fudge the numbers if your experience varies. Changing the 12 hours around won't make that much difference in the later calculations. (below)
Assuming 365.25 days per year, that 12 hours means we have a "no surprises" uptime of roughly 99.8 percent. Not hard if you're running things in a stable environment.
The only way to get those extra two nines is to start running things with spares. If you have a spare system and are careful not to build an environment where both can fail simultaneously (i.e. on the same power grid), the chance of running into a simultaneous surprise becomes 1 - (0.002 * 0.002) or
In short-- there's no way to get five nines from a single system. You need clusters of independent systems.
This would work best in conjunction with a link to show detailed ad information, in particular the "classifications" the ad company has supplied to reach their target market. (i.e. "perl", "hard drives", "CPUs", "php", "developers wanted", "snack foods", etc.)
Classifications are usually created not by technicians, but by some marketing drone who probably has a hard time spelling CPU. A discussion forum and the ability to moderate up well-classified, interesting ads would help good ads get a better clickthru.
The big problem with moderation like this is that each company pays for a certain number of impressions. If their ad sucks, and gets moderated down, the OSDN may not be able to meet their stated number of impressions before the end of the ad campaign.
There needs to be some way to provide positive motivation for companies to put up "good" ads. Rather than fiddling with the ad frequencies, perhaps OSDN could just create a "showcase" page which shows the ads in order of their moderation totals. "Good" ads could be recognized and "bad" ads would also be recognized. ;-) Another thought might be to give the highest-rated ads additional run time for no charge. Perhaps the best ads could go on the front page and all the others would only be shown deeper in?
Ahh, to be able to do some Cruel Brutal Damage again! I miss the days.
Anyone else like to go for the "massive overkill" victory where you kept the last race cooped up on a small, ultra poor planet until you maxxed all the technology levels and started pumping out stacks of 32000 ultra large ships just bristling with miniaturized weapons?
I'm surprised the planet survived.
I also hope they don't try to get too fancy with it and abandon the addictive simplicity involved. I dread the thought of them turning MOO3 into something like Star Control 3. Ugh. That would suck.
Frighteningly, MOO2 is still in my CD pouch of games I always take when I travel. Even if I'm tired of all the others, I know I can pull that out an be amused.
... but AtariDatacenter may be right. I'm posting only because I have an established history on Slashdot and absolutely zero connection to AtariDatacenter or redir.
Consider this a neutral third party observation to document something before it can be changed.
From http://www.reviewboard.com/Section/Cover/E4500, paragraph two:
From http://www.epinions.com/enth-review-5999-27A4508B- 39906C31-prod5, paragraph 1:
The Epinions date is listed as Aug 8 2000. No date was available for the reviewboard article. The Epinions author (nightfall) is not the same author as the disputed E10000 article (jmccorm).
This topic comes up in virtually all intelligent virus discussions. In summary, it is not a good idea to use viral properties, even for something useful. I refer you to item F7 in the comp.virus FAQ (circa 1995):
A very hotly debated topic that has flared-up dramatically several times in Virus-L/comp.virus. The answer to this is not simple and largely hinges on your definition or interpretation of the term computer virus.
By definition (see B1), viruses do not have to do something "bad" (although many people argue that the uninvited "resource wasting" that is almost inherent in viral activity is necessarily bad). From this point (and based on his somewhat esoteric definition of the term computer virus) Fred Cohen has argued that "good" or "useful" computer viruses are a serious possibility. In fact, Dr. Cohen offered a reward of $1000 for the first clearly "useful" virus--despite several potential claimants, however, he hasn't paid up.
Although there has never been a position that was widely agreed upon as a result of any of these discussions, many contributors to this forum believe that there are serious problems with the idea of implementing useful computing functionality through self-replicating programs. Vesselin Bontchev's paper originally delivered at the 1994 EICAR conference, titled "Are `Good' Computer Viruses Still a Bad Idea?", is available by anonymous FTP from ftp.informatik.uni-hamburg.de (IP = 134.100.4.42), as pub/virus/texts/viruses/goodvir.zip. *Anyone* wishing to raise this discussion in Virus-L/comp.virus again should read and carefully consider this paper before posting. It contains many strong arguments against the idea of "good computer viruses", and some prescriptions of how good viruses would have to be implemented and distributed to deserve the label "good". To date no strong arguments countering the points in this paper or otherwise arguing in favor of the concept of good viruses have been posted to the group.
The summary of points made in this paper are:
Even features such as defined lifetimes, central verification, etc. can't control self-replicating code perfectly. It is very easy for viruses to "get away". A great number of the viruses in the wild started out as merely research projects and were never intended to be released.
Allowing one program which has viral properties through one's defenses makes it easy for other programs to exploit the same hole. It's hard to tell when a "good" virus is doing its work versus a "bad" virus.
The process of infection will use up system resources-- what happens when the program hits a host that has few resources to spare?
What happens if you discover a bug in the viral code? How do you update all the installed copies?
The software could break certain systems while it works fine on others. This could make for difficult-to-track problems.
There are always increased risks with viral code, and they can't do anything that nonviral code couldn't do with lower risks.
Vesselin even goes so far as to describe some mechanisms to help mitigate the above problems, but the crux of the story is that it's still simpler and safer to rely on non-replicating code.
There are some examples of failed attempts at "good" viruses in Vesselin's brief. They include The "Anti-Virus" Virus, The "File Compressor" Virus, The "Disk Encryptor" Virus, and The "Maintenance" Virus. Some of these same ideas have been brought up in this very Slashdot discussion.
Amazing what history can teach. Damn, I'm starting to feel old...