Quote:

Original post by C-Junkie *clicks* Nice. I'm going to think about this.

<revival>Hallelujah, brethren, we have another believer! Amen!</revival>

Quote:

Quote: Bad analogy. People are difficult to describe So is data. Seriously. How would you go about NOT naming (for instance) a sound file?

Your mixing up two distinct concepts. A sound file is the sound of something, meaning that something is a natural referrent. However, it doesn't necessarily make for a good filename. The Who Live in Concert is a great referrent; it establishes all necessary data immediately, and sets the appropriate expectation. It's a lousy filename, though, because - for starters - it lacks an extension.

Warning: Detour
Why the hell did Apple take a step backwards to using file extensions to determine type? That has to be one of the most unreliable mechanisms ever! Ever worse is the fact that they got it right before! The only reason I can think of is that they were a) swayed by the overwhelming number of Windows users who had difficulty with files from Macs because of resource forks, type IDs and so forth; or b) they were limited by the inherently text-based and -biased nature of BSD Unix on which they built OS X.

Either way, that's a huge step backwards.

Resuming my point about naming files, because filenames are significant to operating systems and because all resources are described textually, full expressivity in naming is precluded. You can't use a raft of characters in a filename in Windows, for instance, and to use quite a few in Unix you have to escape the character!

More importantly, though, the primacy of filenames requires us to apply thought to every little discardable and temporary piece of data and give it a name. It also inhibits the possibilities of autosaving, since the system will need to prompt you for a filename at some point.

Basically I'm saying that we should only have to name what we want to name, or what needs to be named because there is no other unambiguous way to locate it.

Quote:

Actually, as I just thought, that's kind of hard. How would you represent a hierarchy inside a database? It's rather hard to do efficiently... depends on the format again. sheesh.

Well, here's my idea. By examining the properties of our nameless files, automatic groupings suggest themselves. (I know this works; I used to work for a company that did statistical categorization of opinions across an organization using metadata and valuation. Maybe I'll describe it in greater detail some other time.)

Selecting any category suggests the category to which it belongs (the root category being "All Data"), as well as related categories ("Siblings") and sub-categories ("Offspring"). This hierarchy is broad rather than deep, is not fixed/permanent but rather dynamic, and can even be statistically adaptive.

Quote:

no wonder this hasn't been done everywhere before, it's extremely difficult.

Aye!

Oluseyi: Why not develop some proof-of-method by making a fake file system and making a graphical front end, maybe for windows?


Everybody else: I'm kind of slow, so can anybody give me some hints as to help me understand the concept of Oluseyi's file system. Primarily, how are files "no more than two levels away from where you are" Can somebody give an hypothetical tour of exploring a file system (I like to think in terms of visuals, so speaking in from a visual standpoint, like "clicking the file cabinet to draw out, entering search query, or seeing a list of recent documents...blah blah blah")

Sorry, but thanks!

Cipher3D

Quote:

Original post by Cipher3D Oluseyi: Why not develop some proof-of-method by making a fake file system and making a graphical front end, maybe for windows?

I will, eventually. I just don't want to go off half-cocked and create an intractable mess. It is important to me that the software be usable from a development side as well, which means solid software design. I'd rather spend more time on upfront design before committing to code.

I'm sleepy, so I might try and explain the filesystem in more detail later, if you're still confused when I get back.

Quote:

Original post by stimarco Right, for what it's worth, I'll nail my colours to the mast and make it clear that I'm not a great fan of the "Open Source" concept.

Really? Well, thanks for making that clear. I *never* would have guessed.

Quote:

But "Open Source" is a fundamentally flawed and irrelevant concept for end users -- what Oluseyi has referred to as a "prosumer" -- since the very concept of Open Source implies that the end user actually knows how to write their own code. This is acceptable if you're targeting major organisations with their own development teams, or even the major educational / R&D establishments, with their Ph.Ds and professors in Applied C++, but to Mr. Average in the street? Open Source is irrelevant to most people.

Sheesh. You don't need a PhD in Applied C++ to use Open Source. Hell, most of Open Source uses C, not C++. I have never needed to know how to program to use Open Source software.

Quote:

(2) The Open Source Software Militants.

Stupid. OSS is notably less militant than the FSF.

Quote:

