The marketing muscle behind Intel must be SO brilliant, it blinds me!
"Leap Ahead" - Wow! The brilliance! The magnificence! The genius!
Anybody remember "The Road Ahead"?
And Linus's comment?
Here's a suggestion for Intel - use the slogan "Leap Without looking Ahead!" Then you can add "And Without Looking Back At Bill To See If He Approves"...
In other words, who gives a flying cockroach's ass what the Intel slogan is? It's a SLOGAN, morons!
Oops, the link doesn't work, let's try that again.
Ah, I see,/. fucks up again! The word "gamma" is for some reason being split in the middle - "gam ma" - due to the morons who programmed Slashcode apparently. And I'm using "Plain Old Text" to submit this! Morons! "Check those URLs", indeed! Check your fucking code! This URL is perfectly good as I'm looking at it, you idiots! I've even REWRITTEN the fucking thing and you still can't handle it! Stupid, fucking geeks can't do anything right!
"5. Convert your program into opcodes and poke them into memory byte by byte (Opcode mnemonics are for candy-assed wimps.)"
Ah, a gentlemen who remembers the good ol' days of the MITS Altair! Flipping front panel switches to program!
I used to have to do this on an RCA 301, too. The funny part was that the internal encoding on that machine was...character! Yup - you could read characters directly out of the memory...character-oriented machine...weird...
You had to punch octal code into the console to run a program. The program itself could be in COBOL or Fortran on a tape drive. They even had a disk drive that had a platter the size of a car wheel that required a 30HP motor to spin it. We never got that to work (all this was surplus in the 1970's.)
All the hot air from George Bush, Dick Cheney, Condi Rice and Don Rumsfeld is being secretly redirected into the magma to push up more material.
The government hopes causing a major eruption will divert news attention from the war in Iraq, spying on US citizens, the Katrina failures, the economy, global warming, the Republican Congressional bribe scandals, the outing of CIA agents for the benefit of Russian-Israeli Mafia nuclear black marketeers, the coming war with Iran, the...
So now that you're hit with the facts of the industry move to disk-to-disk, you're upset.
I didn't bother to add up GB from your post because I couldn't care less - and you were the one in such a hurry to drop my argument you mistyped your figures.
"they still use tapes." - Never said tapes weren't useful as archival. I also said that while offsite backup via network was useful, it was costly and suitable only for those who can afford it relative to other means of offsite transport. So you're being redundant again.
As for compression, they probably use Content Optimization, which was another focus of the article. While this is a form of compression, it's a more reliable form (although I'm sure they use regular compression as well - that wasn't my point in this case - the point was disk-to-disk is replacing tape for the purpose I cited - local emergency restoration. And it is.)
Expensive spinning disks? Jesus, you are cheap, aren't you? Complaining about the power cost to spin drives - many of which probably aren't spinning at all until they're backed up to. Compared to the value of the data and the obvious value of quick efficient restoration in the event of primary system failure, power costs are not relevant to these people, obviously. And disks spin whether they're used for backup or not. They outlast tape drives in longevity, too. I don't know how many times I've heard people say that, at least the cheaper tape drives, if not the really expensive ones, barely last a year.
The quote does not rehash anything you said, it clearly explains my points about disk-to-disk. The only thing it says about archiving and compression, however, is that TAPES FAIL - which is why I say don't use archiving and compression together.
Last night I received a confirmation of my policy: I was changing my partition structure on my home system, and had to wipe and restore a partition from a backup made yesterday as well. That went okay, even though it was some 11 DVDs with 250,000 files. I then decided to restore some data I'd taken off to make room last year, about 3GB worth that would be hard to replace should it be lost. That data was backed up on the old LiteOn DVD drive that was flaky.
Restoring it on the newer NEC drive, sure enough, a bad sector read caused one of the two DVDs to fail to restore one or more files. Since I'd had the foresight to back up the data twice, I used the second DVD to restore the missing files. And this was even with individual uncompressed unarchived files. Had I backed up with archiving and compression (and no PARs or other redundancy), I would have lost 3GB of data.
That says it all. There isn't anything more to be said.
You can't compare media to disk just on capacity. When I say $100 per media is bad compared to disk, that means the media is worthless without the drive. The $100 disk IS the drive. You have to ADD the cost of media to the cost of the drive. How many of those 400GB tape cartridges does somebody need? Add that to the cost of the drives.
14 100GB drives at $800 apiece - nice, ignore the 300GB drives out now. Cut the cost by a factor of three, doesn't it? That's simple math, too.
I never said disk made sense for long-term storage. I said you CAN take it offsite for offsite storage. I didn't say how long. Disk drives have stiction problems when not used for a long time; tape has tensioning problems and heat and humidity problems if not stored properly. Long-term storage is another issue entirely than storage for restoration purposes. Again, I'm not talking about archival storage, as I said repeatedly; tape is adequate for that and that's all it should be used for in my opinion - and in the opinion of a lot of other people these days who advise on enterprise IT.
When I said redundancy, I refer to either PAR files or multiple backups of the same data. If the data is critical, you'd better have one or the other - and no matter whether you use disk or tape. That's the original point of discussion. If you use archiving and compression together, you damn sure better have redundancy if the data is critical, i.e., data that absolutely has to be there if it needs to be restored.
Yes, I really do mean backing up individual files (compressed or not depends on the criticality of the individual files) to disk without archiving and compression. You have to read the freakin' files to compress them, it's far faster and more reliable to just back up the entire file. Yes, it eats up space - which is only important to a home user like me who has to pay for DVDs. For corporate data, the media cost is irrelevant to the value of the data (again, distinguishing between critical data and purely archival data.)
Your entire argument is about cost, about time savings, about this and that - and has nothing to do with the core issue - making sure that data can be recovered when it is needed.
Here's the bottom line I found on the Net which sums it all up pretty well:
"Diogenes Analytical Laboratories, an IT advisory company that performs independent product lab evaluations and advises IT buyers, estimated that, on average, between 5 and 20 percent of nightly tape-based backup/recovery jobs fail. According to ESG, roughly one-fourth of SMB users reported that 20 percent or more of their tape-based backup/recovery jobs fail. The number one reason cited: media failure (e.g., lost, damaged or corrupted tapes).
In addition to media failure, there is the high percentage of operational errors, including operator (human) errors such as storing the wrong tape, and procedural errors such as backing up wrong or empty files. Any time there is human intervention, the opportunity for error increases dramatically.
Analysts generally agree that IT management costs represent five to seven times the cost of capital expenditure. It is therefore essential to consider operation and administrative costs (including media management and tape swapping) in addition to acquisition costs when doing a financial analysis of tape versus alternatives. For large organizations, the tape media costs (which generally come out of the expense budget versus capital budget) mount up as well...
For a simple cost comparison, W. Curtis Preston offers this scenario: a midrange tape library costs roughly $4 to $11 per gigabyte (GB) while disk prices are hovering around $3 to $11 per GB. This puts disk and tape about even (excluding reliability and recovery time factors).
Capacity Optimization
Perhaps the most significant change in cost comparison comes from the introduction of a new technology which some have named capacity optimization (CO). Also called data reduction, disk deduplication, or commonality factoring,
Enterprises send backups offsite all the time. You can just as easily pull a bunch of removable drives and send them offsite as you can a bunch of tape. That's just a matter of organization. This is irrelevant, however, because in most cases you backup to SANs for LOCAL restoration, then backup to tape from the SAN for offsite archival storage (or last-ditch restoration if your building blows up.) (That, or you send the data over a commo link to another site for storage as tape or disk.)
Neither of which is relevant to the archive/compression discussion. The issue is should the backup be archived and compressed rather than stored as individual (compressed or not) files.
As for single drives running at tape speeds, what did I say? The new SCSI standards do just that.
Also, exactly how expensive are these wonderful tape drives you refer to? Compare the cost of them to the cost of even an expensive SCSI drive. You want to save money by replacing an eight hundred dollar 300GB SCSI enterprise class hard drive with a FOUR THOUSAND DOLLAR 400GB (WITH COMPRESSION) Quantum LTO-3 tape drive? Good luck with that!
And that doesn't count the cost of the media at $100 a pop! I can buy an entire (ATA) drive for that!
Also, why do you think Quantum is making hard disk backup systems now? Because the market is demanding it, that's why.
Once again, you compare accidents to compression. Accidents are just that - accidents. Archiving/compressing is deliberately INVITING data loss. That's a difference.
I said nothing about taking SANs offsite. I'm talking about backing up to SANs for local restoration and in specific response to your ignorant statement that tape is faster than hard drives - which is bullshit. And if tape IS faster than hard drives, then why the hell is time to backup being better with compression your primary argument? If tape is so fast, then you don't need compression, so why not gain the extra reliability?
"Hard drives never go bad." I never said that. However, hard drives ARE far more reliable than tape - especially if they are only being used for backup. While modern tape systems are far better than the old nine-track - as I SAID - they are still far from completely reliable.
"Forensic bit-recovery is better then a sound backup and recovery practice."
Never said that for an instant. You might try rereading my posts. What I said was that sound backup and recovery practice precludes using archiving and compression together for critical data - and if you do it, you'd better have redundancy built in which means PAR files which means increased complexity and cost for the dubious benefits of archiving and compression.
I also said that the value of data to be restored outweighs the minor cost savings of media and time achievable with archiving/compression - points you have done nothing to dispell and everything to ignore.
"Actually, they're quite common. However, your drives (tape, CD, DVD, hard, etc.) typically have some error correction built in."
That's why I said they aren't worth talking about. It's rare for a bit error to not be corrected automatically and it's rare for a bit error to actually matter given the size and organization of most files today. Unless it causes a program crash, most of the time it's just a glitch in a video or audio stream that is ignored.
"Being able to recover from an error is a good thing -- but it's also important to actually know that there was an error..."
I still don't know what the hell you're talking about here. If you're talking about errors in data that DON'T cause a failure of the system but merely corrupt the data, then your statement makes sense - but is irrelevant to the discussion. I'm talking about errors that prevent restoration of the data - which, again, is the point of backup - to get the data back if it is lost. I'm not concerned about simple data corruption that doesn't cause a restore failure because, as you say, most of the time that is corrected by other mechanisms in the system. I'm concerned about data corruption that causes loss of data by being unable to restore it to replace data already lost elsewhere.
Today I'm backing up my system again (haven't done it for months since it IS a painful process with just DVDs) - I expect to have to use at least twenty or thirty and maybe even forty or fifty DVDs to do it since I have 40GB of media to back up and another 40GB of images to back up, plus several tens more gig of ebooks, documents, programs, etc. I'd use tape if I could afford it, but DVD is the only method I can afford.
I tend to back up only once since much of the stuff is retrievable from the Net. Also, since I back up individual files unarchived and uncompressed, the odds are I'll only lose a few images or something if a bad sector occurs. Thus I avoid having to use PARs - but that's only because little of the data is critical or hard to replace. I'm a bit more protective of my downloaded Corrs videos as they can be harder to replace depending on who's got them uploaded to a Web site at any given time.
But I'd be NUTS to archive and compress this stuff on DVD - one bad sector and I'd lose it all. Especially when DVD drives and media are so flakey - nobody can be sure any given media will work in any given drive. It's a major problem. I had to replace my last LiteOn DVD burner because it absolutely sucked at using even top of the line Taiyo Yuden media. Now I have a much better NEC drive. But who knows - it could go out at any time and the next drive I get might not read anything the NEC burned - more likely, I'd get bad sector reads from the NEC-burned media because of differences in the drives. I learned from the LiteOn experience - do NOT archive and compress.
On an enterprise scale, there may be times when you have to archive and compress. But I stick to the view that for critical data that MUST be restorable (as opposed to merely archived for legal reasons), keep it simple.
Totally obvious why MS is against it - they're the freakin' cause of the problem in the first place!
While users have the "right" to run an insecure PC, they certainly don't have any "right" to communicate with an ISP if their systems introduce malware or spam into the ISP's network. That should be obvious to anybody with a brain.
Does anybody think any corporation would deliberately allow their users to run insecure machines (leaving out simple incompetence - such as running Windows in the first place - on the part of the sys admins, of course)? So why should ISPs be any different? Just because they're offering a consumer service doesn't mean they don't have the "right" to remove that service when it is abused.
I don't agree with the Feds mandating this policy or trying to enforce it in their usual hamhanded way - and I'd be suspicious of their motives in any event - but I see no problem with ISPs enforcing such a policy. If an ISP abuses the policy - and I certainly would expect some to do that - they can easily go out of business and be replaced by someone more accommodating.
And that actually is why such a policy probably won't be enforced - it's too risky for most smaller ISPs that are operating on tight margins as it is. In fact, about the only way I would see it being enforced is if the larger ISPs tried to use it to force out some of the smaller ISPs. That would eventually backfire as well, but it could happen.
I'm aware that current backup systems try to make compression and archiving more reliable.
Now ask yourself: WHY do they do this? Answer: Because they KNOW it's a problem and they are trying to provide a solution.
Whether they are successful or not depends on whether you can afford their particular solution. For enterprise users, this may be fine. For smaller companies, relying on devices that do not provide this sort of safety net is not a good idea. For critical data, relying on the company to be RIGHT about whether their solution works is also risky. Why take the chance?
"a little corruption doesn't mean the entire archive is hosed. It does depend on the archiver to a degree, of course. And if you must do this before backing up to tape, you can include parity files to mitigate risk of corruption."
Right - show me the archiver which does NOT use some sort of parity system that can recover from corruption. I've NEVER had a damaged zip file be recovered by an archiver. They always fail. Your mileage may vary. I can believe that some zip archives can be recovered. My experience is not that promising.
And parity files are indeed a good idea. But they reduce the value of compression significantly if you set the parity high enough to insure recovery from even multiple errors. They also can make backup and recovery a more complicated process - that may be acceptable for the enhanced reliability of recovery, but again it adds to the cost of archiving and compression.
A double backup without compression is easier (at least for those situations where the required backup time can be met by a double backup.) You need to do two backups anyway - one for onsite, one for offsite - so why not take advantage of that need to enhance your reliability?
"Tape backups are pretty damned reliable these days, and very fast. You have to take care to pay attention to tape lifespan and any drive problems that might arise from time to time."
What's wrong with this picture? Do I need to say more? Well, I will anyway.
The two items you mention have been true since tape drives were introduced. And they are exactly why tape is not reliable. Granted, today's tape devices are much more sophisticated than the old nine-track devices. But the fundamental problem of tape - iron oxide being pulled past a reader - hasn't changed. Tape kinks, tape gets erased, tape gets bent, drives get out of spec, the list goes on and on.
Drop a hard drive? Irrelevant. Drop a tape? Irrelevant. Acidents happen and aren't relevant to the discussion.
And yes, you can take hard drives offsite. In fact, that's a very smart move. And one hard drive with 200GB will fit in a safe deposit box (we're talking small business here, not General Motors, for this concept) more easily than a bunch of tapes (granted some of the tape cartridges are damn small these days.)
Comparing the probability of bad media to lightning and nuclear weapons is just stupid. Bad media is very common - the latter aren't. Ignoring the point of backup being recovery is also not a very sophisticated debating technigue - not to mention ignoring the point of enterprise IT backup which is precisely recovery (and archiving for legal reasons.)
"There's even an LTO6 on the horizon that will be able to sustain 540MB/sec with 2:1 compression. Do you know how many SATA hard disk spindles you'd need to even come close to these figures?"
And do you know, Mr. Enterprise Expert, how fast ISCSI, Ultra640, and Fibre Channel SANs go? Try 200-640MBps.
Don't waste my time proving how little you know about enterprise backup. And I damn sure don't want you backing up MY enterprise with that kind of attitude about backup: save time, money and media - and lose the data.
"it usually lets you know, upon restoring, if anything was corrupted or not"
Gee, recovery time is really when I want to know if I have a corrupted backup... That's why one has to use checksum files or PARs - or back up twice (then you don't care as the odds of losing the same file on two backups is very small - unless the drive is failing in such a way as to record errors in the same spot on multiple media - very unlikely.)
And I'm not talking about bit errors in files - I'm talking about whole (sometimes multiple) sector read errors on the MEDIA. That's the show stopper for compressed archives. Bit errors are so rare it's not worth discussing.
I backup twice if the data is hard to recover from the Internet (ie., I have to hunt for it to get it back - such as video files I've downloaded from somewhere), but only once if the data is easily retrieved from elsewhere.
I've never lost a file doing two backups - even when my previous CD drive was screwing up regularly (my current DVD drives seem to be more reliable). I HAVE had bad sector reads on CDs that proved the value of backing up twice. If I had archived and compressed those files and then backed them up only once, I would have lost them. That's when I learned.
Don't know if anybody has tried running ZipGenius under WINE. I've heard 7-Zip can be run with WINE.
The nice thing about ZipGenius is I can download a tar.gz file while operating from my Windows side and unpack it and examine it without having to boot up Linux.
"Are you that ignorant of how backups work? Each file is compressed individually to tape or disk backup files."
That's how it works IF that's how it works.
Most people here are arguing for ARCHIVED backups that are THEN compressed.
I have no problem with individually compressing files - as long as the compression method used is standard and easily handled by decompression programs external to the backup software (because that can fail as well.) I have no problem with using standard zip or gzip compression tools to compress files individually for backup. The issue is the use of archives AND compression. That is just asking for trouble - one bad sector, the entire backup is hosed - unless other means of redundancy are provided.
Nobody is saying that compression BY ITSELF results in data corruption.
What we are saying is that compression aggravates the problem of MEDIA corruption.
That should have been obvious from the start. If it wasn't, my apologies - or I would apologize if this wasn't/.
And I agree - a standard tape backup isn't reliable and never has been. It's also too damn slow - which is why disk to disk backup is taking hold, especially given the per-byte cost of disks vs tape these days. When a tape holding 200GB costs $100, and an entire hard drive holding 160-200GB costs less than $100, given the relative speed, the use of tape is not very logical. The only advantage tape has is ease of mobility - which is also its greatest disadvantage since that's usually where it gets damaged (other than in poorly maintained drives.)
By the way, I have no objection to using compression to send data over the Net or a network - the protocols take care of reliability there (although I suppose there is a small chance of corruption as well which should be taken into consideration.)
"with a proper backup system and procedures, you'll never encounter a time when you'll have to reconstruct a corrupt file."
And this begs the question, which is - what IS a proper backup system and procedures? My point is that compression isn't. And if you have a proper system that does use compression, then most likely you're using such redundancy (multiple backups, PARs, etc.) that the actual value of the compression is much less than it seems to be.
I actually have no problem with compression if the redundancy is sufficient. In many cases, a simple double backup will be enough (although if your drives are failing, there is a small chance of getting a bad sector on both backups - if both backups have archived data, you've lost them both.) It all depends on the value of the data.
As I keep reiterating, the point of backup is RECOVERY. If you can't recover, because of compression or archiving, none of the justifications for using them are relevant.
"If you have the forensic expertise to recover a corrupted non-compressed file, changes are you'd also be able to recover the data from a compressed one."
This makes no sense at all. Most people don't have ANY "forensic expertise" - and it's far easier to recover data from an uncompressed backup than a compressed one.
Look, this is really very simple. You backup one file on two CDs. Both of them end up on the same sectors because the backup is identical. One of the CDs gets a bad sector so you can't retrieve that file (without external assistance either from the archive program or PAR files.) The other CD is not likely to have a bad sector ON THE SAME FILE (unless as I said, the file is big enough to take up at least fifty percent of the CD - which an archive of many files, no matter how compressed, is obviously more likely to do than any single file).
Therefore it is easier to prevent backup corruption by not compressing the backup (unless you want to go to the trouble of using PAR files - which ALSO have to be backed up and which are very large, thus significantly impacting the benefit of compression.)
PARs aren't ten percent of the file - they can be as big as the file itself if you're paranoid and need to recover multiple errors (not usually necessary, especially on CD media, although it can be using them to handle Internet-transmitted files.) If your PARs are 20-50% of your file, compression's value is reduced significantly. If you get 2:1 compression, you could end up with 1.5:1 or less. Which, added to the low cost of disk space and the dangers of corruption, makes it much less useful.
Speed of recovery is also impacted by compression - you have to uncompress those files before you can use ANY of them. Uncompressed files can be used immediately off the backup medium if necessary and can be restored individually more easily.
I'm aware that compression helps backup time. The proper solution for a corporate environment is enough backup servers to handle the job in the required time frame, or sufficiently high performance backup methods such as hot backups disk-to-disk followed by slower offline backups to tape (if the volume warrants.)
The reality is that many organizations have discovered that defects in media or drives result in totally lost archives that could have been prevented by backing up those files individually. And the cost of lost data is almost always higher than the time spent manipulating media or doing the backups in the first place.
I don't have a small shop mindset. I'm aware that some organizations are battling backing up data warehouses with several terabytes of storage using backup tools that at most handle a couple hundred gigabytes and which require almost the entire night to backup. In such situations, compression may be necessary. But I think the issue should be decided on the basis of the actual value of the backup vrs the nickel and diming of media cost and the time to backup. As I said, if the data is that valuable that it needs to be backed up nightly, then the cost of media and servers is irrelevant (c'mon, what does another server cost if you're a company with a petabyte of data?), and the time to backup obviously calls for more servers and a more effective backup method.
As for sending uncompressed files over the Net, obviously compression is useful there - I have no problem with that. The issue of whether it is necessary when doing a BACKUP over the Net is another matter. I can see compressing a backup in that situation because the cost of bandwidth can be significant, as well the fact that the data transfer rate is usually much slower than disk to disk. However, in some cases, it might still be better to decompress on the final storage side - again, it depends entirely on the value of the data and the cost of losing it.
The bottom line: the point of backup is RECOVERY. If you can't recover, none of your backup policies are relevant. And archiving and compressing backups increases the chance of losing the data. It's that simple. And for what? To save some time? To save some media which costs pennies per gigabyte?
"While your point is true that it MAY be more difficult to recover from a corrupt file, that's not the right methodology. If your backups are that valuable, you'd make multiple copies - plain and simple."
Two problems with your response:
1) If your data is that valuable, compressing makes it more likely to lose it.
2) If your data is that valuable, making two copies takes twice the time and space - even with compression - and if you use compression and get a bad sector, fifty percent of your backup is now useless. Sure, the odds are good that you can recover from the second backup - but if IT has a bad sector - even in a different place - possibly because your device is going bad - then you've lost the second backup as well.
If you backup more than once UNCOMPRESSED, you can recover almost anything because it is VERY unlikely that a bad sector will occur in the exact same spot or even in the same file (assuming the one file does not take up most of the specific media.)
If your data is valuable, back up twice uncompressed. If your data is only so-so valuable, back up twice compressed. If your data is easily replaced, back up once uncompressed. NEVER back up once compressed - you might as well not back up at all then.
Alternatively, use PAR files to recover - as long as you're willing to add the extra space and time - which sort of obviates the advantage of compression, doesn't it?
And if the only valid argument for compression is saving the cost of media, then obviously your data is less valuable than you think it is - in which case why bother backing it up at all (other than legal requirements)? The cost of media simply is not a factor in comparison to the cost of the time required to back it up, the cost of the time to restore if needed, and the value of the data itself. That is being "penny-wise and pound-foolish" - a typical attitude among geeks who are obsessed with efficiency over effectiveness. Save a few gigabytes of space and lose the data - yeah, that's real smart...
If you want to back up quickly and securely, have two devices backing up simultaneously uncompressed - or two devices backing up simultaneously compressed with PARs. You can't lose - it's that simple.
Compressing files intended for BACKUP, as opposed to DOWNLOAD, DOES increase the chance of losing the entire file. That was the poster's point and it is entirely correct.
NEVER use compression on a backup unless you have PAR files you can use to recover the lost data if a bad sector on a CD, DVD, or bad block on a tape is discovered on restoration.
The Disk Archive (DAR) program is one of the few backup programs that can generate PAR files during the backup.
That may be true, but they still need to fix the bugs first. The more people use the product, the more the bugs will become noticeable - and the worse the reputation backlash will be. As Firefox is a leading example of open source software, we need to prove it is a quality piece of work - and we need to prove that open source isn't just about geeks pursuing their own features list like some Microsoft marketing team...
A recent article elsewhere listed a number of problems reported by several hundred users of 1.5 - many of which I have experienced first hand.
While 1.5 doesn't slow down as quickly as the 1.07 when downloading images off the Net, it DOES slow down eventually and eat up all of Windows' virtual memory. Eventually it starts issuing "picture cannot be displayed due to errors" messages. In other words, severe memory leaks. These were supposed to be fixed in 1,5, but clearly have not been, although some may have been ameliorated somewhat.
It also seems to be slightly less stable than 1.07, with a slightly higher incidence of crashes (still thankfully relatively rare.)
If they start trying to add features to this code base, they'll get a rep for having a crappy browser on a par with IE 5. They need to fix these problems and fix them fast.
Since the exact technology (artifical neurons?) is not described in detail as to how they work, ascribing "self-awareness" to this experiment is "claiming too much."
Also, use of the word "understanding" may be claiming too much in the absence of any evidence of conceptual processing in either the neurons or the software.
Still, it's an interesting bit of work, which may prove useful if it can be extended.
"I doubt ANYBODY has ANY decent comprehensive concept of "how to expand humans throughout the solar system". That's pure "pie in the sky" unlikely to lead to any specific productive research projects.
On what do you base these doubts? Sure, the goal may sound a bit grandiose, but you gotta start somewhere. Nobody is seriously going to submit a grandiose plan to accomplish that goal in one fell swoop of research."
Why did they cite that then? Or was that from the article submitter? If nobody can successfully submit such a plan, why ask for grandiose ideas in the first place? Face it, nobody can possibly have any clear notion, let alone specific plans, for populating the solar system in anything less than the next fifty years. And one would presume NASA has already considered anything that could be considered rational in that arena anyway.
By the way, in case you haven't heard, nanotech IS regular science - in fact, it's more regular engineering than science, although a lot of new science is likely to be discovered in the process of developing it as well.
Perhaps I'm overreacting, I probably should read the details, but I got put off when somebody started talking about NASA looking for "geniuses with plans to populate the solar system." I can't take that stuff seriously. If NASA wants more serious proposals, fine.
OTOH, if they want budgets and time tables and results milestones, they're not likely to get many major breakthroughs that way, either. Major breakthroughs tend not to be budgetable or schedulable unless it's clear from the outset what direction to go in to get them.
I would say any serious work on conceptual processing, for instance, could produce useful results - if not a "breakthrough in AI" - within five years - but I wouldn't bet my life on it. If they want to pay me $50-100K a year for five years to work on that, I'd do it (as long as I own the copyright to the software, heh, heh - got to think of how to drop Billy Boy once I get it done, you know.)
Slashdot Mirror
The marketing muscle behind Intel must be SO brilliant, it blinds me!
"Leap Ahead" - Wow! The brilliance! The magnificence! The genius!
Anybody remember "The Road Ahead"?
And Linus's comment?
Here's a suggestion for Intel - use the slogan "Leap Without looking Ahead!" Then you can add "And Without Looking Back At Bill To See If He Approves"...
In other words, who gives a flying cockroach's ass what the Intel slogan is? It's a SLOGAN, morons!
Oops, the link doesn't work, let's try that again.
/. fucks up again! The word "gamma" is for some reason being split in the middle - "gam ma" - due to the morons who programmed Slashcode apparently. And I'm using "Plain Old Text" to submit this! Morons! "Check those URLs", indeed! Check your fucking code! This URL is perfectly good as I'm looking at it, you idiots! I've even REWRITTEN the fucking thing and you still can't handle it! Stupid, fucking geeks can't do anything right!
Ah, I see,
"5. Convert your program into opcodes and poke them into memory byte by byte (Opcode mnemonics are for candy-assed wimps.)"
m ma_30.htm/
Ah, a gentlemen who remembers the good ol' days of the MITS Altair! Flipping front panel switches to program!
I used to have to do this on an RCA 301, too. The funny part was that the internal encoding on that machine was...character! Yup - you could read characters directly out of the memory...character-oriented machine...weird...
You had to punch octal code into the console to run a program. The program itself could be in COBOL or Fortran on a tape drive. They even had a disk drive that had a platter the size of a car wheel that required a 30HP motor to spin it. We never got that to work (all this was surplus in the 1970's.)
Here's a description of the Bull version called the Gamma 30. http://www.feb-patrimoine.com/Histoire/english/ga
All the hot air from George Bush, Dick Cheney, Condi Rice and Don Rumsfeld is being secretly redirected into the magma to push up more material.
The government hopes causing a major eruption will divert news attention from the war in Iraq, spying on US citizens, the Katrina failures, the economy, global warming, the Republican Congressional bribe scandals, the outing of CIA agents for the benefit of Russian-Israeli Mafia nuclear black marketeers, the coming war with Iran, the...
So now that you're hit with the facts of the industry move to disk-to-disk, you're upset.
I didn't bother to add up GB from your post because I couldn't care less - and you were the one in such a hurry to drop my argument you mistyped your figures.
"they still use tapes." - Never said tapes weren't useful as archival. I also said that while offsite backup via network was useful, it was costly and suitable only for those who can afford it relative to other means of offsite transport. So you're being redundant again.
As for compression, they probably use Content Optimization, which was another focus of the article. While this is a form of compression, it's a more reliable form (although I'm sure they use regular compression as well - that wasn't my point in this case - the point was disk-to-disk is replacing tape for the purpose I cited - local emergency restoration. And it is.)
Expensive spinning disks? Jesus, you are cheap, aren't you? Complaining about the power cost to spin drives - many of which probably aren't spinning at all until they're backed up to. Compared to the value of the data and the obvious value of quick efficient restoration in the event of primary system failure, power costs are not relevant to these people, obviously. And disks spin whether they're used for backup or not. They outlast tape drives in longevity, too. I don't know how many times I've heard people say that, at least the cheaper tape drives, if not the really expensive ones, barely last a year.
The quote does not rehash anything you said, it clearly explains my points about disk-to-disk. The only thing it says about archiving and compression, however, is that TAPES FAIL - which is why I say don't use archiving and compression together.
Last night I received a confirmation of my policy: I was changing my partition structure on my home system, and had to wipe and restore a partition from a backup made yesterday as well. That went okay, even though it was some 11 DVDs with 250,000 files. I then decided to restore some data I'd taken off to make room last year, about 3GB worth that would be hard to replace should it be lost. That data was backed up on the old LiteOn DVD drive that was flaky.
Restoring it on the newer NEC drive, sure enough, a bad sector read caused one of the two DVDs to fail to restore one or more files. Since I'd had the foresight to back up the data twice, I used the second DVD to restore the missing files. And this was even with individual uncompressed unarchived files. Had I backed up with archiving and compression (and no PARs or other redundancy), I would have lost 3GB of data.
That says it all. There isn't anything more to be said.
You can't compare media to disk just on capacity. When I say $100 per media is bad compared to disk, that means the media is worthless without the drive. The $100 disk IS the drive. You have to ADD the cost of media to the cost of the drive. How many of those 400GB tape cartridges does somebody need? Add that to the cost of the drives.
14 100GB drives at $800 apiece - nice, ignore the 300GB drives out now. Cut the cost by a factor of three, doesn't it? That's simple math, too.
I never said disk made sense for long-term storage. I said you CAN take it offsite for offsite storage. I didn't say how long. Disk drives have stiction problems when not used for a long time; tape has tensioning problems and heat and humidity problems if not stored properly. Long-term storage is another issue entirely than storage for restoration purposes. Again, I'm not talking about archival storage, as I said repeatedly; tape is adequate for that and that's all it should be used for in my opinion - and in the opinion of a lot of other people these days who advise on enterprise IT.
When I said redundancy, I refer to either PAR files or multiple backups of the same data. If the data is critical, you'd better have one or the other - and no matter whether you use disk or tape. That's the original point of discussion. If you use archiving and compression together, you damn sure better have redundancy if the data is critical, i.e., data that absolutely has to be there if it needs to be restored.
Yes, I really do mean backing up individual files (compressed or not depends on the criticality of the individual files) to disk without archiving and compression. You have to read the freakin' files to compress them, it's far faster and more reliable to just back up the entire file. Yes, it eats up space - which is only important to a home user like me who has to pay for DVDs. For corporate data, the media cost is irrelevant to the value of the data (again, distinguishing between critical data and purely archival data.)
Your entire argument is about cost, about time savings, about this and that - and has nothing to do with the core issue - making sure that data can be recovered when it is needed.
Here's the bottom line I found on the Net which sums it all up pretty well:
"Diogenes Analytical Laboratories, an IT advisory company that performs independent product lab evaluations and advises IT buyers, estimated that, on average, between 5 and 20 percent of nightly tape-based backup/recovery jobs fail. According to ESG, roughly one-fourth of SMB users reported that 20 percent or more of their tape-based backup/recovery jobs fail. The number one reason cited: media failure (e.g., lost, damaged or corrupted tapes).
In addition to media failure, there is the high percentage of operational errors, including operator (human) errors such as storing the wrong tape, and procedural errors such as backing up wrong or empty files. Any time there is human intervention, the opportunity for error increases dramatically.
Analysts generally agree that IT management costs represent five to seven times the cost of capital expenditure. It is therefore essential to consider operation and administrative costs (including media management and tape swapping) in addition to acquisition costs when doing a financial analysis of tape versus alternatives. For large organizations, the tape media costs (which generally come out of the expense budget versus capital budget) mount up as well...
For a simple cost comparison, W. Curtis Preston offers this scenario: a midrange tape library costs roughly $4 to $11 per gigabyte (GB) while disk prices are hovering around $3 to $11 per GB. This puts disk and tape about even (excluding reliability and recovery time factors).
Capacity Optimization
Perhaps the most significant change in cost comparison comes from the introduction of a new technology which some have named capacity optimization (CO). Also called data reduction, disk deduplication, or commonality factoring,
Enterprises send backups offsite all the time. You can just as easily pull a bunch of removable drives and send them offsite as you can a bunch of tape. That's just a matter of organization. This is irrelevant, however, because in most cases you backup to SANs for LOCAL restoration, then backup to tape from the SAN for offsite archival storage (or last-ditch restoration if your building blows up.) (That, or you send the data over a commo link to another site for storage as tape or disk.)
Neither of which is relevant to the archive/compression discussion. The issue is should the backup be archived and compressed rather than stored as individual (compressed or not) files.
As for single drives running at tape speeds, what did I say? The new SCSI standards do just that.
Also, exactly how expensive are these wonderful tape drives you refer to? Compare the cost of them to the cost of even an expensive SCSI drive. You want to save money by replacing an eight hundred dollar 300GB SCSI enterprise class hard drive with a FOUR THOUSAND DOLLAR 400GB (WITH COMPRESSION) Quantum LTO-3 tape drive? Good luck with that!
And that doesn't count the cost of the media at $100 a pop! I can buy an entire (ATA) drive for that!
Also, why do you think Quantum is making hard disk backup systems now? Because the market is demanding it, that's why.
Once again, you compare accidents to compression. Accidents are just that - accidents. Archiving/compressing is deliberately INVITING data loss. That's a difference.
I said nothing about taking SANs offsite. I'm talking about backing up to SANs for local restoration and in specific response to your ignorant statement that tape is faster than hard drives - which is bullshit. And if tape IS faster than hard drives, then why the hell is time to backup being better with compression your primary argument? If tape is so fast, then you don't need compression, so why not gain the extra reliability?
"Hard drives never go bad." I never said that. However, hard drives ARE far more reliable than tape - especially if they are only being used for backup. While modern tape systems are far better than the old nine-track - as I SAID - they are still far from completely reliable.
"Forensic bit-recovery is better then a sound backup and recovery practice."
Never said that for an instant. You might try rereading my posts. What I said was that sound backup and recovery practice precludes using archiving and compression together for critical data - and if you do it, you'd better have redundancy built in which means PAR files which means increased complexity and cost for the dubious benefits of archiving and compression.
I also said that the value of data to be restored outweighs the minor cost savings of media and time achievable with archiving/compression - points you have done nothing to dispell and everything to ignore.
"Actually, they're quite common. However, your drives (tape, CD, DVD, hard, etc.) typically have some error correction built in."
That's why I said they aren't worth talking about. It's rare for a bit error to not be corrected automatically and it's rare for a bit error to actually matter given the size and organization of most files today. Unless it causes a program crash, most of the time it's just a glitch in a video or audio stream that is ignored.
"Being able to recover from an error is a good thing -- but it's also important to actually know that there was an error..."
I still don't know what the hell you're talking about here. If you're talking about errors in data that DON'T cause a failure of the system but merely corrupt the data, then your statement makes sense - but is irrelevant to the discussion. I'm talking about errors that prevent restoration of the data - which, again, is the point of backup - to get the data back if it is lost. I'm not concerned about simple data corruption that doesn't cause a restore failure because, as you say, most of the time that is corrected by other mechanisms in the system. I'm concerned about data corruption that causes loss of data by being unable to restore it to replace data already lost elsewhere.
Today I'm backing up my system again (haven't done it for months since it IS a painful process with just DVDs) - I expect to have to use at least twenty or thirty and maybe even forty or fifty DVDs to do it since I have 40GB of media to back up and another 40GB of images to back up, plus several tens more gig of ebooks, documents, programs, etc. I'd use tape if I could afford it, but DVD is the only method I can afford.
I tend to back up only once since much of the stuff is retrievable from the Net. Also, since I back up individual files unarchived and uncompressed, the odds are I'll only lose a few images or something if a bad sector occurs. Thus I avoid having to use PARs - but that's only because little of the data is critical or hard to replace. I'm a bit more protective of my downloaded Corrs videos as they can be harder to replace depending on who's got them uploaded to a Web site at any given time.
But I'd be NUTS to archive and compress this stuff on DVD - one bad sector and I'd lose it all. Especially when DVD drives and media are so flakey - nobody can be sure any given media will work in any given drive. It's a major problem. I had to replace my last LiteOn DVD burner because it absolutely sucked at using even top of the line Taiyo Yuden media. Now I have a much better NEC drive. But who knows - it could go out at any time and the next drive I get might not read anything the NEC burned - more likely, I'd get bad sector reads from the NEC-burned media because of differences in the drives. I learned from the LiteOn experience - do NOT archive and compress.
On an enterprise scale, there may be times when you have to archive and compress. But I stick to the view that for critical data that MUST be restorable (as opposed to merely archived for legal reasons), keep it simple.
You're absolutely right!
Totally obvious why MS is against it - they're the freakin' cause of the problem in the first place!
While users have the "right" to run an insecure PC, they certainly don't have any "right" to communicate with an ISP if their systems introduce malware or spam into the ISP's network. That should be obvious to anybody with a brain.
Does anybody think any corporation would deliberately allow their users to run insecure machines (leaving out simple incompetence - such as running Windows in the first place - on the part of the sys admins, of course)? So why should ISPs be any different? Just because they're offering a consumer service doesn't mean they don't have the "right" to remove that service when it is abused.
I don't agree with the Feds mandating this policy or trying to enforce it in their usual hamhanded way - and I'd be suspicious of their motives in any event - but I see no problem with ISPs enforcing such a policy. If an ISP abuses the policy - and I certainly would expect some to do that - they can easily go out of business and be replaced by someone more accommodating.
And that actually is why such a policy probably won't be enforced - it's too risky for most smaller ISPs that are operating on tight margins as it is. In fact, about the only way I would see it being enforced is if the larger ISPs tried to use it to force out some of the smaller ISPs. That would eventually backfire as well, but it could happen.
I'm aware that current backup systems try to make compression and archiving more reliable.
Now ask yourself: WHY do they do this? Answer: Because they KNOW it's a problem and they are trying to provide a solution.
Whether they are successful or not depends on whether you can afford their particular solution. For enterprise users, this may be fine. For smaller companies, relying on devices that do not provide this sort of safety net is not a good idea. For critical data, relying on the company to be RIGHT about whether their solution works is also risky. Why take the chance?
"a little corruption doesn't mean the entire archive is hosed. It does depend on the archiver to a degree, of course. And if you must do this before backing up to tape, you can include parity files to mitigate risk of corruption."
Right - show me the archiver which does NOT use some sort of parity system that can recover from corruption. I've NEVER had a damaged zip file be recovered by an archiver. They always fail. Your mileage may vary. I can believe that some zip archives can be recovered. My experience is not that promising.
And parity files are indeed a good idea. But they reduce the value of compression significantly if you set the parity high enough to insure recovery from even multiple errors. They also can make backup and recovery a more complicated process - that may be acceptable for the enhanced reliability of recovery, but again it adds to the cost of archiving and compression.
A double backup without compression is easier (at least for those situations where the required backup time can be met by a double backup.) You need to do two backups anyway - one for onsite, one for offsite - so why not take advantage of that need to enhance your reliability?
"Tape backups are pretty damned reliable these days, and very fast. You have to take care to pay attention to tape lifespan and any drive problems that might arise from time to time."
What's wrong with this picture? Do I need to say more? Well, I will anyway.
The two items you mention have been true since tape drives were introduced. And they are exactly why tape is not reliable. Granted, today's tape devices are much more sophisticated than the old nine-track devices. But the fundamental problem of tape - iron oxide being pulled past a reader - hasn't changed. Tape kinks, tape gets erased, tape gets bent, drives get out of spec, the list goes on and on.
Drop a hard drive? Irrelevant. Drop a tape? Irrelevant. Acidents happen and aren't relevant to the discussion.
And yes, you can take hard drives offsite. In fact, that's a very smart move. And one hard drive with 200GB will fit in a safe deposit box (we're talking small business here, not General Motors, for this concept) more easily than a bunch of tapes (granted some of the tape cartridges are damn small these days.)
Comparing the probability of bad media to lightning and nuclear weapons is just stupid. Bad media is very common - the latter aren't. Ignoring the point of backup being recovery is also not a very sophisticated debating technigue - not to mention ignoring the point of enterprise IT backup which is precisely recovery (and archiving for legal reasons.)
"There's even an LTO6 on the horizon that will be able to sustain 540MB/sec with 2:1 compression. Do you know how many SATA hard disk spindles you'd need to even come close to these figures?"
And do you know, Mr. Enterprise Expert, how fast ISCSI, Ultra640, and Fibre Channel SANs go? Try 200-640MBps.
Don't waste my time proving how little you know about enterprise backup. And I damn sure don't want you backing up MY enterprise with that kind of attitude about backup: save time, money and media - and lose the data.
"it usually lets you know, upon restoring, if anything was corrupted or not"
Gee, recovery time is really when I want to know if I have a corrupted backup... That's why one has to use checksum files or PARs - or back up twice (then you don't care as the odds of losing the same file on two backups is very small - unless the drive is failing in such a way as to record errors in the same spot on multiple media - very unlikely.)
And I'm not talking about bit errors in files - I'm talking about whole (sometimes multiple) sector read errors on the MEDIA. That's the show stopper for compressed archives. Bit errors are so rare it's not worth discussing.
I backup twice if the data is hard to recover from the Internet (ie., I have to hunt for it to get it back - such as video files I've downloaded from somewhere), but only once if the data is easily retrieved from elsewhere.
I've never lost a file doing two backups - even when my previous CD drive was screwing up regularly (my current DVD drives seem to be more reliable). I HAVE had bad sector reads on CDs that proved the value of backing up twice. If I had archived and compressed those files and then backed them up only once, I would have lost them. That's when I learned.
Don't know if anybody has tried running ZipGenius under WINE. I've heard 7-Zip can be run with WINE.
The nice thing about ZipGenius is I can download a tar.gz file while operating from my Windows side and unpack it and examine it without having to boot up Linux.
There's a version of DAR for Windows, which uses the Cygwin DLL to allow it to run under Windows.
The main DAR home page has a link to the Sourceforge page where you can get a Zip file package for Windows.
The only complexity is that even under Windows, you have to give DAR filenames with forward slashes imbedded instead of back slashes like Windows.
"Are you that ignorant of how backups work? Each file is compressed individually to tape or disk backup files."
That's how it works IF that's how it works.
Most people here are arguing for ARCHIVED backups that are THEN compressed.
I have no problem with individually compressing files - as long as the compression method used is standard and easily handled by decompression programs external to the backup software (because that can fail as well.) I have no problem with using standard zip or gzip compression tools to compress files individually for backup. The issue is the use of archives AND compression. That is just asking for trouble - one bad sector, the entire backup is hosed - unless other means of redundancy are provided.
Nobody is saying that compression BY ITSELF results in data corruption.
What we are saying is that compression aggravates the problem of MEDIA corruption.
That should have been obvious from the start. If it wasn't, my apologies - or I would apologize if this wasn't
And I agree - a standard tape backup isn't reliable and never has been. It's also too damn slow - which is why disk to disk backup is taking hold, especially given the per-byte cost of disks vs tape these days. When a tape holding 200GB costs $100, and an entire hard drive holding 160-200GB costs less than $100, given the relative speed, the use of tape is not very logical. The only advantage tape has is ease of mobility - which is also its greatest disadvantage since that's usually where it gets damaged (other than in poorly maintained drives.)
By the way, I have no objection to using compression to send data over the Net or a network - the protocols take care of reliability there (although I suppose there is a small chance of corruption as well which should be taken into consideration.)
"with a proper backup system and procedures, you'll never encounter a time when you'll have to reconstruct a corrupt file."
And this begs the question, which is - what IS a proper backup system and procedures? My point is that compression isn't. And if you have a proper system that does use compression, then most likely you're using such redundancy (multiple backups, PARs, etc.) that the actual value of the compression is much less than it seems to be.
I actually have no problem with compression if the redundancy is sufficient. In many cases, a simple double backup will be enough (although if your drives are failing, there is a small chance of getting a bad sector on both backups - if both backups have archived data, you've lost them both.) It all depends on the value of the data.
As I keep reiterating, the point of backup is RECOVERY. If you can't recover, because of compression or archiving, none of the justifications for using them are relevant.
"since you'll know if corruption occured due to errors in decompression. Otherwise, you might not have as much fair warning."
Oh, brilliant. Gee, I really wanna backup so I can find out the backup is no good...
The point of backup is RECOVERY. If you can't recover, it does you absolutely no good to realize you have a corrupted backup. Get a clue.
"You do realize that we're talking lossless compression, not lossy (like JPEG) compression?"
You do realize we're talking about media corruption, not backup software corruption?
"If you have the forensic expertise to recover a corrupted non-compressed file, changes are you'd also be able to recover the data from a compressed one."
This makes no sense at all. Most people don't have ANY "forensic expertise" - and it's far easier to recover data from an uncompressed backup than a compressed one.
Look, this is really very simple. You backup one file on two CDs. Both of them end up on the same sectors because the backup is identical. One of the CDs gets a bad sector so you can't retrieve that file (without external assistance either from the archive program or PAR files.) The other CD is not likely to have a bad sector ON THE SAME FILE (unless as I said, the file is big enough to take up at least fifty percent of the CD - which an archive of many files, no matter how compressed, is obviously more likely to do than any single file).
Therefore it is easier to prevent backup corruption by not compressing the backup (unless you want to go to the trouble of using PAR files - which ALSO have to be backed up and which are very large, thus significantly impacting the benefit of compression.)
PARs aren't ten percent of the file - they can be as big as the file itself if you're paranoid and need to recover multiple errors (not usually necessary, especially on CD media, although it can be using them to handle Internet-transmitted files.) If your PARs are 20-50% of your file, compression's value is reduced significantly. If you get 2:1 compression, you could end up with 1.5:1 or less. Which, added to the low cost of disk space and the dangers of corruption, makes it much less useful.
Speed of recovery is also impacted by compression - you have to uncompress those files before you can use ANY of them. Uncompressed files can be used immediately off the backup medium if necessary and can be restored individually more easily.
I'm aware that compression helps backup time. The proper solution for a corporate environment is enough backup servers to handle the job in the required time frame, or sufficiently high performance backup methods such as hot backups disk-to-disk followed by slower offline backups to tape (if the volume warrants.)
The reality is that many organizations have discovered that defects in media or drives result in totally lost archives that could have been prevented by backing up those files individually. And the cost of lost data is almost always higher than the time spent manipulating media or doing the backups in the first place.
I don't have a small shop mindset. I'm aware that some organizations are battling backing up data warehouses with several terabytes of storage using backup tools that at most handle a couple hundred gigabytes and which require almost the entire night to backup. In such situations, compression may be necessary. But I think the issue should be decided on the basis of the actual value of the backup vrs the nickel and diming of media cost and the time to backup. As I said, if the data is that valuable that it needs to be backed up nightly, then the cost of media and servers is irrelevant (c'mon, what does another server cost if you're a company with a petabyte of data?), and the time to backup obviously calls for more servers and a more effective backup method.
As for sending uncompressed files over the Net, obviously compression is useful there - I have no problem with that. The issue of whether it is necessary when doing a BACKUP over the Net is another matter. I can see compressing a backup in that situation because the cost of bandwidth can be significant, as well the fact that the data transfer rate is usually much slower than disk to disk. However, in some cases, it might still be better to decompress on the final storage side - again, it depends entirely on the value of the data and the cost of losing it.
The bottom line: the point of backup is RECOVERY. If you can't recover, none of your backup policies are relevant. And archiving and compressing backups increases the chance of losing the data. It's that simple. And for what? To save some time? To save some media which costs pennies per gigabyte?
Proprietary, costs money...
I use ZipGenius - handles 20 compression formats including RAR, ACE, JAR, TAR, GZ, BZ, ARJ, CAB, LHA, LZH, RPM, 7-Zip, OpenOffice/StarOffice Zip files, UPX, tc.
You can encrypt files with one of four algorhythms (CZIP, Blowfish, Twofish, Rijndael AES).
If you set an antivirus path in ZipGenius options, the program will prompt you to perform an AV scan before running the selected file.
It has an FTP client, TWAIN device image importing, file splitting, convert RAR into SFX, converts any Zip archive into an ISO image file, etc.
And it's totally free.
"While your point is true that it MAY be more difficult to recover from a corrupt file, that's not the right methodology. If your backups are that valuable, you'd make multiple copies - plain and simple."
Two problems with your response:
1) If your data is that valuable, compressing makes it more likely to lose it.
2) If your data is that valuable, making two copies takes twice the time and space - even with compression - and if you use compression and get a bad sector, fifty percent of your backup is now useless. Sure, the odds are good that you can recover from the second backup - but if IT has a bad sector - even in a different place - possibly because your device is going bad - then you've lost the second backup as well.
If you backup more than once UNCOMPRESSED, you can recover almost anything because it is VERY unlikely that a bad sector will occur in the exact same spot or even in the same file (assuming the one file does not take up most of the specific media.)
If your data is valuable, back up twice uncompressed. If your data is only so-so valuable, back up twice compressed. If your data is easily replaced, back up once uncompressed. NEVER back up once compressed - you might as well not back up at all then.
Alternatively, use PAR files to recover - as long as you're willing to add the extra space and time - which sort of obviates the advantage of compression, doesn't it?
And if the only valid argument for compression is saving the cost of media, then obviously your data is less valuable than you think it is - in which case why bother backing it up at all (other than legal requirements)? The cost of media simply is not a factor in comparison to the cost of the time required to back it up, the cost of the time to restore if needed, and the value of the data itself. That is being "penny-wise and pound-foolish" - a typical attitude among geeks who are obsessed with efficiency over effectiveness. Save a few gigabytes of space and lose the data - yeah, that's real smart...
If you want to back up quickly and securely, have two devices backing up simultaneously uncompressed - or two devices backing up simultaneously compressed with PARs. You can't lose - it's that simple.
Compressing files intended for BACKUP, as opposed to DOWNLOAD, DOES increase the chance of losing the entire file. That was the poster's point and it is entirely correct.
NEVER use compression on a backup unless you have PAR files you can use to recover the lost data if a bad sector on a CD, DVD, or bad block on a tape is discovered on restoration.
The Disk Archive (DAR) program is one of the few backup programs that can generate PAR files during the backup.
That may be true, but they still need to fix the bugs first. The more people use the product, the more the bugs will become noticeable - and the worse the reputation backlash will be. As Firefox is a leading example of open source software, we need to prove it is a quality piece of work - and we need to prove that open source isn't just about geeks pursuing their own features list like some Microsoft marketing team...
A recent article elsewhere listed a number of problems reported by several hundred users of 1.5 - many of which I have experienced first hand.
While 1.5 doesn't slow down as quickly as the 1.07 when downloading images off the Net, it DOES slow down eventually and eat up all of Windows' virtual memory. Eventually it starts issuing "picture cannot be displayed due to errors" messages. In other words, severe memory leaks. These were supposed to be fixed in 1,5, but clearly have not been, although some may have been ameliorated somewhat.
It also seems to be slightly less stable than 1.07, with a slightly higher incidence of crashes (still thankfully relatively rare.)
If they start trying to add features to this code base, they'll get a rep for having a crappy browser on a par with IE 5. They need to fix these problems and fix them fast.
Since the exact technology (artifical neurons?) is not described in detail as to how they work, ascribing "self-awareness" to this experiment is "claiming too much."
Also, use of the word "understanding" may be claiming too much in the absence of any evidence of conceptual processing in either the neurons or the software.
Still, it's an interesting bit of work, which may prove useful if it can be extended.
"I doubt ANYBODY has ANY decent comprehensive concept of "how to expand humans throughout the solar system". That's pure "pie in the sky" unlikely to lead to any specific productive research projects.
On what do you base these doubts? Sure, the goal may sound a bit grandiose, but you gotta start somewhere. Nobody is seriously going to submit a grandiose plan to accomplish that goal in one fell swoop of research."
Why did they cite that then? Or was that from the article submitter? If nobody can successfully submit such a plan, why ask for grandiose ideas in the first place? Face it, nobody can possibly have any clear notion, let alone specific plans, for populating the solar system in anything less than the next fifty years. And one would presume NASA has already considered anything that could be considered rational in that arena anyway.
By the way, in case you haven't heard, nanotech IS regular science - in fact, it's more regular engineering than science, although a lot of new science is likely to be discovered in the process of developing it as well.
Perhaps I'm overreacting, I probably should read the details, but I got put off when somebody started talking about NASA looking for "geniuses with plans to populate the solar system." I can't take that stuff seriously. If NASA wants more serious proposals, fine.
OTOH, if they want budgets and time tables and results milestones, they're not likely to get many major breakthroughs that way, either. Major breakthroughs tend not to be budgetable or schedulable unless it's clear from the outset what direction to go in to get them.
I would say any serious work on conceptual processing, for instance, could produce useful results - if not a "breakthrough in AI" - within five years - but I wouldn't bet my life on it. If they want to pay me $50-100K a year for five years to work on that, I'd do it (as long as I own the copyright to the software, heh, heh - got to think of how to drop Billy Boy once I get it done, you know.)