One Pile Filing System
One Pile Filing SystemA friend of mine had a OnePileFilingSystem upon which he stacked the papers and correspondence he worked with. The most recently worked with paper was on top. When he had to go through his pile to find something he needed, he afterward placed the paper on the top of the pile. He purged the pile every so often by throwing away about 1/3 of the pages nearest the bottom since the least used or referred to pages would make their way downward. It was a LeastRecentlyUsed method of information management. He never had more than a couple hundred pages in his pile. It would all fit in his inbox.
I think this is a useful method to reduce one's personal InformationOverkill.
Reminds me a lot of an LRU paging system.
Reminds me a bit of a HeapDataStructure.
This is worth implementing within a PersonalWiki in a limited space, such as a floppy drive, zip drive, or CDR, with the other space being either the local machine, or a Web-based Repository.
GoboLinux places all installed programs in the /Programs directory. It has the (indirect) ability to track which programs are actually referenced by other programs. E.g., if you install the SDL library in /Programs, and other packages depend on SDL, then iterating through all installed programs and using "ldd" will essentially allow you to mark and sweep programs. In other words, you could theoretically garbage collect. Although possible with other directory layouts, it's made substantially simpler with Gobo's.
This is relevant with OnePileFilingSystem because garbage collection often makes use of generations. And generational GCs essentially work the same way as OPFSes. This suggests, therefore, that a personal wiki isn't the only application of OPFS. I posit that any program or data file should be subjected to this, except those marked such that they stay forever. In other words, things like critical system files and so forth. So, as programs and files tend to no longer be used, then they will get automatically disposed over time. If there is a (direct or indirectly discovered) dependency graph available, then the decision of what to dispose can be made even more intelligent, resulting in a filesystem which disposes files with no known dependencies first, choosing to dispose those with dependencies if, and only if, absolutely necessary.
Just an idea. -- SamuelFalvo?
Heh. Anything locally modified by human effort should be marked to stay automatically. We're hardly short on storage anymore. However, the idea of collecting LeastRecentlyUsed programs and such is still useful... I've considered doing such for distributed, open (i.e. multi-authority) operating systems where garbage collection is nigh impossible. This is especially tempting for programs that can be largely regenerated if needed in the future (the cost being some loss of state).
The idea as presented by the story about this system is that its main use is to control the accumulation of tasks and artifacts which are not presently of near-term importance to its collector. Its use is not so much that of collecting and storing as it is of being used as a ranking mechanism. The pile can be thought of as a series of "notifications". They are not LeastRecentlyUsed as much as they are MostRecentlyUsed?. The lower third of the pile belongs to the former, the top two-thirds to the latter. In a way they are a linked list which is arranged in an order such that when one particular element is accessed, it is moved to the first element and all remaining elements are subordinated by one position. New items are added to the linked list in the same manner as accessed elements, at the head of the list. The periodic nature of removal is made to manage the size of the pile. At one extreme, the pile could be managed so as to remain at a constant number, where the least used (the bottom item) is removed from the list at any time an item is added (new). At the other extreme, the pile might be allowed to accumulate until a certain time or certain size is reached. In effect this would result in a pile building to a point, and then purposely reduced to a preset minimum size. The scheme might be applied to a number of computer applications to good effect. The history of this wiki over the past two years can be said to have resulted in this behavior. The number of pages has come to be limited by the activity of its participants to one of about 33000 pages. Perhaps this is this wiki's most recent contributions to what is a Wiki. -- DonaldNoyes 20071003
Wow. I've had the worst time handling paperwork and paperwork-like tasks since my health took a nosedive in 2000/2001. (In fact, I GaveUpOnEmail? at the end of 2002 so that I'd have one less source of stuff to fuss with.) ThankYou. This OnePileFilingSystem looks encouraging. ThankYou for the encouragement. -- ElizabethWiethoff
Is anyone aware of an e-mail client that can sort messages by frequency of access? I'm not sure how useful such a puppy would be, but it would be an application of the OnePileFilingSystem.
Sounds like the Noguchi filing system (http://communicationnation.blogspot.com/2005/12/noguchi-filing-system.html).
Related: IsAnythingBetterThanPaper
Users:
He never had more than a couple hundred pages in his pile. 567 So on average had to manually search 100 or so pages to find whatever he was looking for at any given time? Assuming a rapid scan of 3 seconds per page, that would be an average of 5 minutes per search, making it possible to find only 12 things per hour, if the whole hour was spent in uninterrupted searching.
But if it was organized into projects filed alphabetically, with an average of 20 pages per project, then at the same rate it would take 3 seconds to find the letter, perhaps 3 seconds to find the project, and then up to 60 seconds to find the page. 66 seconds vs 300 seconds. The ability to find 54 items found per hour vs 12.
If you needed say, three pages regarding one project, that would be 3 searches, taking a quarter of an hour with a one pile system, or a little under 3 minutes and 6 seconds with an organized system.
If you needed to gather all the info for one project, that would be only 6 seconds with an organized system vs. a little under 6000 seconds with a one-pile system.
But on the other end of the pipeline, it takes no time to throw something on the top of the stack vs determining which project it belongs to and creating a new one (with cross-references) if needed. Because an organized system is no good if it's not well-organized.
He purged the pile every so often by throwing away about 1/3 of the pages nearest the bottomAnd hoped that there would be no repercussions for having not only buried and forgotten something for a month, but then having thrown away all the info that would be needed when someone finally reminded him about it?
Perhaps the fact that it hasn't been touched in awhile indicates that it should be evaluated. But an evaluation of around 60 pages at one minute each is only an hour. On the other hand, an evaluation of 3 projects at one minute each is only about 3 minutes. I could see a onepile combined with a lack of spare time resulting in things not getting properly evaluated, and therefore either left on the stack, making it grow inefficient (further reducing available time), or thrown away without evaluation (causing crises which further reduce available time).
Most of the stuff my friend's pile was advisories, notifications, and confirmations regarding items contained in his organizer, or in the only report he had to produce each week which was a detail of accomplishments toward completing a single project. The report was an Excel spreadsheet about items in a production inventory and included over 60 columns and just under 5000 lines. The report was the result of spending 90 percent of his day on the plant floor identifying what was to go in each cell of the report. His pile would only include items either having to do with information coming from outside the plant (from vendors and manufacturers of the production equipment), or notices about meetings or seminars requiring his attendance, or flight and lodging confirmations, etc. Directives about what he was to do and when it was to be accomplished were part of his training before project began. Infrequently, changes might be made and notices received by mail (lotus notes), or he on a couple of occasions received operating instructions for some technically challenging equipment (a TDR to discover cable faults) or about Block I/O devices used to control a production conveyor, etc. These were all things which were multiple pages. He made changes in the production equipment report in his laptop, which he carried with him on the plant floor. The system was one about which he said "ItWorks". His job was done when the report was completely filled in with completed information or completed tasks. There are many other kinds of projects and tasks where similar methods might work. It is not a one method for everyone kind of thing, but rather for jobs which are not "paper-work" intensive. (See PileFilingSystemsWithManyPiles)
I do the same thing: a big stack in which I toss the bottom 1/3 when it gets too big. However, I don't put everything into it, just stuff that's near the border-line between keep and toss. Stuff that clearly belongs in specific folders still goes into folders.
I've also used a similar technique for (digital) process logs. When the log gets too big upon a new addition, the oldest 1/3 automatically gets deleted. However, unlike a paper pile, the log is readily search-able by various columns. --top
insert record
if log.size > 9000 {
delete oldest 3000 records
}
CategorySolutions | CategoryCollections | CategoryFileSystem
EditText of this page
(last edited December 7, 2014)
or FindPage with title or text search