| === psharmor is now known as tekoholic | ||
| jml | compiz is chewing up a lot of CPU | 09:48 |
|---|---|---|
| jml | should I file a bug about this? (precise) | 09:48 |
| dbarth | jml: yes please | 10:38 |
| dbarth | jml: it's weird because i don't think there was a new version released | 10:39 |
| dbarth | jml: so that must be external causes | 10:39 |
| jml | dbarth: ok. will do. | 10:40 |
| dbarth | jml: just let me know of the bug number or subscribe me | 10:41 |
| jml | dbarth: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/906816 | 10:46 |
| ubot2 | Launchpad bug 906816 in compiz "compiz always using significant chunk of CPU" [Undecided,New] | 10:46 |
| dbarth | jml: thanks | 12:09 |
| * rodrigo_ lunch | 13:19 | |
| === davidcalle_ is now known as davidcalle | ||
| Riddell | is there a meeting today? | 13:49 |
| pitti | Riddell: don't think so; half of the team or more is on vac already | 13:52 |
| dobey | pitti: uh, firefox/etc are really reporting bytes transfered as base 10 rather than base 8? | 14:02 |
| pitti | dobey: nautilus/gvfs etc. is; I'm not entirely sure of firefox | 14:02 |
| dobey | that is not very nice | 14:03 |
| pitti | I think firefox still gets it wrong, too | 14:04 |
| dobey | base 10 is wrong :) | 14:04 |
| pitti | no, it's not | 14:04 |
| dobey | it is when you are transferring in blocks of base 8 | 14:05 |
| pitti | unless you only have two fingers | 14:05 |
| pitti | but we don't | 14:05 |
| pitti | or if we do, it's absolutely uninteresting for a human-readable size | 14:05 |
| pitti | but anyway, we've been through this, and https://wiki.ubuntu.com/UnitsPolicy is the result now | 14:06 |
| * ogra_ grumbles about ubuntu-docs taking over 30min to unpack in precise ... that was only 15min in oneiric, did it really grow so much or are we using some insane compression mechanism now ? | 14:06 | |
| pitti | dobey: anyway, even if you want base-2, then format_size_for_display is still wrong | 14:07 |
| * ogra_ expects the same issue for gnome-user-docs ... | 14:07 | |
| pitti | dobey: as it doesn't use the correct units then, like MiB/GiB | 14:07 |
| dobey | pitti: i didn't say format_size_for_dispay was right | 14:08 |
| dobey | but it's all there is in glib < 2.30 | 14:08 |
| pitti | dobey: but as format_size_for_dispay was essentially unfixable, they deprecated it | 14:08 |
| pitti | dobey: right, for older releases we just have to live with it | 14:08 |
| pitti | dobey: but I sent an updated MP which now gets along with both | 14:09 |
| pitti | it gives the correct output for >= 2.30, and remains unchanged for < 2.30 | 14:09 |
| pitti | which is pretty much what we want for SRUs, etc. | 14:09 |
| dobey | what i'm saying, is the policy seems to be broken | 14:09 |
| dobey | pretty much *everything* reads/writes data in 4096 byte blocks, not 1000 bit blocks | 14:10 |
| pitti | how is that relevant? | 14:10 |
| pitti | it doesn't matter if your read/write block size is 1024 or 1234567 | 14:11 |
| pitti | what you display are either file sizes or transfer rates | 14:11 |
| dobey | because it's readying bytes, not bits | 14:11 |
| dobey | reading, not readying | 14:11 |
| pitti | ok, I'm afraid I don't follow | 14:11 |
| pitti | which part of the policy do you think is broken? | 14:11 |
| pitti | (or the g_format_size() implementation for that matter?) | 14:12 |
| dobey | the g_format_size implementation is fine; it just calls g_format_size_full () with the default of using 1000 instead of 1024, and _full lets you use 1024. i think defaulting to 1000 is a bad idea, vs requiring developer to make a conscious choice, but whatever, i don't care to argue that | 14:13 |
| pitti | well, that was made because in all except rare circumstances 1000 is the right default now | 14:14 |
| dobey | and i fundamentally disagree with perpetuating the lies of an entire industry, but whatever. ex post facto standards are complete bollocks, if you ask me. :) | 14:15 |
| kenvandine | oh interesting, i didn't know about the UnitsPolicy page... i've wondered about that a couple times in the past | 14:15 |
| dobey | i think the network bandwidth thing is wrong, though | 14:15 |
| pitti | well, it's not ex post fact | 14:17 |
| pitti | humans have counted in base-10 (well, some in base-60) for centuries | 14:17 |
| pitti | just some nerds a couple of decades ago thought it was a good idea to confuse people with a Mega-something which is not actually what Mega- means | 14:18 |
| kenvandine | it makes sense, normal humans prefer easy number | 14:18 |
| kenvandine | +s | 14:18 |
| pitti | someone just abused the SI prefixes to mean something different | 14:18 |
| pitti | _that_ was the confusion, not switching back to real base-10 prefixes | 14:18 |
| dobey | pitti: computers have never counted in base 10 | 14:18 |
| pitti | why should users care? | 14:19 |
| kenvandine | dobey, computers != humans | 14:19 |
| dobey | the IEC standard didn't exist until 1998 | 14:19 |
| dobey | and hard disk manufacturers had been cheating since way before then | 14:19 |
| kenvandine | we're talking about representing the information to humans not computers | 14:19 |
| * kenvandine stops feeding the dobey :) | 14:20 | |
| pitti | dobey: why cheating? | 14:20 |
| pitti | dobey: 100 MB == 100.0000.000 Bytes | 14:20 |
| dobey | humans don't care. they just want the computer to match what the box says. | 14:20 |
| dobey | when they see certain things | 14:20 |
| pitti | (scratch that extra 0, YKWIM) | 14:20 |
| dobey | there is no box label for how many bytes your computer transferred across the network | 14:20 |
| pitti | what I do agree to is that using the base-2 prefixes is confusing | 14:21 |
| pitti | like, 100 MiB for file sizes, etc. | 14:21 |
| pitti | since users do not know what these really are either | 14:21 |
| pitti | we still need them for total mem size | 14:21 |
| dobey | the XiB crap is annoying because of the i | 14:22 |
| pitti | that's why we shouldn't use it for most things :) | 14:22 |
| dobey | people making stupid naming choices in a standard is no excuse for avoiding base 2 | 14:23 |
| dobey | "we'll just make stupid names for things, so nobody will use them!" | 14:23 |
| * pitti stops any hope of getting dobey out of his geek unit world, and just STFU :) | 14:23 | |
| kenvandine | pitti, it is hard not to feed the dobey :) | 14:24 |
| pitti | dobey: if you had written the standard, which prefixes would you have chosen, OOI? | 14:24 |
| dobey | drwxr-xr-x 2 dobey dobey 4096 2011-05-06 16:19 我的光碟/ | 14:25 |
| dobey | drwxr-xr-x 2 dobey dobey 4.0K 2011-05-06 16:19 我的光碟/ | 14:25 |
| dobey | :) | 14:25 |
| dobey | pitti: i wouldn't pick names that sounded like they came from care bears, at least | 14:25 |
| pitti | but that's a lie :) | 14:25 |
| pitti | it's 4.096 K | 14:26 |
| dobey | pitti: so do you have a patch for ls? | 14:26 |
| pitti | https://wiki.ubuntu.com/UnitsPolicy#Exception | 14:26 |
| pitti | dobey: --si | 14:26 |
| pitti | dobey: http://xkcd.com/394/ is an even clearer standard :) | 14:33 |
| ricotz | jbicha, hi | 16:09 |
| ricotz | jbicha, good catch and interesting patch in gnome-themes-standard for nautilus, but i think something like this would be better http://paste.debian.net/plain/149749 | 16:11 |
| jbicha | ricotz: oh, would that work too? | 16:12 |
| jbicha | I don't actually understand theming | 16:12 |
| ricotz | jbicha, this is hard to notice, but it only draws this dark line? | 16:13 |
| ricotz | and this smaller change does the same, and wouldnt break nautilus 3.3 | 16:13 |
| jbicha | ricotz: yeah, it would be better to work with both nautilus 3.2 and 3.3 | 16:15 |
| ricotz | as long nautilus 3.2 doesnt use GtkGrid it doesnt interfere with the newer style definitions | 16:15 |
| ricotz | jbicha, please change it then | 16:16 |
| jbicha | ricotz: yes, doing it now :) | 16:16 |
| ricotz | thanks | 16:16 |
| ricotz | jbicha, you messed the patch up :( | 16:35 |
| ricotz | jbicha, please look at the paste again | 16:35 |
| ricotz | do it exactly that way | 16:35 |
| jbicha | ricotz: sorry, I'll just copy and paste then | 16:46 |
| === cking_ is now known as cking | ||
| === charles_ is now known as charles | ||
| ricotz | jbicha, me again ;), the break against fglrx in g-s arent compatible with ubuntu | 17:23 |
| ricotz | i think it should be something like "fglrx (<< 2:8.910)" | 17:24 |
| jbicha | ricotz: maybe we could just leave that line out since I hear that the latest fglrx still doesn't work right for everyone w/ gshell | 17:33 |
| jbicha | ricotz: also you should join the desktop team | 17:37 |
| ricotz | jbicha, yes, dropping the line would be the best | 17:39 |
| jbicha | actually, fglrx-driver isn't in Ubuntu at all, so I don't think the breaks hurts anything to be left in | 17:42 |
| ricotz | indeed ;) | 17:43 |
| ricotz | jbicha, on the other hand i was thinking fglrx 2:8.911 fixed some things | 17:48 |
| pitti | cyphermox: did you sync libnl3? | 18:00 |
| pitti | ah, there's a MIR already for xmlstarlet, nevermind | 18:00 |
| jbicha | ricotz: I was thinking of 8.881 which still had problems but I don't run ATI so I don't know if the problems are fixed now or not | 18:08 |
| cyphermox | pitti: yeah | 18:08 |
| cyphermox | I just did the MIR too, I had forgotten all about hte new xmlstarlet requirement | 18:08 |
| ricotz | jbicha, ok, i thought i read some good news about the newer driver | 18:17 |
| pitti | happy holidays everyone! I'll stop IRC now, please mail me if you need me to do something over the holidays (no response time guarantee, though) | 18:36 |
| broder | where's the best place to send feedback on dx's multi-display spec? ayatana@lists.lp? | 18:42 |
| mterry | chrisccoulson, hey, congrats! | 19:21 |
| alex_mayorga | Hello! Can someone here help me get rid of bug 907012 | 21:47 |
| ubot2 | Launchpad bug 907012 in indicator-datetime "indicator-datetime uses 80% of RAM or 3.1g" [Undecided,Confirmed] https://launchpad.net/bugs/907012 | 21:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!