Hacker News Reader

Comment by smacktoward | Hacker News Reader

The bit about replacing folder hierarchies with tags and search reminds me of some ideas that are actually pretty old now. Back in the '80s and '90s, there was a wave of interest in replacing the traditional filesystem with a relational database, for most of the same reasons as outlined here (we can store more files than we can meaningfully organize, hierarchical organization doesn't really fit lots of use cases, searching is easier than clicking up and down a hierarchy, etc.).

This led to a bunch of different products and almost-products, like Apple's "Soups" for the Newton (see https://en.wikipedia.org/wiki/Soup_(Apple)) and Microsoft's WinFS (see https://en.wikipedia.org/wiki/WinFS), and the original file system for BeOS (see https://arstechnica.com/gadgets/2008/03/past-present-future-...).

None of these ever really took off, though. Mostly this was because they ran into unsolvable performance problems. Hardware has come a long way since the mid-'90s, though, so it'd be interesting to see if those ideas that were impractical then are practical today.

View on HN

I think those ideas don't take off because tags don't really solve the problem adequately for normal people.

A folder structure is a self-contained map that will help guide me to the correct document. Each step has hints about where I can go next (sub-directory names), starting from most broad going to most specific. It takes advantage of both locality (similar topics are usually next to each other) and logical, hierarchical grouping.

A tag is a random thought or property stuck onto a file that I now have to remember every time I want to find that file again. I have no way to specify that tags may have a useful hierarchy of other similar but distinct items without manually coming up with a tagging system to give me that. Folders do it by default.

Basically - Folders are a good enough default. Tags might be better in some cases, but you have to be excruciatingly disciplined about using it and I find most people just end up recreating a structure that looks suspiciously like folders.

While I agree with the general sentiment that the mental model of tags is more complex and discovering the right tags is a bigger challange than slapping some tag onto some file, I don't see it as something that needs to replace a traditional file system.

Tags are more useful for certain types of files than others. E.g. let's say you want to mark certain projects done. Instead of moving them to a done folder you can just add tags to them – without changing any paths you change their status.

Tags are also quite useful for pictures, music and other media content.

I never really got, why even in 2019 there is not good support for tags on most desktops.

macOS' Finder has had tag support for some time.

That's ~10% of desktops in the world (and 1 of the 3 "mainstream" desktop OS out there, counting linux)

I'm too much of a mess to use them, but they're there.

Windows has had file tagging since at least XP. Not a lot of people use them (probably because the UI for it is hard to discover), but I have used stuff like royalty-free photo libraries that have searchable tags.

Here's a reference: https://www.howtogeek.com/344543/how-to-tag-any-windows-file...

The problem is that it can only tag those files that provide data structures for tagging like IPTC and EXIF

You can't tag the notes that you write about the holiday you had.

The problem is that it can only tag those files that provide data structures for tagging like IPTC and EXIF

You can't tag the plain text notes that you write about the holiday you had or the bitmap that you created from one of the jpegs.

I'm not familiar with Windows file tagging, but on MacOS this is not true. Any and all files may be tagged, regardless of their type or contents.

What happens if you move or copy a file?

Moving and duplicating both preserve the tags: they're metadata. They're part of the reason for those pesky .DS_Store files that proliferate on network shares and non-Mac filesystems, in fact.

Yeah, they had it back in OS9

I want to have both options because traditional folders and a tag based file system solve different problems.

Let's say I go on vacation with my dog and make pictures. After I am home again I want to sort the pictures but then I have a problem: the pictures in which you can see my dog in belong into the '2019 vacation to Bavaria' collection _and_ also in the 'Best pictures of my dog' collection.

I'd love to have some sort of universal file-database where I can store all my "final" images and then create collections by adding tags.

In macOS (for some number of years now) you store files in a standard folder hierarchy, and you can add tags to files. With or without tags, you can use Spotlight (cmd-space) to quickly find files.

Yes, I know that there are approaches which use the normal file system.

But what I want is different:

I want a universial "DB for binary files" where I can store binary data and all its metadata.

Then I can use this DB to build a app for picture galleries, music collections and tons of other things.

This DB should also support:

* automatic checksumming so that I can detect data corruption

* Some sort of version history so that I can store multiple versions of a file

* there could be built-in replication which I can use to see the same data (or parts of it) on all my devices

Is this common enough a use case that it ought to be a file system feature?

Plenty of applications do just this today by using the file system plus an index in SQLite. Is that method insufficient?

You asked: "Is this common enough a use case?"

Then you answered your own question: "Plenty of applications do just this today".

So yes, it is a common enough case that it could/should be built into the OS.

Well, OS could certainly offer some support, like file change detection, but the main indexing is often too application specific.

Photo albums wants to do face recognition. Music player wants BPM detection. Should those be done by OS? I do not think so.

I think the old BeOS supported what you are describing.

And Haiku, its open-source successor does also.

Sounds a lot like ZFS.

Exactly - ZFS offers everything on the bullet list.

You can achieve this in existing systems with a hardlink.

A hardlink is a (poor, partial) implementation of a tag in the file system. A tag will recover a collection of all the elements filed under the same label, and a link can't do that.

I think hard links could. To take the up-thread example, you have one folder called "Vacation2018", and another called "BestDogPics". The photo of your dog on vacation lives in both folders, but hardlinked together.

I think we'll start to see that happening as machine learning is used to tag the files. See Google Photos for example, where you can basically use search in place of any sorting.

I would like both as well. I can see value in tags but I am thinking from a developer perspective, I'm not sure how I would target a specific file in my code without a tree structure? Maybe I just haven't thought about this enough but it seems necessary.

I think most of the photo organizers offer this? I remember using digiKam back around 2006 or so, and it already had this feature.

I think tags have limited scope. They are great for photos. They are OK for music, but strictly in addition to the main hierarchy. You could use them for text docs, but folders + full text search is much better. And file level tags are completely useless for code/programming

If you have a rich set of tags, you can have more than one main hierarchy.

Artist sort, year sort, genre sort, etc. Genre is really hard though.

There isn't much reason to use tags as the only way of organizing things though, they work great as views.

Agree, views, but not main organizing principle.

For example, my music collection is big and diverse, and both "year sort" and "album sort" are kinda useless now, because there are actually multiple disjoint subsets. There is no point ever in showing me audiobooks for year 2010 and regular music for year 2010. I always only want a subset of it.

This is what I meant "strictly in addition to main hierarchy" -- let me keep my folders, and maybe when I want to go deep enough, I want to browse by tag. But even then it would not be a hashtag-like tags that the original page refers to.

I think the key thing here is that files can indeed be categorized in different ways, and could - and should - exist simultaneously in different collections with different structures.

I therefore think it'd be worth separating the concept of a "filesystem" from a "folder system" or "index system". That is: keep the file storage itself flat (e.g. in a relational database table), then have different categorical "views" that could be relational and/or hierarchical pointing to these files. Naturally, those collections will have their own sets of metadata for that file.

So for example, you have a file named "img-8675309.png" in your camera's storage. The operating system presents a view of said camera storage, in the form of a flat list of files and some basic metadata like creation date (plus perhaps camera-specific metadata if, say, the camera driver is the thing generating the view). You could then open up views for your 2019 Bavaria vacation ("Vacations" → "Bavaria 2019" → "Photos") and your dog ("Pets" → "Fido" → "Photos"), set a sorting field for each view (for the vacation, probably chronological; for your dog, by however you define "best"), drag/drop the camera file into those views (in the latter case, maybe even drag it into the spot where you want it to show up ranking-wise), and the operating system would then add references to that file automatically (almost certainly copying it into a local cache) in both your opened views and potentially in some system-maintained views (e.g. "Local Files" → "Photos").

One of the slick things here is that file access could be entirely transparent to how those files are stored. For example, those views will of course include your device's internal storage, but might also include external devices (like the camera in the above example) or even remote services (like, say, your social media account). If you accidentally delete your prized Fido photo on your local machine, the "Pets" → "Fido" → "Photos" view could still have a reference to the copy on the camera, or a copy in your social media posts, or a copy in the system backup that automatically ran last Sunday, and thus retrieve it and re-cache it locally (or prompt you to plug your camera or your external USB drive back in so it can check there).

> A folder structure is a self-contained map that will help guide me to the correct document.

A hierarchical structure like folders also maps well to how we locate things in real life.

Suppose I want to get a particular book I have. I enter my home through the front door, pass through the living room, from it enter the corridor which links all the rooms, then enter the office, within it go to the bookcase, open the first door on the left, go to the third row, and it's one of the books which are located in that shelf.

In a typical house there's likely also at least one alternative route to get to the office. How do you represent that path with tree hierarchy? Tags (at least nested tags, as shown in OP) allow you to create a generic graph.

For most desktop users this is solved with links and shortcuts; I might navigate directly to a document's location in the hierarchy, but it's more likely that I'll rely on an automatically generated link in the 'recent files' area, or a shortcut I created somewhere to the folder containing it.

Even if there are multiple routes, I still remember by location. What I remeber is "The forks are on the top left kitchen drawer" -- not "to get to the forks from the fridge, turn around and walk two steps to the right; and to get to the forks from the table, turn left, then walk around the cabinet"

How do you represent that path with tree hierarchy?

You represent that by using a spatial Finder [1] (with aliases), instead of a browser. Files and folders can be organized spatially on the desktop and within each window. Since a given window is a permanent view into its folder (there was no way to open multiple windows of the same folder nor could a window ever show a different folder) it was extremely easy to remember what you were looking at, visually.

The classic Mac OS also had tags which you could use to flag files and folders by colour and of course you could change folders into small icon or list view in order to handle many files at a time. These view settings permanently applied to a given folder, so every time you opened it you would see the same window, in the same place, right where you left off.

To someone who may never have used this system, it's hard to describe how incredibly productive it was. Humans have extremely powerful spatial memory and the classic Mac OS Finder leveraged that perfectly. Just like the example of someone walking through their house to retrieve a book from their library or a letter from their desk, you could navigate your folder structure visually, without even reading the file names; it was incredibly powerful!

[1] https://arstechnica.com/gadgets/2003/04/finder/2/

Boo, the finder is the worst thing to happen to UI because it is like pulling all the leaves off a tree and then ranking them in interesting ways. I mean, it's useful and great but at the expense of stalling development on tree/graph representations for the last ~30 years.

I mean look at this article - great writing, lots of good ideas, but not a single picture until page 9 of 10 and then you just get two lists and a card catalog metaphor. Whoo, dynamic lists. The problem with a spatial finder is that it's all about ordering things, which is a hideously constrictive thing even as a dynamic process because it reduces everything to one dimension and encourages quantitative rather than semantic thinking (let me be clear that I'm blaming Apple for this unhappy state of affairs rather than the author).

We can see another instance of this in the mentioned bookmarks; it's 2019 and the only options I have for exploring my bookmarks in any of the popular browsers are as a 90s style menu tree. Why doesn't my browser pro-actively tag my bookmarks and allow me to apply any of many categorical schemas that people share. Likewise, why can't I configure my browser to be more selective about CSS? It blows my mind that websites and apps offer 'dark themes' as a feature when theming has been a basic part of desktop UI for >20 years. I should be able to view any website through a dark theme whose darkness and basic palette I've chosen for my browser, in the same way that I can put on sunglasses rather than having to wait for artificial things in my physical environment to be painted in less vibrant colors.

I'm well aware that there are any number of CSS modifiers and plugins, I have used many over the years. But they all require either restyling individual website elements via a GUI or writing replacement CSS code. This is like saying that if you have an uncomfortable chair the solution is to take up woodworking rather than throw a cushion on it. I am never going to write code to increase my comfort (as opposed to developing new tools) because the discomfort of having to acquire competence with yet another syntax vastly outweighs the likely aesthetic improvement. It would make perfect sense if I was a working designer but I'm not and don't want to be. Invitations to code something oneself are implicit failures to understand the problem, confusing the cup with its content.

I submit that part of the problem is that designers and developers are hopelessly constricted by their own axiomatic metaphors. Take bookmarks; I still use physical bookmarks occasionally, and they're essentially nodes for a particular marker in a one-dimensional linked list (the sequence of paper pages in the book). The browser allowed us to take a collection of such one-dimensional markers and structure them in a binary tree form. That's nice, but by now we should be up to using quaternions to explore 4-dimensional slices in n-dimensional semantic space.

Frankly, if I were dictator of the internet my first rule would be that you can provide content or rendering but not both at the same time unless you want to be in an art museum. UI paradigms are like vessels into which content is poured; the web is the equivalent of having to buy drinks only in single-serving cans or bottles and then telling people to be happy with the huge variety of packaging options, with no regard to the time and cognitive overhead of trying to find what you want behind 500 layers of branding. Economists refer to this as the paradox of choice: little, no, or even negative value is being delivered to the consumer, while vast resources are being spent on trying to slightly expand market share through product differentiation. In some cases, far more economic resources than required for the manufacture and delivery of the underlying product and with significantly higher negative externalities in terms of energy and anxiety.

The problem with a spatial finder is that it's all about ordering things, which is a hideously constrictive thing even as a dynamic process because it reduces everything to one dimension and encourages quantitative rather than semantic thinking (let me be clear that I'm blaming Apple for this unhappy state of affairs rather than the author).

