Re: Alpha & pc98 testers wanted
Sheldon Hearn writes: > >Hi folks, > >The following patch to the 5.0-CURRENT sources allows the installkernel >target to install multiple kernels. Given the following in >/etc/make.conf: > > KERNEL= AXL AXLOPT GENERIC > >the installkernel target would install: > > AXL -> /kernel > AXLOPT -> /kernel.AXLOPT > GENERIC -> /kernel.GENERIC > >I've tested this for the i386 and would prefer to have it tested on the >Alpha and pc98 before committing it, although I'm convinced that it >should work on both of those platforms. > [patch deleted] well, it doesn't work for me on the Alpha. It tries to install all the kernels named in KERNEL at once. Here's the output from make: >>> Installing kernel(s) -- ===> alpha as /kernel cd /usr/obj/usr/src/sys/alpha; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/alpha/usr/libexec:/usr/obj/usr/src/alpha/usr/bin LIBRARY_PATH=/usr/obj/usr/src/alpha/usr/lib:/usr/obj/usr/src/alpha/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/alpha/usr/libexec PERL5LIB=/usr/obj/usr/src/alpha/usr/libdata/perl/5.00503 MACHINE=alpha KERNEL=alpha DESTKERNEL=kernel make install [: GENERIC: unexpected operator chflags noschg /kernel mv -f /kernel /kernel.old install -c -m 555 -o root -g wheel -fschg alpha GENERIC /kernel usage: install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... *** Error code 64 Stop in /u1/obj/usr/src/sys/alpha. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I also noticed that there was a GENERIC and alpha in both the kernel compile directories. Somehow that doesn't seem right. Maybe my world is too old. I'm running a buildworld right now. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Alex Belits wrote: > > Anyone who has anything to do with the Internet must deal with UTF-8: > > "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO > > 10646 coded character set combined with the UTF-8 character encoding > > scheme, as defined in [10646] Annex R (published in Amendment 2), for all > > text." > > This is not approved by ANYONE but a bunch of "unificators". It never > was widely discussed, and affected people never had a chance to give any > input. This is the same kind of "standard documents" that ITU issues by > dozens. I don't guess what meaning could be transferred by the quotation marks around standard documents. As far as I know (especially the Q, X and I series), the ITU-T produces quite good standards that are widely, if not globally accepted (just think about V.34 or V.29, V.17, T.30 and so on). Check'em out and try to send a fax. It works globally. Quite astonishing, isn't it? Or, if that isn't sufficient, you may use the same software to connect to X.25 networks all around the world. You can establish modem connections around the world (after Bell labs standards ceased to exist). You can connect the same ISDN equipment virtually everywhere in Europe to the trunk line... If Unicode is equally well accepted, there should be no problem with it. Bye, Titus [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
You, Alex Belits, were spotted writing this on Mon, Apr 03, 2000 at 03:23:42PM -0700: > On Mon, 20 Mar 2000, MikeM wrote: > > > Has anyone thought of Unicode support on FreeBSD? > > Really the question is much more basic -- who benefits from having > Unicode (or Unicode in the form of UTF-8) support. It isn't me for sure > -- I am Russian. So am I, and guess what? I'd really love being able to handle French and Russian together smoothly and transparently. Not to mention Hebrew. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
You, Alex Belits, were spotted writing this on Mon, Apr 03, 2000 at 08:59:51PM -0700: > > >-- I am Russian. > > > > So? > > So I don't want UTF-8 to be forced on me. Noone is trying to force UTF-8 on you. In fact, userland support of UTF-8 can (and should IMHO) be based around an environment variable a-la LANG which would tell programs whether they should expect pure 8-bit text or UTF-8 text. This will give you a pretty easy option to leave things as they are. > Charset definitions in MIME > headers exist for a reason. Yes, and the better mail clients (e.g. mutt) are already able to translate transparently between different equivalent charsets by using internally a common superset -- Unicode. Everyone should be able to use whatever charset they desire. > One of the most basic strengths of Unix is the ease with which text can > be manipulated, and how "non-text" data can be processed using the same > tools without any complex "this is text and this is not" > application-specific procedures. UTF-8 turns "text" into something that > gives us a dilemma -- to redesign everything to treat "text" as the stream > of UTF-8 encoded Unicode (and make it impossible to combine text and > "non-text" without a lot of pain), or to leave tools as they are and deal > with "invalid" output from perfectly valid operations. This is not a dilemma. Just about the only really different aspect of handling UTF-8 text is the algorithm for calculating the number of characters. Most of the existing programs can easily be tailored to treat the byte stream as either pure 8-bit stream or UTF-8 stream based on YOUR preferences. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
At 22:51 03-04-2000 -0700, Alex Belits wrote: > I agree that Unicode created a good list of glyphs, and it can be >useful for fonts and conversion tables, but it's completely inappropriate >as the base of format used in real-life applications for storage and >communications. Oh, I think it's great for communications. I design web sites. It is good to have a single character representation supported by Internet standards. Saves a lot of work. Before UTF-8 became widely accepted, a typical Slovak web page started by a menu of choices of which encoding your browser supported. You had to have 3 - 4 versions of each page. A major pain! Now you only need one. Or even when designing English pages in a typographically correct way (opening and closing quotes, and things like that), it was a pain before UTF-8 because while ISO-8859-1 is the assumed default, Microsoft, in its infinite wisdom created a slight modification of ISO-8859-1 which they called ANSI, and which the uninitiated commonly believed to be the same as ISO-8859-1. As a result, there are a myriad of web pages out there that use the Microsoft encoding, and there are those that use true ISO-8859-1. So many browsers assume that you are using the MS "standard." It's a real mess. So, in all my recent pages I use UTF-8, and the problem is solved. >> Unicode Consortium >> has no power to force Unicode on anyone. It just happens that it was widely >> accepted. > > So far only by one company actually "accepted" it -- Microsoft. Everyone >else (except Java/Sun) just happened to be depended on them. Java and >Plan9 are special cases because both are essentially endless storages of >ivory-tower design idiosyncrasy and arbitrary decisions made by handful of >people. I was not talking about companies. I was talking about people with genuine i18n needs. When I started working on Unicode support for FreeBSD (a work, I unfortunately had to interrupt due to serious health problems), I subscribed to the Unicode mailing list. People on the list come from different backgrounds, mostly Unix actually. The most active ones who make serious proposals to additions to Unicode are Unix people. > I have just asked, who will benefit from it. No one answered "I will" -- >everyone who makes Unicode support believes that it will benefit someone >else. I thought I did. OK, let me restate: I will! I actually do already because I did some work and it is in the ports. > I am not talking about Unicode representations and encodings but about >Unicode itself. I agree that UTF-8 is the only way to marry Unicode with >text and Unix, however I don't see much point in doing that. Well, that's fine. You don't need it. I do. UTF-8 has many nice advantages for a Unix programmer, which is probably why it became so widely accepted. For example, standard C string functions work with UTF-8: strcmp, strcpy, and other str* functions work without modification. The only possible limitation is that strlen will give you the number of bytes rather than the number of characters, but that is probably the intended meaning anyway (e.g., if you need to see how much memory you need to store a UTF-8 string, its strlen + 1 will still work as intended). UTF-8 also transparently supports both the original Unicode which is 16 bits wide and the new ISO 10646 which is 31 bits wide. >> > So I don't want UTF-8 to be forced on me. >> >> Who's forcing it on you? > > IETF. All recent RFCs are littered with referenced to UTF-8 in all >places where reasonable standards would have "8-bit clean" with no >explicit low-level semantics attached. All they say is that UTF-8 must be supported by all protocols. They don't say other encodings must not or should not. If you need the clean bit, use UTF-7. You can still use MIME. Personally, I see no problem designing a file that can mix text data with other data. The "control" characters still exist in Unicode, so it is easy to a control character followed by the size of data to delimit the start of binary data. > I have spent enough time with "unicoders" to become convinced that the >depth of changes they demand in protocols and libraries is enough to make >it a game of "everything or nothing" -- partial implementations become >unsafe because the design of libraries and prococols hinges on the idea >that only one charset/encoding may exist, so no ways to provide charset >and encoding are left. I have not encountered that attitude. I have seen people who see the advantages of Unicode to the point they do not use anything else in their work, but I do not see them trying to force everyone else to go Unicode only. > This is the problem. There is no "text" and "non-text" -- there is >"valid UTF-8" and everything else. Software designed in "unix style" >can't do heuristics and guess that if the data has some properties (such >as passing UTF-8 validity test) it is really some particular kind of data >and should be treated in some different manner. It does not need to
Re: Unicode on FreeBSD
> > I have just asked, who will benefit from it. No one answered "I will" -- > >everyone who makes Unicode support believes that it will benefit someone > >else. > > I thought I did. OK, let me restate: I will! I actually do already because > I did some work and it is in the ports. OK, I didn't say anything ealier because I though it was fairly obvious that anyone dealind with a *mixed* environment beyond that of ISO 8859-1 (even if that means just a mixture of ISO 8859-1/2) would find Unicode support in the kernel a blessing from the heaven. Let me restate that: I will use it. Currently, if you have a group of ISO 8859-2 users on the system , the ISO 8859-1 people see them as meaningless junk. I don't even want to think about something like Arabic. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales <[EMAIL PROTECTED]> School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.0-STABLE?
I wanted to upgrade several production servers to 4.0 and follow the stable branch. Has 4.0-STABLE been established yet or is stable still RELENG_3? I planned on installing 4.0-RELEASE and then using CVSup with RELENG_4. -- Ted Sikora Jtl Development Group [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, Alex Belits wrote: | On Mon, 3 Apr 2000, G. Adam Stanislav wrote: | | > > Really the question is much more basic -- who benefits from having | > >Unicode (or Unicode in the form of UTF-8) support. It isn't me for sure | > | > Everyone who works with multilingual documents. | | I feel perfectly fine with "multilingual" documents that contain English | and Russian text without Unicode. Please, try thinking wider. Ever thought a mixture of Russian, Hebrew, Korean and English? AFAIK no CCS other than Unicode currently can handle this. | | > Everyone who wants to | > follow a single international standard as opposed to a slew of mutually | > exclusive local standards. Anyone who thinks globally. | | "Globally" in this case means following self-proclaimed unificators from | Unicode Consortium. | | > Anyone who has anything to do with the Internet must deal with UTF-8: | > "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO | > 10646 coded character set combined with the UTF-8 character encoding | > scheme, as defined in [10646] Annex R (published in Amendment 2), for all | > text." | | This is not approved by ANYONE but a bunch of "unificators". It never | was widely discussed, and affected people never had a chance to give any | input. This is the same kind of "standard documents" that ITU issues by | dozens. True, personally I don't like the way Unicode Consortium operates either; I'd prefer a more open system such as IETF. However, it seems an error to brand Unicode as a bad-motivated idea just because the operating body is less ideal. And given that RFC 2277 is just a BCP (Best Current Practice) but not a `standard' document, it doesn't have to be approved by anyone either. If you don't feel right about it, why don't you send a short e-mail message to its author? | | > >-- I am Russian. | > | > So? | | So I don't want UTF-8 to be forced on me. Charset definitions in MIME | headers exist for a reason. If we want to make something usable we can | create a format that can encapsulate existing charsets instead of banning | them altogether and replacing with "unified" stuff where cut(1) and | dd(1) can produce the output that will be declared "illegal" to be | processed as text because it can not be a valid UTF-8 sequence. Nobody is banning anything. Please be reminded that RFC 2277 only mandates the support for UTF-8. One can still go ahead and use US-ASCII, EUC-KR, or whatever you want so far as the protocol supports character set designation such as MIME. And again, RFC 2277 is a BCP. Unlike standards, BCPs has no enforcing power at all. | | One of the most basic strengths of Unix is the ease with which text can | be manipulated, and how "non-text" data can be processed using the same | tools without any complex "this is text and this is not" | application-specific procedures. UTF-8 turns "text" into something that | gives us a dilemma -- to redesign everything to treat "text" as the stream | of UTF-8 encoded Unicode (and make it impossible to combine text and | "non-text" without a lot of pain), or to leave tools as they are and deal | with "invalid" output from perfectly valid operations. In | Windows/Office/... that lives and feeds on complex and unparceable formats | this problem couldn't appear or even thought of -- "text" doesn't exist as | text at all, and the less stuff will look as something that can be usable | outside of strict "object" environment, the better (they now don't even | encode it in UTF-8, and use bare 16-bit Unicode). In Unixlike system it's | a violation of some very basic rules. Yes, it is true that the entire UN*X world is so deeply rooted in single byte-oriented world and it's hard to come up with a reasonable migration path to the multibyte world. But that doesn't justify the byte-oriented system. It has all too many limitations (which you might not realize until you had to mix all different languages in one document; I did :-p), and there has to be an alternative. I'm not saying that the entire UN*X world should migrate to the Unicode world in months. We all know that is just impossible. Eugene -- Eugene M. Kim <[EMAIL PROTECTED]> "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
On Tue, 04 Apr 2000, Ted Sikora wrote:
> I wanted to upgrade several production servers to 4.0 and follow the
> stable branch. Has 4.0-STABLE been established yet or is stable still
> RELENG_3? I planned on installing 4.0-RELEASE and then using CVSup with
> RELENG_4.
Ignore "STABLE" and "CURRENT". The branches are RELENG_3, RELENG_4, and . the
head branch. You can follow any of them that you wish.
Hopefully the FreeBSD team will eventually learn to use database concepts in
their naming conventions. If they did, "stable" and "current" would be aliases
to the invariant name of the underlying development branch.
A few years back, "the wife of the President of the United States" was
"Barbara". Now it is "Hillary". But in a proper database, you don't store
it that way { WifeOf(Office) ==> Lady } and have to change it when the elections
roll around.
Instead you store:
WifeOf (Politician) ==> Lady
and
Officeholder (Office) ==> Politician
That way, when the election rolls around, you simply change the Officeholders
and the rest is automatic.
In the case of FreeBSD, when you change the release status ...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: 4.0-STABLE?
On 04-Apr-00 Ted Sikora wrote: > I wanted to upgrade several production servers to 4.0 and follow the > stable branch. Has 4.0-STABLE been established yet or is stable still > RELENG_3? I planned on installing 4.0-RELEASE and then using CVSup with > RELENG_4. > > -- > Ted Sikora > Jtl Development Group > [EMAIL PROTECTED] > Heh... I tried to CVSUP to 4.0-STABLE and mistakenly chose 4.0-current in the pkg_setup... I wound up with a very nice 5.0-CURRENT machine... Chose 3.X and that is also what you get... You have to set /etc/cvsup manually to RELENG_4 at the moment. Nicole > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- --- -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. -- OWNED? MS: Who's Been In Your Computer Today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DEFPA PCI FDDI cards for trade
!! Before someone shouts at me: I know this is not a FS list But I know some folks were looking for FDDI cards to use on their FreeBSD machines. So that's why.. I have 2 brandnew surplus Digital DEFPA-AB (SAS, MMF, PCI) cards for trade. Please contact me *off-list* if you are interested. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, G. Adam Stanislav wrote: > At 20:59 03-04-2000 -0700, Alex Belits wrote: > > I feel perfectly fine with "multilingual" documents that contain English > >and Russian text without Unicode. > > Those are bilingual, not multilingual. I once had to create a document in > English, Slovak, and Sanskrit (using Devanagari alphabet). There is only > one standard that makes it possible: Unicode. Too bad UTF-8 did not exist > at the time, and I had to use graphics. There is another format that does the same thing better -- MIME multipart documents. Too bad, the development in that direction stopped after certain stupid decision made by some people in IETF. > >> Everyone who wants to > >> follow a single international standard as opposed to a slew of mutually > >> exclusive local standards. Anyone who thinks globally. > > > "Globally" in this case means following self-proclaimed unificators from > >Unicode Consortium. > > I don't know what you mean by "unificators." Why self proclaimed? Those > were people with a need for which they found a solution. With a need to find a cause to break backward compatiobility with everything and sell more software -- just like ITU. I agree that Unicode created a good list of glyphs, and it can be useful for fonts and conversion tables, but it's completely inappropriate as the base of format used in real-life applications for storage and communications. > Unicode Consortium > has no power to force Unicode on anyone. It just happens that it was widely > accepted. So far only by one company actually "accepted" it -- Microsoft. Everyone else (except Java/Sun) just happened to be depended on them. Java and Plan9 are special cases because both are essentially endless storages of ivory-tower design idiosyncrasy and arbitrary decisions made by handful of people. > You're free to create your own system, or ignore it all together. > But just because you see no need for Unicode does not mean you should be > upset when people are willing to work on Unicode support in FreeBSD. I have just asked, who will benefit from it. No one answered "I will" -- everyone who makes Unicode support believes that it will benefit someone else. > > >> Anyone who has anything to do with the Internet must deal with UTF-8: > >> "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO > >> 10646 coded character set combined with the UTF-8 character encoding > >> scheme, as defined in [10646] Annex R (published in Amendment 2), for all > >> text." > > > This is not approved by ANYONE but a bunch of "unificators". It never > >was widely discussed, and affected people never had a chance to give any > >input. This is the same kind of "standard documents" that ITU issues by > >dozens. > > Affected in what way? Many ways of encoding Unicode were proposed, > developed, and used. Most of them are history by now. UTF-8 is the best way > to encode Unicode to this day. Don't like it? Design a better one. I am not talking about Unicode representations and encodings but about Unicode itself. I agree that UTF-8 is the only way to marry Unicode with text and Unix, however I don't see much point in doing that. > > >> >-- I am Russian. > >> > >> So? > > > > So I don't want UTF-8 to be forced on me. > > Who's forcing it on you? IETF. All recent RFCs are littered with referenced to UTF-8 in all places where reasonable standards would have "8-bit clean" with no explicit low-level semantics attached. > > Charset definitions in MIME > >headers exist for a reason. If we want to make something usable we can > >create a format that can encapsulate existing charsets instead of banning > >them altogether and replacing with "unified" stuff where cut(1) and > >dd(1) can produce the output that will be declared "illegal" to be > >processed as text because it can not be a valid UTF-8 sequence. > > You are worried about nothing. No one in this discussion has said anything > about making anything but Unicode and UTF-8 "illegal." Supporting Unicode > does not mean stopping support for everything else. I have spent enough time with "unicoders" to become convinced that the depth of changes they demand in protocols and libraries is enough to make it a game of "everything or nothing" -- partial implementations become unsafe because the design of libraries and prococols hinges on the idea that only one charset/encoding may exist, so no ways to provide charset and encoding are left. > > One of the most basic strengths of Unix is the ease with which text can > >be manipulated, and how "non-text" data can be processed using the same > >tools without any complex "this is text and this is not" > >application-specific procedures. > > Nothing complex about it. UTF-8 uses a very simple algorithm which makes it > very simple to distinguish text from non-text. This is the problem. There is no "text" and "non-text" -- there is "valid UTF-8" and everything else. Software design
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, G. Adam Stanislav wrote: > At 22:51 03-04-2000 -0700, Alex Belits wrote: > > I agree that Unicode created a good list of glyphs, and it can be > >useful for fonts and conversion tables, but it's completely inappropriate > >as the base of format used in real-life applications for storage and > >communications. > > Oh, I think it's great for communications. I design web sites. It is good > to have a single character representation supported by Internet standards. > Saves a lot of work. Before UTF-8 became widely accepted, a typical Slovak > web page started by a menu of choices of which encoding your browser > supported. You had to have 3 - 4 versions of each page. A major pain! Now > you only need one. This is a problem, however Unicode is not the only solution -- actually it's the worst of all solutions -- it solves simple problem only to create a lot of complex ones. > > Or even when designing English pages in a typographically correct way > (opening and closing quotes, and things like that), it was a pain before > UTF-8 because while ISO-8859-1 is the assumed default, Microsoft, in its > infinite wisdom created a slight modification of ISO-8859-1 which they > called ANSI, and which the uninitiated commonly believed to be the same as > ISO-8859-1. As a result, there are a myriad of web pages out there that use > the Microsoft encoding, and there are those that use true ISO-8859-1. So > many browsers assume that you are using the MS "standard." It's a real mess. Misrepresentation of one popular encoding in software of one company doesn't mean that it should be replaced with another, much more complex one, by everyone else. > > So, in all my recent pages I use UTF-8, and the problem is solved. > > >> Unicode Consortium > >> has no power to force Unicode on anyone. It just happens that it was widely > >> accepted. > > > > So far only by one company actually "accepted" it -- Microsoft. Everyone > >else (except Java/Sun) just happened to be depended on them. Java and > >Plan9 are special cases because both are essentially endless storages of > >ivory-tower design idiosyncrasy and arbitrary decisions made by handful of > >people. > > I was not talking about companies. I was talking about people with genuine > i18n needs. People with genuine i18n needs such as linguists or people with genuine i18n needs such as non-English users? Linguists don't see Unicode as being sufficient, and everyone else uses local encodings/charsets. I agree that local encodings are very limiting in the form they exist now, however they, not Unicode, are standards used in real life. If some encapsulation format (not as limited as iso 2022 and not as restrictive as MIME multipart) will be created to support multiple charsets/encodings/languages in one document in labeled chunks, the same problem would be solved with minimal changes in existing software and minimal document conversion efforts. This solution will be far superior to Unicode, and even for "web" use it can be made compatible with charsets support in existing browsers. [skipped without much of disagreement] > Again, it's not about "adoption" of Unicode, it's about supporting Unicode > for those who need it. Going Unicode-only would not be wise, but I don't > see anyone here suggesting that. After looking at what happened to IETF documents, XML and perl I can only come to conclusion that Unicode, once included in some system that didn't have multiple-charset document support infrastructure before that, starts requiring more and more sacrifices to be supported decently until the support of other encodings becomes impossible or significantly more difficult than support of Unicode. I am not against the support of any charset, encoding or language used in the real world, Unicode included. However after seeing how Unicode "support" efforts quickly turn into "adoption" all across the libraries/protocols/applications layers, I believe that only if some decent charset/encoding/language labeling infrastructure will be developed, it will be possible to contain charsets and prevent their "leaking" to application level. Leaking of ASCII (infamous 7-bit restriction that was present for no understandable reason in a lot of protocols and utilities) was a painful enough experience already, and it looks like it's fixed in most of stuff by now. Leaking of local charsets (especially iso 8859-1 and its modifications) was bad, however it was mostly prevented by locale support (even though it is clumsy and unusable in multilingual documents). Leaking of Unicode and UTF-8 can start something even worse because it's already evident that many applications written to support UTF-8 character format, have the hardcoded assumption of this format in their i/o and parsing routines that otherwise are supposed to be either charset-blind, or use external, charset-dependent routines to determine characters boundaries. I don't want to be misunderstood as the oppo
reducing the number of NFSv3 commit ops
Currently FreeBSD issues a very large number of NFSv3 commit rpcs when writing a sequential file. They average out to about one every 64k or so. Solaris, on the other hand, issues only a handful. At least when running against a Solaris NFS server, these frequent commits really kill our write bandwidth. The commits are initiated out of the bufdaemon: nfs_commit(e06866c0,36,0,1,c8aa5e00) at nfs_commit+0x52a nfs_doio(d3088158,c8aa5e00,0,d3088158,40084040) at nfs_doio+0x371 nfs_strategy(ddef1ec0) at nfs_strategy+0x68 nfs_writebp(d3088158,1,ddee5920,ddef1ef8,c0180e42) at nfs_writebp+0xdc nfs_bwrite(ddef1eec,c02a15c0,e06866c0,d3088158,ddef1f28) at nfs_bwrite+0x16 bawrite(d3088158,d30faff0,0,40084040,d30fbae8) at bawrite+0x32 cluster_wbuild(e06866c0,2000,1b8,10,d30fc328) at cluster_wbuild+0x493 vfs_bio_awrite(d30fc328,3f,c0181f8c,c016aef5,0) at vfs_bio_awrite+0x1a4 flushbufqueues(0,8000,c024be00,0,b0206) at flushbufqueues+0x116 buf_daemon(0) at buf_daemon+0x8f fork_trampoline() at fork_trampoline+0x8 The "problem" is that flushbufqueues calls vfs_bio_awrite on the buf's that need commiting. We then go through the overhead of clustering up 64k worth of data & pass it down. It eventually ends up in nfs_doio() which finally realizes that the bufs just need to be committed & calls nfs_commit() on them. This is repeated for every 64k of data. I have an idea on how to reduce these commits & a proof of concept implementation of it. My idea is to have nfs_doio() call a function (which I've called nfs_megacommit()) to consolodate all the B_NEEDCOMMIT bufs from a particular file into one large commit. This nfs_megacommit() function is basically a cut-n-paste of the top half of nfs_flush(). I just tried it this morning & it appears to work. Over a 1Gb/s (Alteon, Jumbo frames) link, my write bandwidth increases from 5-8MB/sec to 17-18MB/sec when talking to a Solaris (2.7, i86) NFS server & writing a 375MB file. The server's nfsstat looks like this. Before: Version 3: (54262 calls) nullgetattr setattr lookup access readlink 0 0%0 0%1 0%1 0%3 0%0 0% readwrite create mkdir symlink mknod 0 0%48325 89% 0 0%0 0%0 0%0 0% remove rmdir rename linkreaddir readdirplus 0 0%0 0%0 0%0 0%0 0%0 0% fsstat fsinfo pathconfcommit 0 0%0 0%0 0%5932 10% After: Version 3: (48078 calls) nullgetattr setattr lookup access readlink 0 0%0 0%0 0%1 0%1 0%0 0% readwrite create mkdir symlink mknod 0 0%48027 99% 1 0%0 0%0 0%0 0% remove rmdir rename linkreaddir readdirplus 0 0%0 0%0 0%0 0%0 0%0 0% fsstat fsinfo pathconfcommit 0 0%0 0%0 0%48 0% Can anybody tell me if doing something like this is fundamentally broken? Is it worth pursuing? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
In the last episode (Apr 04), Andrew Gallatin said: > > Currently FreeBSD issues a very large number of NFSv3 commit rpcs > when writing a sequential file. They average out to about one every > 64k or so. Solaris, on the other hand, issues only a handful. Hmm. Mounting a Solaris box and creating a large file, I see commits too (a 64K commit every 128K or so on my system). Mounting another FreeBSD box, I see absolutely no commits at all. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
* Andrew Gallatin <[EMAIL PROTECTED]> [000404 14:03] wrote: > > Currently FreeBSD issues a very large number of NFSv3 commit rpcs when > writing a sequential file. They average out to about one every 64k or > so. Solaris, on the other hand, issues only a handful. > > At least when running against a Solaris NFS server, these > frequent commits really kill our write bandwidth. > > The commits are initiated out of the bufdaemon: > > nfs_commit(e06866c0,36,0,1,c8aa5e00) at nfs_commit+0x52a > nfs_doio(d3088158,c8aa5e00,0,d3088158,40084040) at nfs_doio+0x371 > nfs_strategy(ddef1ec0) at nfs_strategy+0x68 > nfs_writebp(d3088158,1,ddee5920,ddef1ef8,c0180e42) at nfs_writebp+0xdc > nfs_bwrite(ddef1eec,c02a15c0,e06866c0,d3088158,ddef1f28) at nfs_bwrite+0x16 > bawrite(d3088158,d30faff0,0,40084040,d30fbae8) at bawrite+0x32 > cluster_wbuild(e06866c0,2000,1b8,10,d30fc328) at cluster_wbuild+0x493 > vfs_bio_awrite(d30fc328,3f,c0181f8c,c016aef5,0) at vfs_bio_awrite+0x1a4 > flushbufqueues(0,8000,c024be00,0,b0206) at flushbufqueues+0x116 > buf_daemon(0) at buf_daemon+0x8f > fork_trampoline() at fork_trampoline+0x8 > > The "problem" is that flushbufqueues calls vfs_bio_awrite on the buf's > that need commiting. We then go through the overhead of clustering up > 64k worth of data & pass it down. It eventually ends up in nfs_doio() > which finally realizes that the bufs just need to be committed & calls > nfs_commit() on them. This is repeated for every 64k of data. > > I have an idea on how to reduce these commits & a proof of concept > implementation of it. My idea is to have nfs_doio() call a function > (which I've called nfs_megacommit()) to consolodate all the > B_NEEDCOMMIT bufs from a particular file into one large commit. This > nfs_megacommit() function is basically a cut-n-paste of the top half > of nfs_flush(). > > I just tried it this morning & it appears to work. Over a 1Gb/s > (Alteon, Jumbo frames) link, my write bandwidth increases from > 5-8MB/sec to 17-18MB/sec when talking to a Solaris (2.7, i86) NFS > server & writing a 375MB file. The server's nfsstat looks like this. > > Before: > > Version 3: (54262 calls) > nullgetattr setattr lookup access readlink > 0 0%0 0%1 0%1 0%3 0%0 0% > readwrite create mkdir symlink mknod > 0 0%48325 89% 0 0%0 0%0 0%0 0% > remove rmdir rename linkreaddir readdirplus > 0 0%0 0%0 0%0 0%0 0%0 0% > fsstat fsinfo pathconfcommit > 0 0%0 0%0 0%5932 10% > > > After: > > Version 3: (48078 calls) > nullgetattr setattr lookup access readlink > 0 0%0 0%0 0%1 0%1 0%0 0% > readwrite create mkdir symlink mknod > 0 0%48027 99% 1 0%0 0%0 0%0 0% > remove rmdir rename linkreaddir readdirplus > 0 0%0 0%0 0%0 0%0 0%0 0% > fsstat fsinfo pathconfcommit > 0 0%0 0%0 0%48 0% > > > Can anybody tell me if doing something like this is fundamentally > broken? Is it worth pursuing? http://www.freebsd.org/~alfred/nfs_supercommit_broken.diff only grab as many adjacent blocks as possible, you don't want to scan the entire file's buffer list for each commit, you also don't want to interfere with other client's caching forcing sever commits on thier behalf. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Alex Belits <[EMAIL PROTECTED]> wrote:
> I have just asked, who will benefit from it. No one answered "I will" --
I WILL.
I want to be able to mention Henry Charri{e grave}re and
Stanis{l stroke}aw Lem in a single document and spell those names
correctly. Actually, that's a real world example. I already do on a web
page, and of course this is only possible because of the underlying
Unicode character set of HTML.
I want to be able to give a book title in Cyrillic or Greek.
I want to be able to quote from _Beowulf_.
I *desperately* want to use IPA rather than various ad-hoc ASCII
transcriptions.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
Alfred Perlstein writes: > > > > Can anybody tell me if doing something like this is fundamentally > > broken? Is it worth pursuing? > > http://www.freebsd.org/~alfred/nfs_supercommit_broken.diff > > only grab as many adjacent blocks as possible, you don't want to > scan the entire file's buffer list for each commit, you also don't > want to interfere with other client's caching forcing sever commits > on thier behalf. > I'll look at that tonight. But before I do -- why is it broken? (the name sorta implies that it us ;) Thanks! Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
* Andrew Gallatin <[EMAIL PROTECTED]> [000404 14:25] wrote: > > Alfred Perlstein writes: > > > > > > Can anybody tell me if doing something like this is fundamentally > > > broken? Is it worth pursuing? > > > > http://www.freebsd.org/~alfred/nfs_supercommit_broken.diff > > > > only grab as many adjacent blocks as possible, you don't want to > > scan the entire file's buffer list for each commit, you also don't > > want to interfere with other client's caching forcing sever commits > > on thier behalf. > > > > I'll look at that tonight. But before I do -- why is it broken? > (the name sorta implies that it us ;) I'm not sure, i did it a while back and ran out of time to get it working, it functions in the strategy layer and tries to grab adjacent commit blocks to the already clustered IO. I think I may have some math errors or something, I haven't had time to give it a retry in a while. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
At 1:17 AM +1000 4/5/00, Patryk Zadarnowski wrote: > > > I have just asked, who will benefit from it. No one answered > > > "I will" -- everyone who makes Unicode support believes that it > > > will benefit someone else. > > > > I thought I did. OK, let me restate: I will! I actually do already > > because I did some work and it is in the ports. > >OK, I didn't say anything ealier because I though it was fairly >obvious that anyone dealing with a *mixed* environment beyond that of >ISO 8859-1 (even if that means just a mixture of ISO 8859-1/2) would >find Unicode support in the kernel a blessing from the heaven. Let me >restate that: I will use it. Currently, if you have a group of ISO >8859-2 users on the system , the ISO 8859-1 people see them as >meaningless junk. I don't even want to think about something like >Arabic. I also think this issue is so obvious that it seems silly to even have to mention it. If anyone is working on unicode support in any part of the system, then more power to them. Even if no one did use unicode support, it is mighty nice to have it sitting there should the need arise. If there is a superior alternative down the road, let's call that unicode-II, then it would also be great if FreeBSD has support for that too. I am not aware of any current alternative which is as widely pursued as unicode, though, and it seems pretty obvious that it would benefit FreeBSD if we were among the operating systems which understand what to do with it. I don't understand what possible benefit there is in having *NO* options to deal with all the language-characters in the world. Even if unicode isn't perfect, it is a damn sight better than nothing. If some specific change for unicode does break things, then I can see arguing that change. I can't fathom why anyone would argue against unicode support per se. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, Apr 03, 2000 at 08:59:51PM -0700, Alex Belits wrote: > On Mon, 3 Apr 2000, G. Adam Stanislav wrote: > > > > Really the question is much more basic -- who benefits from > > > having Unicode (or Unicode in the form of UTF-8) support. It > > > isn't me for sure > > > > Everyone who works with multilingual documents. > > I feel perfectly fine with "multilingual" documents that contain > English and Russian text without Unicode. This is bilingual. I have found myself in the need to write in English, Modern Greek (one accent), and Ancient Greek (many accents). This is not possible using 8-bit fonts, since the glyphs for the accented ancient greek alone are much more than 128. Of course, it still remains to be seen if having Unicode support on the console is a Good Thing(TM). - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
At 5:08 PM +0300 4/4/00, Giorgos Keramidas wrote: > ... I have found myself in the need to write in English, >Modern Greek (one accent), and Ancient Greek (many accents). This >is not possible using 8-bit fonts, since the glyphs for the accented >ancient greek alone are much more than 128. > >Of course, it still remains to be seen if having Unicode support >on the console is a Good Thing(TM). I am sure that many an administrator has found themselves staring at the console at some point in their life, and thinking: "This is all Greek to me..." :-) --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help? Device driver 'make depend' errors from comments
Since I received exactly ZERO responses to my plea for help in making my network device driver a loadable module, I'm now trying to compile my driver into the kernel. First, I made up a makefile and got my driver compiling cleanly standalone in my directory. So the code is known good with respect to compiling under FreeBSD with gcc. Then I moved the code under the /sys hierarchy, fixed up my configuration file, and did a 'config' for my kernel. So far, so good. But then when I moved to the compile directory and did a 'make depend', all heck broke loose. I'm getting hundreds of errors and/or warnings. Checking the code, it seems to be complaining (or rather getting confused) about two major things: 1. Comments following a #if or #ifdef, for example: #ifdef FOO // not yet tested While this only generates a 'warning', I'm also getting actual (supposed) errors about 'unbalanced #endif' and the like. Though it is possible these errors are related to problem number 2 instead: 2. It complains (doesn't say 'warning' so I suppose it takes them as errors?) about "unterminated string or character constant" whenever I have an apostrophe WITHIN A // COMMENT !!! For example, just including the word "don't" within a comment is causing problems. So how do I "turn off" these "features" of 'make depend' ??? ;-) Now this is a common codebase for this driver, which compiles fine for Windows and Linux, and, as mentioned above, it compiles fine (stand-alone) for FreeBSD. So obviously it is syntactically-good C code for gcc, so why am I having all these problems? There are over 50,000 lines of code, so please don't tell me to go changing all the comments and #if lines! Any (other :) suggestions would be appreciated... Thanks, Gary -- === Gary Corcoran - Distinguished Member of Technical Staff Lucent Microelectronics - Client Access Broadband Systems Communications Protocol & Driver Development Group "We make the drivers that make communications work" Email: [EMAIL PROTECTED] --- There are only two kinds of machines - those that fail little by little, and those that fail all at once. === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
You, Alex Belits, were spotted writing this on Tue, Apr 04, 2000 at 11:03:58AM -0700: > > On Mon, 3 Apr 2000, G. Adam Stanislav wrote: > > > At 20:59 03-04-2000 -0700, Alex Belits wrote: > > > I feel perfectly fine with "multilingual" documents that contain English > > >and Russian text without Unicode. > > > > Those are bilingual, not multilingual. I once had to create a document in > > English, Slovak, and Sanskrit (using Devanagari alphabet). There is only > > one standard that makes it possible: Unicode. Too bad UTF-8 did not exist > > at the time, and I had to use graphics. > > There is another format that does the same thing better -- MIME > multipart documents. You mean, MIME multipart documents are better than Unicode if I, for instance, want to handle Tolstoy's "War and Peace" with French quotes in the middle of Russian sentences? I don't think so. > I have just asked, who will benefit from it. No one answered "I will" -- > everyone who makes Unicode support believes that it will benefit someone > else. I will. I need to handle French, Hebrew, and Russian, often in the same document. I want to be able to publish Russian poetry in its original pre-1917 spelling, which includes letters missing from existing Russian encodings. I need IPA. I need math symbols not just in TeX documents. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help? Device driver 'make depend' errors from comments
| First, I made up a makefile and got my driver compiling cleanly | standalone in my directory. So the code is known good with respect | to compiling under FreeBSD with gcc. Then I moved the code under | the /sys hierarchy, fixed up my configuration file, and did a 'config' | for my kernel. So far, so good. | | But then when I moved to the compile directory and did a 'make depend', | all heck broke loose. I'm getting hundreds of errors and/or warnings. | Checking the code, it seems to be complaining (or rather getting | confused) about two major things: [ snip. ] When you compile standalone, do you use the same -W options as the kernel does when it compiles? That may account for the millions of warnings you getting when trying to build your driver with the regular kernel build. Cheers, -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, Garance A Drosihn wrote: > I don't understand what possible benefit there is in having *NO* > options to deal with all the language-characters in the world. Even > if unicode isn't perfect, it is a damn sight better than nothing. The existing "market" of multilingual application is so small, and it's based on so simplistic requirements (to be able to display and print characters, and make multilingual "web pages"), that even solution so much flawed as standardization on Unicode can survive. Unicode is positioned as the _replacement_ for languages/charsets handling infrastructure -- "we know all the characters, so we can write all the words, right?". As demands for sopisticated processing of multilingual texts will increase, "Unicode-only" systems will demonstrate their ridiculous limits and ambiguity, however if no multiple-charset/multiple-language infrastructure in libraries, formats, protocols, text and document editors and interpreter-based programming languages will be in place, there will be no way to improve the situation. This is why I think that the design of the language support infrastructure is an extremely important taks, and if it will succeed, efficient, modularized support of charsets/encodings, including Unicode, can be implemented painlessly. > If some specific change for unicode does break things, then I can > see arguing that change. I can't fathom why anyone would argue > against unicode support per se. I am not against the support for Unicode. I just never have seen an attempt of providing usable Unicode support that didn't leave scorched earth to any other possible attempt of supporting multilingual environment or even single-charset environment other than iso8859-1 or Unicode. I think that instead of blind following the ideas of "one charset" we need to design something that can painlessly accept various charsets in the same document/stream/etc (just like MIME does in its own clumsy way). If Unicode support will be implemented on top of it, I will be the last person to criticize it. -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, Anatoly Vorobey wrote: > You mean, MIME multipart documents are better than Unicode if I, for instance, > want to handle Tolstoy's "War and Peace" with French quotes in the middle of > Russian sentences? > > I don't think so. This is what multipart format exists for -- to combine documents or sections in the document with possibly different metadata in the headers. The idea of "mail attachment" appeared later. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, Alex Belits wrote: > > You mean, MIME multipart documents are better than Unicode if I, for instance, > > want to handle Tolstoy's "War and Peace" with French quotes in the middle of > > Russian sentences? > > > > I don't think so. > > This is what multipart format exists for -- to combine documents or > sections in the document with possibly different metadata in the > headers. The idea of "mail attachment" appeared later. I have to add that I agree that the way, MIME multipart is handled is primitive and inconvenient for such applications, however this is not the result of any flaw in its design, only of the lack of progress after "everything should adopt Unicode" doctrine was declared. One may argue that the way that TeX handles such a text is even more inconvenient, however even now it's most likely that TeX would be used for this kind of typesetting. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, Apr 04, 2000 at 12:08:39PM -0700, Alex Belits wrote: > I don't want to be misunderstood as the opponent of all things Unicode >-- as I have said, its support is useful. However I oppose: > >1. The point of view that Unicode is the only possible or the best >possible way to handle multilingual documents. > >2. The point of view that support of Unicode should be made at the expense >of compatibility with everything else, or by the introduction of some >unsafe guesswork such as application of UTF-8 validity check to determine >if the chunk of data is in UTF-8 or not. Then you have nothing to fear. This is FreeBSD we are talking about. This is not some control freak company. We will have as much, or as little, Unicode support as we put in it. I don't see anyone saying we should drop everything in favor of Unicode, let alone do I see anyone volunteering to do it. -- Where two fight, third one wins -- Slovak proverb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, Apr 04, 2000 at 05:08:56PM +0300, Giorgos Keramidas wrote: >Of course, it still remains to be seen if having Unicode support on the >console is a Good Thing(TM). I don't see how it would be even possible, due to hardware limitations. The console can only support an 8-bit font (I mean 8-bit encoding). If you change it for one character, you change it for everything on the console. And this was designed by *International* Business Machines! :) I see the main way of supporting Unicode in providing libraries that programs can use to convert between Unicode and local display. I did some of it with my i18ntools. I wanted to do more, but could not due to health reasons, as mentioned already. I am in a better shape now, and hopefully will be able to resume the work I started. But it won't happen in the near future for reasons other than else (mostly because I am broke and am concentrating my programming efforts on software I can sell - but when my current project is completed, I will *probably* do more work on Unicode support for FreeBSD). Cheers, Adam -- Suppose you were an idiot. Suppose you were a member of Congress. But I'm repeating myself... -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, Apr 04, 2000 at 05:05:05PM -0700, Alex Belits wrote: > The existing "market" of multilingual application is so small, and it's >based on so simplistic requirements (to be able to display and print >characters, and make multilingual "web pages"), that even solution so much >flawed as standardization on Unicode can survive. Unicode is positioned as >the _replacement_ for languages/charsets handling infrastructure -- "we >know all the characters, so we can write all the words, right?". Not so. Unicode is a character map. One of many. It just happens to be the most inclusive one in existence. I also strongly disagree with your view of it being simplistic. Unicode is not, and never was, meant to be a high level linguistic system. Rather, it provides primitives for such a system. It is a map, nothing else. It is system-independent. It does not even specify how the map is to be encoded (e.g., UTF-8, or 16 bits, etc). The Unicode Consortium does provide all kinds of text files that help programmers use the map better: They provide such information as which character is upper case, lower case, digit, control, etc; how to convert upper case to lower case, and things like that. It does not, for example, provide sorting order. It cannot. Unicode is not about linguistics, it is about mapping characters regardless of their use in specific languages. And different languages sort characters differently. For example, in Slovak, "ch" is considered a character which belongs after the "h". In other languages it is sorted differently. And in most languages, it is just two unrelated characters. Unicode is not simplistic. It does what its stated goal is, and it does it well. How we use it, is up to us. Cheers, Adam P.S. Hmmm... Interesting. I noticed my random quote contains a C-caron. I wonder how it is going to be handled. :) -- Can you imagine the silence if everyone said only what he knows! -- Karel Čapek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help? Device driver 'make depend' errors from comments
> Since I received exactly ZERO responses to my plea for help in making > my network device driver a loadable module, I'm now trying to compile > my driver into the kernel. Go back to the module if this is for 4.x; I don't recall your original post, sorry, but feel free to pass it back off the list. > Now this is a common codebase for this driver, which compiles fine > for Windows and Linux, and, as mentioned above, it compiles fine > (stand-alone) for FreeBSD. So obviously it is syntactically-good > C code for gcc, so why am I having all these problems? There are > over 50,000 lines of code, so please don't tell me to go changing > all the comments and #if lines! Any (other :) suggestions > would be appreciated... Oh joy. It was probably written for MSVC in that case. You're going to have to compile as a module in order to get different compiler warning flags; the code you're trying to build isn't really valid C and you'll have to work around this. Please let us look at your module problems again, and poke me specifically about it if you're not getting answers. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, G. Adam Stanislav wrote: > On Tue, Apr 04, 2000 at 05:05:05PM -0700, Alex Belits wrote: > > The existing "market" of multilingual application is so small, and it's > >based on so simplistic requirements (to be able to display and print > >characters, and make multilingual "web pages"), that even solution so much > >flawed as standardization on Unicode can survive. Unicode is positioned as > >the _replacement_ for languages/charsets handling infrastructure -- "we > >know all the characters, so we can write all the words, right?". > > Not so. Unicode is a character map. One of many. It just happens to be > the most inclusive one in existence. It is. However if you look at the current efforts of its "adoption", it is not used as one. It's touted as the solution to all language-related problems, as a replacement of language/charset labeling infrastructure and as the necessary prerequisite for any multilingual text processing. [skipped] > It does not, for example, provide sorting order. It cannot. Unicode is > not about linguistics, it is about mapping characters regardless of their > use in specific languages. And different languages sort characters > differently. For example, in Slovak, "ch" is considered a character > which belongs after the "h". In other languages it is sorted differently. > And in most languages, it is just two unrelated characters. This is the kind of work that currently nonexistent language support infrastructure should do -- when some language is encountered in "multilingual" document/protocol/... its name can be used to load the procedures (in this case sorting but it may be hyphenation, phonetic match, etc.) for that particular language, and if no matched language is known or supported, data should be just left alone. The same infrastructure can be designed to support charsets and encodings, doing conversion between them (and unicode) only where possible and necessary, and providing the text in either "original" or "preferred", "supported", etc. encoding for the language for the particular operation that should be performed on the text. If such thing will be implemented, all existing charset-specific routines that now exist in various places, can be reused, and compatibility with existing software can be achieved without any significant pain. > Unicode is not simplistic. It does what its stated goal is, and it does > it well. How we use it, is up to us. > > Cheers, > Adam > > P.S. Hmmm... Interesting. I noticed my random quote contains a C-caron. > I wonder how it is going to be handled. :) It was handled pretty well for such a primitive system as pine in xterm. Since your charset was iso 8859-2, it was marked as such in Content-Type header of the message. pine given me a warning: ---8<--- [ The following text is in the "iso-8859-2" character set. ] [ Your display is set for the "koi8-r" character set. ] [ Some characters may be displayed incorrectly. ] --->8--- and displayed the text. xterm used the default font that happened to be in koi8-r charset, displaying C-caron as cyrillic ha. I have read the warning, manually switched xterm to a font in iso 8859-2 charset, and text was displayed correctly. If I used a gui-based MUA such as Netscape (what I didn't because Netscape Messenger sucks for reasons that have nothing to do with its charsets support), it would just display the message in the charset defined in the header. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
:> :> I'll look at that tonight. But before I do -- why is it broken? :> (the name sorta implies that it us ;) : :I'm not sure, i did it a while back and ran out of time to get it :working, it functions in the strategy layer and tries to grab adjacent :commit blocks to the already clustered IO. : :I think I may have some math errors or something, I haven't had time :to give it a retry in a while. : :-- :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] :"I have the heart of a child; I keep it in a jar on my desk." If I remember the right patch, I think my comment on it was that the buffers should use non-blocking locks rather then blocking locks in order to avoid deadlocks, which it looks like you did. This may still patch into -stable but it probably isn't safe to patch into -current. It still looks a little rough but the general concept is sound. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help? Device driver 'make depend' errors from comments
Mike Smith wrote: > Go back to the module if this is for 4.x; I originally asked about making a network driver module for 3.4. I was hoping for either a "here's how you do it" or at least an "it's not possible with 3.4" response... > > Now this is a common codebase for this driver, which compiles fine > > for Windows and Linux, and, as mentioned above, it compiles fine > > (stand-alone) for FreeBSD. So obviously it is syntactically-good > > C code for gcc, so why am I having all these problems? There are > > over 50,000 lines of code, so please don't tell me to go changing > > all the comments and #if lines! Any (other :) suggestions > > would be appreciated... > > Oh joy. It was probably written for MSVC in that case. How did you guess?... ;-) Yes, originally developed for Windows. Ported to Linux (as a module) without many problems; now I'm the "lone wolf" trying to add support for FreeBSD... > You're going to have to compile as a module in order to get different > compiler warning flags; Okay - that's what I needed to know. It looks like I should definitely be targeting 4.x instead of 3.x. :( I'll install 4.0, see if there are any network driver module examples, and get back to you-all if I have any more problems... Thanks, Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Regardless of how you feel about Unicode--whatever, just think of how horribly terrible things would be if people actually had to *speak* to one another. gah, the torture. ;-) Dan gh > On Tue, 4 Apr 2000, G. Adam Stanislav wrote: > > > On Tue, Apr 04, 2000 at 05:05:05PM -0700, Alex Belits wrote: > > > The existing "market" of multilingual application is so small, and it's > > >based on so simplistic requirements (to be able to display and print > > >characters, and make multilingual "web pages"), that even solution so much > > >flawed as standardization on Unicode can survive. Unicode is positioned as > > >the _replacement_ for languages/charsets handling infrastructure -- "we > > >know all the characters, so we can write all the words, right?". > > > > Not so. Unicode is a character map. One of many. It just happens to be > > the most inclusive one in existence. > > It is. However if you look at the current efforts of its "adoption", it > is not used as one. It's touted as the solution to all language-related > problems, as a replacement of language/charset labeling infrastructure > and as the necessary prerequisite for any multilingual text processing. > > [skipped] > > > It does not, for example, provide sorting order. It cannot. Unicode is > > not about linguistics, it is about mapping characters regardless of their > > use in specific languages. And different languages sort characters > > differently. For example, in Slovak, "ch" is considered a character > > which belongs after the "h". In other languages it is sorted differently. > > And in most languages, it is just two unrelated characters. > > This is the kind of work that currently nonexistent language support > infrastructure should do -- when some language is encountered in > "multilingual" document/protocol/... its name can be used to load the > procedures (in this case sorting but it may be hyphenation, phonetic > match, etc.) for that particular language, and if no matched language is > known or supported, data should be just left alone. The same > infrastructure can be designed to support charsets and encodings, doing > conversion between them (and unicode) only where possible and necessary, > and providing the text in either "original" or "preferred", "supported", > etc. encoding for the language for the particular operation that should be > performed on the text. If such thing will be implemented, all existing > charset-specific routines that now exist in various places, can be reused, > and compatibility with existing software can be achieved without any > significant pain. > > > Unicode is not simplistic. It does what its stated goal is, and it does > > it well. How we use it, is up to us. > > > > Cheers, > > Adam > > > > P.S. Hmmm... Interesting. I noticed my random quote contains a C-caron. > > I wonder how it is going to be handled. :) > > It was handled pretty well for such a primitive system as pine in > xterm. Since your charset was iso 8859-2, it was marked as such in > Content-Type header of the message. pine given me a warning: > > ---8<--- > [ The following text is in the "iso-8859-2" character set. ] > [ Your display is set for the "koi8-r" character set. ] > [ Some characters may be displayed incorrectly. ] > --->8--- > > and displayed the text. xterm used the default font that happened to be in > koi8-r charset, displaying C-caron as cyrillic ha. I have read the > warning, manually switched xterm to a font in iso 8859-2 charset, and text > was displayed correctly. If I used a gui-based MUA such as Netscape (what > I didn't because Netscape Messenger sucks for reasons that have nothing to > do with its charsets support), it would just display the message in the > charset defined in the header. > > -- > Alex > > -- > Excellent.. now give users the option to cut your hair you hippie! > -- Anonymous Coward > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reducing the number of NFSv3 commit ops
* Matthew Dillon <[EMAIL PROTECTED]> [000404 19:59] wrote: > :> > :> I'll look at that tonight. But before I do -- why is it broken? > :> (the name sorta implies that it us ;) > : > :I'm not sure, i did it a while back and ran out of time to get it > :working, it functions in the strategy layer and tries to grab adjacent > :commit blocks to the already clustered IO. > : > :I think I may have some math errors or something, I haven't had time > :to give it a retry in a while. > : > :-- > :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > :"I have the heart of a child; I keep it in a jar on my desk." > > If I remember the right patch, I think my comment on it was > that the buffers should use non-blocking locks rather then > blocking locks in order to avoid deadlocks, which it looks like > you did. > > This may still patch into -stable but it probably isn't safe > to patch into -current. It still looks a little rough but > the general concept is sound. There's some definite funkyness with the patch, it just doesn't DTRT. When I have time I'll try again, perhaps Andrew will give it a shot. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
Richard Wackerbarth wrote: > > In the case of FreeBSD, when you change the release status ... Feel free to change CVS to work that way and then submit patches. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The size of the pizza is inversely proportional to the intensity of the hunger. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
"Nicole Harrington." wrote: > > Heh... I tried to CVSUP to 4.0-STABLE and mistakenly chose 4.0-current in the > pkg_setup... I wound up with a very nice 5.0-CURRENT machine... Chose 3.X and > that is also what you get... You have to set /etc/cvsup manually to RELENG_4 at > the moment. Don't you have /usr/share/examples/cvsup/4.x-stable-supfile? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The size of the pizza is inversely proportional to the intensity of the hunger. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
On Wed, 05 Apr 2000, Daniel C. Sobral wrote: > Richard Wackerbarth wrote: > > In the case of FreeBSD, when you change the release status ... > Feel free to change CVS to work that way and then submit patches. But that IS the way CVS works. There is NO "STABLE" tag. The tag is "RELENG_4". If you want CVS to reflect the way you describe the system, you would have to change the repository to match your description. I advocate that we change the description to match the repository. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
On 05-Apr-00 Daniel C. Sobral wrote: > "Nicole Harrington." wrote: >> >> Heh... I tried to CVSUP to 4.0-STABLE and mistakenly chose 4.0-current in >> the >> pkg_setup... I wound up with a very nice 5.0-CURRENT machine... Chose 3.X >> and >> that is also what you get... You have to set /etc/cvsup manually to RELENG_4 >> at >> the moment. > > Don't you have /usr/share/examples/cvsup/4.x-stable-supfile? > Yup.. however if you use.. " pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz " It does not use it... It just asks questions.. Problem is (with 4.0 now being in the stable branch, that it now asks the wrong questions.. Nicole > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > The size of the pizza is inversely proportional to the intensity of the > hunger. [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- --- -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. -- OWNED? MS: Who's Been In Your Computer Today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, Apr 04, 2000 at 07:19:06PM -0700, Alex Belits wrote: > It is. However if you look at the current efforts of its "adoption", it >is not used as one. It's touted as the solution to all language-related >problems, as a replacement of language/charset labeling infrastructure >and as the necessary prerequisite for any multilingual text processing. Abusus non tollit usum! Besides, you were criticizing the Unicode Consortium for this. The Consortium is certainly not representing Unicode as anything but a character map. Alex, frankly, we are moving in circles here. Let's drop this thread. Adam -- When a finger points at the Moon... do you look at the Moon? Or, do you prefer to worship the finger? -- Unknown Zen Master To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
