byuu's message board

Beaten like a red-headed stepchild by foobar2000, even if wine is missing various functions it uses. For instance, "Open Containing Folder" crashes it. And it can't open URLs in your web browser, so forget about using the troubleshooter or seeing the results of submitting a crash log.

Or if you prefer some of the looks and almost none of the functionality, you can always try DeaDBeeF.

QFT.

Ah, that's why I've never heard of it - it's not packaged in Ubuntu.

I'm still pretty happy with Quod Libet and its mighty slice-and-dice tagger. I wish it supported iTunes-style 'move all the music in my collection into a standard folder and filename structure', though.

It seems to me that any company even attempting to implement compression into their OS would be hit with a big fat anti-trust lawsuit. If this were ever to occur it would have to be in the open source community.

What you say is true - Microsoft implemented compression in their OS at least three, possibly four times*, and they were hit with an anti-trust lawsuit - but it turns out those two things are unrelated. The only legal fallout I know of from implemeting compression is they got sued by Stacker, whose technology they, uh, "borrowed" for their first version.

* for those keeping count, that's DoubleSpace in MS-DOS 6.2, DriveSpace in MS-DOS 6.22 (after the Stacker lawsuit), and on-disk compression in NTFS. The optional fourth round is DriveSpace for Win9x; I'm not sure whether that was separate from the DriveSpace-for-DOS or a wholly new thing.

I believe it was a backward compatible update thing. As it went there was:

DriveSpace in MS-DOS 6.22
DriveSpace 2 in Windows 95 (32-bit driver)
DriveSpace 3 in Microsoft Plus! for Windows 95, also as standard with Windows 98/98SE (HiPack and UltraPack support)

Each one added more features and could handle partitions compressed with previous versions. So it's either three rounds (the three versions of DriveSpace counted as one) or five rounds (each version of DriveSpace counted separately).

What you propose is very similar to the situation of Video/Audio codecs on Windows. Most codecs on Windows are implemented as DirectShow decoding filters. When a media player wants to play a media file, it takes a look at the file, and asks DirectShow to handle the actual decoding (This doesn't apply to media players like VLC which actually come with their own codec libraries). This makes it easy to make a media player without having to worry if you have all the popular codecs out there. Media Player Classic will still be usable when the next amazing video codec comes out (Assuming we're still using Windows and DirectShow)

I think it'd be a good idea to implement such an API for compression. It's relatively silly for every single program have to link against libzip2/libzlib/whatever to have something as basic as file compression (though Java seems to have solved this by building gzip compression into the standard library, which is quite handy.) It'd be better for everyone, I'd imagine: No worrying about whether or not some program I'm using will support my compressed files, either it supports compression through the proper APIs and it does, or it doesn't.

I'm not sure I like the idea of my OS heuristically deciding to compress my data, however. Mainly because I very much doubt it could make very good compression decisions (especially since it would be working without the detailed information the filesystem driver would have... though I'm not sure I'd want the filesystem to perform this either.) Additionally compressed files are much less resilient to errors (a block error in a text file may be some corrupted text, a block error in a compressed file is very likely an unrecoverable file)

On the GNU+Linux side of things, one old app is able to handle transparent decompression of many formats: Midnight Commander (mc).

I use mc quite often, if I'm ever wanting to hand-pick which files in a large group to move, or if I'm wanting to work with compressed files. Simply pressing Enter on almost any type of compressed file will open it as a folder, allowing you to copy files out of it, or for certain supported files, deleting, moving or adding files. I use this for opening many types of archives, including: RAR, RPM, DEB, Bzip2, Gzip, Tar, Zip, Ace, Arj, etc. Not sure if it works for 7zip or ISO files, I've never tried using mc for those.

I quite like mc as a file manager, once it's tweaked substantially for efficiency. If you turn off the command prompt and hide the date column from the file lists, then it is very efficient. You can then type the first letter(s) of a file or directory name to jump to it. I've also set up every possible type of media file to open with MPlayer, and images to open with GL Image Viewer (gliv).

Edit 1:
Also, I wanted to agree with the previous commenter about automatic compression -- I wouldn't want that. In this age of multi-terabyte hard disks, the need to compress files which aren't already compressed is (pardon the pun) small. Currently my family shares a 6.3TiB multiply redundant RAID array plus backups of the more important files. If there was a catastrophic failure, I would like to be able to recover as much as possible, compression greatly reduces what can be recovered using forensics tools. As was said, most files taking up the huge blobs of space are images and videos, both of which are usually compressed quite heavily already.

Edit 2:
Another issue with compressing files is that almost all files will be accessed at some point, especially on GNU+Linux systems. Tools such as "file" which read information about what a file is, or file managers for Gnome and KDE all require read access to the uncompressed file in order to function. For instance text files are determined by their content, not file extension. PDFs and JPEGs are opened to create the thumbnail icon, etc. etc. All of this would require very regular decompression. If some very heavy solid-archive compression was used, the filesystem would slow to a crawl. To me anyway, the loss of time is not worth it when you can buy an additional 1TB hard disk for $80. Not to mention the increased CPU usage adds to your electricity bill, which wouldn't take that long to equal the cost of a new hard disk (which itself uses about 6 to 12 watts).

I use MC mostly for quick inspection of ISOs, worked so far. Very handy.
7zip should probably work fine, too, just a matter of filter/configuration.

I like how configurable mc is. I set .pk3 files, which are Id Software's renamed version of .zip files, to open transparently as .zip. I'm not sure if Windows transparent .zip decompression would work for files not using the .zip extension, but it sure was easy to set up in mc.