Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 May 2003 06:25:35 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h4RDPI2x030389 for ; Tue, 27 May 2003 06:25:19 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GZVMLXKR; Tue, 27 May 2003 09:25:43 -0400 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h4RDOGfj016734; Tue, 27 May 2003 09:24:16 -0400 Message-ID: <3ED36700.4050804@wgate.com> Date: Tue, 27 May 2003 09:24:16 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: linux-xfs@oss.sgi.com Subject: Re: Tomorrow References: <1053694002.2887.1.camel@localhost.localdomain> <1053697162.21472.51.camel@jen.americas.sgi.com> <20030523134438.GC30288@wotan.suse.de> <20030523150530.A31022@infradead.org> <20030524071709.GK27626@plato.local.lan> <20030524095245.A24074@infradead.org> <20030524091516.GM27626@plato.local.lan> <20030524093103.GA12181@wotan.suse.de> <3ED344C0.1010700@wgate.com> <20030527120650.GA22306@wotan.suse.de> In-Reply-To: <20030527120650.GA22306@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1353 Lines: 31 Andi Kleen wrote: [...] > Yes there is: Unicode/UTF-8. That is where all the Linux distributions are > going too. For legacy SMB support you will still need to support codepages, > but that could be done by samba. For XFS I guess it would be enough to just > support UTF-8. Supporting different code pages is probably not too useful > anymore. I would agree that a single standard is the best thing to do. Also, I fully understand why this has to be in the filesystem in order to produce a reasonable performance result. Too bad this also means that any hashing has to be redone. Also, too bad the volume needs to be mounted as one way or the other... I used to be a case-insensitive fan for any user-interface items. I still thing that the average user does not care about case in most cases other than for visual aesthetics. Preserving case is important. However, after having worked on the technical issues when you go international (and back in the day where 16meg of RAM was a HUGE amount and most had less than 1meg) BTW - I still remember when the first C++/C-front stuff was suggesting that the C++ files be named "file.C" vs "file.c" for regular C code. What a mess! -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others.