Can you elaborate on this a little more? I'm not quite sure what you mean here.

To me, the spatial metaphor Finder was all about semantic thinking. I'd open up my project folder and all of the documents would be spread out visually, within the 2D plane of the window, and their spatial orientations and groupings carried meaning for me. Additionally, I'd tag things with various colours, such as marking a file red (for TODO) or another one green (for Done). This was just about as far from one-dimensional as I could envision a workable UI (3D UIs have been tried in games and they're pretty clunky).

As for bookmarks? I agree with you. Bookmarks suck!

Well, you make a fine point about the colors, which were something I'd forgotten to consider. I did (and do) use this approach, but with the passage of time my enthusiasm for the maintenance required has really diminished.

What I am looking for is something in the same ballpark as dynamic graph generation as seen here, but with shareable tagging: https://www.mcnutt.in/forum-explorer/

When you say their spatial orientations and groupings carried meaning for me I wholly agree; What I'm trying to say (poorly uwu) is that managing the finder or other WIMP desktop elements is like laying out a beautiful graph in Visio or some other flowcharting software, vs the sort of dynamic graphs that the computer can render for you on the fly.

Taking the example above and imagining it extended to disks and documents as opposed to topics and comments, suppose you could have nesting nodes, whose size might be a treemap-like function of their content and whose layout might be manged with Apollonian gaskets; and imagine further that I could click on the name of individual contributors (isomorphic to file properties or curated tags) and quickly see a cross-section of their contexts - not the text of the individual comments, but the immediate neighborhood of the graphs in which they appear; and imagine further that as I applied selection criteria of various kinds to refine my graphs, their unique combination would itself form a metagraph which I could save at any time, like the key to a particular collection.

That last sounds a bit handwavey, but I'm imagining a fairly small graph that would map about the same amount of information as a regex string or polynomial expression. You wouldn't read the content of these graphs (unless you really wanted to) any more than you measure the ridges and notches of your most commonly used physical keys. They'll just become shapes you recognize and name to unlock your favorite perspectives, fulfilling much the same function as the extension buttons on your browser toolbar.

Taking the example above and imagining it extended to disks and documents as opposed to topics and comments

I like to think of it in terms of the real world objects the metaphor is meant to mimic. So I think of documents the way I would pieces of paper on my desk and control panels like light switches in my house (to borrow John Siracusa's example).

On the other hand, something like an address book or a filing cabinet full of tax records is not what I'm interested in organizing spatially. Instead, I'd use a purpose-built tool such as an address book application or document-oriented database. Likewise for photos or music, which lend themselves to custom database applications of their own.

I'm not sure what your treemap-like graph database would be optimized for, other than disk space cleanup tools (which I have used).

How do you make a spatial finder work with multiple devices that have different screen sizes?

Same way you draw a UI for different screen sizes: you scale it. If you were doing this from scratch today, you'd use a resolution-independent UI drawing library, such as one based on vector graphics.

As for wildly different aspect ratios (portrait vs landscape) you're just going to have to compromise. As long as you have a mechanism to make sure windows can't get lost outside the bounds of the screen, you should be fine.

It the problem should only happen once, though. After your files have been synced between the devices for the first time, thereafter each device should maintain its own window positioning.

If you scale down a large display to a phone-sized one, either usability is horrible on the phone because touch targets, text etc. are too small or you cannot use the space of the large display effectively.

> After your files have been synced between the devices for the first time, thereafter each device should maintain its own window positioning.

No they shouldn't. That breaks the entire metaphor because now items don't have a single spatial position anymore.

Tags are a strict superset of folder functionality. There's nothing you can do with folders that you can't do with tags. You want nesting? Tags can nest. You want visual clues? Tags can have visual clues. Folders can be and sometimes are implemented as tags.

Well, tags and folders are identical. You can have the same file linked to from multiple folders at once. `ls` will even show you the number of folders the file is part of in the second column.

I agree that there's lots of value in the simplicity of a tree hierarchy as a default, but sometimes the extra power of a tagging/labeling system would be valuable. Essentially it gives you a generic graph structure. Others have mentioned that this is valuable for things like media, ie photos that often need to be members of multiple album collections. It could also have other benefits as well, such as being able to visualize your filesystem as a graph, and easily see clusters of data depending on which tags are used the most.

The only heuristic we really have for tree filesystems to get a feel for a subtree (child folder) is the total disk usage of that folder, or maybe total number of files in the subtree.

I agree that tags shouldn't really be some additional meta property on the existing files/filesystem.

I had an idea to use folders as tags, and to make a script that moves folders around according to the usage of the tags. So that way we have hierarchical folder structure, and the folder name is the tag, but it will stay organized according to the usage.

The trick in my case was to come up with a convention for a folder name in order to make it obvious it's a "tag" folder.

https://github.com/foucist/tagmv

I am also not a huge fan of tags. Gmail uses tags. It allows hierarchies of tags. In theory that is more powerful. It's like a folder system where something can be in multiple folders. In practice it just makes things messy.

Gelernter disagreed and proposed temporal vs spacial organizational metaphor.

http://www.cs.yale.edu/homes/freeman/dissertation/etf.pdf

Autogeneration of topology tags should solve this. I also need tagging agents that run around when I'm not busy and tag things on my behalf, particularly recognizable patterns in existing tagged structures.

Tags are like a book index while folders are like a table of contents. Both are very useful, but I'd say an index is more useful as it can scale very well across multiple books. (Such an index would have its own table of contents, I think :)

You can have hierarchical tags even with a flat system, just name them "foo", "foo/bar" and so on. (And if you design a tag system nothing prevents from adding a hierarchy of tags.) But you're right tags need discipline and single source. There's no way to have a community-based tag soup without some sort of tag police.

Another problem is that all tag-based system I saw (not many) looked very much in their infancy. All they had was very basic flat tagging without hierarchy and very basic search. These are not enough to realize their potential.

It doesn't work because users are unwilling to go through and tag all their files.

We live in a world were people still email word files back and forth, incrementing numbers at the end in a desperate attempt to keep track of versions. (Or just appending "final final...")

Now imagine asking users to tag each copy of that word document that lands in their inbox and gets downloaded? (Assuming file system tags will be tossed soon as the file goes through email).

Google Photos does tagging properly. They only had to spend 5 years building the most sophisticated consumer visual machine learning algorithm ever made. Then they made it work on animals. (Why haven't I seen any discussion around the fact that Google has trained a model to identify animals by their face? Super cool!)

But even ML is only ever going to be able to ID a subset of content.

(Google's auto tagging of things is mind blowing though, did you know you can ask Google for a list of all restaurants you've visited in a given city? Creepy but useful!)

> It doesn't work because users are unwilling to go through and tag all their files.

I tend to agree -- in fact, I was just describing this very idea (that users will go in and mark up their all their content if we just give them the tools to do so) the other day here on HN as "the metadata delusion": https://news.ycombinator.com/item?id=19515848

But it's important to note that tagging as the main usage scenario is envisioned by the linked article, not by those earlier RDBMS-as-filesystem projects. Those older projects assumed that much if not all of the metadata associated with data would be generated and managed by applications sitting on top of the database, using it as their data store. Users could add additional metadata if they wanted to, but they didn't have to for the system to be able to offer benefits.

The RDBMS-as-filesystem argument went more like this. If you want to be able to filter all your documents and only show the completed ones, then yes, allowing you to put a "done" tag on those documents is a crude way of doing that. But if all applications have access to a common data store, more sophisticated options become available, like letting developers build a workflow application that can read your documents and track changes, log approvals/change requests, etc. Then you wouldn't have to tag done documents "done"; you'd just use software to do your work, and your applications would teach the system what it means for a document to be "done".

(Of course, those older projects all fizzled out in the marketplace so we never got the chance to find out how these theories would have played out in practice.)

"It doesn't work because users are unwilling to go through and tag all their files."

This doesn't make sense. They "File -> Save" to a location, right? That's a tag. All metadata is tags. People give filetype suffixes to their filenames, right? That's a tag. They might "Save As -> Format", right? That's a tag. Maybe they "File -> Print" on January 17 at 3pm? That's a tag.

Oh and ALSO they are a 'superuser' who wants the photo to go into "Great Pics Of My Dog" tag? Cool, they apply that, and that's also a tag.

People can handle change, people can handle simple concepts, people use tags today, people can handle tags generally.

Getting users to tag data has already been attempted. Heck Office has had this built in for years (decades?).

We live in a world where after nearly 30 years of the folders paradigm, the vast majority of every day users still store everything on their desktop.

(Though IT policies are working to change this, forcing files to be stored on network drives and such).

Some more advanced users may use a folder called "work".

Years ago I went through and tagged all my photos. Of course the photo management system I used up and died. After that I gave up. I do have some photo organized and stored locally, but now days Google Photos handles most of that for me, including the auto-tagging.

When people sit down at a computer, they generally have a task in mind. Be it write a document, calculate with a spreadsheet, or send a picture of their dog to a friend.

Most people don't think ahead to "5 years from now I may want to find this document so I should think up of every possible word I may search for then and apply it as a tag."

Tagging data takes time, and a good deal of thought to have a coherent system. Then, technically, those tags need to persist and transfer across disparate OSs.

I personally love the idea of tags. My capstone project in college was exploring different UIs for tagging files, and trying to make the process as fast and friendly as possible.

But changing users habits is hard.

> This doesn't make sense. They "File -> Save" to a location, right? That's a tag.

The folder-hierarchy version of "unwilling to go through and tag all their files" is saving all files to the Desktop.

I actually think it has less to do with performance problems than the significantly more complicated mental model one needs to deal with relational databases. Hierarchical files and folders are very simple.

The theory was that you would never really interact directly with the database; you'd interact with applications, which would just happen to use the database as their data store. So developers could use it to build rich interfaces that were appropriate for the tasks their app was supposed to tackle, and those interfaces would shield the user from the complexity of dealing with the database directly.

This sounds similar to the mobile approach, excepting that the underlying fs is heirarchical. Do you have any idea how this worked with paths in the terminal?

I'm not sure any of them particularly cared about the terminal. Remember, this was the '90s; all the companies that explored this (Microsoft, Apple, Be) were deeply invested in the GUI as the Future of Computing™.

Yes, many ordinary users never get past the folders-on-desktop organizational level for their files...

It's a bit of an chicken-and-egg problem - or as we like to say, an equilibrium of many.

Every attempt I did to use any great tagging system, in pretty much anything ever, had resulted in the system/app/infrastructure (etc.) dying sooner or later, which is why I don't use any of that stuff, creating the same externality for others.

Folders, on the other hand, are stable. You can't change folders, at least not simply.

Jumping between those equilbrias needs a better strategy than "offer tags".

Because that's just what every user wants -- for all the performance gains of their new, fast hardware to be soaked up by OS administrivia they didn't even realize they needed. I mean, FS performance under Windows is already such garbage that an SSD is basically a requirement for a usable desktop; a little more chug is basically just gravy on top by this point.

Don't they need it, though? People are already using layers over the filesystem, like "media libraries" and "document managers", which undoubtedly trade performance for "administrivia". Maybe it'd be better if this was provided by a common layer, much like the FS already provides a layer over disk blocks.

As a counter to tagging everything, in which one "thing" can be in multiple "places" (tags), there's spatial file management. [1]

http://archive.arstechnica.com/paedia/f/finder/finder-3.htm

As someone that had to interface sharepoint once or twice, I cannot get behind the idea to replace folders. Folders are just a simple tree structure. Like any table of contents or index. That is not a concept too hard to understand. My 75 year old grandpa mastered this in about 10 minutes.

I have much more problems with people that ask how they can scrap their images from smartphones. Because they don't know where their custom app likes to save them. And I have to search too. This is 100 times worse if you do not use the one way the manufacturer intended that might not be applicable to your use case.

The article mentions some really good ideas for window managers. I currently use a widescreen curved monitor that is pretty awesome, but the normal windows window manager is actually quite decent. You just use a few different hotkeys. Nothing that inhibits "productivity".

> Hardware has come a long way since the mid-'90s

Too bad Wirth's law states that software is overcompensating for that.

Yet files are bigger now and more numerous than ever. We definitely want rich indexes of files sometimes but files can be so much more than rich data for users — they are also cheap book-keeping for programs for users. Imagine trying to implement a performant database on top of this database. No amount of technology can make O(log N) a substitute for O(1).

Reply on news.ycombinator.com