Re: CUPS should be the default print service in Debian/Sarge
Le Thu, Jul 31, 2003, à 03:09:15PM +0100, Ross Burton a écrit: > On Thu, 2003-07-31 at 15:00, Cyrille Chepelov wrote: > > if only gnome-cups-manager wasn't leaking memory like a CPU leaks > > heat...) > > Terribly sorry about this. It's only gnome-cups-icon which leaks like > mad, so you can kill that and use eggcups instead (looks almost > identical). Well, the laserjet 1100 is noisy enough that I know it has stuff in its queue, and I use the Photosmart seldom enough that I don't mind lpstat'ing when I really need a status report (in the long run, I don't mind if the cups-icon gets fixed, but people tend to become crazy if they don't get some fresh air from time to time -- at least I know why there's no activity on that bug for the moment) -- Cyrille -- pgpBoGj97kBam.pgp Description: PGP signature
Re: CUPS should be the default print service in Debian/Sarge
Le Thu, Jul 31, 2003, à 09:44:17AM -0400, Daniel Jacobowitz a écrit: > The last time I tried to use CUPS, I found it to be so user friendly > that I couldn't get it to do anything useful. Very pretty, less > functional; and the documentation was entirely inadequate. Well, while what you describe more or less matches the experience I had with CUPS 18 months ago, I don't think it still applies today (with the sarge binaries). Maybe one could charge CUPS with eating a little bit too much memory, or that funnelling the contents of linuxprinting.org[*] to enhance the foomatic-db isn't exactly user-friendly, but save from this, I find it very nice (even if I'm mostly using its lpr-compatible command-line interface. aaah, if only gnome-cups-manager wasn't leaking memory like a CPU leaks heat...) -- Cyrille [*] for a HP Photosmart 7150. --
Re: Bug#198158: architecture i386 isn't i386 anymore
Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit: > > but dropping all Pentiums until Pentium II generation > > seems completely foolish. I hope I misunderstood your message. > > I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > would count... Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support for 386 and 486, I'd love if I could keep my home edgge router running the way it is thank you very much (and I'm happy with the great job the Security Team is doing). Not that the flea market value of a Pentium Classic is that high nowadays, but why fix what works? I thought Free Software was above planned obsolescence... (note that if there is a compelling technical reason for forking i386 into i386-proper and i686, I'm happy with it. Have you seen it? I haven't so far.) -- Cyrille --
Re: Debian for x86-64 (AMD Opteron)
Le Thu, Apr 10, 2003, à 03:33:39PM +0200, Wichert Akkerman a écrit: > That way you could do something like: > > # echo x86-64 >> /etc/dpkg/legal-archs > # dpkg -i libgtk2-2.0-1_i386.deb > # dpkg -i lib64gtk2-2.0-1_x8664.deb Will we have to also have lib64gtk2.0-dev? Wouldn't that have pretty bad inconvenient consequences on the build dependencies? -- Cyrille --
Re: Debian for x86-64 (AMD Opteron)
Le Thu, Apr 10, 2003, à 10:40:47AM +0100, Hamish Marson a écrit: > I'm not sure how your logic works out that a 64 bit reg is going to be > faster than a 32bit one. Or do you mean simply you're expecting a speedu > because there are MORE 64 bit registers tahn 32 bit registers? Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC, long is 64 bit and of course any T* ). So yes, anything which plays with pointers will be larger on x86-64, but it's not an automatic doubling in size of everything. And mapping libraries twice also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even counting a large SSE2 register file as well) should help gcc feel more at home (especially with less code dedicated to handling register<->memory swap-outs) I don't have numbers to back either choice, but it looks to me that a mixed userland with everything duplicated should be a last resort. And I'm sure some people have numbers out these. Assuming a pure x86-64 (no 32 bit support) can be bootstrapped with relative ease, I guess it would be very interesting to see a couple benchmark (speed and memory) numbers against running the exact same package selection but from the i386 archive. It looks to me that the /lib-vs-/lib64 scheme should have enough room to let people make the right tradeoff between running full 32-bit (but allegedly smaller in data sizes), full 64-bit (but allegedly faster in code in some situations, and probably slightly larger in data size) or a mixture (obviously mapping common libraries twice), using their own workloads. -- Cyrille --
Re: g++ 3.2 on woody ?
Le Wed, Aug 14, 2002, à 10:15:17AM -0400, Michael Stone a écrit: > On Wed, Aug 14, 2002 at 10:00:35AM -0400, Daniel Burrows wrote: > > On Wed, Aug 14, 2002 at 08:16:46AM +0200, "J.H.M. Dassen (Ray)" <[EMAIL > > PROTECTED]> was heard to say: > > > "The main point of the GCC 3.2 release is to have a relatively stable and > > > common C++ ABI for GNU/Linux and BSD usage. Unfortunately this means that > > > GCC 3.2 is incompatible with GCC 3.0 and GCC 3.1 releases." > > > (http://gcc.gnu.org/gcc-3.2/c++-abi.html) > > > > Wasn't that the point of the GCC 3.1 release? > > I thought it was one of the promises of 3.0 :) No, you got it backwards: in fact, that will ALSO be the point of 3.3 ;-) (we can at least call ourselves lucky that they break ABIs uniformly across CPU architectures, at least so far). -- Cyrille -- Grumpf.
Re: franc,ais locale (was Re: A language by any other name)
Le ven, sep 14, 2001, à 12:39:31 -0500, David Starner a écrit: > On Fri, Sep 14, 2001 at 06:02:45PM +0200, Cyrille Chepelov wrote: > > it looks like it's because your default locale is 8859-1. > > Nope. My default locale is UTF-8. As someone else said, your headers > look fine. I stand corrected. Indeed, before I tweaked them to output 8859-15, they did output 8859-1 correctly. I'll probably follow Radovan's document in the next days or weeks, anyway. -- Cyrille -- Grumpf.
Re: franc,ais locale (was Re: A language by any other name)
Le ven, sep 14, 2001, à 09:39:55 -0500, David Starner a écrit: > On Fri, Sep 14, 2001 at 09:39:10AM +0200, Cyrille Chepelov wrote: > > (by the way, does the line mutt added at the very beginning of this post > > display completely on your screen ?) > > Here it does. The message I got was properly labeled as ISO-8859-1, too. it looks like it's because your default locale is 8859-1. I've re-read my message, and nothing there was giving hints to MUA's not using 8859-1 by default. Oh, well, let's kill this subthread -- a misconfigured MUA here, nothing more. -- Cyrille -- Grumpf.
Re: franc,ais locale (was Re: A language by any other name)
Le ven, sep 14, 2001, à 08:54:40 +0100, Oliver Elphick a écrit: > Cyrille Chepelov wrote: > >Le ven, sep 14, 2001, 04:13:31 +0900, Junichi Uekawa a crit: > ... > >(by the way, does the line mutt added at the very beginning of this post > >display completely on your screen ?) > > Your message didn't specify any character set, so the non-ASCII > characters seem to have been dropped. damn, you're right. -- Cyrille -- Grumpf.
Re: franc,ais locale (was Re: A language by any other name)
Le ven, sep 14, 2001, à 04:13:31 +0900, Junichi Uekawa a écrit: > On a very different topic, I cannot even type in > franc,ais in my system, and it seems to be a character not available > in the default locale which is C. C does not specify a charset outside ASCII, does it ? On my system, with LC_ALL=C, I surely can type and display whatever glyph is in 8859-1. What does your system, with LC_ALL=C, do with characters above 127 ? (and how does it display characters under 128 ? Romaji ?) > How are people meant to handle this? Drop outdated, region-specific encodings and switch all to a united one. In gdm's case, the specific problem of displaying "français" on an Asian box (or, for what it's worth, displaying the word "Nihongo" in one of its original scripts on an European box) has a solution not very far ahead. (by the way, does the line mutt added at the very beginning of this post display completely on your screen ?) -- Cyrille -- Grumpf.
