[00:25] mdeslaur: I've used another approach here https://code.launchpad.net/~3v1n0/unity/lockscreen-keys-disable/+merge/217528 [00:34] Trevinho: that looks to me like it modifies some of the code you added recently to ensure it re-starts locked if it dies while locked -- does it still lock in that case? [00:34] sarnold: sure [00:35] sarnold: it just gets called in another cb function [00:35] sarnold: I could keep the old one, but duplicating the callbacks wasn't the nicest thing [00:35] Trevinho: excellent :) thanks for reassuring me :) [00:35] looks good, and is way better then my branch [00:35] * bschaefer goes to reject his [01:13] Trevinho: thanks! [01:28] mdeslaur: if there are not other issues, I'm going to bed... That branch should be enough [04:04] morning [08:03] hey! [08:11] good morning desktopers [08:14] lut seb128 [08:14] Laney, howdy, how are you? [08:15] * seb128 shakes fist at xnox [08:15] very good thanks! and you? [08:15] xnox, could you please stop uploading without considering the packaging vcs-es? [08:15] Laney, I'm good thanks ;-) [08:16] naughty xnox [08:16] especially that in this case he stepped over a version already used for a SRU [08:16] which made the SRU be rejected after a week of waiting in the queue [08:16] *great* [08:23] so touch can corrupt xorg-server :P [08:23] anyone here with a touchscreen and some interest in valgrind? [08:24] well, no special "interest" but I can probably help getting debug info [08:28] yeah just spawning xorg-server + a unity session and reproducing bug 1311828 and bug 1298727 is enough. [08:28] Launchpad bug 1311828 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT" [Medium,New] https://launchpad.net/bugs/1311828 [08:28] Launchpad bug 1298727 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in point_on_screen()" [Medium,Incomplete] https://launchpad.net/bugs/1298727 [08:28] something like "/usr/bin/valgrind --keep-stacktraces=alloc-and-free --show-reachable=yes --track-fds=yes --leak-check=full --error-limit=no --freelist-vol=50000000 --freelist-big-blocks=10000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -core -verbose 10" [08:29] and install xserver.*dbg$ [08:35] k, I'm trying to do that in a bit, need to update my test config first, install valgrind, dbgs, etc and see if I can reproduce the bug [08:35] where do you put that command? do you replace the X binary by that or..? [08:36] that's one way to do it :P [08:36] I created an /etc/X11/X2 shellscript, and symlinked /etc/X11/X to it (that file must be a symlink or X won't start) [08:37] http://paste.debian.net/96346/ my /etc/X22/X2 [08:38] thanks [08:38] x22! [08:38] oops :P [08:40] oh and probably the dbg files for libdrm.*dbg$ and libpixman.*dbg$ [08:46] seb128: argh, sorry. which package did i step over like that? [08:46] xnox, empathy [08:47] seb128: well, use SRU version numbers for SRUs? =))))) [08:48] xnox, what is a SRU version? [08:48] 3.8.6-0ubuntu9.1 [08:49] as per SRU docs... [08:51] xnox, that wouldn't have changed the fact that the vcs had work to be uploaded that should have been included in that upload, instead of doing a no change upload [08:51] yeah, sorry. [08:52] no worry, please be careful with desktop packages next time though, most have packaging vcs-es [08:52] some are out of date, some are not. [08:53] i want a way to do version numbers for rebuilds that are not reusing any other upload numbers ideally. to avoid contention. [09:09] seb128, hi [09:09] just a short question ;) [09:09] will utopic target gnome 3.12 or are you going straight for 3.13/14? [09:09] lol [09:09] ricotz, hey [09:10] i guess the conservative approach turned out fine for you [09:10] ricotz, we plan to discuss the topic during the meeting later today, but I can tell you for sure not going to 3.13 [09:10] I would rather ponder the "stay on 3.10" [09:10] but realistically I think we are going to end up doing 3.12 [09:10] alright ;) [09:11] and yes, the "stay on stable" serves us pretty well [09:11] 3.12 sounds fine since there are a lot synced already too [09:11] we didn't have too much fire fighting since we do that and quality went up [09:12] right ;) [09:12] well, 3.12 synced, so things depwait on a newer gtk? [09:12] I don't see gtk 3.12 being done/ready before some time [09:12] no, just some minor components which doesnt require gtk 3.12 [09:12] k, that's fine then [09:13] gtk 3.12 is in gnome3-staging so testing it is possible [09:13] is that a proper update? [09:13] with patches? [09:13] yes [09:13] or another of those updates dropping the patches that were too difficult to port? [09:14] please just give it a short look and judge about it [09:15] thanks, bbl [09:16] is there any known issue with themes or overlay scrollbar? [09:16] does seem to have all the patches, only change is git backports [09:16] yeah [09:16] I just compared the series [09:17] and the other ones didn't require much updating ... [09:17] what is this wizardry [09:17] larsu, ^ maybe you want to have a look/try gtk 3.12 from https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages?field.name_filter=gtk%2B3 ? [09:17] is this like bearing the fruits of upstreaming stuff or something :P [09:18] there must be some runtime issues with overlay-scrollbar or something [09:20] one gotcha is going to be the text-wrapping/dialogs I think [09:20] but we can distro patch that out before release if needed [09:20] yep, debian will probably do that too [09:21] looking to the NEWS entries, that seems not a crazy cycle [09:21] that's good news [09:22] I'm going to try it before the meeting today [09:31] somebody has been browsing e.u.c for lightdm issue and clicking the "create" button [09:34] * mlankhorst pokes seb128 [09:34] yes? [09:35] I'm starting the test box for your issue [09:35] sorry, got busy until now with other things [09:46] k [09:46] np :) === davidcalle_ is now known as davidcalle [09:49] hey seb128, Laney [09:49] hey darkxst [09:53] seb128, really? staying on 3.10? as if that well happen ;) [09:54] easiest way to avoid gtkheaderbars... [09:55] ricotz: where do you keep the packaging branch for gtk? [09:55] seb128, did the entire conversation last night, just fly past you? [09:55] larsu, we don't have any packaging branches currently, going to look at setting that up this cycle [09:55] darkxst: ah okay, thanks [09:56] darkxst, which one? [09:56] on how to handle gtkheaderbars? [09:56] seb128, yes, gtkheaderbars! [09:56] or on the conflict of interest between flavors? [09:57] but, no, none did fly past no [09:57] seb128, and ignoring the WN hints to get back titlebars [09:57] WM even [09:57] I'm still not convinced we can make gtkheaderbar a non-regression for !gnome-shell users [09:57] I'm not convinced that wm bar + headerbar without control is not a regression in UI over what we have [09:58] I need to test on real cases to see how it looks/feel [09:58] seb128, without window controls and with titlebars its not much difference to what in archives currently [09:58] like there is no title in the headerbar? [09:59] seb128, huh? you guys would have a titlebar with a *title*! [09:59] seb128: I want to talk about this at the hackfest tomorrow [09:59] there are two approaches for us [09:59] (1) go csd, but with our theme [09:59] (2) make headerbars into primary toolbars by adding a titlebar [10:00] larsu, upstream won't take 2, so that would have to be a distro patch [10:00] what do you mean with (2)? [10:00] the title issue is [10:00] what happens to http://curiousdtu.files.wordpress.com/2014/02/gedit2.png?w=774 if we add a wm bar [10:00] do we have "unsaved document" 3 times ? [10:00] one in the wm bar, one in the headerbar bellow it, one in the tab? [10:01] darkxst: I'm not so sure about that [10:02] seb128: no, it would hide the title in the toolbar [10:02] larsu, how would it look for apps that have only a title and a close button if we hide both [10:02] would we get an empty headerbar? [10:02] or would it get hidden? [10:03] I don't know about that case [10:03] most of the time, apps have additional buttons there [10:03] larsu, when I discussed with them, they seemed to think ignoring the WM hints in Unity was the way to go [10:03] like in the screenshot you posted [10:03] larsu, https://lh6.googleusercontent.com/-Ixfpn57HBL8/UtbDAz_crhI/AAAAAAAAAaM/xwvAaPy8Ebc/w480-h500-k/gnome%2Bcalculator%2B3.11.3%2Bfedora%2B21%2Brawhide.png [10:03] seb128: i think i've seen this link somewhere before ;) [10:03] desrt, no, different one [10:04] that's not a buggy case this time ;-) [10:04] oh. why do you show it, then? :) [10:04] darkxst: who is "them"? [10:04] just an example of headerbar with only a title and button [10:04] desrt, ^ [10:04] desrt, because of larsu, how would it look for apps that have only a title and a close button if we hide both [10:04] larsu, mclassen and co [10:04] desrt is meaning to talk to him [10:04] was gonna yesterday but got busy with menus [10:04] seb128: fair point. Maybe we should hide it then [10:05] seb128: I'm not sure (2) is the better option, and in fact desrt just mentioned some compelling reasons for (1) [10:05] seb128: I'm still pondering and haven't thought about all of the issues [10:05] I'm unsure what (1) mean [10:05] is that doing what GNOME is doing? [10:05] yes, but changing it to look more like unity [10:06] e.g hidding the wm controls and making the theme look "native enoguh" [10:06] right [10:06] dark theming, different buttons etc [10:06] ya [10:06] my concern that we would never have perfect consistency that way [10:06] but I'm happy to be proved wrong [10:06] seb128: we decide to have a desktop based on five toolkits.... [10:06] we will never have perfect consistency, ever [10:06] I'm not sure "perfect consistency" is what we should optimize for [10:06] many apps are going that route [10:06] for example chromium [10:07] chromium is much better integrated than gtkheaderbars [10:07] it even has a setting to use the name wm controls [10:07] and QT apps pretending to be GTK ones like USC! [10:07] name->native [10:07] well, one toolkit you can dream about [10:07] but it's not going to happen [10:07] unless you want to replace skype, eclipse, libreoffice, firefox, chrome [10:08] and I don't see GNOME achieving that either [10:08] seb128, epiphany is pretty slick these days ;) [10:08] so reality is that we have to deal with apps using different toolkits [10:08] darkxst, if you don't care about security in your browser yes [10:08] webkitgtk doesn't do security updates [10:09] epiphany is great -- for webapps, with trusted sites :) [10:09] seb128, yes I know... that is why we still ship firefox ;( [10:09] which is why no distro ships with epiphany as a webbrowser [10:09] using it as a general-purpose browser is pretty much insane [10:09] (and unusable, honestly) [10:09] I hear there is a volunteer to finish the gtk3 native port of libreoffice in the channel? [10:09] right [10:09] Sweetshark_gc, would that be you? ;-) [10:09] seb128: *cough* no? [10:10] Sweetshark_gc, start by fixing those menus! [10:10] *grumble* [10:10] Sweetshark, and add gtkheaderbars ;) just to annoy seb128 ;) [10:10] larsu, but yeah "perfect consistency" might not be the goal, I would still prefer to avoid user-experience-regressions in our default apps if possible [10:10] larsu, but solutions to that might be to patch like we did for menus [10:10] seb128, I'd be open to someone contributing a gtk port of oxide if you want a webengine that's maintained by the security team ;) [10:11] larsu, or to replace those apps by some "written for traditional desktops" [10:11] larsu, e.g we might decide that e.g eog design goals are too far from ours and that we would be better served by another image viewer [10:11] seb128: taking a step back, headerbars are an awesome step forward [10:12] desrt, depending for who, not for app writers that want to target the different desktops [10:12] seb128: i said to take a step back :p [10:12] they give their users a pretty suboptimal experience [10:12] i agree that they're not a great fit if you just drop one app into a desktop like this [10:13] but what i'm trying to say is, honestly, i think we should try to move more toward such designs ourselves [10:13] the issue here is only the consistency one [10:13] (and i agree that is an issue) [10:13] right, I agree with that [10:17] * darkxst hands seb128 a fork ;) [10:17] * desrt hands seb128 a knife and a steak [10:18] * larsu hands seb128 some red wine [10:19] seb128: we'd have user experience regressions too if we switch apps, no? [10:24] larsu, not especially ? if some app is better ? [10:24] larsu, like we replaced f-spot by shotwell, I don't consider that an user regression [10:25] it's different, it doesn't mean less integrated/less easy to use/less features [10:25] seb128: i think the trouble is in finding high quality apps :) [10:25] for better or worse, gnome (still) has some of the best stuff around [10:25] seb128: I meant the confusion that comes with changing the app. But yeah, if it's much better that weighs more [10:26] desrt, well, one possible one could be evince -> okular for example (note that I didn't look at okular, but poppler upstream keep using it as an example of better pdf viewed than evince) [10:26] seb128: poppler upstream are kde developers :p [10:26] I know, okular seems to be a good pdf viewer though [10:26] anyway no point to discuss specific examples [10:27] specific examples are good to discuss, i think [10:27] I'm also sure we would have no difficulty finding a decent calculator [10:27] okular might be good [10:27] it's not like gnome-calculator was the perfect calc [10:27] but if we want to switch away from nautilus or something? [10:27] we would take nemo [10:27] scary :) [10:27] that would give us back split view [10:27] why not caja? [10:27] and other stuff our users complain about loosing [10:27] sorry to chip in, but are you discussing moving towards headerbars? [10:27] * larsu missed those games the last few cycles [10:27] I don't know what caja is [10:27] ochosi: yes [10:27] mate-nautilus [10:28] ipython is a pretty good calculator ;) although probably not for thte masses ;) [10:28] from xubuntu POV (if that is of any concern/interest to you guys) we were rather happy about you patching out the headerbars in 14.04 [10:28] s/xubuntu/xubuntu's/ [10:29] yeah... the problem is that that will become increasingly hard [10:29] ochosi, only nautilus and epiphany were patched, everything else was just avoided [10:29] also: headerbars, in their own right, are good [10:29] and seb128 is afraid that we'll get another patch madness like we have with menus now [10:30] right, that's understandable. but personally i think it'd be better to talk to upstream about providing more options for !gnome-shell desktops [10:30] just "dealing with what we got" is what xubuntu alone is forced to do, we're a tiny team and we have no leverage/voice [10:30] seb128: i hate to appeal to the media, but it seems that all i hear about anymore is gnome is getting better UI and unity is getting worse... [10:31] ochosi, upstream did quite some work with for example allowing WM button layouts within the headerbars [10:31] i think we should not be afraid to follow gnome on some of the improvements [10:31] ochosi: talking to them about more options is asking them to do the work, which is a bit unreasonable [10:31] desrt, not sure what you call "media", I didn't read anything about GNOME vs Unity for a long time and all the trusty reviews I read stated that Unity was "a polished desktop now" [10:31] but they are not going to make gtkheaderbars optional, and atleast in my discussions with them, they seem to think the WM should just ignore the MWN hints for decorations/titlebars [10:32] seb128: i just searched 'ubuntu unity' and the first item that came in google news is "Ubuntu 14.04 review: Missing the boat on big changes [10:32] desrt, is media = reddit ? [10:32] While a new kernel should mean better performance, Canonical's UI troubles persist. " [10:32] arstechnica in this case [10:32] larsu: whatever happened to the good practice of a bit of backward compatability? anyway, i understand, but i think that'd be a good thing even if patches would have to be contributed. maybe i'm too optimistic about "making a voice heard" [10:33] seb128: +1, i haven't read much about that either [10:33] ochosi: voices are heard, it's just that noone has time for it [10:33] darkxst: yeah, but being able to disable headerbars would be more desirable. there's a lovely post by martin grÃ¤sslin about the shortcomings of headerbars (not being able to kill a hanging app,...) [10:34] desrt, yeah for crappy titles [10:34] "What's missing [10:34] Mir and Unity 8 did not make the cut, but they will be coming eventually (14.10 looks pretty likely to see at least xMir enabled by default)" [10:34] media on new gnome release seems to be "hey... this is finally getting really nice... too bad nobody ships it" [10:34] desrt, so arstechnica is speaking about the LTS not having the newest kernel, Mir or unity8 [10:34] seb128: right [10:34] but the unity part of the review is rather positive [10:34] in general i see the biggest thing said about this release is "kinda boring... not much changes..." [10:35] right, that's a LTS [10:35] not much changes since last lts :p [10:36] desrt, that review you mentioned states "Ubuntu is one of the most polished desktops around, certainly the most polished in the Linux world, " [10:36] in the conclusion [10:36] seb128: and the very same article, in the conclusion, talks about the mess that all of our patching has caused us :p [10:36] they have more issues with things like nautilus dropping features, and they say it's coming from GNOME [10:37] "what does it say that it still can't make menus behave consistently?" [10:37] haha [10:37] desrt, well, I don't have the same reading [10:37] to me their issues is what I was pointing before [10:37] design changes from GNOME [10:37] seb128, gnome-shell has improved in leaps and bounds since last LTS [10:37] that are making apps no consistent [10:37] +1 [10:37] seb128: seems like the biggest complaint is with global menu, in fact [10:38] but i think maybe we should stop arguing over what is written in the press [10:39] you are the one who started it! [10:39] but agreed [10:39] ya [10:39] even when i started it i knew it was a bad idea :p [10:39] I think your view of the press is biased as well [10:39] maybe [10:39] but one thing that is pretty clear is that people are liking the direction of gnome [10:40] so if they don't like how gnome apps are integrating in ubuntu then this is either an issue of integration or an issue of the patching that we've done [10:41] desrt, I'm unsure I agree with that, some people like where GNOME is going, some hate it [10:41] same for Unity [10:41] desrt, or an issue of some gnome apps being very old (think gnome-terminal) [10:41] seb128: i think people are upset over some specific things in gnome -- i'm one of them [10:41] but the overall design idea appears to be paying off [10:42] I read lot of comments from user who like mint/cinnamon/elementary/xfce better than GNOME3 or Unity [10:42] ya... of course [10:42] i hear that some crazy people even like kde... [10:42] lol [10:42] I don't think GNOME is winning the "battle of minds" [10:42] i'm just saying that if we want to continue to have gnome apps, we may want to adopt some of their new approaches [10:42] we have more fragmention than before in anything [10:43] they're not bad [10:43] and I don't see a clear winner [10:43] in->if [10:43] and our increasingly complicated attempts to remain in the past are starting to hurt us more and more [10:43] well [10:43] (the past = make gnome apps look like they used to) [10:43] desrt, well particularly hurting Ubuntu GNOME! [10:43] unity7/our current desktop is meant to be a "stable developer desktop" [10:44] our innovations go to unity8 [10:44] * desrt kinda wishes gnome had this kind of focus... [10:44] that has its own set of apps, etc [10:44] * darkxst can't believe that some people prefer to crawl through applications menus, rather types a few letters to search for said app [10:44] so all the problems we discuss are going to be resolved there [10:44] the friction is on the "traditional desktop" [10:45] seb128, how so? unity8 will just further disjoint the "traditional desktop" people? [10:45] darkxst: most people always had some sort of launcher icons for their favourites [10:46] darkxst, what do you mean? [10:46] desrt, that is still there in gnome-shell and unity (I presume) [10:46] darkxst, well, unity8 comes with new apps using the new toolkit, so it's going to resolve the conflict of (ab)using GNOME apps to make them match our design [10:47] seb128, touch apps on desktop ;) [10:48] fwiw, i don't care too much about ubuntu gnome... [10:48] darkxst: the idea is that those will be adjusted for desktop usage and more laptops will have touchscreens [10:48] my primary concern is the increasing amount of developer resource we spend on patching things... [10:48] the question is what we do in the meantime [10:48] which might be a couple of cycles [10:48] right [10:49] well, as said we basically have 2 desktops [10:49] could maybe stop updating all gnome apps [10:49] this is a pretty viable idea, really... [10:49] unity7 is a "traditional" developer desktop, I don't see much design changes or innovation going there [10:49] that's what I was sort of suggesting [10:49] since most of the changes in gnome these days are changing to new UIs.... and then we just want to reverse those anyway [10:49] just keep unity7 as a solid base, just fix issues [10:49] kinda pointless [10:50] imho this is not the right approach, but i certainly like it better than moving to new versions and then hacking their UIs halfway back to the old way [10:51] desrt, the entire point of Ubuntu GNOME is building a community around gnome desktop and make it work well in Ubuntu [10:51] darkxst: i know [10:51] suggesting to hold everything back will just kill our project [10:51] but i guess it's not really the concern of canonical... [10:52] and the potential developers that come from it ;) [10:52] darkxst: you've elected to fight an uphill battle... [10:54] unless we want to start forking everything (unity-nautilus, unity-evince, etc.) like we did g-s-d and g-c-c, you're faced with what is effectively a fork of gnome, trying to make it work like upstream [10:55] desrt, I am not going to fork upstream projects! Canonical should be forking the oldies they want to keep [10:56] ya... maybe there is some good argument for this [10:56] seb128: 3.12 is working fairly nicely [10:56] we did it with g-s-d and g-c-c, after all [10:56] seb128: first issues I'm seeing are titlebar-less dialogs [10:56] larsu, good news! [10:56] but then you get the burden of packaging the gnome releases [10:56] seb128: even o-s seems to work [10:56] \o/ [10:56] I haven't done extensive testing yet, though [10:56] this makes me very happy [10:56] it would have been extremely bad news if we would have had to get rid of o-s [10:56] desrt, if we are going down to "fork" we can as well share the fork, and use e.g nemo... [10:57] or caja [10:57] take a look at mate, seriously... [10:57] it's basically like releasing old versions of gnome :p [10:57] heh [10:58] just keep updating the libraries -- this is all most people care about [10:58] "developers", after all [10:58] desrt: it's what you care about === MacSlow is now known as MacSlow|lunch [10:59] larsu: in so far as i care about people like yorba who care about things like which libraries are available on ubuntu [11:00] desrt: they also care about what kind of ui and platform integration we have [11:00] and it's a pain to support more than one for them [11:00] larsu: ya... but we can keep this looking OK by staying with old versions [11:00] man, why are we talking on irc? [11:00] I can even see your irc window from here [11:00] because we're not red hat ;) [11:00] haha [11:02] desrt, larsu: anyway, to focus back the discussion [11:02] let's make GtkHeaderBar work as good as we can on !gnome-shell (Unity being the main focus) [11:02] that's the first step [11:02] this sounds good [11:03] once we think we have "as good as we can get", we can see how apps feel like [11:03] and then decide on the next steps for those [11:03] like if we feel gtkheaderbar are integrated enough [11:03] or if we need to get out of our way to resolve extra issues [11:03] seb128: what do you mean by that? My suggestion (1) or (2) from earlier? [11:03] there are a few things that are needed to get it working right... but not majorly huge ones [11:03] (make them look native in unity or make them be toolbarS) [11:04] larsu, I'm sure, whichever you feel like is going to give us the best experience on Unity [11:04] *unsure* [11:04] sounds like we have some work for the coming days [11:04] ya, this is my main goal for the hackfest [11:05] great [11:05] seb128: interesting. I'm unsure as well :) [11:05] sorry for all the side discussions [11:05] no worries [11:10] attente: hi, could I bother you a bit about http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/437.1.10, and in particular about these lines? [11:10] 344+ if (n_sources < 2 || g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "Unity") == 0) [11:10] 345 strip_xkb_option (options, "grp:"); [11:10] These lines break keyboard layout switching in applications that grab the keyboard, like SDL applications, so we cannot type e.g. Greek in e.g. tuxpaint, tuxtype, teeworlds etc. [11:10] See also e.g. my comment #7 in https://bugs.freedesktop.org/show_bug.cgi?id=42244 [11:10] Freedesktop bug 42244 in Server/Input/Core "Multimedia keys become unresponsive in full-screen applications" [Normal,Reopened] [11:11] (it's not only about multimedia keys anymore, now it's significantly more important, all those applications become useless for non-latin environments) [11:13] alkisg, we disabled it because layout switching is done differently in unity and we didn't want xkb switching to conflict with that [11:13] attente: and, is there any provision for the issue I mentioned? [11:14] Because I don't think you'll be able to allow keyboard switching without letting xkb manage it... [11:14] (in apps that grab the keyboard) [11:14] alkisg, no, I think it's one of those GNOME design decisions where you are going to need to wait for wayland/Mir to have it working back correctly [11:15] seb128: in Fedora they have it working like I mentioned [11:15] It's an ubuntu-specific patch [11:15] alkisg, sorry, i'm reading the bug report, but not really sure how the grp: option is related [11:15] alkisg, the freedesktop bug states "(It's the same in other distros too, it's not Ubuntu specific)" [11:15] seb128: there are many many bugs about it, it's a lot more than this one, [11:15] alkisg, also the xorg grabbing is nothing Ubuntu specific [11:15]