Because Unix is based on the old serial processing model. It is a poor fit even for _today's_ ideas, let alone tomorrow's. Use it where it's applicable, but for crying out loud, stop acting like it's a perfect fit for every damned project under the Sun.

Except for the really expensive ones, computers are serial processing devices.

Quote:

If you want to see a modern, truly object-oriented operating system that _already_ includes many of Oluseyi's suggestions, look at Symbian. It makes Unix -- and Unix clones -- look like a bloody dinosaur.

Are we making an "OOP-Is-Perfect" assertion? I do hope not.

Quote:

Its claims of 'security' are also invalid: Windows is constantly being attacked because *it's what everyone uses*, not because it's insecure. (I'll grant there are holes in it, but Linux also has plenty of flaws reported too. They just don't get the same publicity as Windows ones do.)

Yawn. Windows is attacked because it's insecure. It's impossible to make an OS perfectly secure. However, it is possible to react quickly to reported exploits. Can you guess which OS tends to be patched against vulnerabilities within hours, and which within days?

Quote:

Quote: Bollocks. Every operating system is founded on that view. Do you know why? It's what a damned computer does! Speak for yourself. Again, I give you Symbian as evidence.

Of course, you can't say "again", because when I made my post, you had not given Symbian as evidence. Regardless, are you claiming that the Symbian OS is not based upon input/processing/output? The developers have reinvented the very definition of a computer?

Quote:

In Symbian, *everything* is a component. *Everything* is an object. Granted, it still retains the concept of 'applications', but these aren't the monolithic structures of old.

Somehow, this is proof that Symbian does not perform processing upon input and produce output?

Quote:

(a) automatically saves _everything_ for you; (b) automatically closes applications when memory is tight.

Of course, these things only work when they're together. Personally, I find it a little irritating that my phone is happy to scribble over a text message I was working on if I recieve a message whilst writing it and make a reply -- it automatically saves the reply over the original text message. I would be surprised if my email software behaved similarly. I might suggest that mobile phones are not, in fact, perfectly usable.

Quote:

Indeed, the mobile phone user experience is one of the reasons why I tend to rail against traditional GUIs so much. I've seen people who have a bloody hard time just grasping the _basics_ of Windows and MacOS X cheerfully texting their friends and relatives on a phone with a tiny, menu-based UI and a numeric keypad.

It's easy to make an interface to limited functionality. My wristwatch has a perfect user interface.

Quote:

Another example: very few phone apps will ask you for a name for your document, simply because they don't need to; the filename concept is retained because these things have to talk to PCs and Macs at some point. But I can tell which picture I want because I can _see_ it among the thumbnails on the screen. This same concept could equally apply to other visually-identifiable documents and I agree with Oluseyi that there are alternatives to asking for filenames if you think things through.

Pictures can be indexed by thumbnail, yes. With pictures, it's reasonable to suppose they can be indexed by keywords, thumbnails and an automatically chosen (and possibly hidden) Name. But that clearly doesn't apply to all types of file. How do you index a DLL with a thumbnail?

Quote:

When I go look through my papers for a bank statement, they're not particularly organised, but I can tell by _looking_ at the document which one is which. An annual report will invariably have a title page describing its contents; if your display has a high enough resolution, you could simply display the document's first page as a thumbnail for its icon. Filename no longer required. Think about it: do you stick a Post-It note on each and every piece of paper you own, with a name on it like "PhoneBillJUL03"? No. You can tell what a document is by looking at it. This wasn't possible in the old CLI days, but when GUIs were implemented, it seemed only 'natural' to perpetuate many CLI concepts, even when not required. OS X's "Dock" doesn't usually display app and document names, because the icons are either very obvious, or miniature renders of the application's main window.

You're making two mistakes. One is to assume that the best way to organise your bank statements is by sight. That's not the case. The best way to organise your bank statements is by date. In this case, you don't need to give the statement a name, the computer can figure one out because it has domain-specific knowledge -- it might give one of my bank statements the external name "www.myhost.com/~nbaum/statements/Halifax/2004/Q1", assuming I was unwise enough to public my bank statements online.

