Hacker News Reader

Hierarchical filesystems are primitive ops. How you use your filesystem, that's a layer above - and a lot of it is convention not necessity, defined in the age of the Apple beige toaster and preserved by generations of don't-make-me-think. File, save, save-as: those are older than the commodity hard drive.

Lets imagine different conventions. As soon as you start typing it puts a file in $HOME/Documents (or a configurable alternative). If the application is amenable to guessing a title (like the first entry in Heading 1), then it uses that, otherwise it goes with the usual "untitled". The menu ops are File -> Open, File -> Save, File -> Save a copy, File -> Set name and File -> Move. The last file opens if you stop and restart. Every single operation gets lazy-queued for flush to disk on an activity log (more than just auto-save: preserve every undo-able op). Save means "commit my changes to the canonical copy and clear the activity log".

All of those still use the hierarchical file system. They just use it in a way that makes modern sense.

What if a box were provided near the top of the document with the document's current name? To rename the file you simply type the new name in the box.

Users should never really have to worry about saving. Google Docs does a good job of keeping documents saved without any need for user intervention.

A box with a name would be good, but you miss one important function of saving I took pains to preserve: it is the action which turns tentative changes to the file into permanent ones. You want to preserve those tentative changes, but you don't want to put them in the actual file until the user commands it.

True, with current software you don't want to save tentative changes but the only reason for that is that your "undo" history is lost the instant you close a program. If you could undo changes through the entire history of the document explicitly saving becomes pointless.

That works for a Word document, but what if you were editing a PHP file? You neither want your changes to be immediately applied while they aren't finished, nor can the PHP interpreter handle a special format with embedded undo.

Or, lets suppose you just log the undo in a hidden file alongside the original. Imagine you've edited a lot of files. All that eternal undo would pile up, and you'd end up with gigabytes wasted on useless undo logs. Plus plenty of stranded logs from moved files.

No, the ability to save, to not save yet, and to abandon the undo - those are useful features.

Amen. And iTunes is a total nightmare if you don't want it to store the files where it wants to. I'm all for abstracting away the file system, but the fact remains that there are files under there, so don't make it difficult for me to deal at that level when I have to.

I wouldn't call unchecking one preference a "total nightmare".

However, Mr. Figs, and this is speaking from personal experience, if you happen to store your files on an external USB drive, and you happen to launch itunes at a moment when the drive is disconnected from your laptop, Itunes will revert to its default folder--forcing me to think about things I shouldn't be polluting my brain with.

I actually find that handy for use with my laptop--unplug the HD, import my "core library" (about 30GB), then plug it in and import the rest (over 200GB at this point.) Thus, when I'm out and want to listen to something, I still have all my favorite songs; just not everything (which wouldn't fit on my laptop's HD, anyway.) Basically, it turns the internal HD into a not-too-smart cache of the external one. (On that note, if there's a program that provides this internal/external storage caching mechanism more intelligently and on a larger scale, I'dclove to hear about it.)

If you're not expecting that, and have mostly empty or invalid ID3 information, because you have habitually kept metadata in the filename and directory hierarchy, iTunes will destroy your library. Everything becomes Unknown Title 243 by Unknown Artist 14, and by the time you notice (because who's expecting an MP3 player to rearrange all the files on disk!?), the only way to fix this is by listening to each track and trying to figure out via Google what song it is.

This happened to me in 2003 when I switched from Linux to Mac. I still get a little worked up over that, even though nowadays I just let iTunes manage everything and throw away the original files after I rip something.

As in the cases people already described, and some others I won't go into, it is NOT as simple as unchecking a preference.

Also, try plugging your USB hard disk into a different USB port in a different order from your iPod. Now it comes up with a different drive letter and iTunes can't find any of your music.

Most people don't understand hierarchical filesystems.

It might not be the best way to organize most files, but people do understand hierarchical systems. There are too many examples of hierarchies in everyday life.

I do understand hierarchical filesystems, so why would I want to do things the same way as people that don't?

The filesystem isn't relevant to what either of you want to do - namely, start taking notes, and, not lose them if you forget to save them.

Sure, save them wherever you like however you like - but I bet you start with "I need to make a note of this phonenumber" and not "I need to create ~/data/contacts/business/suppliers/joans.computers" so I can put this phonenumber in it".

> I bet you start with "I need to make a note of this phonenumber" and not "I need to create ~/data/contacts/business/suppliers/joans.computers" so I can put this phonenumber in it".

I only save things that think that I'll want to find some time in the future.

As a result, I don't think "I need to make a note of this phone number". Instead, I ask something like "How do I make a note of this phone number so I can find it again?" and then I think "I should put it {some place}".

Yes, hierarchical file systems are merely one of the many ways to implement "{some place}", but that doesn't make "{some place}" unimportant, irrelevant, or unnecessary.

Interesting. I think your point is generally good but that phone numbers is an example against it. I tend to document stuff using the second approach, because I'm documenting for lookup. Phone numbers are a case in point - I always have it in front of me on a scrap of paper, but want to enter it into the appropriate page and place of our wiki where I or a colleague will be able to quickly recall it later. I'm creating it with the lookup in mind.

Whereas if I'm opening a document just to play around with ideas I won't be doing that, and most documents start that way. I think this is why Word has so far won the field in mainstream document production. Word is a superb tool for prototyping and terrible in almost every aspect of structuring data for its long-term use.