Re: Using standardized SI prefixes
Hi all, Somebody asked about real world experiences. Ever tried fitting mixed multiple data to a CD or DVD & have to see in byte-size if things are good or not. Ever downloaded an .iso only to find later it doesn't fit the CD/DVD by some MiB . How much overburning can be done by a CD/DVD burning application . I do lot of burning of content & it really pisses me off. If software guys pick up the trend then only there is hope. Otherwise do the reverse make it so that 1000 bytes is a KB & not 1024 something has to be changed. -- 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: Using standardized SI prefixes
On Tuesday 12 June 2007 08:44, Roberto C. Sánchez wrote: > 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. It is possible that nobody used the word "kilobyte" before it became conventional to use it to mean "1024 bytes", but if they did, it must have meant "1000 bytes", by default. > 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. Of course not. The utter mess of miles, gallons, tons, pounds troy/avoirdupois, and so on, is completely irrelevant. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpywNT4mshd8.pgp Description: PGP signature
Re: Using standardized SI prefixes
Magnus Holmgren <[EMAIL PROTECTED]> writes: >> No it doesn't. >> >> The "SI binary prefixes" are an abomination. > > Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: Until now, in a typical computer app, "900K" had an unambiguous meaning: 900*1024. Now that a bunch of people are all in a misguided frenzy to "correct" things (which weren't broken), there will almost certainly be cases where some silly fool will change the _calculation_ but not the label (e.g., in a case where space is at a premium) -- e.g., they'll keep "K", but change the calculation to "/ 1000", because that's "correct". However it's _guaranteed_ that many apps will stick with "/ 1024". Thus a suffix (e.g. K) which was previously unambiguous in practice (and no, disk-drive advertisements don't count) will have become more ambiguous in practice. [At which point of course the kib-fans will start crying out that because things are now very confused, we muuust switch to "gib" suffixes -- all because they basically screwed things up.] Great. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- 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: > > 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. Most of the time you won't have to say it. Spoken language tends to be less formal than written language, and 2^10 bytes still is approximately a kilobyte (and so on up to giga, where the approximation starts to fail). So you only have to say kibibyte when you need to be precise. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpEKOaSzboZ9.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 03:54:25PM +0900, Miles Bader wrote: > Until now, in a typical computer app, "900K" had an unambiguous meaning: > 900*1024. No, its 900 Kelvin aka 626.85°C Should I say that kb and Mb are kilo bases and mega bases, as in DNA? Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2 -- 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 à 19:56 -0500, Mark Reitblatt a écrit : > That's not "consistent". Kilobyte has always meant 2^10 bytes. No, it has never. Kilo has always meant 10^3. Full stop. End of story. Bye bye. People didn't invent the SI just so that a small group of hackers decide that suddenly it is 2^10 just because it is more convenient. SI units are *universal*. There is a world outside computing, you know. Just ask anyone outside your small world how much bytes they think a kilobyte is. > "kilo" in "kilobyte" is not an SI prefix. "Kilo" is always a SI prefix. > SI prefixes only apply to SI measurements No. > There is no confusion; There seems to be in your mind. > the only place where a kilobyte != 2^10 bytes is in hard drive > manufacturer's advertising materials. No. A kilobyte is 10^3 bytes everywhere. At least, in all countries who use SI units. > This is the way it has been for > decades, and it is a perfectly acceptable and desirable standard. It has never been anything but a gross imprecision introduced by people incapable of following rigorous standards. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:20:30AM +0200, Josselin Mouette wrote: > Le lundi 11 juin 2007 à 19:56 -0500, Mark Reitblatt a écrit : > > That's not "consistent". Kilobyte has always meant 2^10 bytes. > > No, it has never. Kilo has always meant 10^3. Full stop. End of story. > Bye bye. People didn't invent the SI just so that a small group of > hackers decide that suddenly it is 2^10 just because it is more > convenient. SI units are *universal*. > Really? Because there is no history of words being co-opted and being assigned new meanings? Pirate? Hacker? It is a fact that, lacking a better work, people will take a word that is a close approximation in some way and use it. The kilo ≈ 2^10 is not the first, nor will it be the last. > > It has never been anything but a gross imprecision introduced by people > incapable of following rigorous standards. > It has never been anything more than people defaulting to a close approximation. Language is imperfect. People make do. 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 Tuesday 12 June 2007 08:54, Miles Bader wrote: > Magnus Holmgren <[EMAIL PROTECTED]> writes: > >> No it doesn't. > >> > >> The "SI binary prefixes" are an abomination. > > > > Why - besides pronunciation? > > Well among other things, the end result of this whole mess will likely > be to _increase_ confusion, rather than lessen it: In that case it's not an end result. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpO9RTU1zlB8.pgp Description: PGP signature
Re: Using standardized SI prefixes
Miles Bader wrote: Magnus Holmgren <[EMAIL PROTECTED]> writes: No it doesn't. The "SI binary prefixes" are an abomination. Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: Until now, in a typical computer app, "900K" had an unambiguous meaning: 900*1024. How often must we repeat it: it is not unambiguous. When you buy a hard drive 500G does not mean 500 * 1024³ (please note: one context [size], two different meanings for "G"). 1Mbit/s usually means 10^6 bits per second in the context of data transfer rates. How is this unambiguous for you? Now that a bunch of people are all in a misguided frenzy to "correct" things (which weren't broken), there will almost certainly be cases where some silly fool will change the _calculation_ but not the label (e.g., in a case where space is at a premium) -- e.g., they'll keep "K", but change the calculation to "/ 1000", because that's "correct". Nope, it's more likely that *if* we take action, we would chose the binary suffix notation to avoid this confusion. -- 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 mardi 12 juin 2007 à 03:29 -0400, Roberto C. Sánchez a écrit : > > It has never been anything but a gross imprecision introduced by people > > incapable of following rigorous standards. > > > It has never been anything more than people defaulting to a close > approximation. Language is imperfect. People make do. You'll tell that to a court if there is such an "approximation" in a contract. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:36:34AM +0200, Josselin Mouette wrote: > Le mardi 12 juin 2007 à 03:29 -0400, Roberto C. Sánchez a écrit : > > > It has never been anything but a gross imprecision introduced by people > > > incapable of following rigorous standards. > > > > > It has never been anything more than people defaulting to a close > > approximation. Language is imperfect. People make do. > > You'll tell that to a court if there is such an "approximation" in a > contract. > What are you talking about? We all know that the *precise* meaning of kilo is 1000. The point is that the term was also co-opted, since there was not a better term. If you are talking about a contract, I would expect that the *precise* meanings of words are being used, along with definitions of any words where there could be ambiguity. Why do you think that the marketing materials for most hard drives include the note that 1 GB = 1 000 000 000 bytes? If the SI prefixes only ever held their *precise* meanings, then such clarifications would not be necessary. 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
Le mardi 12 juin 2007 à 03:43 -0400, Roberto C. Sánchez a écrit : > What are you talking about? We all know that the *precise* meaning of > kilo is 1000. The point is that the term was also co-opted, since there > was not a better term. If you are talking about a contract, I would > expect that the *precise* meanings of words are being used, along with > definitions of any words where there could be ambiguity. When I use a computer program, I don't want to wonder whether it uses precise units or approximate ones. A computer is a damn stupid machine and it will never know whether I need precision. Which is why it should *always* do things the precise way. > Why do you think that the marketing materials for most hard drives > include the note that 1 GB = 1 000 000 000 bytes? Maybe because they are sold in the US, one of the 3 countries where SI units are not standard? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
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. 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. It's all not as simple as you write it. Bit rates have been usually measured in 10^(3x) bit per second, e.g. kbps or kbit/s. So when talking about transfer rates, kilo meant thousand. However, when talking about file/memory sizes, kilo meant 1024. But then again, a lot of people aren't aware of this difference and there are a lot of programs which present e.g. download speeds in 2^(10x) bytes per second (_bits_ per second are more common to be used in "lower levels", but there are also programs which use 2^10 _bits_ per second as transfer speed units). Another "historic" example is a floppy-MB: A 1.44MB floppy disc can store 1,474,560 Bytes, that is 1440 KiB and 1.40625 MiB or approximately 1475KB or 1.48MB with kilo=10^3 and mega=10^6. However, these floppies were known as "1.44MB"-floppies. (MB meaning 1000 times 1024 bytes). Very consistent! Your example of hard drive manufacturers is a another good example why we actually SHOULD have unambiguous prefixes. Advertising always tends to abuse ambiguities. When SI prefixes were used consistently, it would have been clear from start that you cannot fit 100 GiB of data on a hard drive advertised as having 100GB free space available. Just because something has been done wrong for a long time doesn't make it right. People who know the inconsistencies get used to them and do not want to change it because it may be inconvenient for them or it simply sounds stupid to them (what an argument!). However, this means that _every_ new generation of students and hobbyists has to go through learning the inconsistencies if we change nothing. Hooray, confusion till the end of times! But if we pushed the use of SI-prefixes, the computer-gurus would have to get used to the new system but following generations would profit from having a consistent unit system. In my opinion this is something that is worth the effort. The problem with such big changes is that a critical mass is needed to benefit from this new system and the faster it is achieved, the shorter the confusion-period will be. I think that the open source community should participate since consistent and unambiguous conventions are a good thing (TM). Christof Krüger
Re: Dependencies on shared libs, take 2
On Thu, 07 Jun 2007, Raphael Hertzog wrote: > Otherwise, the discussions in this thread lead to several interesting > points (listed in the TODO in the repository) which will require some > rewrite and optimization of the format of the symbols file. I'll update > the wiki page and my implementation as soon as I have enough time. My goal > is to finish this during debconf in any case. I have updated the wiki page with the new format that I've come up: [| ] [ as many alternative dependency templates as needed ] [ ] [ as many symbols as needed ] A dependency template is a full dependency that might integrate "#MINVER#". This place-holder is then replaced by the appropriate "(>= )" when the real dependency is generated. The minimal version is generated by finding the biggest out of all the symbols used by the application that are affected to this dependency template. Note that #MINVER# can be empty if the application doesn't use any symbols from a library that it's still linked with. If a symbol has no explicit , then it's supposed to be affected to the main dependency template (id=0). Otherwise the number refers to the 'th alternative dependency template. I believe this should cover all uses cases that have been submitted to me. Does it look ok for everybody? Of course most packages will never have any alternative dependency and will also never put any explicit behind the symbols. This extension is what suits best the libGL case as explained by Steve. If you use only official symbols you get a dependency on the virtual package, otherwise you also get a dependency on the particular implementation that provided the other symbols. A short example might be: libGL.so.1 libgl1-mesa-glx #MINVER# | libgl1 | libgl1-mesa-glx #MINVER# [EMAIL PROTECTED] 6.5.1-0.6 [EMAIL PROTECTED] 6.5.1-0.6 1 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: Using standardized SI prefixes
On Tue, 2007-06-12 at 09:37 +0200, Christof Krüger wrote: > Another "historic" example is a floppy-MB: > A 1.44MB floppy disc can store 1,474,560 Bytes, that is 1440 KiB and > 1.40625 MiB or approximately 1475KB or 1.48MB with kilo=10^3 and > mega=10^6. > However, these floppies were known as "1.44MB"-floppies. (MB meaning > 1000 times 1024 bytes). Very consistent! > The difference is a sufficiently small percentage, that most users will not care. In fact, the only people who ever seem to care enough to know that a 1.44MB floppy disk is actually 1.48 Million Bytes are geeks. I don't think it's the differing scale of units that confuse people, changing KB to KiB everywhere where you don't use kB -- I think it's the reality of having differencing scales in the first place that's confusing. Changing the unit prefixes is just a geek "precision" gratification that will confuse everybody who is used to talking about "kilobytes", "and gigabytes"... "My computer has two gigabytes of RAM!" "Aha! No it doesn't!" "It says two gigabytes." "No, you mean two gibibytes! A gigabyte is ten-to-the-nice bytes, whereas a gibibyte is two-to-the-thirty bytes!" *punch* "Ow! You broke my nose!" Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
On 12/06/07 15:37, Christof Krüger wrote: > Just because something has been done wrong for a long time doesn't make > it right. People who know the inconsistencies get used to them and do > not want to change it because it may be inconvenient for them or it > simply sounds stupid to them (what an argument!). > However, this means that _every_ new generation of students and > hobbyists has to go through learning the inconsistencies if we change > nothing. Hooray, confusion till the end of times! > > But if we pushed the use of SI-prefixes, the computer-gurus would have > to get used to the new system but following generations would profit > from having a consistent unit system. In my opinion this is something > that is worth the effort. The problem with such big changes is that a > critical mass is needed to benefit from this new system and the faster > it is achieved, the shorter the confusion-period will be. > I think that the open source community should participate since > consistent and unambiguous conventions are a good thing (TM). > > Christof Krüger > > Until you wrote these two paragraphs I was not particularly interested. Your email prompted me to read some more. Now I'm happy to be counted in the camp of those that chant "standardise". (Of course now I'll be laughed at because of using "kibibytes", but you get that :) To be fair, I suspect that the use of kibibyte in spoken language would be phased out over time. Perhaps the IEC did pronounce them out aloud so we would all be embarrassed into using the SI units :) And just in case anyone else was as confused as I was, wikipedia cleared it up for me: * http://en.wikipedia.org/wiki/Kibibyte * http://en.wikipedia.org/wiki/Kibi (Ironically, my spell-checker had never heard of a kibibyte :) -- Onno Benschop Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |>>?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Mon, Jun 11, 2007 at 07:56:13PM -0400, Joey Hess wrote: > This assumes that experimental is used by a lot of people, which I > doubt, especially given the default apt pins and the numbers above. There's also the fact that if you remove experimental it's easy enough for people to set up their apt repositories somewhere if they want to provide packages outside of unstable. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 09:24 +0100, Scott James Remnant a écrit : > Changing the unit prefixes is just a geek "precision" gratification that > will confuse everybody who is used to talking about "kilobytes", "and > gigabytes"... The confusion lies in the current situation. Bringing precision doesn't bring any confusion. > "My computer has two gigabytes of RAM!" > "Aha! No it doesn't!" > "It says two gigabytes." > "No, you mean two gibibytes! A gigabyte is ten-to-the-nice >bytes, whereas a gibibyte is two-to-the-thirty bytes!" > *punch* > "Ow! You broke my nose!" We're not talking about spoken language here. Nobody cares about gigabytes / gibibytes when discussing how much RAM / disk / horsepower a computer has. We are talking of fixing computer programs with incorrect or confusing display. Of course, I don't usually care that file sizes in my browser window are displayed in kibibytes and mebibytes. Not until I select some of them, see the total size, and ask myself whether they fit on a DVD. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
[OT] howto file bugs in debian bug-tracker
Hi all, Can somebody tell me how I can file upstream debian bugs from bug tracker. Case in point https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 . I know this is not the place, so let's take this off-list perhaps or point to a better resource/mailing list where I can direct that. Cheers ! -- 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: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 11:40:46AM +0200, Josselin Mouette wrote: > Of course, I don't usually care that file sizes in my browser window are > displayed in kibibytes and mebibytes. Not until I select some of them, > see the total size, and ask myself whether they fit on a DVD. If you want to figure out whether they fit on a DVD, you want the number of bytes in your total anyway, not the amount of kilobytes (regardless of whether that's 10^3 or 2^10) -- 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: [OT] howto file bugs in debian bug-tracker
On 6/12/07, shirish <[EMAIL PROTECTED]> wrote: Hi all, Can somebody tell me how I can file upstream debian bugs from bug tracker. Case in point https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 . I know this is not the place, so let's take this off-list perhaps or point to a better resource/mailing list where I can direct that. Cheers ! If you mean filing a bug with the Debian BTS, use the reportbug tool, available in the package of the same name. -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 Spammers only === [EMAIL PROTECTED] === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mass RC bugfiling due to removed apache1 packages
Hello! Due to the removal of apache1 packages from the pool (including libapache-mod-perl) quite a lot of packages aren't installable/buildable anymore due to missing (build-)dependencies. I'm preparing a massbug filing for those so the maintainers are aware of that their packages are RC due to this and either send the ftp team a bugreport about removal of them or update them to work with apache2 instead/drop support of apache1 if apache2 support is already included. This is the notification per policy, I'm not yet done with the package list and mail writing, so feel free to beat me over the head now before I sent them, if you have to - but pretty please also tell me why. :) So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:53:32AM +0900, Miles Bader wrote: > > No one is actually confused. > > This "standard" doesn't actually solve a real problem. unit confusion can be very serious, eg: the mars orbiter Regards, Paddy -- 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 08:54, Miles Bader wrote: > Now that a bunch of people are all in a misguided frenzy to "correct" > things (which weren't broken), there will almost certainly be cases > where some silly fool will change the _calculation_ but not the label > (e.g., in a case where space is at a premium) -- e.g., they'll keep "K", > but change the calculation to "/ 1000", because that's "correct". > > However it's _guaranteed_ that many apps will stick with "/ 1024". THe right way to do it, I believe, is to start out by changing the prefixes from k/M/G/etc. to Ki/Mi/Gi/etc. _where these units are used today_. Whenever you see a number followed by KiB, MiB etc., you can be certain of what it means. No confusion is possible. When you see a number followed by kB, MB etc., it can still have two meanings, just like today. However, until the IEC prefixes become commonplace, the SI prefixes shouldn't suddenly be used to denote powers of two where they previously denoted powers of ten (as in your example), unless the same piece of software also makes prominent use of IEC prefixes (in which case you can be pretty sure that if it *says* kB, they it *means* kB) and/or clearly documents the change (e.g. in a legend). So, just because some developers *might* do things wrong, that doesn't mean it will surely happen. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp8O7rhl7WEV.pgp Description: PGP signature
Re: ITP: pysycache-- Educational game to teach children to move the mouse
On Tuesday 12 June 2007 09:21, Marcus Better <[EMAIL PROTECTED]> wrote: > 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. :-) The GIMP is a good tool for teaching young children about these things. The color selection part of the toolbar allows dragging the color to the desktop background or the title-bar and using the brush for painting teaches mouse control. -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Re: Using standardized SI prefixes
On Tue June 12 2007 01:20:30 am Josselin Mouette wrote: > > "kilo" in "kilobyte" is not an SI prefix. It is not even a prefix. > "Kilo" is always a SI prefix. In computing the "K" stands for "kilobyte", not "kilo" + "byte", and a kilobyte has always been the number of memory locations addressable by the A0-A9 bits on the address bus of a bytewide system... that's 1024 possible addresses, not 1000. IOW, it is not just shorthand for an enumeration (as the SI prefixes are) or a mathematical constant, it is the name of a physical constant. "Kilobytes" naturally became the measure of capacity, (sadly) it may also be natural that Marketing twisted its ambiguity with the SI prefix in an attempt to get marketshare. "1024" will go away when we stop using binary computers. :) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote: > On Tue, 2007-06-12 at 09:37 +0200, Christof Krüger wrote: > > > Another "historic" example is a floppy-MB: > > A 1.44MB floppy disc can store 1,474,560 Bytes, that is 1440 KiB and > > 1.40625 MiB or approximately 1475KB or 1.48MB with kilo=10^3 and > > mega=10^6. > > However, these floppies were known as "1.44MB"-floppies. (MB meaning > > 1000 times 1024 bytes). Very consistent! > > > The difference is a sufficiently small percentage, that most users will > not care. In fact, the only people who ever seem to care enough to know > that a 1.44MB floppy disk is actually 1.48 Million Bytes are geeks. If one wants to introduce new -- well defined -- prefixes, one first has to realize that there is a need for this step. There is a need if the existing prefixes had not been used consistently in the past. However, Mark stated that Kilobyte always had meant 2^10 bytes. My point is that this is just not true and I presented examples for it. The most important thing to notice is that we do not need unified prefixes in isolated worlds or communities like computer nerds, communication engineers etc., but in the intersections where these people cooperate and need to communicate unambiguously. > Changing the unit prefixes is just a geek "precision" gratification that > will confuse everybody who is used to talking about "kilobytes", "and > gigabytes"... > > "My computer has two gigabytes of RAM!" > "Aha! No it doesn't!" > "It says two gigabytes." > "No, you mean two gibibytes! A gigabyte is ten-to-the-nice >bytes, whereas a gibibyte is two-to-the-thirty bytes!" > *punch* > "Ow! You broke my nose!" Well, there are situation where it simply doesn't matter and if someone is pedantic about the use of GB or GiB in these cases... I could care less. You won't ever find 2GB memory bars right next to a 2GiB version. However, there will be situation where it matters. Let me give you an example from the real world: There was a bridge to build over the river Rhine connecting Switzerland and Germany. You have to know that sea levels are defined differently in both countries so if you plan to build a bridge you have to take it into account. Well, the engineers tried to, but they've substracted instead of adding (or vice versa) and so they had to lower the road 54cm on the other side to match the bridge. Read here: http://weblogs.elearning.ubc.ca/thieme/archives/005928.html This would not have happened if they had the same reference point for the sea level. I'm convinced that in the fast-paced computer world such a unification should be possible. Christof Krüger
Re: [OT] howto file bugs in debian bug-tracker
Am Dienstag, den 12.06.2007, 19:57 +1000 schrieb [EMAIL PROTECTED]: > On 6/12/07, shirish <[EMAIL PROTECTED]> wrote: > > Hi all, > > Can somebody tell me how I can file upstream debian bugs from > > bug tracker. Case in point > > https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 . > > I know this is not the place, so let's take this off-list perhaps or > > point to a better resource/mailing list where I can direct that. > > Cheers ! > > If you mean filing a bug with the Debian BTS, use the reportbug tool, > available in the package of the same name. ... or reportbug-ng, if you are more familiar with GUI-tools. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 13:01 +0200, Christof Krüger wrote: > Let me give you an example from the real world: > There was a bridge to build over the river Rhine connecting Switzerland > and Germany. You have to know that sea levels are defined differently in > both countries so if you plan to build a bridge you have to take it into > account. Well, the engineers tried to, but they've substracted instead > of adding (or vice versa) and so they had to lower the road 54cm on the > other side to match the bridge. Read here: > http://weblogs.elearning.ubc.ca/thieme/archives/005928.html > This would not have happened if they had the same reference point for > the sea level. I'm convinced that in the fast-paced computer world such > a unification should be possible. > This is a strong advocation for using powers of ten everywhere, and abolishing the use of powers of two multiples altogether, no? Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: ITP: pysycache-- Educational game to teach children to move the mouse
El mar, 12-06-2007 a las 18:26 +1000, Russell Coker <[EMAIL PROTECTED]> escribió: > > On Tuesday 12 June 2007 09:21, Marcus Better <[EMAIL PROTECTED]> wrote: > > > 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. :-) > > > > The GIMP is a good tool for teaching young children about these things. > > The > > color selection part of the toolbar allows dragging the color to the > > desktop > > background or the title-bar and using the brush for painting teaches mouse > > control. > > It's a joke, isn't it? I've been using pysycache for the last year (with previous versions) with 3 and 4 years old kids, and they learn how to use the right & left button, or doing drag&drop enjoying, learning how to identify the numbers even in foreign languages. I've installed it in primary schools, and it's just a desktop icon for the teacher/student to launch it. Do you imagine using gimp to do such thing in a classroom with 25 children? Everything has a target, and when the child finish the activity and a girl drawing appears saying "You've got it" , he raises his hands happily. I don't think that's gimp's target. Regards José L. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 04:21:58PM +0800, Onno Benschop wrote: > (Ironically, my spell-checker had never heard of a kibibyte :) Because it's not a correct word. English linguistic is a descriptive science -- what is correct and what is not depends on what people use. This stays in stark contrast to prescriptive languages like French where a government agency is entitled to ban the use of an established word and enforce using a made-up replacement. And what version is used is trivial to check. Oh, wait -- in this case not that trivial, when using the Google test "kilobyte" is so much over the cap that you need tricks like searching for "kibibite foo" and "kilobyte foo", using several words to avoid bias caused by a certain term. The results I got are: "kibibite" has below 0.3% use of "kilobyte". With such a crushing defeat, I doubt the whole "kibibyte" crap has much of a leg to stand on, regardless whether a self-imposed "Academie Anglaise" says. Please, stop this madness. s/KiB/KB/g at least in Debian. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Joey Hess <[EMAIL PROTECTED]> [2007-06-11 19:56]: > Gustavo Franco wrote: > > > * developers and most active contributors are pretty much using only > > stable or unstable and not testing. > > What's your data? It is well known that 87.9% of the assertions made by Debian developers in the mailing lists are not based on factual data. (Please, do not ask me where I got that figure from :-) -- Rafael -- 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 14:09, Adam Borowski wrote: > On Tue, Jun 12, 2007 at 04:21:58PM +0800, Onno Benschop wrote: > > (Ironically, my spell-checker had never heard of a kibibyte :) > > Because it's not a correct word. > English linguistic is a descriptive science -- what is correct and what is > not depends on what people use. This stays in stark contrast to > prescriptive languages like French where a government agency is entitled to > ban the use of an established word and enforce using a made-up replacement. You're arguing that since few people use an otherwise superior concept, Debian should not use it either -- a fallacy known as argumentum ad populum (http://en.wikipedia.org/wiki/Argumentum_ad_populum). Again, if everybody waits for the majority to change first, no change will ever happen. > And what version is used is trivial to check. Oh, wait -- in this case not > that trivial, when using the Google test "kilobyte" is so much over the cap > that you need tricks like searching for "kibibite foo" and "kilobyte foo", > using several words to avoid bias caused by a certain term. > > The results I got are: "kibibite" has below 0.3% use of "kilobyte". > With such a crushing defeat, I doubt the whole "kibibyte" crap has much of > a leg to stand on, regardless whether a self-imposed "Academie Anglaise" > says. I get 59 500 hits for "kibibyte" and 1.5 million hits for "kilobyte". That's about 4%, not 0.3%. In fact, it's sufficiently widespread to earn a place in dictionaries, IMHO. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpO8OlDyVBEq.pgp Description: PGP signature
Re: Reasonable maximum package size ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11 Jun 2007, at 9:22 pm, Josselin Mouette wrote: 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. That's not true, unfortunately. They also have different design criteria for duty cycles, and more stringent MTBF testing requirements. There's been a lot of assertion in this thread, without any real data, so this post provides links to some hard data provided by disk manufacturers. Here follows a posting I sent to the Bioclusters mailing list a few months ago, which includes PDF documents from Seagate showing that their desktop products are absolutely *not* equivalent to their higher-end spindles: Quote begins: Practical experience of running a petabyte of storage arrays here is what I'm basing my opinion on, not claims for device MTBF. Besides, MTBF is highly dependent on duty cycle. MTBF figures are meaningless if you don't also consider the duty cycle. You need to make sure the spindles are designed for a 24/7 duty cycle. Cheap SATA drives normally are not. Anyway, you asked for figures, so here we are, from a spindle manufacturer and (later) from Microsoft (yes, I know): http://www.seagate.com/docs/pdf/marketing/tp_544_tiered_storage.pdf Their nearline fibrechannel drives have an MTBF of 1 million hours, 24/7 duty cycle, read/write. Their desktop SATA drives have an MTBF of 600,000 hours, but that's for an 8x5 largely read-only duty cycle. If you abuse them by running them 24x7 read-write, I dare say it will be considerably less. But ignoring that, by my rough estimate, a double drive failure causing data loss of your RAID5 array using desktop SATA drives will probably happen about four times more frequently than using fibrechannel disks. Of course, you can buy high MTBF SATA drives but (surprise!) they cost about the same as the fibrechannel ones. More details here about what Seagate put in their cheap drives vs. the expensive ones: http://www.seagate.com/content/docs/pdf/whitepaper/ D2c_More_than_Interface_ATA_vs_SCSI_042003.pdf There are also some sobering graphs in this joint presentation from Seagate and Microsoft (apologies for the Powerpoint): http://download.microsoft.com/download/9/8/f/98f3fe47- dfc3-4e74-92a3-088782200fe7/TWST05005_WinHEC05.ppt The graph showing the probability of second disk error during RAID5 rebuild on desktop and server drives is slightly scary even for server drives, but positively terrifying for the cheap drives. This of course, is why we use RAID6 and a hot spare in our large Lustre filesystems. RAID5 is simply not reliable enough, using the SATA drives which underly our SFS servers. As many others have said in this thread, you get cheap or reliable. You do not get both. Quote ends -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRm6UlBypeFo2odvPAQJAzwf/fNAU26PvkXcsjKu+7nknd5WWpB6E1KtB fER1jAEgGjnJOAfumFR56m2QKMm+TDBOX1BQ5z7bV1S010QRme1zEwX8V8N+rAv5 9aLBUnhEAaBMEmy6ls0aQUv13SKgxjryBGUCdUP+xq2g8DSFpdH+4IKYjbIjPi7M nGU2UBH8zrxdkE32AwUU1PIP7gjmvDeiUUmkjbzoI+nUdPCLLEu/HgPShAZLHy3S fRQrRJc6q/gjtA8aTeOL5zUY7NhWjfSngO1A5B6Q26fr0LGUXYkjhuVdTpVY8aat 82os02g+J+gIHOqI8+4b/GkYETK8pEg/pO8xY2ofShTQXl6x9Uv/Ig== =LxT7 -END PGP SIGNATURE- -- 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: Using standardized SI prefixes
I demand that Magnus Holmgren may or may not have written... [snip] > Most of the time you won't have to say it. Spoken language tends to be less > formal than written language, and 2^10 bytes still is approximately a > kilobyte (and so on up to giga, where the approximation starts to fail). So > you only have to say kibibyte when you need to be precise. If I need to disambiguate, I'll say either "real kilobyte" or something like "marketroids' kilobyte". And as for the next step up, well, "gigabytes" is a given, and it's tempting to say "giblets"... -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING. Warning: do not confuse billion with billion. Thousand million or trillion? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Tue, 12 Jun 2007, Tim Cutts wrote: That's not true, unfortunately. They also have different design criteria for duty cycles, and more stringent MTBF testing requirements. There's been a lot of assertion in this thread, without any real data, so this post provides links to some hard data provided by disk manufacturers. Thanks for the facts. As many others have said in this thread, you get cheap or reliable. You do not get both. Which perfectly fits to my real life experience. BTW, could we now come back to the development related issues in this thread. I do not really mind whether it is cheap or not what we expect people to do who want to mirror Debian: We add them a burden (even adding cheap stuff is some work and we should make sure that it is worth the effort) and the initial question is: How can we meaningful provide large chunks of data? And once more: Any explanation why 38902 is tagged wont-fix? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 00:36, Magnus Holmgren wrote: > > I get 59 500 hits for "kibibyte" and 1.5 million hits for "kilobyte". > That's about 4%, not 0.3%. In fact, it's sufficiently widespread to > earn a place in dictionaries, IMHO. It has already happened, see http://www.bbc.co.uk/dna/h2g2/A471476 Now there is a real authority ;) Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 [EMAIL PROTECTED] - personal.[EMAIL PROTECTED] - business I sell GNU/Linux & GNU/Hurd CDs & DVDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 02:36:55PM +0200, Magnus Holmgren wrote: > > And what version is used is trivial to check. Oh, wait -- in this case not > > that trivial, when using the Google test "kilobyte" is so much over the cap > > that you need tricks like searching for "kibibite foo" and "kilobyte foo", > > using several words to avoid bias caused by a certain term. > > > > The results I got are: "kibibite" has below 0.3% use of "kilobyte". > > With such a crushing defeat, I doubt the whole "kibibyte" crap has much of > > a leg to stand on, regardless whether a self-imposed "Academie Anglaise" > > says. > > I get 59 500 hits for "kibibyte" and 1.5 million hits for "kilobyte". That's > about 4%, not 0.3%. In fact, it's sufficiently widespread to earn a place in > dictionaries, IMHO. That's the cap I mentioned earlier -- most searches are halted soon after roughly 1M hits. To have a clue about the real value you need to search for phrases which contain the words you want to compare. Repeat this a few times to eliminate the risk of using a helper word used more by those who have a stronger preference for one of the variants. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
I demand that Josselin Mouette may or may not have written... [snip] > When I use a computer program, I don't want to wonder whether it uses > precise units or approximate ones. A computer is a damn stupid machine > and it will never know whether I need precision. Which is why it should > *always* do things the precise way. Agreed. Use 1024 rather than the imprecise and misleading 1000... (And yes, I'd prefer apt* to use 1024, not 1000.) [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/progs.packages.html> You don't notice your mistakes, but somebody reading over your shoulder will. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/11/07, Joey Hess <[EMAIL PROTECTED]> wrote: 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. Yes, let me make clear it wasn't a statement against RM team work or the amount of time invested coding testing related scripts. It was a call to evaluate the results. 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/ Sorry, i forgot CUT it looks like a 0 proposal since it came first. How and when do you plan to start a team for that and have you considered who from other teams will need to join/agree on the idea? > * developers and most active contributors are pretty much using only > stable or unstable and not testing. What's your data? I'm asking around since 2004 and just a few said that they're using testing on their desktops or laptops, a rarely used test machine running testing doesn't count, IMHO. For example faw said 'yes, I'm running testing since I found out that just a few contributors and developers are actually really using testing'. 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 (...) (For bonus fun, someone could graph how these change over time..) Any idea on how to collect more reliable data in a opt-in base? Does a survey on pentabarf (or public acessible) during debconf makes sense? > 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. Wrong, if I'm asking for experimental removal I'm assuming that there's not a lot of people using that. Considering the rest of your argument, definitely a lot of people will use testing instead this 'new unstable'. Do you see? If you want more users to use testing, see CUT. Looks like a interesting proposal too. 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. You're missing the "I'm on the edge" feeling. People won't use testing just because testing is testing even if you've tons of tools to develop and test everything over unstable. I pretty much believe that's possible today, but I'm yet to hear somebody that moved from unstable to testing because there's a possibility to test testing and develop for sid. > 2) The 'remove testing' proposal Amoung many other problems this postpones most work on the installer until the release it will install is frozen. Could you or somebody else please list some of them? thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Kevin Mark <[EMAIL PROTECTED]> wrote: > > 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) I'm sorry Kevin but I totally missed the point of your answer. Considering that we know that experimental is not a full branch and there's no migration from experimental to unstable, do you agree then we could remove experimental and switch unstable automatic nature to not automatic (release) and keep it's current features: 'full' branch, migration from unstable to testing and others ? thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 02:36:55PM +0200, Magnus Holmgren wrote: > On Tuesday 12 June 2007 14:09, Adam Borowski wrote: > > English linguistic is a descriptive science -- what is correct and what is > > not depends on what people use. This stays in stark contrast to > > prescriptive languages like French where a government agency is entitled to > > ban the use of an established word and enforce using a made-up replacement. > > You're arguing that since few people use an otherwise superior concept, > Debian > should not use it either -- a fallacy known as argumentum ad populum > (http://en.wikipedia.org/wiki/Argumentum_ad_populum). Except, I did not claim that one of the versions is superior. What I stated was: 1. English is a language where the correct usage is what most people use, 2. "kilobyte" is preferred over "kibibyte" by a vast majority of those whose communicate using means accessible to Google search Thus, referring to popularity is not fallacious here; my argument was that in the case of English, it's popularity not prescriptions which determines which version is correct. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 13:57 +0100, Darren Salt a écrit : > I demand that Josselin Mouette may or may not have written... > > When I use a computer program, I don't want to wonder whether it uses > > precise units or approximate ones. A computer is a damn stupid machine > > and it will never know whether I need precision. Which is why it should > > *always* do things the precise way. > > Agreed. Use 1024 rather than the imprecise and misleading 1000... The question is not whether to use powers of 2 or 10 (different software use both), but rather to use the good prefixes depending on that choice. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 14:59 +0200, Adam Borowski a écrit : > > I get 59 500 hits for "kibibyte" and 1.5 million hits for "kilobyte". > > That's > > about 4%, not 0.3%. In fact, it's sufficiently widespread to earn a place > > in > > dictionaries, IMHO. > > That's the cap I mentioned earlier -- most searches are halted soon after > roughly 1M hits. Sure, this is why googling for "for" returns 7 billion entries. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 14:57, Darren Salt wrote: > I demand that Josselin Mouette may or may not have written... > > [snip] > > > When I use a computer program, I don't want to wonder whether it uses > > precise units or approximate ones. A computer is a damn stupid machine > > and it will never know whether I need precision. Which is why it should > > *always* do things the precise way. > > Agreed. Use 1024 rather than the imprecise and misleading 1000... Come now, there is no inherent difference in *precision* between 1000 and 1024, or K/k and Ki. Precision is the number of digits an amount is expressed in. *Accuracy* is the correctness of an amount, and depending on the situation, either kB or KiB may allow one to express an amount accurately with the least number of digits. For example, 1 Kibyte is exactly 1024 byte (1.024 kbyte), and 1 kbyte is exactly 1000 byte (can't be expressed exactly as a decimal fraction in Kibyte, because 0.1 Kibyte is a non-integral number of bytes). Hence, having two sets of prefixes to choose from depending on what fits best is the best option. -- 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 pgpXkCK9UzpD1.pgp Description: PGP signature
Consequences of the removal of Experimental.
> On Mon, Jun 11, 2007 at 07:56:13PM -0400, Joey Hess wrote: > > This assumes that experimental is used by a lot of people, which I > > doubt, especially given the default apt pins and the numbers above. Le Tue, Jun 12, 2007 at 10:08:20AM +0100, Mark Brown a écrit : > There's also the fact that if you remove experimental it's easy enough > for people to set up their apt repositories somewhere if they want to > provide packages outside of unstable. ... but they would lose the autobuilding from buildd.net. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- 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 15:36, Adam Borowski wrote: > On Tue, Jun 12, 2007 at 02:36:55PM +0200, Magnus Holmgren wrote: > > On Tuesday 12 June 2007 14:09, Adam Borowski wrote: > > > English linguistic is a descriptive science -- what is correct and what > > > is not depends on what people use. This stays in stark contrast to > > > prescriptive languages like French where a government agency is > > > entitled to ban the use of an established word and enforce using a > > > made-up replacement. > > > > You're arguing that since few people use an otherwise superior concept, > > Debian should not use it either -- a fallacy known as argumentum ad > > populum (http://en.wikipedia.org/wiki/Argumentum_ad_populum). > > Except, I did not claim that one of the versions is superior. What I > stated was: 1. English is a language where the correct usage is what most > people use, 2. "kilobyte" is preferred over "kibibyte" by a vast majority > of those whose communicate using means accessible to Google search But "kilobyte" and "kibibyte" are different words, not alternate spellings of the same word. Their meanings overlap, but are not identical. Therefore "kibibyte" is not incorrect just because more people use the less precise/more ambiguous "kilobyte". > Thus, referring to popularity is not fallacious here; my argument was that > in the case of English, it's popularity not prescriptions which determines > which version is correct. 3. You also stated that Debian should not use IEC prefixes, calling it, or perhaps rather even discussing it, "madness". Should I have concluded that it is solely other reasons, and not popularity, that is ground for your aversion? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpu3vlMKm7tU.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 15:46, Magnus Holmgren wrote: > On Tuesday 12 June 2007 14:57, Darren Salt wrote: > > I demand that Josselin Mouette may or may not have written... > > > > [snip] > > > > > When I use a computer program, I don't want to wonder whether it uses > > > precise units or approximate ones. A computer is a damn stupid machine > > > and it will never know whether I need precision. Which is why it should > > > *always* do things the precise way. > > > > Agreed. Use 1024 rather than the imprecise and misleading 1000... > > Come now, there is no inherent difference in *precision* between 1000 and > 1024, or K/k and Ki. Sorry, semantically (or linguistically or something) "kibibyte", "mebibyte" and the others are more precise because they mean exactly one thing, whereas "kilobyte", "megabyte" etc. *can* (currently) mean either of two things unless explicitly or implicitly disambiguated. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp6vXOhG5uhE.pgp Description: PGP signature
Re: [OT] howto file bugs in debian bug-tracker
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > >https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 . > >I know this is not the place, so let's take this off-list perhaps or > >point to a better resource/mailing list where I can direct that. > > Cheers ! > > If you mean filing a bug with the Debian BTS, use the reportbug tool, > available in the package of the same name. I think that the original question should raise more than 'just use the tool'. Indeed, it would probably benefit both Ubuntu and Debian if a way to link bugs between Launchpad and the Debian BTS. I see something like Pierre Habouzit's bts-link which allows to automatically track upstream bugs in Debian BTS as long as the bug in Debian has been reported upstream as well *and* tagged as such by the Debian maintainer. I'm not really familiar with Launchpad tools but it would be Good to make as easy as possible to "forward" bugs received in Ubuntu to "upstream", ie Debian, ie less manually than what seems to be suggested in https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 I do not mean that any bug reported in Ubuntu should be automagically reported to Debian's BTS. It should be a manual "point-an-click" action to be used by Those In Charge in Ubuntu when they decide wisely that it is Good to report the issue in Debianand *link* both issues. signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Scott James Remnant <[EMAIL PROTECTED]> writes: > This is a strong advocation for using powers of ten everywhere, and > abolishing the use of powers of two multiples altogether, no? Nothing needs to be abolished but inconsistency. The same good would be had by *knowing the difference*, and differentiating explicitly between powers of 10 and powers of 2. We have the standard tools now to do that, if we but use them. -- \ "I have never made but one prayer to God, a very short one: 'O | `\ Lord, make my enemies ridiculous!' And God granted it." -- | _o__) Voltaire | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] howto file bugs in debian bug-tracker
> I do not mean that any bug reported in Ubuntu should be automagically > reported to Debian's BTS. It should be a manual "point-an-click" > action to be used by Those In Charge in Ubuntu when they decide wisely > that it is Good to report the issue in Debianand *link* both > issues. In case it's not clear, of course, my point is that the work to do probably lies more in Ubuntu tools but having the goals discussed in common. -- signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Darren Salt <[EMAIL PROTECTED]> writes: > If I need to disambiguate, I'll say either "real kilobyte" or > something like "marketroids' kilobyte". And as for the next step up, > well, "gigabytes" is a given, and it's tempting to say "giblets"... That's assuming that everyone you converse with is aware of the particular definition you carry for those terms. Alternatively, you could use terms already well-defined and standardised. -- \"None can love freedom heartily, but good men; the rest love | `\not freedom, but license." -- John Milton | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/12/07, Adam Borowski <[EMAIL PROTECTED]> wrote: Except, I did not claim that one of the versions is superior. What I stated was: 1. English is a language where the correct usage is what most people use, 2. "kilobyte" is preferred over "kibibyte" by a vast majority of those whose communicate using means accessible to Google search I didn't want to get involved with this, but it's seems clear to me that both KB and KiB would both be written out as "kilobyte" in most cases because most of the time it simply doesn't matter. It also seems clear to me that in cases where accuracy matters you should use the prefix that applies. However, I don't think any of the examples given it really matters, except possibly the DVD sizing, but in that case you'd just drag it and see if it fits. (Disclaimer: I'm from a metric country and bytes are really the only thing where there is ambiguity as to what the 'k' means). Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consequences of the removal of Experimental.
On Tue, Jun 12, 2007 at 10:57:17PM +0900, Charles Plessy wrote: > > On Mon, Jun 11, 2007 at 07:56:13PM -0400, Joey Hess wrote: > > > This assumes that experimental is used by a lot of people, which I > > > doubt, especially given the default apt pins and the numbers above. > > Le Tue, Jun 12, 2007 at 10:08:20AM +0100, Mark Brown a écrit : > > There's also the fact that if you remove experimental it's easy enough > > for people to set up their apt repositories somewhere if they want to > > provide packages outside of unstable. > > but they would lose the autobuilding from buildd.net. which doesn't work properly anyways. The experimental buildd network is at best a joke. Let's take the glibc 2.6 for example: quoting http://packages.qa.debian.org/g/glibc.html: [2007-05-30] Accepted 2.6-0exp2 in experimental (low) (Aurelien Jarno) I'll let you check in http://ftp.debian.org/debian/pool/main/g/glibc/ that only the amd64 binary is present. It's the architecture Aurélien used to upload. It was 2 weeks ago. And I'm sure other examples exist. The experimental uploads of the glibc are very useful to check that the libc builds and passes the testsuite properly. If we have to wait for 2 weeks to have an answer to that test (and it's a still running counter for now) then it's already useless anyways. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptBVuSgr1ia.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote: > The difference is a sufficiently small percentage, that most users will > not care. No, like I said in my earlier post, the error grows quickly. As 1.024^x, in fact. x = 1 kibi vs. kilo 2.4% x = 2 mebi vs. mega 4.9% x = 3 gibi vs. giga 7.4% x = 4 tebi vs. tera 10% Especially nowadays with terabyte disks coming out and hitting the consumer market, there is *no place* for 10% of ambiguity. This was precisely my point earlier. "Back in the day", nobody cared for 2.4% error because all they ever measured anything in was kilo-somethings. -- 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
shirish writes ("Using standardized SI prefixes"):
> Please look at http://en.wikipedia.org/wiki/Binary_prefix .
Urgh, these things are ugly and an abomination. We should avoid them.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2007 06:24 AM, Ingo Juergensmann wrote: > 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. Besides m68k, snapshot.debian.net maybe also have some use for these disks (but AFAIK the server is in Japan). You can also mail [1]Hardware Donations Coordination, they can help find a destination for these disks. i18n server probably will need some space in a near future. 1. <[EMAIL PROTECTED]> There are also some other Free Software Projetcs in [*]Brazil and Latin America that could use that (BrOffice.org, the Brazilian name for OpenOffice.org due to trademark issues; FLISOL -- Free Software Latin American Install Festival). Kind regards, [*]: I know it because I'm taking care of their servers and helping with their infrastructure. - -- Felipe Augusto van de Wiel (faw) "Debian. Freedom to code. Code to freedom!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbrguCjAO0JDlykYRAkw8AKDV8odRgONUf7m+LT64AF+FS1CvTgCcCqu+ 7PhLzv83ImJYRuPwe1myRzc= =yoPk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 15:50 +0100, Alex Jones wrote: > On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote: > > The difference is a sufficiently small percentage, that most users will > > not care. > > No, like I said in my earlier post, the error grows quickly. As 1.024^x, > in fact. > > x = 1 kibi vs. kilo 2.4% > x = 2 mebi vs. mega 4.9% > x = 3 gibi vs. giga 7.4% > x = 4 tebi vs. tera 10% > > Especially nowadays with terabyte disks coming out and hitting the > consumer market, there is *no place* for 10% of ambiguity. > a) terabyte disks are often just that, 1x10^12 bytes. b) quoting the disk as 1TB guarantees that you have at least 1x10^12 bytes available. Depending on the actual disk model, you may have 1x2^40 bytes, or 1024x10^9 bytes, or 1024x2^30 bytes available - or in fact anything in between. Only by quoting 1TB are you not potentially violating a guarantee of available bytes. It is always better to underquote than overquote. c) One of each "binary" unit, rounded with no decimal places, is identical to the equivalent SI unit. 1YB = 1x10^241YiB = 2^80 =~(0 dec place) 1YB 1ZB = 1x10^211ZiB = 2^70 =~(0 dec place) 1ZB 1EB = 1x10^181EiB = 2^60 =~(0 dec place) 1EB 1PB = 1x10^151PiB = 2^50 =~(0 dec place) 1PB 1TB = 1x10^121TiB = 2^40 =~(0 dec place) 1TB 1GB = 1x10^9 1GiB = 2^30 =~(0 dec place) 1GB 1MB = 1x10^6 1MiB = 2^20 =~(0 dec place) 1MB 1kB = 1x10^3 1KiB = 2^10 =~(0 dec place) 1kB d) There are few places where binary units should be exposed to humans anyway. Bandwidth should be quoted in true SI units over a metric of time, e.g. kilobytes-per-second (e.g. the average UK DSL upload speed is 250kbps == 250,000bps) Therefore Traffic should also be quoted in true SI units to make conversion between bandwidth and traffic easy[0] (e.g. the web server shifted 86.4GB today =~ 86,400,000,000 bytes) Therefore File Sizes should also be quoted in true SI units, because they consist the majority of traffic; and to allow easy determining of the speed of upload (my 10GB file will take ~90 hours to upload on my DSL line[1]) Therefore Disk Sizes should also be quoted in true SI units, because they are used to store files, and because the ATA standard says so (I can fit 10 10GB files on my 100GB disk). Memory usage should be quoted in true SI units, since executable programs are derived from files (this 10MB program binary will use 10MB of RAM) Therefore Memory sizes should also be quoted in true SI units (I can fit 50 10MB programs, and 50 10MB files in my 1GB of RAM) The only real places I can see are where an implementation factor actually results in things using a true power of two, for example filesystem block sizes or disk sector sizes, etc. And in these cases, the multiple of two only extends as high as the "block" or "sector" unit. A 1.5GB file will use 366,211 blocks of 4096 bytes. Since you're referring to a technical implementation detail, which is only interesting in terms of accuracy, using phrases such as "kibiblocks" is ridiculous. Scott [0] try converting a continual 8 Megabits-per-second to Gibibytes for the day [1] !!! the UK sucks -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Consequences of the removal of Experimental.
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Tue, Jun 12, 2007 at 10:57:17PM +0900, Charles Plessy wrote: >>> There's also the fact that if you remove experimental it's easy enough >>> for people to set up their apt repositories somewhere if they want to >>> provide packages outside of unstable. >> but they would lose the autobuilding from buildd.net. buildd.net is only a frontend to some buildd data, it has nothing to do with the experimental autobuilders. > which doesn't work properly anyways. The experimental buildd network > is at best a joke. Let's take the glibc 2.6 for example: glibc is a special case and usually breaks the mail limit on most hosts. I'm still waiting for the local admin (... Ganneff) to fix the max mail size to actually see glibc build logs. I'm also waiting to move the wanna-build for experimental to another host, were it can finally be properly updated so that versions containing ~ don't fuck up the version comparision (which is the reason for you getting #425784, but not trying any newer version). Marc -- BOFH #163: no "any" key on keyboard pgp5H6UUG8ZAX.pgp Description: PGP signature
Re: Using standardized SI prefixes
Actually bandwidth is mesured in bits per second and no bytes per second On 6/12/07, Scott James Remnant <[EMAIL PROTECTED]> wrote: Bandwidth should be quoted in true SI units over a metric of time, e.g. kilobytes-per-second (e.g. the average UK DSL upload speed is 250kbps == 250,000bps) Scott [0] try converting a continual 8 Megabits-per-second to Gibibytes for the day [1] !!! the UK sucks -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- BUGabundo :o) (``-_-´´) GPG key 1024D/00967685 Linux user #443786 http://BUGabundo.net http://BrinKadeiraS.BUGabundo.net http://host.BUGabundo.net -- http://alojamento.BUGabundo.net From 1€ / month Crazy Domain Insane (200GB disk, 2TB bw, 6.00€ ($7.95)/month) at http://www.dreamhost.com/r.cgi?249195/signup 50$ discount with promo code "BUG50" on all plans Free lifetime domain with promo code "BUGDOMAIN"
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 16:50 +0100, (``-_-´´) -- Fernando wrote: > Actually bandwidth is mesured in bits per second and no bytes per second > > On 6/12/07, Scott James Remnant <[EMAIL PROTECTED]> wrote: > >Bandwidth should be quoted in true SI units over a metric of time, > >e.g. kilobytes-per-second (e.g. the average UK DSL upload speed is > >250kbps == 250,000bps) > Right; I got the example correct but thinko'd the text. Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 16:52, Ian Jackson wrote:
> shirish writes ("Using standardized SI prefixes"):
> > Please look at http://en.wikipedia.org/wiki/Binary_prefix .
>
> Urgh, these things are ugly and an abomination. We should avoid them.
Purely emotional arguments. I think it's to a big extent just a matter of
getting used to them.
Do you have anything to add that hasn't already been said?
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
pgpSvfcE221IF.pgp
Description: PGP signature
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 05:49:18PM -0600, Wesley J. Landaker wrote: > Well, in SI units, KB never means kilobyte, and is not ambiguous at all; > it's a kelvin??bel. Nope. kelvin is a unit, not a prefix. K as a prefix means kilo, so KB is kilo bell. You better have small values or you are dealing with something very very loud. So yes already trying to apply SI units to bytes has gone all wrong and they shouldn't have even tried in the first place. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 04:20:42AM +0100, Alex Jones wrote: > 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"? Because computer people have always bastardised everything. Booting, window, mouse, etc. > 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. > > 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. :) The drive makers screwed up. They are the ones that should be fixed. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 12:19 -0400, Lennart Sorensen a écrit : > Nope. kelvin is a unit, not a prefix. K as a prefix means kilo, so KB > is kilo bell. Prefixes are case-sensitive. Kilo is "k". (This is also why there is much less ambiguity with K used for kibibytes.) -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 06:25:22PM +0200, Josselin Mouette wrote: > Prefixes are case-sensitive. Kilo is "k". (This is also why there is > much less ambiguity with K used for kibibytes.) Hmm, I used to think both k and K were accepted for kilo, but I can't find anything that says K is accepted for use as kilo. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: > Sorry, i forgot CUT it looks like a 0 proposal since it came first. > How and when do you plan to start a team for that and have you > considered who from other teams will need to join/agree on the idea? I don't necessarily start a team for every proposal I make. :-) I'm interested to see what the general reception is to the ideas in CUT, I don't know if I've identified everything that needs to be done, or have perhaps chosen some things to do that arn't really necessary. > >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 > >(...) > >(For bonus fun, someone could graph how these change over time..) > > Any idea on how to collect more reliable data in a opt-in base? Does a > survey on pentabarf (or public acessible) during debconf makes sense? The numbers are not entirely reliable since a) not everyone uses reportbug b) some people run reportbug on a machine that doesn't have the bug c) some people file many more bugs reports than others d) it's likey that users of some suites tend to generate more bug reports than others e) there's no differentiation between developers and users d) duplicate bugs are not accounted for But I do think that the numbers are a pretty good indication of how much use testing receives by the kind of user/developer who contributes to Debian. It's not clear to me how a straw poll at Debconf would result in better numbers. > Wrong, if I'm asking for experimental removal I'm assuming that > there's not a lot of people using that. Considering the rest of your > argument, definitely a lot of people will use testing instead this > 'new unstable'. Do you see? No, I don't understand. As I said, unstable will not become significantly more unstable if all experimental uploads are directed there. -- see shy jo signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Let me outline the 'testing' pros and cons from my point of view: 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. Packages won't transition if they are not ready. This can mean: not built on all release archs, not installable in testing, making other packages in testing uninstallable, having more RC bugs in unstable than in testing or not waiting long enough in unstable. The Release Team can force packages in, block packages from going in, change the waiting time and hint some packages to go in together. 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 Which would remove a testing ground which doesn't influence the releasability of a package. People are urged to upload to experimental if the version they're uploading is not meant to transition to testing. I don't see what advantage removing experimental has? * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... [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 might be better solved by CUT IMHO. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures There are experimental autobuilders for all archs. * 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 This is more or less what unstable is meant for at the moment... 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. That's a status quo AFAICS. As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Josselin Mouette wrote: > The question is not whether to use powers of 2 or 10 (different software > use both), but rather to use the good prefixes depending on that > choice. It sounds like you've surveyed a lot of software in Debian and found some that uses 2 and some 10 for data storage measurement[1]. What's the breakdown look like between the two? The only software I know of that uses powers of 10 is partman (which I'm pretty sure d-i has a bug report about somewhere). But I have not surveyed the other software, aside from a few things like ls that I use day-to-day and know use powers of 2. I had generally assumed that most programmers were reaonsable and used powers of 2, but this thread is certianly changing my mind about *that*. -- see shy jo [1] Bandwidth measurement is, as noted in this thread, a general absolute mess and PITA. signature.asc Description: Digital signature
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 05:19:45AM +, Andrew M.A. Cater wrote: > 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 :) US gallon, of course; that way you get powers of two from the ounce on up. 8 gallons to the kiloounce; 32 gallons to the kilogill. -- 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]
Bug#428575: ITP: plexus-i18n -- Plexus internationalisation package.
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-i18n Version : 1.0-beta-6 Upstream Author : Plexus Developers * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : Plexus internationalisation package. Required for maven2 packaging -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
2007/6/12, Josselin Mouette <[EMAIL PROTECTED]>: Sure, this is why googling for "for" returns 7 billion entries. billion = 10^9 or billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) further argument to use powers, not words to define multiples. P.S.: I googled 'for' ~7*10^9 results. -- PMarc: Debian, GIS, gpsd, OpenWRT user and wannabe-devel Lives @ -22.915 -42.224 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > Sorry, i forgot CUT it looks like a 0 proposal since it came first. > How and when do you plan to start a team for that and have you > considered who from other teams will need to join/agree on the idea? I don't necessarily start a team for every proposal I make. :-) Oh, i just followed the "I propose that we form a team" sentence you wrote there. :-P I'm interested to see what the general reception is to the ideas in CUT, I don't know if I've identified everything that needs to be done, or have perhaps chosen some things to do that arn't really necessary. I think that the proposal is good and we need bless and a team with people from the following others teams: RM team, security testing team, d-i and probably kernel. This new team will work for CUT and be its voice inside the others teams, exactly as we do with Debian Desktop. Debian Desktop as a whole isn't a goal of every related team involved, but the people involved in the Debian Desktop are able to make a difference for our aims in each one of them. > >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 > >(...) > >(For bonus fun, someone could graph how these change over time..) > > Any idea on how to collect more reliable data in a opt-in base? Does a > survey on pentabarf (or public acessible) during debconf makes sense? The numbers are not entirely reliable since a) not everyone uses reportbug b) some people run reportbug on a machine that doesn't have the bug c) some people file many more bugs reports than others d) it's likey that users of some suites tend to generate more bug reports than others e) there's no differentiation between developers and users d) duplicate bugs are not accounted for But I do think that the numbers are a pretty good indication of how much use testing receives by the kind of user/developer who contributes to Debian. It's not clear to me how a straw poll at Debconf would result in better numbers. Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. > Wrong, if I'm asking for experimental removal I'm assuming that > there's not a lot of people using that. Considering the rest of your > argument, definitely a lot of people will use testing instead this > 'new unstable'. Do you see? No, I don't understand. As I said, unstable will not become significantly more unstable if all experimental uploads are directed there. Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Hi Luk, On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: (...) > * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... I'm not writing about "automatic" transition from unstable to testing through scripts. It was about the Release file. It's pretty much the key of that proposal and why I've suggested remove experimental, because in a scenario that we switch unstable to not automatic, experimental will be redundant. > [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 might be better solved by CUT IMHO. Probably, but the "remove experimental" and CUT proposals could be implemented at the same time. (...) As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Could you please write more about the versioning instead of less RC bugs idea? thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Back to the point (was: Re: Reasonable maximum package size ?)
On Tue, Jun 12, 2007 at 02:57:51PM +0200, Andreas Tille wrote: > On Tue, 12 Jun 2007, Tim Cutts wrote: > > >That's not true, unfortunately. They also have different design > >criteria for duty cycles, and more stringent MTBF testing > >requirements. There's been a lot of assertion in this thread, > >without any real data, so this post provides links to some hard data > >provided by disk manufacturers. > > Thanks for the facts. > > >As many others have said in this thread, you get cheap or reliable. > >You do not get both. > > Which perfectly fits to my real life experience. BTW, could we now > come back to the development related issues in this thread. I do > not really mind whether it is cheap or not what we expect people > to do who want to mirror Debian: We add them a burden (even adding > cheap stuff is some work and we should make sure that it is worth > the effort) and the initial question is: How can we meaningful > provide large chunks of data? I tried to give a meaningful answer to that in <[EMAIL PROTECTED]>, but received no reply; I guess it got drowned in the silly "all disks are reliable!" noise. Perhaps you may want to read the three final paragraphs there and give your opinion. -- 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: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: > Considering that we know that experimental is not a full branch and > there's no migration from experimental to unstable, do you agree then > we could remove experimental and switch unstable automatic nature to > not automatic (release) and keep it's current features: 'full' branch, > migration from unstable to testing and others ? Eh, I don't think I understand what you're suggesting here. Perhaps a few questions will help: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? Personally, I think the net effect on _unstable_ achieved by removing _experimental_ will be zero. * What do you mean by "switch unstable automatic nature to not automatic" * How does that fit in with "keep it's current features: 'full' branch, migration from unstable to testing and others"? I'm afraid you've completely lost me in that bit of your suggestion. -- 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 Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov <[EMAIL PROTECTED]> wrote: > On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: > > > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) > > =10^12 :) > > and Germany, France, former UdSSR, Anywhere where milliard is 10^9, basically... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: > Do you think that the numbers are positive in terms of testing usage, > really? I see the numbers even if not that reliable as proof of my > argument that just a few (almost half if compared with unstable) bug > reporters are actually using testing. > > Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. I'd be happy if there were an even larger number of users happily using testing, without encountering and filing a lot of bug reports. As seems to be to case with stable[1]. The number of bug reports filed from testing actually seems high to me. Although it's hard to say without more analysis (perhaps looking at the severities of those bugs). > Exactly the first proposal, remove experimental and upload everything > to unstable with the difference that unstable will become not > automatic as experimental is today. Keep migration from unstable to > testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. -- see shy jo [1] We know from popcon that currently three times as many users use stable as unstable+testing. signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Wouter Verhelst <[EMAIL PROTECTED]> wrote: On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: > Considering that we know that experimental is not a full branch and > there's no migration from experimental to unstable, do you agree then > we could remove experimental and switch unstable automatic nature to > not automatic (release) and keep it's current features: 'full' branch, > migration from unstable to testing and others ? Eh, I don't think I understand what you're suggesting here. Perhaps a few questions will help: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? Personally, I think the net effect on _unstable_ achieved by removing _experimental_ will be zero. I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. * What do you mean by "switch unstable automatic nature to not automatic" In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. * How does that fit in with "keep it's current features: 'full' branch, migration from unstable to testing and others"? We've no experimental to unstable migration as you know, but the 'new unstable' should keep its current features as full branch (all the packages) and migration. I'm afraid you've completely lost me in that bit of your suggestion. I hope I was more clear now and you figure out the impact of this change. :-) thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] howto file bugs in debian bug-tracker
Em Ter, 2007-06-12 às 16:19 +0200, Christian Perrier escreveu: > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > >https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 . > > >I know this is not the place, so let's take this off-list perhaps or > > >point to a better resource/mailing list where I can direct that. > > > Cheers ! > > > > If you mean filing a bug with the Debian BTS, use the reportbug tool, > > available in the package of the same name. > > > I think that the original question should raise more than 'just use > the tool'. > > Indeed, it would probably benefit both Ubuntu and Debian if a way to > link bugs between Launchpad and the Debian BTS. I see something like > Pierre Habouzit's bts-link which allows to automatically track > upstream bugs in Debian BTS as long as the bug in Debian has been > reported upstream as well *and* tagged as such by the Debian > maintainer. > > I'm not really familiar with Launchpad tools but it would be Good to > make as easy as possible to "forward" bugs received in Ubuntu to > "upstream", ie Debian, ie less manually than what seems to be > suggested in > https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/+bug/119995 > > > I do not mean that any bug reported in Ubuntu should be automagically > reported to Debian's BTS. It should be a manual "point-an-click" > action to be used by Those In Charge in Ubuntu when they decide wisely > that it is Good to report the issue in Debianand *link* both > issues. FWIW, I'm working on something a bit related to that for Debian on this year GSoC: A tool to help triaging (Debian) bugs, of which one (arguably the main) feature will be to facilitate forwarding bug reports upstream. Maybe it would be interesting to expand a bit the concept and allow using launchpad as a source of bugs if ubuntu people is interested... -- Gustavo R. Montesino http://grmontesino.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > Do you think that the numbers are positive in terms of testing usage, > really? I see the numbers even if not that reliable as proof of my > argument that just a few (almost half if compared with unstable) bug > reporters are actually using testing. > > Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. Exactly my point, again: Contributors and developers are using unstable or stable more than testing. I would like to see a scenario where we keep a lot of people using unstable with no automatic updates to force them pick how and what much of that they want, but at the same time use as base of their system testing. There's no better way to make CUT a reality, IMHO. The two proposals (CUT and 'remove experimental and change unstable to not automatic updates') aren't mutually exclusive. (...) > Exactly the first proposal, remove experimental and upload everything > to unstable with the difference that unstable will become not > automatic as experimental is today. Keep migration from unstable to > testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. I don't get it, as you also realized: unstable _is_ experimental. Let us develop over testing with some pieces of unstable, no need to have two experimental branches once we switch unstable to not automatic updates. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tuesday 12 June 2007 21:40, Gustavo Franco wrote: > > * What effect do you think removing experimental will have on > > unstable? * How do you think it will have that effect? > > > I think it will have a positive effect if we add 'NotAutomatic: yes' > into unstable release file. Are you also willing to promote uploading packages "that are quite probably broken in some ways, but the maintainer still would like to see tested" to unstable? I don't think I would like that at all! An essential difference between unstable and experimental is that unstable has "should be working" packages, while experimental has "quite likely still has issues" packages. If experimental were dropped, how the hell am I supposed to distinguish between the two? Personally I think the current system is fine. I certainly don't think I would like the hassle of having to decide for myself (based on no available information) if I should upgrade a package or not. For me, the only reasons _not_ to upgrade a package in unstable are: - broken dependencies: handled perfectly fine by packing tools, to be expected for unstable - severe known issues: should be fixed ASAP by maintainer; aptitude makes it really easy to "forbid" a known broken version but automatically update once a new (hopefully fixed) version becomes available Cheers, FJP pgpVbDp3Z19RX.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Tuesday 12 June 2007 21:51, Gustavo Franco wrote: > I don't get it, as you also realized: unstable _is_ experimental. No, it most certainly is *not*, and any developers who treat it as such should be drawn and quartered. pgpvlthFzQSRb.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: > On 6/12/07, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > >On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: > >> Considering that we know that experimental is not a full branch and > >> there's no migration from experimental to unstable, do you agree then > >> we could remove experimental and switch unstable automatic nature to > >> not automatic (release) and keep it's current features: 'full' branch, > >> migration from unstable to testing and others ? > > > >Eh, I don't think I understand what you're suggesting here. Perhaps a > >few questions will help: > >* What effect do you think removing experimental will have on unstable? > >* How do you think it will have that effect? > > > >Personally, I think the net effect on _unstable_ achieved by removing > >_experimental_ will be zero. > > I think it will have a positive effect if we add 'NotAutomatic: yes' > into unstable release file. Doing that would just annoy people, nothing more. Those who only have 'unstable' lines in their sources.list will not see any change. Those who have only 'testing' in their sources.list will not see any change, either. The only people who will see any difference from your proposed change are people who have sources.list lines for multiple distributions in their sources.list, and these are typically advanced users already anyway, with perhaps a rather complex set of apt preferences. Given that, I don't think you'd be able to achieve any postive effect by changing the defaults of what happens if you add both unstable and testing entries to sources.list. Additionally, there's no need to drop experimental if you want to make this type of change. If you want to encourage more people to use testing, fine; that's not a bad idea in itself. But by changing the defaults of what happens in something that really is a corner case and by removing something else that's totally unrelated, you don't do that. Rather, you annoy people who know what the current defaults are, and who expect that these defaults haven't been randomly changed while they weren't watching. [...] -- 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: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > Do you think that the numbers are positive in terms of testing usage, > really? I see the numbers even if not that reliable as proof of my > argument that just a few (almost half if compared with unstable) bug > reporters are actually using testing. > > Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. Exactly my point, again: Contributors and developers are using unstable or stable more than testing. I would like to see a scenario where we keep a lot of people using unstable with no automatic updates to force them pick how and what much of that they want, but at the same time use as base of their system testing. There's no better way to make CUT a reality, IMHO. The two proposals (CUT and 'remove experimental and change unstable to not automatic updates') aren't mutually exclusive. (...) > Exactly the first proposal, remove experimental and upload everything > to unstable with the difference that unstable will become not > automatic as experimental is today. Keep migration from unstable to > testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. I don't get it, as you also realized: unstable _is_ experimental. Let us develop over testing with some pieces of unstable, no need to have two experimental branches once we switch unstable to not automatic updates. NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. experimental is playground, uploading packages to experimental if one is not sure they are good candidates for testing is what people should do. I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote: >> Gustavo Franco wrote: >> > Do you think that the numbers are positive in terms of testing usage, >> > really? I see the numbers even if not that reliable as proof of my >> > argument that just a few (almost half if compared with unstable) bug >> > reporters are actually using testing. >> > >> > Not better numbers, but statistics: x% of developers are using foo >> or bar. >> >> For testing to remain at a good quality level, there needs to be a large >> group of people using (and testing) unstable. That nearly 2x as many >> bugs are filed from unstable as from testing indicates to me that a >> healthy number of people are using unstable. > > Exactly my point, again: Contributors and developers are using > unstable or stable more than testing. I would like to see a scenario > where we keep a lot of people using unstable with no automatic updates > to force them pick how and what much of that they want, but at the > same time use as base of their system testing. There's no better way > to make CUT a reality, IMHO. The two proposals (CUT and 'remove > experimental and change unstable to not automatic updates') aren't > mutually exclusive. > >> (...) >> > Exactly the first proposal, remove experimental and upload everything >> > to unstable with the difference that unstable will become not >> > automatic as experimental is today. Keep migration from unstable to >> > testing as it's and that's it. >> >> Making apt not automatically upgrade to newer versions from unstable >> doesn't seem useful. It's useful in the case of exeperimental because >> any given user of experimental only wants to pull a few packages from >> it. Most users of unstable want to pull _all_ available updates from it. > > I don't get it, as you also realized: unstable _is_ experimental. Let > us develop over testing with some pieces of unstable, no need to have > two experimental branches once we switch unstable to not automatic > updates. NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. experimental is playground, uploading packages to experimental if one is not sure they are good candidates for testing is what people should do. I believe we all know and read the official documents we can diverge about how people are actually using the branches, but that's not the point. I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Sure, a more experimental (and not automatic) unstable and heavily used testing from where we do main development and could generate CUT images easily. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote: >> Gustavo Franco wrote: I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Sure, a more experimental (and not automatic) unstable and heavily used testing from where we do main development and could generate CUT images easily. Next to having a more experimental base for testing migration which wouldn't help the Release Team at all and an unstable that probably would be used less what would it bring? Sorry, but I'm still not understanding in which way removing experimental would help. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > Hi Luk, > > On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: >> Gustavo Franco wrote: >> >> (...) >> > * Switch unstable (release) for not automatic updates >> >> They are only automatic as far as the Release Team wants them to be as >> explained earlier... > > I'm not writing about "automatic" transition from unstable to testing > through scripts. It was about the Release file. It's pretty much the > key of that proposal and why I've suggested remove experimental, > because in a scenario that we switch unstable to not automatic, > experimental will be redundant. Ok, I misunderstood what you meant. Making unstable not automatic would mean less testing of individual versions in unstable AFAICS which is a bad thing IMHO. I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. >> > 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. I'm not at all sure that it means we won't have less people using unstable, even more every version that is uploaded to unstable... I believe that people will use testing as base for contribute and develop using lots of packages from unstable, differently from what we've with experimental as outlined above. (...) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Hi Luk, On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: (...) > * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... I'm not writing about "automatic" transition from unstable to testing through scripts. It was about the Release file. It's pretty much the key of that proposal and why I've suggested remove experimental, because in a scenario that we switch unstable to not automatic, experimental will be redundant. Ok, I misunderstood what you meant. Making unstable not automatic would mean less testing of individual versions in unstable AFAICS which is a bad thing IMHO. > 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. I'm not at all sure that it means we won't have less people using unstable, even more every version that is uploaded to unstable... (...) As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Could you please write more about the versioning instead of less RC bugs idea? It's only in it's planning stage, but would at least include RC bug versioning support in britney... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: Gustavo Franco wrote: > Hi Luk, > > On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: >> Gustavo Franco wrote: >> >> > 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. I'm not at all sure that it means we won't have less people using unstable, even more every version that is uploaded to unstable... I believe that people will use testing as base for contribute and develop using lots of packages from unstable, differently from what we've with experimental as outlined above. Which is just proving my point that less people than today will use unstable. It will probably be more than the amount of people that is using experimental today, though I can't see why we should test our base for testing migration less to have a better testing?! Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: > Exactly my point, again: Contributors and developers are using > unstable or stable more than testing. I would like to see a scenario > where we keep a lot of people using unstable with no automatic updates > to force them pick how and what much of that they want, but at the > same time use as base of their system testing. That doesn't work. Testing is mostly identical to unstable unless the changes that filter into it have first been tested in unstable and the bad changes filtered out. With your proposal, there is a lower probability of a change being tested by anyone before it reaches testing. I've already discussed in this thread how cherry-picking of changes from experimental rarely works well enough to get useful testing in experimental. Do you have some reason to believe that cherry-picking changes from unstable would somehow work better? -- see shy jo signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Frans Pop <[EMAIL PROTECTED]> wrote: On Tuesday 12 June 2007 21:40, Gustavo Franco wrote: > > * What effect do you think removing experimental will have on > > unstable? * How do you think it will have that effect? > > > I think it will have a positive effect if we add 'NotAutomatic: yes' > into unstable release file. Are you also willing to promote uploading packages "that are quite probably broken in some ways, but the maintainer still would like to see tested" to unstable? Promote 'quite probably broken in some ways' stuff isn't the motto. Upload everything that we've in experimental actually seems to be more appropriate. I don't think I would like that at all! An essential difference between unstable and experimental is that unstable has "should be working" packages, while experimental has "quite likely still has issues" packages. If experimental were dropped, how the hell am I supposed to distinguish between the two? That's the point, you would be using testing for development and cherry picking changes from unstable manually. Remember that in this scenario we still have unstable to testing transition so if you don't push stuff manually it will get there anyway, probably the second step would fine tune the unstable to testing metric but RM team already has some ideas on this camp as Luk pointed out. Personally I think the current system is fine. I certainly don't think I would like the hassle of having to decide for myself (based on no available information) if I should upgrade a package or not. For me, the only reasons _not_ to upgrade a package in unstable are: As i wrote above you don't need to decide from a user point of view, considering that the testing scripts sooner or later will do that for you, of course a lot of people will push the latest GNOME, whatever from this new unstable to user over testing and then I believe it will help our next release. (...) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:32:21PM -0300, Gustavo Franco wrote: > On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote: > >NO! > > > >unstable is meant for packages that should be in the next stable > >release, as such only packages that are in the maintainer's opinion > >ready to migrate to testing should be uploaded to unstable. > > > >experimental is playground, uploading packages to experimental if one > >is not sure they are good candidates for testing is what people > >should do. > > I believe we all know and read the official documents we can diverge > about how people are actually using the branches, but that's not the > point. This is not a matter of opinion; both experimental and unstable have a clear and well-defined meaning. Using either in a different way than what they are intended to do will *break* Debian. Don't do that. If people use experimental incorrectly, then that's a bug. It certainly isn't something we should be happy or even encouraging. -- 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: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:25:59PM -0300, Gustavo Franco wrote: > Promote 'quite probably broken in some ways' stuff isn't the motto. > Upload everything that we've in experimental actually seems to be more > appropriate. Eh, you lost, now. Please go read what experimental is for. > >I don't think I would like that at all! An essential difference between > >unstable and experimental is that unstable has "should be working" > >packages, while experimental has "quite likely still has issues" > >packages. > >If experimental were dropped, how the hell am I supposed to distinguish > >between the two? > > That's the point, you would be using testing for development and > cherry picking changes from unstable manually. That doesn't work. Packages migrate from unstable to testing in only ten days; if people know that, nobody ever bothers to manually force package upgrades. [...] -- 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: Two proposals for a better Lenny (testing related).
On 12/06/07 at 22:23 +0200, Luk Claes wrote: > NO! > > unstable is meant for packages that should be in the next stable release, > as such only packages that are in the maintainer's opinion ready to migrate > to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Back to the point (was: Re: Reasonable maximum package size ?)
On Tue, 12 Jun 2007, Wouter Verhelst wrote: I tried to give a meaningful answer to that in <[EMAIL PROTECTED]>, but received no reply; I guess it got drowned in the silly "all disks are reliable!" noise. Perhaps you may want to read the three final paragraphs there and give your opinion. Well, in fact your opinion was reall meaningful and for the moment I had nothing to add - that's why I keept silence to keep the trafic on this thread that was drifting away low. To awake this thread again I'm quoting you here. On Mon, 11 Jun 2007, Wouter Verhelst wrote: 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. You are perfectly riht here. But even if it is gray there should be a document that draws this gray line for two reasons: 1. Make sure DDs know about the problem 2. Characterize the points in the far white and far black area. Personally, I'd advice the OP to try to find the smallest data set that is still at least moderately useful for the package, Sounds like a very reasonable advise for Packaging Manual. 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 I'd prefer the real pointer in the docs while the description should just say: Read doc_xy (preferably README.Debian to learn how to obtain larger data sets. I expect from a good doc that it contains a complete code example. 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. This comes very close to what I would regard really good user support. 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. Yes. When I was speaking about numbers I had more like a function dependand from certain key parameters in mind than hard numbers. So "roughly two times the average package size at the time the package is created" fits absolutely my expectation for a description of the limit. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum wrote: > On 12/06/07 at 22:23 +0200, Luk Claes wrote: >> NO! >> >> unstable is meant for packages that should be in the next stable release, >> as such only packages that are in the maintainer's opinion ready to migrate >> to testing should be uploaded to unstable. > > Then shouldn't we have a more aggressive policy about removals from > unstable, for packages that have failed to get into testing during the > past n months ? Actually, I support that. What about a push from unstable to experimental when a package fails to behave ? (given reasonable amount of time and notice, of course). This way, I tend to believe more people would have their eyes on experimental, and that might solve some of the problems adressed in this thread. Regards, Vincent -- Vincent Fourmond, Debian Developer http://vincent.fourmond.neuf.fr/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007, Luk Claes wrote: > Making unstable not automatic would > mean less testing of individual versions in unstable AFAICS which is a bad > thing IMHO. I wonder whether it would make sense to suggest default pinning levels in Release files to allow people in testing to add unstable safely without relying on the default release. Not sure it would be useful for backports anymore since these do use NotAutomatic already. Currently, we only distinguish: - NotAutomatic / Automatic - default release or not all other cases have to be handled by the end user/admin; but we could (instead?) pin experimental/unstable/testing/backports/stable for users by default in the Release files to some sane values which they may override. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/12/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote: On Tue, Jun 12, 2007 at 06:25:22PM +0200, Josselin Mouette wrote: > Prefixes are case-sensitive. Kilo is "k". (This is also why there is > much less ambiguity with K used for kibibytes.) Hmm, I used to think both k and K were accepted for kilo, but I can't find anything that says K is accepted for use as kilo. All the symbols in SI units have to be distinct, as combined units are units also. Consider: kWh = kilo-watt-hour = 3.6 MJ Nm = newton-metre The capital K is used for kelvin. So Km = kelvin-metre, which I suppose would be the unit to measure the total temperature over a length (product of temperature and length). Sure, most people can guess what you mean from the context but that doesn't make it right... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