The other mistake is to confuse the actual with the potential. Display hardware cannot display thumbnails at a good enough resolution for you to identify complex similar-looking documents by sight, unless those thumbnails are very large indeed. This is, again, a situation where you need to think about what would happen in the real world. In the real world, a filing cabinet does not usually contain folders which have little thumbnails of their contents stuck to the front. That might be appropriate if the folders contain images, but even then there'd be metadata about images, such as the time, place, content and reason for the image being produced.

Quote:

Music is obviously more reliant on a labelling system of some sort, but with systems like CDDB to label ripped CDs for you, the need to actually type a filename in yourself is often very small. There is, I think, no reason for software not to be able to work out a suitable label for you for the majority of data. As we progress, we'll find it far easier to determine suitable names programmatically, instead of asking the user.

The problem is not with the computer naming a file. If the computer has enough knowledge about a file to determine an appropriate way to label it, that's fine. The problem is with the notion that some files shouldn't have a name. That's fundamentally flawed. In addition, if the user doesn't tell the computer to how to name a file, the computer must tell the user where it put it. Otherwise, the user has to hope that the computer indexed it somewhere sensible.

Quote:

HDTV will make emailing and browsing -- even writing quick letters -- using the TV set far more practical too. In fact, HDTV is a key "enabling" technology that should finally kill off the "desktop PC" as we know it. The PC itself won't disappear entirely, I think, but the market will become much more fragmented, with Jack-Of-All-Trades designs replaced by more heavily tailored models geared towards specific markets, such as video editing, music composition and sequencing, etc.

People have been fortelling the death of the PC for some time. Never seems to happen.

Quote:

Finally: Symbian no longer design user interfaces for their OS. It's entirely GUI-agnostic. So there's no reason why it couldn't be licenced by a benevolent Foundation or Trust for the purposes of open research projects.

Symbian doesn't appear to be free software. That means that the free software community is not free to extend Symbian with the many features Symbian lacks.

Quote:

I don't understand where people get this fixation that Linux is a required ingredient in all future research and development work by OSS and FSF teams.

I don't understand where you get this fixation that people think this.

Quote:

It can be used as a jumping-off point, certainly, but it's not _required_ and I contend that it's not necessarily the best place to start. There's no reason why the R&D platform _has_ to be an Open Source one, other than politics.

Erm. Yes there is. There is a very good reason why the primary platform of a free software environment should itself free software.

Quote:

I disagree, but because Linux isn't the only choice out there. It's perfectly legitimate and feasible to develop Open Source and Free Software on other platforms, such as Windows, Symbian, BeOS or even PalmOS. Symbian emulators and SDKs are available for free download. Ditto for Windows and other platforms. Why does it _have_ to be Linux?

It doesn't, now does it? It would appear you are blissfully unaware of that the fact that most Open Source software happily runs on non-Linux platforms. To pick one example, KDE runs on FreeBSD -- it even runs on Windows.

Quote:

Quote: Nonsense. Pipes work. Unix is more than pipes. Pipes are not the most appropriate metaphor for all kinds of interprocess communication. But they are ideal for representing a stream processing task which can be expressed as several discrete stream processing subtasks. Such tasks are still very common. They do have their uses, but they're very confusing for non-experts. A filter-graph system strikes me as more flexible and better suited to a GUI environment and might even be a good fit for a Linux-based project given the underlying architecture. You could even use it as a high-level, component-based programming environment if you designed it right.

That would be silly, but a filter graph would be both useful and easy for those used to pipes to understand.

Quote:

Quote: Quote: Step One: Change of Leadership. No, doofus. It's produced an operating system which is partly vaguely like an archaic operating system. If it's a clone, it's a shockingly bad one. I've used many flavours of "Unix" (and I appreciate that there is no "standard" Unix any more), but I cannot, in all honesty, spot any objective difference between, say, BSD Unix, AIX and Linux in terms of interface and behaviour.

In the case of BSD and Linux, that's because they're virtually the same operating system, except for the kernel. Everything above the kernel is, for the most part, the same GNU environment.

And there is very much a standard Unix.

Quote:

GNU/Linux is far more similar to the various *nix flavours out there than Apple's OS X is to, say, Microsoft Windows XP. That Linux has been the victim of feature-creep like every other OS does not prevent it from being, fundamentally, a very close relative of all the other "Unix-like" operating systems out there.

