Slashdot Mirror
newdocms: Beyond the Hierarchical File System
Manuel Arriaga writes "After two years of hard work (and many scrapped versions), I have just released a (ugly, but working!) preview version of newdocms, a completely new document management system. newdocms isn't a file browser: it is a layer between the hierarchical file system (HFS) and the user, which provides a radically new way to store and retrieve documents. No longer will you browse complex directory trees or directly interact with the HFS; instead, you define any number of document attributes when saving a document and then query a database of those attributes when trying to retrieve it later on.
For the first time you have a true alternative to the hierarchical file system at the OS level. Through the modification of the KDE shared libraries, newdocms currently works with all KDE apps! (I am looking for volunteers to add support for GNOME and OpenOffice.org!) This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."
I'm already using The Brain. It's *really* unique, and it works. It works very well. And, in addition to organizing files the way YOU want them organized, it also connects random thoughts, web sites, emails, etc. If you haven't seen it, check it out. It's pretty damn incredible.
It sounds basically like when you want to find a file, you go type in a few pieces of meta-data, and then hit "search". It's a way to do it, but it seems to me (and it's early, so bear with me) that it's easier for me to remember one piece of meta-data (i.e. the path to the file) than several (as it would seem with this setup, as you would have to present more than one piece of data to differentiate between different documents, let's say, created by the same author on the same day). Maybe I'm just used to a HFS, but I find it simple to open up a command prompt and type "pico /documents/foo/bar/fubar.txt".
Anyway, an interesting concept.
Don't I remember reading something about the Blackcomb file system being database driven? Billg called the current file system a "cesspool" and said it's going to be completely overhauled, IIRC.
Oh well, in a few years the *n?x-philes will be screaming about M$ stealing their ideas. Figures.
What Microsoft suggested something like this, everyone went mental, and I got bitch slapped for saying I thought it was a good idea.
What's wrong with hierachical systems anyway?
;-)
Well, they're pretty darn hard to spell, for one thing.
- Not confusing enough.
- No possibility of new patents.
- Lack of ability to lock users into your proprietary file system.
I didn't know HFS was broken.NetInfo connection failed for server 127.0.0.1/local
I have worked with many a user that has had problems with the concept of folders (directories). Perhaps those users can grasp this concept easier.
sPh
Microsoft couldn't have come up with this idea: the submission explicitly states that it wouldn't be possible outside the free software model. QED.
While I do think the work presented is a great idea, it seems to me that it's a lot of effort just to setup the system.
It would be ideal if the computer -- the thing that is supposed to make life easier -- did the clasification. Until that happens I cannot see myself even considering such a file access method.
-- bartman
My father is really going to understand that. Not a bad idea but the implementation appears to need work. Another interesting thing to note is that this is probably coded in C++ and is going to be a bitch once again to interface with scripting libraries. I love KDE but it is a difficult task to integrate other languages with.
Got Code?
Exactly. Users STILL have to create their own type of organization.
/documents contains documents. Duh.
/documents/work contains documents for work.
The problem is people don't want to be organized, so they look to technology to help them be lazy. Plus try explaining 'metadata' to someone. At least now you can use the file cabinet, drawers, folders, papers example to explain the layout to someone.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
The answer is in the G:\archived\userFolders\shlemiel\appfiles\textdocs \myFavEditorFiles\compDocs\scratch\WhyHierarchical FSBad.txt file.
1. "Filesystem? I don't need no stinkin filesystem!" An ideal Palm-esque computing environment wouldn't have any filesystem. There simply isn't any reason for it. Why would you store addresses in an address file or a book report in a word file? Saving/Opening files should be transparent to the end user. Versioning should be built in, yet simple to understand. Forking files can be accomplished without copying a file. This is intuitively the simplist idea.
2. If you somehow *have* to think in terms of files, then your conclusion may be to use files. However, I don't see why anybody would come up with a hierachical file system, unless they were accomidating for hardware limitations. Placing files somewhere within a huge directory tree is just too darn complicated. Why should the same file not exist in multiple directories? Why should copies of a file exist? Everything, including advanced security policies (more advanced than what is currently possible) is available for a *keyword* driven filesystem.
I believe this is a step in the right direction and I can't wait until my favorite OS (not Linux) adopts a similar feature.
ting systems, not that the commercial developers couldn't do it with their own products. Clearly they could. Or are we now claiming that "innvation" belongs solely to the open source community now and not to commercial developers?
You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
"This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."
... or not. As I recall, BeOS had a fully functional database driven file systerm although it did not entirely through out the hierarchical side of things either (probably a good decision in my opinion). In fact, I recall reading a while back that future versions of Windows were supposed to have database driven file systems as well.
While free software is great, let's not get too cocky about what kind of innovations it can produce when we aren't aware of what the traditional software companies have already done.
Who came up with the idea of "folders" anyway? Not hierarchical trees, but the metaphor.
The biggest problem with folders is no one wants to be a file clerk and weed, sort, and file their docs. The act of socking away a doc should as mindless as possible, not because (all) users are mindless but because they have better things to do, and shouldn't spend a minute adding keywords to every doc they might never see again.
You know how it is -- you're searching and coming up with junk, and want to yell at the computer, do what I meant, not what I said! This would be one of my first pics for AI on a personal computer.
I agree folders doesn't cut it, though as a metaphor for explaining the tree it's not bad. The problem is the tree.
The Brain is an interface on top of your current FS. Things like this have been done going back to the days of the Leading Edge Word Processor (separate file to get around the 8.3 naming conventions).
I believe the point that this mad scientist was making was that he's completely replaced the FS with this new database-based one.
It's certainly not innovative, but it's something different I guess.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
I agree. Basically the only way this is different from your HFS is that it encapsulates the meta-data (that is currently in the path name) differently. I'm not sure that's any better or worse. In fact, I myself like to be able to see at a glance what all the categories of documents that I have are which is quite easy with HFS, but doesn't sound so easy here. Perhaps that's more because this is a new idea and not mature yet.
Everyone seems hot to SQL the file system, and while I think that will be the way of the future, I don't think that there is a clear view of how that works from the user's perspective yet. Remember that this is a rather large paradigm shift from what everyone is used to. It's going to take a while for this to mature to the point that Joe User is going to be able to hack it. I mean, I looked at the Save As dialog on that page, and while it looks cool it also looks counter-intuitive to me and I'm a developer! How much more will a user get confused?
All in all we're going in the right direction, but by no means are we anywhere near the goal yet.
Ben
Proprietary file formats are to blame. Imagine if every file format was similar to open office xml based documents. A background process could be indexing the documents and making available very powerful searching. Then add a natural expression engine on top to get the documents. "show me all documents that contain the word resume"
Got Code?
Who needs this? As one poster put it, isnt the path the only real piece of meta data you need to find a file? Think about mom and dad. What do they want to know? "Where are the christmas pictures of the baby from last year?" "What happened to that email I sent my brother last week?" "Where's the latest copy of my resume?" and so on. Natural language aside, these are all metadata-type queries (mostly dealing with time and filetype data, both of which can be extracted without any additional effort by the user). I think that if such a system of searching files is ever perfected, we'd have a serious killer app on our hands. Isn't this part of what the "semantic web" is all about? Isn't it frustrating to everybody that even the best search engine in the world still can't understand "find me all books whose author is mark twain"? It seems like a logical progression to expect that. Just like most of us aren't searching the web for *pages*, but rather particular *informatin* on those pages, I think that Joe User doesn't care about looking for *files*, but rather the information contained in those files. Thus it's only reasonable that if you give a user a way of easily describing those files by something more than just a filepath, that it will then be easier to find the information later.
www.HearMySoulSpeak.com
or something very much like it a few years ago.
i used it and it works like a charm.
of course hierarchical file systems are easy to use, you can name folders after categories, and they are easy to backup.
Interfacer.
all your HFS are belong to us.
But thankfully, it's an article about file systems.
Stop corporate
Exactly. In fact, these hierarchies do not make sense to anyone, encountering them for the first time. There's nothing user friendly about them at all, really. They aren't even alphabetically sorted, which is the least you usually expect from a file cabinet. It's just the simplest way of doing things and it seems logical to you, because you haven't worked with any other kind of file system since you're first computer experience. Admittedly, a keyword driven system would not give you a shorter syntax. But administering a system using thousands of levels of subdirectories would not do that, either. Imagine a database driven file system, combined with near-perfect speech-recognition software. Suddenly the additional keywords required do not matter so much, and the advantages of a system like this could really become obvious.
Sounds a lot like BFS.
If memory serves me correctly, the BeOS team was originally trying to do a pure database filesystem (no hierarchy), but found (in the early '90s) that the performance hit was too heavy on the hardware of the time.
The whole desktop/file/filesystems may indeed be ripe for a new metaphor to help conceptualise them. When computers were the principal domain of workers, the idea of a desktop with files and folders allowed them to grasp alien concepts.
But computers are becoming ubiquitous, pervasive. Perhaps a new metaphor could be found. An example could be objects in rooms. Think of different folders as different rooms - all files (or rather, all streams) are objects in those rooms. Navigation between rooms is possible through doors.
Of course, as others have pointed out, the HFS ain't broken, so why fix it? (Answer: why not? PC cases aren't broken, but we still have case-modders, don't we?)
you mean osX doesn't have this "feature" yet? even microsoft has the broken search feature...
really, files, documents, directories, folders, whatever you want to call them you're saving a unit of work for later retrieval. this concept adds extra LAYERS to that save and retrieval process (keywords, and categories). and even the categories resemble folders/directories a LOT. so in effect, this merely adds meta-tags to the document header and allows searching on meta-tags across folders.
file versioning is a nice feature that i really liked in VMS, but you learn to be more carefull in other systems that don't have that built in. instead of letting the OS automatically create backups, you do it yourself when it's needed.
That was done pre-UNIX with PICK. The whole O/S was a database.
Microsoft has been working on an Object File System for years and it is rumored that it might finaly ship in Yukon.
A database baked file system is a great idea for an O/S. But the relational model is long overdue for the garbage pail. Modern programming languages since C have used pointers or object references. If JOIN and messing arround with tables is so good why don't we all use COBOL?
One of the things that appeared in VMS a while back that was pretty cool (and pretty easy to do on a log based file system) was transactions at the file level. You could take any set of file I/O operations and wrap a transaction arround them. This meant that you could have atomic updates to any file base resource without having to suffer the pain of SQL.
It would be pretty easy to implement this on a Linux log based file system (or windows for that matter). All you do is extend the log structure so you can group operations together and implement some sort of commit flag.
You could then build an object oriented filestore database using XML flat files. OK so maybe the system is not going to be up to storing millions of records without more infrsastructure. However most programming tasks use configuration files that are unlikely to be more than a few tens of Kb and are routinely managed as in memory structures anyway.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
It seems to me that the majority of people who reply with "I use HFS just fine, file-> save as -> my documents works just fine" are also the type of people who don't actually create more than a few documents anyway.
I write a lot of documents and my filing system becomes ever more difficult to manage, without the skills that a librarian or filing secretary has I find that my documents become harder to locate over time. To me this is a potential solution to that problem, I do however appreciate that "Joe Bloggs" will not understand what it is about, but as far as I am concerned "Joe Bloggs" should not be using computers in the first place. Pandering to his ilk has set computing back 10 years.
The potential pitfall of this system could be where many documents have been written about the same subject i.e. testresult001.txt to testresult999.txt. The user would know with the traditional system that he wants testresult823.txt but with the new system would be presented with 1000 choices. I am possibly being myopic here!
Perhaps it is time for a new paradigm and I for one will be looking at this method with great interest.
Sounds like Microsoft Sharepoint to me. Sorry, but that doesn't excite me too much...
If so, and based on the bad Sharepoint implementations I have seen, this seems unlikely to be world-shaking. How about a follow-up article on this in a year?
- -
Are you an SF Fan? Are you a Tru-Fan?
This is exactly what I have been wanting for almost a decade now.
..etc as well as those that are simply wallpapers and photos). More importantly, if you see a good bump texture for a certain surface, describe it as such without changing the filename.
Some uses I imagine
- Create music playlists on the fly (MoodLogic doesn't count)
- Categorize work files (Across the whole partition, find images that serves as bumps, HDRI
- Install Windows and service packs first, mark files as "windows native". Then install apps. Some OS glitch, you need to reinstall ? Backup all files with directory structure which don't have "windows native" tag alongwith c:\program files and registry. Reinstall windows, restore the backed up files. Voila, no app installations required.
I have used "The Brain" while I was in Windows, but it was nearly useless as it didn't support the two most important things:
.docs or .xls.
a) Web browsing
it should now the sites you've visited, know your bookmarks and allow you to open everything you have found with a simple click.
b) E-Mail.
When it finds an E-Mail a simple double-click should be enough to open it in your mail, show you the thread it belongs to, etc.
I guess, that I'm not the only one, who has more important things in mails than in
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
I was reading about Reiser4 last weekend and HR mentioned similar functionality IIRC. I would hope everyone can sees the point behind metadata...it's kinda the reason XML is considered a GOOD THING. The question is...can we shift our paradigms to use this newer model? Change is hard to effect...this would have to be adopted be a mainstream OS for this to really catch on and be widely used. (Asbestos uunderwear on!) Isn't Longhorn's new DB filesystem also supposed to offer some or aLL of this? (RTFA if you want to reply please!) MS might not be as behind the curve as we'd like to think....time will tell if this will actually be widely accepted. My .02.
Always value the individual over the system. --Bruce Lee "I don't need a Sig - I have a custom 191" - me
of the difference in the GUI vs. command line mind set.
These abstraction layers have been used before on OSes such as MAC OS and OS/2. The problems always came into play when you pass the files around. There is always a step that strips the extended information. The key is wide acceptance and establish a standard for the data storage. Be sure there is a way to pass the extended data in a text format (i.e. XML) when you want to store the files on a non-supported system (or so command line tools can be easily modified to update the db).
The idea is good and I am sure it will be very useful to a lot of people. Good Luck.
1. Paths tend to get long.
2. You have to be careful of your "current path". Some apps have weird defaults and if you're not careful, you end up with your file in a strange location.
3. Some items do not fit into the hierarchical structure. Should my porn directory be organized into movies, stills and texts or perhaps perverted, spicy and nice? Whichever atrribute I choose I will have trouble searching on the other.
Of course I can always use locate or find, but these tools only look at preset attributes (filename, last access date, substrings) and the solution from the article lets you specify your own attributes.
Personally, I do not think computers need to move towards making things yet easier for the user (instead people need to get a clue!). I do see how this might save some in support costs, but the end result will be dumber users, who now still can't find things, just for different reasons.
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)
this sort of innovation could never happen if it weren't for the free software nature of the underlying systems
Surely this is an overstatement. I think what you mean is that a guy off the street couldn't add this file navigation scheme to an existing commercial OS, not that the commercial developers themselves couldn't do it. Or are we now suggesting that the open software movement is the sole owner of the term "innovation"?
You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
So where do your documents go when you save them with newdocms? As you might have noticed (if you looked at the window titles after saving something), they are stored as ~/Docs/{numeric id}.{ext}.7 All the metadata is stored in a file called ~/newdocms.db. (It is not wise to delete it!) In that file each document's attributes are associated with its unique numeric id (the one which is used as a file name).
Right.
This is astoundingly bad software engineering.
Manuel, when your software fails, and it will, and somehow that db file gets trashed you've rendered that users' files as a huge heap of unsorted data. Effectively it would be 100 times worse than never implementing your system than 10 times better. No matter how bulletproof you think your code is, it probably isn't 100% perfect so having all your eggs in one basket is unwise to say the least.
Even if your code is 100% perfect this is a mistake. What happens when a sector goes bad and this file is trashed? What happens when the first really dangerous linux worm makes it a point to delete *.db from the filesystem?
Give the files names that are coded with human readable attribs! Double up that db file! Jesus, man... build SOME kind of redundancy in your system before you throw away the old way of storing the data.
There's a reason why there is such a scramble to implement a general attribute system at the FS level on many FS projects right now(*). The time has come for OSS to start being smart about this, but cramming all your metadata into a single file and throwing the backup out the window is just a very, very poor idea.
(*) BeOS was, yet again, way ahead of it's time with BeFS.
This looks a lot like something I've used in the past - FileNET Content Management Services. FileNET lets you create meta-data for each document you save, as well as a complete version history and check-in/check-out for each document if you want to. It also allows for hierarchical storage of files as well as using the meta-data so you can still categorize things by folder if you want, but still query documents by any of the indexes that you have built. It will even add a full-text search across everything in the library if you want, and it has no problems indexing most standard formats including Word and PDF files.
i dunno, the start button is, after all, mainly a shortcut to the "Program Files" folder of your heirarchy...it makes it very easy to go "Start=>Programs" and now you're browsing in the "Program Files" folder just as if you'd gone into the file system...as long as most programs install here, it makes it pretty easy to run the program you're looking for...
"On the Mac, I was used to double-clicking the hard drive, then navigating through the directories to the application I wanted to use, and launching it from there"
plus, it's not like they took that option away...no one has stopped you from double-clicking on "My Computer" and navigating into any of the hard drives...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
Microsoft Sharepoint also allow you to store your own metadata with files - and also grab the "properties" from office files. This is not to substitute the folder tree, but in addition to it, and it's indeed a great tool (aimed more at the corporation than the individual)
:-P
But it's MS and here I am burning karma for just mentioning it. Big deal, I can spare the karma
The AS/400 and its predecessors have had a database oriented file sysem for centuries (in Moore-law years).
I find it a nuicance from a programmer's point of view, and indeed it can get quite messy when you have about 100 different Libraries on your 400, each with a few dozen Objects, some of them with another few hundred members etc etc. From the point of view of the application, and the end user (who will typically have only a single version of a few applications installed on his dedicated database server), it is the greatest thing since sliced silicon.
I think it predates the hierarchical filesystem by a lifetime as well (again in Moore's law years).
The system I have been dreaming of for a while would be far more graphical (had a quick look at thebrain.com, it's still text with a few lines as far as I can see).
My dream system would enable you to specify file attributes such as size, path(s), name, type etc, as well as regex greps on the content, and then plot the filing system in 3D space, through which you could move with a joystick. You would be able to assign attributes to graphical features, eg make scripts cuboid, text files spherical, bigger files bigger on a logarithmic scale and so on. Related files would appear like solar systems, and by changing the importance of the file attributes you could change the way the files grouped.
Probably not what you'd want to use every day, but I'm sure I'd find a few mislaid files with such a system.
Virtually serving coffee
If you try to forget everything that you know about computers, and then abstractly think about what a filesystem should be you come to one of the following two conclusions:
Let's see. If I want to retrieve a document that's been filed I go to the bank of file cabinets, select the cabinet that has the drawer I want, open the drawer, scan folders, pull envelope from correct one, extract document.
Cabinet/drawer/folder/envelope/document
Maybe it's because there really is an analog in meatspace for the heirarchical file system.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
Hierarchical file systems are as close to intuitive as you get. Everything you do in the real world, as pertains to dealing with information, mimics a hierarchical file system. Your chilton manuals are in the garage, your cookbooks and recipe boxes are in the kitchen or dining room, your computer books are by your computer. You don't look in the computer manual for how to change your oil. When you are trying to bake a cake, you don't walk out into the garage for inspiration. Having information organized into different places, and then having those places subdivided into different boxes is intuitive, and is how most organized people think.
v able\Yesterday\Tomorrow\A WeekAgoToday might be confusing, but the filesystem paradigm isn't.
1. (a) "We don't need no stinking filesystem." The ideal palmesque OS would have the same idea just demonstrated differently. You aren't going to open up your notepad to see an address. The address file is in the address program (directory). The schedule file is in the calendar program(directory). The programs you use to open the files become your folders.
1. (b) "Saving/Opening files should be transparent" The only people that would think like this in the real world have been living with someone that picks up after them all the time. When you are working on some (paper and pencil) project, and just stand up and walk away, do you exepect it to be available at the office tomorrow? When you start working on several projects in succession on your desk, and have reams of loose paper, can you easily bore your way back down. No, reasonable, organized people pick up the porject they are working on, file it away in the file cabinet/brief case/wherever it is supposed to go. There are logical beginnings and endings to your working on a project that only you can decide on. A spreadsheet, for example, do you want it to save every time you make a change... No, by their design, you would normally set up all your formulas, save that, and then every day/month/year open up the spreadsheet, plug the numbers, get the results, and save the specific results to a different file, or just look at the values produced. Not to mention, when you sit down at your desk in the morning, do you expect your desktop to know what project you want to work on? No, and you don't expect your computer to know what project you are working on either. Opening/Saving files shouldn't be and can't be transparent to the user.
I used to use a lot of floppies when growing up. I appropriated a lot of disks from other places. I used the "grab the black disk with the couple of remnant label pieces... no the other black disk... No, the one with the two small pieces of adhesive... Ooops, the one with the three pieces..." Now, I have to search all the disks everytime I want anything off of them, because I never labeled them. Saving things in well defined locations, for well defined tasks is reasonable, intuitive, and necesary task to saddle a user of any system/technology/information with.
2. I don't really need to address this point specifically, since the answer is inherent in the points above. The overly large filesystems are part of a whole system that the user doesn't really need to know about. That is why the "Desktop/..." paradigm of Windows came about, and is so useful. People working on your word processor have a reason to put the font files in one directory, the plugins in another, and the preferences in a third. The user couldn't care less. If you start the user in a directory tree just for them, then they won't be stuck in a huge file system, and can still work in a fashion that has made sense for litteraly thousands of years.
The filesystem paradigm has been around for a long time, again litterally thousands of years, because it works, it is easy, and it is how people think.
G:\Netowkrfilesystem\
Accounting\AccountsRecie
I believe metadata is a useful additional means to find files, however I would still want heirarchy as the primary storage. For most people the only metadata they ever consider is the name of a file, and this is often poorly named. I applaud the effort of the person who is doing this project though.
-- Solaris Central - http://w
What is the deal with people wanting EVERYTHING in a SQL/LDAP style databse! Every intern I have to manage out of college seems to have been brainwashed to think that whatever the app, it's data should be in a relational database.
I like datbases, but for somethings they should not be used!
When it comes to the OS, I want to be able to text process data EASILY...with BASH! This road leads to things like binary configuration files and that leads to things like the Microsoft registry which I detest.
Databasizing everything (including the filesystem) IS NOT THE ANSWER
Should my porn directory be organized into movies, stills and texts or perhaps perverted, spicy and nice? Whichever atrribute I choose I will have trouble searching on the other.
Errr, symlinks anyone, they fit in any number of categories. In fact it would be simple to create a file saving/organizing app that would automatically set up HFS links based on attributes that you define.
Of course I will try this new filesystem. I'll always try out anything new, but I do have some preliminary reservations. I'm happy with HFS, but I'm a coder. My linux desktop is 99% command line driven, I use ratpoison as my wm, so it may not work for me, but I certainly won't bash something that might work for others.
Use the right tool for the right job
I'm the big fish in the big pond bitch.
Should my porn directory be organized into movies, stills and texts or perhaps perverted, spicy and nice? Whichever atrribute I choose I will have trouble searching on the other.
How about store the files alphabeticaly, by model name? Install PostgreSQL/PHP and assign key words. Use drop down menus (breast size, hair color, action, file type (image, movie, etc.) etc.) to only bring up what you're looking for. It seems that this is what this guy's doing, only for KDE save/open.
I drank what? -- Socrates
I have recently become very annoyed with the way I am storing information. I've realised that I have four parallel, similar, yet completely independent methods for cataloguing information. One is the file system - directories containing documents, images, etc on various subjects. The second is the Favourites list in my web browser, containing links to web sites on various subjects. The third is my email contact list, containing groups of contacts in various categories. The fourth is my mailbox hierarchy, containing archives of emails on various subjects.
What I realy need isn't a way to help store one category of information, but a single unified way to store all related information together, by subject. All my documents, emails, web links and addresses relevent to a particular customer, for example.
I don't realy need a search tool (although they're always a nice function to have), I need a way to keep everything together and easily accessible.
Simon Hibbs
I've noticed about three main types of people in the world of open source: those who fix things, those who try to improve existings things (i.e., make it run faster, smaller, etc.) and those who like to tinker and make new stuff. This person seems to fit in the third category. As far as I can tell, this person is not so much trying to "fix" the file system, but to make a new and different version and/or approach to it. This may be a good thing. But if you don't like it, don't use it.
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
That Amazon doesn't have a patent on this?
Funnies aside, I'll bet you half a bunch of grapes that there's at least one patent on something that arguable descibes this, just waiting for someone to implement it so that they can sick the lawyers on them. Them being you. I hope not, but I really wouldn't be surprised.
If you were blocking sigs, you wouldn't have to read this.
Isn't this what stuff like Active Directory are for? Why can't I create one hierarchy that represents the actual storage structure, then map an infinite number of additional heirarchies on top of that based on metadata, e.g. as if I were to use softlinks to create additional heirarchies based on a different attribute than what I originally sorted on.
/pr0n/movies /pr0n/stills /pr0n/text [do people download pr0n text???]
/pr0n/perverted /pr0n/spicy /pr0n/nice
In a manner of speaking, I could store my pr0n as:
and then create another organizational structure of "links" as
I still have the option of layering movies, stills, and text under the perverted, spicy, and nice categories as well.
Shared-library hacks are not "the OS level" even if you're talking about libc, and even less so for something KDE-specific.
Wrong again. At least five years ago I was using a Windows shell extension that let me attach metadata to files and search by metadata. I don't remember the name off the top of my head, but it was similar to Explorer Notes or FileNotes or Annotater. Sure, those only work in Explorer, but that's no worse than only working in KDE. Far from being a "free-software innovation" this is something that's been kicking around for ages in the non-free world and the free-software version is (as usual) pretty late on the scene.
Slashdot - News for Herds. Stuff that Splatters.
I sure hope they don't try to emulate the completely broken way Palm handles file management. By dumping any sort of file management from the OS, they left all of the work on the application developers to manage files. Every application works differently and there are all sorts of unintended consequences that arise. Like removing one of your two ebook readers also deletes all of your ebooks(!!!). Also, it is frequntly not possible to beam just a document (or in do anything with a document for that matter) if the application doesn't support it. That's why Beambox was written, but the flat nature of the file system makes it a pain to use.
My biggest concern with this new system is that if you fail to generate good keywords (I suspect this will be a big problem) it is going to be hard to browse through a likely directory to find the file. It is also going to be a bit more difficult to do housecleaning (usually I notice that some forgotten directory won't be needed anymore and delete it, but with this system you should never see files you aren't specifically looking for). It seems to me that this system is going to be a bit less tolerant of poor organization, which could prove to be a headache for real users.
I read the internet for the articles.
My god. Our users are so dumb they can barely remember the name they gave a file 10 minutes ago, and now you want them to think in terms of "concepts," "terms," and "shortcuts"? This will confuse them sooo much it isn't even funny.
unique: Being the only one of its kind.
*really* unique: c.f. redundancy
If you were blocking sigs, you wouldn't have to read this.
I certainly have to agree with you. When I first started using Linux it was a move from Windows 3.11 (though 95 may have been out at the time I don't remember) so it was a bigger culture shock for me. Even something as simple as /usr/bin vs. /usr/local/bin or /usr/local/anything seemed such a simple but great way of doing things to me. If I needed to back up I could easily isolate what I had put on the machine post installation. Everything else would be built by the distro disk. Contrast this with Windows where everything seems to go wherever; thought it is possible to do the same thing, and I started doing so at the time, Windows has never been as conducive to that sort of habit as *nixes.
I'm the big fish in the big pond bitch.
A zillion years ago there was a concept called the 'Xanadu file system' which, if I am recalling correctly, was very similar to what the author has actually implemented. I did a quick google and found one tangential reference to it for those interested in late 1980s/early 1990s history
http://tgif.fremont.ca.us/~mfw/diss/node39.html
That the author has produced working code is a HUGE INNOVATION. That this innovation has been produced by one person with a personal itch to be scratched is the reason that free/open software works so well.
This sort of improvement in the user interface is what will allow Linux/BSD derivatives to drive right over the top of certain proprietary systems in common use today.
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
What's wrong with HFS? 1) Not optimized for catagorical querying of stored objects which can render views which are far more useful than a standard HFS. This is its primary use. 2) Distance between any two leaves is arbitrarily large and can be quite large (requires you to make sacrifices as to the categorization of your files vs. relative distance between common files or create a myriad of symlinks which is basically what a catagorization system does inherently) 3) Whats hard about setting categories: attribute: movie attribute: porn attribute: Jenna Jameson whooo, hard. And these file attributes eventually can very easily be represented across the web in saved downloads. 4) Is this not open source? patents? give me a break.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
plan9 could do all you are asking. It uses 9p a protocol for file access, the file server responds to requests for files as can user level processes.
You could bundle all the meta data you like into your user level file server process and present the data in whatever format you like.
It's really no big deal
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The idea was that Microsoft discouraged navigating your HD as much as possible. Especially from the command line, but even the Program Files directory comes up by default with a "You shouldn't be here, click here to break your system" type message. The problem is that the folder names in "Program Files" and the names on the Start menu often don't match, and neither of them are the name of the application you originally installed. Half of the time it's something like Program Files\Big Long Name Soft\Project Wordiness\Your Application's Directory\YourApplication.exe which is stored in the start menu as Project Wordiness\YourApplication.exe or some such. WinXP makes this even more interesting with it's "you really shouln't leave the start menu" mentality.
I read the internet for the articles.
Xanadu just became reality!
668: Neighbour of the Beast
Modern programming languages since C have used pointers or object references.
inodes & symlinks
If JOIN and messing arround with tables is so good why don't we all use COBOL?
we use other turing complete languages instead
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
"it is a layer between the hierarchical file system (HFS) and the user, which provides a radically new way to store and retrieve documents"
The only things that are radically new is that a) it is open source b) it is aimed at individuals.
Commercial EDMS (Electronic Document Management Systems) vendors have been doing this for years - companies like Documentum and Filenet. Like newdocms, they combine the filesystem and a database of attributes for file storage and retrieveal. Documentum itself has gotten very sophisticated; it can read the text of the document and, using an XML taxononmy of your choice, auto-file the document in the appropriate place. Likewise searches can be performed on both user-supplied attributes, computer-generated taxonomic values, or the text of the document itself. Companies like pharmaceutical manufacturers, with millions of complex documents, simply couldn't function without it. And it works with multimedia files as well, actually reading the close-captioning on movie clips to perform it's auto-tagging and auto-filing operations.
That said, it is a great accomplishment, and a welcome addition to this KDE user. While I have worked with EDMS systems off and on for the past 5 years, I could never actually afford one myself, and none of the current EDMS vendors that I'm aware of support Linux.
As work begins on version 1.1, I suggest taking a look at the features available with the commercial EDMS products for ideas - especially for things they haven't thought of!
Good work!
Actually I would LOVE to have everything accessable in a database somehow. I've been wondering about something using the userfs stuff. Not really mounting a mysql database as a usermode filesystem but having information from the system available that way.
I've found myself many times wishing I could just type "select location,filename from datastore where contents like %resume%"
SQL comes much more naturally to me than the find command does. I would love an easier way to index the contents of everyfile on my system by an arbitrary number of metadata and then have that accessable via a simple sql statement.
I remember Scott Hacker did something similar with BeFS and his webserver at somepoint but he's long gone as is BeOS.
Am I the only one that this makes sense to?
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
The xmas issue of new scientist had an article about some research on office desk layouts. The messy desks were more efficient than the clean desks as the user knew where things were. The tidy workers who always filed everything (or were forced to by policy) spent a lot of time looking for documents.
:-)
This is "of course" why you can drag&drop docs onto your "desktop". So why shouldn't there be a proper implementation of a messy filesystem
checking for Qt... configure: error: Qt (>= Qt 3.1 (20021021)) (library qt-mt) not found.
It needs a Qt from October(?) apparently. A stock RH8 (Qt3.0.5) isn't good enough, even though his (limited) docs indicate that you just need KDE3.x (except he then recommends 3.1pr5 !).
creation science book
Gosh, are you telling me I have to think up keyword and the like? Smells like work to me.
/. article about this some months ago), and the user could really be confused! It might be neat to have the system automatically find neighborhoods of documents (by content matching and by time).
Wouldn't it be great if this overpower POS (piece of silicon) could catagorize the document itself? It would not really need "natural language" ability; just steal (er, borrow) ideas from web search engines and have a thesaurus handy.
Combine this with the idea that the "save" button is outdated (there was a
The real silver bullet to good programs is caffeine; lots and lots of caffeine! *twitch, twitch*
The PICK OS was released in 1973. This means it postdates Unix. It did inherit ideas which were originally used in GIRLS, which dates from 1965, but that was a simple application on the IBM/360. If you want to argue that that means PICK dates from 1965, then Unix dates from 1959, with the start of the Multics program.
But this doesn't sound new to me. Am I the only person who thinks this guy is building a file system search engine?
Seriously, what user is going type "Ok, it's about dogs, and dalmations in particular, also pet care and grooming and diet and exercise and training..." for every file he creates? No way.
More likely:
find . -type f | xargs egrep -i "dalmation"
Of course that won't work on binary formats, but guess what could? A more intelligent search engine. Hey, I think there are a few of those available!
-FF
SQUEAK, the Death of Rats explained.
I like this guys enthusiasm for open source.
I have questions though about the users ability to apply meaning attributes to the numerous amounts of content. If the user fails to provide meaningfull attributes the system fails to provide the user with meaningful results. In which case I would judge this system to less user-friendly because the files would be returned in a 1 big lump.
This idea stricks me as an implementation of something similar to the Dublin Core Metadata Initiative except for local content. Wouldn't this project benefit from enabling the user to manage ALL types of information, even remote. It wouldn't be a large stretch of the imagination to take that step.
If anybody is interested how the Dublin Core works in application you might want to check out the Zope CMF(Content Management Framework).
My experience from using Zope's CMF is that the initial learning process of a user using this method of organiztion was slow and bumpy. Although I must point out that my experience with the system was only with using a single implementation, so I'm not making the assertion that an implementation couldn't be designed that could improve the learning curve for users.
I would also like to point out to the people that have said this would ruin Linux that they don't understand exactly what this tool does. Its a means of effeciently catalogging and managing content. Any use of the tool does not restrict the user to that tool alone; it can be used in conjunction with the traditional HFS. The author even says so in the article.
...the contents of the file itself. Anything else is extra. Nice to have, but extra.
You want to find last quarters financial data and can't remember where you put it? OK, search for something that would be in that file ("Nov 2002"), and of file type X(whatever you use for a spreadsheet)
HFS or file descriptor info adds to this searching, but if you can't remember where you put it....search the text.
Doesn't work with binaries or images, but you get the idea.
Well, yes. On a computer, I would expect it to available tomorrow *exactly* the way i left it. The only reason that I don't expect this in the real world is because it's not a feasible possibility. If it were, then I would expect it to be as I left it in the real world, too.
You commented: "My biggest concern with this new system is that if you fail to generate good keywords (I suspect this will be a big problem) it is going to be hard to browse through a likely directory to find the file."
Although I will admit that current searching technologies are not very good at determining what I actually want (e.g. misspellings, synonyms), I will say that I don't think that choosing keywords would be a problem. I believe that choosing which directory to place the file in is a more complicated problem, because you can only pick one place (without worrying about shortcuts or links). Many of the searchable keywords would be generated from the document itself: last-edited-today, various project keywords, application-based (e.g. excel-spreadsheet, letter), keywords based upon the content. Ultimately, I believe this system would be *more* tolerant of poor organization, rather than less as you state. I believe that people would adapt to it and learn to use good keywords easier than they did for hierachical filesystems. I will admit, however, that it is a flaw *whenever* people have to adapt to something, and most have alread adapted to the idea of a hierachical filesystem.
You also mention that the PalmOS filesystem implements such a filesystem poorly, but please don't crush the idea based upon one implementation. I see NO reason that application developers would have to worry about implementing a keyword filesystem any more than they would hierachical filesystem. It sounds like Palm's version isn't mature enough to be useful.
The industry is working to remove the hierachical filesystem. It's only a matter of time. Look at WindowsXP Tablet edition's note-taking program. You basically have one *file* for all of your notes... ever. You can subdivide and categorize these notes, but it's all one file.
While HFS has a number of drawbacks, it seems better to change or replace the FS instead of abstract its failures.
We still have to deal with file systems on some level. What happens to your abstracted layer when you want to copy something to a disk or burn a CD? You can't perform a file copy without breaking the abstraction, so the abstraction is broken before you begin to use it.
When you insert a Drivers CD in Windows, it may auto-run, sheilding you from the (often arcane) filing of the drivers. But unless there is an agreed format for the meta-data, your computer may not understand what is on the disc.
The system he proposes also breaks down on anything that is not new and made by the user. Document storage. Do we then only abstract the Documents folder?
While document management is a good idea, it needs to be subtle. It may take a user some time to learn the system, but that is better than crippling it to ensure first-time user ease. Macs used to come with several Tutorials on how to use the mouse and interact with the OS. We will probably need tutorials of that type again, soon.
Document management needs to spend very little time taking the user away from work. It must be integrated with the file system to work adequately, or the "switching" people will have to do to move from managed to unmanaged filing will aggravate and confuse them.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
...is something like a cross between a meta-data based document repository (like this or like The Brain), with automatic-mirroring capability for websites - or at least something that can be integrated into a weblog. I like to store interesting links and articles I encounter daily and be able to search them later. However, as we all know, what a link points to today, may be gone tomorrow, so that article you want to reference or remember might have *poof*ed out of existence. Right now this involves me manually mirroring every weblog post with 'wget' which is decidedly non-optimal and provides very little as far as searching and crossreferencing (which would be the real win: "what other articles do I have that relate to this article"). I'm sure it would be easy to hack together something for this specific case (cookies are a problem though), but I would hope there could be a general solution.
It's 10 PM. Do you know if you're un-American?
watch closelly, or even participate, on this project. might be useful.
What ? Me, worry ?
Here's something that is not stressed enough in school: the HFS is a database, with the fully qualified path name as unique ID and basic operations of update, delete, record lock, and retrieve supported across most operating systems.
Other query operations are supported such as wildcard characters and, in large OSes other than Unix, a variety of other attribute queries (a la "/usr/bin/find" but accessible from "ls").
Now the file table itself is a database, which can be readily implemented using a relational database. Microsoft NT an other OSes have had such support for quite a while now.
I'm glad to see the full relational database FS model starting to hit the mainstream. By this time researchers are looking into XML based File Systems (store metadata in XML-like syntax, support any XML query on the files).
Which brings us back to an often overlooked fact. Linux has, in general, not been at the leading edge of OS research (with the possible exception of the beowulf architecture). This is alright as for many years the goal of Linux was to reimplement Unix on the intel x386 architecture. However we must keep in mind that the really advanced OS features out there have yet to make it into Linux, things such as new environment metaphors, persistent data support, and intelligent user interactions.
For exampe, with music. Music comes on CDs, organized by Artist, then Album, then Track. So I have /music/Tool/Undertow on my filesystem. This works, but it's still somewhat lacking. I would like my Tool albums also categorized into the categories "Metal" and also "Kinda Weird". Obviously, with HFS I can't put Tool into two different categories(I've tried this with symlinks, it's not so fun...).
That way, if I wanted to listen to random metal, or random weird shit, I could enter a query, and could get results for a bunch of good stuff to listen to. OTOH, if I know I want to listen to a particular song, or album, or artist, I would still have my HFS.
In other terms, think of the real world. EVERYTHING in the real world has an actual physical location, so should everything on your computer. That's why, in the real world we have catelogs, indexes, etc. for finding the real physical locations of our stuff.
I think what would be really, really excellent would be if all files on a filesystem could have meta-data. Then file selectors could have an extra query field, then you could go to either your root(/) or your music folder(/music), then enter some queries, and everything under the current folder matching those queries could be displayed in the fileselector.
That, IMO, is the optimal way of doing things.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I've noticed about three main types of people in the world of open source
:)
Unfortunately you overlook the fourth and largest group -- those who COMPLAIN about everything and do nothing.
First all, I agree that this is a great idea to supplement HFS storage of documents. Documents will often fit into more than one category, so users have to choose one, and then do multiple searches to find it later. (Should I file a review for an employee under his name, reviews, and year, or year, reviews, and name, or reviews, name, and year??)
If users don't use thoughtful, meaningful, and clear directory structures and file names now, what possible argument can be given that they will use anything else in a thoughtfull, meaningful, and clear way? I get enough calls from users that can't even remember where they saved documents or what they named them (or why I should know) to make me doubt their ability to utilize such a toolset.
The ability to store keywords in a document and search by them have been in word processing programs for years. Those that are organized will take new tools such as newdocms and use them to the greatest advantage and receive the most benefit. Those that are not organized will only be further confused as they continue to save Document1.doc, Document2.doc, etc. with even more meaningless keywords such as 'expense report' or 'boobie picture'.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Yep, that's what IPTC fields, and a misc directory, are for. Throw something like this into grep, and grep those fields based on the file's magic number. Of course, that assumes that someone didn't already add that type of function to grep :)
Oh, here's a caption indexing program. You should be using your IPTC fields when creating your images (Whoops, that would be self-organization), and this program will create an index based on your captions. Grep that! :P
I'm sorry, but all these tools already exist. A new filesystem isn't necessary. IPTC fields are huge, and wouldn't really work with this new os-level filesystem. If you're looking for pictures, you query the IPTC fields. If you're looking for an email, you should use a proper subject.
Again, it's just people looking for an easy way out of organizing.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
Windows XP has most of the groundwork for this - Windows has actually had it for a while; for some reason the last piece (the filesystem that lets you take advantage of it all) keeps not showing up.
You want metadata on files? NTFS streams give you a place to store metadata (much like Mac resource forks but with any number of named streams).
You want to search on the metadata? The Microsoft Indexing Server will build a database and let you search on it (though it's a very strange system to use - in XP go into Administrative Tools, Computer Management, Services and Applications, Indexing Service, System and click on "Query the Catalog". You can do instant searches for all kinds of stuff, look at the help.
OLE Structured Storage is like a single file version of the filesystem we're talking about - a way of saving a bunch of objects (some of which you didn't create but that are in your document) into a file. I believe Microsoft's Office apps use it (could be wrong there though).
Right-click on an MP3 file and pick Properties in XP and go to the Summary tab. There's the metadata - the stuff the index server is going to index. If you add a new file format to the system, you can supply a DLL that will be able to supply the metadata for those files - so you download an MP3, save it on your disk, and the index server uses the DLL to get the metadata and add it to the database. It works pretty well.
I don't really have a point to all this, just listing some stuff that Windows has that "should" make it easy for Microsoft to add the OO FS someday and have it instantly work with existing apps.
- Steve
INFORMATION CAN EXIST IN MULTIPLE PLACES, realword stuff can't.
Even the data representation of a file, can only be written in one place on a harddrive. A file should represent information rather than some physical collection of bits on a platter. The OS (not the application), should handle the abstraction of taking the bits on the platter and representing it as information.
"Filesystem? I don't need no stinkin filesystem!"
No matter what the layer above should look like, it is nice to have a filesystem below. You can do stuff like making backup copies. Take a copy of the files belonging to one particular application. Move files. Fix problems when something goes wrong.
Forking files can be accomplished without copying a file.
Versioning should not conceptually be built into a filesystem. I find it far too complicated. A filesystem should be conceptually as simple as possible (but no simpler).
However, I don't see why anybody would come up with a hierachical file system, unless they were accomidating for hardware limitations.
I don't get it. Back in DOS 1.x a flat filesystem was being used. In DOS 2.x this was extended into a hierarchical filesystem. That was not due to any kind of hardware limitations, in fact the growing media sizes was probably one of the reasons to want a way to organize data. In fact the hierarchical filesystem was one of the most important improvements in DOS 2.x, the fact that it was implemented in a clumsy way was certainly not due to a bad idea, but rather because that way it could be slightly more backward compatible. That this clumsy directory implementation was allowed to exist all the way until W95 just proves a certain companys incompetence, other systems has had far better hierarchical filesystems.
Placing files somewhere within a huge directory tree is just too darn complicated.
The hierarchical filesystems were introduced to make things simpler. And it certainly did. Some applications implement some complicated stuff on top of that, but that is certainly not due to the hierarchical filesystems.
Why should the same file not exist in multiple directories?
In most of the hierarchical filesystems I know a file can actually exist in multiple directories. In fact FAT happens to be the only filesystem I know without that feature.
Why should copies of a file exist?
For backups, or simply because you want to work on a copy rather than the original. Then again I'd like to see filesystems implementing efficient copying of files by the use of CoW, but that must be transparent to the overlying applications.
Everything, including advanced security policies (more advanced than what is currently possible)
Do we want more complicated security policies? They can be a threat to security because of implementation bugs or incorrect usage. There are few situations that cannot be covered with the user, group, other attribute concept. But in fact more complicated security policies are being built into hierarchical filesystems, so we don't need a keyword system for that.
Finally it must be noted that I don't dislike the idea of a keyword based approach to files, I just don't want to give up the hierarchical filesystem to achieve it. A keyword approach built on top of a hierarchical filesystem sounds like a great idea to me. Built as an extension to a hierarchical filesystem also is an option, though care must be taken not to break too many existing applications. You don't want to loose your metadata because your backup utility saves only the files without the keywords.
Also note that I don't say a filesystem must be simple, only that it should implement a simple concept. A simple interface between applications and filesystem is important to me. But the underlying filesystem implementation can be arbitrary complex, and sometimes that is a good idea. FAT is a perfect example of a too primitive implementation.
Do you care about the security of your wireless mouse?
Holy shit, that sounds like a whole lot of infrastructure just to work around shortcomings of windows 9x! ;-)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
That is not true. When you click start, you are actually browsing the start menu, which is $WINDIR\Start Menu in 95/98, and under your profile directory in 2000, and probably XP, NT.
Programs is a subdirectory of Start Menu, as is Startup. These folders (typically) contain "shortcuts" to files all over your computer, not necessarily located in the Program Files directory. If you were to browse the Program Files directory, you would see an ASSLOAD of stuff.
Also, you can double click My Computer and browse your drive from there. Or, you could click Start -> Run, and type in something like "c:\" to browse the c: drive. Or, use Windows Explorer. Or, use Internet Exploder. The directories in Windows are hardly hidden. However, certain file types ARE hidden by default, so the first thing I ever do when I touch a Windows computer is turn off the "hide file extensions of known types" and "hide system files". Those are the only 2 methods by which MS "hides" files from users.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
regular expressions?
And unless I'm missing something here I havn't a clue as to what this has to do with free software. You've created a database that stands as a layer *between* the HFS and the user, as a middleware layer.
Well, I can do that in Access and VBA.
Besides, as everyone * and his grandmother, literally* is saying already, people understand and *LIKE* the HFS. That's why it's lasted so long as it is, not for any technical reason.
"Mary, get me the deeds for the Swanson account."
Ok, go to the "Records" room. Go to the "file cabinets." Go to the "S" section. Open the "Sw" drawer. Remove the "Swanson" file folder. Remove the "deeds" envelope. Open envelope and remove "deeds."
HFS is how the real world works. *YOU* are trying to invent a "logical" system that can only be applied in a virtual space, which means that people will find it *less* intuitive.
And you've done it in a bloatful, crufty, way that emits bogons like crazy. It makes me want to scream "It's alive!"
File locations are already stored in a database, why, not only, reinvent the wheel but glue an extra set to the side? It would have been far more elegant and resource friendly if you'ld just made a user friendly front end to find and regular expressions.
Which of course brings us to where the problem of finding files really lies. The failure of the "user" to give files meaningful search terms.I don't see your system really addressing this issue in any meaningful way. This is actually much easier to do in a flat HFS way than in a RDMS way. Some*one* is going to have to *tell* the database that this is an article *about* the NYT, not an article *from* the NYT.
It really does all come down to the nut that holds the keyboard. You can only go so far in designing around that.
KFG
> Errr, symlinks anyone,
Symlinks only allow you to give an object multiple identifiers. I think the win here is supposed to be that replacing (or augmenting) the hierarchy-based infrastructure with an attribute-based one allows the user to create views on the fly, without having to use more than one identifier.
> create a file saving/organizing app that would automatically set up HFS links based on attributes
Sounds just like the subject, only less transparent.
Russian puppets - forgot the name
... sort of. :)
Babushkas. If you want some, there's always Google.
Um, I'm pretty sure babushka is Russian for an old woman or grandmother, or a statute of same. (Or I see in the dictionary, a head scarf. This is sort of like aloha.)
I think the poster refers to Ukrainian (or Russian) Nesting Dolls.
Well, you did ask
Pick was never relational.
We are talking different levels. Pointers, C and the like are system programming. The relational model is for applications programming. Perhaps Lisp or something the like could bridge these levels, but in principle they are different. And even C could use relational storage.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I think Multics dates from 1965, see History and 1965 paper on the file system.
Just to let you know that MS didn't innovate this one.
Back in the 80's a British computer company, ICL, produced a chunk of hardware called CAFS. This did a basically similar thing.
Unfortunately for them their management was absolutely crap and a number of their other ideas (Distributed Array Processor, mainframes with a tagged architecture, compilable scripting language) all disappeared. I believe they are now an MS reseller.
SQL is not relational, the latest versions of the related standard do not even use the word relational or the concepts of the relational model.
By violating principles, adding arbitrary restrictions and being too complex SQL robs us of simplicity, power and speed the relational model is capable of delivering.
This is a big issue. I recomment you read whatever you can get your hands on from Chris J Date, Hugh Darwen, Fabian Pascal, David McGoveran and E F "Ted" Codd.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
"Filesystem? I don't need no stinkin filesystem!" An ideal Palm-esque computing environment wouldn't have any filesystem.
I've been thinking along these lines for a couple years now. Suppose a computing appliance, perhaps handheld, or not, didn't have a filesystem. How would you make use of the hard disk?
Suppose the software saves everything in memory resident database. No filesystem, and no disk. Everything stays in memory. But it is virtual memory. Every page in memory has a reserved backing store page on the disk. The disk partition for this OS is just a big swap area. The total size of your usable "memory" is the swap area, not RAM. Now powering off the device becomes very fast. And so does powering on. No more "booting up" nonsense. You press the "off" button, and almost instantly the device is off. No matter how much data you have, or if you were in the middle of a huge unsaved word processing document, the device instantly powers off and back on again. No artificial concept of "saving" a file -- just like PalmOS. You don't "save" anything. In fact, no artificial concept of computer files. (For flamers: I'm not outlining a fully fleshed out implemention here, just some rough ideas, think different.)
You can still move your stuff to other computers via. "syncing" or whatever you want to call it. It's just that higher level concepts are copied, uploaded, downloaded, e-mailed, etc. rather than a file (i.e. collection of untyped, unlabeled bytes). I may move my mp3's, and they are still categorized by artist, recording, date, label, etc., etc..
I've also been thinking that a filesystem such as NTFS or ReiserFS that allows attaching huge ammounts of metadata, or small amounts of metadata to any file would be important. For instance, my 4096x2048 digital photograph of the grand canyon (big file), should still be able to have a thumbnail (say about 128 KB) attached as metadata. Since the thumbnail is part of the "directory" information of the file, merely copying the file to another location retains all the metadata. (As opposed to Windows or KDE, where the thumbnail is another little hidden file somewhere near where the original file was stored.) Heck, I might want a graphic thumbnail metadata attached to an mp3 file. Of course, I suggest ReiserFS or NTFS because there should be no limit on the number of labeled metadata attachments, nor on their size. I should be able to attach metadata "Title":"Grand Canyon", "TYPE","TIFF", or "Audio Clipping":<5 MB of audio data> just as easily. When I move the file, the metadata moves with it -- but the metadata is not seen in the primary information flow -- i.e. sequence of bytes -- that make up the "file" data.
As much as I hate Microsoft, I expect that it is they who will do stuff like this first. Ideas such as I am discussing here will encounter lots of resistance from the old school. Just look at the resistance to the topic of this article in this discussion. (I remember when we had to had to organize and save our files ourselves, and we used stupid extensions like ".jpeg" as the only metadata, and it was uphill both ways.)
Drifting to a different topic, I wonder if true innovations at higher levels come from us geeks? We put up with the most abysmal user interfaces for so long that we are not even capable of recognizing a bad user interface. We are comfortable with what we've got. I frequently see the attitude: if I can learn this stuff, then you can too. If you can't get under the hood of your 1920's car and fix it when it frequently has minor troubles, then you shouldn't be driving. Where I'm going with this is that it may take talented people who are being paid to build next generation interfaces who follow someone else's vision who is not constrained by the present.
Just some opinions. I should quit rambling now.
The price of freedom is eternal litigation.
i didn't say that start menu was "Exactly" like browsing your program files folder...i said it was "basically" like it, or something like that...in any case, my point was that they've made it easy to access all the things you need to launch individual programs by placing shortcuts to them in the Start=>Programs heirarchy...so, the Start=>Programs menu, is basically an easier way to navigate the program files structure...assuming you're looking to launch applications...
i also brought up that you can use "My Computer" to search through the directory structure, and i agree completely, i always turn on all file extensions, and show all system files by default...
the other thing i hate is the thing XP has where when you're browsing through the structure it doesn't show you anything until you click on the "Show all files" after the "This folder contains system files" or something like that warning message...of course, i turn all that off by default too...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
> INFORMATION CAN EXIST IN MULTIPLE PLACES
I disagree with your all-caps assertion. Even in a filesystem, information does not exist in many places. What you think of as a unit of information which does "exist in multiple places" is really just one such unit seen through some retrieval sleight-of-hand. HFS does have some of the magic, in the form of links (both hard and sym).
Perhaps I'm just lucky but I've never had that problem (files getting placed in strange locations) when using a UNIX-based tool. It happens quite often in Windows, though, with Office wanting to put everything under 'My Documents' instead of in the project directory where the darned file was supposed to go. Having said that, UNIX tools sometimes will put a file in an unexpected place but only when you launch them from a GUI which tends to make the app believe that the starting directory should be $HOME. Personally, I don't find that too much of a problem since I tend to work in an xterm most of the time and find it easier to keep my hands on the keyboard but I can see the viewpoint of others who (somehow :-) ) do most of their work with a mouse.
I sort of like the idea of searching by keywords. Heck this has been available in various word processors for quite some time. The problem is that you have to bend over backwards to save the documents with keywords. Plus you have to go through the effort of assigning meaningful keywords to the documents. Then you have to remember what keywords have been used in the documents. Saving a file and not assigning any keywords to it makes it ``unfindable'' in a later keyword search. But forgetting the keywords makes it just as unfindable. Now a keyword search system that incorporated Roget's Thesaurus so that a keyword search for ``cats'' would find something wiht a keyword ``feline'' would be something.
I'll bet there's a heated debate on that topic currently raging on some ``alt'' Usenet group.
CUR ALLOC 20195.....5804M
Neither "newdocms" nor "The Brain" are any big breakthroughs. Attributed and associative information storage go back all the way to Vannevar Bush, if not before. There have been numerous attempts to implement them, mostly in research settings. The most successful one, the web itself is an experiment in associative information storage. Commercial implementations are, as usual, very late to the game and just trying to skim the cream off decades of research by others.
I think approach taken by "The Brain" is better: no need to burden the file system with indexing and attribution. However, there is nothing unique to "The Brain"--there are plenty of other systems that create, maintain, organize, and display relationships among documents. "The Brain" just has a better marketing strategy behind it and a slicker UI.
That's what I was saying, you can still create views on the fly. It's very easy, and most likely how this project works. I haven't had time to pull the tarball down and check it out, but it is a layer between a HFS and the user, essentially just a shell. So at some level it is still an HFS. In fact I would call this project a file system at all, it's a file system browser.
I'm the big fish in the big pond bitch.
Microsoft has been working on this for ages. Remember Cairo? I think I first heard presentations on it in 92. Basically all of it has been implemented over the years except for the famed object file system, which is basically what this sounds like. Plans are currently to implement it in Longhorn.
1. If you're point-and-clicking, long path names are not a problem. They're only a pain for the hard-core text-only fanatic. Besides, suppose it takes you a dozen clicks to get to a directory containing the files; how many attributes would you have to enter to find those files in a similar way?
2. Fair enough. But are any of these apps going to work with this new system. $5 says they won't...
3. Symlinks. Even Windows allows you the ability to use shortcuts. You can have any number of directories, each with shortcuts/symlinks/whatever (pick your OS; pick your naming convention) to the actual location of the files themselves. You have to remember to add the shortcuts to the relevant directories when you do it, but then with the other way you have to remember to set the right attributes as well.
Grab.
> "I've also been thinking that a filesystem such as
> NTFS or ReiserFS that allows attaching huge
> ammounts of metadata, or small amounts of metadata
> to any file would be important. For instance, my
> 4096x2048 digital photograph of the grand canyon
> (big file), should still be able to have a
> thumbnail (say about 128 KB) attached as metadata."
Uh, you mean like ADS in NTFS? Some thumbnail programs use it for keeping the thumbnails attached. The data is automatically discarded by NT when the file is copied to a partition which doesn't have NTFS (FAT/ISO9660)... Since the data is an 'attached' file, you can store any kind of data there (and access or execute them like other files/executables)
Google: NTFS ADS
It's a bad idea to put this sort of thing in the kernel, like Microsoft is doing: file system attributes and indexing add too much unnecessary complexity and overhead to the kernel; kernel file systems aren't used primarily for organizing user-created documents.
(You also deserved to get "bitch slapped" for calling an old and tired idea like that "radical".)
Case 1:
I'm your average home user, but even so I have about 100 documents I work on. However, I was smart enough to give them meaningful filenames and locations where it takes only a few seconds to find the file. Remembering attributes for each and every file would be a pain.
Case 2:
I'm a developer. I'm sorry, but I want file Y in F/O/O/BAR. I need something exact to describe where a file is at least. Anything else doesn't work.
Case 3:
I'm a mornon who doesn't give a flying-f*** about where I put my files, and I don't care what I name them. I already have documents in my C\:, C:\Windows/Temp, C:\sdf34\, and C:Documants. It takes me a couple minutes or two to find a file. What? I have to classify by keyword now? Who do you think I am? It needs to classify the files for me or I won't have any of it.
Case 4:
I'm a scientist/business man that deals with classifications on a day to day basis. I already have a database because I needed it to be efficient. If it was on the file system level, then it'd be pretty cool.
I can't think of any other positive cases where this product is useful. Thus, it's my bet that it'll be niche forever. Anybody got any other use cases that I'm obviously missing?
But there's something that your meatspace filing system has (or at least all the ones I've ever used have) that a HFS doesn't have. That's a metadata index.
When an item is filed in a meatspace filesystem entries are made into an indexing system. Your files may be ordered by an attribute but for each other attribute that you might want to search by there will be an index that tells you where to find the files that match that attribute.
For example if your filesystem stores patient records for a hospital your records will most likely be ordered by an arificial key like 'patient number' to ensure uniqueness. To locate a record by that you would probably either apply some decoding algorithm to the patient number (e.g. first two characters are the cabinet, next character is the drawer, next two are the folder &c) or look it up in an index which will tell you the location of the file. Suppose you then want to see all patients treated by Dr Jones in the last 6 months? You can't use patient number to look that up so you would have a separate index which gives you locations of files for patients treated by a particular doctor with the dates of treatment. And now suppose you want to see the records for patients treated in a particular time period? You could either use the doctor index but check all doctors or have a calendar based index that records when files were updated. And if you wanted to see all records for patients who had reported with certain conditions you'd need an index by condition.
HFSs don't tend to have these extra indexes, the DMS adds them. If you know that the only way anyone could possibly want to access a set of documents is always via the same criteria then you can get away with just a HFS, but such situations are uncommon in real world organisations.
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
You might come up with new ways to organize the tree, maybe some different ways but it's still the only way you can process data.
Hierarchical file systems have become as prominent as they are because they are simple, they are efficient, they work, and they support all the indexing and attribution people need (well, that may not be true of VFAT, but it is true of modern UNIX file systems). Attribution schemes are easily mapped onto hierarchies. For example, I organize my documents and projects as ~/{work,personal}/(project)/...
But I also have other directory trees. I store stuff by keywords under "~/notes"; file names in that directory are very long, containing many words. To find something, I can search for it with "locate keyword" or "ls ~/notes | grep keyword", and to browse through it, I might use "cd ~/notes; view $(ls | grep keyword)", or "cd ~/notes; ls | grep keyword | xbrowse".
Experimental results are stored as ~/data/(experiment)/(condition)/(subcondition)/(su bsubcondition)/(measurements), and I have dozens of gigabytes of that stuff. The notion of a working directory lets me keep my data and my projects apart, and the hierarchical naming provides a quick an simple attribution scheme.
Directory trees are also easy to query in UNIX/Linux. If I don't remember whether project "foo" was personal or work-related, I can refer to it as "~/*/foo". If I'm looking for all the projects containing a particular image "img.jpg", I use something like "find ~/{work,personal} | fgrep img.jpg". Looking for any TeX file containing a particular phrase is also simple: "locate .tex | xargs grep -l phrase" for an older file and "find ~ | fgrep .tex | xargs grep -l phrase" for one I modified today. The command line utilites that UNIX and Linux come with out of the box are more powerful for indexing, attributing, and associating information than anything any commercial product or file system hack does, and they give me far more freedom in making crucial space/time tradeoffs.
These operations are not as fast as if the system had maintained indexes (well, for "locate" it does), but they are fast enough. Given that most of the time, I just want data access as quickly as possible, that's the right tradeoff as far as I'm concerned. I don't want to have to add additional metadata or pay overhead for indexes and attributions to speed up a rare and already fast operation further.
I think a lot of these efforts to add attribution and indexing to the UNIX file system are because people just don't understand the capabilities they have already at their fingertips in UNIX.
Of course, there is probably value for people working in GUI environments on Linux to get some handholding: you can't "find" or "grep" from within a GUI, so GUI-based users really need extra help. And for that purpose, a library based approach like "newdocms" is the right one. But this stuff does not belong into the kernel, at least on a general purpose OS like UNIX or Linux.
Splitting a crowded directory affects all subdirs - they become one level deeper. On the other hand if a particular attribute tuple gets crowded (suppose I have many pics of leather clad pink bunnies), you only have to specify an additional attribute for this particular tuple (for example 'big eared' and 'small eared'). Notice, that the 'leather clad pink horses' tuple remains unaffected, and when it grows large, the already added 'big eared' and 'small eared' attribute will probably work fine.
This has some analogies in graph theory - while a hierarchical file system is a tree (and a not very well balanced one), an attribute based system is a hypercube-like structure. Generally, paths in hypercubes are shorter than in random trees of same degree. This of course is very vague and might not work in reality (just as HFS isn't a well-balanced tree, an attribute FS might be far from a nice regular hypercube).
For those that don't want to use this... don't. But i can almost guarantee that you don't know where all your scripts and documents are located off the top of your head. And other people who might need to browse your shared directories certainly don't. And you can't tell me that there has never been a time that a doc could have been properly placed in more than one folder- everything can't be pigeonholed into one exact category... that is the nature of information. However, i agree that this system has its limitations. I've been wanting to do something like this, but it would allow you to save your document where you want in the HFS, and would make links from other "category" directories to the "actual" directories based on what the computer knows about the file (i.e. it is an mp3 file, so it goes in the audio category and the mp3 category, at least) and categories that you select in the Save dialog box. These categories and files would also be indexed in some type of database for additional searching capabilities. Please let me know of any products that do something similar to this.
We have a document imaging system that does basically just that. It's a Win32 package called application extender from OTG software. It hooks into your file->save dialogs and stores all your documents in a share with a nasty ID as the name, but then you look things up via the attributes you've set. Normal users don't actually even interact, or know where the true files are stored.
It's actually excruciatingly painful for users to deal with sometimes, since their interface makes it very difficult for normal users to figure out how to open an "actual file" rather than something in the application extender database.
As for the DBMS part, yes, Pick was a DBMS-based OS. But not for the relational part, because Picke was never relational, and any non-relational system is so limited to really not be much of an advantage anyway.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Good to hear that someone's making it a reality -- it seems like a much more logical approach than a hierarchy for some things...
With something like this, my family could, just possibly, manage to keep our digital photos organized...
This is really important stuff. The file cabinet concept worked well for many years, because it bridged the tree model systems design could create, and an intuitive real-world model users could understand. There are three prevalent models individuals use to interact with the world. Any system design that encompasses only one of these will always be difficult to use for the majority of the population. This app doesnt break new ground beyond the text based approch, but it DOES try to break out of the document/tree centered way things work now. That is a good thing and we should applaud.
The next big mountain to climb is expanding the interface. A variety of ways to interact with systems in different circumstances is needed before the real promise of computers can be realized in everyday life. That means a variety of ways to manage documents and information. While I am at my desk, a HFS is fine. But I want to use a wearable computer for active tasks. A voice driven, keyword oriented filing system with audio feedback is probably going to be more useful than a point and click driven HFS in that situation. An app like this one is helping to build the foundation for these kinds of new interfaces.
The posters that ask whats wrong with HFS, or say that unorganized users will lose their files anyway are suffering from ivory tower vertigo. They are like the monks that saw no reason why anything needed to be written in anything but Latin. Ignore them. They don't understand what you are doing.
Cool. But how can you mash this into a filename string so it works with everything else in the OS?
But wait, I thought you said it was at the OS level.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
My problem has always been, for example, for class note-taking, do I set up:
college
class 1
homework
schedule
notes
class 2
assignments
schedule
notes
(etc)
or
college
homework
class 1
class 2
schedule
class 1
class 2
notes
class 1
class 2
(etc)
And I've often thought about this ability. Perhaps add some autodetection capabilities... give files automatic attributes such as "English"/"Spanish"/"Romanji" or "C"/"C++"/"Perl"...?
if the answer isn't violence, neither is your silence / freedom of expression doesn't make it alright
The problem is people don't want to be organized, so they look to technology to help them be lazy. Plus try explaining 'metadata' to someone. At least now you can use the file cabinet, drawers, folders, papers example to explain the layout to someone.
Your right, people don't want to be organized. They want to be lazy. That's what computers are for... to do otherwise thoughtless work.
As far as explaining the word metadata, why would I try to do that? People already understand the word 'description'. Describe the file.
People use metadata every day. When my mom wants to play a game online, she doesn't go to games.yahoo.com. She goes to google and types "online card game". When someone wants to buy a pair of shoes, they don't type http://www.amazon.com/exec/obidos/tg/detail/-/B000 072G1W/qid=1041616305//104-5897266-1255115?v=glanc e&n=507846. They type amazon.com and then search for "Nike Shoes". People will understand it if it's presented correctly (which of course, it won't be until Apple or MS get a hold of it).
-- sorry about that last comment. I couldn't help it.But we do have subgroups here, some of which tend to act as a mob a la religious fanatics. Try posting something unflattering to Apple or to Mac users in any Apple-Whatever discussion. Doesn't matter if you had a good point or an honest observation; you'll get modded down to oblivion anyway. And yeah, it's tribalism in action, that mortal enemy of independent thought. But of course that could *never* happen on Slashdot, where folk are expected to think for themselves ;}
~REZ~ #43301. Who'd fake being me anyway?
Putting it into the kernel also strikes me as just a dandy way to lose or corrupt all your data, in the event that the filesystem gets wonked -- even what are now trivial disk errors could become disasters. How do you recover your data if the only way to tell which file is what is in a now-mangled index??
Seriously, has anyone got ideas about that? (remembering that current backups are increasingly a pleasant fantasy, rather than functional reality.)
~REZ~ #43301. Who'd fake being me anyway?
No longer will you browse complex directory trees or directly interact with the HFS; instead, you define any number of document attributes when saving a document and then query a database of those attributes when trying to retrieve it later on.
Yes... lets make OS's even more confusing for the average person!
Seriously... why? All you did was change the way we access the HFS... Instead of having a directory called "Program Files" or "home", we now have an "attribute" called "Program Files" and "home". Congratulations, you've sucessfully created a file system that forces you to type in the location of the file instead of just double clicking on some icons...
Nah, works because I misspelled it in my document in the first place. ;)
-FF
SQUEAK, the Death of Rats explained.
"free software" ... actually lags behind software driven by the profit model.
Who says free sofware is never driven by the profit model? Tell that to Red Hat.
Find free books.
The problem with a HFS is just that paths are usually not commutative. That is, I might save some .ogg file as 'Albums/Indie/Slut/Blow Up.ogg', but I can not easily simultaneously access it as 'Indie/Albums/Slut/Blow Up.ogg'.
Why would I want that? The first path is useful when I want to browse all full albums. The second is useful when I'm looking for all Indie songs, including those which belong to collections of full albums.
Another path would be simply '/Slut/Hope.ogg', for getting all songs by Slut, including those not belonging to a full album. I would want to find 'Blow Up.ogg' in that same directory as well.
A nicely sorted ogg/mp3 collection is just one example. There are lots of documents on my computer that I could sort more nicely based on attributes instead of a plain hierarchy.
I'm not saying that newdocms meets my requirements, as I haven't tried it yet. My vision is some way of storing files along with attributes and using paths as a kind of query on attributes or keywords. Something to the effect of '/this/that/file' matching attributes/keywords 'this' and 'that', or maybe advanced queries allowing not only and-type queries, but more general boolean or regex operators.
Of course. Your computer is not going to clean up after you. And I don't want it to. But Manuel's attempt at least seems to be trying to give me a more powerful tool to sort my files. Maybe people don't want to be organized, but some might like more advanced features. A hierarchical system works pretty well, but nobody said it's the ultimate perfection.
I'm guessing you are an idiot who calls someone stupid because you don't immediately understand their point. I know what a relational model is thank you.
My point was that the semantic gap between the data model used in databases and the data model used in all modern programming languages - C#, Java etc. is completely unnecessary.
There is no reason I should need to encode my data in tables just to get atomic transactions. I should be able to create a class and get atomicity simply by declaring that the methods on that class are atomic.
There is a whole field of 'persistent' programming methodologies you appear to be ignorant of, so don't go arround telling people they are stupid.
The problem we have is that there are many types of database. Applications typically use only a limited subset of the capabilities of a database. All the programmer is usually interested in is making transactions atomic and persistent.
If you want to analyse a large amount of data manually you need a different set of features. You want a tool that provides you with an interactive and flexible view of the data. It is most likely that if you are dealling with data manually you are going to be using a snapshot of the data.
I agree that a form of JOIN is useful in the second case. However if you are providing a persistence store for applications, which is what a file system level database would be targeted as that level of power is completely undesirable.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
For one thing, HFS makes document security simple. By storing in directory X, you limit use of the document to those with various levels in User Group X.
For the home user/single PC, it's GIGO -- no matter the file system, whether HFS or metadata, the user has to recall it. Usually when looking for those 2-y.o. records, the user will give up and do a full content search. No great loss in productivity for the simple home user, who doesn't have that much data to organize in the first place.
For corporations with networks and immense document structures(where metadata comes in handy), there are already dozens of software/servers that allow indexing by metadata -- like Centra2000 (now Konfig), or *gag* Sharepoint Portal Server, or Documentum. The admin stores documents in an HFS (for determining security/accessibility), but the users find the docs using metadata, indexing, or links without having to worry about the OS Directory location. Very reliable, easy for users to understand.
In the end, the problem is solved for business, and for home users, the problem is the home user, not the amount of data or structure of the FS.
So that would work for pictures...
Now what about some movies of the family? How would they be arranged? What about a short story that the kid wrote for school?
Hello McFly!! People aren't just storing documents! Music, pictures, movies, email, and so on, all need to be stored. Making a hack for one type of format doesn't help for the 15 other types.
So forget grep. Forget find. HFS isn't cutting it.
No, I don't trust in god. He'll have to pay up front, like everybody else.
SomeGuyFromCA has a point. I wish someone had time to investigate this. I had the same problem when I was a student. Now I'm working full time and there's a lot of travelling involved, so don't have enough spare time to think about stuff like this much.
;-)
Perhaps someone could write something using newdocms that arranges your stuff in eother of these ways. Documents would need to be given two attributes. One for class 1 | class 2, and one for homework | schedule | notes. I'd like a combination of the hierarchical file system and newdocms. I'd like all my GTK themes to live in a folder called gtk_themes, and so on.
Also, I think newdocms should get a better name. It'll sound out of date when it stops being new
Follow me
3. Some items do not fit into the hierarchical structure. Should my porn directory be organized into movies, stills and texts or perhaps perverted, spicy and nice? Whichever atrribute I choose I will have trouble searching on the other.
/porn/movies (contains movies)
/porn/stills (contains stills)
/porn/text (contains text)
/porn/perverted (contains symbolic links to files in the above)
/porn/spicy (ditto)
/porn/nice (ditto)
Well, in a good file system, you can make a set of directories like this: (since we're using porn as an example)
Some platforms are much better suited to doing this (unix), while others (Win) are not.
Now, having the ability to automatically generate the symbolic links would be nice.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
Quoting the article...
...write an OS from scratch or perhaps license code from Microsoft or Apple...
Obviously not a true geek then. Why not talk of licensing code from Sun or IBM?
Follow me
Nothing about the file systems prohibit your functionality, that is all application level stuff. Hard/Soft Links are there if the save dialog supported it. But for the common user, I think that dialog would be excessively confusing (I can't imagine how you would offer the selection graphically, and whatever delimiter you choose if by text could cause a great deal of confusion to a user unfamiliar with it who just happens to try to use the character as part of a single filename). For those that want it, there are links, aliases, .lnk files in the appropriate operating systems, all easily accessible through file managers. Too many people and systems focus and getting as far away from the file manager as possible, turning it into basically a launch platform and having most file management tasks done in the open/save dialogs. This is sloppy. I like some ideas as exemplified by rox (http://rox.sf.net/). Applications developed purely with rox in mind don't have open/save dialogs, they offer convenient methods of calling up a rox window in a reasonable location. Both loading and saving are done through drag and drop. Smoothly integrating the file manager with applications works very well, and means the user does not have to become accustomed to different, inconsistant methods of file management. Operations should be intuitive, consistant, and symmetric. If you can drag and drop to open a file (and all apps should open the file, not paste it in as some do), the same should be possible to save. Of course this is all unreasonable now, people are used to open/save dialogs and this just would be confusing, but it would have been nice if things had gone that way in the mainstream....
For two, I think application preferences regarding this matter work well. Imagine that you had a system that did choose the default directory based on a 'find -type f -exec file {};' sort of mechanism (and by some miracle worked without a performance hit). This means the default directory could change between two save dialogs opening without the user necessarily doing anything to change this. Say they do spring cleaning on a directory of spreadsheets, and categorize each and put them all in different directories. Now they make a new one, go to save it, probably not paying attention to the path since they are used to knowing where it goes, and it picks the biggest category. Incorrect behavior.
I have not known a single person who desperately needs or wants a revolution with regard to file organization. They almost always know where to look for things, and in the rare event they do not, file search is there. Boosting the speed and complexity of that functionality without impacting the general user experience is where the most good can be done. No reason to subject computer users in general to a file organization paradigm shift (not to mention legacy applications).
XML is like violence. If it doesn't solve the problem, use more.
Wow. Animal porn and graph theory in the same post. Only on Slashdot...
A deep unwavering belief is a sure sign you're missing something...
Not many... I'm working now for a government office, trying to convert plans to pdf. They come in bits and pieces and lots of the original material is lost. Most of the time I'll end up scanning in whatever I can't find. If I could do a SQL query like "SELECT * FROM PLANS WHERE NO = '9985' AND STATUS = 'FINAL'" and magically have everything I need, but like hell if that's ever going to happen. When they can't even find a very specific file using the search function, there's no way in hell they'll add sufficent metadata.
Kjella
Live today, because you never know what tomorrow brings
I agree that people are brainwashed to think plain text is evil... XML is an improvement, since it is typically human readable, but if it is a smallish application with a reasonably small search space, then plain text, or even XML is much better than a binary DB.
/etc/passwd as a directory, able to cd in and see the data listed in different ways simply by going to different directories and doing an ls. Individual entries could be opened in a text editor, or vi /etc/passwd and you get the view you are accustomed to. It's all the same to the filesystem, no matter how you do it. If the lowlevel filesystem drivers are aware of the workings of the database, they can and should implement transparent text editing facilities (and structures convenient to shells). The MS registry is a train wreck for many reasons. One of those is they never intended on heavy end-user direct modification, so it is ugly and not well integrated in terms of access. It *could* be as easy as editing a text file when implemented at a low enough level, it's just that people don't.
However, I think something on the scale of a filesystem needs something more efficient, both in terms of storage space efficiency and performance. A plain text fs index would be large and slow to query compared with an optimized database format. That does not mean, of course, that the data has to have special tools to access it. Quite the contrary, when implemented at the OS level, textual representations can be generated rather quickly on the fly for editing if you so choose. I seem to recall reading up on some of the ideas in the next-gen Reiser filesystem. Their example was
Of course I don't agree with the goal of this article either. Too obtrusive to the user. I would prefer something along the lines of 'locate' with more sophisticated and up-to-date indexing methods and more comprehensive attribute recording. Take the many many hints already available rather than asking a user to provide more. Would have to be implemented on a lower level to do it right, but a small price to pay to avoid using find when up-to-the-minute info is needed.
XML is like violence. If it doesn't solve the problem, use more.
Isn't that the entire point of AlienBrain? Source control for artists. Because otherwise they might be tempted to call files "Final version of nysetex32 more recent final32.max" or something like that and then copy that into "Backups" and "new" directories :-)
Of course AlienBrain ain't cheap (and I haven't used it myself), but they've obviously seen a need...
And yet, what is the filesystem itself but a very highly structured database anyway?
Look at the direction filesystems have been going. First we had simple filesystems with no directories, that just stored names and content. Then we had more complex filesystems that store directories, names, content, and specific attributes (owner, group, permissions). Then we had even more complex filesystems that stored arbitrary ACLs and metadata (NTFS). Alongside that development we have journalled filesystems that use (horrors!) transaction logs.
Since the filesystem is evolving towards being a full-fledged, transaction-capable database anyway, why not leap over the stuff in the middle and go straight for the gold?
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Ok--, my caveat is that this is the sort of product I won't use-- I find hfs's fit my needs pretty well, but I see this as good and important anyway for competitive reasons:
This is the same sort of result that Microsoft is trying to achieve in Longhorn, I believe. And this just means that we are beating them and coming out with their intended features *first.*
So, I am all for this because if people oooh and ahhh over Longhorn, we will have the alternative to offer them.
LedgerSMB: Open source Accounting/ERP
On a mac there is an application directory. When you click on it you see icons representing the whole of all the files an application contains. If I were to browse these contents manually I would see an assload of stuff, but since they are normally hidden from the user the Application directory itself is used in place of the start menu.
You really have to use a mac for a while to understand this one, after you do you will see how fucked up the start menu really is.
I live in a giant bucket.
/usr/
My stuff
/home/myname
Other crap that makes the computer run
/etc
Did I miss something? Perhaps it's simply a question of not telling the user about the confusing stuff. I generally set new users up with a WindowMaker desktop with icons already installed, and categorised by screen (1 to 10), and leave them to it.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I've been pondering this idea for a while.
:)
I've spoken about it in many IRC channels.
Now reading this Slashdot article, it seems that my idea is finally impelmented, and even the description is put in almost the exact same words I used to describe the idea.
I wonder if I inspired someone...
Even if they don't, as someone else suggested, always fill in the fields with the same bogus data, they'll figure out a way to create an empty document, save that with bogus data, then always open the document and save it under a new name or with as little extra typing as possible.
:-)
And then, they'll demand that YOU find it. The only way to solve these problems is to make the computer smarter than the user. Shouldn't be hard, but it is.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
No, it simply violates it.
No, it does not. Prolog is about relationships, not relations. It is nearly worthless as a database sublanguage, but useful for some AI-related stuff.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
So I need a different index for every type of file! I don't want an indexer for jpgs, a separate indexer for movies, another one for documents. What if I want to look for a common characteristic across several different types of documents? So I need to search through several little index programs. Not convinient.
Don't get me wrong - I still want to keep the HFS. But, I think an overlay with metadata would be significantly more effective.
Organizing a 120Gig drive is a chore. You have documents, music, pictures, movies, backups, notes, configuration files, and so on. HFS worked for 2Gig drives, but they are limited.
As for integration into the OS, lots of things are integrated into the OS now. Let me mention windows - thumbnails of pictures, web browsing, help functionality. KDE has sampling of audio files too. Just make an option to disable it, if you like it, use it. No arm-twisting either way.
This subject is a love-it/hate-it, that's for sure.
No, I don't trust in god. He'll have to pay up front, like everybody else.
About your work, Tablizer, it needs work... you still have to fully understand the relational model, and do away with SQL and navigational concepts. Much of what you say in your articles is simply a less clear form of relational algebra.
The Third Manifesto.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
With that said, I do have one caveat about hierarchical systems, that aren't typically addressed by such systems - the problem when you need to have a copy of the same thing reside in two (or more) areas.
I typically run into this with bookmarked links - say I have a bookmark for "3D Computer Graphics Programming" - well, it would be nice if it could referenced in multiple areas (each of those words could be a topic, for instance), without needing a copy in each area.
*nix tends to solve this (in the "standard" hierarchical filesystems typically used) through symbolic linking, which isn't a bad thing, but maintenance can be high (of course, *nix and shell scripting can come to the rescue here). Also, sometimes it would be nice if I could just search on some "keywords" and find the links/files I need based on a description (many times I find myself googling and bookmarking a link I already have - it would be nice to google and get the links I already have in my bookmarks first, then the links from an external search engine - I want to keep my links instead of only using google, because sometimes the link "goes away", but there is enough info in it and the URL to track down the site again, if it has moved or whatnot)...
Metadata filesystems try to bridge these areas, but they suffer from the issue of the user needing to enter in data about the file (especially if it is a sound file - ie, MP3 ID tags - or image file, like a jpeg - and IIRC, there are tags for jpegs as well - but are hardly ever filled in) as they save it.
Perhaps what is needed is more of a combo - keep storing stuff in a hierarchical filesystem, plus store a pointer to that file in a searchable database, populating the fields with the metadata from the file itself (if it has such fields, like jpegs, MP3s, etc - if not, ask for some generic data to be filled in). Finally, you would need some front-end "search" tools for the metadata representations, as well as some maintenance tools or something to keep the links/pointers in the DB up-to-date with the location of the file.
Something tells me that a simple version of such a system could be whipped up with a few Perl scripts, MySQL, and a cron job (maintenance)...
Reason is the Path to God - Anon
Yet you can glean much from what is online.
You have no libraries, no employer?
Some libraries accept suggestions, and I am actually having my employer buy literature such as this.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
What you discribed if thats the way you want to have your files orginized is the way you (people) can do it in a hierachical file system. Thats how i always orginize things on my computer. Is there something more to this that you didn't say or wasn't clear.
Conceptually, it exists in multiple places, in reality in the techical side, it doesn't of course. But I think it would be obvious that were talking conceptually here, since the techical side is irrelivant from the users perspective.
Where do you get this idea that people "weren't able" to give meaningful files to names? All current filesystems give the user quite a bit of space to generate meaningful directory and file names.
What is not in evidence is that anyone ever had any problem organizing their file system data for any other reason than laziness.
Unless the new system is AUTOMATIC, it will be subject to at least as many problems as the old ones. Any system that intends to depend on the initiative of uninterested end users will fail miserably.
A Pirate and a Puritan look the same on a balance sheet.
Ok, that worked for that companies files, but how do I manage the 100,000+ files just on my laptop (and no, it's not porn. Some of us have real lives and real data!)? Moore's law also applies to the amount of files collected by users on their hard drives, but we are rapidly reaching the limit of files we can manage (i.e. navigate, not store) with the traditional file systems.
This is a problem of sufficient complexity that it is probably beyond any single individual to solve. The existing hierarchal system is flexible and simple to use. It aint broke, but it is limited in its ability to support the management of a large amount of disparate but loosely linked information. However, getting a taxonomical attribute classification file system into the mainstream will require a quantum leap, as there are many problems to be solved to achieve the same simplicity as our existing solution.
A good attribute based file system is real hard:
They can be used for different purposes and users
Attributes should be hierarchal (classifying): E.g.: Operating System::\bin\bash, or Operating System::\system32\drivers\bin
Note that while it is possible to have strong taxonomies that are non hierarchal through use of multiple attributes, the hierarchical structure gives a richer and more precise language for the taxonomy. Also, simple attributes like "blue" are fairly meaningless - are we talking about "emotion\blue" or "color\blue"?
Need to have multiple attributes to achieve a full classification. E.g. Operating System::~\My Documents\, Applications::\Word\, User Classifications::~\work\\projects\
Classification data required should be minimal in the beginning
Need to classify files enough to maintain "sensible" uniqueness. Timestamps can differentiate between two files for uniqueness (e.g. financial reports#1999 Vs financial reports#2000), but more meaningful classifications can be found (e.g. financial reports#My tax Vs financial reports#Enron Corp). (Especially as file system timestamps often don't match the original time relevant to the content).
Classifications for existing content should evolve over time, i.e. more precise classification data should be added to old content as new content is added.
We need multiple layers to support such a file system:
Underlying file system, APIs etc
Applications that are taxonomically aware
GUI and command line based tools of equal capabilities
Tools for manually classifying content
Navigation tools that provide rapid, intuitive navigation of multiple dimensions
Users trained to understand the file system metaphors & mechanics
And then we need:
Intelligence tools to automatically suggest classification attributes based on the content and the systems learnt understanding of the user.
We need to know when to stop! Hey, we could build a full AI system to manage contextual relationships and understand content, but let's get the minimal set of features required to make the use of the system compelling.
SQL is not the answer here...
The metadata management risks and issues are similar to other file systems. Remember DOS compressed drives? Eventually MS achieved reliable file system compression in NTFS. Yes, this is complex and risky until the bugs are sorted out. No, I don't want to run a production system on an unstable filesystem.
So good luck to Manuel. This will be an area of much activity.
Thanks for clearing that up. I get what your saying. I don't think hierachical is bad though. For most uses you probably would always think in the same order. There typicaly is one order that is more logical than the others. But having they way you mention would be nice to have.
Well, a lot of it *is* the interface... It helps me remember things that I wouldn't normally remember on my trips into the hierarchies on the various computers. It's truly *one* place to find things... I could do the same thing with shortcuts to different things, but not only do I point to documents, but also to email, web sites, etc. And they're organized by the way that I think, so it doesn't matter if it's a text document, email, web site, application, etc. It's all connected. Also, I get to jot down notes about all kinds of things. No need for multiple text files, or one big text file.
One example:
I run a brick & mortar shop where I'm constantly buying new products. I get requests, I find cool things, and I have to keep track of them. I have a few thoughts that are "immediate", "longer term", and "like to have these if I can find 'em". Sometimes they're requests, so I jot a quick note. Sometimes they're in emails, so I'll link the email. Sometimes they're websites, so I'll link to those. And, I also have links from products, to say, ways I'd like to arrange stuff in the store. I need to get product X. Also, I'd like to re-arrange those shelves like that. And, oh yeah, I also have a bill to pay to vendor Y. And I also have to buy product Z next time I order from vendor Y. And here's the fax number for vendor Y. Oh, and Vendor Y has a custom app to order via EDI. Here's a link to that app.
It's all connected in ways that I think to keep it centralized and to jog my memory when I've got hundreds of different things going on. The only drawback is training myself to use it, like any other system. But when I do, I find myself forgetting less, and working much more efficiently.
Well, I'm certainly lazy about organizing my stuff. I don't care about having things organized on paper, I care about understanding things in my head. I would love to have a computer keep track of things that I needed to know, as long as it learned to follow what I'm thinking. Obviously we're a long way from that, but this here is a small but very useful evolutionary step. No doubt people will want to continue to categorize and hierarchical represent things, drawing on the strengths of HFS. But they will also learn to use search and metadata based filesystems to organize things in other ways. And once they get a chance to do this, we can use what we learn to take more steps towards being lazy. And then slovenly victory will be ours!
Ah, yes all those millions of Google users who don't really understand metadata sure are having a hard time searching for things...
The presumption being that everyone will categorize their files the same way - ever try and find something on the P2P pirate (Kazoo & Murphious) networks? Same UI issue...
Windows auto-run - a truly stupid idea. How many times do you want to install the same application/driver/whatever every time you insert a CD? The geniass that dreamed that up should be strung up by his short and curlies.
Sorry, that's not my concept and isn't how I think of it, and I have no reason to believe that most or even many people think that way (of those who think about it at all). The idea is wrong from the start, so I don't see why I should alter my thinking to match it, either.
It is as if we are discussing telegrams, and you are telling me, in the London office, that you are duopresent "conceptually" in Bombay, on the grounds that you are able to transmit ideas to India over the wire.
So, if I choose 'Save As' and place my opened document in a new place it writes it in the same place on the harddrive? Maybe I'm not understanding what you're saying, but just because I can use links how many users actually do that? 'Save As' writes a copy to a new place on the harddrive, but now you have new information. If you want to delete/change this file, the other copies will remain unchanged. If you somehow use links, then you still run the risk of deleting the original and losing all information AND you are inconveniencing your self for the sake of an unintuitive filesystem.
I've seen the same file in multiple places on harddrives and each of them is taking up their own real estate. What you've seen are multiple copies of the same file.
Keeping
What about if you created a heirarchical filesystem that placed files into directories, but it didn't matter which order you typed directories. /home/biff/mp3s/NIN/broken.mp3
For example:
ls
listed the same file as was listed by:
ls mp3s/NIN/biff/broken.mp3
(I left a few directories out, because they are likely redundant). This is still a heirarchical filesystem, yet many of your anti-keyword filesystem people will agree that the order shouldn't matter. Well, this is a keyword based system.
This is a good idea for commandline driven keyword based system.
Keeping
Just so everyone is up to speed here, all filesystems have to store data on a physical disk. Pretty basic stuff, but when you start to think about the ideas suggested here (SQL queries against a raw disk device?? Physical layout by file type??), you need to rethink things a bit. The reason we have used HFS for the last 30 years is that it's very easy and efficient to store data on a disk using the directory/file paradigm at both the physical and UI levels. If someone here is smart enough to figure out a way to do a DB-on-a-disk, and (heaven forbid!) actually implements such a beast, you will forever be my hero.
All on-disk HFSes store metadata, and most (all?) store file metadata right next to the physical file. I know for sure this is the way ext2 and reiserfs work, having gone over the code myself recently. The hooks in the Linux 2.x FS API are designed to be even more flexible than this. If anyone knows of more and better metadata than any current FS implements, I invite you to roll your own and release a module.
In addition, there is no reason why anyone couldn't put together a user-space daemon to go over the on-disk filesystem recursively, say as a cron job, and put together a searchable index of metadata. This index could then be searched (via SQL even) by another user-land process, maybe even a new shell (sqlsh, anyone?). This shell (and the associated replacements for 'ls', 'cd', etc) wouldn't have to present the FS in hierarchical terms.
In any event, what we've got on disk isn't likely to change any time soon without a radical insight by someone who has experience bit-grovelling, and what we see as users is most likely to go on reflecting what we've got on disk unless someone writes the aforementioned userland tools. I have too many other things I'm working on right now, but mabye someone else will help us all out and start a new project?
This post expresses my opinion, not that of my employer. And yes, IAAL.
Guess what, they do not want to promote a new language standard. They want to promote relational systems.
If you take the pains to read the book, you will see Tutorial D is but a sample of what a sane relational language would be. It is by no means complete, nor intended to be an standard. The idea is that other people will implement it or something like it, and that is what Alphora for an example did: D4 has nothing to do with Tutorial D apart from conforming to The Third Manifesto. More precisely, Tutorial D follows the COBOL-like IBM tradition of Alpha, QUEL and SQL while D4 is Pascal-like.
Moreover, if you take the pains to do your homework and explore the Web you will see that even the authors themselves publish a Tutorial D grammar online, and several tentative implementation proposals besides.
So good learning!
BTW, what is your background apart from xBase?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
You've completely lost me. Maybe you could re-phrase you original post?
Then why the fuck did you use the example of 4(!) win2k machines? I apologize for assuming you had less experience with win* then you actually do.
OMFG M$ suxxor ROLOFL linux adn BsD is teh bomb!!11!"
Ok... Please stop putting line noise in my mouth, thanks.
That's why you're such an expert in Windows 2000 and why your servers (?) and workstations just wouldn't damn work.
I *never* said that. Our workstations work fine. *ALL* I said was that we have had *some* serious problems with win2k. And furthermore, I said the last time we had a serious problem was over a year ago. And you take this to mean our "workstations just wouldn't damn work"...
Our servers, and a couple workstations, run Linux and BSD, which we have never had any serious problems with. And no, we have never had any serious filesystem corruption with either Linux or BSD.
We are not falling all over ourselves trying to make our network work as you seem to think. It works fine, even the win2k machines. A couple win2k machines have had serious enough problems to require reinstalling windows, nothing catostrophic, just annoying.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I think that the hiericharial filesystem is the best way to organize file data. Remember that filesystems store a specific type of data. If you have to store something that dosen't fit well into the model, perhaps you need to use a database or something.
Jordan Bettis
OK, so let us see.
They presented sets of (1) Proscriptions, (2) Prescriptions, (3) Strong Recommendations for a valid relational database D. Moreover they have made it clear that anything abiding by (1) and (2) would qualify as a D.
Moreover, they produced an example D, named Tutorial. Their website includes a LARL Tutorial D grammar, besides links to tentative implementations, at least one of which is useable.
There are no patents.
So what else more you need for openness of a language?
Well, if you want working, free source code... be welcome to producing it!
Actually that is not true.
No one of commercial consequence ever heard Codd, only IBM BS12 and QUEL people; now Alphora too. IBM itself decided on SQL, which Codd decidedly disavowed and tried to reform.
It is just curiosity, because your writing gives a hint to your thought being conditioned by xBase and SQL, but mainly SQL. You do not seem to have read anything seriously relational.
Why are you so violent?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Basically because of their personal background. They have been used to big organisations, like IBM, its direct competitors and users, and standards bodies that produce books and really expensive documents.
Moreover, Chris J Date is not rich, and his living comes basically from his books. None of them are systems programmers.
Now Hugh Darwen has created The Third Manifesto, the site
, precisely to give people what you just asked.The book itself had precisely the same objective, just that it was meant to a different world. They are still trying to grok free software and the Net as related to it.
First, you inspire yourself in IBM BS12, which was a good realisation of the relational model, but an early one and only an implementation anyway. The model have developed a lot in the last 20 years, and his should base his work on the fully developed version of the general idea, not on a specific realisation of it. BTW, I guess you have no other contact with BS12 than that page, so even what you can get from BS12 is very limited.
Second, xBase is really no good neither as a language nor as a database interface. Influence from it should be qualified as contamination, not information.
Third, you still use SQL terminology, and it seems that you never grasped the relational concepts from which SQL decayed in the first place.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I did some research on this sort of thing, abandoning filenames and using metadata to fully categorize things. I never got a working implementation, but I got part of one ;)
[I had an interesting field of metadata that you might not think of right away, but I thought it might be useful. In addition to a "Creator application" field, I had an "Author of creator application" field. I thought this would be useful because, after installing about a thousand packages on one linux box over the years, I realized multiple authors have come up with the same clever acronyms, leading to confusion and conflict. I figured that the chances of both the author names and application names being identical were far, far smaller than just the application names being identical.]
Kudos to the developer of newdocms, and maybe he'll take his package one step further and throw away filenames altogether.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
If you can't buy some books, then you have to make do with that. Or perhaps offer them some help?
These guys have been toiling from 20 to 30 years now. The Net, and mission critical free software, is a new occurrence to them. They need time to adapt, they are not young.
Cursors are just a feature of the client library or of the database cache. They have nothing to do with a database model. Even SQL does cursors quite nicely.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Probably because having to FILL OUT the fields was a PITA. I think what the parent post had in mind was more like a series of checkboxes.
Speaking from bitter experience, you wouldn't believe the lengths some users will go to buck "the system". They see even simple checkboxes and drop-down menus as a gross infringement of their god-given right to create a useless mess. The same finger muscles that these people think with to make "New Document 1", "New Document 2" etc. get used to learn a series of rapid spacebar-and-tab clicks to make the bad metadata box go away. The result is all their documents get tagged as a single type. It takes good auditing (and a stern papal decree from management) in a large corporation to keep this to a manageable minimum.
OTOH, in small groups,where everyone can see who does what, it's harder to hide this kind of laziness. Newdocms looks very promising for workgroups.
Dear Mr. Arriaga,
:-)
We represent Microsoft Corporation, the owner of the federally registered trademark and service mark "MS". The mark "MS" is registered with the United States Patent and Trademark Office under registration numbers 1,775,441; 1,540,928; 1,342,353; 1,329,474; 1,318,717; 1,306,997; and 898018, copies of which are attached. We also represent the editors of Ms. Magazine, which is the licensee of the "Ms." trademark.
The federally registered trademark, "MS", is famous, distinctive and unique. Your use of this mark in the "newdocms" name dilutes the distinctiveness of the mark in violation of the federal trademark antidilution statute, 15 U.S.C. $ 1125(c) and California's antidilution statute. See, Archdiocese of St. Louis v. Internet Entertainment Group, Inc., 34 F.Supp.2d 1145 (E.D. Mo. 1999); Mattel, Inc. v. Internet dimensions, Inc., 55 U.S.P.Q.2d 1620 (S.D.N.Y. 2000); Deere & Co. v. MTD Products, Inc., 41 F.3d 39, 43 (2nd Cir. 1994).
Accordingly, in the hope that we may resolve this matter amicably, we request that you immediately cease and desist the use of this name and transfer it to us at once.
Yours Sincerely,
His Infernal Sliminess, Screwtape
Screwtape, Slubgob and Wormwood Attorneys
666 Wilshire Blvd.
Los Angeles, CA 90010
Suppose the software saves everything in memory resident database. No filesystem, and no disk. Everything stays in memory.
My Newton MessagePad 2000 computer (what I used before I could afford a real laptop) did this. And I got burned twice, in the same way: I had accidentally deleted the contents of a file and then typed some text. But because the app (called "NewtonWorks") saw those as two changes, and the app had only one level of undo, I had no way to recover the text because Newton applications automatically commit changes permanently. Had the app used an open/save metaphor like a Mac or Windows app, I would have been able to rollback my changes by close the document and answer no to "Save changes before closing?".
should still be able to have a thumbnail (say about 128 KB) attached as metadata.
Detail nit: Why should a thumbnail image take 128 KB? Most thumbnail images in image management programs I've seen are stored in a resolution close to 160x120 or smaller. At 160x120, a JFIF (.jpg) image saved in GIMP, with quality cranked up to just where the tiling disappears, weighs in at about 8 KB.
Will I retire or break 10K?