I _knew_ Apple was behind this somehow!
-miles
--
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arc
Vincent Lefevre writes:
> But with:
...
> int r = fegetround();
> if (r != FE_TONEAREST)
> fesetround (FE_TONEAREST);
> y = exp(x);
...
> I only get a 9% slowdown. I suppose that withing glibc code, it can
> be lower.
Makes sense... I can imagine the way overworked CPU d
Vincent Lefevre writes:
>> So... these functions were made almost an order of magnitude slower
>> in the (overwhelmingly) common case, in order to handle rare and
>> exceptional cases...?
>
> This depends on the processor. You should get a processor that
> handles rounding-mode change in a better
Vincent Lefevre writes:
>> Based on a glance at the source, it seems like the math libraries
>> were changed in lots of little ways between 2.13 and 2.16 [and it
>> looks like the FPU-twiddling that made expf slow in 2.13 has been
>> _added_ to the generic version of the "exp" (double-precision)
>
Steve Langasek writes:
>> Is there a reason that Debian has such an old version of glibc, even in
>> unstable?
>
>> The current upstream version of glibc seems to be 2.16, whereas Debian
>> has 2.13 (which is circa 2011-02).
>
> The basic reasons are that 2.14 was a dud of an upstream release, and
Is there a reason that Debian has such an old version of glibc, even in
unstable?
The current upstream version of glibc seems to be 2.16, whereas Debian
has 2.13 (which is circa 2011-02).
[The particular improvement I'm interested in is a (significantly)
faster version of the "expf" function (unf
Gergely Nagy writes:
> if upstream considers a package a core part of a platform,
> recommends *is* wrong.
Er, no.
Upstreams are not infallible, and are often quite fallible...
Upstream's "view" is a good _default_, but such judgements should be
made based on the reality on the ground.
-miles
Jeremy Bicha writes:
> I don't claim to be a networking expert, but I believe half the
> conversation here is based on wrong or outdated information.
My (personal) complaint about NM is that it doesn't correct correctly
work with NFS mounts, I believe because it doesn't run at the right
time duri
Félix Arreola Rodríguez writes:
> But, ignoring the "a desktop works fine without n-m" thing, n-m makes
> more, much more easy connecting to wifi networks, espeacially for
> laptops. I suggest make Laptop task depend on n-m, in this way, n-m
> don't get installed on desktop systems, just on laptop
Charles Plessy writes:
> I do not think there is much trolling. We need to discuss issues
> openly.
It certainly _resembles_ a classic troll: long and vaguely insulting
(under a surface veneer of politeness), yet curiously vague and
information-free, despite its length, and ending with "I'm givi
Arno Töll writes:
> On 24.06.2012 19:15, Neil Williams wrote:
>> This bug is *not* useful to anyone. Please close it and find an
>> RC bug to close instead.
>
> I'm pretty sure this could be expressed in another tone. Especially
> since we welcome everyone (you know) and we have _no_ written rule
Thomas Goirand writes:
>> Perhaps it should be
>> extended to allow the directory to be below ~/ instead of below
>> /tmp/. :)
>>
> I don't think so. As other pointed out, your /home could be
> remote (over NFS?), and then slow, while /tmp is normally
> on your local machine, so moving the temp
Brian May writes:
>>> This is not a good idea: http://mako.cc/writing/hill-free_tools.html
>>
>> MUCH seconded. Thanks for sharing the link!
>
> I don't see the problem, github is just a hosting provider. Unlike,
> say Bitkeeper, you are free to make git clones anywhere, entirely with
> open sourc
Peter Samuelson writes:
> If you can think of a way to implement this same stuff (and remember,
> bash-completion supports a _lot_ more complex cases than 'kill')
> without adding 200 kB of shell functions to bash's runtime, by all
> means, do it and see how it works out.
What would seem interest
Salvo Tomaselli writes:
>> This is indeed a valid point. But that’s no regression; /tmp has
>> always been for small short-lived files, and /var/tmp for those
>> that are not one of them or not both.
>
> You just made up this difference.
No he didn't, it's common practice from unix-days-of-yore (
Serge writes:
> I'm asking for *popular* apps, that create files in /tmp, *never put
> large files* there, and become *noticeably* faster with /tmp on tmpfs?
Is that even the issue, for the most part? My impression is that
using tmpfs is just logistically simpler and safer -- it can be
mounted v
Serge writes:
>> Every tool either supports setting TMPDIR=/var/tmp before running
>> it or is buggy. Go fix these instead
>
> Do I understand you right? You suggest every tool that need large
> tmp files to use /var/tmp instead?
That's not a new suggestion, it's been standard practice for nigh-
Jakub Wilk writes:
> ACK. /tmp on tmpfs is a nice hack (I use it myself!), but it's a
> terrible default.
I can't say whether it's a good default or not (though it seems to
work pretty well in practice), but the OP's argument is completely
silly. Most apps use /tmp not for "reducing memory usage
Paul Wise writes:
> There is smolt for that, but folks haven't packaged it for Debian yet:
>
> https://fedorahosted.org/smolt/
> http://bugs.debian.org/435058
Hmm... from "http://smolts.org/static/stats/stats.html":
The statistics script is no longer running and creating new
data. We're in
Alexander Wirt writes:
> I am just speaking for myself as listmaster. But I don't think any
> DD has more "right" to talk on a mailinglist than anybody else. I
> won't support such a proposal nor want I participate in it. If you
> have a problem with someone on a mailinglist, report it and
> listm
Bernd Zeimetz writes:
>> Er, what? Please don't throw out silly strawmen...
>
> Stephan's points are valid. Just having a link on your favourite cisco does
> not
> mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
> via radvd does not mean that you are able too acce
Stephan Seitz writes:
>>Isn't mounting filesystems, which can depend on the network, part of
>>the boot process?
>
> Yes, but how do you check if the network is configured and operational?
> - when the link is up?
> - when the IP address is configured (how do you check this with
> IPv6?)? What ar
Svante Signell writes:
> So, the
> real problem is: How do you define the boot process of a computer. For
> me it is when the kernel has been loaded by the boot media, memory,
> graphics card, etc initialized. Some modules are needed for boot, other
> modules can be loaded later. The only case I c
Adam Borowski writes:
> On Sat, Apr 14, 2012 at 11:22:06AM +0200, Jakub Wilk wrote:
>> >GLR means "Generalized Left-to-right Rightmost deviation parser"
>> >or maybe "Generalized LR parser". EBNF is the Extended BackusâNaur
>> >Form. Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty
>
"Bernhard R. Link" writes:
> For the grammer I personally would prefer it expanded, though I
> think it is more understandable as "EBNF (Extended Backus-Naur Form)
> Grammar" than the other way around.
I agree -- in reinforces the fact that these are well-known terms
which are often known by thei
David Weinehall writes:
>> Consider the case where a legal department was worried about the code
>> repository becoming "tainted" with uncontrolled or ill-considered GPL
>> obligations.
>
> If the legal department is that incompetent it's about time they got
> replaced by more competent people...
Carlos Alberto Lopez Perez writes:
> $ sudo apt-get remove network-manager*
> $ sudo apt-get install wicd wicd-curses wicd-gtk
> ^ wicd-kde ?
> $ wicd-curses
>
> And enjoy your network without the NM mess :)
... unless, of course, you're using gnome-shell,
Reinhard Tartler writes:
> On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic wrote:
>> For me d-m.o was (and still is) valuable resource.
>> Some codecs missing in Debian packages because of the policy (I don't
>> blame Debian for that) and in that case d-m.o is best option for me
>> because I don
Jonathan McCrohan writes:
> I certainly don't plan on uploading and abandoning this package, but
> given the high level of opposition to this ITP, guess there is little
> point pursuing it.
There's some whining by the usual sorts, but why would anyone pay
attention to them...?
-miles
--
Bacchu
Ian Jackson writes:
> We should not still be using this software.
Er, given that gdm3 works fine for many people, that seems excessive.
Moreover, the choice of default display manager seems unrelated to its
ability to support obscure tweaks -- indeed, it's very common for
default packages to be
Ian Jackson writes:
> Finally, the reviewer revealed in the review that they're not a native
> speaker of English. Is it normal for l10n reviews to be conducted by
> non-native speakers of the target language ? Are we really so short
> of native English speaking l10n reviewers ? If so I would b
Adam Borowski writes:
>> And things may change yet again in the future. With Btrfs, one can
>> have a single filesystem with multiple subvolumes. The subvolumes
>> can be mounted independently, and also snapshotted independently,
>> but have a common pool for free data, so unlike partitions any
Ian Jackson writes:
>> The 486-class processors that would no longer be supported are:
>> 1. All x86 processors with names including '486'
>
> I'm still running the machine below, and it would be irritating to
> have to replace it.
...
> vendor_id : CentaurHauls
> cpu family: 6
> model
Björn Esser writes:
> So how shall I name it then?
Given that there isn't actually any conflict, that the two libraries
are in different "domains" (one C/C++, the other html/javascript), and
that neither of them appears to be heavily used (though the lib used
in yast seems to get many more google
"Jaldhar H. Vyas" writes:
>> * Package name: libyui
>
> the package for the Yahoo! User Interface toolkit is called libyui-js
> which is bound to cause confusion. Can you rename yours to maybe
> libyastui or something?
"libyastui" would seem sort of misleading -- from the description, it
sou
Ben Hutchings writes:
>> I don’t think Debian requests FHS to document something before we can
>> use it. The real problem with the bizarre GNU invention that
>> is /usr/libexec is that nobody knows what it is here for.
>
> It's not a GNU invention; I believe it derives from BSD.
Yes, it original
Paul Wise writes:
>> Not a solution for the interactive mode, or am I wrong?
>
> Not AFAICT, I only read the documentation rather than the code though.
Kinda surprising, actually; this has long been the #1 most horrible
thing about aptitude, and one about which there's been plenty of
complaining.
Jakub Adam writes:
> With this additional support, a vast repository of C/C++ code can be
> checked out, built, and maintained under the CDT rather easily without
> having to resort to the command line.
Nice!
[Maybe "having to resort" is a bit judgemental in tone, though ...]
-miles
--
Logic,
Tollef Fog Heen writes:
> ]] Miles Bader
> |When cross-compiling, there shouldn't be any default fallback for
> |pkg-config if a cross-pkg-config (${ARCH}-pkg-config) isn't found;
> |the current default behavior is more harmful than useful.
>
> You c
Adam Borowski writes:
>> > AFAICT, the easiest way to handle all this is just to make a missing
>> > cross-pkg-config look like a missing pkg-config to the configure
>> > script. Then whatever logic the script may have for detecting the
>> > "not pkg-config at all" case, will do the right thing f
I earlier wrote:
> However, the current state, where it pretends pkg-config is present,
> when it really isn't in a useful way, just fools the configure script
> into doing the wrong thing.
>
> AFAICT, the easiest way to handle all this is just to make a missing
> cross-pkg-config look like a missi
Simon McVittie writes:
> That's the missing piece of the puzzle: some sort of cross-toolchain
> package (which doesn't exist yet in Debian - but neither does a
> cross-gcc) should make the symlink
>
> x86_64-w64-mingw32-pkg-config -> /usr/share/pkg-config-crosswrapper
>
> in your $PATH. For th
Simon McVittie writes:
> That's the missing piece of the puzzle: some sort of cross-toolchain
> package (which doesn't exist yet in Debian - but neither does a
> cross-gcc) should make the symlink
>
> x86_64-w64-mingw32-pkg-config -> /usr/share/pkg-config-crosswrapper
>
> in your $PATH. For th
Simon McVittie writes:
> On Thu, 15 Sep 2011 at 16:53:26 +0900, Miles Bader wrote:
>> Tollef Fog Heen writes:
>> > Your cross-toolchain is supposed to set up a symlink from
>> > /usr/bin/$triplet-pkg-config to /usr/share/pkg-config-crosswrapper which
>> >
Miles Bader writes:
> A brief browse of the pkg-config docs doesn't show any obvious
> user-level way of specifying an alternate host architecture. There's
> the environment variable "PKG_CONFIG_SYSROOT_DIR", but that seems a
> little low-level.
Also, PKG_CONFIG
Tollef Fog Heen writes:
> | I don't know how pkg-config handles multiarch either, but however
> | it detects the desired host arch (is it just the PKG_CONFIG_PATH
> | variable?), your /usr/bin/foo-config shouldn't have to care.
>
> Your cross-toolchain is supposed to set up a symlink from
> /usr/b
Josselin Mouette writes:
> I’m not a GNU package maintainer (unless you still consider GNOME a GNU
> project), so I’m not saying anything about GNU as upstream developers,
> but if you want to discuss frankly our issues with them, I hope you can
> talk about RMS and the handful of holier-than-thou
Josselin Mouette writes:
> Package: A
> Recommends: A-plugin-B {B}
> APT would be made to install A-plugin-B by default, but only if B is
> installed too. In addition, it would also have to install it while
> pulling B if A is already here.
It would be very nice!
I've noticed man
Simon McVittie writes:
> the convention is that autogen.sh *does* call ./configure
Huh? This is not my impression at all.
I'm sure there probably are packages out there where autogen.sh calls
configure, my general sense is that it usually doesn't.
Rather, autogen.m4 usually seems to act like
Josselin Mouette writes:
> For example, Thunar works perfectly fine outside Xfce, but you don’t
> want to show it in KDE or GNOME.
Why not?
Some users may prefer it to the "standard" app for the desktop
environment they're using.
-Miles
--
Politeness, n. The most acceptable hypocrisy.
--
To
Russ Allbery writes:
> I'm hesitant to recommend moving the documentation to /usr/share/doc/foo
> when we've always put it in a directory named after the package in the
> past; I'm afraid long-time Debian users won't be able to find it.
I'd certainly be confused!
Being able to just look in /usr/
Michael Banck writes:
>> Just out of curiosity, what changed with that version...?
>
> Miles, you can lookup their release notes if you like, but this question
> is really unappropriate for this list.
If such information is deemed too inflammatory, an off-list reply would
be cool too...
Thanks,
Mark Allums writes:
> In my opinion, and at risk of starting a fruitless spiral into the
> flames, I think Ubuntu have jumped on the crazy train with 10.10
> Maverick Meerkat.
Just out of curiosity, what changed with that version...?
-Miles
--
Dictionary, n. A malevolent literary device for c
Paul Wise writes:
> Usually it is a good idea to CC the allegedly MIA maintainer (done on
> this mail).
>
> Have you done any of the things suggested by the devref?
>
> http://www.debian.org/doc/developers-reference/beyond-pkging.html#mia-qa
Thanks for the tips -- I'm not a DD, so I don't think I
Hi,
He's the maintainer of the "magit" package, which doesn't seem to have
received any attention in a long time. I sent email to him a few weeks
ago, but haven't received any reply.
Has anyone had contact with Marius Vollmer, or know what's up with the
magit package?
Thanks,
-Miles
--
Innar
Python does seem a very poor choice for this kind of application, given
the traditional bloat of a python installation, but I suppose they've
made their decision...
-Miles
--
"... The revolution will be no re-run brothers; The revolution will be live."
--
To UNSUBSCRIBE, email to debian-devel
Sebastian Otaegui writes:
> Lamson's goal is to put an end to the hell that is "e-mail application
> development". Rather than stay stuck in the 1970s, Lamson adopts modern
> web application framework design and uses a proven scripting language
> (Python).
How about dropping all the breathless an
Chris Lamb writes:
> Agreed. IMHO, it is one of those phrases (along with "Our priority is
> our users") that actually means extremely little in practice, except for
> generating lots of hot air with nobody agreeing.
"Our priority is endless surreal flamewars over minor technicalities"
seems abou
Goswin von Brederlow writes:
>> Does it properly support aptitude / synaptic / etc yet?
>>
>> [The whole "print a message on stdout telling the user he'd better do
>> something else" thing was dodgy beyond belief, and clearly is not
>> acceptable for testing.]
>
> Sure the support isn't perfect ye
Goswin von Brederlow writes:
> And why should there be. The package it totally usable and functional
> as designed.
Does it properly support aptitude / synaptic / etc yet?
[The whole "print a message on stdout telling the user he'd better do
something else" thing was dodgy beyond belief, and cle
Roger Leigh writes:
> Although I use amd64, I have yet to want to install any 32bit
> software, so I'm not entirely sure what the use case is for it.
While I agree in general, I do occasionally want a more fully functional
32-bit system infrastructure. Typically this is when I need to compile
a
Yannick writes:
> Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32-
> apt-get but at the distribution level?
My impression is that it's not necessarily the abstract idea of
ia32-apt-get that's so wrong, but rather the apparently clumsy way it
was implemented.
I, at least,
Manoj Srivastava writes:
> and documentation all over the place that assumes the Debian
> default is Exim
I think that's a weakness that should be addressed regardless of what
happens with the default.
[Of course changing defaults is one way to force the issue a bit, but of
course it doesn't sto
Ben Finney writes:
>> You're arguing that a Reply-To header is "harmful" (not that I am
>> convinced)
>
> That field is very useful. What's harmful is mailing-list software
> munging that field, which is for the author to set and for nothing else
> to fiddle with.
Yup. Reply-To is for the _orig
Michael Tautschnig <[EMAIL PROTECTED]> writes:
>> > Description : Safe dialect of C
>>
>> I suggest "C-like compiler with improved security checks"
>
> I disagree - dialect is the proper technical term here.
Though the actual thing being compackage seems to be a compiler, so:
compiler f
Christian Perrier <[EMAIL PROTECTED]> writes:
> "tunnelling utility through HTTP and HTTPS proxies"
>
> to better fit the write style recommended in DevRef.
Or with correct grammar:
"utility for tunneling through http and https proxies"
-Miles
--
Generous, adj. Originally this word meant nobl
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
>> > if you appreciate using Debian as a development platform, the fact
>> > that CodeBlocks can't be built on it is IMHO a pretty critical
>> > problem.
>>
>> Why?
>
> Maybe "because not being able to build" and "development platform" don't go so
> we
Vadim Zeitlin <[EMAIL PROTECTED]> writes:
> if you appreciate using Debian as a development platform, the fact
> that CodeBlocks can't be built on it is IMHO a pretty critical
> problem.
Why?
-Miles
--
Love is a snowmobile racing across the tundra. Suddenly it flips over,
pinning you underneat
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Umm. Why would any distributed version control system always
> need history truncation? I am not even sure that arch has such a
> thing; and I have never felt the need for such a beast.
>
> A distributed VCS that bundles in the whole
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> Wearing a Debian 'user' as well as 'developer' hat, I was stopped in the
> tracks
> a few days ago when I tried to look at some C/c++ IDE (code::blocks) which
> would
> not configure on my testing box due to a lack of wxWidgets 2.8.
>
> Not nice at
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
>> I think it's going to cause a lot of confusion if you call this package
>> "lua-peg" -- _everybody_ knows it as "lpeg"...
>
> Hence, I guess, the proposed name would be "lua-lpeg", right?
That seems best... The crucial thing, I think, is that some
Enrico Tassi <[EMAIL PROTECTED]> writes:
>Package name: lua-peg
> Version: 0.7
> Upstream Author: Roberto Ierusalimschy <[EMAIL PROTECTED]>
> URL: http://www.inf.puc-rio.br/~roberto/lpeg.html
> License: MIT/X
> Description:
> LPeg is a new pattern-matching
Osamu Aoki <[EMAIL PROTECTED]> writes:
> For me, exim4 is better:
> * less memory on run time
> * mailname is implimented as expected by the policy.
Postfix has a reputation for being faster and more secure than exim.
Why is it worth worrying about, though? Are the difference between exim
and
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> If you enforce longer passwords than people are comfortable with, you
> get weaker passwords (or poor password management practices). It's
> the humans that matter, not the machines.
Exactly.
If the system is excessively anal about what passwords i
Peter Samuelson <[EMAIL PROTECTED]> writes:
> I think your problem is that you have confused "our priorities are our
> users..." with "our priority is everything icelinux believes might help
> some subset of our users". To which I can only say, get over yourself.
Do you really expect any differen
Peter Samuelson <[EMAIL PROTECTED]> writes:
>> If anyone knows how to limit the fontsize to 8 only for a otf/ttf
>> font, please contact me. (The original font is in bdf format)
>
> If this font is intended to be used at one fixed size, why bother with
> ttf/otf at all? Just ship it as bdf.
Aren'
Roger Leigh <[EMAIL PROTECTED]> writes:
> The packages he maintains and co-maintains are listed below. Most are
> GNOME packages he has not apparently uploaded. Some are already
> comaintained by others. The two of most concern are cinepaint and
> cupsys-pt, which are not comaintained. cinepain
Klaus Ethgen <[EMAIL PROTECTED]> writes:
> So please calm down and come back to the reality and do not try to see
> nazis in all thinks in the world.
Amen.
I'm reminded of vehement protests over a public official's use of the
word "niggardly"...
-Miles
--
`To alcohol! The cause of, and soluti
Eduard Bloch <[EMAIL PROTECTED]> writes:
> What is not really understandable is why this stupid naming has been
> kept in Windows XP.
Because nobody actually cares except control-freak types, and they're
certainly not who windows is targetting!
-Miles
--
`To alcohol! The cause of, and solution
Magnus Holmgren <[EMAIL PROTECTED]> writes:
>> No it doesn't.
>>
>> The "SI binary prefixes" are an abomination.
>
> Why - besides pronunciation?
Well among other things, the end result of this whole mess will likely
be to _increase_ confusion, rather than lessen it:
Until now, in a typical compu
Bastian Venthur <[EMAIL PROTECTED]> writes:
> I agree with the "sounds stupid" part, although I don't belive this is a
> valid argument. What I don't believe is your 80 colums argument. Could
> you please name a few of the *many* programs which would have to drop
> information, precision, or signif
shirish <[EMAIL PROTECTED]> writes:
> It isn't just ubuntu or debian but this needs to be done
> everywhere.
No it doesn't.
The "SI binary prefixes" are an abomination.
"Kibibytes"? Christ... [Did they try pronouncing these horrid things
when "standarizing" them?!?]
-Miles
--
We are all
Steve Greenland <[EMAIL PROTECTED]> writes:
>> Since then, it seems like most users have switched to apt-get and
>> synaptic, with hardly anyone using aptitude or dselect any more
>
> Really? I'd have guessed that most people used aptitude. I can't imagine
> anyone preferring synaptic to aptitude
Jari Aalto <[EMAIL PROTECTED]> writes:
> Le't call this "wishlist" if we need to be pedantic. I would still
> call this a bug from a QA perspective. Quality is more than "valid
> syntax".
It's not a bug from any perspective, it's you trying to legislate your
personal tastes. The place for that is
Ben Finney <[EMAIL PROTECTED]> writes:
> Meanwhile, the message header is about the message *as an email
> message*, and the From field is supposed to be about the individual
> who sent the message.
... unless there's a "Sender:" header, in which case _that's_ the person
who send the email, and th
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>>> A few more examples below. I think lzma isn't the right thing for the
>>> archive. p7zip seems much faster, needs a lot less ram and compression
>>> is similar.
..
>> Should you be using the "-9" option? The lzma help output says this:
>>
>> -
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> The etymology of the word is not english: (Hindu + stan). When
> incorporating it into English, the word came with a well defined
> meaning.
Apparently the english authors who used it didn't realize that, and I
assume their usage reflects th
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I hate to break it to you (and I do sincerely apologize for
> spoiling your innocence), but lexicons are not handed down to mankind
> on tablets writ in stone as some kind of divine donation.
I was not claiming that.
Indeed, I was claiming
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Merriam-Webster is falling into the old non-PC
> over-generalization that all inhabitants of India are Hindus.
"Merriam-Webster" isn't falling into anything, it's a dictionary, and
dictionaries describe usage.
I know from reading old books t
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> A few more examples below. I think lzma isn't the right thing for the
> archive. p7zip seems much faster, needs a lot less ram and compression
> is similar.
...
> Lzma: 34306752 Bytes
> Compressing : 19410 mrvn 0 376m 370m R 97.2 36.9 1:5
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Having eog and evince in the menu serves the "I want to look at a file I
> know I have on my disk" case. But you can open the file in the same
> number of clicks but with a better interface, by launching a nautilus
> window.
"Better interface" for som
Michael Banck <[EMAIL PROTECTED]> writes:
>> Well we shouldn't keep ourselves hostage of stupid upstream behaviour,
>> should we?
>
> Contrary to us, GNOME (in this case RedHat) actually employs usability
> experts. Who are we to think we know better?
Actual users?
-Miles
--
`...the Soviet Uni
Brian May <[EMAIL PROTECTED]> writes:
> Eventually I guessed that inkscape was a newer version of sodipodi,
> and not a competing program.
oh ... really?
That's one confusion cleared up...
-miles
--
自らを空にして、心を開く時、道は開かれる
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "un
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> The university here is opening up for Kerberos-enabled NFSv4 from the entire
> campus network RSN. Now you know one :-)
[Isn't nfs4 rather different than previous versions, in that it's
fixed some of the most egregious "nfs bogosities"?]
I use
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> That's a bad example. X is a client/server system for a reason.
>
> E.g., there is no graphical hardware for s390, yet it can still be a
> good idea to use X software on s390 hardware with X terminals.
Yeah, that's the thing -- while maintainers are us
Frank Küster <[EMAIL PROTECTED]> writes:
> .app is pretty much meaningless. Therefore I'd prefer if you'd use a
> suffix with a less arcane meaning, like -gnustep.
Does anyone truly care? Is it worth any effort to rename?
-miles
--
"Unless there are slaves to do the ugly, horrible, uninteresti
Hendrik Sattler <[EMAIL PROTECTED]> writes:
> Which OS combination does not define int to be 32bit on a 64bit architecture?
> long should better be 64bit then as many assume that you can cast a pointer
> into a long and back (e.g. timer in the linux kernel has a long for private
> data and not a
Steve Langasek <[EMAIL PROTECTED]> writes:
> It is also clear that this is how many maintainers have understood it,
> because as you yourself have noticed, there are many packages that
> assume they can ship directories in /var/run and have them remain
> available after reboot. :)
I think it's mor
Marc Haber <[EMAIL PROTECTED]> writes:
>>http://www.markshuttleworth.com/archives/56. It says 76% of Debian
>>users run unstable and probably a fair fraction of the rest run testing.
>
> I tend to doubt these numbers, especially if they come from a source
> that is known for its Ubuntu / Canonical
martin f krafft <[EMAIL PROTECTED]> writes:
>> Python (and any language that depends on vast amounts of installed
>> infrastructure) seems a bit dodgy for a core low-level facility.
>
> It's a great language to develop stuff at a moderate speed.
It may well be (kinda ugly though) -- but that doesn
1 - 100 of 292 matches
Mail list logo