Linux is a victim of feature-creep? I suppose Windows XP is lean and mean? Nonetheless, I never said Linux wasn't like other operating systems that bare a vague resemblance to the ancient UNIX -- I just said that Linux wasn't like the ancient UNIX. And that's true -- all of the UNIX-decendants are vastly different from UNIX.

Quote:

If you disagree with my view, I have no quarrel with that; I've never cared for CLI-focused operating systems and have stayed away from them as much as possible for the better part of 20 years. Even those few systems I've used that _did_ have text-based GUIs were machines like the ZX Spectrum, for which the CLI was, in fact, a full-on BASIC intepreter.

And? My shell's CLI is a Real Programming Language as well.

Quote:

I dug my old STFM out of the attic recently and found that it actually made me notice how 'click-happy' both MacOS and Windows are by comparison. I wonder if there's a reason why "drop-down" lost out to "pull-down" menus.)

I'd suggest it's because users find it difficult to remember to keep the mouse button pressed when using a menu. I've seen people be completely unable to resist the urge to click. Teaching them how to drag icons around is taxing.

Quote:

I've said this before and I'm getting tired of repeating myself: LOOK AROUND YOU. User interfaces are *EVERYWHERE*, not just on computers!

Are you sure you've said that before?

Quote:

You want an example of a good GUI that doesn't follow the traditional "desktop" metaphor? Look at your mobile phone.

It doesn't have what I'd call a good GUI. I can't even customize it. I want to be able to start writing a text message with one button press.

Quote:

Look at Opera, which _invented_ the much-vaunted tabbed browsing *AND* the mouse gestures used in the Mozilla/Firefox browsers. (And Opera, I might add, also runs on my netBook, my mobile phone and, yes, even Linux.) You cannot claim a product is "great" merely because it apes features that already existed in other browsers.

Of course you can, idiot. The mere fact that tabbed browsing was first introduced in Opera (which I suspect is not the case -- I'll lay odds somebody made a tabbed browser decades ago. Probably at XEROX Parc.) does not mean that Firefox is shit because because it copies that feature. You could say it wasn't innovative, but not being innovative doesn't stop something being great. My house has a roof, which isn't a great innovation, but is great at keeping the rain out.

Quote:

Er, yes it is. By their own website's assertion, their primary aim is to, and I quote (again): "The GNU Project was launched in 1984 to develop a complete UNIX style operating system..." That operating system exists, and has done so for some time now. It is called "GNU/Linux". I believe some people here may have heard of it.

If you're going to quote from their website about the GNU operating system, try reading the parts about the GNU operating system. The kernel of the GNU operating system is Hurd which, as some people here may be aware of, is not complete.

Quote:

It's a copy of an operating system designed _by_ programmers, _for_ programmers. FSF and OSS are so blatantly programmer-centric that it's amazing anyone believes otherwise, yet you'd imagine that, over the intervening 20-odd years, we might have seen a few actual advances in programming techniques from these people. But no. Which brings me back to my original point: GNU is over.

Yawn.

Quote:

See how twitchy you guys are about Linux though? This is my point exactly. I'll repeat this once more: I am NOT advocating just terminating all further development of Linux. I AM advocating that it should cease to be The Big Wahoonie of Software Libre.

Me? Twitchy about Linux? You're the one equating Free Software with Linux.

Quote:

Hey, I'm just offering some constructive criticism

No you're not. You're offering criticism. Nothing constructive about it. You're not offering any suggestions as to how GNU/Linux could be improved. That would be constructive criticism of GNU/Linux. "OSS is bad and wrong, all OSS programmers are arrogant and don't give a fuck about anyway but themselves, the OSS communitity should abandon Linux and start using Symbian, a closed source operating system" is hardly constructive criticism for OSS as a whole.

Quote:

I couldn't personally give a flying fuck whether OSS and the FSF actually live or die. In fact, I consider them lost causes already and of marginal irrelevance to the future of computing in general at best.

So why not shut the fuck up about it already? You don't give the impression of being someone who doesn't care about OSS and considers them to be of "marginal irrelevance" (which, I note, actually means that they are not irrelevant at all).

Quote:

My personal opinion is that most of the people who promote Open Source are basically just doing it because they love programming. They don't give a shit about anything other than the code. "Open Source" as a philosophy actually reinforces this and appears to condone it. I consider it a flawed philosophy as it tends to result in people who care only for the code; the elegance of the code; the quality of the code; the 'purity' of their algorithms... but who couldn't give a damn about whether anyone other than another programmer actually *uses* their code.

OMG! Programmers who love programming! Programmers who write programs that they want to use! Why is that flawed?

Quote:

And freely given too.

Oh, the irony. You're a funny man. Not.

Slightly askew here but I saw this...

"I'll lay odds somebody made a tabbed browser decades ago. Probably at XEROX Parc.)"

and just had to remark that you are SO right. I laugh every time someone starts thumping around about how Opera and Mozilla are so great because they have this awesome "new" feature of tabbed browsing. It's not new at all, I was using a tabbed browser back in '94 or '95 with an ISP called Global Net or some such (hell it was a long time ago) it was this great little app that handled both browsing and usenet as well, with multiple tabs along the bottom....too bad they got bought out by AOL and were never seen again :(

I suppose I should come up with a point here besides a random reflection of days gone by. I guess we COULD say that there is very little that is truly new or innovative anymore, usually somebody has already done it before...but im tired and thats probably a bogus statement....

Anyhow...sorry for the interruption, you may now resume your regularly scheduled argument :)

