[01:11]  * TheMuso sighs. Redhat writing their own init daemon.
[01:11] <TheMuso> Or Lennart is at least.
[02:01] <psusi> who was it that maintains udisks?  got an interesting problem with dvd+rw... it seems udisks is confused by the fact that a blank dvd+rw is not "blank" so it just ignores the media and the drive vanishes from nautilus
[02:16] <imbrandon> TheMuso: i thought fedora ( and rh by proxy ) used upstart ?
[02:17] <TheMuso> imbrandon: they do
[02:18] <imbrandon> TheMuso: hum, then that is diserning
[03:26] <respire> ideas for ubtuntu
[03:26] <respire> some guy made a script called rmkernel, it deletes unused kernels since they hog space its very simple
[03:27] <respire> ubuntu should do it on boot and if nobody used a kernel for a week ask them if they want to delete it or to never ask again
[03:27] <respire> (skip with timeout)
[03:28] <respire> also there was this program i saw that was supposed to help delete unused ubuntu programs
[03:28] <respire> it was awful, rubbish a total failure
[03:28] <respire> im prepared to help and in fact mostly write a replacement if someone else will too :)
[03:41] <respire> why is there no services config tool for the sysv stuff
[03:41] <respire> you could make a gui for that easy
[03:52] <psusi> pitti, finally got those logs you asked for in bug #558926
[04:44] <George_E> Hey, just wanted to thank everyone for making Ubuntu 10.04 a tremendous success!
[04:44] <George_E> You guys rock!
[04:46] <George_E> Lucid boots in literally 10 seconds on my computer - compare that to Vista which takes > 5 minutes.
[04:56] <jdong> George_E: glad to hear! believe it or not there's STILL room to improve with our bootup sequence!
[04:56] <George_E> Really.... I didn't think that was possible. Well, keep up the good work. Love the new look too!
[04:57] <jdong> George_E: http://jdong.mit.edu/~jdong/ureadahead-pack.svg this image is a semi-accurate look at the files being accessed while booting, on a fresh Ubuntu Lucid setup
[04:57] <jdong> George_E: so... once we figure out a way to "defragment" (move all those files to one spot on disk), you can expect another speedup
[04:58] <George_E> Oh good. Also shutdown time is wicked fast. Vista takes around 1:30 - 2 minutes to shutdown... :(
[04:59] <virtuald> on a fresh install?
[04:59] <George_E> Well... not exactly.
[04:59] <jdong> virtuald: yeah, I did 3 more fresh installs just to verify
[05:00] <jdong> George_E: well we should actually give Vista a bit of credit for the bootup/shutdown systems
[05:00] <George_E> How so?
[05:00] <jdong> George_E: Vista actually has an AI algorithm for placing blocks on disk next to each other to minimize seeking
[05:00] <jdong> George_E: and Windows has had a parallel bootup (like Upstart does for us) since NT.
[05:01] <jdong> George_E: the reason Vista is slow is likely because it's close to 20GB while we're 2GB or so altogether...
[05:01] <jdong> if you normalize to that size discrepancy, I bet Vista is achieving faster MB/s disk reads at bootup
[05:01] <jdong> though that doesn't excuse its monstrous size
[05:01] <George_E> Vista has a lot of legacy support too. That has an effect on startup time.
[05:02] <jdong> it loads a lot more services too
[05:02] <jdong> but I do feel their bootup and application launch systems are somewhat "smarter" than us, though now we've got most of the tools needed to catch up
[05:02] <jdong> as soon as the EXT4 defragmentation API stabilizes a bit more, we're in business
[05:02] <George_E> Yes. Ext4 is a nice step forward.
[05:02] <jdong> that graph was generated with data from our existing bootup accelerator (ureadahead)...
[05:03] <virtuald> so you're working on bug 1 :)
[05:03] <jdong> so we already KNOW exactly which blocks needs to be moved together
[05:04] <George_E> ubottu: Haha. That is a *real* bug.
[05:06] <virtuald> jdong: does this affect ssd's at all (performance wise)?
[05:07] <jdong> virtuald: it certainly does...
[05:07] <jdong> virtuald: SSDs have some minimal block size which is fairly large, sometimes as big as a couple hundred KB's
[05:07] <virtuald> o.O
[05:07] <jdong> virtuald: the smallest unit you can ask it to read is a "block"
[05:07] <jdong> so if you've got a bunch of text files that have configuration data stored everywhere on the disk...
[05:07] <jdong> you might be reading WAY more data than you really need to
[05:08] <virtuald> i see
[05:09] <jdong> so I think a combination of good placement on disk + proactive/predictive prefetching into cache is important for everyone
[05:10] <ion> jdong: And after that, reordering blocks based on post-boot usage patterns as well. :-)
[05:11] <jdong> ion: yup indeed.
[05:11]  * George_E is not so sure SSDs are all they're cracked up to be :)
[05:11] <jdong> George_E: they're expensive and kinda sorta band-aid our current seek performance grief
[05:11] <jdong> George_E: but I honestly don't see any reason why everyone needs to be moving to SSD's
[05:12] <jdong> George_E: I think optimally, SSDs should play a role like ZFS's L2ARC cache hierarchy
[05:12] <jdong> where fast SSDs sit in front of a slower but larger HDD pool
[05:12] <jdong> and a good replacement algorithm selects the best data to place in the SSDs
[05:14] <George_E> They have benefits (lower seek times, etc.) but they're not perfect (slower write times, etc.).
[05:15] <jdong> George_E: huge cost disadvantage, larger block size, uneven wearing issues, unproven reliability track record, and so on :)
[05:16] <George_E> The uneven wearing issue is my biggest concern. (And a concern with all flash-based devices)
[05:16] <jdong> George_E: yes and the algorithms that take care of that seem to nullify quite a bit of the SSD performance advantage over time
[05:17] <temugen> jdong: as an L2ARC the reliability/wearing wouldn't be as much of an issue if replacement were easy
[05:17] <temugen> of course that doesn't justify the cost factor any more
[05:17] <jdong> temugen: and hopefully the L2ARC algorithm wouldn't be finicky to keep replacing its contents :)
[05:17] <George_E> If you need fast access to non-system data, you can always use a ramdisk... but for system use... hmmm.
[05:18] <jdong> George_E: well the ramdisk effect is what RAM caching is supposed to do
[05:18] <jdong> George_E: the L2ARC would be a second level of cache that sits between RAM and mechanical disks
[05:18] <George_E> True. Though it's only on a small scale.
[08:12] <Damascene> hi, joaopinto
[08:13] <joaopinto> hello Damascene
[08:14] <Damascene> did any one add a session about the vte issue?
[09:00] <TrueTom> Is there a way to offer the installation of a package based on an udev event / newly pluged-in USB device?
[09:03] <RAOF> TrueTom: That's a fine question.  I'm pretty sure the answer is “yes”, but you'd need to write the udev rule.  A logical place to put a generalisation of this code (if it isn't there already) would be Jockey.
[09:12] <Damascene>  /j #launchpad
[09:33] <TrueTom> RAOF: Hm, the "branding" of Jockey suggest to only use it for proprietary drivers... I want to install 'irda-utils' when an USB-IrDA device is pluged-in, which would look weird since it's free...
[11:24] <switchgirl> anyone found a fix for Bug 569543
[11:24] <switchgirl> it's very urgent
[11:50] <switchgirl> well?
[11:50] <switchgirl> i guess not
[11:55] <jpds> !weekend
[11:56] <mdke> switchgirl: that could be bug 552227 - there is a workaround described in the comments there, give it a try and mark your bug as a duplicate of that if it works
[11:57] <mdke> switchgirl: if it's not the same, then you'll need to wait for the developers to fix it unless you can find a fix yourself
[12:00] <switchgirl> mdke, umm i tried deleting the couch
[12:00] <switchgirl> nothing happened
[12:01] <mdke> switchgirl: this was the workaround I had in mind - https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/552227/comments/55
[12:02] <mdke> switchgirl: not sure if it's the same issue you have or not though
[12:22] <switchgirl> mdke, no it's not i can auth facebook
[12:22] <switchgirl> not do the next step
[12:22] <switchgirl> ie not create the account
[12:22] <switchgirl> same with twitter
[12:22] <switchgirl> not with flikr
[12:23] <switchgirl> i use google dns
[12:45] <mdke> switchgirl: I wondered if the cause might have been the same. Anyway, I don't know much about gwibber so can't help further
[12:46] <switchgirl> ok mdke where can i poke the dev's?
[12:47] <mdke> switchgirl: you can try #ubuntu-desktop during a working day, I guess. But it's one among many other bugs so if you don't have a fix, you'll have to be patient
[12:48] <switchgirl> mdke, its a buggy anoying thing for fresh install's of ubuntu that loads are coming across
[12:48] <mdke> switchgirl: there are plenty of such bugs, I'm afraid. We have 85000 bugs, with over 1000 ascribed with "High" importance
[12:50] <mdke> gwibber seems to have quite a few crashes unfortunately
[12:59] <switchgirl> mdke, i dunno whyit was included in the 10.4 release then
[13:04] <kklimonda> because it's linux and now windows. we include stuff that mostly works and let users help test it. (my personal opinion, probably noy an official one ;) )
[13:05] <kklimonda> and not*
[13:33] <mdke> kklimonda: not really - the focus of a long-term support release like this one is stability. Probably the reason is that gwibber mostly works for those people who tested it
[13:39] <kklimonda> mdke: is it realle stability? I know it's supposed to be but the amount of changes (or maybe their nature) that has been pushed into this LTS says otherwise. it does seem to me that we use users as testers, which I personally don't mind. gwibber mostly working (because it does work for me most of the time indeed) looks like an example - users are going to test it and we'll have more data to fix
[13:39] <kklimonda> it in the 10.10 release.
[13:40] <imbrandon> yes its really stability , there will always be cases that arent caught, change != not stable
[14:55] <joaopinto> kklimonda, I agree with you, there were a significant changes on this release which increase the likely of problems, but I don't see how it could have been done better, not keeping the release goals and schedule
[14:56] <joaopinto> it has been stable for most people involved in the development phase
[16:36] <joaopinto> anyone noted a bug report about the gnome theme randomly failing to be set on the first login ?
[16:54] <Bernardo> hi all
[16:55] <Bernardo> I am trying to port the patches for the poulsbo drivers and xorg 1.7.x from mandriva to lucid, but I am stuck initializing DRI. Anyone can help me?
[17:22] <imbrandon> Bernardo: you might try #ubuntu-x ( and durring the week for even better response )
[17:36] <Bernardo> imbrandon: thanks!
[17:37] <imbrandon> Bernardo: np
[17:38] <anil> Hi All
[17:38] <anil> this is my first time here
[17:38] <anil> I wanted to know, if Ubuntu 10.04 LTS now support Indian Languages natively? Thanks
[17:39] <anil> Also any GUI builder recommended for ppl coming from Windows Dev to Linux Dev? Thanks
[17:45] <joaopinto> Hello anil, the best channel for support in #ubuntu :)
[17:46] <imbrandon> anil: as far as the dev gui builder try monodevelop ( sudo apt-get install monodevelop ) but there are lots of them
[17:50] <anil> thanks Imbrandon and joapinto
[17:50] <anil> sorry got into the wrong room
[17:50] <anil> Cheers!
[17:50] <joaopinto> anil, check the quickly project, I personally don't recommend monodevelop, my tests shown itsn't not stable
[17:50] <joaopinto> erm, gone
[17:50] <joaopinto> or is it quicky
[17:50] <imbrandon> quickly
[17:50] <joaopinto> ops :)
[17:51] <imbrandon> but monodevelop isnt stable ? really ? i use it every day without issue
[17:57] <joaopinto> imbrandon, go to help, search for ()
[17:57] <joaopinto> the last time I have tried it crashed, the bug is open for more than 1 year :)
[17:58] <joaopinto> I didn't test run it on lucid yet
[18:03] <Laney> works here
[18:04] <joaopinto> ok, time to check it, maybere there is an usable RAD tool now :P
[18:10] <joaopinto> Laney, thanks for testing
[18:10] <joaopinto> time to close the bug
[18:14] <joaopinto> still not stable, 1 minute to find a new bug, http://www.ubuntu-pics.de/bild/55823/screenshot_002_3WwGI6.png
[18:15] <joaopinto> on a plain solution creation wizard
[18:16] <joaopinto> imbrandon, http://www.ubuntu-pics.de/bild/55824/screenshot_003_9BOWZ8.png <- I am missing something at the top :) ?
[18:17] <joaopinto> am I...
[19:18] <BAKTUN> Help! Ubuntu 10.04-64.bit - exFAT driver link please. My English is not good. Please Help.
[19:21] <MachinTrucChose> hiya
[19:22] <BAKTUN> Do not help me?
[19:22] <MachinTrucChose> Not sure if this is the right channel to discuss Ubuntu suggestions. Is it? I'm trying to gauge the feasability of something.
[19:22] <MachinTrucChose> and I don't think the people in the main channel would be the sort to udnerstand the technical difficulties
[19:24] <micahg> !brainstorm
[19:25] <MachinTrucChose> that's probably for the better, yeah
[19:28] <MachinTrucChose> is the brainstorm account list separate from the ubuntuforums one?
[19:28] <MachinTrucChose> evidently
[19:28] <MachinTrucChose> allright thanks for your help
[21:18] <xaver__> Hello all, hello Keybuk i have the problem with mountall too. I tryed to use your fix (2.15~ppa1) but nothing changed :( I use 64bit kubuntu, i tryed the standard kernel and 2.6.33 and i use cryptdisks-early. At the moment i use the whorst fix (dpkg --force-depends -i mountall_1.0.2_amd64.deb). The Problem startet with the update to 2.14.