Re: APT 0.7 for sid
Michael Vogt schrieb am Montag, den 11. Juni 2007: Hi, *snip* > [..] > > - automatic installation of recommends like aptitude > [..] > > This is currently turned off because of the concerns raised. its a > matter of changing the default of "APT::Install-Recommends" to true. > > I want to turn it on by default in the near future, but with a > reasonable warning time for the transition. Please never make it a default. Humans make errors and I never want packages installed by default. I consider this really a dangerous option (but maybe usefull on desktops) so just integrate some kind of button in synaptic & co, but please don't make it a default. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Christian Perrier <[EMAIL PROTECTED]> wrote: > Another widely misunderstood feature of aptitude is the ability to > handle packages installed as dependencies. It's pretty often badly > understoood and leads to horror stories floating around of "aptitude > wants to remove half of the system" while the issue is just the user > not understanding the documentation that explains how to switch > properly from apt-get to aptitude. Where ist that part about switching? I couldn't find it in the TOC in html/en/index.html, nor by grepping for "apt-get" in those html files. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On 10 Jun 2007, at 6:38 pm, Steffen Moeller wrote: On Sunday 10 June 2007 17:20:54 you wrote: On 9 Jun 2007, at 11:27 am, Steffen Moeller wrote: Once a (computational) biologist starts a new project, (s)he wants the latest data no matter what and anything older than three months (or a week sometimes) is likely not to be acceptable. Actually, my experience is that they tend to want diametrically opposite things, at the same time. 1) When starting a new project, they usually want the very latest data. 2) But they usually then want to keep that data static for the lifetime of the project. :o) very true. For 1) I hink that Debian packages for databases do not work. They might well work for 2), though. ... except that they usually want several versions present at once, which would mean a completely separate package name for each release. Ick. But ... how can one directly access a feature on the genome that has no accession number because you have just found it across releases of Ensembl? * base pairs and chromosome ID does not work across (NCBI) releases * centiMorgans are too vague * distances in bp relative to the nearest genomic marker? Not too bad, probably. The easiest seems indeed to keep the data on which whatever results are computed which is diagnosed as behaviour 2). Oh, yes, I'm not saying the requirement isn't *reasonable*. It just makes life difficult! Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, 11 Jun 2007, Alexander Wirt wrote: > > I want to turn it on by default in the near future, but with a > > reasonable warning time for the transition. > Please never make it a default. Humans make errors and I never want packages > installed by default. I consider this really a dangerous option (but maybe > usefull on desktops) so just integrate some kind of button in synaptic & co, > but please don't make it a default. I disagree. Please make it the default. We need consistency and that's the intended meaning of that field. You really need to explain why it would be a dangerous option when the only problem could be that the user has installed more packages than really needed. Otherwise your disagreement is of no value. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428256: ITP: ffrenzy -- Multiplayer platform with dwarfs fighting with/for food
On Sun, Jun 10, 2007 at 10:41:43AM +0200, Paul van Tilburg wrote: > Package: wnpp > Severity: wishlist > Owner: Paul van Tilburg <[EMAIL PROTECTED]> > > * Package name: ffrenzy > Version : 1.0.2 > Upstream Authors: Bas Kloet <[EMAIL PROTECTED]>, Christian Luijten <[EMAIL > PROTECTED]>, > Emiel Neggers <[EMAIL PROTECTED]>, Bram Senders <[EMAIL PROTECTED]>, > Sjoerd Simons <[EMAIL PROTECTED]>, Paul van Tilburg <[EMAIL PROTECTED]> > * URL : http://ffrenzy.luon.net/ > * License : GPL > Programming Lang: C mainly, Python for the menu and utils > Description : Multiplayer platform with dwarfs fighting with/for food > > Dwarfs need to collect food as fast as possible to bring it back to their > mushrooms to live. When a dwars leaves his home without providing it with ^ ? > food too long, it dies from hunger. The collected food can be thrown at > other dwarfs, making them unconscious when hit. When a power-up is picked > up, thrown food will have special powers! -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428381: ftp.debian.org: proposed-updates is not part of "release a=stable"
Package: ftp.debian.org Severity: normal Since "proposed-updates" contain only approved updates for the next stable release it make sense to add it to the sources.lists (at least for some users). I have done so and I'm discovering a little quirk related to its use. Until now I had etch + proposed-updates only in my sources.list. Recently I have added sid in my sources.list and added APT::Default-Release "stable" to make sure to follow etch. All packages which already got updated via proposed-updates are now candidates for upgrade to sid... that's because proposed-updates is not labelled as being part of "release a=stable" and as such is not pinned accordingly. It has: release v=4.0-updates,o=Debian,a=proposed-updates,l=Debian,c=main Whereas etch has: release v=4.0r0,o=Debian,a=stable,l=Debian,c=main I don't know how dak works but IMO it would make more sense to have proposed-updates be: release v=4.0-updates,o=Debian,a=stable,l=Debian,c=proposed-updates/main Of course, for an experienced APT user the problem is minor. It can be solved by adding this snippet to /etc/apt/preferences: Package: * Pin: release a=proposed-updates Pin-Priority: 990 But I really believe that APT::Default-Release "stable" should be enough and do the right thing with proposed-updates as well. Cheers, -- System Information: Debian Release: 4.0 APT prefers proposed-updates APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Using standardized SI prefixes
Hi all, Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 & Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Using standardized SI prefixes
Ugh, The second example I wanted to give was of libburnia http://libburnia-project.org/changeset/877 . Sorry -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, 11 Jun 2007, Alexander Wirt wrote:
> Please never make it a default. Humans make errors and I never want packages
Recommends *are* to be installed by default, unless you specifically tell
the tool not to. This is the whole point, one that has been broken for a
few *years* now and has caused problems to everyone for that long.
It is high time to either remove apt-get, or to just damn fix it to actually
do what it is supposed to do. apt-get can't continue living on as a
"mostly debug tool" when it is used everywhere as a main admin tool.
Heck, some misguided soul even made a slogan out of it ("apt-get into it")
to promote Debian. Let's fix the damn thing already.
I am sick of telling users that "you did not install a recommended package,
that's why it is not working as you expect it to", because they use broken
package managers.
> usefull on desktops) so just integrate some kind of button in synaptic & co,
synaptic & co are also broken in a very bad way if they do not offer to
install recommends by default (and broken in a very bad usability way if you
can't tell them that no, you don't want that recommended package installed).
Just fix them. dselect was fixed a long time ago, and aptitude does this
right since day one (AFAIK anyway).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: > Really? I'd have guessed that most people used aptitude. I can't imagine > anyone preferring synaptic to aptitude. Of course, I don't really > understand why anyone prefers [any graphical MUA] to mutt, or [any > graphical newsreader] to trn. I mean, GUIs are nice for things you don't > use every day, but for serious work, they're so damn slow and klutzy. My mum uses synaptic. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Fri, Jun 08, 2007 at 01:01:18PM +0200, Gabor Gombas wrote: > On Fri, Jun 08, 2007 at 11:36:57AM +0100, Luis Matos wrote: > > > i have 2 servers that i only login for apt-get update && apt-get upgrade > > -y, they are running sarge (yet) and only install security upgrades. > > > > These 2 server will not be put in danger by making the update && upgrade > > in an autonomous way. > > IIRC a security update in sarge changed sudo's behaviour and that broke > many local scripts. We decided that the security threat addressed by the > update was basically zero and went back to the old version - finding & > fixing all the broken scripts was simply not worth the effort. > > So an automatic security update _can_ break a working server. Yes, of course. *Any* change to the software might break a working system, either because it introduces or uncovers bugs, or because it changes something a script or third-party app relies on. Perhaps an automatic security update system could make use of additional info (local or remote exploit, etc) to offer more control over the balance of risks. Would such a system have saved you from unnecessary automated breakage ? Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
shirish wrote: Hi all, Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 & Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. I support your request. Although I think this isn't a big deal for the average user, it is pretty confusing from time to time since you can't be sure what a k actually means. This standard you're talking about exists for a while now but it seems that people (programmers) are adapting really slow. We could do the community a favor by doing what's in our possibility and push the adoption a bit further. Cheers, Bastian PS: Next time please use your real name when posting to Debian mailing lists. -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le lundi 11 juin 2007 à 18:27 +0530, shirish a écrit : > Hi all, > Please look at http://en.wikipedia.org/wiki/Binary_prefix . I > put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 & > Aaron helpfully said it needs more discussion. I have had great > support from libtorrent code.rasterbar.com as well as the guys at > deluge http://dev.deluge-torrent.org . > The difference is simply astonishing to put aside if let's say a > download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB > (70/1024) . Please lemme know what you guys think about it ? > It isn't just ubuntu or debian but this needs to be done > everywhere. Have something accurate. FWIW, this is already the case in GNOME. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
ITP: pysycache-- Educational game to teach children to move the mouse
Package: wnpp Severity: wishlist Owner: José L. Redrejo Rodríguez <[EMAIL PROTECTED]> * Package name: pysycache Version : 3.0.1 Upstream Author : Vincent Deroo <[EMAIL PROTECTED]> * URL : http://www.pysycache.org/ * License : GPL Description : Educational game to teach children to move the mouse The application offers some activities based on simple objects, photographies, numbers and letters with their sounds in different languages. The activities make children practice on clicking, double-clicking, drag and drop, moving and identify the mouse buttons. From its website many packages can be downloaded to add new photos and text to the activities. signature.asc Description: Esta parte del mensaje está firmada digitalmente
The Shell: arithmetic comparison with void
If was time, where string comparisons with void were ... with features. |-*- if [ "x$a" = 'x|' ]; then |-*- Yet arithmetic ones are still with them: |-*- [EMAIL PROTECTED]:/tmp$ bash -c "test '' -eq 0 ; echo \$?" bash: line 0: test: : integer expression expected 2 [EMAIL PROTECTED]:/tmp$ dash -c "test '' -eq 0 ; echo \$?" 0 [EMAIL PROTECTED]:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?" 0 [EMAIL PROTECTED]:/tmp$ |-*- Ah, bash is clever? |-*- [EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf '\t'\" -eq 0 ; echo \$?" test " " -eq 0 ; echo $? 0 [EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf ' '\" -eq 0 ; echo \$?" test " " -eq 0 ; echo $? 0 [EMAIL PROTECTED]:/tmp$ bash -c -v "test \"printf 'a'\" -eq 0 ; echo \$?" test "a" -eq 0 ; echo $? bash: line 0: test: a: integer expression expected 2 [EMAIL PROTECTED]:/tmp$ |-*- Nope? Are there bugs or features? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 14:57, shirish wrote: > Please look at http://en.wikipedia.org/wiki/Binary_prefix . I > put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 & > Aaron helpfully said it needs more discussion. I have had great > support from libtorrent code.rasterbar.com as well as the guys at > deluge http://dev.deluge-torrent.org . > The difference is simply astonishing to put aside if let's say a > download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB > (70/1024) . Please lemme know what you guys think about it ? > It isn't just ubuntu or debian but this needs to be done > everywhere. Have something accurate. I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? -- Magnus Holmgren pgpaVIzYUqkyh.pgp Description: PGP signature
Re: Using standardized SI prefixes
Magnus Holmgren wrote: I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? I think we should go for the binary prefixes. Users will be confused when they read 1k and notice that the package has 'just' 1000 bytes. Plus, the 2^n presentation is much more common in the IT world than the 10^n presentation. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Henrique de Moraes Holschuh wrote: > On Mon, 11 Jun 2007, Alexander Wirt wrote: >> Please never make it a default. Humans make errors and I never want packages > > Recommends *are* to be installed by default, unless you specifically tell > the tool not to. This is the whole point, one that has been broken for a > few *years* now and has caused problems to everyone for that long. [..] > synaptic & co are also broken in a very bad way if they do not offer to > install recommends by default (and broken in a very bad usability way if you > can't tell them that no, you don't want that recommended package installed). > Just fix them. dselect was fixed a long time ago, and aptitude does this > right since day one (AFAIK anyway). > FWIW, synaptic has an option in its preferences dialog called "Consider recommended packages as dependencies", which is off by default. I completely agree, to treat Recommends as "weak dependencies" and install them by default and make that behaviour consistent among all package managers. The frontends imho just need a clear way of showing which packages are going to be installed because of a Depends and which because of a Recommends, so it would be easier to de-select a recommended package. Otherwise there would be no point having Suggests and Recommends, if they are basically treated the same by the package management tool. Just my 2¢, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
(no subject)
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (no subject)
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Francois-Denis Gonthier wrote: > unsubscribe > > mm... crap I'm really sorry. - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAwECABS3FuvxegTt63v7UWCF iSdtKgVqvAMAFNtYnPf/czq1EyEfvnKRBT4kXaMpBAAUDuTQouyueK8rYsc0K72n8XinFeoF ABTaOaPuXmtLDTJVv++VYBiQr9gHCQYAFBL7zffDNIBf5j18CuIdHHV6nHddBwAU+nHOBUjC gttJMc67xnzu+UGHwYwRABgAAABOIEZtcu0AAcu4EU4TAAQAggP8 DjLQGHZNcebX7OWD4kQ+Bh95Om++g1sMfnlMyZLu0Q1PB7ZyoYZPJEt203o0PBNJaeG8Fnwo sM4JShLe3ow7pdIUkp6X3/fr/kAOKXZgXAOT0q6tQpGMskFT5Gqsm/CL5XOwyMl/DJZzoFc1 z2zLlRvf4CY2ilKyd40tl2qOVDw= - KRYPTIVA SIGNATURE END - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: > On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: > > Diskspace *is* a problem for mirrors, as is bandwidth in many countries. > > Also, you should think about this issue not just in the context of the > > single package you are interested in but as a general policy. > > Honnestly, no, this is not true anymore nowadays. With a 500Gb sata > hard drive, you're able to have a full debian mirror (all archs). Such a > disk is around 100€ nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. A typical 300GB server-class hotpluggable SATA or SAS disk is quite a bit more expensive than a typical desktop-class 500GB hard disk, and for a RAID setup that will actually survive the breakdown of a number of moving parts parts, you'll need at least four or five of them. Disk space is *not* cheap, and using it as an argument to add more packages to the archive is stupid. Additionally, network bandwidth isn't cheap, either, and the update of a number of 400MB packages might disrupt the (twice-daily) mirror pulse. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 05:14:18PM +0200, Bastian Venthur wrote: > Magnus Holmgren wrote: > > >I'm in favour! (But are you requesting that aptitude use SI prefixes > >correctly, or that it use IEC (binary) prefixes? > > I think we should go for the binary prefixes. Users will be confused > when they read 1k and notice that the package has 'just' 1000 bytes. > Plus, the 2^n presentation is much more common in the IT world than the > 10^n presentation. Not for network bandwidth, and less and less for storage space (commercials do understand what a "free" 7.5% bonus means, i.e. selling something as 7.5% larger when it is in fact the same that it used to be). I do agree, that especially in the case of filesystem organisation, it makes much more sens to use the binary units. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Raphael Hertzog schrieb am Montag, den 11. Juni 2007: > On Mon, 11 Jun 2007, Alexander Wirt wrote: > > > I want to turn it on by default in the near future, but with a > > > reasonable warning time for the transition. > > Please never make it a default. Humans make errors and I never want packages > > installed by default. I consider this really a dangerous option (but maybe > > usefull on desktops) so just integrate some kind of button in synaptic & co, > > but please don't make it a default. > > I disagree. Please make it the default. We need consistency and that's the > intended meaning of that field. > > You really need to explain why it would be a dangerous option when the > only problem could be that the user has installed more packages than > really needed. Otherwise your disagreement is of no value. Args it was too early in the morning. Please forget my mail. I was at the "install security updates automatically feature". Sorry the he mess. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
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 lying in the gutter, but some of us are looking at the stars. -Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Hi, On Mon, Jun 11, 2007 at 05:39:54PM +0200, Michael Biebl wrote: > FWIW, synaptic has an option in its preferences dialog called "Consider > recommended packages as dependencies", which is off by default. > > I completely agree, to treat Recommends as "weak dependencies" and > install them by default and make that behaviour consistent among all > package managers. > > The frontends imho just need a clear way of showing which packages are > going to be installed because of a Depends and which because of a > Recommends, so it would be easier to de-select a recommended package. For synaptic, I think it would be fine if Recommends were marked as such in the window which pops up when you select a package; right now Depends and (if you select the above option) Recommends are just mentioned as "Will be installed" (at least in my outdated version of synaptic). Synaptic could mark them as Recommends there and offer a check-box for each, so people could easily unmark recommended packages they do not want installed at this point (though maybe it should be pointed out (once) that doing so might be unwise). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 18:53, Miles Bader wrote: > 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. Why - besides pronunciation? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQQ5itw9oLY.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 07:05:23PM +0200, Magnus Holmgren wrote: > Why - besides pronunciation? Aren't the names enough? :) Maybe they could have called them Kilobin bytes and Megabin bytes or something somewhat less awful sounding that they came up with. Did they even talk to anyone that might actually use the units? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
I prefer not to use these new prefixes, because the old ones only became confused due to the efforts of drive manufacturers. Who are perfectly capable (and equally financially motivated) of pulling the same trick with the new units, standards body or no. Also, the "ib" prefixes sound stupid. Furthermore, the "KiB" abbreviation wastes a lot more screen space than "K", while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the "KiB" unit. Debian has approximately as small of a chance standarising this throughout the distribution as we do standadising the spelling of "colo[u]r" or "standardi[sz]e" throughout the distribution. (On the other hand, I am one of the minority of people in the world who still prefer imperial measures, so apply salt to taste.) (On the third hand, I am a proponent of binary or decimal time and date representations. Down with bases 12, 60, and 30+-1 !) -- see shy jo signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
On Sun, Jun 10, 2007 at 06:59:49PM +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: > > On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: > > > Diskspace *is* a problem for mirrors, as is bandwidth in many countries. > > > Also, you should think about this issue not just in the context of the > > > single package you are interested in but as a general policy. > > > > Honnestly, no, this is not true anymore nowadays. With a 500Gb sata > > hard drive, you're able to have a full debian mirror (all archs). Such a > > disk is around 100€ nowadays. > > ... but it will break down in three months with the typical usage > pattern of a public Debian mirror. > > A typical 300GB server-class hotpluggable SATA or SAS disk is quite a > bit more expensive than a typical desktop-class 500GB hard disk, and for > a RAID setup that will actually survive the breakdown of a number of > moving parts parts, you'll need at least four or five of them. Actual data seems to show the cheap desktop disks are not worse than so-called server-class disks. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, Jun 11, 2007 at 07:03:47AM +0200, Christian Perrier <[EMAIL PROTECTED]> wrote: > > upgrade path for two releases now, with its Recommends: handling being a > > major reason for this. I'd be surprised if there weren't at least *some* > > users switching to it as a result. > > > Developer users probably. The ones that resist are more non-developer > users. I'm constantly being annoyed at work with so-called systems > administrators pinging /me about "my Debian box upgrades badly" which > is nearly always the consequence of the use of apt-get for upgrades. > > And I can definitely confitm that, when one just answers "read the > bloody release notes and learn about aptitude", the surprise is often > very high when people discover that the recommended tool is aptitude > and not apt-get. > > There are so many examples all around the web with various apt-get > calls and pretty few with aptitude. In these days where googling > becomes a synonym of "read the documentation", it hurts badly. > > Another widely misunderstood feature of aptitude is the ability to > handle packages installed as dependencies. It's pretty often badly > understoood and leads to horror stories floating around of "aptitude > wants to remove half of the system" while the issue is just the user > not understanding the documentation that explains how to switch > properly from apt-get to aptitude. The fact is : users don't read documentation. Software should be designed considering this fact. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Joey Hess wrote: I prefer not to use these new prefixes, because the old ones only became confused due to the efforts of drive manufacturers. Who are perfectly capable (and equally financially motivated) of pulling the same trick with the new units, standards body or no. Also, the "ib" prefixes sound stupid. Furthermore, the "KiB" abbreviation wastes a lot more screen space than "K", while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the "KiB" unit. Ok, "sounds stupid" and "may not fit on 80 column" screen. 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 significantly change their display to use the "KiB" unit? On the other hand, we have the chance to avoid user confusion and follow a standard that (according to the wikipedia article) many already adopted, like the GNU core utils, the linux kernel, ifconfig, launchpad and gparted and many standards bodies and technical organizations like IEEE, CIPM, NIST, and SAE. Debian has approximately as small of a chance standarising this throughout the distribution as we do standadising the spelling of "colo[u]r" or "standardi[sz]e" throughout the distribution. One is correct American- and the other correct British English spelling. I don't see the problem. I think there is already a l10n for package descriptions project going on to solve this problem, so we don't have to standardi[sz]e one of them ;) Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On 06/11/07 12:28, Mike Hommey wrote: On Sun, Jun 10, 2007 at 06:59:49PM +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: Diskspace *is* a problem for mirrors, as is bandwidth in many countries. Also, you should think about this issue not just in the context of the single package you are interested in but as a general policy. Honnestly, no, this is not true anymore nowadays. With a 500Gb sata hard drive, you're able to have a full debian mirror (all archs). Such a disk is around 100€ nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. A typical 300GB server-class hotpluggable SATA or SAS disk is quite a bit more expensive than a typical desktop-class 500GB hard disk, and for a RAID setup that will actually survive the breakdown of a number of moving parts parts, you'll need at least four or five of them. Actual data seems to show the cheap desktop disks are not worse than so-called server-class disks. If your data center infrastructure is based around SCSI or SAS, then it's irrelevant how much better or worse they are. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 10-Jun-07, 20:16 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: > On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: > > On 10-Jun-07, 17:47 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > 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. Of course, I don't really > [..] > > Steve the hopelessly out-of-date > > dselect still works, fwiw ;) Oh, I know. I used it extensively. One of the things I miss in aptitude is the ability to get alternate sorting via 'o' and 'O'. I never quite understood the distinction in dselect, but I knew that if I kept pounding 'o' (or 'O'), I'd eventually cyle around to the sorting order I wanted. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 11-Jun-07, 08:45 (CDT), Michael Banck <[EMAIL PROTECTED]> wrote: > On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: > > Really? I'd have guessed that most people used aptitude. I can't imagine > > anyone preferring synaptic to aptitude. Of course, I don't really > > understand why anyone prefers [any graphical MUA] to mutt, or [any > > graphical newsreader] to trn. I mean, GUIs are nice for things you don't > > use every day, but for serious work, they're so damn slow and klutzy. > > My mum uses synaptic. Of course she does. If I was setting up a Debian box for my mother (or any other new convert from Windows or OSX), I'd show her synaptic, too. I'm not insane. Nor was my comment meant to bash synaptic (or GUI tool users); as I noted, for things that I use rarely, GUI frontends are nice. Actually, my comment was mostly meant to keep Daniel from getting depressed and dropping aptitude :-) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 19:26, Joey Hess wrote: > I prefer not to use these new prefixes, because the old ones only became > confused due to the efforts of drive manufacturers. Who are perfectly > capable (and equally financially motivated) of pulling the same trick > with the new units, standards body or no. I don't believe that to be true. There are other computer-related contexts where SI prefixes aren't used for powers of two, although perhaps most of them don't involve bytes. For an average user, knowing two sets of prefixes should be easier than knowing exactly in which situations to interpret the SI prefixes as binary prefixes. Drive manufacturers used the SI prefixes in the correct, albeit unexpected way. The fact is that with the IEC prefixes, all ambiguity is removed, so if someone claims that a storage device is 32 GiB when it's in fact 32 GB, there can be no doubt as to the fact that they are lying. Or what kind of tricks did you have in mind? > Also, the "ib" prefixes sound stupid. Furthermore, the "KiB" > abbreviation wastes a lot more screen space than "K", while actually > converying no additional useful information. Many programs use every > available character in a nominal 80 column screen and would have to drop > information, precision, or significantly change their display to use the > "KiB" unit. You seem to fancy the K-is-1024--k-is-1000 convention, which doesn't work with any higher power. But even if we accept that K unambiguously equals 1024, then to be consistent either K should be KB or KiB can be shortened to Ki. That's a single character, not "a lot". > Debian has approximately as small of a chance standarising this > throughout the distribution as we do standadising the spelling of > "colo[u]r" or "standardi[sz]e" throughout the distribution. If everybody waits for somebody else to change first, then no change can ever happen. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) "Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack)" -- Dave Evans pgppwi26TZ4dd.pgp Description: PGP signature
Re: Using standardized SI prefixes
Hi, * Bastian Venthur <[EMAIL PROTECTED]> [2007-06-11 20:09]: [...] > Ok, "sounds stupid" and "may not fit on 80 column" screen. > > 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 > significantly change their display to use the "KiB" unit? Don't we have $COLUMNS? :) Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpLN6YNtsTE2.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 20:06, Bastian Venthur wrote: > 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 significantly change their display to use the > "KiB" unit? What I'm missing in this request is the practical use. The original example given at the start of this thread was: Package: filezilla State: not installed Version: 3.0.0~beta10-0ubuntu1 Priority: optional Section: universe/net Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]> Uncompressed Size: 2134k Can you tell me in which cases you would make a different decision if this was either 2134*1000 or 2134*1024 bytes? In either case, ~ 2 million bytes suits your requirement, or it doesn't. This sounds to me like solving a non-problem, unless you can of course tell me in which situations adding the "B" or "iB" in the field above would solve a real question. thanks, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 07:28:13PM +0200, Mike Hommey wrote: > On Sun, Jun 10, 2007 at 06:59:49PM +0100, Wouter Verhelst <[EMAIL PROTECTED]> > wrote: > > > > A typical 300GB server-class hotpluggable SATA or SAS disk is quite a > > bit more expensive than a typical desktop-class 500GB hard disk, and for > > a RAID setup that will actually survive the breakdown of a number of > > moving parts parts, you'll need at least four or five of them. > > Actual data seems to show the cheap desktop disks are not worse than > so-called server-class disks. > That may be true when it comes to breakdowns. However, I challenge you to show me a "cheap" desktop disk that is also SCSI or SAS *and* hotpluggable. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 20:38, Thijs Kinkhorst wrote: > On Monday 11 June 2007 20:06, Bastian Venthur wrote: > > 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 significantly change their display to use the > > "KiB" unit? > > What I'm missing in this request is the practical use. > [...] > Can you tell me in which cases you would make a different decision if this > was either 2134*1000 or 2134*1024 bytes? > > In either case, ~ 2 million bytes suits your requirement, or it doesn't. > This sounds to me like solving a non-problem, unless you can of course tell > me in which situations adding the "B" or "iB" in the field above would > solve a real question. In many cases the difference is insignificant. It's the consistent use of IEC vs SI units everywhere that give the big benefits. Since the effort needed to convert a piece of software is in the vast majority of cases tiny, it's worth it. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpAzvsgKQDo0.pgp Description: PGP signature
Re: Using standardized SI prefixes
Bastian Venthur wrote: > I agree with the "sounds stupid" part, although I don't belive this is a > valid argument. It's a perfectly valid argument for me to use to ignore a bad standard. If the standard makes me talk funny, I will ignore it or make fun of it. (Bibibibibibibibibibib.) > 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 significantly change their display to use the > "KiB" unit? iftop, top, ls, and df are the first few to come to mind. > On the other hand, we have the chance to avoid user confusion and follow > a standard that (according to the wikipedia article) many already > adopted, like the GNU core utils, the linux kernel, ifconfig, launchpad > and gparted and many standards bodies and technical organizations like > IEEE, CIPM, NIST, and SAE. Note that wikipedia is rarely perfectly accurate on technical matters. And coreutils does not consistently use the SI prefixes. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 15:07, shirish wrote: > Ugh, >The second example I wanted to give was of libburnia > http://libburnia-project.org/changeset/877 . Sorry Uh, tell them that kiB should be KiB. Don't ask me why. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpXOeIiuxsxj.pgp Description: PGP signature
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 07:28:13PM +0200, Mike Hommey wrote: > Actual data seems to show the cheap desktop disks are not worse than > so-called server-class disks. My "actual data" does not back up your claim. Moreover, desktop-class hard disks never support hotplugging, which you really want for a publically-accessible mirror. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Monday 11 June 2007 13:09:40 Roberto C. Sánchez wrote: > That may be true when it comes to breakdowns. However, I challenge you > to show me a "cheap" desktop disk that is also SCSI or SAS *and* > hotpluggable. While not SCSI or SAS, there are SATA controllers that support hotplugging drives. wt -- Warren Turkal
Re: Using standardized SI prefixes
Magnus Holmgren wrote: > I don't believe that to be true. There are other computer-related contexts > where SI prefixes aren't used for powers of two, although perhaps most of > them don't involve bytes. For an average user, knowing two sets of prefixes > should be easier than knowing exactly in which situations to interpret the SI > prefixes as binary prefixes. Drive manufacturers used the SI prefixes in the > correct, albeit unexpected way. The fact is that with the IEC prefixes, all > ambiguity is removed, so if someone claims that a storage device is 32 GiB > when it's in fact 32 GB, there can be no doubt as to the fact that they are > lying. Or what kind of tricks did you have in mind? The kind of tricks that a company with a marketing department typically comes up with, not me. > > Also, the "ib" prefixes sound stupid. Furthermore, the "KiB" > > abbreviation wastes a lot more screen space than "K", while actually > > converying no additional useful information. Many programs use every > > available character in a nominal 80 column screen and would have to drop > > information, precision, or significantly change their display to use the > > "KiB" unit. > > You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hallo, On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Alex Queiroz wrote: > Hallo, > > On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: > > > >No, I hate that convention. K and k should only ever refer to 1024. > > > > Like in kg or km? This thread is about units of data. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hallo, On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: Alex Queiroz wrote: > Hallo, > > On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: > > > >No, I hate that convention. K and k should only ever refer to 1024. > > > > Like in kg or km? This thread is about units of data. The prefix don't change according to the unit type. -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:25, Joey Hess wrote: > Magnus Holmgren wrote: > > You seem to fancy the K-is-1024--k-is-1000 convention > > No, I hate that convention. K and k should only ever refer to 1024. In that case you're just sloppy. Prefixes and symbols for units are case sensitive. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpzpLOoR9VqR.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:41, Joey Hess wrote: > Alex Queiroz wrote: > > On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: > > >No, I hate that convention. K and k should only ever refer to 1024. > > > > Like in kg or km? > > This thread is about units of data. kbit? kbit/s? kB/s? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpLBBfO2s64p.pgp Description: PGP signature
Re: Using standardized SI prefixes
Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : > > You seem to fancy the K-is-1024--k-is-1000 convention > > No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 01:24:34PM -0600, Warren Turkal wrote: > On Monday 11 June 2007 13:09:40 Roberto C. Sánchez wrote: > > That may be true when it comes to breakdowns. However, I challenge you > > to show me a "cheap" desktop disk that is also SCSI or SAS *and* > > hotpluggable. > > While not SCSI or SAS, there are SATA controllers that support hotplugging > drives. Whatever. The point wasn't that you can't set up a professional RAID array using cheap desktop hard disks; you can, if you really want to, though I wouldn't recommend it. And yes, you're completely free to ignore that particular advise, so long as you don't expect me to become a customer of yours. The point was that a single 500G hard disk just doesn't cut it for a publically-accessible Debian mirror; that you need much more than that, both in terms of quality (hotpluggable controllers don't really help if your disks aren't ready for hotplugging--which is usually the case for cheap desktop-class hard disks--possibly other interfaces than the popular SATA connection, and preferably also disks that have had way more testing than desktop-class hardware) so that "there is this set of cheap crappy hard disks that are large enough so that you can store an entire Debian archive on it" is a ridiculous argument in favour of "throwing every insanely large piece of junk into a Debian package and onto the Debian archive". Note that that also doesn't talk about *what* exactly defines the line between "an insanely large piece of junk" and "a piece of interesting data large enough to be useful, but not so large as to become a problem". The borderline there would seem to be rather gray. Personally, I'd advice the OP to try to find the smallest data set that is still at least moderately useful for the package, and to package that (so that people not familiar with the software or the type of data it requires can still try it out), unless that would require a package larger than a few tens of megabytes. Additionally, it would be useful to point in the package description and/or its documentation to either a way to automatically generate debs out of a larger data set so that users can generate their own data debs and distribute them on their own network, or to a separate debian archive that they can add to their sources.list if they want. I don't think setting a hard limit (as in, with numbers) on maximum recommended package size is a very good thing to do; I'm tempted to think that this kind of limit is not really static over time, and thus that wording such as "roughly two times the average package size at the time the package is created" or so would be more appropriate. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : > The point wasn't that you can't set up a professional RAID array using > cheap desktop hard disks; you can, if you really want to, though I > wouldn't recommend it. And yes, you're completely free to ignore that > particular advise, so long as you don't expect me to become a customer > of yours. You seem to strongly believe the cheap desktop hard disk is different from the server hard disk. This is entirely wrong. Apart from 10k and 15k rpm disks, these are all strictly the same. Only the electronics change. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
#include * Thijs Kinkhorst [Mon, Jun 11 2007, 08:38:11PM]: > On Monday 11 June 2007 20:06, Bastian Venthur wrote: > > 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 significantly change their display to use the > > "KiB" unit? > > What I'm missing in this request is the practical use. > > The original example given at the start of this thread was: > > Package: filezilla > State: not installed > Version: 3.0.0~beta10-0ubuntu1 > Priority: optional > Section: universe/net > Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]> > Uncompressed Size: 2134k > > Can you tell me in which cases you would make a different decision if this > was > either 2134*1000 or 2134*1024 bytes? > > In either case, ~ 2 million bytes suits your requirement, or it doesn't. > This sounds to me like solving a non-problem, unless you can of course tell > me > in which situations adding the "B" or "iB" in the field above would solve a > real question. Excuse me? Pretty simple example: you have only 2.03 GB (real GB) remaining free space (seen in some disk info tool) on your harddisk and you are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it breaks about 99% and displays some very unexpected message. I hate this disambiguation since I had to deal with lots of 1.44MB floppies. Oh wait, was there 1.48MB? 1.39MB? Or 1.4MB? Or 1,440MB? Or what was the point again? The point is that some old bad idea of how a real-world prefix can be abused in computer world has burned so deep into the minds of even respectable people that it seems to need another four decades to make people use the correct terms again. Eduard. -- Getty: Solche Aussagen tätigt man hier nicht - sonst kommt wieder der weasel daher und zitiert einen auf der #-Seite! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 10:22:32PM +0200, Josselin Mouette wrote: > Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : > > The point wasn't that you can't set up a professional RAID array using > > cheap desktop hard disks; you can, if you really want to, though I > > wouldn't recommend it. And yes, you're completely free to ignore that > > particular advise, so long as you don't expect me to become a customer > > of yours. > > You seem to strongly believe the cheap desktop hard disk is different > from the server hard disk. This is entirely wrong. Apart from 10k and > 15k rpm disks, these are all strictly the same. Only the electronics > change. You seem to strongly believe that I care about things that are totally (and I mean *totally*) beside my point. This is entirely wrong. Apart from the fact that it *may* be a data point to some, my post wasn't about the reliability, or lack thereof, of desktop-class hard disks. Now go back, read my mails again, and please reply to the actual content this time. Thanks. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Enter Postpone
Hi,
316 + 0,9K Jun 10 22:32 Debian Installe cb+myon=de
postpone_0.1_amd64.changes is NEW
320 + 0,4K Jun 11 12:30 Debian Installe cb+myon=de
postpone_0.1_amd64.changes ACCEPTED
looks like postpone got fast-tracked in the NEW queue (thanks Joerg!),
so here's what I posted in my blog yesterday again:
--- 8< ---
I just finished implementing postpone [1], a wrapper that is intended
to take an arbitrary command, fork into the background, wait until
some lockfile is freed, and then run the command. Of course the idea
is that the lockfile is /var/lib/dpkg/lock, and that postpone is used
in maintainer scripts. (Update-menus already does that, and I've
basically grabbed that code and generalized it as a separate program.)
As a test implementation, I modified the post{inst,rm} templates in
the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg
-i texlive-lang-*.deb takes over 4 minutes in the old version, but
only a total of 60s with postpone used (35s for dpkg -i plus 25s for
the background jobs).
A Debian package is currently sitting in NEW, let's hope it will
actually get used in maintainer scripts.
[1] http://www.df7cb.de/projects/postpone/
[2] http://www.df7cb.de/projects/postpone/texlive/
--- >8 ---
NB, the .diff in [2] is meant as a test implementation and in fact,
I've probably missed some details in the way fmtutil-sys is called.
(And while looks like an NMU, I don't intend to upload it but will
leave the implementation of the maintainer scripts to the experts.)
There's a few other postinst/postrm jobs that could benefit from
postpone:
* python modules
* emacs
* ldconfig
* install-docs can probably factor out some parts
* update-dictcommon-aspell, aspell-autobuildhash, etc.
* defoma, other font stuff
* scrollkeeper
* anything re-starting some init script (though catching exit code
won't work anymore)
* maybe even update-menus
* ...
Of course, there are cases where running later is not always
appropriate (ldconfig is a candidate), so this need to be decided on a
case-by-case basis.
For good new, the maintainer scripts are most often generated by
debhelper or some other utility, so there's actually not much to
change to use postpone. (Otherwise, only few packages are affected so
there's not much to gain). And there's the question whether to depend
on postpone or have the maintainer script implement both cases
(postrm scripts might need to do this anyway).
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
SCSI drives for donation
I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using for anything interesting. Can anyone tell me if these would be useful to Debian or recommend another free software group to donate them? Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o
On Sun, Jun 10, 2007 at 06:46:48PM +0200, Frank Küster wrote: > Michael Banck <[EMAIL PROTECTED]> wrote: > > >> > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > >> > > >> > Any idea? > >> > >> I have none, is anyone able to help? Is this a problem in the script > >> that generates packages.debian.org's information, or elsewhere? Will investigate. > I'm not looking for an authoritative answer, but rather for useful > information on the web, for users and for other developers. Who is > responsible for p.d.o? Bugs should be filed against www.debian.org Most pdo pages also have the following footer which might have helped you: "To report a problem with the web site, e-mail [EMAIL PROTECTED]" Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
On Sun, Jun 10, 2007 at 02:17:49PM +0200, Frank Küster wrote: > Florent noticed that for tex-common, two versions are listed as being > available in testing although the package is Arch: all: > Florent Rougon <[EMAIL PROTECTED]> wrote: > > > BTW, I don't understand why both 1.0.1 and 1.7 are listed for > > testing at: > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > > > > Any idea? > > I have none, is anyone able to help? Is this a problem in the script > that generates packages.debian.org's information, or elsewhere? It was a stale m68k Packages file lying around plus the fact that I still had m68k in the testing architecture list. Should be fixed now. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enter Postpone
On Monday 11 June 2007 22:36, Christoph Berg wrote:
> As a test implementation, I modified the post{inst,rm} templates in
> the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg
> -i texlive-lang-*.deb takes over 4 minutes in the old version, but
> only a total of 60s with postpone used (35s for dpkg -i plus 25s for
> the background jobs).
To be honest, this is exactly an example where I would *NOT* want to see
this implemented.
A major downside of the mechanism supported by this package is that there
is absolutely no check is any errors occur during the running of these
postponed scripts!
In the case of texlive, failure in the script currently leaves the
package "unconfigured", which is correct as it may not be usable [1].
Using the mechanism proposed here, the package would happily get the
status "fully installed" and the user would be none the wiser why he'd
get all these inexplicable errors while using the software.
> There's a few other postinst/postrm jobs that could benefit from
> postpone:
>
> * [...]
The only case where IMO using this mechanism could be considered is if
failure of the scripts to run correctly has no or only extremely minor
consequences for the correct working of the software, as is I guess the
case for update-menu.
For all other potential use cases, maintainers should wait for the
implementation of triggers in dpkg [2], which is the only correct way to
deal with this issue.
Cheers,
FJP
[1] And that this is not purely theoretical can be shown with the recent
RC bugs (#419020 and friends) against jadetex, which caused failure in
the postinst for all texlive packages which call such scripts.
[2] http://lists.debian.org/debian-dpkg/2007/04/msg6.html
pgp27VaYadMXA.pgp
Description: PGP signature
Upgrade of the pam library?
Hi, As a maintainer of a pam module (pam-keyring), I would like to know if there is any plan to upgrade the version of the libpam in lenny. The current version is antique (0.79 vs 0.99) and doesn't have some features as syslog logging... Regards Laurent pgpd9XLNhRqvV.pgp Description: PGP signature
Re: Using standardized SI prefixes
Am Montag 11 Juni 2007 22:15 schrieb Josselin Mouette: > Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : > > > You seem to fancy the K-is-1024--k-is-1000 convention > > > > No, I hate that convention. K and k should only ever refer to 1024. > > /me waits for the day measuring jugs are graduated in powers of two, > just to please a group of hackers who don't like SI units. And you have to change their world in an useless atempt? Abbreviations are ambiguous by design. Who actually says that KB means kilobyte? I don't like those Special Interest units in all situations ;) As yes, I favour the 1 MB = 1024 KB = 1048576 B HS pgp329bydJAxl.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Mon, June 11, 2007 22:11, Eduard Bloch wrote: >> In either case, ~ 2 million bytes suits your requirement, or it >> doesn't. This sounds to me like solving a non-problem, unless you can of >> course tell me in which situations adding the "B" or "iB" in the field >> above would solve a real question. > > Excuse me? Pretty simple example: you have only 2.03 GB (real GB) > remaining free space (seen in some disk info tool) on your harddisk and you > are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it breaks > about 99% and displays some very unexpected message. We are talking about tools like aptitude here, or at least, the OP does. Did you ever have 2 GB free and decided to install a package that would exactly fill that space in? I'm not quite convinced that real world situations exist where you'd use the installed-size parameter of a package in that amount of significance. Even more because the size of a package can grow a bit due to generated files and the like. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Two proposals for a better Lenny (testing related).
I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach. We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros - * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures * Warn developers and contributors that experimental is for transitions and adopt a sort of 'if in doubt upload to experimental' approach. It's really important The developers and contributors might keep using unstable and some pieces of experimental. Things will get harder during freeze, but I believe it's still better than we've today unless developers and contributors don't cooperate out of freeze and ignore the 'experimental if in doubt' approach. Note that it reduces RM team power during the development cycle, the first suggested approach doesn't. be cool, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
In article <[EMAIL PROTECTED]> you write: >-=-=-=-=-=- > >Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : >> The point wasn't that you can't set up a professional RAID array using >> cheap desktop hard disks; you can, if you really want to, though I >> wouldn't recommend it. And yes, you're completely free to ignore that >> particular advise, so long as you don't expect me to become a customer >> of yours. > >You seem to strongly believe the cheap desktop hard disk is different >from the server hard disk. This is entirely wrong. Apart from 10k and >15k rpm disks, these are all strictly the same. Only the electronics >change. Sorry, but you're utterly wrong. I've worked in the storage industry for several years and in that time I've spoken to engineers working on hard drive design and production. There can be significant physical differences between desktop and enterprise disks including (but not necessarily limited to) data layout, head assemblies, motors, physical damping, platter sizes and materials. The underlying principles are clearly the same, but desktop drives are designed down to a price using cheaper designs and components wherever possible. One of the most common mistakes is to make large arrays of cheap disks. As cheaper disks tend to be less well isolated, vibration and resonance between the different disks can be a major problem and can cause very rapid drive failure. Even worse, this is often provoked in groups such that RAID setups can still fail due to multiple failures. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 10:15:25PM +0200, Josselin Mouette wrote: > Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : > > > You seem to fancy the K-is-1024--k-is-1000 convention > > No, I hate that convention. K and k should only ever refer to 1024. > /me waits for the day measuring jugs are graduated in powers of two, > just to please a group of hackers who don't like SI units. Shall I bring you a half gallon of milk to Scotland, then? "Pff, base 10, the metric system is so archaic" -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o
Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > It was a stale m68k Packages file lying around plus the fact that > I still had m68k in the testing architecture list. > > Should be fixed now. Ah, many thanks! Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Enter Postpone
Frans Pop <[EMAIL PROTECTED]> wrote: > To be honest, this is exactly an example where I would *NOT* want to see > this implemented. > > A major downside of the mechanism supported by this package is that there > is absolutely no check is any errors occur during the running of these > postponed scripts! That's exactly the reason why we never did that ourselves. > For all other potential use cases, maintainers should wait for the > implementation of triggers in dpkg [2], which is the only correct way to > deal with this issue. Seconded. Regards, Frank > [1] And that this is not purely theoretical can be shown with the recent > RC bugs (#419020 and friends) against jadetex, which caused failure in > the postinst for all texlive packages which call such scripts. Well, this one is actually a bad example, because it wouldn't happen if the thing was postponed, it's kind of a timing issue. But there are other valid examples of failed TeX commands (by the dozen in the BTS). -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Qt4.3.0 in experimental
hi, Qt4.3.0 was uploaded in experimental. There's some API changes. Please, check your packages works with this new upstream release: Debian Java Maintainers <[EMAIL PROTECTED]> classpath Debian LyX Maintainers <[EMAIL PROTECTED]> lyx Jan Niehusmann <[EMAIL PROTECTED]> psi qca Utopia Maintenance Team <[EMAIL PROTECTED]> avahi Masami Ichikawa <[EMAIL PROTECTED]> bookmarkbridge René Mérou <[EMAIL PROTECTED]> bulmages Steffen Joeris <[EMAIL PROTECTED]> dc-qt marble Barak A. Pearlmutter <[EMAIL PROTECTED]> djview4 Florian Ragwitz <[EMAIL PROTECTED]> esperanza Arnaud Cornet <[EMAIL PROTECTED]> gnudoq Arnaud Kyheng <[EMAIL PROTECTED]> gnunet-qt Dmitry E. Oboukhov <[EMAIL PROTECTED]> hedgewars Steve M. Robbins <[EMAIL PROTECTED]> ipe Patrick Winnertz <[EMAIL PROTECTED]> italc Bart Martens <[EMAIL PROTECTED]> kcheckers marble speedcrunch Reinhard Tartler <[EMAIL PROTECTED]> keepassx Debian Kolab Maintainers <[EMAIL PROTECTED]> kolabadmin Juan Manuel Garcia Molina <[EMAIL PROTECTED]> ktoon John Stamp <[EMAIL PROTECTED]> lastfm Vincent Fourmond <[EMAIL PROTECTED]> libqt4-ruby Wesley J. Landaker <[EMAIL PROTECTED]> mimms Mattias Nordstrom <[EMAIL PROTECTED]> nzb Benjamin Mesing <[EMAIL PROTECTED]> packagesearch Mario Iseli <[EMAIL PROTECTED]> pokerth Ondřej Surý <[EMAIL PROTECTED]> poppler Torsten Marek <[EMAIL PROTECTED]> python-qt4 Joop Stakenborg <[EMAIL PROTECTED]> qantenna Tobias Toedter <[EMAIL PROTECTED]> qbrew Miguel Gea Milvaques <[EMAIL PROTECTED]> qdacco Debian GIS Project <[EMAIL PROTECTED]> qgis Frederic Daniel Luc Lehobey <[EMAIL PROTECTED]> qrfcview Debian KDE Extras Team <[EMAIL PROTECTED]> qtemu strigi Debian Multimedia Team <[EMAIL PROTECTED]> qtractor Gudjon I. Gudjonsson <[EMAIL PROTECTED]> qwt qwtplot3d Jeremy Lainé <[EMAIL PROTECTED]> sailcut Bjoern Erik Nilsen <[EMAIL PROTECTED]> stopmotion Joseph Smidt <[EMAIL PROTECTED]> texmaker Yann Dirson <[EMAIL PROTECTED]> tulip A. Maitland Bottoms <[EMAIL PROTECTED]> vtk Marco Nenciarini <[EMAIL PROTECTED]> wengophone Debian/Ubuntu wpasupplicant Maintainers <[EMAIL PROTECTED]> wpasupplicant cheers, Fathi Qt/KDE Team
Re: Using standardized SI prefixes
* Eduard Bloch <[EMAIL PROTECTED]> [070611 22:27]: > > Can you tell me in which cases you would make a different decision if this > > was > > either 2134*1000 or 2134*1024 bytes? > > > > In either case, ~ 2 million bytes suits your requirement, or it doesn't. > > This sounds to me like solving a non-problem, unless you can of course tell > > me > > in which situations adding the "B" or "iB" in the field above would solve a > > real question. > > Excuse me? Pretty simple example: you have only 2.03 GB (real GB) > remaining free space (seen in some disk info tool) on your harddisk and > you are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it > breaks about 99% and displays some very unexpected message. Isn't uncompressed size filesystem dependent? (At least the space the package will need when being installed will be). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 10:11:25PM +0100, Steve McIntyre wrote: > In article <[EMAIL PROTECTED]> you write: > >-=-=-=-=-=- > > > >Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : > >> The point wasn't that you can't set up a professional RAID array using > >> cheap desktop hard disks; you can, if you really want to, though I > >> wouldn't recommend it. And yes, you're completely free to ignore that > >> particular advise, so long as you don't expect me to become a customer > >> of yours. > > > >You seem to strongly believe the cheap desktop hard disk is different > >from the server hard disk. This is entirely wrong. Apart from 10k and > >15k rpm disks, these are all strictly the same. Only the electronics > >change. > > Sorry, but you're utterly wrong. FWIW who is wrong does not matter. If you're not ftpmaster.debian.org or the primary debian mirror or let's say one of the 5 or 6 primary debian mirrors, you don't _need_ to be safe, you just need to be always online. You can achieve that with a simple array of usual desktop (sorry that works well) SATA drives (or even 10k desktop grades sata drives, yes that exists) in a sufficientely redundant raid array. If you choose your hardware properly: * it will be hotpluggable (yes even desktop sata drives supports this), * you will be able to monitor it. * you will be able to change the drives before they fail. Even if you burn 2 500Go disks every 6 months, it will still be cheaper in the end than the "carrier-grade" hardware that is sold. The really funny part here, is that when time passes, your replacement disks become bigger and bigger, and faster than the archive growth. Isn't it nice ? And even if all of that should fail, rebuilding a debian mirror is fast (I build my x86+amd64 in a few hours behind a dsl line), and costs a fragment of the bandwidth this mirror would consume in the long term anyway. My point is: disk space is expensive because people didn't realized that disks are expendable. Well, some people, google did realize. And would I need to build a very efficient mirror, I'd put my money on the RAM so that the very used parts of the mirror would stay in cache anyways. The other fun part was that my real point was that there is a real problem that is bandwidth, not really for the mirrors sync, but because of the downloads from the clients (I've no real data to backup that claim of course, but if a mirror uses more BW to be kept in sync that what his usual clients use, then its worthless). And yes, unlike disks, bandwidth is still a real real real constraint. Though, I'd say that we could work on distributed mirrors infrastructures, because disk is cheap for our users too, and even a smallish fragment of their bandwidth could be of use. As soon as such a distribution service exists, I've for sure some dozens of gigabyte and 10 to 20 Mbits on a server of mine to be part of the network. _that_ would be 100x more productive than to try to take shortcuts on the archive for bad reasons. PS: Oh and I don't say it's a good idea to see the archive grow just because we have space. I've 2 RM: bugs on old packages of mine that are worthless and uselessly bloat the archive. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcF2VHIh7KB.pgp Description: PGP signature
Re: ITP: pysycache-- Educational game to teach children to move the mouse
José L. Redrejo wrote: > The activities make children practice on clicking, double-clicking, drag > and drop, moving and identify the mouse buttons. Since children probably learn this by age five or so with or without help, perhaps the author should focus on making a similar tool for adults instead. :-) Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 15:10:24 Hendrik Sattler wrote: > Am Montag 11 Juni 2007 22:15 schrieb Josselin Mouette: > > Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : > > > > You seem to fancy the K-is-1024--k-is-1000 convention > > > > > > No, I hate that convention. K and k should only ever refer to 1024. > > > > /me waits for the day measuring jugs are graduated in powers of two, > > just to please a group of hackers who don't like SI units. > > And you have to change their world in an useless atempt? > Abbreviations are ambiguous by design. Who actually says that KB means > kilobyte? Well, in SI units, KB never means kilobyte, and is not ambiguous at all; it's a kelvin·bel. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: > * testing metric is too simple, packages are allowed to enter testing > only after a certain period of time has passed no matter if much > people tested it before that and just when they don't have > release-critical bugs filed against them. Of course we have a team of RMs who are able override that and apply as complex a metric as you'd like on a special-case basis. As well as urgency=high in the changelog. The tendency of dependency chains can block transitions, and keep RC bugs open unduely long in testing is a much worse problem with speed of testing migration. Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ > * developers and most active contributors are pretty much using only > stable or unstable and not testing. What's your data? A fun though not entirely reliable data source is the "APT prefers" lines inserted by reportbug in bug reports. A quick grep[1] of the BTS gives: 51988 APT prefers unstable 30351 APT prefers testing 2076 APT prefers stable 420 APT prefers experimental 373 APT prefers testing-proposed-updates 220 APT prefers oldstable 190 APT prefers proposed-updates 60 APT prefers dapper-updates 50 APT prefers dapper 30 APT prefers breezy-updates 24 APT prefers edgy-updates 17 APT prefers breezy 16 APT prefers feisty-updates 13 APT prefers edgy 10 APT prefers hoary-updates 10 APT prefers feisty 10 APT prefers breezy-security 7 APT prefers sarge 7 APT prefers etch 7 APT prefers dapper-security (For bonus fun, someone could graph how these change over time..) > 1) The 'remove experimental' proposal > > * Warn developers and contributors[0] > * Remove experimental > * Switch unstable (release) for not automatic updates > > [0] = This warning should contain the hint for contributors switch from > unstable to testing and those who want to pick unstable stuff do like > we do today with experimental. > > The benefit of the approach above from a RM point of view is that we will > have more eyeballs over testing and it doesn't mean that we will have less > people using unstable pieces. This assumes that experimental is used by a lot of people, which I doubt, especially given the default apt pins and the numbers above. Experimental is already only rarely uploaded to -- 1 in 20 packages have a version in experimental (some of them outdated). I've seen plenty of cases of developers complaining that they uploaded to experimental and got too little additional testing from doing so. Moving the line between experimental and unstable might drive some people to testing, but I don't feel it will be many, especially as many developers upload even risky changes to unstable already. If you want more users to use testing, see CUT. If you want more developers to use testing, I firstly don't entirely see the point, but providing better tools for developers to develop for unstable while using testing might help. > 2) The 'remove testing' proposal Amoung many other problems this postpones most work on the installer until the release it will install is frozen. -- see shy jo [1] [EMAIL PROTECTED]:/org/bugs.debian.org/spool/db-h>find -name \*.log | xargs grep 'APT prefers' | uniq | sed -e 's/.*: *//' -e 's/ *$//' | sort | uniq -c | sort -rn signature.asc Description: Digital signature
Bug#428467: ITP: balance -- Surprisingly successful load balancing solution and generic tcp proxy
Package: wnpp Severity: wishlist Owner: "Rafael D'Leon" <[EMAIL PROTECTED]> * Package name: balance Version : 3.35 Upstream Author : Thomas Obermair ([EMAIL PROTECTED]) * URL : http://www.inlab.de/balance.html * License : GPL Programming Lang: C Description : Surprisingly successful load balancing solution and generic tcp proxy Balance is a surprisingly successful load balancing solution being a simple but powerful generic tcp proxy with round robin load balancing and failover mechanisms. Its behaviour can be controlled at runtime using a simple command line syntax. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-ck2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
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 significantly change their display to use the > "KiB" unit? E.g. all of the "top"-type programs, which display stuff in colums like memory sizes etc, and are _extremely_ starved for space. It would be ludicrous to change the memory size displays in such programs from "224K" to "224KiB" just to give some obsessive-compulsive types a warm fuzzy. > On the other hand, we have the chance to avoid user confusion No one is actually confused. This "standard" doesn't actually solve a real problem. -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. On Tue, 2007-06-12 at 01:53 +0900, Miles Bader wrote: > 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 lying in the gutter, but some of us are looking at the stars. > -Oscar Wilde > > -- Alex Jones http://alex.weej.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/11/07, Alex Jones <[EMAIL PROTECTED]> wrote: Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. That's not "consistent". Kilobyte has always meant 2^10 bytes. "kilo" in "kilobyte" is not an SI prefix. SI prefixes only apply to SI measurements, of which "byte" is not a member. There is no confusion; the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. On Tue, 2007-06-12 at 01:53 +0900, Miles Bader wrote: > 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 lying in the gutter, but some of us are looking at the stars. > -Oscar Wilde > > -- Alex Jones http://alex.weej.com/ -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Mark Reitblatt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, 2007-06-11 at 19:56 -0500, Mark Reitblatt wrote: > On 6/11/07, Alex Jones <[EMAIL PROTECTED]> wrote: > > Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just > > choose one over the other and be consistent. > > That's not "consistent". Kilobyte has always meant 2^10 bytes. "kilo" > in "kilobyte" is not an SI prefix. SI prefixes only apply to SI > measurements, of which "byte" is not a member. Then why bastardise an SI prefix? This surely serves only to confuse people. Why don't we invent a new word? Should we call it the "thousandbyte"? It is simply a convenient accident that 2^10 ~= 10^3. As I'm sure you're well aware, this approximation starts to become way off as you approach tera-. In fact, that's about 10% error, which is simply unacceptable. It's time to move on and accept that the approximation fails with big numbers. > There is no confusion; > the only place where a kilobyte != 2^10 bytes is in hard drive > manufacturer's advertising materials. This is the way it has been for > decades, and it is a perfectly acceptable and desirable standard. And I suppose you think that differences such as that between the American and the English ton are acceptable and desirable. Let it be known that I strongly disagree with you here. :) -- Alex Jones http://alex.weej.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, Jun 11, 2007 at 05:39:54PM +0200, Michael Biebl wrote: > The frontends imho just need a clear way of showing which packages are > going to be installed because of a Depends and which because of a > Recommends, so it would be easier to de-select a recommended package. > > Otherwise there would be no point having Suggests and Recommends, if > they are basically treated the same by the package management tool. You could scrap the "Suggests and Recommends" tags all together and use the debtags to relate packages. Just a thought. :-) Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 02:46:08PM -0600, Warren Turkal wrote: > I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using > for > anything interesting. Can anyone tell me if these would be useful to Debian > or recommend another free software group to donate them? As shipping may be a consideration, in the cost-benefit analysis, it may be useful to say where in the world you are, in a general way, so that someone in the area, who could use them, could reply. -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgp2UP3scD5p8.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Mon, Jun 11, 2007 at 06:20:17PM -0300, Gustavo Franco wrote: > I would like to ask you interested in our next release to stop and > look at 'testing' for a while. I believe that now, during the start of > a development cycle and during debcamp/debconf we've a interesting > opportunity to review pros and cons of our current approach. > > We believe that 'testing' means that things shouldn't break as badly > as in unstable or experimental. That's important understand the > automatic update concept of unstable and the experimental > non-automatic nature. In other words use unstable means that upgrade > is dangerous, use unstable and experimental means that you pick how > much more of the danger you want from there (experimental). > > Let me outline the 'testing' pros and cons from my point of view: > > pros > - > > * testing is under control of release team, it's supposed to be harder > to a random developer break our next release > > * testing is our 'daily updated' release snapshot > > > cons > - > > * testing metric is too simple, packages are allowed to enter testing > only after a certain period of time has passed no matter if much > people tested it before that and just when they don't have > release-critical bugs filed against them. > > * developers and most active contributors are pretty much using only > stable or unstable and not testing. > > > I've two different proposals to address the cons trying to avoid as > much as possible create new cons, they are: > > 1) The 'remove experimental' proposal > experimental is not a 'full' branch like stable, testing or unstable. It only has a handfull of package built for it (at least that is what I have seen from reading debian-devel-changes) Also, there is no transition from experimental to unstable. checkout my diagram at http://mysite.verizon.net/kevin.mark/ (there is an older,not updated dia source in spanish if that is helpful) -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpq8hVMq1eZy.pgp Description: PGP signature
Re: Using standardized SI prefixes
Miles Bader wrote: > Bastian Venthur <[EMAIL PROTECTED]> writes: > > > On the other hand, we have the chance to avoid user confusion > > No one is actually confused. can you say, in all the thousands of users, not a single one is ever confused? Not a single one ever wonders if it means 1000 or 1024? 1048576 or 100? 1073741824 or 10? > This "standard" doesn't actually solve a real problem. http://physics.nist.gov/cuu/Units/binary.html It does solve a real problem. It solves an ambiguity. Does k mean 1000 or 1024? Does M mean 100 or 1048576? Answer: k mean 1 000 ki means 1 024 m means 1 000 000 mi means 1 048 576 No more ambiguity. Because you see no problem does not mean there is none. If you want to use the ``classical'' SI units as a basis, then look no further than deka: abbreviated da. http://physics.nist.gov/cuu/Units/prefixes.html -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Monday 11 June 2007 21:52:09 Kevin Mark wrote: > As shipping may be a consideration, in the cost-benefit analysis, it may > be useful to say where in the world you are, in a general way, so that > someone in the area, who could use them, could reply. I will ship anywhere in the US. Exporting them would have to be investigated. Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 02:46:08PM -0600, Warren Turkal wrote: > I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using > for > anything interesting. Can anyone tell me if these would be useful to Debian > or recommend another free software group to donate them? The m68k port is nearly always in need for SCSI replacement disks for their ~20 m68k buildds. Some boxes just have 9 GB drives for multiple chroots, which causes some build failures from time to time because the disks have no free space anymore. One buildd is currently down because of SCSI disk problems as well. So, the m68k port has the need for some larger disks, especially when those disks are usuable with a standard 50 pin SCSI cable. It would be nice if you could send us one or more disks. Stephen Marenka is located in the US while I'm located in Germany (as most m68k buildds as well). CC'ing him. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 02:32:35PM -0700, Steve Langasek wrote: > On Mon, Jun 11, 2007 at 10:15:25PM +0200, Josselin Mouette wrote: > > Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : > > > > You seem to fancy the K-is-1024--k-is-1000 convention > > > > No, I hate that convention. K and k should only ever refer to 1024. > > > /me waits for the day measuring jugs are graduated in powers of two, > > just to please a group of hackers who don't like SI units. > > Shall I bring you a half gallon of milk to Scotland, then? > > "Pff, base 10, the metric system is so archaic" > The US gallon being the Queen Anne period wine gallon or 0.83 gallons? I'll stick to Imperial thanks - four pints will be fine in anywhere in Scotland/England/Ireland/Wales and I'll get slightly more :) Fuel consumption in UK is defined as relative to the (Imperial) gallon: the Spanish Empire,of course, did far better - in a good year they got several thousand miles to the galleon :) Andy K or k in a computer context, is, OF COURSE, 1024 :)
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 11:19:00PM -0600, Warren Turkal wrote: > On Monday 11 June 2007 21:52:09 Kevin Mark wrote: > > As shipping may be a consideration, in the cost-benefit analysis, it may > > be useful to say where in the world you are, in a general way, so that > > someone in the area, who could use them, could reply. > > I will ship anywhere in the US. Exporting them would have to be investigated. Oddly enough if you had posted this a bit earlyer, one of the US folks who will attend Debconf (this year in the UK) could have brought it with them. This would make it easy to directly give it to many folks who are part of Debian. Although it may still be possible, if it is done in an extreamly timely manner, as Debconf is June 17th-23rd. Maybe There should be some announment a month or two before debconf so that hardware donations can be co-ordinated around it and the participants -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpMYDRHxE9kH.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 09:55:35PM +0200, Magnus Holmgren <[EMAIL PROTECTED]> wrote: > On Monday 11 June 2007 21:41, Joey Hess wrote: > > Alex Queiroz wrote: > > > On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: > > > >No, I hate that convention. K and k should only ever refer to 1024. > > > > > > Like in kg or km? > > > > This thread is about units of data. > > kbit? kbit/s? kB/s? So, a Gigabit ethernet card has a rate of 1073741824000 bits a second ? cool ;) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:21, Joey Hess wrote: > Bastian Venthur wrote: > > 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 significantly change their display to use the > > "KiB" unit? > > iftop, top, ls, and df are the first few to come to mind. Both ls and df produce very variable-width output where one extra "i" is no big deal. Besides, they don't use prefixes by default. top uses "m" for mebi (and nothing for kibi), which is *completely* wrong - but on the other hand "m" can't be confused with "M" for mega-. The default layout seems to have enough space left, but, just to be sure, perhaps we can make an exception if it's well documented? iftop uses powers of 2 except if logarithmic scale for the bar graphs is turned on. I think it would be better if it used powers of 10 throughout. There is a comment: /* This 1024 vs 1000 stuff is just plain evil */ None of these put a space between the number and the unit, as is proper, but that I don't think can be reasonably expected. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) "Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack)" -- Dave Evans pgpV1ndhcmP5Y.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 23:10, Hendrik Sattler wrote: > Abbreviations are ambiguous by design. Who actually says that KB means > kilobyte? You're arguing that although IEC prefixes eliminate all ambiguity in the area of amounts and rates of data, there is still some ambiguity left, i.e. IEC prefixes have to be rejected for not being a perfect solution. http://en.wikipedia.org/wiki/Perfect_solution_fallacy > I don't like those Special Interest units in all situations ;) SI units aren't special. They are universal. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpsWRlWvrljp.pgp Description: PGP signature
Re: SCSI drives for donation
On Monday 11 June 2007 23:56:16 Kevin Mark wrote: > Oddly enough if you had posted this a bit earlyer, one of the US folks > who will attend Debconf (this year in the UK) could have brought it with > them. This would make it easy to directly give it to many folks who are > part of Debian. Although it may still be possible, if it is done in an > extreamly timely manner, as Debconf is June 17th-23rd. Maybe There > should be some announment a month or two before debconf so that hardware > donations can be co-ordinated around it and the participants I live in Fort Collins, CO. Some of the HP Linux Labs people live here. Are any of them on the list and care to speak up? wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 02:56, Mark Reitblatt wrote: > On 6/11/07, Alex Jones <[EMAIL PROTECTED]> wrote: > > Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just > > choose one over the other and be consistent. > > That's not "consistent". Kilobyte has always meant 2^10 bytes. "kilo" > in "kilobyte" is not an SI prefix. SI prefixes only apply to SI > measurements, of which "byte" is not a member. There is no confusion; > the only place where a kilobyte != 2^10 bytes is in hard drive > manufacturer's advertising materials. This is the way it has been for > decades, and it is a perfectly acceptable and desirable standard. That's an argument that's been heard before but it's *wrong*. SI prefixes *are* used with non-SI units without losing their normal meaning and there is no reason why bytes should be an exception. Since kilo has always meant 1000, kilobyte must initially have meant 1000 bytes, before people started to use it as if to mean 1024. There is confusion; hard drive manufacturers' advertising material is not the only place where kilobyte != 2^10 bytes. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpy4lPhufMuy.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 08:36:39AM +0200, Magnus Holmgren wrote: > > That's an argument that's been heard before but it's *wrong*. SI prefixes > *are* used with non-SI units without losing their normal meaning and there is > no reason why bytes should be an exception. Since kilo has always meant 1000, > kilobyte must initially have meant 1000 bytes, before people started to use > it as if to mean 1024. There is confusion; hard drive manufacturers' > advertising material is not the only place where kilobyte != 2^10 bytes. > If I remember my history of computing correctly, kilo was not chosen to mean exactly 1000 when it came to computers. Things were initially done in powers of 2 (oversimplification). Since 2^10 = 1024 ≈ 1000, kilo was chosen as the prefix to use, since it already existed. The idea of going back and redifining the kilo to mean exactly 1000 in the context of computing was a marketing gimmick. Besides, there are other units of measure which carry the same name and have different numerical values based on context (think statute miles and nautical miles), though I don't think any such examples can be found in the SI. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hi Thijs! You wrote: > We are talking about tools like aptitude here, or at least, the OP does. > Did you ever have 2 GB free and decided to install a package that would > exactly fill that space in? Afaik, we are talking about making the use of the prefixes consistent over all of Debian, so that everywhere the program says MB, you know exactly what that means. Doing everywhere except in apt would kind of defeat the purpose, because then you still can't be sure... Bas. -- +--+ | Bas Zoetekouw | Sweet day, so cool, so calm, so bright, | || The bridall of the earth and skie: | | [EMAIL PROTECTED] | The dew shall weep thy fall tonight;| +|For thou must die. | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
