Why is .lzh format still popular with japs?

The rest of the world uses .zip and .rar and these retards still seem to use .lzh a lot.

It's not because the format itself was constructed by a "fellow" Jap is it?

>>39,40
I am perfectly aware of the structure of many file formats. All I said is that it's a bad idea. I know that currently operating systems, file systems, and transport protocols have minimal support for metadata, so these kinds of ugly hacks are necessary. And I believe the situation will improve in the future.

Just look at those file formats you mentioned: Basically all they do is compress bitmaps. Then every format has its own way of storing the metadata associated with the bitmap (compression type, alpha channel, width, height, palette, comments, etc). This causes overhead in implementations and numerous shitty limitations (only gif can contain animations, only png has proper alpha support). It's a shitty situation.

>>32
That was me. I'm not even kidding.
I'm not surprised, you're the lusers' hero.

7zip Setup.folder
How's that too different from downloading a fucking RAR file?

>>33
That's because of solid compression. You can do the same with RAR, TAR+BZIP2, and any archiver that doesn't suck (oops ZIP).

>>34
The HTTP spec says nothing about directory indexes.
I said the server returns, not HTTP specifies.

>>35
Or it could send an file containing info about the files in the directory (xml would work nicely)
Yay, let's use XML so it's scalable and Web 2.0.

if someone sent you a file of unknown type, your computer would request a filter or something (written for a simple VM with no system access)
Crappy idea, and bound to have bugs that compromise security one way or another. I want to install my things by hand, choose my sources, do it the way I like, and be able to say "NO U, I'm not installing this shit even if it's required to view this file".

Unfortunately, operating systems will suck for probably at least a couple more decades.
Fortunately, OSes will not be completely luser-friendly for a couple more decades. Fixed.

>>37
Computers should NEVER install software behind your back.
Agree, and I will add, computers should never do anything behind your back.

>>38
Not software, just an algorithm for converting one datastream to another (notice how I mentioned a VM).
And that would be...? SOFTWARE YOU IDIOT

Also storing filetype inside a file (such that 'file' can recognize it) is an even uglier hack than storing it in the filename.
Finally, something I agree with.

>>40
The filename with the extension is just for stupid Windoze so it can tell what kind of file it is.
Yay, let's run file on everything all the time, reading two or three times more hard disk sectors (depending on your FS) just to be able to name your files like "dude" and "pal", without the .PNG or .PL .

>>42
Yay, let's use XML so it's scalable and Web 2.0.
No, I hate XML, but in this case it would work best, unless everyone will suddenly agree on a suitable binary container.

Crappy idea, and bound to have bugs that compromise security one way or another.
No. Since this would only need to convert between two datastreams, the VM could be small enough that it can be guaranteed to be free of bugs.

OSes will not be completely luser-friendly for a couple more decades.
You are mistaking efficiency for user-friendliness. Seriously, computer use could be much more efficient than it is today, especially for more advanced users.

And that would be...? SOFTWARE
Sure, but without the security issues that were alluded to.

>>43
you should use kde you dickless blackanese piece of shit

>>1
to get back to the topic.

lzh is used only for small (in both size and number) files.
they use rar for big things like ISOs.
and use zip for images

i'm liking the idea of an image-conversion algorithm virtual machine (ICA-VM)

while we're at it, let's make a video-conversion algorithm vm as well (VCA-VM)

get to work!

That's because of solid compression. You can do the same with RAR, TAR+BZIP2, and any archiver that doesn't suck (oops ZIP).

I just want everyone to know that tar+bzip2 is complete garbage. To get at a single file you need to decompress the bz2. There is no random access within the file. And guess what? You can do the same shit with zip! zOMG!

Think of it like this:
zip -0 = tar
zip -9 = gzip -9

Guess what would happen if I used the second on the first? WHOA!

rar is Not Free. Use bzip2 or 7zip.

>>47
tar is a container (just like 7z, zip and even rar), gzip/bzip2 are compressors. the difference is that the files are stored compressed inside of the container in 7z, zip, etc.

>>47
No shit, Sherlock. You really are clueless. Google solid compression or something. Then read how tar and bzip2 work, which are two different things. And zip -9 is not equivalent to gzip -9 .

this thread fails

>>50
You don't get it, so let me elaborate (just for you!). Read very carefully, okay?

tar is an archiver. It allows you to store files uncompressed in a single file. Guess what an uncompressed zip does? It stores files uncompressed in a single file. So yes, they can work very much alike, contrary to penguin fucking fanboys.

Now what does gzip do? It compresses a file. Guess what zip usually is used for? Compressing a file. What does gzip use? Deflate, a variant of LZ77. What does zip use? LZ77.

So... if you were to roll a bunch of files into an uncompressed zip, it would be analogous to using tar. If you were then to compress that uncompressed zip with zip, it would be analogous to gzipping a tarball.

And by the way, that is how solid compression works: by compressing data across files. A single data block, instead of one for every file. That's all. So tar+gz is a form of solid compression, and so is zip+zip. If you hate zip so much, you should hate tar+gz more, because unlike a normal zip, tar+gz can never randomly access files internally.

Oh, by the way, since I just know you're going to be stupid: when I say an uncompressed zip, I mean a zip that used zero compression, not a zip that has yet to be zipped. Zipping a zip that already used compression won't help, just so we're clear, mmkay?

PS. You're an idiot.

>>52
Gzipping a tarball is similar to a ZIP file, but this is not what you posted so don't come changing what you said to look less stupid. You said zip -9 is equivalent to gzip -9 which is not. Nothing will change the fact you're an idiot.

>>27
Wether you have a point there or not is irrelevant - you have issues man. Go see a shrink.

>>55
Is it because I don't like lusers fagging up my OSes?

>>53: "when I say an uncompressed zip, I mean a zip that used zero compression, not a zip that has yet to be zipped. Zipping a zip that already used compression..."

This HAS to be the LEAST INTELLIGENT SENTENCE POSSIBLE using the word "zip."

>>54
Haha, you got owned, and that's the best you can come up with? Only a complete nub wouldn't understand what was being said in >>47.

Oh, wait...

>>38
>>35
<FATAL_BLOW>
Ok, back to the argument that including typeid information within a file is an "ugly hack."

Is it an "ugly hack", then, for XML files to include the <?xml version="1.0">, </xml> tags?  Is it an "ugly hack" for HTML files to include the <html>, </html> tags?
</FATAL_BLOW>

IM ZIPPING THE ZIP OUT OF YOUR ZIPPY ZIPPYNESS!
thread over.

>>59
For reasons of elegance, having a root element in 'nestable' formats like XML is nice. For (X)HTML, they conveniently named it 'html'. They could've named it 'document' or 'hypertext' or whatever. It does not identify the filetype. Send it to a good browser with mimetype text/plain, and it will happily display the source instead of parsing it. Same goes for the 'xml' directive, except in that case it's not a root attribute, but serves to give version/encoding info (which should actually be in metadata attached to the file, so it is an ugly hack, but it's necessary because metadata is far from universally supported).

BTW, there is no "</xml>".

Also, there is actually a way to specify filetype in xml (sort of): with the xmlns attribute. The reason for this is that xml is actually a container format (like tar, in a way), so it has an external filetype (xml), and one or more internal 'filetypes' (xhtml, svg, etc).