Slashdot Mirror
PKWare Zips to Growth
Rob Kennedy writes "The Milwaukee Journal Sentinel has a story about PKWare's new business plan. It talks about the investment group that bought the company after founder Phil Katz's death in 2000, and the plan for PKWare to produce what president and COO Timothy H. Kennedy (no relation) calls 'the next generation of zip' by adding various security features."
So none of you guys can find out whats really in my porn.zip??
Might these security features include paying per zip file or something?
When I PGP a file, it shrinks to same or smaller than when I standard zip it. Isn't that secure / small? Or am I horribly confused?
Since a Zip has to be decompressed anyway it makes a lot of sense to integrate encryption. It's easier to unzip once compared to unzipping and then unencrypting or vice versa.
:)
Now, integrate this with email attachments and we're on a roll
.: Max Romantschuk
Most of the files I want to send are not going to compress to well in the fisrt place. Nowhere near enough entropy. The only files that will actually benefit are source code and binary executeables.
Okay, there may be some specialised industry data formats for microchips and the like, but the really large files tendto be things like pictures and videos. These are already compressed using standard lossy techniques. zipping these won't work.
1) replace rot13 with xor
2) ???
3) profit!!!
They need a new name. PKIWare :)
From the article:
PKWare no longer sells its products as shareware.
Is this a good idea? I believe that shareware is the only way to get your product known to all computer users (apart from bundeling it with Microsoft Office). There are not that many computer users that still known PKWare, and when this strategy is followed, that won't change.
- global password (for the filelist)
- per file(s) password(s) (for groups or individual files)
- version management (store changes, but keep the original)
- signing (both global and for file(s))
- execution abilities (oops, could trigger viruses, must be signed, but for example decompress files and compile 'em)
What I would also like is for them to go open source and actively support *nix (including Linux and MacOS X).One of the coolest moments of the many GenCon Game Fair's that I attended in Miwaukee, WI was when a panel consisting of most of the premiere Origin producers including Richard Garriot and Warren Spector took a question from the crowd during the Q&A session and when the nervous speaker said, "Well I have a programming question...and...um.. well I'm from a little company in town...do you know PKWare?"
And all the members of the panel looked at one another and then started doing the Wayne's World bow and chanting, "We're not worthy! We're not worthy!"
Then Warren (if I remember correctly) made a mildly sarcastic and admonishing comment towards the poor PKWare dude along the lines of, "Hey man you guys have saved us tons of money on media. We use Zip all the time. Of course we know your company." (games of the era were beginning to approach some 30 floppy discs compressed and CD-ROM had not yet become an affordable alternative)
It's nice when a little mostly unkown (at the time) company making software compression utilities gets recognition from a (at the time) powerhouse game development company like that.
Once more unto the breach dear friends...
cs94_002.tar.bz2 (Source) 10.7Meg,
cs94_002.tar.gz (Source) 12.6Meg,
cs94_002.zip (Source) 16.7Meg
As a side note, winrar will extract bzip2 but not create it.
Religion is a gateway psychosis. -- Dave Foley
The .zip format has great inroads into the corporate world, whereas PGP is still a geek's toy. By leveraging (cough) the massive usage numbers, they could be successful with this. Of course, it remains to be seen what features they want to add. But enough zip files fly around corporate networks without security, that it does make sense to improve PKZip in that area.
On the other hand, WinZip has a a head start, as the preferred way to deal with zip files for most people. And the PKWare website seems to come up blank on Mozilla, not an encouraging sign.
But what I really want is security for my PDA data, so it is secure over the network, and secure on the hard drive of any PC, even a PC that others have access to. Can zip help with this? Not sure.
Fair point, encryption and compression are commonly used together, but I still have my doubts about bundling functions into a single (bloating) app in this way.
These programs are essentailly filters and the most logical and flexible way to provide them is as seperate entities.
For folks who want to combine them: use a script, or a GUI or a simple wrapper app to hide the details - none of this is procluded by keeping the logically different functions involved seperate and independently usable at a lower level.
Reginald Molehusband. Edinburgh, Scotland
A corporation built on "tar -cf - . | gzip | crypt". And people wonder why TCO for Windows systems is so high.
By the guy who did ARJ, JAR implimeneted GOST as it's encryption.
It's Christmas everyday with BitTorrent.
PKWare promoted their GUI'd version of PKZip way too late into the game. Winzip already dominated the windows audience, which is already a big chunk in itself. PKUnzip will always hold a special place...those were the days.
.smell my feet.
Hah. He took the established ARC format, which had copyrighted free-as-in-beer public domain routines in C, and rewrote them in x86 asm for speed... and then sold PKARC (Phil Katz ARC) as a commercial product. The original inventors of ARC sued him and won - he even kept the same misspellings in the strings, for fuck's sake. He settled for a lump sum in court, then ended up making a couple of changes to the ARC format and renamed it PKZip.
That, and if you actually look at the ZIP format, you'll notice that it's all routines invented by other people. "Shrink" is dynamic LZW, "Reduce" is RLE with a second-pass probabalistic encoder, and "Implode" is a sliding dictionary with post-compression using Huffman/SF-tree encoding.
Katz was an excellent promotor and had good networking skills. I admire him for that much, and for establishing a defacto format that scaled nicely to 64-bit sizes and arbitrary-length Unicode filenames. HOWEVER, he was hardly a pioneer in compression algorithm design. Give him credit where credit is due.
Hopefully, if this is what they want to do, they will do better than the embarrasingly insecure "encryption" that the old DOS PKZip included (a cryptographically-weak LFSR-based stream cipher). With good support for cryptographic standards, they could have something here.
By the way, you always do encryption AFTER data compression. Doing it before data compression ensures that your compression ratio is close to 0%.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
Growth means increase. Either of revenue, or profits... Is there even one word of real as opposed to expected growth for PKWare? Will the new format even be compatible with .zip???
In my book, the article can be resumed to:
1. Build a better .zip format
2. ???
3. Profit
It is the ??? the /. community should analyse, not the bullshit marketing.
Mother is the best bet and don't let Satan draw you too fast.
So are these security features for the users, as everyone seems to be assuming, or for the content producers? Incorporating DRM into zipping would be a good way of placing speedbumnps on various P2P sharing systems.
The company's sales efforts are now focused on corporate customers.
And why companies should listen:
The company has crafted a new partnership with RSA Security Inc., which will lead to merging zip capability with security features in the same programs.
Maybe that'll be enough.
I'm pretty sure the shareware business model for these guys would be dead anyway whatwith some other competitors being so well known and wide spread there days. Can you say "WinZip"? (Yuck, bad, bad program.)
From the article:
/. to come up with a better paragraph than this.
"Eventually his personal problems caught up with him. Struggling with chronic alcoholism, Katz was estranged from his family and often hung out with strippers. He turned into a recluse, often avoiding his posh Mequon condominium and staying in cheap hotels instead."
You couldn't pay the trolls on
graspee
Like to see an effective stream compression system... That way mebbe one day we can actually SEE the REAL sites that have been slashdotted!!
Now watch this drive.
From what I've read, compression helps, but not much because most compression algorhitms generate some very predictable data. For example, ZIP files begin with "PK". That alone could be enough to help decryption.
You must mean Hildegard Katz, Phil's mom, who was the VP of PKWare.
There used to be a photo on the wall of PKWare's boardroom that said volumes... It showed a beautifully done show-booth at some convention, with Phil buried in a laptop on a small podium completely ignoring all the convention-goers milling around him.
If anyone promoted and networked for PKWare, it probably wasn't Phil.
I tested bzip2 on some lossy compressed data I was working on, and it was faster than pretty much anything except LZO, which compressed alot worse.
gzip -9 was about 8.7 seconds, bzip2 -5 was about 8.1 seconds, and compressed 60% better.
I also tried rar, ace, everything 7zip supports, dmc, lzo, lzw... bzip won out by far overall. Maybe it's just quirks in the test data?
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
Well the other reason for doing encryption after compression, is to mitigate dictionary attacks. So the cost of breaking in by brute force includes both decryption as well as decompressing.
kinda seems like having curtains in your house but never pulling the down; someone may not be able to 'get at' your stuff but they can see everything you have.
Winter 2010: With Glowing Hearts
Am I dreaming? Certenly not! My old RiscOS did this, like, TEN YEARS AGO!. The zip files were handled just like any other folder/directory. Then you could use the OS standard access control and version managment. (Put a cvs repository inside zipped filesystem?) But somehow I think this isn't so important anymore, in times of 100GB hard drives.
J.
the future of winzip is basically death since zip compression in browsing s built into xp
/var/db/pkg/pkzip-2.5
pkzip is still a command line utility elsewhere
drwxr-xr-x 2 root wheel 512 Oct 11 09:06
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Yeah, the cipher was pretty weak. Interested people might like to read the paper A Known Plaintext Attack on the PKZIP Stream Cipher by Biham and Kocher. Esentially, a string of 13 known bytes and a few hours on a good PC will decrypt the rest of the file.
But what's even worse, imho, is the horribly bad implementation. They encrypted only the file contents; file name, size and (what were they thinking?) the CRC were all in the clear. If you were using encryption to hide the fact that you possess a file you're not meant to, Pkzip will do you in real nice.
All in all an excellent example of how crypto works not.
Alex
Heisenberg may have been here
Now that the RSA patent has expired, why does anyone bother with RSA Security, Inc. anymore? RSA, Inc's crypto software was widely regarded to be poorly implemented and slow. According to my (limited) understanding, nearly everyone serious about crypto purchased their suite but never actually used it; they considered it the cost of a patent license and used widely available Open Source implementations, which were almost universally better.
Schwab
Editor, A1-AAA AmeriCaptions
I remember when Winzip came out and PkZip didnt really have it together in terms of a GUI, when companies started seeing the benefit of using compression Winzip came along and took most of the market only because it had a half decent GUI, Pkzip's was pretty shoddy, if anything Winzip had better icons heheh.
Not being a troll, but ever sick of the woes of the 2 gig limit on zip's data structure. (I'm in data engineering and usually work with files over 6 gig) Other missing features were not being able to easily click on a few files/dirs and select the size of the volumes (disk span) and save the files to the current dir without sticking in floppies one at a time, poor password/encryption security.
Winrar on the other hand has had their features for years including an 8 gig limit on rar's, (one of the major reasons i *had* to switch) you can also setup policies so each time you create a rar it will follow the policy you setup originally in the configs.
Supports multiple NTFS file/permission streams among other things.
I hope the new PK Inc can live up to some of the features in rar, they may have a good chance...
On the subject where the zip format should go, I believe it would be nice to see some new compression algorithms - I believe the header has space to define new types. The bzip2 algorithm would be a lead candidate. It would also be nice to see encryption and signing capabilities incorporated, perhaps based on the Java archive (jar) format.
Another thing that would help compression were if there were something akin to the tar / cabinet file mechanism for compression, where the entire contents and manifest are concatenated and compressed as a single entity rather compressed individually. This would allow for some very tight distributables.
Maximum compression-rate with lossless algorithm
Implement a compression algorithm that virtually takes resources for granted and provides ultimate compression rate for "source-like" data. If this is not enough, design a method for automatically detecting the optimal compression rate / bandwidth to optimize the total download/uncompress time. Who downloads and uncompresses the Linux kernel fastest using same bandwidth and identical HW resources?
The first new feature they introduce will create an incompatability with InfoZIP & other clones. I'm sure the users of such products will complain loudly.
It's amazing that PKWare ever succeeded, based on the story. It was the dream of every shareware author: a product that was so successful it could overcome nonexistent management, etc.
On the other hand, we now have a horde of pointy haired "professional managers" taking over, wanting to "build on success" to enrich themselves. Time to pump out resumes before the laser printers get monitored.
Three guesses where PKWare will be in a year or two (and where the "investors" will be, with whatever they can loot.)
or just support bzip2?
It beats deflate all the time and is free too.
Tom
Someday, I'll have a real sig.
Yeah, the only time I use ZIP anymore is to send stuff to people who I know have WinZIP and are too clueless to even think about moving them up.
RAR is far and away better, including Linux support from the manufacturer (rather than from 3rd parties, which will lag in feature implementation). It's not open source, but the same license works across platforms and the unRAR thing is free beer everywhere.
The 7z format used by 7-Zip is an open architecture. There are several available compression methods and bzip2 is one of them.
Programs that encrypt computer files tend to make the files much larger, gobbling up valuable room on a hard drive or ...
This is bullshit. I do not know of even a single cipher which makes the files larger. Indeed all ciphers commonly used today for file-archiving are block-ciphers which transform a fixed-size (typically 64 bit) cleartext-block into an identically sized ciphertext-block. Examples of such ciphers include DES, IDEA, Blowfish, 3-DES, AES, Twofish and many others.
Combining encryption with data compression is a natural, said Stephen Crawford, vice president of marketing.
The vice-president of marketing is not typically a good person to ask about technical issues. In this case he is correct though, it is a good idea to compress files prior to encryption, this both saves place, aswell as making certain attacks a little bit harder due to more entrophy in the compressed plaintext than in the plaintext itself.
Unfortunately for him this idea is so obvious that it's been implemented in typical encryption-programs for ages. Both PGP and GPG for example by default compress the plaintext priorto encrypting it. This is hardly novel.
(Trollish post coming...)
... so Joe User is going to encrypt/decrypt zip files? And he'll pay for the this when it was offered as shareware before?
Joe User doesn't care. Joe user has an internet connection, MS Works, and couldn't tell the difference between a firewall and a firefly.
I think they'll lose money and people will use the regular format because its out there and you can encrypt it however you please now if you feel like it. Who would pay for this?
For all the spyware they crammed into their product, you would think their marketing department would have done a better analysis on future market share...
This space for rent.
sick of the woes of the 2 gig limit on zip's data structure
Not only that, there are apparently file number limits also. I recently had to archive up a few million small files, and ZIP just exploded. I tried InfoZIP on Linux and WinZIP, and both did the same thing, created the ZIP file but then it didn't work.
So I used RAR. I really don't ever use anything else anymore; RAR is what they have to surpass now.
If you want a zip utility with good encryption now, UltimateZip is a pretty good WinZip clone. It is free (as in gratis) for private and commercial use and has an extra meny command that can encrypt/decrypt with AES Cipher Rijndael. It's only for Windows though.
Never express yourself more clearly than you are able to think. --Niels Bohr
Just in case it's not clear to everyone, JAR files *are* ZIP files. See http://java.sun.com/docs/books/tutorial/jar/basics /index.html for docs on this.
ZIP files are more relevant than ever, but PKZip is not. They have little chance of taking control back.
This is the most disturbing part of the whole story. I think that PKWare will die a slow and painful death as all the "interesting" ideas get thrown on the floor. Why do companies think that purchasing a successful company and then changing the basics around how they operate will make them grow?!?
Yea, making the company "market driven" is going to work.
KangarooBox - We make IT simple!
7 Zip is good but you might also check out JZip. JZip looks more like Winzip which is what most users are used to.
Or try FreeExtractor which creates self extracting exe's. I have a whole collection of Open Source Software for Windows.
Georgia summer camps
Did he also pass away shortly before WinRAR 3.0? If so, that doesn't sound promising for the continued support of WinRAR.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
I wonder if this new business plan has come up because of the new feature in Windows XP -- Compressed Folders, aka .zip files that are treated just like folders. Zip files in XP now have the little + icon next to them, just like folders. Click on it, and it opens the file and directory listing just like a folder. Drag and drop files into and out of the 'compressed folder.'
Ouch WinZip...
"And like that
Since a Zip has to be decompressed anyway
While until just recently, this was true - now you can create a "ZIP" file that doesn't decompress. The idea is instead of decompressing the files to disk, a tiny user-mode OS is inserted between the application that needs to use the data and the compressed data. The new OS does transparent decompression/decryption and to the application it appears the files reside on the hard drive. The OS provides streaming decompression so only small blocks are decompressed at a time and the memory requirements are very low. Yes, the data is present in memory in unencrypted form at some point so it is possible to hack - but it provides a pretty good level of data security.
The cool thing is that the archive size is usually the same size as a ZIP, but it runs directly with no install and no decompression time. Usually applications load 2x faster in this state.
This is something I've spent the last year working on. Checkout here
-- Virtual Windows Project
I have been using WinRar for years, it's been the easiest to use and most versatile archiving program for windows I have ever used. (yes this is a shameless plug but I think the product is that good) It completely supports the .rar and .zip formats along with being able to extract and/or decompress the following formats CAB, ARJ, LZH, TAR, GZ, ACE, UUE, BZ2, JAR, ISO.
The integration into the shell and the multitude of options for RAR archives like solid archives (treating the data as one big file to get better compression), recovery data (allows a good portion of a damaged archive to be reconstructed with little space overhead).
Overall I wish that rar would become the de facto standard (it's not completely free but 90% of the functionality is). The compression gain over zip is incredible and it's A LOT easier to use.
...When Katz was in charge, PKWare's programmers often would work on new features that they found interesting rather than targeting specific needs of potential customers, Kennedy said.
"In some cases what they did was successful, but in many cases what they did wasn't anywhere near successful," he said. "The company from this standpoint now is market driven."
The engineers are no longer in charge, money is. All the clueless and stupid "features" that corporate slave drivers can think of will become projects for the Brown Deer survivors. I can imagine them asking for central repositories of file lists, tables of "sensitive" files that can't be ziped, and other silly work arounds the serious lack of data control their w2k desktops have. I can also imagine that half of the "I wanna micro manage my staff to death" initiatives will directly contrardict the requirements for the other half. Sounds like hell if they really have remade the company that way, and sure the customer gets screwed along with the lusers. That's what happens when you put sales in front of engineering.
I could be wrong. Dr. Kelly could be a fine fellow and have no intentions of making this happen. It will be difficult for him to manage the monster he's making. Good luck and never trust M$, the folks that bought 5th Generation Software to kill Fastback and who have always seen backup utilities as a threat and aid to "pirates".
Friends don't help friends install M$ junk.
The poster is absolutely correct. A proper stream of encrypted data should be ~uncompressable as it should resemble truly random data.
Trolling is a art,
I was about to point out that ZipMagic has done this for years, but on checking your site you seem to be talking about 2 slightly different things.
Using a ZIP/compressed file as a file system level folder via an OS extension has been around on the desktop for years - ZipMagic, for instance, and SparkFS on Acorn RISC OS is even older.
However, your app seems to do something else (compress an EXE and all its files into a single EXE that runs natively, for speed and obfuscation reasons), and it doesn't use the ZIP file format.
At least I hope it doesn't use the ZIP format, otherwise it's trivial to bypass the system to de-obfuscate it.
Tim
If zips just had a more 'rar' like ability to do multi-parts, zip would probably have more flexibility. Screw more 'security features'. Just fix the multi-spanning (multi-part) zips. That implimentation was horriable from the beginning. It was competing with lharc at the time (late 80's) and lharc just kicked it's butt as far as multi-parts. The whole idea of being restricted to floppys is just a bad idea.
Actually, the next PkZip generation will support the L-Zip compression.
Lossy compression is very secure, (combined with lossy crypto).
Yeah, As far as I know, there isn't anything else like this. There are some system-level things you can do if you install device drivers, but what user is going to put up with that for every other application or data file they receive?
Thinstall is all user-mode code and doesn't install any drivers. Everything needed for the additional functionality is built into the EXE. So it will run directly from CDROM/floppy on any Windows computer you walk up to. The overhead size it adds to the EXE is about 75k, which is much smaller than InstallShield would take, and I think smaller than WinZip's self-extracting EXEs.
-- Virtual Windows Project
was, "The investors who bought the company.... bolstered the top management team." In light of some of the recent commentaries by Robert X. Cringely (like this one , the decision to usie"professional managers" in a software company may be the kiss of death. Too many of these suits have a "vision" of short-term gain versus long-term profitability. PKware is not a public company, of course, and doesn't necessarily follow Cringely's model (which is to increase stock prices, sell out, and haul ass for the next vict... er, company). But, if there is an IPO in the near future, watch out!
It was also interesting to learn that a drunk techie CEO who let his programmers follow their own interests still managed to have a profitable company. Remind me to hang out with strippers more often.
No one ever had to evacuate a city because the solar panels broke!
The bloat already happened.
In August of 2000, I bought PKZip Explorer from PKWare. Figured for the $10 special promotion, what the hell, and it would be nice to have PKZIP that could handle Windows long file names. Also assumed it would have the same feature set as PKZIP for DOS, and their promo literature certainly *sounded* like it would.
Well, it was one of the poorest $10 purchases I ever made. The installer (a two-step, partially online-only process due to paranoia about piracy) is about 6mb, and the installed program is apparently scattered thruout Windows. So I was already annoyed by the time it was finally installed and running.
On to making my first ZIP with it. Turns out the ONLY thing it can do is grab the specified files and create a new ZIP, or unzip a specified ZIP. That's ALL it can do. It's absolutely devoid of ALL the switches and options that made PKZIP for DOS so useful. The only good thing I can say about it, is that it's fast.
Now, maybe it's improved some since then, but if it didn't even have its own ancestral feature set in 2000, yet was already 3x the size of competing products like WinZIP and WinRAR, I have scant hope for later incarnations.
And thanks to this experience, chances are I'll never buy another product from PKWare.
~REZ~ #43301. Who'd fake being me anyway?
I sure PkWare never goes out of business. I don't know what I'd do without my WinZip and my GNU zip/unzip.
Encryption and compression make a lot of sense...
;)
Yeah, I just hope PKWare remembers to compress the data *before* they encrypt it.
They're going to break it, plain and simple. A nice, neat, simple alogrithm will be bunged up with neat little bells and whistles and useless cruft.
Thanks, I'll pass.
pkunzip 2.04g is the one piece of software I've had ever since I started using computers (pre-1993) that I still occasionally use and keep copies floating around. There's nothing wrong with it! Can't say that about any other 10-year old piece of software.
Most compression formats have lead in characters in the files, PKZip does anyhow so thats probably not a problem when breaking the encryption.
He who defends everything, defends nothing. -- Fredrick The Great
Wouldn't this be a problem for random access? I mean lets say I'm playing a 700MB divx that I decided to zip as well (admittedly a stupid thing) and I decide to start half way through the movie, it would have to decrypt the first 350MB then?
:)
I see this as only being useful for sequential access, please correct me if I'm being stupid here
He who defends everything, defends nothing. -- Fredrick The Great
I've not really had a problem with this. I compress blocks of 64k at a time so random access to large files is about this same or faster than normal. If an application had a long spell of jumping around in the file, reading only one byte at a time then performance would suffer - but it's likely to suffer worse without compression because there is a higher possibility of a disk seek, which is much slower than decompression.
While the block size might be configurable in the future, beyond 64k compression doesn't get much better and there is the additional memory overhead from having to store an entire block in memory before passing it to the application. But for your example, a divx movies is unlikely to compress much - if any, no matter what the block size it.
-- Virtual Windows Project
The Info-Zip group provides multiplaform code to zip and unzip under a BSD-like licence.
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
bundled up the files into an uncompressed zipfile with -e0, and then compressed that. This gives you a few percent over compressing the files straight into a zipfile, when they are compressed individually.
I tried once to do that but I noticed that the size were simlilar if not bigger. I guess it would only work with lots of very small files.
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Since Java's library runtimes are compressed using the pkzip alg. - or has that changed in the past 3 years?
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Who needs brute force? People silly enough to use password-protected zip files really don't care about security that much. One time I wanted to install something on a new computer from the recovery CD that came with a different computer. Everything was stored in password-protected zip files, and the recovery program checked to make sure you were using the CD right computer. But of course the recovery program itself had to know the password. A simple search of the binary turned up the command line used to launch pkzip, and the password right next to it stored as an unobfuscated string. Piece of cake.
BTW, the password was "magic"
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Thanks, I realize compressing divx would be a silly thing to do, it was just an example :)
A few years ago when I was at uni I was doing my postgrad thesis on multi-dimensional DB indexing. I was comparing several algorithms against one another, the main problem being that the bottleneck of the system was disk access so I couldn't make a fair comparison. This was of course exacerbated since I was using Java (hey, I was young and reckless back then) so the IO was slow. I looked at a few ways of improving the IO and one method was compressing the data to load faster (since cpu cycles were cheap), it was however unfeasible because of the random accesses the database would have to do. I ended up buying a ton of RAM and storing the DB there.
Now I think about it more it should be reasonable straightforward to store DB blocks compressed, the index after all keeps an byte-offset to the data so I don't see how compression would effect it as long as the data was stored in 64K blocks. I do think that this compression would have to be managed by the DBMS not a generic system wide compresssion system since the index should represent bute offsets in the compressed file not the uncompressed file (otherwise more work would need to be done then actually needed). It would be a cheap way of getting more disk space, but more importantly it may speed up the access time, like a cheap SCSI (or mabye use it with SCSI) at the expense of some CPU.
</rant>
He who defends everything, defends nothing. -- Fredrick The Great
These programs are essentailly filters and the most logical and flexible way to provide them is as seperate entities.
Your argument could work for spellcheckers and word processors--but they still get bundled because they're used together.
Whenever a set of programs is commonly used together for the same task (create a file, move a file, etc.), a consolodation should at least be attempted.
I for one hate having to make WAVs before I can make OGGs. If the only way to have encryptied archives was to ZIP and then Archive them, I probably wouldn't do it.