Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5178 ; Tue, 22 Dec 92 08:00:53 EST Xref: sserve comp.unix.bsd:9164 comp.os.linux:19862 Newsgroups: comp.unix.bsd,comp.os.linux Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST) Message-ID: <1992Dec19.083137.4400@fcom.cc.utah.edu> Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <id.M2XV.VTA@ferranti.com> <1992Dec18.043033.14254@midway.uchicago.edu> <1992Dec18.212323.26882@netcom.com> Date: Sat, 19 Dec 92 08:31:37 GMT Lines: 95 In article <1992Dec18.212323.26882@netcom.com> messina@netcom.com (Tony Porczyk) writes: >goer@kimbark.uchicago.edu (Richard L. Goerwitz) writes: > >>>> Has anyone in this newsgroup ever heard of the Unicode/ISO10646 >>>> (UCS) standard? >>> >>>You know, if 386BSD could be made to support NET-UTF (the Plan 9 version >>>of the 10646 standard) that would be a major advantage over commercial >>>Unices... > >>One of the big criticism leveled at US Engineers is that they are either >>too dumb or lazy to build into their software support for non-Western >>scripts. Given that Linux originates in Europe, can we look forward to >>better support for Unicode and ISO10646? At least for "long" charac- >>ter definitions? > >Yeah, that's probably why NT supports Unicode, it's those dumb US >Engineers... Could we lay off idiotic generalizations and stick to >technical aspects of the software? It's business that dictates what's >included in the package. If it makes economic sense, it will be there. >Most of the internationalization is done locally anyway, so it has >nothing to do with dumb engineers. 1) You have a good point about US Engineer bashing. 2) "Internationalization done locally" is called localization. 3) I---------------------------- Bitnet: UNM409@DBNRHRZ1 Volker A. Brandt UUCP: ...!unido!DBNRHRZ1.bitnet!unm409 Angewandte Mathematik Internet: volker@sfb256.iam.uni-bonn.de (Bonn, Germany) From tessier@bnr.ca (Daniel Tessier) 724988675 Xref: sserve comp.unix.pc-clone.32bit:758 comp.unix.sysv386:26394 comp.unix.bsd:9064 comp.os.linux:19547 Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!torn!nott!bnrgate!bmerh85!bnr.ca!tessier From: tessier@bnr.ca (Daniel Tessier) Subject: Re: ET4000/W32 and VESA VL-Bus Message-ID: <1992Dec16.191911.9003@bmerh85.bnr.ca> Sender: news@bmerh85.bnr.ca (Usenet News) Reply-To: Daniel.Tessier@bnr.ca Organization: BNR Ottawa, Fibre Systems Development References: <BzBEI1.CH@aeon.in-berlin.de> <1992Dec16.155355.7416@netcom.com> Date: Wed, 16 Dec 92 19:19:11 GMT Lines: 41 In article <1992Dec16.155355.7416@netcom.com>, hasty@netcom.com (Amancio Hasty Jr) writes: |> In article <BzBEI1.CH@aeon.in-berlin.de> thomas@aeon.in-berlin.de (Thomas Wolfram) writes: |> >Hi, |> >does anyone already using the new ET4000/W32 chip, perhaps in an |> >VESA VL local bus version? How is the performance compared with |> >ET4000AX and does it work with XFree86 1.1? |> > |> >Thank you, |> >Thomas |> >-- |> >Thomas Wolfram, thomas@aeon.in-berlin.de |> >EANTC, TU Berlin, wolf@prz.tu-berlin.de, +49 030 31421294 |> |> S3 is faster than the et4000 based technology the reason is because |> of the server and its use of hardware assisted graphics functions. |> We are about 6 times faster than an ISA et4000. In fact, it is more |> accurate to say that XS3 can compete against your typical workstations |> such as suns workstations. Typically an S3 801 costs less than $220(US). |> XS3 is our X server for S3 chipsets and it runs on 386bsd and Linux. |> |> XS3 has been clocked at 64k xstones onn terms of "economic sense", one wonders why Unicode and ISO10646, basically Western standards, are being applied to Far East languages like Japanese, Chinese, and Korean, when the XPG4 standard, using JIS (an existing Far Eastern standard) as a subset, is being ignored by NT? To deal with the points in order: US Engineers produce software for the available market; because of the input difficulties involved in 6000+ glyph sets of symbols, there has been a marked lack of standardization in Japanese hardware and software. This means that the market in Japan consists of mostly "niche" markets, rather than being a commodity market. This has changed somewhat with the Nintendo corporations recent successes in Japan, where standardized hardware is being used in most homes; this is probably an indicator of where the Japanese market is heading. Still, a Nintendo (even with many peripherials not available in the US) is not a workstation. Even here, the use of a custom DMA chip on *each* cartridge instead of *in* the machine, with a patent on it and a stiff licensing fee outside of Japan tend to imply that the Japanese software market will not be open any time soon to volume sales of US originated software. This combines to make most internationalization Europe-centric, and therefore limited to 8-bit clean applications/drivers. It is currently possible to localize anything. Some of the European work (and some very particular "8 bit clean" code done in Greece) have been done for 386BSD. This is called enabling; in particular, enabling for localization. What we want is internationalization of 386BSD; this means providing tools and native (kernel and file system, and in particular, file system name space) support for it. Internationalization goes beyond localization by providing for multinational use without exectable code changes. If we assume booting to X on a VGA (640x480) as a default, and additional setup of the X to support alternate resoloutions