=== Obama is now known as Guest52901 === ssweeny_ is now known as ssweeny === ara_ is now known as ara === asac_ is now known as asac === Obama is now known as Guest40234 [11:58] hi [11:58] all === srx_ is now known as [srx] [15:53] So who's here for Ubuntu Developer Week and who's excited about it? :-) [15:53] Me!!! [15:53] come on everybody! :) [15:54] who else.... don't be shy :) [15:54] * MrKanister clapps [15:54] * Ireyon too [15:54] Who did NOT tell their friends to come yet? :-) [15:55] Do it now, you still have 5 minutes before ara kicks it off! :-) [15:56] dholbach: discreet way to ping me ;-) [15:56] ara: I knew you'd be around, I wasn't really worried :) [15:57] alrightie... we have Ara Pulido here today, who's going to talk about "Automated Desktop Testing" [15:57] it'll take just an hour for you to realise that it's the best thing since sliced bread [15:57] :) [15:57] if you have questions, please ASK :-) [15:58] but please ask in #ubuntu-classroom-chat prefixed with QUESTION [15:58] ie: QUESTION: ara: what is your favourite band? [15:58] and I would say; dholbach: Saint Etienne [15:58] I'm sure you're going to have a lot of fun here, so let's have an applause for Ara! [15:59] * Ireyon claps [15:59] claps [15:59] (and you still have one minute to grab a coffee, tea or something stronger before we kick off!) [15:59] * [srx] claps [15:59] YAY! :-) [15:59] enjoy [16:01] OK, it is 4pm UTC, I think that we can start with the session [16:01] thanks dholbach and everybody else for the warm welcome [16:02] as dholbach just said, I am going to talk about Automated Desktop Testing, but first let me tell you a secret [16:02] a secret very few developers know [16:02] it will change your life as you know it [16:02] ok, here it is: [16:02] testing software is *FUN* [16:03] not boring, not tedious, but FUN [16:03] my name is Ara and I am part of the Ubuntu QA Team [16:04] (https://wiki.ubuntu.com/QATeam/) [16:04] as part of my duties in the team I have started the Ubuntu Desktop Testing project [16:04] (http://launchpad.net/ubuntu-desktop-testing) [16:05] The project aims to create a framework to run & write automated desktop tests for Ubuntu [16:05] To be able to try some of the tools that I am going to present, you will need to have installed 'bzr' in your computers. If you don't have it, you can install it easly: [16:05] $ sudo apt-get install bzr [16:06] Also, if you don't understand something or you think I am going too fast, please, please, please, stop me at anytime (asking in the -chat room) [16:06] Ape3000: QUESTION: Should I use my Intrepid desktop or Jaunty virtualbox machine? [16:07] Ape3000: Both of them should work [16:07] Let's start with a brief introduction to desktop automated testing, just in case you don't know what this session is about [16:08] With automated desktop testing we name all the tests that runs directly against the user interface (UI), just like a normal user would do [16:09] a script will run and you will start to see buttons clicking, menus poping up and down and things happening, automagically [16:09] Ireyon: does that answer your question? [16:09] yes it does, thanks [16:09] In Ubuntu we do this by accessing the GNOME accessibility layer (AT-SPI) [16:10] This layer was originally written for assistive technologies, like screen readers and such [16:10] technologies to make computers accessible to people with disabilities [16:10] but it turned out that it works pretty well for desktop automated testing [16:11] that is why some testing frameworks use the AT-SPI layer to get access to the UI objects, get some information from them, and get them to do things (push buttons, write text, etc.). [16:12] if you want to be able to run the examples during the session you would need to enable the assistive technologies [16:12] and you must use GNOME, as the layer does not work for KDE [16:12] Here they are some instructions on how to do it: https://wiki.ubuntu.com/Testing/Automation/Desktop/#How%20to%20run%20the%20tests [16:12] basically is checking the box in the dialog in System->Preferences->Assistive Technologies [16:13] the bad bad bad news is that you would need to restart your gnome session if you want the changes to be applied (if you are using a virtual machine for the examples this is not as bad news) [16:14] weboide: QUESTION: Can those tests make the machine become unstable/frozen/broken? [16:15] weboide: depending on what you do with your tests :-) normally they do no harm, but the at-spi layer still have some bugs, so you may spot some of thems [16:15] For the Ubuntu Desktop Testing project we are using LDTP (http://ldtp.freedesktop.org/), that has a python library for writing tests. This is one of those automated desktop testing frameworks that use the at-spi layer [16:16] If you want to run the examples in this session, please, install LDTP: [16:16] $ sudo apt-get install python-ldtp ldtp [16:16] ia: QUESTION: does exist some log system in this tests, so user/developer after testing could see, what goes well and what goes wrong? [16:17] ia: sure! you don't have to watch your tests as they are running. You can go and do your things and come back to check the results. We will be seeing that later on [16:18] When using this library you have to use some specific information from the UI in order to recognize the objects (window titles, object hierarchy, etc) [16:18] I.e. if you want to click a button in the Gedit window, first you will need to recognize the window, then obtain its children, and finally click the selected button. [16:19] If we add all that information to the script and then the UI changes, we would need to change all the scripts to match the new UI changes. [16:19] One of the main objectives that we are trying when we create a testing framework for Ubuntu desktop is to avoid scripts to know anything about the objects behind them. [16:20] Definitively, these objects will still require to be maintained, but the logic of the scripts will remain the same. [16:20] One example. Let’s imagine that we had a regression test suite for Gedit that will edit, modify, open and save several files. [16:21] If any of the Gedit features changes its UI, only the Gedit class will be modified. All the scripts will still be valid. [16:21] The other good thing about it is that people willing to add new test cases to ubuntu, can do it easily [16:21] they don't need to know much about ap-spi or LDTP, just some basic python scripting will do [16:21] If you're running Intrepid or Hardy you can get the Ubuntu Desktop Testing library as: [16:22] $ bzr branch lp:ubuntu-desktop-testing/intrepid ubuntu-desktop-testing [16:22] If, by any chance, you're running Jaunty, the trunk fixes some differences in this release: [16:22] $ bzr branch lp:ubuntu-desktop-testing [16:22] If you find any bugs in the UDT library itself, please, report them in the Launchpad project: [16:22] https://launchpad.net/ubuntu-desktop-testing [16:23] don't report them to the Ubuntu project :-) === gman_ is now known as gman16k [16:23] The Library API is up-to-date and it is available at: http://people.ubuntu.com/~ara/ubuntu-desktop-testing/doc/ [16:23] Right now we have classes for Gedit, Update Manager and PolicyKit and Seahorse. We also have a generic Application class to gather common behaviour from GNOME applications. [16:24] Let's see an example on the difference on writing tests for ubuntu using the testing library and using only LDTP [16:24] so you can understand better what I mean with "basic python scripting" [16:25] This is the link to the code using the testing library: https://wiki.ubuntu.com/Testing/Automation/Desktop/HowToUseTestingLibrary/Comparison/UsingDesktopTestingLibrary [16:25] what would you say this code does? [16:26] weboide, Ireyon: yes. that's it [16:26] the code is more or less self explanatory [16:27] (and commented, just in case...) [16:27] Now the code using pure LDTP code, with out the Ubuntu Desktop testing library: [16:27] https://wiki.ubuntu.com/Testing/Automation/Desktop/HowToUseTestingLibrary/Comparison/PureLDTPCode [16:29] It is not very very complicated, but the code is becoming less clear, and more difficult to understand for new people [16:29] Also the desktop testing library include error checking code that I have removed from this example to make it clearer [16:30] not to say that using at-spi code directly would make things even harder... [16:30] Ok, let's try a small example. Remember that you will need to have the Assistive Technologies enabled to try this at home :-) [16:31] if you don't have them enabled, you can log out and come back (I will answer questions in the next 5min if people decide this) or wait and try it when the session finishes [16:31] what do you guys prefer? [16:33] Ireyon: I don't get the libs installed [16:33] Ireyon: what libs? [16:33] the python libs [16:33] Ireyon: what error do you get? [16:34] ok, we will go on [16:34] The example that we are going to run will open gedit, will write some characters in there, will save the file, and will compare it to another one to check for pass/fail. Be sure to close all your gedit sessions before running this test, to avoid messing up your documents. [16:34] Let the magic start: [16:35] $ cd ubuntu-desktop-testing [16:35] $ ../bin/ubuntu-desktop-test -a gedit [16:35] change that last one by [16:35] $ ./bin/ubuntu-desktop-test -a gedit [16:35] sorry [16:37] OK, once that your test has finished, you can grab the logs [16:37] ia: ^ [16:37] the logs can be found at ~/.ubuntu-desktop-tests/gedit [16:37] you will find and XML log (in case you want to transform it to something else) [16:37] and a nice HTML report, in case you want to publish that somewhere === sdx24 is now known as sdx23 [16:39] Ireyon: LdtpExecutionError: "Mmm, something went wrong when saving the current document:'The mnuSave menu was not found.'" [16:39] Ireyon: did you close the window? before the test finished? [16:40] Ape3000: QUESTION: Would it be possible to create desktop macros for general use with this? [16:40] Ape3000: yes, you could. I don't think that it is the best library for macros, though, but yes, you could use it for that [16:42] one of the classic questions that people ask is, can I use this to test Fedora/OpenSuSE/Debian/OtherDistroOfMyChoice... [16:43] the answer is yes [16:43] and the good thing is that it is the perfect timing if you want to join a brand new team [16:44] The GNOME people started to be really interested in the project, so we decided to create a GNOME desktop testing project [16:44] (https://launchpad.net/gnome-desktop-testing) [16:44] The code is now in LP, but it will move eventually to GNOME SVN servers. [16:44] It includes the things in ubuntu-desktop-testing that can be apply to all the GNOME environments [16:45] i.e. it does not include UpdateManager class, because that it is something Ubuntu exclusive [16:45] If you'd like to contribute and be part of this motivating new project, go ahead and show your love at http://live.gnome.org/DesktopTesting [16:46] Ape3000: QUESTION: So what are the best things with using this kind of automation? [16:46] Ape3000: regression testing, mainly. If something breaks between releases, those tests can be useful to catch this kind of regressions [16:48] This technology can be used also to test Xubuntu [16:48] so, if you are using Xubuntu and want to contribute, that would be great [16:48] right now we are only giving coverage to Ubuntu (GNOME desktop) [16:49] Ok, only ten minutes left, let's wrap up [16:49] Ape3000: QUESTION: Do you have any example bugs / cases where automated desktop testing was helping greatly? [16:50] Ape3000: The project is still very young, but we helped solving some accessibility bugs, while creating our tests [16:50] Ape3000: a list https://wiki.ubuntu.com/Testing/Automation/AtspiBlockers [16:51] You can contribute easily, with very little programming knowledge, to the automated testing efforts by writing new test scripts using the testing library. A How-To guide is available at https://wiki.ubuntu.com/Testing/Automation/Desktop/HowToUseTestingLibrary [16:51] Also, if you have more advanced python knowledge and would like to give a try on extending the desktop library that would also be great [16:52] Please, apply your changes in your branch and use "Merge proposal" feature in Launchpad! [16:52] Any other questions? [16:53] counting down... [16:53] 5... [16:53] 4... [16:53] 3... [16:53] 2... [16:53] 1... [16:53] ... [16:53] loic-m: QUESTION: Is it possible to use this for benchmarking desktop tasks (i.e. à la Phoronix)? [16:54] (with the bell) [16:54] loic-m: Yes. It is not specifically a benchmarking framework [16:54] loic-m: but times are always taken between tests [16:55] loic-m: and it is pure python code, so you can use any python library of your choice [16:55] no more questions? [16:57] [srx]: QUESTION: can we print like this? [16:57] [srx]: I don't understand the questions, sorry [16:57] One more thing. These tests work only (for the moment) if you have your desktop in English :-) [16:57] Ireyon: ^ [16:58] QUESTION: is this only for Gnome applications, or will it work for qt/tcl-tk/etc? [16:58] loic-m, StyXman: KDE is working on having a better accessibility layer. but for the moment these tests only work for GNOME [16:59] i guys [16:59] Ireyon: QUESTION: Is there any chance to get it working with any language? [16:59] what is this room for i am new here [17:00] Ireyon: right now we are starting giving coverage to English desktop. Maybe in the future... [17:00] OK. No time for more. If you have any questions you can ping me in #ubuntu-testing channel or at my email address [17:00] Thanks all for coming! I hope you all enjoyed the session! [17:00] * Ireyon claps again [17:00] ara: Great job! Thanks you. [17:00] iamarockstar: for sharing and learning more about ubuntu "it's a classroom" [17:00] thank you ara, that was awesome :) [17:01] somaunn: then what is the diff betwween this and nirmal ubuntu irc room?is this for devs? [17:02] iamarockstar: https://wiki.ubuntu.com/UbuntuDeveloperWeek [17:02] iamarockstar: for devs and those who are interested in becoming one [17:02] thanks!! great session!! [17:03] silwol: ok thx [17:03] iamarockstar:follow the link given by Ape3000 for more info [17:03] somaunn: https://wiki.ubuntu.com/Classroom [17:03] * repete looks at the clock... [17:04] Can we start the next session? [17:04] Ok, in the absence of a moderator, we will :-) [17:05] Hi and welcome to the Ubuntu Netbook Remix session for Ubuntu Developer Week. I am Pete Goodall, the product manager for the OEM Services group at Canonical. And joining me are Neil Patel and Bill Filler, also with OEM Services, and the lead developers for the Ubuntu Netbook Remix project. [17:05] We did a session on Ubuntu Netbook Remix (UNR) back in November for Ubuntu Open Week, so this will be an update on UNR followed by a question and answer session. [17:05] Neil, Bill and I work for the OEM Services group at Canonical, and we are the group responsible for customising Ubuntu for device manufacturers. By "customising" we mean making sure that all the hardware components work, integrating custom interfaces (ala Dell and HP) and providing on-going maintenance. [17:06] So you know what is coming, here is a quick agenda for this hour: 1) Installing UNR 2) Developing for UNR and netbooks in general 3) Question and answer session. [17:06] OK, so lets start with installing UNR. Hopefully many of you are already running UNR on your laptop or netbook, but if you are not you can find information on how to install UNR at the UNR wiki - http://wiki.ubuntu.com/UNR. [17:06] To date, Ubuntu Netbook Remix has been an addon to Ubuntu 8.04 and Ubuntu 8.10. Installing the UNR interface involved either adding the PPA to your software sources list and twiddling configuration bits, or running the UNR installer which overwrites your entire hard drive. [17:07] However, starting with Ubuntu 9.04 (Jaunty) you will have two new and improved ways to install UNR on your existing device. If you don't already have Ubuntu or you just want to do a clean install you will be able to download a Live CD image just like you can with Ubuntu Desktop Edition and go through the normal installer. That means you can choose your own partitioning or just use the Live CD to see what UNR is all about. [17:07] We are still working out the exact way it will be done, but the second option is for those that have an existing Ubuntu 9.04 system and want to install the UNR interface as well. You will no longer have to add a PPA to your software sources list because UNR will be in the official Ubuntu software repositories. Therefore you can just install the UNR interface with apt-get, aptitude, or synaptic. This may or may not involve tw [17:09] Before I move on to developing for UNR, does anyone have questions about installing? [17:09] QUESTION: Should it work with virtualbox? [17:09] No, unfortunately, as there will not be OpenGL acceleration available for the launcher [17:10] repete: previous-to-last paste got truncated at 'This may or may not involve tw...' [17:10] ah... thx [17:10] so the launcher will run with software accel., which is slow and a bit buggy [17:10] This may or may not involve twiddling configuration bits, but we're trying to make it easy. :-) [17:10] QUESTION: Will the LIVECD (iso) image have support for many common netbooks? ie. corrcet driver for eeepc wifi? [17:11] As much as possible we try to support all the hardware [17:11] To your specific question, the wireless should work just fine in the eeePC [17:11] Many people use UNR on a eeePC [17:11] there are always device-dependant quirks (just like with ubuntu desktop), which will need tweaking after install === Keybuk_ is now known as Keybjk [17:12] QUESTION: Do you also have the ordinary Ubuntu interface with the netbook remix? === Keybjk is now known as Keybuk [17:12] yes, you have the option to switch to "classic" Ubuntu interface [17:12] Yep, we have a nifty utility called Desktop Switcher, which allows you to switch between netbook-mode and classic-mode without losing your customisations [17:12] this was not available for intrepid, but will be for jaunty [17:13] You can find the Desktop Switcher in Preferences [17:13] OK. Next let's talk about developing for Ubuntu Netbook Remix. If you are interested in contributing to the development of the UNR interface and components there a couple of things you need to know. First, the UNR launcher (netbook-launcher) is written using the Clutter (http://clutter-project.org/) toolkit. If you are not already familiar with Clutter it is basically a toolkit that simplifies common OpenGL and OpenGL ES ope [17:14] The second consideration is that we need to keep things simple. That is a core value of the UNR project. At Canonical, we work with OEMs and ODMs to create devices that are sold to consumers. "Consumers" may be people whom are not techies and just want things to be easy to use. [17:14] They don't want a spinny cube, they don't want a thousand functions available at a single click and they don't want to open a terminal from any place in the system. :-) [17:15] I'm conscious that my long posts are being truncated so I'll make them shorter [17:15] If you are not already familiar with Clutter it is basically a toolkit that simplifies common OpenGL and OpenGL ES operations and allows you to create rich, annimated user interfaces. If you are already familiar with gtk+ and gobject, Clutter should not be hard to learn. [17:15] Since the inception of this project we have received invaluable feedback from the Ubuntu user and developer community, and this has been a key advantage of UNR. [17:16] If the project leads reject your feature as "out of scope" please don't be offended. We are just trying to keep things simple. [17:16] If you really want to implement a more advanced or crazy feature all the code for the UNR launcher and the various components is in Launchpad. From there you can create your own branch. [17:16] Finally, if you already maintain an application in Ubuntu or are considering creating an application for UNR please consider the available verticle resolution. [17:17] Last year most netbooks had a resolution of 1024 x 600. This year 1024 x 576 is the new black. [17:17] Canonical has worked to fix some applications such the Evolution account dialog, Pidgin and various GNOME utilities. [17:18] Also, you should be mindful of the emergence of touch. Touch will be more and more prevalent and application developers should keep this in mind. [17:18] Bigger icons, simpler interfaces [17:18] Not too reliant on right-click, menu-bars etc [17:18] Ok. let's field some questions about developing for UNR. [17:19] thats ok [17:19] " and various GNOME utilities." --- ?!? o_O [17:19] I thought GNOME was not used in UNR? [17:19] UNR is based on Gnome, but we have a different UI for launching and switching applications [17:20] gnome-panel is used, but configured differently by default in UNR [17:20] The reason UNR is called a "remix" is because it is based on Ubuntu Desktop Edition, but adds some components and changes some configuration bits [17:20] QUESTION: I submitted 2 bugs a while ago for UNR, however it took around a month for them to get seen, are you making steps to shorten this time? [17:21] the bug situation is almost definitely my fault, and yes it is getting better [17:21] our QA team is now formally involved in initially confirming/triaging bugs, so the initial response time should be much faster [17:22] it is a goal of ours for sure to improve this process [17:22] QUESTION: some graphic effects (ex, spinning icon during opening app) doesn't looks correct, if compiz enabled (i think, it's becase exist some confilcts in graphic between compiz and clutter). does UNR team plan to include correct compiz support? [17:22] The intel video drivers (on most netbooks), do not support displaying Compiz and a GL window (like the launcher) at the same time [17:22] you can get some more information here https://bugs.edge.launchpad.net/netbook-remix-launcher/+bug/237731 [17:23] This is a bug that's fixed in xorg bugzilla and will hopefully be available fr testing in Jaunty [17:23] QUESTION: Are there plans to support LXDE? [17:24] We have looked at LXDE as a base, but the GNOME environment is a well developed environment [17:24] QUESTION: What are the goals wrt Memory footprint as well as boot time for UNR? And how have you been striving to meet them? [17:25] by that I mean that GNOME has things such as advanced power management utilities, accessibility [17:26] boot time 30 secs or less, RAM 1GB, HDD/SSD 4GB minimum [17:27] Boot time is a major focus of Ubuntu 9.04, so there should be some big improvements when UNR is released on Ubuntu 9.04 [17:27] we test those configurations, boot time is the biggest challenge and we spent much time trying to reduce boot time, Jaunty should help in this area [17:28] QUESTION: why opengl? why not plain gtk? [17:28] it's sexier :) [17:28] We wanted a nicer user experience with the launcher, using animations, fades etc to enhance it. We are currently quite tight on which animations we use, but we plan to start experimenting more over the next few months [17:29] QUESTION: If most people say GNOME is bloated (in contrast to other desktop environments); And UNR team is trying to make thing light and simple, why not choose other like Xfice? [17:29] This is similar to the LXDE answer [17:30] We have looked at XFCE, and we actually have one of the core devs on staff, but the GNOME environment is still better developed for our purposes [17:30] Several years ago, GNOME was stripped down for the 2.0 release [17:31] ever since them they have been building up capabilities as needed. We believe it is the best environment for the job. [17:31] s/them/then/ [17:32] Anymore questions? [17:32] QUESTION: do all the development made for OEM appear in the repositories, i.e. 1. hw drivers 2. hw and software tweaks 3. interface configuration ? [17:33] Yes. The user interface components that make up the netbook remix are all developed in launchpad and available from there [17:33] the patches to desktop apps to make them fit in the smallr space are being reviewed and merged into Ubuntu main and we are working with the upstreams to get them integrated [17:34] Where appropriate we push the hardware drivers upstream as well [17:35] As part of the OEM engagement we require close collaboration with the component manufacturers [17:36] So all hw should function the same, wether from the OEM install or if one wants to reinstall from scratch using for example a (sometimes newer) LiveCD? [17:36] Well with our customers they are using hardware that may not actually be on the market yet :-) [17:37] As soon as the product is released we work to get those drivers in upstream, but that doesn't mean we can necessarily get it in Ubuntu 8.04 [17:37] there also may be custom work we've done for an OEM is newer than the latest release of Ubuntu [17:37] because that is a released product and we cannot change that kernel too much [17:38] we work to ensure mods which are made to the kernel, drivers, apps, etc.. make it into the next Ubuntu release where applicable [17:38] Any more questions? (We've moved onto Q&A now, if it wasn't obvious ;) [17:39] QUESTION: I understand ten that the Ubuntu Dell is shipping is the same as the Ubuntu I can install via the Canonical CD? or are there differences? === rosset is now known as rosset-brb [17:40] there are differences, the publicly available UNR from Canonical is completely free, open-source components and standard UNR launcher [17:41] Dell and other OEM are able to ship applications which require a license (i.e Adobe Reader, Skype, etc..) where the free version doesn't have these components by default [17:42] Dell's launcher is also customized, but it is open source [17:42] so there are differences, yes [17:42] QUESTION: has any OEM asked for non GPL/LGPL development (f.e. hw drivers)? [17:42] it's the same baseline of code though [17:42] sorry, bfiller :-) [17:42] I'm done :) [17:43] ok. So to answer the non-GPL question... [17:43] Canonical does not do any non open source development work on the client [17:43] Anything that is not open source is done by a third party [17:44] Wherever possible we always encourage our customers to use and contribute to open source software [17:44] QUESTION: difference bw OEM install and Ubuntu repos means if i buy an OEM with UNR, the only way to be sure hw will be "perfectly" supported is to stick with an "old" version of Ubuntu? [17:46] I think you are referring to the fact OEM version of UNR is based on 8.04 [17:46] updates are released to the OEM repository, but is based on 8.04 [17:47] With a device that is sold in retail it is not a good idea to change the underlying OS every six months. Ubuntu 8.04 is a long term support release (LTS), so that mean we will support it (and products based on it) for up to three years. [17:47] so yes, for a fully supported product released by the OEM you should stick with their install and update as appropriate [17:48] it doesn't mean the latest and greatest free version won't run on it, but it may not be specifically tested and supported on that particular device [17:49] QUESTION: how can users check that a netbook that comes with UNR is entirely supported by OS drivers (so no lock-in), and to make it easier is there a logo Canonical is advising OEM to stick when it's the case? [17:50] As much as possible drivers from an OEM install will make it into the next version of Ubuntu. [17:50] If you want to test your hardware, you can (as of Ubuntu 9.04) use a Live CD. [17:51] any other questions? [17:53] QUESTION: AFAIU, Intel IGP used in most netbooks aren't open-source (and the one they plan to use for their next Atom platform, based on PowerVR tech, isn't either), are you in discussions with Intel to improve the situation? [17:53] loic-m is obviously very interest in UNR :-D [17:55] Intel is a close partner of Canonical. As I mentioned earlier, we *always* advocate for the use of open source software. That being said, it is entirely up to Intel how the license drivers. [17:56] QUESTION: Has Canonical tied up with other company (aside from Dell) to release Ubuntu as netbooks default OS? [17:56] Also, the IGP cipset isn't the one that's being used the most. Most of the netbooks have 954GMA, which has very good drivers [17:56] There are two other vendors that have released products based on Ubuntu [17:56] sorry, three :-) [17:57] No, two... [17:57] Toshiba NB100 and the Sylvania G Netbook Meso [17:57] both running UNR [17:58] woohoo! [17:58] of course there is lots of interest in products based on UNR, so look out for more to be released this year [17:59] Ok, we are out of time, but thank you for attending. [17:59] thanks everyone! [18:00] thank you [18:00] njpatel, repete, bfiller: thanks a lot [18:01] thank you! [18:01] * Keybuk wanders in and fiddles with the projector [18:02] I guess that I just get started [18:02] so, Hello [18:02] I'm Scott James Remnant, and I'll be having a bit of a chat about Boot Performance [18:03] I've not done one of these before, but I'll do my best [18:03] Hi guys. Do you think I can list these 2 bugreports together? https://bugs.launchpad.net/ubuntu/+bug/320105 and https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/319553 the last one happens to be mine. [18:03] sorry! [18:03] wrong room [18:03] I'll try and answer any questions as I go, if they're relevant to what i'm talking about [18:04] and there should be plenty of time for general questions at the end [18:04] ok, so [18:04] boot performance, it's all about making Ubuntu useful to its users quicker [18:05] one of the first things is deciding exactly when you start and stop the clock [18:05] from a user's point of view, the machine starts booting when they press the power button [18:05] and stops booting when things stop moving around on the screen, and the machine stops making a loud disk noise [18:06] which is usually when they feel it's safe to try starting firefox [18:06] unfortunately us geeks know a bit more about what's going on [18:06] and we try and play games [18:06] for a long time, distributions only measured how long it took them to get to the login screen [18:06] and sped that up by starting lots of things after the login screen was up [18:07] (slowing down the login process) [18:07] and now there's a phase of starting things after the basic desktop is visible [18:07] and you hear things like "can we not start that 30s after boot?" [18:07] which is just doing the same again - it makes it slower for the user to use their machine [18:07] Windows tries many of these tracks [18:08] and years of experience has taught users not to touch it while things look like they're still loading [18:08] but then Windows has bugs like it closing the start menu on you ;) [18:08] and Ubuntu doesn't have any bugs like that [18:08] [18:09] :D [18:09] so, really, there's three distinct phases of a boot [18:09] you press the power button, and the hardware starts up and initialises (BIOS, etc.) [18:09] that hands over to our bootloader, and we start up the core operating system [18:09] (kernel, etc.) [18:09] and then we start the X server, and all of your desktop components and applets [18:10] now, we can't do anything about the first one [18:10] that's firmly in the hands of the hardware and chip manufacturers [18:10] but the last two are definitely under our control [18:10] so that's what we time [18:11] but be sure when you hear someone talking about a 30s boot, that they tell you what they mean by "Boot" [18:12] my times start from the boot loader, and end when we have a full desktop up [18:12] I'm hopeful that in the future, as we get better relationships with hardware partners, we'll be able to work closely on the hardware initialisation with them and start the time at the power button where it should be! [18:13] so [18:13] you may have noticed that boot performance has gotten a bit slower over the past 20 years [18:13] my modern, quad-core, all singing and dancing machine takes over a minute to boot [18:14] whereas the ZX Spectrum I had when I was 5 pretty much booted immediately [18:14] well, not quite it had a splash screen ;) -- the screen went white, black, and then white again [18:14] of course, it's not really fair [18:14] those machines had fixed hardware, their Operating System code was in ROM, and they just executed it [18:15] nowadays, not only do machines vastly differ in hardware, even from the same manufacturer [18:15] but users are able to add and remove hardware on the fly [18:15] and will often do so during boot and wonder why things go wrong ;) [18:15] and you can actually upgrade your operating system without a soldering iron [18:16] (someone who had a BBC Micro is going to point out that you didn't need a soldering iron because the chip was designed to come out fairly easily ) [18:16] so yes, we don't boot as fast as home machines of the 80s [18:16] but that's because they didn't really boot at all [18:17] and you can't plug a USB printer into a C64 [18:17] so, I'm going to let you into a little secret [18:17] you can make your machine instantly boot faster [18:17] (or slower, if you're so inclined) [18:18] all it takes is changing one thing [18:18] the disk [18:18] your hard drive is by far the slowest part of your computer [18:19] if one person shows you a boot char on a quad [18:19] oops [18:19] if one person shows you a boot chart on a quad-core machine [18:19] and it's faster than your little laptop [18:19] it's not because of the cores, or even the blue leds on the side [18:19] it's because it has a much faster disk [18:19] and, unfortunately [18:19] the disk is where the operating system code lives [18:20] it's where all your configuration lives [18:20] boot is all about getting things from the disk and into memory [18:20] (and executing them on the processor) [18:20] so, to speed up the boot we need to either: [18:20] 1. load less from the disk [18:20] 2. be more efficient about our use of the disk [18:21] Loading less is the easy one [18:21] We take a good look at everything we do in the boot sequence, and we start being ruthless about it [18:21] How much of this stuff do we _really_ need to do on boot? [18:22] A good example here is a change we made quite early on in Ubuntu compared to Debian [18:22] we used to generate the database of available kernel modules on every single boot [18:22] this involves reading a lot of data, doing some CPU work, and writing it out to disk before using it [18:22] we don't do that anymore [18:22] now we regenerate that database only when you install a new kernel, or a new module package [18:23] and we do it in the package's maintainer scripts so it happens while you're running apt [18:23] it turns out that a lot of things done on boot could really be done during upgrades or software installations === rosset-brb is now known as rosset [18:24] another similar change is looking at whether services could be started on demand [18:24] do we need to start the entire printing subsystem until the user actually tries to print something? [18:25] do we need to start the bluetooth stack that early? [18:25] these are just examples of questions which haven't been answered yet, but that's the kind of thing we look at here [18:25] can we cut down on the amount of data we load [18:25] And secondly can we be more efficient about booting [18:25] this is kinda the same thing, but from a different point of view === max_ is now known as modestMAX === danne_ is now known as danne [18:26] oliver_g_ asked a question about compression [18:26] and it's a good example [18:26] in many cases, if there's a large amount of data to be read off the disk, it's better to have that data compressed [18:26] and decompress it in memory [18:26]