This came up in the General mailing list of the Fribourg (Switzerland) Linuxbourg user group, and I thought it would be interesting as food for thought and debates in /. Em Sáb, 2003-10-04 às 18:46, Robert Ribnitz escreveu: > Quoting Florian Verdet _goto : > >> Mais ce Ke je me demande est pourKoi ce n'était pas repris dans >> EXT* ? / Pourquoi "GNU/Linux" n'a pas pris un autre type de fs (ac >> N°s de versions) par defaut... > > I don't think we need to belittle the user. He/She knows what they > are doing. For the question of versioning files, I don't think its > that important. Else why is it not in the Various unix-versions, but > only in closed systems like VMS? This is reasoning from authority, and this is never a good thing, being a logical fallacy. Google around for _Worse is Better_ or something the like, an essay about why Unix has succeeded instead of Lisp. Yes, you can run Lisp on a Unix system, but True Hackers want a fully Lisp machine, and that's where RMS comes from. The nice thing about Unix is that is as simple as possible, shifting all non-essential complexities out of the kernel into userland and if possible out of the OS into applications. Thus lots of hardcoded decisions -- like GUI widgets, window managers, network protocols, filesystems, versioning control -- that were in older systems (and yes, conceptually speaking MS WNT *is* older than Unix, because its design by accretion took lots of pre-Unix elements) hardcoded are optional, exchangeable modules or applications in Unix. On one hand this simplicity enables non-essential functionality to evolve without requiring the whole OS and legacy applications to change, and new ideas to be tried at will until something sufficiently good gets popular enough to be standardised either de facto or de jure. Thus, RCS evolved into CVS that evolved into Ægis and similar stuff, while MIT ITS has fallen by the wayside, VMS is dying, MVS isn't going anywhere and WNT is just desperately trying to keep up with Unix while all the time becoming more and more bloated -- technologically speaking, because the marketshare situation is the inverse as you all well know due to Moore's 'Law', network effects, herd behaviour, proprietary lock-in, lack of standardisation and plain misinformation. Now, on the other hand, even after these subsystems evolve almost to death, Unix has a defect of almost never incorporating them, because people tend to disagree about what's best. Thus we are still stuck at the GUI wars with X wannabes born more or less every other year, RCS or SCCS aren't still to be taken for warranted, and so on. It is not only that these are optional modules that can be omitted in an embedded system as X itself has happily enough became (true BTW), or that they are kept out at userland to keep the kernel simple (also true), or that we don't want decisions to be forced on us (obvious), but that "we" -- as in the users and developers community -- haven't made our minds yet,and perhaps never will. All this to explain why there aren't plans to a versioned ext4fs. Now to the hard thing, explaining why there shouldn't be. The whole idea of versioning is but an interface to underlying, possibly richer, functionality. There could be a versioning API as an extension of the I/O API in Unix -- or GNU -- as a transition, but implementing it as an end goal, and particularly as a hierarchical filesystem feature would be a hugely expensive mistake. The way to go is to treat files as data, and data must be organised relationally, simply because there isn't any other model to organise data besides the relational and graph (networks, hierarchies) ones, and despite all the XMLDB and OODB hype they are just resurrecting the graphs -- and these have already been proved too complex and not enough powerful -- besides corrupting their theoretical foundations, much as SQL is to the relational model. Now this is controversial, as most people think at physical instead of at the logical levels and thus don't see that hierarchies are a physical assumption that user and applications don't need at all, and a legacy from pre-Codd times that has long lived its usefulness. Yes, there is data which is hierarchical in nature, but filesystems aren't; and yes, there are people who really want to organise their files hierarchically, but there isn't any good reason why this hierarchy can't be just a UI layer over a relational database, without blocking access to relational features. Obviously the tough thing, besides user and developer education, is to agree on a minimum specific, normalised data model that would eventually end up in POSIX or whatever. But there is no reason why this can't bedone, once there are enough educated users and developers to claim for it and criticise bogus proposals that are sure to sprout around like mushrooms. Given the current decadence of our civilisation in general and IT in particular, and that there isn't an alternative in view besides barbarism and a new Dark Age (besides the Second Coming, but I digress, as usual), Gartner-like I give this a 0.01 probability. This 0.01 is the possibility that some hackers grok this, that Duro or Opus actually succeed or Alphora Dataphor becomes Free, that they get implemented in the GNU/Hurd and that the Hurd actually succeeds Linux. Tough call indeed. Or else Gnome Storage succeeds, but it is not a clean system at all, not being quite relational. And by the way, but now I am definitely provoking, this is the reason why I am unemployed and going back to my home country, besides my permis B contingenté and some CV shortcomings which I blush to mention, ofcourse. Flames, especially personal ones, to /dev/null, sound debates welcome, recommended reading http://dmoz.org./Computers/Software/Databases/Relational/ and Codd, Date, Darwen, Pascal and McGoveran books and web pages such as http://dbdebunk.com/ and http://www.thethirdmanifesto.com/.