Live data from Hacker News

TMSU: a tool born out of frustration with the hierarchical nature of filesystems

tmsu.org

51–60 of 131 posts

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#51
post #25

I seem to recall reading somewhere that one of the reasons Vista was a "bad" os, was that it originally had much higher more optimistic ambitions to build a sql like file system (i suppose similar to this). It however had issues, and a decision to scrap it delayed the vista project, and reduced the scope of "cool" things it was supposed to deliver.

Yep: https://en.wikipedia.org/wiki/WinFS

An interesting chart appears on the Wiki explaining how Microsoft keeps tilting at this windmill and has two decades of cancelled or scaled back products to show for it.

I suspect there is an inherent scaling problem with the approach. While it demos well and can be useful in a lab setting, the full scale version ends up being so complex that mere mortals aren't able to comprehend it and end up just losing their files constantly in the morass of schemas and structured accesses.

The talk on the wiki about being able to write an editor that can handle any file type smells of pure insanity to me. An application that can present a usable editing interface for any filetype would be so bloated that it's almost inconceivable to think about a single company writing it. Can you imagine the kind of application that has an interface for manipulating photos, writing reports, tabulating data, programming (all languages), doing CAD, editing textures, composing music, etc...?

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#53

How is this different than something like this: mkdir -p ~/tags/{music,big-jazz,mp3} ln -s /path/to/summer.mp3 ~/tags/music/ ln -s /path/to/summer.mp3 ~/tags/big-jazz/ ln -s /path/to/summer.mp3 ~/tags/mp3/ From there, you can use all normal filesystem tools to interact with your 'tags'. You could extend this with a simple script that handles duplicate file names in the same tag by sticking a hash of the file before t…

Think of the poor inodes!

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#55

How is this different than something like this: mkdir -p ~/tags/{music,big-jazz,mp3} ln -s /path/to/summer.mp3 ~/tags/music/ ln -s /path/to/summer.mp3 ~/tags/big-jazz/ ln -s /path/to/summer.mp3 ~/tags/mp3/ From there, you can use all normal filesystem tools to interact with your 'tags'. You could extend this with a simple script that handles duplicate file names in the same tag by sticking a hash of the file before t…

This supplies you with only one relation between the tags: "And Then". Ex. 'Path' (and then) 'to' (and then) 'summer.mp3'. Or 'tags' (and then) 'big-jazz'. What you want is to also have AND, OR and NOT available. How would you find 'music' (and) 'mp3' (and not) 'big-jazz'?

I'm not saying this would be simple, or as nice as the tool given, but it's not impossible.

First, do a 'ls' directory dump of the 3 folders. Then 'cut' out the softlink destination from each file. This will end up with 3 files with soft links. From there, 'grep' the music and mp3 files together to get a list of soft links that are in both music and mp3. Then you can do an inverse 'grep' to remove softlinks that are in big jazz.

Even if the system creates hard links instead of softlinks, then the same could be done via inode numbers

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#56
post #18

Earlier quoted context omitted.

I agree. I actually like the hierarchical organisation, and I don't like the 10 year usability trend, particularly driven by Microsofts attempts to patch over their horrid structure with even worse workarounds. The solution to learning my mother were to find her documents is not hiding the place 15 levels deep and having 10 symlinks to it. Fast, unobtrusive indexing and a good structure is all that is needed. Humans…

> Humans organise and memorise things in hierarchies Big claim. Proof?

Big proofs. Conceptual categorization is a big part of how we humans comprehend and analyze the world around us, and it relies on a hierarchy of defining attributes, from abstract model to concrete specimen:

https://en.wikipedia.org/wiki/Prototype_theory#Basic_level_c...

https://en.wikipedia.org/wiki/Stereotype#Cognitive_functions

https://en.wikipedia.org/wiki/Concept_learning

Maybe less abstract: if you try to remember where your phone is, do you follow a pattern like "which room", "which coat/pants/desk", then "which pocket/drawer"?

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#57
post #28

Earlier quoted context omitted.

You have to realize though that this software doesn't take away your heiracichal system, it just gives you another way to look at it. Recently I've been cleaning up my music library and I'm seeing some of the shortcomings of the current system. What do you do with a compilation album? Have a folder for each artist or put them all together, (Which would separate them from others works by the same artist)? iTunes or wh…

That iTunes view is still a hierarchy, though. More accurately, it's still a DAG. The hierarchy is not the problem here, it's the rigidity of trying to put something in only one part of that hierarchy.

Tags are still a DAG, too. I don't see what you're trying to prove here.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#58

Earlier quoted context omitted.

Yep: https://en.wikipedia.org/wiki/WinFS

An interesting chart appears on the Wiki explaining how Microsoft keeps tilting at this windmill and has two decades of cancelled or scaled back products to show for it. I suspect there is an inherent scaling problem with the approach. While it demos well and can be useful in a lab setting, the full scale version ends up being so complex that mere mortals aren't able to comprehend it and end up just losing their file…

I can imagine such a thing; it's called a programming language. A GUI application, you say? Well then you're just asking for a graphical programming language, and as they say, now you have two problems...

I think the more general-purpose a tool is, the more intelligence and/or general knowledge is needed to wield it:

"Here's a widget thromper. You push the big green button and it thromps the widgets."

vs

"Here's a car. It will get you from virtually anywhere to anywhere else. Don't kill anyone."

vs

"Here's a general purpose computer. Knock yourself out."

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#59
post #56

Earlier quoted context omitted.

> Humans organise and memorise things in hierarchies Big claim. Proof?

Big proofs. Conceptual categorization is a big part of how we humans comprehend and analyze the world around us, and it relies on a hierarchy of defining attributes, from abstract model to concrete specimen: https://en.wikipedia.org/wiki/Prototype_theory#Basic_level_c... https://en.wikipedia.org/wiki/Stereotype#Cognitive_functions https://en.wikipedia.org/wiki/Concept_learning Maybe less abstract: if you try to remem…

I actually wnt to believe you because it accords with my own intuition but I don't trust my intuition on this!

Conceptual categorisation + language + ? is totally how we humans comprehend and analyze the world around us, granted. (The devil is in the details of course.) But I don't see how we can go from there to "it relies on a hierarchy of defining attributes"

I don't buy your example because the concepts in our heads seem to be organised in context-specific word bags, i.e. tags.

I think I would believe you if cognitive science discovered that tree-hierarchy navigation relied on built-in neuro-spatial machinery or something like that :)

I _want_ to believe you but I also want proper proof! :)

edit: thanks for the heads up on prototype theory, can't believe I'd forgotten about this. also, thanks for making me ponder more deeply about stereotypes.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#60
post #13

Why not use file attributes and provide a nice interface for managing them? (e.g. extend find to search them, etc)? A parallel database is fragile -- it can trivially get out of synch.

I thought the same thing, but in practical terms you'd need to maintain a separate db for portability anyways I guess.
Post reply on HN