=== udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1308/client-2/ - http://irclogs.ubuntu.com/2013/08/29/%23ubuntu-uds-client-2.html === bfiller is now known as bfiller_afk === Sweetsha1k is now known as Sweetshark [14:42] who can setup the hangout for the 32 v 64? (or is it me?) [14:47] the track lead [14:54] Laney: that might be me.. how do I get access? [14:54] gQuigs: It's not. Client 2 is seb128 [14:55] Laney: oh, good :) [14:55] ? === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | 32 vs 64 bit discussion\; should we recommend 64 bit now? | Url: http://summit.ubuntu.com/uds-1308/meeting/21877/client-s-32v64-bit/ [14:55] gQuigs, slangasek is going to host 32v64 bits [14:55] we traded hosting [14:55] he's going to be more useful than me in that discussion [14:57] hangout is up whenever people are ready; broadcast starts at 5 after the hour: https://plus.google.com/hangouts/_/8062a252264637337f25ffd01d50d5ce4cdfa32c [15:03] bah, i was on wrong irc. [15:03] xnox: https://plus.google.com/hangouts/_/8062a252264637337f25ffd01d50d5ce4cdfa32c [15:12] slangasek: apt-get download grub-efi-amd64:i386 results in grub-efi-amd64_2.00-18ubuntu1_i386.deb [15:15] Is there anyway to instrument the installer to warn the user if they are using the 64-bit installer, and their processor is 32-bit capable? could this be done before grub? [15:15] arges: I thought the 64 bit image wouldn't even boot then [15:16] pitti_uds: that's what i was thinking. but wasn't sure [15:16] arges: at least they don't boot on my atom netbook (dell mini 10) [15:18] Does anyone know of an ubuntu developer that is running a 32-bit machine? my guess is that there are very few... so from a tested by development perspective, I'd expect 64-bit to be much more thoroughly tested. [15:18] chiluk: indeed; but there are a few like seb128 who deliberately use 32 bit for that very reason (testing that arch) [15:19] which again proves my point, that 64-bit is more heavily installed by our developer base, and as such should be the default. [15:20] chiluk, I'm running 32 bits [15:20] less memory waste, used to have better compat with some binaries [15:20] ok so there are two of you, and possibly apw, since he's crazy and uses a netbook. [15:20] mterry used to run 32bits as well [15:20] (didn't check recently) [15:21] everyone used to run 32.. [15:21] but we still have 32-bit images [15:21] this is a question of recomemndations [15:21] chiluk, that's probably not the majority but there is a non trivial number of users running 32b [15:22] chiluk: no, I've run 64 bit on my workstation since 2005 :) [15:23] chiluk, well, that "used" was some months ago, not years ago [15:23] slangasek: could we use launchpad to get statistics on 32/64 usage? [15:23] chiluk, not sure what point you are trying to make, there are i386 users, do you try to deny that there is any? [15:23] bug reports etc [15:23] arges: yes, on all apport bugs we have an Architecture: field [15:24] seb128, my point is, our default should be whatever the majority of our developers are using. [15:24] bdmurray has a fair bit of machinery for mining LP bugs, perhaps he can run a query about the Architecture: field [15:25] chiluk, that's likely 64bits then I guess [15:25] chiluk: I don't think that's a good metric; developers do different things than the average user (e. g. more compiling, and perhaps less gaming, etc.) [15:26] bdmurray: how do we ensure that the reports are coming from unique machines? [15:26] do we have any metrics based on what is being downloaded? [15:26] chiluk, but number of users is not the only metric, "is it working on all hardware our users have, or are we going to recommend things that don't even boot for 10% of our userbase" is another one [15:26] 64 bit speeds up compilation quite a bit, but why would a non-developer care [15:26] arges: the error tracker keeps track of unique machines [15:26] bdmurray: cool that would make it easier then [15:26] but with UEFI it becomes interesting, as at some point the i386 images which don't boot on modern computers will outnumber the old computers which don't boot with amd64 [15:27] majority is majority... that's what we should be recommending...there will always be people with old or corner case hardware... we can't cater to the minority. [15:27] yes, even if we offer 64 bit by default we need to keep the 32 bit ones; but I don't think anyone proposes dropping them [15:27] pitti_uds: arges: right, 64bit images doesn't boot on 32bit-only-cpu. and the flip coin to that SecureBoot-UEFI-64-bit by default will not boot the 32bit image. [15:28] hence the threshold when 64bit becomes more compatible than 32bit, as neither boot everywhere. [15:28] pitti_uds, correct, we should not drop 32-bit... but I don't think those people are the majority at this point. [15:28] chiluk: yes, I agree [15:28] woops s/are/are not/ [15:28] http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93 [15:29] chiluk: "default what majority devs use" is false statement, as we are not the typical users, we often have SSD, redicilous cpus, and large amount of ram. [15:29] * xnox doesn't have GPU, but have 32GB of RAM. [15:30] xnox, I would state that users of linux are typically more like our developers than like my mother-in-law (who uses a netbook) [15:31] chiluk: we don't have a data source to know which one is the majority, among _ubuntu_ users. [15:31] and hence the workitem to get a reliable source. [15:31] apw: ^^^ /sys/firmware/efi [15:31] i know you guys are like +1m [15:31] xnox, we do have experiences from meeting users at conferences [15:31] arges, right ... though that isn't already in apport sadly [15:31] I don't think popcon is being updated [15:32] xnox, I agree it would be best to get a reliable source of metrics [15:32] :-) [15:32] so if we collect this info, will we be ready for a decision in 14.04? [15:33] arges: /o\ \o/ depends how quickly we sru and get it out. [15:34] I would think that apport could also be off a bit as I would expect things like using old machines for print-servers or so (or actually some of the small systems usable as routers) would have such a broad sw usage to create simlary many bugs [15:35] Isn't this a bit of an abuse of whoopsie? [15:35] It's supposed to be a tool for error reports not data mining [15:38] go with 64-bit! [15:38] Laney: in fact, the whole intention of errors.u.c. was to do data mining [15:39] Laney: arguably data mining for errors, but if it works for this stuff, too :) [15:39] pitti_uds: Well, as it relates to errors ... [15:39] Laney: it's a pure mining tool of errors. it's whole purpose that it has large amount of data to act on it. [15:39] This is attaching something to my error information that you want to use for some other purpose [15:39] Laney: i took action to check whoopsie policies / privacy / etc if this is ok to include or not. [15:39] At least the purpose is: how to make Ubuntu better for more people. (suggesting the right default) [15:42] i thought the module creates /sys/firmware/efi [15:42] arges: right, but we want find out if the 32bit booted machines, can do efi. [15:47] don't kill 32-bit, please [15:47] arges: https://plus.google.com/hangouts/_/8062a252264637337f25ffd01d50d5ce4cdfa32c [15:48] hah [15:48] ok [15:48] kill it with fire! [15:50] arges: http://pad.ubuntu.com/uds-1308-client-s-32v64-bit [15:50] I'm even against killing 32-bit with fire. [15:51] chiluk, right, a laser works, too :-) [15:51] however, this discussion is only about what the default recommendation should be. [15:51] (right) [15:51] metrics may actually be biased toward 32-bit at the moment simply because 32-bit is still the default.. so quantitative metrics may not be the best. [15:55] xnox: again, different bias -- the non-LTS versions may receive much less attention by non-developers [15:56] pitti_uds: true. [15:56] on a side node, with multiarch it's actually theoretically possible to sidegrade someone from 32 to 64 bit, right? [15:56] yes [15:56] (so that we can eventually drop it for upgrades, too) [15:56] good [15:58] +1 [15:58] thanks all! [15:59] pitti_uds: practically speaking, a sidegrade is currently quite hairy, but it is possible ;) [15:59] thanks! === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | building a community around Mir next | Url: http://summit.ubuntu.com/uds-1308/meeting/21939/client-1308-mir-cosmonauts-community/ [16:02] who is hosting client2? [16:03] seb128, are you hosting this session? [16:04] tvoss_, yes, https://plus.google.com/hangouts/_/18a8f304eec961035f1902f224b7d587a0ac6784?authuser=0 [16:04] back in 1 min to start the streaming [16:04] gQuigs: who is drafting that blueprint? I guess me, as I'll have the most action items, or do you still want to draft? or like draft together? [16:06] xnox: I'm fine either way :) [16:06] gQuigs: ok, i'll draft it, and will ask for a review from you. [16:06] xnox: awesome, thanks! [16:06] stream starting in a min [16:07] http://youtu.be/hKiqUGlu0fU [16:23] you guys are talking a lot about the PPA, are you going to discuss at all what kind of community you want to facilitate? [16:24] yep [16:32] I think the start of the on ramp should be installing the PPA, right? [16:35] wow, that's a lot to repeat ;) [16:35] rickspencer3, remember I am the one writing summaries for summaries [16:36] :) [16:37] I think another problem is that there is a certain amount of trolling from other projects that Mark mentioned in his opening plenary [16:38] it makes it not as fun to join a project under those circumstances [16:40] unity is a good example === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1308/client-2/ - http://irclogs.ubuntu.com/2013/08/29/%23ubuntu-uds-client-2.html === alecu is now known as alecu_lunch === alecu_lunch is now known as alecu