While looking for something else (of course) I ran across Deletionpedia, an archive of pages that have been deleted from Wikipedia. The idea is simple: siphon off pages deleted from Wikipedia, with exceptions such as copyright violations, libel and intentionally offensive pages.
Why do this? Wikipedia is reasonably wide-open, but it does have well-known standards for inclusion. If it's not notable, or contains original research, or creative writing, or anything else that doesn't really belong in an encyclopedia, it's out, regardless of its other merits. Deletionpedia was an effort to preserve such pages.
I saw "was" because, even though the site is still up, it hasn't been updated since mid-2008 (or 2012, if you believe the rather odd timestamps on the Recent Changes page). All in all, Deletionpedia collected about 63,000 pages in the space of a few months. Why did it stop? The last status update, from 2008, apologizes for recent downtime, promises it will return in improved form and that "Full service will resume ASAP."
Famous last words, indeed. Another cool idea that most likely just didn't have sufficient resources behind it, particularly the time required to administer the site and maintain the Python script that was meant to automate the process of sifting out pages that not even Deletionpedia should provide a home for.
The origins of the whole exercise may lie in the "Inclusionist/Deletionist" theological debate in the Wikipedia community. I wouldn't say that a site like Deltionpedia necessarily supports one side or the other. On the one hand, it perpetuates pages that would otherwise disappear. On the other hand, it lowers the consequences of deleting a page.
Neither should such a site have much effect on Wikipedia's "Right to Vanish" which, as far as I can make out, is more of a Right to Make it Somewhat Harder to Associate Your Edits With Your Identity. Invoking this right does entail deleting one's User: page (but not one's Talk: User page), but I'm not sure how the average user page would make it easier or more difficult to track down who made a particular set of somewhat-anonymized edits. But I'm not a Wikipedia.expert, so I may have missed something.
Naturally, there is a Wikipedia page on Deltionpedia, and naturally, it has been nominated for deletion at least once.
Showing posts with label mutability. Show all posts
Showing posts with label mutability. Show all posts
Thursday, February 17, 2011
Tuesday, August 28, 2007
Jim Gray et. al. on disks and scan times
Here are a couple of highlights Jim Gray and Prashant Shenoy's 1999 paper "Rules of Thumb in Data Engineering", with approximate updates for 2007.
Two key parameters for disk storage are
Increasing scan time has more subtle but crucial effects. We're used to thinking of disks as random-access devices (at least in comparison to, say, tapes). That's why we use them for virtual memory. But they're actually becoming more like tapes and less like RAM. Random access on a disk takes seek time and rotation time. Sequential access just takes transfer time. Seek time and rotation time are becoming more and more expensive relative to transfer.
This has a whole host of implications. Some that Gray and Shenoy mention:
Two key parameters for disk storage are
- Price: 1994: $42K/TB. Predicted for 2004: $1K/TB. Seagate currently offers a 500GB drive which can be had for $180, or $0.36K/TB. This isn't the bleeding edge. Seagate is announcing a 1TB drive, and I haven't done anything like a thorough search across all manufacturers.
- Scan time (time required to read every byte on a disk or other medium): Disks have been getting faster, but they've been getting bigger faster than they've been getting faster. In 1999 a typical 70GB drive with a transfer rate of 25MB/s would scan in about 45 minutes. The paper predicts 500GB, 75MB/s and 2 hours for 2004. The Seagate 500GB drive can sustain 72MB/s.
Increasing scan time has more subtle but crucial effects. We're used to thinking of disks as random-access devices (at least in comparison to, say, tapes). That's why we use them for virtual memory. But they're actually becoming more like tapes and less like RAM. Random access on a disk takes seek time and rotation time. Sequential access just takes transfer time. Seek time and rotation time are becoming more and more expensive relative to transfer.
This has a whole host of implications. Some that Gray and Shenoy mention:
- Mirroring makes more sense for RAID performance than parity. With mirrors you can spread read accesses out across multiple copies, clawing back some of the lost random access performance.
- Mirroring also makes more sense for backup. Gray and Shenoy look at tape backup and conclude that tape storage will soon (i.e., now) be purely archival. It just takes too long to scan through all the data on tape. They don't look at CD/DVD, but 500GB of disk is about 60 dual layer DVDs (neglecting compression). Better just to keep multiple copies online.
- Log-structured file systems will make more and more sense for general use (and were already prevalent in high-performance database systems in 1999). This dovetails with the "change by adding" viewpoint of wikis, version control systems and such.
Monday, August 27, 2007
One thing I actually knew about Wikipedia
I see Wikipedia has snuck a little "Ten things you didn't know about Wikipedia" link onto their pages (now that's not very NPOV, is it? [Ed. Note: It's since been softened to "Ten things you may not know ..."]). The sleeper in the list is #4: "You cannot actually change anything in Wikipedia... (you can only add to it)".
This feature of Wikis, dating back to the original WikiWikiWeb, is what gives them their agility. Since there's a complete history, there's an "undo" button on everything. This lets editors "be bold", makes it easy to revert vandalism, provides a fascinating view of the process behind a wiki apart from the results, and doubtless provides any number of other benefits I haven't thought of.
I've long been convinced that this sort of "change by adding" model is the norm in the non-virtual world, or at least closer to the norm than the "instant, compete overwrite" model that the CPU sees. Some random examples:
Web protocols handle either scenario. It's up to the author to decide whether a link means something ephemeral or something permanent. Thus the distinction between permalink, which implies that the contents will not change, and plain link, which carries no particular implication.
There is a full spectrum of mutability available, from a true permalink from a source like Wikipedia that promises no changes absent a full-blown catastrophe, to something completely ephemeral like the wind speed at a given weather station. There is also a lot of interesting territory in between that seems worth exploring.
This feature of Wikis, dating back to the original WikiWikiWeb, is what gives them their agility. Since there's a complete history, there's an "undo" button on everything. This lets editors "be bold", makes it easy to revert vandalism, provides a fascinating view of the process behind a wiki apart from the results, and doubtless provides any number of other benefits I haven't thought of.
I've long been convinced that this sort of "change by adding" model is the norm in the non-virtual world, or at least closer to the norm than the "instant, compete overwrite" model that the CPU sees. Some random examples:
- If you return an item, the charge doesn't disappear from your account. Instead, a matching credit appears.
- Other recordkeeping -- school transcripts, employment records, hospital charts, etc. -- tend to follow a similar pattern. Your state changes and the record maintains a history, adding new notations and documents as things happen.
- A print newspaper, by necessity, can't unprint an article. Instead, it issues a correction or retraction.
- Similarly, reference books accrue addenda and errata. When these are finally published in a new edition, the previous edition still exists.
Web protocols handle either scenario. It's up to the author to decide whether a link means something ephemeral or something permanent. Thus the distinction between permalink, which implies that the contents will not change, and plain link, which carries no particular implication.
There is a full spectrum of mutability available, from a true permalink from a source like Wikipedia that promises no changes absent a full-blown catastrophe, to something completely ephemeral like the wind speed at a given weather station. There is also a lot of interesting territory in between that seems worth exploring.
Subscribe to:
Posts (Atom)
