The only reason I've used Winamp in the past few years is that most of the players for music formats related to classic game consoles have been released as input plug-ins for Winamp. Does XMPlay support NSF (NES), GBS (Game Boy and Game Boy Color), SPC (Super NES), SGC (ColecoVision and Sega), GYM/VGM (Sega logged), PSF (PS1), USF (PS2), GSF (Game Boy Advance), and 2SF (Nintendo DS)? On the XMPlay page, I see "Game Music Emu input plugin", which covers the NSF, GBS, SPC, SGC, GYM, and VGM, but not PSF and friends. What worries me more is that the page also states a policy of making the input plug-in SDK available only to approved developers: "The input plugin SDK is currently available only on request. If you would like to create an XMPlay input plugin, please get in touch."

How should one make sure a particular model of SSD is not broken before buying it? I was under the impression that by the time all the bugs got shaken out of a product, it ended up close to EOL.

Block-level run-length encoding is exactly what I had in mind. This way more logical sectors can be packed into one 64-128K erase page. A sector that has been compressed into "0x00, then 4095 more of the last byte" is as good as TRIMmed. It needs to be done anyway for file tails.

Perhaps you missed my implication: Instead of having a concept of empty sectors to begin with, just treat sectors with long runs of a constant value as highly compressible. You need to do that anyway for the last sector of a file, which contains on average half a sector of zeroes.

Pigeonhole principle. I'm aware of that.

By about one byte, a marker that the sector is uncompressed. In a real file system, this overhead of one byte per sector is made up for by real files that contain real redundancy, such as the last sector of a file (or the only sector of a small file). On average, the last sector of a file will contain a run of half a sector's worth of $00 bytes. This and other cases where sectors can be compressed allow more logical sectors to fit into a single erase page.

So? European health care has a median among countries, and it's still valid to compare that median to American health care.

I'm aware of that. But what should I do if I want the browser to write the page to flash memory, such as if I'm about to go offline for an hour?

Because the explicit command causes unintended side effects in drives manufactured prior to the command's introduction.

Any file system supporting "secure" deletion should be filling deleted files' sectors in the background anyway.

Either way, when you read that sector back, the drive would decompress it to a string of 0xFF. This is true whether it's an "empty sector" or a row of white pixels in a BMP file.

What happens when the kernel attempts to read back a sector that hasn't been written since it was last TRIMmed?

A lot of flash controllers already use compression of some sort to reduce write amplification. So a controller could just store which sectors compress to the smallest sizes. That wouldn't be much more effort than storing which sectors are TRIMmed, and it'd ensure a well-defined response when the kernel attempts to read a TRIMmed sector.

Unless, as Immerman pointed out, a particular drive chokes on it. Sending TRIM to a device that doesn't correctly support TRIM produces "undefined behavior", and even some drives that claim to support TRIM don't in fact. No drive chokes on constant fill.

Why couldn't an operating system just write a big block of 0xFF bytes to an unused sector, which the SSD's controller would compress into an efficient representation of a low-information-content sector, instead of needing a dedicated command?

I imagine that discussing the suggestions on Slashdot first is a way to avoid presenting half-baked suggestions to busy developers.

What happens when the kernel sends a TRIM command to a drive that does not recognize TRIM commands?

Solid-state drives (SSDs) are an alternative to hard disk drives using flash memory instead of spinning platters. This greatly improves read speeds but doesn't do quite as much for write speeds. One reason is that each sector on a solid-state drive can only be erased a finite number of times before it starts failing. For this reason, the microcontroller in an SSD perform wear leveling to spread writes across more physical sectors. TRIM is a feature that an operating system can use to notify a drive that a range of sectors has become unused, which helps wear leveling run more efficiently. A cron job is a program that runs periodically in the background, and Canonical (the publisher of Ubuntu, a distribution of the GNU/Linux operating system) wants to add a cron job that scans attached drives for unused sectors and sends TRIM commands for these sectors. It's possible for an operating system kernel to send a TRIM command for multiple ranges of sectors, but the current version of Linux doesn't know this and instead sends one range at a time. This slows down deleting files because the kernel has to notify the drive of each sector range as the file is deleted. To work around this missing feature of Linux, the cron job will TRIM when a drive isn't busy doing something else.

Microsoft didn't feel a need to issue such a "security" patch for desktop Windows 8, so why would it issue such a patch for desktop Windows 8.1?