linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cus.cam.ac.uk>
To: Hans Reiser <reiser@namesys.com>
Cc: Nathan Scott <nathans@sgi.com>,
	Andreas Gruenbacher <ag@bestbits.at>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@oss.sgi.com
Subject: Re: reiser4 (was Re: [PATCH] Revised extended attributes  interface)
Date: Wed, 12 Dec 2001 02:16:18 +0000 (GMT)	[thread overview]
Message-ID: <Pine.SOL.3.96.1011212015827.2712B-100000@draco.cus.cam.ac.uk> (raw)
In-Reply-To: <3C169DCD.8060806@namesys.com>

On Wed, 12 Dec 2001, Hans Reiser wrote:
> Anton Altaparmakov wrote:
> >I was just stating a fact of how they are stored on NTFS, again something
> >I have no power to change.
> >
> But does NTFS specificism/cripplism belong in VFS?

No, of course not. But the vfs needs to be able to cope with limitations
of specific file systems (even if it is only by passing -Exyz into
userspace).

> >>Well, gosh, okay, maybe you want to prepend ',,' to streams and '..' to 
> >>extended attributes.  I personally think Linux would only want to do so 
> >>when used as a fileserver emulating NTFS/SAMBA.  There is no enhancement 
> >>of user functionality from doing it for general purpose filesystems. 
> >
> >Just wait until this functionality is available and watch all GUI things
> >start to use it en masse! I don't doubt that GNOME/KDE/replace with your
> >favourite window manager are going to hesitate to start putting in the
> >icon, the name, and whatnot inside EAs or inside named streams the instant
> >they are ubiquitously available and I think that makes a lot of sense too.
> >No doubt I will get flamed for saying this but all flames go to
> >/dev/null...
> >
> >Both MacOS and as of recently Windows do this kind of stuff, too, and it
> >can't be long before Linux goes the same way, provided file systems
> >support the required features (i.e. EAs and/or named streams) so I
> >disagree with you this is only a compatibility thing. It might start out
> >as one but it will find real world applications very quickly...
> >
> I am not saying that the features of EAs are not useful, I am saying 
> that I want to choose them individually for particular files.
> 
> It could be so much better to have EDIBLE_PIZZA (example from previous 
> email) instead of just PIZZA, sigh.

I am not quite sure what you mean. Surely you can just have all features
available at all times/to all files and then you just use the ones you
want, just ignoring/not using the rest. Why do you see the need for
"selecting features of EAs individually for particular files"? It makes
sense when buying EDIBLE_PIZZA but I don't see how that can be transferred
onto files. After all I can just have all pizza ingredients and only put
the ones I want on the pizza just ignoring the others.

Um, I think we might be saying the same thing in different words...

> >>Programs will get written to use your API, and not work with reiserfs, 
> >>and will get written to use our API and not work with NTFS, and this is 
> >>bad....
> >
> >Now that is true. And yes, it is bad. However it will be up to the
> >community to decide which API to use and at the moment there are several
> >fs using the "bestbits" API and only reiserfs (?) the "reiserfs" one...
> >And we all know from our very own $Deity that we don't design software, we
> >just write things and let evolution decide which is better. (((-;
> >
> Fortunately he isn't entirely consistent on this point.:-)
> 
> I predict you guys will ship first and get a lot of usage, and then we 
> will ship later with more features,
> and the result will be a mess for users.  This is the usual evolutionary 
> design standards mess.  

Yes, your prediction will likely hold true IMO.

> Objectively, I understand it is highly reasonable for the Linux 
> community to assume that what we
> implement will be horrible until we finish it.  I would encourage it to 
> assume that someone else
> will eventually get orthogonalism right though, and I think it would be 
> worth waiting for it, because
> these are the sorts of design features that stick around for 30 years. 
>  I don't really expect that most folks will choose to wait though.

Me neither. People want it now, which pretty much limits the choice to
one of the things available and working now, plus some required cleanups
to satisfy all $Deities so the solution can be accepted in the kernel...

The one who comes first gets to populate the vacuum. Evolution at its
best. (-:

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/



  reply	other threads:[~2001-12-12  2:16 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05  3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-05  9:08 ` Anton Altaparmakov
2001-12-06  5:46   ` Nathan Scott
2001-12-06  3:05 ` Daniel Phillips
2001-12-06  5:41   ` Nathan Scott
2001-12-06 15:25     ` Daniel Phillips
2001-12-06 23:15       ` Nathan Scott
2001-12-07  1:45         ` Daniel Phillips
2001-12-07  2:03         ` Daniel Phillips
2001-12-07  3:51           ` Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08  4:58   ` Nathan Scott
2001-12-08 20:17     ` Hans Reiser
2001-12-11  2:42       ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 12:02         ` Hans Reiser
2001-12-11 19:23         ` Anton Altaparmakov
2001-12-11 20:14           ` reiser4 (was Re: [PATCH] Revised extended attributesinterface) curtis
2001-12-11 21:34             ` Hans Reiser
2001-12-11 23:04               ` curtis
2001-12-11 23:28                 ` Hans Reiser
2001-12-11 23:46                   ` Anton Altaparmakov
2001-12-12  1:00                   ` curtis
2001-12-11 21:21           ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-11 23:33             ` Anton Altaparmakov
2001-12-11 23:59               ` Hans Reiser
2001-12-12  2:16                 ` Anton Altaparmakov [this message]
2001-12-12 12:02                   ` Hans Reiser
2001-12-12 13:34                   ` Anton Altaparmakov
2001-12-12 15:40                     ` Hans Reiser
2001-12-13  1:43             ` Andrew Pimlott
2001-12-13  9:23               ` Hans Reiser
2001-12-13 10:36                 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37                   ` Ragnar Kjørstad
2001-12-13 16:06                     ` Romano Giannetti
2001-12-13 18:58                       ` Ragnar Kjørstad
2001-12-18  0:17                     ` Pavel Machek
2001-12-13 23:24                   ` David Wagner
2001-12-21 21:28                   ` Andreas Ferber
2001-12-13 15:27                 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Andrew Pimlott
2001-12-13 20:47                   ` Hans Reiser
2001-12-13 21:01               ` Anton Altaparmakov
2001-12-10 11:52     ` [PATCH] Revised extended attributes interface Stephen C. Tweedie
2001-12-10 15:00       ` Peter J. Braam
2001-12-10 15:56         ` Stephen C. Tweedie
2001-12-10 16:00           ` Mr. James W. Laferriere
2001-12-10 16:15             ` Stephen C. Tweedie
2001-12-10 19:01           ` John Stoffel
2001-12-11  1:22       ` Timothy Shimmin
2001-12-11 11:33         ` Stephen C. Tweedie
2001-12-11 15:15           ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11  1:41       ` Nathan Scott
2001-12-11 13:47         ` Stephen C. Tweedie
2001-12-11 18:23           ` Hans Reiser
2001-12-11 18:46           ` Anton Altaparmakov
2001-12-11 23:37           ` Implementing POSIX ACLs - was " Nathan Scott
2001-12-11 13:30       ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34         ` Stephen C. Tweedie
     [not found] <20011214051604.723C52B54A@marcus.pants.nu>
2001-12-14 11:10 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-14 15:06   ` dmeyer
2001-12-14 21:23     ` Bernd Eckenfels
2001-12-14 18:27   ` Brad Boyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.3.96.1011212015827.2712B-100000@draco.cus.cam.ac.uk \
    --to=aia21@cus.cam.ac.uk \
    --cc=ag@bestbits.at \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=nathans@sgi.com \
    --cc=reiser@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).