=== m_conley_away is now known as m_conley | ||
=== m_conley is now known as m_conley_away | ||
Omega | We get to keep Firefox in Oneiric :) https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-default-browser | 07:00 |
---|---|---|
micahg | Omega: that's the idea :) | 07:02 |
fta2 | this blueprint is b*t | 07:04 |
fta2 | no modern browser has an engine stable for 6 months. | 07:05 |
micahg | fta2: the premise was we don't necessarily need a "modern browser" as the default | 07:06 |
fta2 | if one doesn't get an update in 6 months, it's sure full of vulnerability, no one should ever want to have that installed | 07:06 |
fta2 | -ty+ties | 07:06 |
micahg | fta2: no, the idea was to use webkit which we plan to do stable branch releases for as the backend so security isn't a concern | 07:06 |
fta2 | ok, so it's definitely a good time for me to find another distro then | 07:07 |
micahg | fta2: don't worry, I cancelled the session | 07:07 |
fta2 | "security isn't a concern" is not my definition of a good distro | 07:08 |
micahg | fta2: huh? it's most definitely a concern, I said it wasn't a concern because I'll be backporting security patches from webkit trunk to the stable releases, not that it would be ignored | 07:08 |
micahg | sorry for not being more clear, It's 1 AM here | 07:10 |
fta2 | http://ubuntuforums.org/showthread.php?p=10746888#post10746888 :( | 07:11 |
micahg | fta2: well, we would need to know what toolchain/compile flags google uses to do some type of real world comparison | 07:12 |
micahg | fta2: maybe check with upstream if they have any tricks you can use in your packages | 07:17 |
fta2 | they don't, everything is in the gyp files | 07:18 |
fta2 | but our toolchain sucks more and more release after release | 07:18 |
micahg | fta2: also, is it a specific release that's slower? | 07:18 |
micahg | if we can pinpoint the regressions, we can try to get them fixed | 07:19 |
* micahg is hoping 4.6 to be good | 07:19 | |
micahg | *gcc-4.6 | 07:19 |
micahg | I'm noticing better performance from chromium as the releases progress | 07:19 |
fta2 | why would it? we hardern more and more stuff, making the whole desktop slower | 07:19 |
fta2 | it = gcc 4.6 | 07:20 |
fta2 | natty is way slower than maverick here | 07:20 |
fta2 | itself slower than lucid | 07:20 |
fta2 | etc | 07:20 |
micahg | well, the optimizations the compiler does with each release gets better as well, so hopefully that balances out | 07:20 |
fta2 | obviously not | 07:21 |
micahg | desktop performance is the focus of one of the sessions at UDS | 07:21 |
micahg | phoronix also posted some stats on speed regressions, I think this will be a focus for oneiric and the LTS | 07:22 |
micahg | fta2: if you find we need something to make chromium faster, let me know and I"ll see what I can do | 07:23 |
fta2 | it's easy to test. grab the same version built with different toolchains and test. the 4 ppas are good candidates. exact same packaging | 07:25 |
chrisccoulson | fta2 - regarding the default-browser blueprint, see my responses to the discussion on the ubuntu-desktop list ;) | 07:28 |
chrisccoulson | micahg - have you tried dissecting the chrome binary btw (with objdump and readelf). you might be able to have a guess at some of the major compiler and link flags from doing that | 07:29 |
micahg | chrisccoulson: nope | 07:30 |
chrisccoulson | is chromium built with -pie? | 07:31 |
* micahg forgot if we reenabled, checking | 07:32 | |
chrisccoulson | i'm guessing chromium is pie, and chrome isn't | 07:33 |
chrisccoulson | woah | 07:34 |
chrisccoulson | chrome: Relocation section '.rela.dyn' at offset 0x2f680 contains 318 entries: | 07:34 |
chrisccoulson | chromium: Relocation section '.rela.dyn' at offset 0x1db60 contains 214625 entries: | 07:34 |
micahg | yep, with -pie | 07:34 |
chrisccoulson | there is something fundamentally different with how we build chromium. | 07:34 |
micahg | except on ARM I think | 07:34 |
chrisccoulson | yeah, pie is a big killer there | 07:34 |
chrisccoulson | the difference in the amount of relocations is pretty awful | 07:35 |
chrisccoulson | that's not just a minor toolchain quirk ;) | 07:35 |
micahg | well, unless we can make PIE more efficient, there's not much we can do about that | 07:35 |
chrisccoulson | there isn't a way to make PIE efficient. it's a performance killer by design | 07:35 |
chrisccoulson | every access to a global variable goes via the GOT | 07:36 |
chrisccoulson | and every function call via the PLT | 07:36 |
chrisccoulson | which is pretty wasteful | 07:36 |
chrisccoulson | comparing the binaries could turn in to an interesting little experiment | 07:37 |
micahg | chrisccoulson: well, the tradeoff would be to link to more libs instead of having one huge binary, another speed killer | 07:38 |
chrisccoulson | well, one huge binary is actually a performance benefit when you're not using -pie | 07:41 |
chrisccoulson | with -pie, it doesn't make much difference | 07:41 |
chrisccoulson | this is why mozilla ships fennec as one big binary on android :) | 07:41 |
chrisccoulson | when you're linking against external libs, the number of relocations the linker needs to do increases, and that isn't cheap | 07:42 |
chrisccoulson | but in the -pie case, that doesn't really matter, because you already do all those relocations | 07:42 |
chrisccoulson | i'd be interested to see a chromium build without -pie, just to see the difference :) | 07:44 |
micahg | chrisccoulson: I can kick one off locally tomorrow, I need to finish thunderbird now | 07:45 |
chrisccoulson | that's ok, i can do it here later | 07:45 |
chrisccoulson | we also use BIND_NOW in ubuntu, which is a startup time killer | 07:46 |
chrisccoulson | especially with apps that have a lot of relocations (like firefox and chromium) :) | 07:46 |
chrisccoulson | which is probably one reason why upstream mozilla builds start significantly faster than our builds ;) | 07:47 |
micahg | chrisccoulson: could we build with static libs and optimize at build time so it can all be loaded quickly (PGO?) | 07:50 |
chrisccoulson | it's not going to make much of a difference with -pie ;) | 07:50 |
chrisccoulson | and PGO doesn't really improve loading speed | 07:50 |
micahg | chrisccoulson: would help with start time though, wouldn't it? | 07:50 |
chrisccoulson | well, when I tried PGO here, it didn't really change startup time | 07:51 |
micahg | hmm, that could be because we have PIE enabled w/dynamic libs + BIND_NOW like you said | 07:51 |
fta2 | chrisccoulson, i tried ff4 on android, it's way slower than the stock browser. start time is at least 10 times slower on my tablet | 08:06 |
fta2 | chrisccoulson, and btw, i really don't think pie does any good to chromium. there's already the sandbox | 08:10 |
fta2 | btw, i do a static build, like upstream, hence the huge binary | 08:11 |
fta2 | the only difference is PIE, maybe ld-gold (not sure) | 08:11 |
fta2 | and of course, they use an older toolchain (used to be hardy) | 08:12 |
=== yofel_ is now known as yofel | ||
chrisccoulson | fta2 - yeah, ff4 on android isn't fast | 08:22 |
xjjk | hello, somewhat OT | 09:26 |
xjjk | is there a PPA containing only Firefox Aurora builds? | 09:26 |
xjjk | instead of nightlies | 09:26 |
chrisccoulson | xjjk, no. in any case, they're pretty much nightly anyway, aren't they? | 09:58 |
chrisccoulson | chromium (no -pie) - Relocation section '.rela.dyn' at offset 0x1d0c0 contains 412 entries (versus 214625 for -pie) | 10:44 |
chrisccoulson | ouch ;) | 10:45 |
chrisccoulson | bug 776355 - wtf? | 14:10 |
ubot2 | Launchpad bug 776355 in firefox "commercial image in background of firefox 3.6.17" [Undecided,New] https://launchpad.net/bugs/776355 | 14:11 |
=== m_conley_away is now known as m_conley | ||
chrisccoulson | ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh | 15:57 |
chrisccoulson | asac - the patch we carry for mozilla bug 467766 is causing mozilla bug 654099 :( | 15:58 |
ubot2 | Mozilla bug 467766 in Preferences: Backend "user settings for pref keys with defaults in extension get reset on upgrade" [Normal,Assigned: ] http://bugzilla.mozilla.org/show_bug.cgi?id=467766 | 15:58 |
ubot2 | Mozilla bug 654099 in Firefox Sync: Backend "intl.accept_languages is being set to non-localized value chrome://global/locale/intl.properties" [Normal,New: ] http://bugzilla.mozilla.org/show_bug.cgi?id=654099 | 15:58 |
xjjk | chrisccoulson: I didn't think so? thought they were better-tested nightlies | 16:50 |
micahg | chrisccoulson: I thought that first one was mostly fixed for 4.0, maybe we can just drop it? | 17:09 |
chrisccoulson | micahg - i'm not sure, i don't think anything has changed there | 17:10 |
micahg | chrisccoulson: re commercial image bug> I asked for a screenshot | 17:10 |
micahg | chrisccoulson: I remember having to fuzz that patch at one point, also, when you did the 4.0 upgrade, you fuzzed it as well | 17:11 |
micahg | so, the logic changed a bit, but idk if it was actually fixed | 17:12 |
chrisccoulson | no, i doubt it's fixed it, as it's a fundamental issue with the way it works (and a long term fix would probably go elsewhere too) | 17:15 |
jcastro | fta: ok so that download progress thing looks niiiiiiiiiice. | 17:32 |
jcastro | chrisccoulson: you're behind now! | 17:32 |
chrisccoulson | jcastro - http://people.canonical.com/~chrisccoulson/unityfox.png ? | 17:32 |
chrisccoulson | and see my post to the ayatana list too ;) | 17:33 |
jcastro | yeah! | 17:33 |
=== m_conley is now known as m_conley_away | ||
fta | jcastro, indeed | 17:34 |
chrisccoulson | jcastro, https://lists.launchpad.net/ayatana/msg05617.html | 17:39 |
chrisccoulson | basically, i need some design input really ;) | 17:39 |
jcastro | yeah | 17:40 |
chrisccoulson | and mpt suggested last week that the way we indicate progress on the launcher could be improved | 17:40 |
jcastro | I think 2 is correct, download only | 17:40 |
jcastro | and for 3, just wiggle at the end | 17:40 |
jcastro | that makes the icon shake out a bit to indicate that you're done and turns the home button blue | 17:40 |
chrisccoulson | yeah, i agree. i'm just not sure it's clear what the progressbar represents from a browser :) | 17:40 |
jcastro | yeah | 17:41 |
fta | jcastro, did you have a chance to check my bug from yesterday? | 17:43 |
jcastro | I have not | 17:46 |
jcastro | I have been slammed with UDS planning | 17:46 |
jcastro | I haven't even been able to check the appmenu bug with trevino | 17:46 |
=== m_conley_away is now known as m_conley | ||
fta | ok | 18:22 |
micahg | chrisccoulson: about the mozilla patches, I was originally thinking about dropping the prefs patch, but is that a valid tradeoff to drop prefs in favor of have the default language correct? | 18:29 |
chrisccoulson | micahg - yeah. the prefs issues is an edge-case | 18:29 |
chrisccoulson | the language issue makes it pretty much unusable, and for no obvious reason :/ | 18:29 |
micahg | chrisccoulson: k, go ahead and drop it then | 18:30 |
chrisccoulson | it happened to me too, and all google sites become unusable (i can't understand cherokee) | 18:30 |
micahg | chrisccoulson: since it's not a regression over release, I can't push through -security, but we could SRU it | 18:30 |
chrisccoulson | and you need to be about to understand cherokee to change your language back to english in google ;) | 18:30 |
micahg | chrisccoulson: there's a link to use google in english ;) | 18:30 |
chrisccoulson | micahg, that's ok, i've got another change to do a SRU for too | 18:30 |
chrisccoulson | micahg, is there? i didn't notice that | 18:31 |
chrisccoulson | all i got was an unusable page :) | 18:31 |
chrisccoulson | micahg - we can try to figure out a better way to fix it, but it would likely involve a more intrusive patch | 18:32 |
micahg | chrisccoulson: I'll add a google search page to QRT so we can catch it in the future | 18:32 |
chrisccoulson | in any case, the current patch breaks a public mozilla API, so we really shouldn't have it in the first place ;) | 18:32 |
chrisccoulson | micahg, https://launchpadlibrarian.net/69336194/googlehome.png ;) | 18:33 |
chrisccoulson | actually, this one is more valid: https://launchpadlibrarian.net/69336109/searchresult.png | 18:33 |
chrisccoulson | the first screenshot is just someone manually using cherokee | 18:33 |
chrisccoulson | the second one is a result of the bug | 18:33 |
micahg | weird, I got a link for english on mine | 18:34 |
chrisccoulson | 1 second, i will try and see if i can get google to automatically pick the wrong language again | 18:35 |
chrisccoulson | micahg, hmm, there's no link to use english here :/ | 18:36 |
micahg | chrisccoulson: k | 18:36 |
chrisccoulson | so, i definitely think we should regress the other bug to fix this one | 18:37 |
chrisccoulson | it sucks, but i think this one is worse | 18:37 |
micahg | chrisccoulson: it would be nice if we have a better fix before we push to lucid/maverick | 18:43 |
Omega | chrisccoulson: Do you want me to ask the firefox ux people what they think of unityfox? | 19:09 |
chrisccoulson | Omega, do you know them? | 19:10 |
Omega | yes | 19:10 |
chrisccoulson | well, i'd certainly like to know what their thoughts are for download progress indication in general | 19:10 |
chrisccoulson | i don't like the current download progress window ;) | 19:10 |
chrisccoulson | but i don't think integrating it with the unity launcher is a substitute for that | 19:11 |
chrisccoulson | which is why i'm stuck ;) | 19:11 |
Omega | Alright, I'll mention it on IRC, if it sparks some interest I'll post it on the mailing list :) | 19:11 |
chrisccoulson | thanks | 19:11 |
fta | http://www.netmarketshare.com/browser-market-share.aspx?qprid=1 | 19:18 |
Omega | chrisccoulson: Do separate firefox windows use separate download lists? | 19:18 |
chrisccoulson | Omega, no | 19:19 |
kbrosnan | on non-untiy firefox, no | 19:19 |
Omega | chrisccoulson: What is the multiple firefox problem? | 19:21 |
Omega | (Err, I mean, I don't see how having multiple instances of firefox open complicates the matter) | 19:22 |
chrisccoulson | Omega, in unity, all firefox windows are represented by a single icon on the launcher | 19:22 |
chrisccoulson | the multiple windows case is not a problem, as there is only one process talking to the launcher | 19:23 |
chrisccoulson | but, if you run multiple instances of firefox, then you can have several processes all trying to control progress indicators on the launcher | 19:23 |
chrisccoulson | i guess that's a design flaw in unity though ;) | 19:23 |
chrisccoulson | niiiiice, i just tried the chromium implementation too :) | 19:26 |
Omega | chrisccoulson: Ah, yes, that does seem like a design flaw. | 19:29 |
Omega | You should raise that issue on the mailing list. | 19:29 |
chrisccoulson | Omega, which mailing list? | 19:31 |
chrisccoulson | i'll probably just grab the guy working on launcher design at UDS :) | 19:31 |
Omega | ayatana would probably be the most appropriate | 19:32 |
Omega | Because it needs design thought. | 19:32 |
Omega | They can take it into different directions, maybe spawning more icons when different processes want to use the launcher, or having multiple progress indications | 19:33 |
Omega | chrisccoulson: Are you at UDS? | 19:38 |
chrisccoulson | Omega, i will be, from sunday night | 19:38 |
Omega | Fun :) | 19:41 |
chrisccoulson | yeah, i'm looking forward to it ;) | 19:43 |
chrisccoulson | although, it's always a busy week | 19:44 |
chrisccoulson | and we've got lots of things to figure out, like, how we support firefox in the distro ;) | 19:44 |
m_conley | chrisccoulson: i've been thinking about that - the behaviour should be the same as Chromium, no? | 19:49 |
chrisccoulson | m_conley, in general, or just for the launcher bits? | 19:49 |
m_conley | chrisccoulson: hm - maybe I didn't read enough scrollback. I just assumed you were talking about how you were going to deal with the new release cycle | 19:50 |
m_conley | chrisccoulson: if that's not the case, ignore me. ;) | 19:50 |
chrisccoulson | m_conley, oh, i misunderstood entirely there | 19:50 |
chrisccoulson | different conversation ;) | 19:50 |
chrisccoulson | lol | 19:50 |
chrisccoulson | yes, it should be mostly the same i guess | 19:50 |
chrisccoulson | m_conley, our main bottleneck is going to be because of how we distribute translations | 19:52 |
chrisccoulson | because we bundle them with our language packs, which are built using an export from launchpad | 19:52 |
m_conley | I see (I think) | 19:52 |
chrisccoulson | and we don't want the security team being stuck testing 10s of new language packs for 100s of applications every few weeks ;) | 19:53 |
chrisccoulson | and i still have no idea how long firefox 4 is going to be supported :/ | 19:54 |
chrisccoulson | i'd like to upgrade all our users to it, but i don't want to do it before i know we're fully prepared for dealing with faster releases | 19:54 |
* m_conley nods | 19:54 | |
chrisccoulson | but if firefox 4 is supported for another 6 months or so, then that gives us plenty of time | 19:55 |
chrisccoulson | if it's only until firefox 5 is released, then we'd be screwed ;) | 19:55 |
m_conley | chrisccoulson: just checked - it's 6 months after FF5 is released. Minimum. | 19:56 |
micahg | m_conley: is that info public somewhere, I've trying to find timetables for weeks | 19:57 |
m_conley | micahg: I literally just walked over to some Firefox people and asked. I have no idea if it's on a wiki anywhere. It probably should be. :/ | 19:57 |
* micahg feels bad dropping conkeror now :( | 19:58 | |
chrisccoulson | micahg, i wouldn't worry. we'd kill it anyway ;) | 19:58 |
chrisccoulson | we shouldn't be spending time on things like that really | 19:58 |
micahg | well, I'd like to see if we come up with a xul plan at UDS or not | 19:59 |
chrisccoulson | drop it and stick it in a PPA ;) | 19:59 |
chrisccoulson | tbh, there's not much left in the archive using it now | 19:59 |
chrisccoulson | http://paste.ubuntu.com/602927/ | 20:01 |
chrisccoulson | and conkeror is already gone | 20:01 |
chrisccoulson | python-gtkmozembed is going anyway | 20:01 |
chrisccoulson | chmsee has a patch for a webkit port somewhere. it needs it anyway, as it uses gtkmozembed | 20:02 |
chrisccoulson | google-gadgets has gone already | 20:02 |
micahg | fennec will move to internal xul I think | 20:02 |
chrisccoulson | why are these all still in my apt cache? | 20:02 |
chrisccoulson | these went weeks ago :) | 20:02 |
chrisccoulson | dehydra only uses spidermonkey | 20:02 |
micahg | chrisccoulson: I still have a few universe packages to port to mozjs | 20:03 |
chrisccoulson | that only really leaves instantbird, mozplugger and xiphos | 20:03 |
* micahg thought xiphos was being ported to webkit | 20:04 | |
chrisccoulson | i'm not sure | 20:04 |
chrisccoulson | that's not the sort of application i use regularly ;) | 20:05 |
micahg | I'll talk to the instantbird devs, might want to switch that to internal xul as well | 20:05 |
micahg | or kill | 20:05 |
chrisccoulson | yeah, i'm not too fussed about that | 20:05 |
chrisccoulson_ | ok, firefox uploaded to natty-proposed | 20:48 |
BUGabundo | evening | 20:50 |
micahg | chrisccoulson_: heh, that's not something we do often :) | 20:54 |
=== m_conley is now known as m_conley_away | ||
Omega | chrisccoulson_: They say it covers the most iconic part of the logo. | 22:34 |
Omega | chrisccoulson_: this is what she said: | 22:36 |
Omega | <@Boriss> Tim: it and the notification number cover the most iconic parts of the logo, | 22:36 |
Omega | <@Boriss> as a simple progress indicator it's not bad. i'd just change it if i were designing it with only firefox logo in mind :) | 22:36 |
Omega | chrisccoulson_: maybe this is a good thing to mention to mpt, a possible alternative would be to place the progress bar on top of the icon (kind of like how firefox indicates page load progress) | 22:37 |
ripps | huh... chromium from the dev ppa keeps freezing 10 seconds after it starts. I even tried starting it in incognito in case an extension was causing it, but no difference. | 23:56 |
ripps | it's barely using any cpu too, it just stops doing anything | 23:57 |
ripps | I have to kill it using xkill | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!