.ZIP Standard to Fragment? 627
fudgefactor7 writes "As IDG.NET tells us, the venerable .ZIP compression standard is about to undergo a bit of a schism. PKWare and WinZip, the "big two" in the .ZIP format biz are (unfortunately) going to be making their respective releases incompatible (to an extent) and an archive made with one may not be accessible from another. The problem lies with PKWare not giving information to WinZip, thus making WinZip to go it alone."
Zip encryption's pretty useless, anyhow. (Score:5, Insightful)
So, if a fork occurs in a feature which nobody uses, does it make a sound?
Not that serious (Score:3, Insightful)
PKWare vs. WinZip? (Score:5, Insightful)
uh, bzip2 anyone? (Score:2, Insightful)
Following the Big Boys... (Score:2, Insightful)
PGP as the new competitor (Score:5, Insightful)
It seems as if PKWare and Winzip are moving into the realm that is dominated by PGP and the GNU variant. PGP compresses the data when it encrypts it, so that need was taken care of already. I wouldn't use either Winzip or PKZip to send an encrypted zip file, because PGP is more universally known, and can give you 2048 bit encryption.
AFAIK, the actual zip standard hasn't changed, which means that you'll be able to open zip files with either program (or the WinXP shell... heh). That's what I see most zip files being used for anyway... Windows based shareware / freeware. Stuff where encryption is not necessary.
The venerable tar.gz and tar.bz2 formats, thankfully, will not be dictated by stupid companies. :-)
Who the hell are PKWare? (Score:4, Insightful)
Yes, I do know the answer to that, and so do most of you, but the hordes of Windows users out there do not.
What will happen is that the WinZip will win this feud, simply because it is what people use.
...and since the problem stems from PK not sharing information, UNIX zip implementations will likely behave in the same manner as WinZip.
Re:best Winzip feature (Score:2, Insightful)
Spec Release *After* the Product's Done?!? (Score:2, Insightful)
In paragraph 14 of the article, just before the heading "Other Options": "But the spec should not come out until a product is done, says Steve Crawford, PKWare's chief marketing officer."
I'd already been kind of wondering what was up with PKWare not documenting stuff. Now I'm starting to think they're just messed up. Specs should be released first (IMNSHO); then everyone who needs to support the spec can write to it.
We'd scream bloody murder if Microsoft released a new version of IE that implemented some bizarre new HTML or HTTP standard, even if they said they'd publish a spec for it a few months later. And the same goes for Mozilla. We very rightly insist that browser makers build their software to support the already-published specs from the W3C and IETF.
Similar comments apply to Apache and HTTP, CGI, and various other standards; to Sendmail/Postfix/Qmail/etc. and SMTP; to Linux and the POSIX standard... this is what standards and specs are for
Free clue to PKWare's Steve Crawford: you're just a marketing director. Let your CTO worry about specs; you're just making your company look worse.
Did we miss the point, here? (Score:3, Insightful)
So switching doesn't do a hell of a lot of good unless you switch to theirs. Which is probably the plan, I guess.
PKWare is dead, too (Score:5, Insightful)
Also, memory serves that Philip W. Katz, the late founder of PKWare, worked with IDC to make the ZIP file format public domain, both because it wasn't entirely original to either organization, and also because it would never take off were it not. So here then we have PKWare, in the wake of the death of Katz, trying to "pull a Microsoft" and make their version incompatible with others in the hopes that more people will use their version. For that matter, I think PKWare's main claim to fame for years now has been that they were "the first".
However this has the potential to backfire. PKWare may be trying to "pull a Microsoft" but they are not Microsoft and so now they're in the position where their product now creates the incompatible file. A file made with PKZip may not work with others, a file made with WinZip almost definitely will.
Re:Zip encryption's pretty useless, anyhow. (Score:3, Insightful)
AES what (how many bits)? And how do they collect entropy? How do they generate the IV? Are there password complexity rules, or at least warnings on insecure passwords?
The actual encryption algorithm is but one small factor in determining the security of a system. People who say thinngs like, "It uses AES, so its secure," are the ones that the NSA, CIA, and FBI encourage, because they're the ones that can be easily fooled.
If WinZip9 uses AES with 56 bits, no thanks. That's not secure. If they use 128 bits, kudos.. its adequate for most uses. If its configurable up to 256, even better. However, using a published and reviewed encryption product like PGP or GPG would still be my method of choice.
I'd like to suggest Bruce Schneier's [counterpane.com] Cryptogram [counterpane.com] as a good source of applied crypto knowledge. My favorite section of his newsletter is The Doghouse, [counterpane.com] where he debunks dubious claims and "cryptographic snake oil".
Anything labeled as "proprietary" is generally bad when it comes to cryptography. Peer review is the best way to verify a system can be trusted. And that's difficult to do on closed-source products.
rar is lame... (Score:1, Insightful)
Winzip's "standard" will win by default (Score:5, Insightful)
Re:W - R - O - N - G (Score:5, Insightful)
Re:PKWare vs. WinZip? (Score:2, Insightful)
And lost control of that standard with the PS/2. By being incompatible with that standard and trying to force everyone else to move to the 'new standard' while simultaneously locking other vendors out.
Re:Does it really matter? (Score:3, Insightful)
I use the "trial" version of Winzip (You've been using this for 683 days! This isn't free!) and since I *never* compress and I only uncompress when I download a new Quake/HL mod, its no biggie which utility I use.
I think this entire thing is getting blown *way* out of perspective. At risk of being repetetetive and a noing:
Who gives a crap about zip encryption?
Re:More importantly.. (Score:3, Insightful)
And come to think of it, what further changes are they planning anyway? The zip format is very much standard and making something new that cant open zip files will not work, nor will compressing files in a format in which most unzippers will fail. The market itself will ensure the old zip format will remain.
Re:More importantly.. (Score:5, Insightful)
If PKWare suddenly closes their format, and if WinZip keeps theirs open, then it looks like WinZip will win by default.
It seems that we've been down this road countless times before. The way to win marketshare in the tech sector is to keep things open and allow other companies to champion your standard for you.
Think please. (Score:2, Insightful)
No, gzip is very nice thank you. It's a tool that does what it says it will, compress files. The way you use it might be at fault. Don't make giant archives of unrelated work. That may be the unix way, but it's not the efficient way.
Who made you SCO this week? ;-)
The unix way is to break your work up into reasonable chunks. Try making tarballs of related work, then a tarball of tarballs, then compress the biggie to get it from your place to someone elses. That way you get your data to the other side in a usable form. If you need to compress the smaller archives for storage, go ahead. To keep the other side up to date, just send the files you modify. Tar can append and replace files in archives.
You can probably extend the same methods to a graphical client like winzip. Make zips of zips and all that.
The big story here is that PKware is not sharing information. That means that people who don't have pkware eventually won't be able to work with archives sent by pk users. It's obnoxious, the same way WORD.DOC is. Free software might be able to keep up, but Winzip won't want to. Oh, the wonders of closed source develpment. Make it stop.
And the winner is... (Score:4, Insightful)
Depends on dumping. (Score:4, Insightful)
It does when the company in question starts dumping product and people start using it. Just let them promote the useless feature and wait for the ass pains to set in. If they are dumping a "client" ala Adobe PDF, people can say, "Don't complain, the client is free." Ugh, at least Adobe released file specs.
If a company decides to go 20 years retro and create a new non free file format, that's just one more dumb format to get in the way. You would hope that people knew better by now, but they don't. Witness the growing popularity of M$.DOC, the dumbest way to exchange text ever.
Re:Splitting Those ZIPs (Score:3, Insightful)
Except that the Unix way allows compression of the collection of files as a whole, rather than per-file.
To take an extreme example, consider tar-ing and gzip-ing the
But, that said, the actual degree of compression is not the only consideration for a good compression format. For example, being able to add or remove individual files from a
Open format via closed review? Doubleplusgood! (Score:2, Insightful)
"Certificate-based encryption is still a work in progress," says Jim Peterson, PKZip chief technology officer. "We're not publishing it because we still have a number of features to add."
Sing it, brother. So essentially, cert-based encryption in the zip format is too much of a moving target to bother posting a complete spec, even a preliminary one, but not enough to prevent you from introducing the feature into your product almost a year ago? Solid.
But is this simply one man's poor choice of words? Maybe he's being quoted out of context. Luckily, another suit quickly steps in to disabuse us of that notion:
But the spec should not come out until a product is done, says Steve Crawford, PKWare's chief marketing officer.
Read: "We can't publish the full details of changes to our open format until our own commercial implementation has gone through a few revs."
Okay, I need everyone who loves to bash Sun's handling of Java to line up on the left over here. Please proceed in an orderly fashion
Giving Sun a little credit, for at least having the good sense to provide some form of community review process on proposed specifications, is optional, but highly recommended.
Those who wish to play the role of PkWare apologists should instead use the wooden stick to beat themselves unconscious
Re:More importantly.. (Score:2, Insightful)
Re:Why tar/gz and tar/bz2 suck, compared with zip (Score:3, Insightful)
That's the difference between gadget freaks and users. Most users extract single files so rarely that they really don't need an entirely different format. For the once-in-a-blue-moon event that they have to find a single file, they probably just untar the whole archive, find the file by browsing the directory tree, and then delete the tree. But gadget freaks are so happy to have just the right gadget for a particular problem that they will go through any cost to acquire and use a gadget.
And when you have an application that needs a random access format, zip is pretty lousy: you'd be better off with a loopback-mounted file system (like MacOS
Re:More importantly.. (Score:1, Insightful)
That's why I have zip tools here on my Linux box. Occasionally, I will need to extract a zip made by some Windows user... Or maybe, some day, I'll need to make an archive for one.
Even More Importantly.. (Score:5, Insightful)
If you use GnuPG(GPG) [gnupg.org] or PGP [pgpi.org] to encrypt your files, you get compression [pgpi.org] too. There is absolutely NO reason to use a nonstandard compression utility to do low quality encryption.