Re: regular fsck runs are too disturbing
On Wed, 2007-10-10 at 12:02 +0200, mike corn wrote: > How about running fsck only when the file system was not properly > unmounted the last time it was online? (crash, power fail) > > Assuming the file system is robust and bug-free, this should be > adequate. For this to be true, you need another assumption: All hardware is absolutely reliable which just is not the case. If a bit flip occurs due to bad RAM, a bad IDE cable, chipset problems or whatever, wrong values might be written to disk even with perfectly bug-free software. Such errors often don't have lethal impact from the beginning so that the user might not notice until its already too late. Having a scan from time to time might show up slight file system inconsistencies and raise attention to the user. Hinting a user to make backups after fsck had discovered errors on a regular scan (as opposed to a scan after a crash or power failure) would also be nice. However, I strongly agree that the user should be given the option to abort the scan. This also implies that the user is being informed on the splash screen first and that he knows what is actually about to happen. Just having the progress bar not moving for some time and going to console after the timeout occurs might look quite disturbing for inexperienced users. Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wed, 2007-06-20 at 16:36 -0400, Scott Kitterman wrote: > In order to join ubuntu-qa you have to show experience with bug triaging. So > once again, this is a new barrier to entry for people that want to fix bugs. > Bug triaging and bug fixing are two different things. What you propose is > like a layer violation in protocol design. I'd like to agree with Scott and don't let it look like he is alone with his view. I'm an ubuntu *user* and there have been some small bugs that were -- well -- bugging me. I don't have the overview about how the ubuntu community is organized in detail. Sometimes, I find small bugs which I can fix by myself. This has already happened several times in the past. Having to register for a ubuntu-qa group first would definitely discourage me from using LP because my time is quite limited and I only want a certain bug fixed ASAP without having to be a member of a special group. Actually, the problem is not *being* a member of a group but *becoming* it. Such a user has to find out how things are organized and where he needs to apply first, which he just might not be interested in in the first place. Especially, I don't think that ubunqu-qa would be the right group anyway. I'm not interested in triaging bugs. I just don't have the expertise for this. Remember, I just want to fix a bug here and there which is a personal thing and not related to how important a fix actually is for the average user or "the community". > IMO it's a solution in search of a problem. I have yet to see anyone > set a bug to in progress that wasn't actually working on it. If this is the case, I don't see a need to change that, too. If you want to fix something, you need a problem first. If the fix also imposes additional work (group management) it might be counterproductive. I'm sure I wasn't saying anything that wasn't already said here. However, I felt like having to confirm what Scott was writing about from a "occasional patch writer" perspective. Cheers, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Using standardized SI prefixes
On Thu, 2007-06-14 at 09:05 +1000, James "Doc" Livingston wrote: > On Thu, 2007-06-14 at 00:35 +0200, Christof Krüger wrote: > > I agree that this is the way to go. However, I think the OP wanted to > > suggest to have something like an official policy so that > > changes/patches are also created by ubuntu and eventually proposed > > upstream. > > But I guess there will be no consensus on it so just let upstream do it. > > Good luck convincing every upstream of this. Well, I'm pretty sure that this will not be possible. However, if making big steps is not possible, we need to make a lot of small steps instead. I believe that it is important to point out the advantages so that someone without a strong opinion about it can decide after reading this thread. The point is that the more people use SI prefixes consistently, the more everyone benefits from it. Therefore, every person convinced counts. You don't have to convince all upstream authors to switch over. It will suffice if several popular programs do it right and if authors of new software respect the standard. People will then get used to the funny-sounding kibibytes and eventually consider wonder why there are still programs which use kilo for a quantity of 1024. But I'm getting idealistic now (but then again, doesn't "open source" imply a bit of idealism? Well, i don't want to start a discussion about THAT ;) ) Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 22:29 +0200, Dennis Kaarsemaker wrote: > After wasting too much time reading this thread, I think the bike shed > should be yellow this time. I'd like to have it red, please. > And for something at least slightly useful: > This is not something Ubuntu should do, upstreams should do this. So if > anyone really cares about this, poke our upstreams instead of rambling > on about whether the difference between the different gigglebytes or > tibblebytes is significant. I agree that this is the way to go. However, I think the OP wanted to suggest to have something like an official policy so that changes/patches are also created by ubuntu and eventually proposed upstream. But I guess there will be no consensus on it so just let upstream do it. Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: > [...] > And we still have many figures in both GB and GiB which are neither of > the two! okay ... reading on ... > [...] > I see no problem with this "1TB" quote being approximate. It's > rounded anyway. So you don't care if it is approximate? Then you should care less if it's even exact! However, I find that tebibyte, gibibyte, mebibyte and kibibyte sound quite familiar to their base-10 friends so that it should be no problem even for a dumb user to understand its meaning if he already knew what a gigabyte or megabyte is. This is especially the case with the short notation (e.g. KiB vs. KB). The more important case is when a user actually *cares* about the exact number. At the moment base 10 and base 2 numbers are often prefixed both with k for kilo, M for mega etc. This means that there will be confusion if something is labeled 100GB. Now consider introducing SI prefixes. There still will be confusion with "100GB", because apparently not everyone likes SI prefixes and continues using the "old" prefixes with base 2 numbers. However, when something is labeled "100GiB", there is no confusion (remember that we are talking about a user that cares about the exact number, the dumb user will guess that GiB must be something similar to GB). Okay, so we gained some confidence about what is meant. How can we get rid of the rest of uncertainty? Answer: Use the SI prefixes consistently! This will take a while of course, but eventually you can only benefit. Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Using standardized SI prefixes
> Let me start with a dumb example: > For a child or uninterested commoner that flying critter is simply "a > birdie". For those in the know exactly the same entity is a "Falco > peregrinus". > Even if simply calling it "birdie" or perhaps "falcon" would be > easier, more "user friendly" more "understandable for everyone" it > simply would not be /correct/. The word birdie is a generalization of quite every critter that can fly. So it is correct, the critter "Falco peregrinus" is a birdie, too. Calling this critter "falco peregrinus" is correct, too. The example just doesn't apply here because KB is not a generalization of KiB and vice versa. > > Computers deal with numbers in base two. Humans deal with numbers in > base 10. When computers and humans interact (on a technical level) > humans must adapt to the computer, because computers can not. > Dealing with chunks of data, addresses, registers, etc. has to be done > in base 2. Even if 1024 is "close enough" to 10^3 for a PHB or > marketing humanoid, that will never make those two numbers equal. Right, and this is the reason why having the same name for different things is not good. > And it must never be allowed to. Computers, computer designers, computer > technicians and most computer programmers will always deal with the > _real_ base 2 numbers like 1024. Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. > Another example. Pi is an irrational number starting with 3.14 > Sure, it would be easier to "standardize" it to 3.00. Done deal. It > would be easier to remember and more marketable. It would also be > totally useless AND completely wrong. AFAIK some very dumb people > actually managed to decree by law that pi was to equal 3. They had to > stop doing that. Well, another example that does not apply here. Nobody wants to change something true to something wrong. The status quo is that KB can mean either 1000 or 1024 bytes depending on the context (or shoe size of the developer or whatever). So there is an ambiguity here. Introducing SI prefixes would eliminate ambiguities if applied consistently. Pi is well defined. There is no ambiguity. > Computers > have always, do, and will continue to deal with their numbers along > the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... > So, when dealing with computers, must we. Yup, I totally agree. But why do we call it "kilo" then, when we actually mean 1024? Someone found it handy dozens of years ago and everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. > A well-known and very common trait of language is that one given word > can often have more than one specific meaning. When this is the case > you need a context to be sure. This is considered normal, and never a > real problem. This should hold true regarding computers and counting > as well. This is called a homograph. An example taken from wikipedia: shift n. (a change) shift n. (a period at work) I agree that in "normal life" you can guess the meaning from the context because it has completely different meanings. However, I don't agree that this should hold true in computer science. One possible meaning of KB is "1000 bytes". The other is "1024 bytes". Now take the sentence: "Hello John. I've got a file here and want to send it to you. It's 25KB large." Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. > Finally a personal and subjective thought. At times one has to chose > whether to oversimplify facts and information to the point where > "everyone" understands it, (If this happens they DO NOT understand it; > they are given the illusion of understanding) or whether to educate > the public. I think that you base your argumentation on wrong assumptions. The purpose of introducing SI prefixes is *not* to make the newbie's life simpler, at least not as primary goal. Surely, there are situations where it really doesn't matter (e.g. if you are interested in the order of magnitude 10% error may be totally acceptable). However, SI prefixes
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 15:52 +0100, 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.
>
> Ian.
>
I'd really like to hear some real arguments against SI prefixes, besides
being ugly or funny to pronounce or just because "it has always been
like that". Advantages of using SI prefixes has been mentioned in this
thread. Please tell me the disadvantages so there can actually be a
constructive discussion.
Christof Krüger
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 12:54 -0400, Felipe Sateler wrote: > I fail to see the relationship between "different reference points" > and "screwing the calculation". In this case there was no ambiguity, > engineers knew exactly what to do, but screwed up. Its like saying someone > screwed up converting from Calories to Joules. That doesn't mean Calories > should be eradicated (or viceversa), it just means the person wasn't > careful enough. You're right, the example doesn't fully fit here. However, I found it interesting that there are multiple definitions for "sea level". One of these definitions may seem to be the "default" for people from Germany or Switzerland. The crucial point: If you don't know this ambiguity or simply don't think about it right now, you can screw the calculation. And even if you know it, you can still screw it. This is what the example actually shows but -- you're right -- that does not have to do with the discussion here. I still find it funny, though ;) Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Newest Testing Report of Ubuntu 6.10 from BSTQC China (Jianggw)
On Sun, 2007-04-29 at 21:23 +0530, shirish agarwal wrote: > 2.The format is a .doc format which makes things pretty bulky and > inconsistent. I just cleaned up your 3 MB .doc file & saved it & got > the same file in .odt format for 142 KB. Although it took me atleast 4 > hrs. to do the cleaning up but one good action deserves another. I > have put up the cleaned up file at > http://rapidshare.com/files/28563156/Ubuntu_6.10_defect_report.odt.html. I've uploaded your modified odt-file together with a pdf version to: http://ubuntu.localhost.li/ Bye, Christof -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: too much space around text
Hi, > I am using GNU/Linux for several years now and like it very much. One > issue I always disliked is the extensive space, windows managers require > on the screen to display text. Because of this menus and windows become > too big thus the screen looks crowded and confusing. Well, this is clearly a matter of taste. Having much space around controls does not make the screen crowded at all. Personally, I find too small controls crowded and confusing. > Also I could not manage to customize the space consumption in KDE or > GNOME. Is there any possibility to change this behaviour? If so, why it > is not changed by default?! All this is not just by accident. There a guideline behind this: http://developer.gnome.org/projects/gup/hig/ Typically, multiples of 6 pixels are used for margin and padding. Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Bug 49221] How to solve it, and why I'm not fixing it.
Hi Scott, funny enough, I was looking on the 13_smoother_fading patch today because it didn't work well on my machine (xinerama setup) but it didn't have anything to do with the bug you are referencing. I've uploaded a revised patch on launchpad: https://launchpad.net/ubuntu/+source/gnome-session/+bug/12389 It is based on the upstream implementation but and does not use usleep. It fixes the problems with multi-monitor setups and with the strange colors. It should be faster than the upstream code also, but it would be nice if someone could test it. If the fading is too irregular, calls to usleep could be incorporated just like in the current patch. Regards, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
