Re: debian can be better
On Wed, 27 Oct 2010, Patrick Matth??i wrote: Am 27.10.2010 23:32, schrieb Russell Coker: On Wed, 27 Oct 2010, Pedro Paulo Argolo jamer.ja...@hotmail.com wrote: needs better support video cards from Nvidia and ATI video boards Intel. I had configuration problems because of that, and for a typical user is a very embarrassing situation. ~: ( The change from nv to nouveau was a good improvement for my main system (Thinkpad T61), 2D graphics performance improved noticeably although I do occasionally get transient corrupted bitmaps. Debian is dedicated to free software (which precludes the non-free NVidia driver from being in main) and I don't want the security risk of running binary-only software on my important systems. Most desktop users also want to have some 2D/3D performance, or special features like tv out, xvideo acceleration etc etc. nouveau is a good replacement for nv, but still far away of being useful for powerful desktop users. So, buy a graphics card that supports the features you want rather than one that doesn't. That's how the free market works. It is unfortunate when you inherit hardware from others or otherwise don't have a choice in the matter, but you get what you pay for. I was also rather embarrassed when I bought a GeForce 2 back in 2002 and discovered that Nvidia's idea of source code was a small bit of C to interface to a binary blob. I'm boycotting them until they either provide documentation or release a proper open source driver, and I encourage you all to do the same. If you already own an Nvidia card, please poke them about it, because they don't think enough people care. ATI only partially misses out in that I only buy their hardware that is old enough to be supported by DRI. I am not aware of anything that stops a Debian user from using a binary-only Xorg driver. Not supported by us, officialy, they are also not on our installation cds (users have to activate non-free by themselve). Does Ubuntu or any other distro claim to support it? If you find a bug it doesn't seem like they could do much more than tell you to take it up with the manufacturer. It's not like anyone other than nvidia can support their drivers, so if they don't want to support your favorite distro, that's up to them to decide, and up to you to care about. But, yes, it is unfortunate when you inherit hardware that is only supported by closed source drivers/X servers. When will Debian start supporting windows graphics drivers so I can use my 3Dlabs cards? ;) (Honestly, I would be rather scared if they did.) Ivan
Re: correct way to mount stuff on tmpfs
On Mon, 25 Jan 2010, Thomas Koch wrote: Hi, while searching the right way to use tmpfs for a few locations, I found this howto: http://forums.debian.net/viewtopic.php?t=16450 What do you think about this approach? What's wrong with just putting it in /etc/fstab other than that synss doesn't like it? It seems like that would be least confusing, as it is where people expect mountpoints to be specified... Ivan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
On Wed, 13 Aug 2008, Brian May wrote: Dmitry E. Oboukhov wrote: qemu makes mount the directory /tmp/mount.$$. Attacker creates many symlinks /tmp/dir.\d+ - /etc and if qemu (/usr/sbin/qemu-make-debian-root) starts then /etc goes out from root directory tree. The result: system is unusable. I might be dense, but I don't get this. Attacker does: [EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234 Then the genuine user does: [EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234 mkdir: cannot create directory `/tmp/mount-1234': File exists strace shows: mkdir(/tmp/pmount-1234, 0777) = -1 EEXIST (File exists) So, ok, this means the process can't continue any more (denial of service attack), and if the process does continue this is a problem, otherwise I can't see how this would bring the entire system down. qemu-make-debian-root will continue running even if mkdir failed. Also, assuming qemu-make-debian-root is running with PID 1234, an attacker is free to change the /tmp/mount.1234 symlink during the execution of the script. If /tmp/mount.1234 is linked to /etc/, the script will mount the freshly created filesystem image on top of /etc, making a lot of programs very sad. An attacker could then change the symlink such that debbootstrap will install anywhere he wants. (which may allow him to overwrite some files, but I haven't looked closely at debbootstrap.) And then he could change the symlink again to overwrite and delete a few more files. Of course some of these are timing attacks, so may work with varying reliability. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)
On Wed, 14 May 2008, David Härdeman wrote: If the entropy pool is properly coded, there is no negative effect of adding data which may or may not be truly random to the pool (i.e. you cannot degrade the quality of the pool no matter what you add). Therefore step b) might add some entropy or it might do nothing at all, depending on how truly random the uninitialized data is, but it won't hurt. I think that might depend on how not truly random the data is. For example, suppose the pool is coded to simply xor the new entropy with the pool. This works great when the entropy is distributed evenly through all the bits. If you treat it as a black box, it may seem that no matter what entropy you add, you can't make the pool any worse. However, if the entropy you add happens to be a copy of the pool... Anyways, that doesn't really apply, since it isn't adding unitialized memory to the pool, it's simply using it as the initial value for the pool. I guess it's possible the uninitialized values just happen to cancel out the entropy that would later be added to the pool, but that seems extremely unlikely. In general, I think it would increase the entropy a little. I'm pretty sure openssl uses something better than xor, but I don't see how you could code a pool so it wouldn't be possible to degrade the quality by adding the right fake entropy. The goal of the patch that was used in Debian's OpenSSL was to placate valgrind by removing step b) as valgrind complained about the use of uninitialized memory (here it was one of the few cases where it might be legit to do so). Unfortunately, step d) was *also* removed by that patch. And therein lies the bug. What made me really sad, was that b) already had an #ifndef PURIFY around it. The ./Configure script already had an option that would do the right thing. If you simply google for purify, you would quickly find out it is a proprietary valgrind equivalent. Did the person who came up with the patch not wonder why there was an #ifndef around the thing he was commenting out? It seems really silly to leave an #ifndef around a comment, without bothering to check what it was supposed to change. Anyways, Debian is still my favorite distro, even though it's becoming a bit too nebie oriented for my liking. (This seems to be a common trend.) Not a DD, Ivan
Re: Targeting RPM and Debian from a Debian box?
On Fri, 6 Jul 2007, Russ Allbery wrote: Christian Convey [EMAIL PROTECTED] writes: My development workstation is running Debian, and I'd like to produce both .deb and .rpm releases of my software. Is this something people normally do from the same Debian workstation, or do they typically fire up a RedHat system to do their .rpm creation, and use a Debian workstation to do their .deb creation? You'll have to use the appropriate OS to build packages for that OS. Debian requires this as well in order to get things like shared library dependencies right, to satisfy Build-Depends, and so forth. It makes sense that RPM has the same issues. I don't build RPMs any more, but you should be able to build them just fine inside a chroot. Look at the schroot package if you want to do it as a normal user. You will still want an install of each distro you want to build/test packages for, although some things built for one distro may work fine on another. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, 21 Jun 2007, Hamish Moffatt wrote: On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: On Wed, 20 Jun 2007, Ben Finney wrote: The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. The other solution can be for humans to find those few (if any) packages that say MB when they mean 1,000,000 and fix only those. Then we'd have a consistent system conforming to the standards most CS people expect. How many packages can you name that measure bytes in powers of 10? Are there any? People tell me I am making an argument from ignorance, and that I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. Not everywhere related to computers. Only when the unit is bytes. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. Yes, for network traffic both are just as natural. Hard disks are different again; I don't know that there is any particular reason for them to have 2^n byte sectors (and at the hardware level perhaps they don't). Page sizes are powers of two. Filesystem block sizes are multiples of the sector sizes, and it's very convenient when they can be aranged nicely in pages. CD-ROMs have 2304 byte raw sectors. 2048 + 256 for ECC, both of which are powers of two. Even if you use the 2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by 10^1. Most NAND FLASH chips have 2062 byte blocks, which even throws the memory device argument out the window. I have no idea about this, but I would expect http://www.google.com/search?hl=enq=2062+flash+nandbtnG=Search to have more results where the 2062 is a block size... You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB (72x128M) DIMM, you're actually getting 1207959552 bytes of raw storage. But even then, the powers of two are more natural than the powers of 10. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 20 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: Here's a shell for people who don't remember what the output of their commands mean: #!/bin/bash while echo -n '$ '; read cmd line; do man $cmd | cat; eval $cmd $line | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; done I'm choosing this to quote because it highlights the mistake being made. The above assumes that this proposal is about *replacing*, unilaterally, every instance of one text with another. This is mistaken, because the proposal is about fixing *only* those cases where the unit does not match the quantity. The programs which output base-ten unit abbreviations correctly would be *broken* by the above simple substitution. The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. The other solution can be for humans to find those few (if any) packages that say MB when they mean 1,000,000 and fix only those. Then we'd have a consistent system conforming to the standards most CS people expect. How many packages can you name that measure bytes in powers of 10? Are there any? People tell me I am making an argument from ignorance, and that just because I don't know of any such packages doesn't mean they don't exist. Because of these packages that may or may not exist, they say we need to change all the other ones to avoid inconsistiencies with the packages we can't prove don't exist. Yey. Well, anyways, I'm a lot less worried now that I realized that these bug reports get ignored and passed around for years. At the rate things are going, Debian will probably be too newbie oriented for me well before you succeed at filling my output with is. :P Have fun, Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Sat, 16 Jun 2007, Wesley J. Landaker wrote: On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote: Le vendredi 15 juin 2007 ?? 17:36 -0400, Ivan Jager a ??crit : Yes. Any time the unit is bytes. There is even a standard for it. I must have missed that one. Could you point us to this standard? I too would love to see that standard. Ok, so it appears to be deprecated, but it does exist. October 30, 1986 ANSI/IEEE Std 1084-1986 IEEE Standard Glossary of Mathematics of Computing Terminology. http://ieeexplore.ieee.org/iel1/2485/1030/00026589.pdf?isnumber=1030prod=arnumber=26589arSt=ared=arAuthor= kilo (K). (1) A prefix indicating one thousand. (2) In statements involving size of computer storage, a prefix indicating 2^10, or 1024. mega (M). (1) A prefix indicating one million. (2) In statements involving size of computer storage, a prefix indicating 2^20, or 1,048,576. Apparently back then giga wasn't ever applied to computer storage. :) Ivan
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: On Thu, 14 Jun 2007, Ben Finney wrote: [re added the relevant quote] The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. Ok, so this applies to dd and what else? It applies to any software that refers to quantities that use these units. Pick a unit for the quantity, base-10 or base-2, and use its precise meaning and the precise term for it. I think you missed the point. The only times it is not rounded is when the user is specifying a size. (And even then it is sometimes rounded.) I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Any time the software says GB when the quantity was actually calculated in 2^30, or says GiB when the quantity was actually calculated in 10^9, the units are mismatched. Whether the quantity was rounded is irrelevant to this fact. It was relevant enough for Alex to say sizes aren't rounded... Yes, accuracy, precision, and ambiguity are all separate things. Rounding is not completely irrelevant though, since most of the time 1 GB is correct, 1 GiB is also correct. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Sat, 16 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? First, it would hardly say 79GB. Maybe 79.96GB which is much closer. Huh, I guess I just have a bigger journal than you, more inodes per byte, and some backup superblocks. (I use the defaults.) Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose was to look and sound silly while disambiguating from the commonly used ones we all know and love. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 19 Jun 2007, Magnus Holmgren wrote: Ivan Jager wrote: On Sat, 16 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: [...] Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) This sounds like another not a perfect solution fallacy. Accurately presenting the full amount of disk space a file uses is an orthogonal problem that having distinct prefixes can't be expected to solve. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. They are not strictly better. Did you not read the part where I said I didn't want an extra column of is that serves no real purpose? What you personally have become accustomed to is irrelevant in the big picture and in the long run. That you can't think of any problems doesn't mean that no problems exist It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. (http://en.wikipedia.org/wiki/Argument_from_ignorance). Actually, it is you who can't seem to think of any problems that would arise from changing almost everything. (or rather, you may be choosing to ignore said problems.) In addition, you seem to be trying to move the burden of proof. Why do I need to prove that there isn't a problem? It is those who think it needs changing who should be proving there is a problem and that their proposed change actually fixes it without introducing new problems. That you mistake an SI MB for a MiB, for example, is not an argument against consistent prefix usage. The quicker everybody stops using power of ten prefixes incorrectly, the quicker this transitional problem goes away. I don't mistake an SI MB for a MiB. Our disagreement is because I don't mistake a non-SI MB for an SI one, and, presumably, you do. This is why you see the ambiguity as a serious problem and I don't. I am not against consistent prefix usage. On the contrary, I have pointed out that all the programs I use consistently use MB to mean 2^20 bytes, and that I would rather not have this consistency broken by ever having one say MB when it means 10^6 bytes. Your argment is not in favor of consistency, but rather in favor of explicitly indicating consistency. I would find it much less obtrusive to simply drop a file in / explaining that we are consistent. (But I also think that is unnecesary.) Trying to adhere to what the outside world does will not make Debian consistent, because the outside world is not consistent. http://foldoc.org/?query=megabyte http://www.m-w.com/dictionary/megabyte http://dictionary.reference.com/browse/megabyte http://dictionary.oed.com/cgi/entry/00304795 How about using these prefixes to unambiguously refer to powers of 10? kd kidi 10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose was to look and sound silly while disambiguating from the commonly used ones we all know and love. An appeal to emotions, once again. Maybe, but it doesn't change the fact that every argument you've made in favor of explicit binary prefixes applies equaly well to explicit decimal prefixes instead. It comes with the added benefit that we'd need to file a lot less bug reports. I was actually kind of playing devil's advocate there, as I was arguing in favor of something I don't support. The part where the appeal to emotions comes in is that I don't expect you to support explicit decimal prefixes even though they are almost strictly better than what you do support. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. So, that is saying it is strictly better to use the explicit binary *and* explicit decimal prefixes. My argument still holds that they are not strictly better because they do have the disadvantage of using an additional character. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 20 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:39:22PM]: On Tue, 19 Jun 2007, Magnus Holmgren wrote: Ivan Jager wrote: They are not strictly better. Did you not read the part where I said I didn't want an extra column of is that serves no real purpose? Don't you read the explanation where people say which purpose it does serve? If you cannot distinguish between a perfect solution and a good partial solution, then you are a real victim of the not a perfect solution fallacy. Uhh, I think you mixed something up in that last sentence. Anyways, just because it solves one problem for some people doesn't make it strictly better. It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. So if you know that there are problems then there is no point in argumenting against the people who want to have them solved. Umm, again I fail to follow your logic. I want to have problems solved, so why are you arguing with me? Your reasoning seems to imply you think there are no problems in the world. You're going to have some trouble convincing me of that. :) Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 19 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]: Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only This rounding is still overhead, so don't say it doesn't. But it doesn't. du does not add filesystem overhead when displaying file sizes. It simply rounds up to the block size. The size it adds on is completely independent of the filesystem overhead. accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) Oh, you cannot say that easily for everyone either. Just compare an FS with big data files with /usr/share/doc contents. Yes, what about it? Are you trying to make a point? Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. Really? You need additional knowledge to interpret the program output and you call this less confusing? I doubt that. Yes. I don't like computers that are designed for people who don't know anything. I find such beasts confusing and obnoxious. Here's a shell for people who don't remember what the output of their commands mean: #!/bin/bash while echo -n '$ '; read cmd line; do man $cmd | cat; eval $cmd $line | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; done Tell me if that isn't obnoxious to use. And you care about waste? You waste every 8 bit right now! Yes, and if people were trying to force me to use UTF-16 so that we could use a different type of whitespace to separate words that what we use to separate sentences, I would also be objecting. I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. But they ARE broken. Have been for years. If you make a simple analogy from that statement to other dings then you need to declare much more people as stupid Don Quixotes, like those who work on LFS (you know, 2GiB is ought to be enough for everyone), or on IPv6, or on Unicode, etc.etc. I seem to be failing to folow your logic again... Anyways, you know we've all switched to IPv6 already, right? We no longer need 6bone because all our ISPs give us IPv6 addresss already. See http://www.6bone.net/ if you don't believe me. Grr. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose Doesn't look so for me. It looks more like a bad attempt to miscredit brave people. Yes, all those brave people who risked their lives to, uhh, very bravely do, uhh, something, umm, what people am I trying to miscredit? I think maybe I need to figure this out before I can figure out what brave things they were doing. Oh, or was I trying to miscredit all brave people? I'm sorry, but I don't think I was trying to miscredit anyone. I simply don't want people fixing a part of my system that works exactly how I want it, just because it is confusing to non computer people. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, Ben Finney wrote: David Verhasselt [EMAIL PROTECTED] writes: Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. A GiB is the same in any locale, and has the same display -- GiB -- in any locale. Displaying it another way is misleading. I like the way ls -lh prints it's output, thankyouverymuch. Adding an extra iB accomplishes nothing for me other than causing more filenames to wrap. I'm not saying GiB is always bad, but just because some standards organization defined a prefix to mean something, doesn't mean the same prefix doesn't also have another meaning. When you see GB, why do you insist that the G must have the SI meaning, when the B clearly doesn't? If I say 1 Ton, do you parse that as meaning 1 * 10^12 on's? :) BTW, I prefer SI units over imperial ones, but there are no SI units for information, so we're stuck using bits and bytes. I also generaly prefer things to be unambiguous when there is no disadvantage, but, fortunately, that is not a problem for me in any of the programs I use. They all use the binary powers. If enough of them started using GiB, and even one of the programs I use regurarly switched to using decimal powers, I would suddenly become mistrustful of a lot of other programs, simply for not wasting an i. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote: On Fri, Jun 15, 2007 at 01:46:10PM -0400, Phillip Susi wrote: Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. Which context would this be? Computer Science? Computer Engineering? Computer Networks? Storage Disks? Magnetic or Optical? File sizes? Memory size? Cache size? Yes. Any time the unit is bytes. There is even a standard for it. I agree that in computer science, many (not necessarily most of) times it would very bad sense to use a power of 10 instead of a power of 2. Like back when they used ten's complement. However, this makes the point stronger, since 10 was a base used with some digital computers. It *was* used. Then people realized base 2 was a lot better for digital computers. Some people living on this continent before us used to use base 20. So this makes the point stronger that if I want change for a $10, you should give me back four $5 bills. :) And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy a disk, what do the vendor says the capacity is? 80 GB. But your software states it is no more than 75GB. What the fuck!? If GiB is confusing to users, so is base 2. People use base 10 and k (kilo) means 1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are used to base 10. How about when you buy 80 GB of RAM, and your software says you have 88 GB? How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. How about using these prefixes to unambiguously refer to powers of 10? kd kidi 10^3 Md meda10^6 Gd gida10^9 Td teda10^12 Pd peda10^15 Ed exda10^18 Zd zeda10^21 Yd yoda10^24 Come on, you know you want a yodameter. :) Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, 14 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: On Wed, 13 Jun 2007, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Rounding can be done after the calculated number is obtained, but it's not inherent in the process of obtaining the number the way that measuring 1 km or 1 tablespoon is. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. Ok, so this applies to dd and what else? I guess fdisk kind of counts, except even there, while being a specified size rather than measured, the size of the partition it creates is still rounded to a whole cylinder. I'm having trouble thinking of anything where a n00b would be specifying sizes with prefixes and expecting it to be exactly a specific size down to the byte. I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Do the GUI equivalents show full precision even with prefixes? That seems kind of pointless. AFAIK we are using precise meanings of the prefixes. They are just ambiguous, since they have more than one precise meaning. On computers, when measuring units of bytes, I am confused any time someone isn't using the binary values. (Although I'm not so surprised when the numbers are coming from marketing people.) While 10^9 2**30, I find the later to be a much more useful number on a computer. A few more things I thought of where a user might need to specify a size: xorg.conf VideoRAM option mem argument on kernel commandline mkfs resize2fs ping All of these except for ping want the byte sizes to be divisible by some power of two. Because memory comes in powers of two, and disks come in multiples of 512 bytes, the powers of two tend to be a lot more useful than the powers of ten. I might be too much of a systems person... Let me know if you can come up with examples where you would want to specify byte sizes in powers of 10 rather than 2. I am now somewhat tempted to do a small survey asking random people how much they think a megabyte is. :) Ivan
Re: Using standardized SI prefixes
On Wed, 13 Jun 2007, Wesley J. Landaker wrote: On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote: On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. I am happy to very brutally assert that the team who didn't use SI was not doing legitimate science or engineering. But whether it's from unskilled employees or bad management, it's quite unfortunate. =( Over here we have two sieres of intro physics courses. One is for science students, and the other is for engineers. Guess what the biggest difference is. Yes, I know it's sad, but apparently engineers need to learn their physics in imperial units... :( Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 13 Jun 2007, Alex Jones wrote: On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. 10% error is no good for me. You can continue to play the at least card, but what about when it's more important if it is at most something? And seeing as this error only goes up exponentially, at which prefix do you draw the line and say no more? And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. But, just because it is approximate, doesn't mean it isn't also ambigouous. :) 1 TB could mean between 5000 and 14999 bytes, between 549755813888 and 1649267441663 bytes, or even between 5000 and 14999.99... bels. :) So, if you want the exact number of bytes, don't round it off, and if you do round it off, don't be surprised if the rounding is ambiguous, because the units are not SI units, and the prefixes may or may not be. Just don't use prefixes when not rounding. I wonder, do people feel as storngly about exactly how many tablespoons 1 TT is? Ivan
Re: More stuff the installer does which isn't done on upgrade
On Mon, 26 Mar 2007, Joey Hess wrote: Nathanael Nerode wrote: [...] On old installs it looks like this: # The first network card - this entry was created during the Debian installation auto eth0 iface eth0 inet dhcp - While on new installs it looks like this: -- # This is a list of hotpluggable network interfaces. # They will be activated automatically by the hotplug subsystem. mapping eth0 script grep map eth0 We haven't used the script grep hack in quite some time, this entire stanza is not present in new installs, though it might be present on some oldish ones. # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp Yes, it writes allow-hotplug instead of auto if the interface seems to be hotpluggable. (Most interfaces appear that way with udev.) An old system that has auto eth0 here will work fine though, unless eth0 is in fact a hotpluggable interface, in which case hotplugging it will not work. Is there a case where hotplugging would have worked in sarge and won't in etch, with the old config? That would be one for the release notes. I did run into a case where it didn't work. When switching from cardctl to hotplug for PCMCIA, hotplug no longer configured the interfaces when I inserted my wireless card. I eventually discovered the allow-hotplug option and all was well. Almost. Another related issue was that I had two interchangeable wireless cards, until the upgrade. After the upgrade they would get different interface names. This was a long time ago, so it may have been fixed by now. IIRC I was going to file a bug report but ran into something saying it wasn't a bug and was documented in the changelog or something. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian in Sanger (Re: update on binary upload restrictions)
On Thu, 1 Feb 2007, Tim Cutts wrote: On 1 Feb 2007, at 1:30 pm, Steffen Moeller wrote: There is probably no point for Debian to compete in the package versions with upstream developers of BioPerl, Wise, EMBOSS and whatever other tools yours and your neighbouring institutes' are providing :o) What I'd actually like is some sort of non-root packaging system so that users could build software with decent dependency checking for their shared software infrastructure. Can dpkg be cajoled into doing that? About a year ago I was playing with getting emerge to do this. I had gotten to the point where I could emerge most of system and a few other things as a normal user on a debian system and have it install stuff in ~/gentoo/. Most of the changes made it into the portage-prefix branch, but last I checked it was still needing a lot of work. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
