Re: Font loading extremely slow with the UTF-8 locale
#include hallo.h * Branden Robinson [Mon, Jan 27 2003, 12:15:04PM]: What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. This may come as a deep shock to you, but your personal opinions on how Debian can best serve its users and free software are not shared by everyone else in the project. Hehe. If more people would agree with you more often, you would be the DPL now. Not necessarily, and wholly irrelevant to this line of discussion. In I am glad that you finaly realized it. It began with your first reference to the other post, without any help in this issue but using this mail to strike back. any event, I'd rather lose a popularity contest if to win it means sacrificing my sense of integrity. I hope this does not sound slighting. As opposed to many of the other remarks you make about me and my packages? Not many. And now, please don't send any further off-topic mails to the mailing list - it is useless to have a public flamewar against you, since you often showed to be the Napalm. Sure, everybody can say that he is right and his idea is the one that better fits into the Social Contract. But OTOH I showed that your failure caused a violation of it. ...in your interpretation. I do not see how refusing to violate the freeze guidelines set down by the Release Manager is a personal failure on my part to satisfy the Social Contract. I also do not see how not optimizing upstream code with a patch that, to my knowledge, doesn't even exist yet is a personal failure on my part to satisfy the contract. Now, we mix the things up. I tried KNOPPIX and there is the same problem, bad, bad performance of IceWM in UTF-8 mode. Will do, when the time comes. The gradual freeze caused more problems then it ever should. ...in your opinion. Why are the decisions of the Release Manager my problem? ... Why are the decisions of the Release Manager and FTP admins my problem? That are not your problems, and you may not be the one to blame for the current situation, since we all have been fooled several times with the information about the final deadline. If I were DPL, I would have more responsibility for such things. Maybe you take your grievances to the person who was elected to that office, and not to random package maintainers. When the time comes, I will make more presure. As said, gradual freeze was IMO a disaster and should not happen again in this form. Because it shipped with working modules (read: those from XFree4.2) while Woody could not support one-year-old Geforce4 when released? Why are the decisions of the Release Manager my problem? Who prevented you from packaging XFree86 4.2.0 in January 2002 and releasing Bloch Linux, an enhanced version of Debian GNU/Linux with XFree86 modules that work? Guess what, I had other things to do. It would look different I would have had more time. And yes, you will claim the same. And I think, DanielS does the right thing this time. Debian packages should be ready when the upstream is ready and not need another upstream release period. Moreover, what does Woody's release schedule and contents have to do with the speed of XFree86 4.2.1's UTF-8 font loading? Can you pick a point and stick to it, please? As said, you began with pointing to other messages about my attitude - without that useless mail, discussion could still be On-Topic. Gruss/Regards, Eduard. -- Da kam dann das Elfmeterschießen. Wir hatten alle die Hosen voll, aber bei mir lief's ganz flüssig. -- Paul Breitner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Font loading extremely slow with the UTF-8 locale
#include hallo.h * Branden Robinson [Sun, Jan 26 2003, 04:18:09PM]: What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. This may come as a deep shock to you, but your personal opinions on how Debian can best serve its users and free software are not shared by everyone else in the project. Hehe. If more people would agree with you more often, you would be the DPL now. I hope this does not sound slighting. It is revealing that you ascribe differences of opinion to failures of people who disagree with you to abide by the Debian Social Contract. Sure, everybody can say that he is right and his idea is the one that better fits into the Social Contract. But OTOH I showed that your failure caused a violation of it. You may be pissed and start with personal attacks, but this is not a solution and only an ugly way to make people shut up. You still fail to see the point. If you keep a recent upstream version back, you do NOT cure the problems of other ports but actually damage the hardware support on mainstream architectures and so harm Debian's reputation. I suggest you have a talk with the Release Manager, then. It's his call to say no new upstream versions when we're in a freeze. Will do, when the time comes. The gradual freeze caused more problems then it ever should. You may also want to speak with the Stable Release Manager and determine under what circumstances he would allow a new upstream version of XFree86 into a point release of Debian 3.0. Stable is Stable, and you know it. I favorize the idea of Working Branch, but without support of RM and FTP maintainers, it is not easy to implement it. And, please, next time when you make a bad comparison, find an example that is less ridiculous. Knoppix has UTF-8 fonts, and there are much more non-latin1 using people than Americans may think. Irrelevant. Is Knoppix's XFree86 4.2.1 faster at loading the UTF-8 fonts than Debian's XFree86 4.2.1 is? If so, I detect an opportunity for someone to create a patch and file a wishlist bug. Alternatively, you can eschew the collaborative process altogether, switch to Knoppix exclusively, and tell everyone who'll listen to you to do the same. I will try tonight and try to locate the reason if it performs better. But comes that you are so keen on degrading the reputation of Knoppix? Because it shipped with working modules (read: those from XFree4.2) while Woody could not support one-year-old Geforce4 when released? Gruss/Regards, Eduard. -- Daimler Benz ist es nun gelungen, fur eine Entwicklungssumme von über einer Milliarde DM ein Auto zu entwickeln, welches sich bei Gefahr auf den Rücken legt und tot stellt.
Re: Font loading extremely slow with the UTF-8 locale
#include hallo.h * Branden Robinson [Mon, Jan 27 2003, 12:15:04PM]: What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. This may come as a deep shock to you, but your personal opinions on how Debian can best serve its users and free software are not shared by everyone else in the project. Hehe. If more people would agree with you more often, you would be the DPL now. Not necessarily, and wholly irrelevant to this line of discussion. In I am glad that you finaly realized it. It began with your first reference to the other post, without any help in this issue but using this mail to strike back. any event, I'd rather lose a popularity contest if to win it means sacrificing my sense of integrity. I hope this does not sound slighting. As opposed to many of the other remarks you make about me and my packages? Not many. And now, please don't send any further off-topic mails to the mailing list - it is useless to have a public flamewar against you, since you often showed to be the Napalm. Sure, everybody can say that he is right and his idea is the one that better fits into the Social Contract. But OTOH I showed that your failure caused a violation of it. ...in your interpretation. I do not see how refusing to violate the freeze guidelines set down by the Release Manager is a personal failure on my part to satisfy the Social Contract. I also do not see how not optimizing upstream code with a patch that, to my knowledge, doesn't even exist yet is a personal failure on my part to satisfy the contract. Now, we mix the things up. I tried KNOPPIX and there is the same problem, bad, bad performance of IceWM in UTF-8 mode. Will do, when the time comes. The gradual freeze caused more problems then it ever should. ...in your opinion. Why are the decisions of the Release Manager my problem? ... Why are the decisions of the Release Manager and FTP admins my problem? That are not your problems, and you may not be the one to blame for the current situation, since we all have been fooled several times with the information about the final deadline. If I were DPL, I would have more responsibility for such things. Maybe you take your grievances to the person who was elected to that office, and not to random package maintainers. When the time comes, I will make more presure. As said, gradual freeze was IMO a disaster and should not happen again in this form. Because it shipped with working modules (read: those from XFree4.2) while Woody could not support one-year-old Geforce4 when released? Why are the decisions of the Release Manager my problem? Who prevented you from packaging XFree86 4.2.0 in January 2002 and releasing Bloch Linux, an enhanced version of Debian GNU/Linux with XFree86 modules that work? Guess what, I had other things to do. It would look different I would have had more time. And yes, you will claim the same. And I think, DanielS does the right thing this time. Debian packages should be ready when the upstream is ready and not need another upstream release period. Moreover, what does Woody's release schedule and contents have to do with the speed of XFree86 4.2.1's UTF-8 font loading? Can you pick a point and stick to it, please? As said, you began with pointing to other messages about my attitude - without that useless mail, discussion could still be On-Topic. Gruss/Regards, Eduard. -- Da kam dann das Elfmeterschießen. Wir hatten alle die Hosen voll, aber bei mir lief's ganz flüssig. -- Paul Breitner
Re: Font loading extremely slow with the UTF-8 locale
On Sat, Jan 25, 2003 at 08:12:20PM +0100, Eduard Bloch wrote: #include hallo.h * Branden Robinson [Tue, Jan 21 2003, 01:27:13PM]: I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. This may come as a deep shock to you, but your personal opinions on how Debian can best serve its users and free software are not shared by everyone else in the project. It is revealing that you ascribe differences of opinion to failures of people who disagree with you to abide by the Debian Social Contract. You still fail to see the point. If you keep a recent upstream version back, you do NOT cure the problems of other ports but actually damage the hardware support on mainstream architectures and so harm Debian's reputation. I suggest you have a talk with the Release Manager, then. It's his call to say no new upstream versions when we're in a freeze. You may also want to speak with the Stable Release Manager and determine under what circumstances he would allow a new upstream version of XFree86 into a point release of Debian 3.0. And, please, next time when you make a bad comparison, find an example that is less ridiculous. Knoppix has UTF-8 fonts, and there are much more non-latin1 using people than Americans may think. Irrelevant. Is Knoppix's XFree86 4.2.1 faster at loading the UTF-8 fonts than Debian's XFree86 4.2.1 is? If so, I detect an opportunity for someone to create a patch and file a wishlist bug. Alternatively, you can eschew the collaborative process altogether, switch to Knoppix exclusively, and tell everyone who'll listen to you to do the same. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | msg05491/pgp0.pgp Description: PGP signature
Re: Font loading extremely slow with the UTF-8 locale
On Sat, Jan 25, 2003 at 08:12:20PM +0100, Eduard Bloch wrote: #include hallo.h * Branden Robinson [Tue, Jan 21 2003, 01:27:13PM]: I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. This may come as a deep shock to you, but your personal opinions on how Debian can best serve its users and free software are not shared by everyone else in the project. It is revealing that you ascribe differences of opinion to failures of people who disagree with you to abide by the Debian Social Contract. You still fail to see the point. If you keep a recent upstream version back, you do NOT cure the problems of other ports but actually damage the hardware support on mainstream architectures and so harm Debian's reputation. I suggest you have a talk with the Release Manager, then. It's his call to say no new upstream versions when we're in a freeze. You may also want to speak with the Stable Release Manager and determine under what circumstances he would allow a new upstream version of XFree86 into a point release of Debian 3.0. And, please, next time when you make a bad comparison, find an example that is less ridiculous. Knoppix has UTF-8 fonts, and there are much more non-latin1 using people than Americans may think. Irrelevant. Is Knoppix's XFree86 4.2.1 faster at loading the UTF-8 fonts than Debian's XFree86 4.2.1 is? If so, I detect an opportunity for someone to create a patch and file a wishlist bug. Alternatively, you can eschew the collaborative process altogether, switch to Knoppix exclusively, and tell everyone who'll listen to you to do the same. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgp9RG3kuTSw5.pgp Description: PGP signature
Re: Font loading extremely slow with the UTF-8 locale
#include hallo.h * Branden Robinson [Tue, Jan 21 2003, 01:27:13PM]: I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. I suggest you take your query upstream. Or maybe Lindows or Knoppix has solved this problem, by not having any UTF-8 fonts on the system. After all, ISO-8859-1 is the only encoding that really matters, just as i386 is the only architecture that really matters. You still fail to see the point. If you keep a recent upstream version back, you do NOT cure the problems of other ports but actually damage the hardware support on mainstream architectures and so harm Debian's reputation. And, please, next time when you make a bad comparison, find an example that is less ridiculous. Knoppix has UTF-8 fonts, and there are much more non-latin1 using people than Americans may think. Gruss/Regards, Eduard. -- Es ist sch�ner, eine sch�ne Gegend zu betrachten als zu betreten. -- Jean Paul msg05474/pgp0.pgp Description: PGP signature
Re: Font loading extremely slow with the UTF-8 locale
#include hallo.h * Branden Robinson [Tue, Jan 21 2003, 01:27:13PM]: I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. What is your problem with my attitude? As said before, my Priority are Our Users and Free Software, see Social Contract. Not personal warfares, no faulty decissions ruled by semi-technical (but personal) problems. I suggest you take your query upstream. Or maybe Lindows or Knoppix has solved this problem, by not having any UTF-8 fonts on the system. After all, ISO-8859-1 is the only encoding that really matters, just as i386 is the only architecture that really matters. You still fail to see the point. If you keep a recent upstream version back, you do NOT cure the problems of other ports but actually damage the hardware support on mainstream architectures and so harm Debian's reputation. And, please, next time when you make a bad comparison, find an example that is less ridiculous. Knoppix has UTF-8 fonts, and there are much more non-latin1 using people than Americans may think. Gruss/Regards, Eduard. -- Es ist sch�ner, eine sch�ne Gegend zu betrachten als zu betreten. -- Jean Paul pgpwMlRN52ssd.pgp Description: PGP signature
Re: Font loading extremely slow with the UTF-8 locale
On Mon, Jan 20, 2003 at 06:35:31PM +0100, Eduard Bloch wrote: I tried this with Sid version, Brandens preview packages and Daniels development tree. In all cases, I noticed a significantly high (gigantic) CPU usage when applications tried to load the Unicode equivalents of their fonts. For example, Icewm and XChat1.9 need 5..15 seconds (depending on the theme) to start. Once they started, they work fine. And normaly, with an latin locale, they start about 10 times faster. So could anyone enlighten me about what is going on? I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. I suggest you take your query upstream. Or maybe Lindows or Knoppix has solved this problem, by not having any UTF-8 fonts on the system. After all, ISO-8859-1 is the only encoding that really matters, just as i386 is the only architecture that really matters. -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://people.debian.org/~branden/ | -- J. Michael Straczynski msg05395/pgp0.pgp Description: PGP signature
Re: Font loading extremely slow with the UTF-8 locale
On Mon, Jan 20, 2003 at 06:35:31PM +0100, Eduard Bloch wrote: I tried this with Sid version, Brandens preview packages and Daniels development tree. In all cases, I noticed a significantly high (gigantic) CPU usage when applications tried to load the Unicode equivalents of their fonts. For example, Icewm and XChat1.9 need 5..15 seconds (depending on the theme) to start. Once they started, they work fine. And normaly, with an latin locale, they start about 10 times faster. So could anyone enlighten me about what is going on? I don't know why you expect help from this list after exhibiting the attitude you did in Message-ID: [EMAIL PROTECTED]. I suggest you take your query upstream. Or maybe Lindows or Knoppix has solved this problem, by not having any UTF-8 fonts on the system. After all, ISO-8859-1 is the only encoding that really matters, just as i386 is the only architecture that really matters. -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://people.debian.org/~branden/ | -- J. Michael Straczynski pgp3ZiLd3uqDu.pgp Description: PGP signature
Font loading extremely slow with the UTF-8 locale
Hello,
I tried this with Sid version, Brandens preview packages and Daniels
development tree. In all cases, I noticed a significantly high
(gigantic) CPU usage when applications tried to load the Unicode
equivalents of their fonts. For example, Icewm and XChat1.9 need 5..15
seconds (depending on the theme) to start. Once they started, they work
fine. And normaly, with an latin locale, they start about 10 times
faster. So could anyone enlighten me about what is going on?
Example from the strace log:
open(/usr/X11R6/lib/X11/locale/locale.dir, O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=28105, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4000c000
read(6, #\t$Xorg: locale.dir,v 1.3 2000/08/17 19:46:48 cpqbld Exp $\n#\n#\tThis file
contains locale database file names\n#\tThe first..., 4096) = 4096
read(6,
LC_LOCALE\t\t\tfr_CA.ISO8859-1\niso8859-15/XLC_LOCALE\t\t\tfr_CA.ISO8859-15\niso8859-1/XLC_LOCALE\t\t\tfr_CH.ISO8859-1\niso8859-15/X...,
4096) = 4096
read(6,
VISCII\niso8859-1/XLC_LOCALE\t\t\twa_BE.ISO8859-1\niso8859-15/XLC_LOCALE\t\t\twa_BE.ISO8859-15\nmicrosoft-cp1255/XLC_LOCALE\t\tyi_U...,
4096) = 4096
read(6,
TF-8/XLC_LOCALE\t\t\tlo_LA.UTF-8\nen_US.UTF-8/XLC_LOCALE\t\t\tlt_LT.UTF-8\nen_US.UTF-8/XLC_LOCALE\t\t\tlv_LV.UTF-8\nen_US.UTF-8/XLC_...,
4096) = 4096
read(6,
n_IE.ISO8859-15\niso8859-1/XLC_LOCALE:\t\t\ten_JM.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\ten_NZ.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\t...,
4096) = 4096
read(6,
SO8859-15\niso8859-1/XLC_LOCALE:\t\t\tnn_NO.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\tnn_NO.ISO8859-15\niso8859-1/XLC_LOCALE:\t\t\tny_NO...,
4096) = 4096
close(6)= 0
munmap(0x4000c000, 4096)= 0
writev(3, [{1\2\21\0\1\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3, \1\361\r\t\20\0\0\0\1\0c\10\220md\10\0\20\0\0\0\0\0\0\220md\10\0\0\0, 32) =
32
readv(3, [{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1\0\0\0, 64},
{, 0}], 2) = 64
writev(3, [{1\2\21\0\1\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3, \1\361\16\t\20\0\0\0\1\0c\10\220md\10\0\20\0\0\0\0\0\0\220md\10\0\0\0, 32)
= 32
readv(3, [{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1\0\0\0, 64},
{, 0}], 2) = 64
writev(3, [{2\2\21\0d\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3,
\1\17\tL\0\0\0\376\377\1\0\0\0\376\377\370\377\0\0\251\1\0\0\1\0\r\0\r\0\17\0, 32)
= 32
read(3, \5\0\0\0007 Ad\0\0\377\0\0\0\33\0\0\0\\0\v\0\3\0\1\0\0\0, 28) = 28
read(3,
\256\0\0\0I\1\0\0@\0\0\0J\1\0\0\257\0\0\0K\1\0\0\260\0\0\0\307\0\0\0\261\0\0\0\321\0\0\0\262\0\0\0\303\0\0\0\263\0\0\0\f\0\0\0;\0\0\0x\0\0\0\264\0\0\0K\0\0\0\265\0\0\0K\0\0\0\266\0\0\0L\1\0\0\267\0\0\0F\0\0\0\270\0\0\0\332\0\0\0\271...,
216) = 216
Etc... And:
# grep iso10646 log | wc -l
1526
Too many lookups, IMHO. Same with latin1 locale:
grep 8859 log2 | wc -l
114
Gruss/Regards,
Eduard.
--
F�r einen neuen Monitor bitte hier ==[X]== einen Nagel einschlagen.
jetzt ist ein Nagel in der Wand, und er Beamer stahlt weiter..
(ja, richtig flache Witze...)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Font loading extremely slow with the UTF-8 locale
Hello,
I tried this with Sid version, Brandens preview packages and Daniels
development tree. In all cases, I noticed a significantly high
(gigantic) CPU usage when applications tried to load the Unicode
equivalents of their fonts. For example, Icewm and XChat1.9 need 5..15
seconds (depending on the theme) to start. Once they started, they work
fine. And normaly, with an latin locale, they start about 10 times
faster. So could anyone enlighten me about what is going on?
Example from the strace log:
open(/usr/X11R6/lib/X11/locale/locale.dir, O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=28105, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4000c000
read(6, #\t$Xorg: locale.dir,v 1.3 2000/08/17 19:46:48 cpqbld Exp
$\n#\n#\tThis file contains locale database file names\n#\tThe first..., 4096)
= 4096
read(6,
LC_LOCALE\t\t\tfr_CA.ISO8859-1\niso8859-15/XLC_LOCALE\t\t\tfr_CA.ISO8859-15\niso8859-1/XLC_LOCALE\t\t\tfr_CH.ISO8859-1\niso8859-15/X...,
4096) = 4096
read(6,
VISCII\niso8859-1/XLC_LOCALE\t\t\twa_BE.ISO8859-1\niso8859-15/XLC_LOCALE\t\t\twa_BE.ISO8859-15\nmicrosoft-cp1255/XLC_LOCALE\t\tyi_U...,
4096) = 4096
read(6,
TF-8/XLC_LOCALE\t\t\tlo_LA.UTF-8\nen_US.UTF-8/XLC_LOCALE\t\t\tlt_LT.UTF-8\nen_US.UTF-8/XLC_LOCALE\t\t\tlv_LV.UTF-8\nen_US.UTF-8/XLC_...,
4096) = 4096
read(6,
n_IE.ISO8859-15\niso8859-1/XLC_LOCALE:\t\t\ten_JM.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\ten_NZ.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\t...,
4096) = 4096
read(6,
SO8859-15\niso8859-1/XLC_LOCALE:\t\t\tnn_NO.ISO8859-1\niso8859-1/XLC_LOCALE:\t\t\tnn_NO.ISO8859-15\niso8859-1/XLC_LOCALE:\t\t\tny_NO...,
4096) = 4096
close(6)= 0
munmap(0x4000c000, 4096)= 0
writev(3, [{1\2\21\0\1\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3,
\1\361\r\t\20\0\0\0\1\0c\10\220md\10\0\20\0\0\0\0\0\0\220md\10\0\0\0, 32) =
32
readv(3,
[{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1\0\0\0, 64},
{, 0}], 2) = 64
writev(3, [{1\2\21\0\1\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3,
\1\361\16\t\20\0\0\0\1\0c\10\220md\10\0\20\0\0\0\0\0\0\220md\10\0\0\0, 32) =
32
readv(3,
[{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1\0\0\0, 64},
{, 0}], 2) = 64
writev(3, [{2\2\21\0d\0\0, 8},
{-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1, 60}], 2) = 68
read(3,
\1\17\tL\0\0\0\376\377\1\0\0\0\376\377\370\377\0\0\251\1\0\0\1\0\r\0\r\0\17\0,
32) = 32
read(3, \5\0\0\0007 Ad\0\0\377\0\0\0\33\0\0\0\\0\v\0\3\0\1\0\0\0, 28) = 28
read(3, [EMAIL
PROTECTED];\0\0\0x\0\0\0\264\0\0\0K\0\0\0\265\0\0\0K\0\0\0\266\0\0\0L\1\0\0\267\0\0\0F\0\0\0\270\0\0\0\332\0\0\0\271...,
216) = 216
Etc... And:
# grep iso10646 log | wc -l
1526
Too many lookups, IMHO. Same with latin1 locale:
grep 8859 log2 | wc -l
114
Gruss/Regards,
Eduard.
--
F�r einen neuen Monitor bitte hier ==[X]== einen Nagel einschlagen.
jetzt ist ein Nagel in der Wand, und er Beamer stahlt weiter..
(ja, richtig flache Witze...)
