From mboxrd@z Thu Jan 1 00:00:00 1970 From: Horst von Brand Subject: Re: silent semantic changes with reiser4 Date: Sat, 28 Aug 2004 20:04:13 -0400 Message-ID: <200408290004.i7T04DEO003646@localhost.localdomain> References: Cc: Linus Torvalds , Diego Calleja , jamie@shareable.org, christophe@saout.de, vda@port.imtp.ilyichevsk.odessa.ua, christer@weinigel.se, spam@tnonline.net, akpm@osdl.org, wichert@wiggy.net, jra@samba.org, reiser@namesys.com, hch@lst.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, flx@namesys.com, reiserfs-list@namesys.com Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com To: Rik van Riel In-Reply-To: Message from Rik van Riel of "Thu, 26 Aug 2004 16:10:48 -0400." List-Id: linux-fsdevel.vger.kernel.org Rik van Riel said: > On Thu, 26 Aug 2004, Linus Torvalds wrote: > > So "/tmp/bash" is _not_ two different things. It is _one_ entity, that > > contains both a standard data stream (the "file" part) _and_ pointers to > > other named streams (the "directory" part). > Thinking about it some more, how would file managers and > file chosers handle this situation ? > > Currently the user browses the directory tree and when > the user clicks on something, one of the following > happens: > > 1) if it is a directory, the file manager/choser changes > into that directory > > 2) if it is a file, the file is opened And now you have a mess. Is it "really" a file, or a directory? Why not just keep both well apart, and stay happy? I just fail to see what could be gained by having directories that really aren't, and files that aren't either. Use a directory if you want one, use a file elsewhere. > Now how do we present things to users ? > > How will users know when an object can only be chdired > into, or only be opened ? Easy: It is a directory, or it isn't. > For objects that do both, how does the user choose ? Don't give silly choices. > Do we really want to have a file paradigm that's different > from the other OSes out there ? I vote "no". There are/have been OSes with weird "files", none of them survived to get anywhere as popular as Unix and "file == stream of bytes". Even with much simpler variants like files as sequences of records. For a good reason: The Unix way is simple, and extremely flexible, as my proggie can define at its own whim how to handle what's inside. If a single stream isn't enough, we have directories. No need to innovate there. > What happens when users want to transfer data from Linux > to another system ? Or between Linux systems with different kernels that happen to implement different views/metadata on files. Please do remember devfs: It sounded like a cool idea, got into the kernel just to be thrown out later because nobody used it. Much heat was generated, nothing of permanent value. This looks the same: A very vocal tiny minority is clamoring for something completely non-Unix for totally bogus reasons. What happened to "code talks, bullshit walks"? There is _no_ code (== real-world, user programs that can't be done efficiently enough without this), so this nonsense should just be thrown out, and everybody go back to real hacking. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513