Hm, I understand the relational database concepts (I hope), which is that files should be catagorised by their content, and should be cross-referenced with other files with similar attributes, etc. It should be on a "flat" filesystem, which I assume is roughly equivalent to one (1) directory. If that's true, then using a file manager/picker like Explorer would be stupid, because you can't do anything meaningful with 32,000 files in your view. Therefore, there must be a new way of choosing files. First, there's the Most Recently Used list, yes. But what if you want to access a very ancient file? Since it's on a flat database, and there's no need for filenames, you can either: 1) reference it via it's GUID/IDODE (I'm assuming an INODe is a numerical identifier of a data entry/file) - which is particular stupid. I don't want to immediately open my very_important_passwords.txt (ok, there's no filenames, but so what) by invoking file numer 30203984. So there must be the other method: searching. So where does this mentioned "hierarchy within database" come in? I thought hierarchies were banished, except for the organisation of search results (i.e. Readme.html/Warcraft III or Warcraft III/Readme.html"). Also, I'm assuming if there's no filenames, then the file system is going to choose the catagorisation of your files via examiniation of document contents. What if I create random binary data?

What if I create this document:

"aksldjfklajsdklfjklasdjfkljaskld;f"


Or my passwords file:

"389x0fk"

Suppose I want to retrieve my passwords file, because I forgot my password. I can't type in 389x0fk to search, because I forgot it. Searching under passwords is a great idea, but that means other people can see it too. Ok, password files is a bad idea, but it serves my purpose.

According to my understand of it (which is probably wrong), this file system will "force" the user into a very rigid way of computing, because he doesn't have that much control of file creation and placement, except for providing any "keywords" (but then the user can't keyword EVERY single file, what system does that?)

If I write a map editor for my game, do I have to explicitly give my map file keywords in my game?

oluseyifs_givekeywords(file,3,"Quake XVII","Maps","Level 20");
oluseyifs_writefile(file);

Thanks,

Cipher3D

Quote:

Original post by Arakiel I suppose I should come up with a point here besides a random reflection of days gone by. I guess we COULD say that there is very little that is truly new or innovative anymore, usually somebody has already done it before...but im tired and thats probably a bogus statement....

Perhaps the point is that there are no new ideas. The only innovation that is possible in computing is bringing together old ideas in new ways.

Even then, it's not a matter of just using a couple of Big Ideas.
Relational database filesystems have already been done. Indeed, a quick google turns up MySQLFS -- a MySQL filesystem for Linux, no less. Since MySQL isn't in the kernel, this isn't an option for the root filesystem but then you don't usually need advanced indexing capability for that; shared documentation and personal files are what you want indexing for and they don't have to be mounted until a user logs in.

Of course, this is rather primitive stuff. A truly innovative filesystem would need to mix together searching and indexing facilities, useful version control, transparent handling of remote files (or even remote versions of files), files with structure at the filesystem level, and many other ideas I haven't had yet.

Quote:

Original post by Cipher3D Hm, I understand the relational database concepts (I hope), which is that files should be catagorised by their content, and should be cross-referenced with other files with similar attributes, etc. It should be on a "flat" filesystem, which I assume is roughly equivalent to one (1) directory.

No, it wouldn't be like that. The filesystem is divided into categories. It is those categories that the user interacts with. Under the hood, it's possible that all files would be stored in one big directory. However, it's important to realise that this never matters to the user, or the programs that the user runs. So far as the user is concerned, the filesystem is highly structured.

Quote:

If that's true, then using a file manager/picker like Explorer would be stupid, because you can't do anything meaningful with 32,000 files in your view.

Well, you could choose the "All Files" category and see how many files you have. But what you'd usually do with the Explorer-like tool is to browse and manipulate the categories.

Quote:

Therefore, there must be a new way of choosing files. First, there's the Most Recently Used list, yes. But what if you want to access a very ancient file? Since it's on a flat database, and there's no need for filenames, you can either: 1) reference it via it's GUID/IDODE (I'm assuming an INODe is a numerical identifier of a data entry/file) - which is particular stupid. I don't want to immediately open my very_important_passwords.txt (ok, there's no filenames, but so what) by invoking file numer 30203984.

Of course there would be filenames. Suppose the password file has a password set on it which you must type in before being able to read it, even though you own the file. That means the browser can't display a thumbnail without asking you for the password, and that would be a headache if you had more than a couple of protected files in a particular category. So if the browser isn't displaying thumbnails, how can you tell your list of passwords from a Top Secret email? You need to be able to name files. But, you don't need to name all of them. Sometimes, a file may need no name, or the system may be able to give it a sensible name.

In addition, inode numbers can be more transient than filenames, although sometimes they aren't. When saving, some programs rename the existing file to a backup file and put the saved data in a new file. The old inode would still refer to the old version of the file, and, when the file was saved again and the backup replaced, to a file that doesn't exist any more. When converting a file from one format to another, a new inode is almost certain to be used. If the conversion removes the old file, then you're stuck with a deleted inode -- an inode that might be used again by the filesystem the next time a file is created. So a program that references a file by inode number might end up reading from an entirely unrelated file.

Quote:

So there must be the other method: searching. So where does this mentioned "hierarchy within database" come in? I thought hierarchies were banished, except for the organisation of search results (i.e. Readme.html/Warcraft III or Warcraft III/Readme.html").

Nah. The hierarchy would be a hierarchy of categories. You may have a "Documentation" category, which would contain "Games" which would contain "Warcraft III". You may also have a "Programs" category which contains "Games" which contains "Warcraft III" which contains "Documentation". "Readme" would be in both categories. It may seem that the file would need a unique path to identify it, but even UNIX doesn't guarantee that -- multiple entirely distinct paths may lead to the same file. To determine if two paths lead to the same file, you compare their inode numbers.

Quote:

Also, I'm assuming if there's no filenames, then the file system is going to choose the catagorisation of your files via examiniation of document contents. What if I create random binary data?

Another obvious flaw in a filename-less system, which is why any such system would have filenames, but they might not be compulsory.

Quote:

Suppose I want to retrieve my passwords file, because I forgot my password. I can't type in 389x0fk to search, because I forgot it.

How do you login to read your passwords file if you've forgotten your password? [wink]

The logical option would be for the system to ask you how to categorise the file (including, possibly, giving it a name) when you've finished with it. It might do that for all files, just files that it can't figure out how to categorise, or any kind of file for which you tell it to ask you.

Quote:

According to my understand of it (which is probably wrong), this file system will "force" the user into a very rigid way of computing, because he doesn't have that much control of file creation and placement, except for providing any "keywords" (but then the user can't keyword EVERY single file, what system does that?)

My problem is how to balance a categorising filesystem with the need for the user to know where a file is. If the user is forced to choose, or at least acknowledge the computer's choice of, the categorisation of a file, then that's alleviated to some extent. But the user must certainly always be able to manually move a file into a particular folder, and must be able to set up a traditional hierarchical folder system where names are required.

That would be important not only for users who are used to filesystems that are like that, but also for exposing files to other computers via non-DBFS network filesystems. Although the DBFS could maintain an exportable hierarchical filesystem under the hood, it's easier all around if the user can directly interact with the same filesystem that his workmate will be interacting with via file sharing.

Quote:

If I write a map editor for my game, do I have to explicitly give my map file keywords in my game? oluseyifs_givekeywords(file,3,"Quake XVII","Maps","Level 20"); oluseyifs_writefile(file);

That would be good practice, anyway. But the file save dialog should allow the user to specify additional keywords (and view and remove or change keywords provided by the system).

Most importantly, perhaps, is that you don't need sophisticated indexing and searching capability for the standard maps that come with your game -- you already know what and where they are. It would be safe to just store them without keywords in a traditional hierarchical form. Custom maps are a different matter -- they should have all manner of attributes set on them that allow a user to find just the map he wants. Of course, these attributes would be set by the map designer when he makes the map -- your editor wouldn't be expected to figure out whether or not a map was suited to deathmatch or teamplay, for example.

---

Oluseyi implied a while back that filename extensions were necessary. I don't know if he was just meant that they were necessary on traditional filesystems, or if he felt they would be needed on future filesystems. Edit: A reread of the earlier post makes it quite clear that Oluseyi does not approve of enforced extension-based file typing. On UNIX, one can often get away with not using extensions. Many systems use context-dependant mechanisms to determine file types. I know KDE's file manager can flag an extensionless C++ file as a C++ file by examining its contents. Of course, this isn't perfect, and some explicit mechanism for associating a file with information about what type of data it contains is essential.

I'm not sure that extensions are the best way to go about this. Internet Explorer has a habit of messing up extensions of downloaded files from time to time. On Linux, I've often downloaded a .tar.gz file to find it's not actually compressed, or a .ps file to find it is compressed.

Extensions are nice, when they're accurate, because it means that whenever you see the name of a file, you also see the type of data it contains. Since the type of a file is probably the most important metadata you need, that's very useful. But why do we need to know the type of the file?

Traditionally, the filetype has told us which program we need to use to open the file. But modern operating systems don't require that a user manually invokes a program on a particular file -- they allow a user to say "open this file" (or "print this file" or "email this file" or whatever) and it picks the right program for the job.

In olden times, the difference between "Yearly Report.spreadsheet" and "Yearly Report.textdocument" was important to the user That's no longer the case. What's important now is only "Yearly Report".

Another advantage of dropping extensions, aside from shielding the user from information that isn't that relevant to him, is that it allows the system to transparently change the type of a file. For example, a text/plain file might be changed into a text/enriched file when formatting is applied. Without extensions, the name of the file hasn't changed -- the user won't get confused, and other programs that refer to the file by name won't get confused.

An obvious disadvantage is that other systems usually expect filename extensions, so files shared on the web or a network filesystem would need to have (or pretend to have) a suitable filename extension.

Something that looks like a disadvantage at first is that searching for files of a particular type is no longer as trivial as searching for "*.jpg" but then that was never satisfactory in the first place. Not only does that not locate other image formats, it doesn't even locate files which end in .jpeg, which are obviously JPEG files as well (or they should be, with that name). In UNIX, one could search for "*.{jpg,jpeg,gif,png,bmp}", but that's not particularly discoverable, and relies upon the user knowing that those are the only types of image files he has.

I see. So if you open the DBFS (or OluseyiFS) file manager, you would see "folders," which correspond to "categories." But what if you have a a complex categories hierarchy? What happens to the "no file is more than two steps away from the current one."

Ciph

Quote:

Original post by Oluseyi Quote: Original post by seanw I'm not nitpicking over semantics, I'm trying to say that saying all OSS have bad interfaces is a stupid statement to make. Nobody made that statement. Nobody said that "All OSS, categorically and without exception, have bad interfaces." Which was my point. You're getting agitated over nothing, largely because you feel that it offends your sensibilities. Whatever. Generalizations are a useful mechanism for examining aggregate or average behavior across a substantial sample of individuals. If you can't process that, your opinion is less than worthless. Yes, I have a habit of being rude. To idiots. Isn't that the OSS way?

You're implying I'm an idiot because you don't agree with the opinion of one of my replies? I honestly cannot understand why people tolerate you here based on my perception of your average behaviour across a substantial sample of your posts.