=== zeedo [n=zeedo@80.68.92.188] has joined #ubuntu-devel === LaserJock [n=LaserJoc@lambda.chem.unr.edu] has joined #ubuntu-devel [12:07] Riddell: Kubuntu install CDs up [12:12] Kamion: thanks [12:13] http://king.buildd/%7Ebuildd/livecd/kubuntu/current/livecd.kubuntu.cloop: [12:13] 23:11:21 ERROR 403: Forbidden. [12:13] meh [12:13] lamont: please fix? all buildds I think [12:14] lamont: ah, the problem is that the cloop didn't build, due to this, which is still your bug :-) [12:14] E: Couldn't find package kubuntu-base [12:15] lamont: both Kubuntu and Edubuntu should use ubuntu-base [12:15] infinity: or you, if you're around? [12:20] Kamion: hrm... === lamont goes to fix [12:20] Kamion: while I'm doing that - do you know how to run javascript crap in a manner that gets me error messages when I have syntax errors? [12:21] lamont: tools->javascript console in firefox [12:21] woot [12:21] Kamion: ISTR kubuntu-base got created in breezy, yes? [12:21] lamont, for more serious stuff, download venkman [12:21] lamont, full javascript debugger in xul. [12:22] anyone holding packages for firefox1.5 rc's somewhere? [12:23] sadly, that doesn't show me the errors in my proxy.pac file... [12:25] lamont: AFAIK there was never a kubuntu-base [12:25] lamont: for good reason - it isn't possible to make netboot installs work properly if Kubuntu's or Edubuntu's base system is ever at variance from Ubuntu's [12:26] at least not at present [12:26] LIST="$LIST ubuntu-base ubuntu-desktop ubuntu-live" [12:26] LIST="$LIST ubuntu-base kubuntu-desktop kubuntu-live" [12:26] LIST="$LIST ubuntu-base edubuntu-desktop edubuntu-live" [12:26] great, that's correct [12:26] you are go for launching your builds [12:26] launched [12:26] thanks for the quick fix [12:26] now tell me how to find proxy.pac syntax errors. :-) [12:27] on that, I'm afraid, I am clueless :( [12:27] well, I still need to go really fix the source, etc. [12:27] Kamion: ditto [12:28] neuralis: E: Couldn't find package venkman [12:28] mozilla-venkman | 0.9.85-3 | dapper/universe | all [12:28] (back to hoary/universe) [12:28] lamont, look harder :P [12:28] danke === LeeJunFan [n=junfan@s64-186-37-120.skycon.net] has joined #ubuntu-devel [12:30] neuralis: and this lets me examine the .pac file how? === lfittl [n=lfittl@83-65-243-186.dynamic.xdsl-line.inode.at] has joined #ubuntu-devel [12:31] lamont, you didn't specify proxy.pac as part of your problem until later. venkman lets you "run javascript crap in a manner that" gives you full debug control. [12:31] ok. [12:31] how does it let me do that? [12:32] Kamion: fix committed, it'll be in 0.25 for real. [12:33] after starting it up, it will show javascript loaded across all firefox windows, and allow you to place breakpoints or enable full-tracing and such. i'm not sure it'll help with proxy.pac. [12:36] elmo: please sync smb4k from debian, ok to override ubuntu changes [12:38] Riddell: queued === BenC [n=bcollins@209.163.125.153] has joined #ubuntu-devel [12:38] mdz: I reckon the Flight 1 announcement should go to ubuntu-devel-announce these days. Should it go to ubuntu-users too? [12:39] neuralis: how do I print something in javascript? [12:39] there's nowhere to print to, generally. alert('message') will do a pop-up. [12:40] Kamion: sure [12:40] Kamion: perhaps with a note to subscribe to -devel-announce for the future [12:41] good plan === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #ubuntu-devel [12:45] grumble. myIpAddress() returned 127.0.0.1 [12:46] amd64/server pass [12:48] The autoconfig file can be output by a CGI script. This is useful e.g. when making the autoconfig file act differently based on the client IP address (the REMOTE_ADDR environment variable in CGI). [12:48] but I don't _WANT_ to write CGI === hunger [n=hunger@p54A603EE.dip0.t-ipconnect.de] has joined #ubuntu-devel === lamont successfully avoids cgi again === carbon [n=mybutt@adsl-157-47-190.bna.bellsouth.net] has joined #ubuntu-devel [01:13] Riddell: just a procedural note re http://lists.ubuntu.com/archives/kubuntu-devel/2005-November/000554.html - it's not called flight-1 until it's released [01:16] amd64/install pass === seth_k [n=seth@asmallorange.com] has joined #ubuntu-devel [01:17] Kamion: good point, noted [01:20] Riddell: things are looking good on the Ubuntu side; I've written the release announcement, although I probably won't actually do the release until tomorrow morning now. If you've got basic testing done on all the CDs by then, let me know and I'll release Kubuntu Flight 1 along with it; otherwise I can do it shortly afterwards. [01:20] you don't have to test quite as thoroughly as for preview/RC/final - just basic validation that the image can perform an install or boot to a live session as appropriate will be fine [01:22] I'm afraid my release announcement errs on the duck side of the debate contrary to my personal preference, but only because I found the perfect quote ;) [01:23] Kamion: I don't have anyone to test the ppc disk but otherwise they should all be tested by morning [01:23] Riddell, i can test ppc live [01:23] ok, I'll download ppc install and see if I can give it a go tomorrow morning [01:23] thanks ogra [01:24] ooh, live CDs are up [01:24] ogra: http://cdimage.ubuntu.com/cdimage/kubuntu/daily-live/20051119/ thanks [01:24] i'll try rsyncing a ubuntu live :) [01:24] ah, yes [01:25] ogra: that will help a bit, probably, but not a lot [01:25] a bit is fine ... [01:25] at least more than nothing ;) [01:28] meh [01:28] dapper-live-powerpc.OVERSIZED [01:28] Riddell, ^^ drop some languages :) === anavim [n=avavim@nat1.supportsoft.com] has joined #ubuntu-devel [01:28] says the man whose project has a special exception in cdimage code to let it be larger ... [01:28] lol [01:29] kubuntu/powerpc/live is only 3MB over; no great concern for now [01:45] ogra: what, drop .de? [01:46] heh... i'm fine with .en :) [01:46] noone uses it :) [01:46] Kubuntu ships a *lot* of languages; dropping a couple would not be a problem, and we wouldn't have to go anywhere near the most popular ones [01:46] this sort of optimisation may be best done later though [01:46] well, s/optimisation/tweaking/ [01:48] * Languages: af am as az be bg br bs ca cs cy da el eo et eu fa fi ga gl gu he hr hu ia id [01:48] ^-- list of languages hipped on kubuntu/powerpc/install outside the most popular dozen === ajmitch barely recognises half of those [01:49] er, "shipped" === mpt proposes shipping only those that have complete translations [01:49] that should cut down on plenty of space :-) [01:50] sounds like a good way to ship only one language ;) [01:50] if they are not complete, they might not take much space :) [01:50] now is a bad time to try to execute that metric, though === ajmitch wonders how complete en_NZ is :) [01:50] and, as ogra says, incomplete ones are cheap [01:50] if Microsoft or Apple shipped with incomplete translations, they'd get tomatoes thrown at them, wouldn't they? [01:50] nope [01:51] Apple probably ... [01:52] it depends how you define "complete". our archive contains a hell of a lot more software than either Microsoft or Apple ship; even if you go by what we ship, we have an awful lot of translation domains [01:53] it's hard to compare because Microsoft and Apple don't have the same kind of huge archive of stuff you can grab after the install [01:53] and we don't measure CD-completeness separately? [01:53] we don't measure it at all yet [01:54] Rosetta measures completeness at all [01:54] ok, I didn't know how good its measurements were, but I'm pretty sure it doesn't measure CD-completeness [01:55] in any case I can tell you for free that only one language other than English was even at 100% in the breezy installer [01:55] french ? [01:55] many were very close, but IIRC only French actually made it [01:55] :-( [01:56] Will Dapper's earlier feature freeze mean more time for translation? [01:56] hahahahahaha [01:56] I wish [01:56] *g* [01:56] in any case I don't think more time would have helped; we need better advertisement of what order one should translate things in [01:57] I've been discussing installer translations with Carlos [01:57] we have a plan which should help [01:57] anyway, bed :) [01:57] a lot of random stuff in universe got translated? [01:57] night Kamion [01:57] we have a bug reported on that [01:57] night Kamion [01:57] show which stuff is important first [01:57] g'night Kamion [01:58] https://launchpad.net/products/rosetta/+bug/20 === hunger [n=hunger@p54A6454B.dip0.t-ipconnect.de] has joined #ubuntu-devel === retrix [n=sam@ppp219-41.lns1.adl2.internode.on.net] has joined #ubuntu-devel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-devel === spstarr_home [n=sh0n@CPEdeadbeef0000-CM000039d4cc6a.cpe.net.cable.rogers.com] has joined #ubuntu-devel === jk_ [n=jochem@jkossen.nl] has joined #Ubuntu-devel === Aegir [n=richard@d220-238-232-61.dsl.vic.optusnet.com.au] has joined #ubuntu-devel === jdong [n=jdong@ubuntu/member/jdong] has joined #ubuntu-devel === marcin [n=user@www.e-dev.tele2.pl] has joined #ubuntu-devel === anavim [n=avavim@nat1.supportsoft.com] has left #ubuntu-devel ["Leaving"] === lakin [n=lakin@dsl-hill-66-18-228-60-cgy.nucleus.com] has joined #ubuntu-devel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-devel [03:04] elmo: please sync nvclock from unstable, ok to override ubuntu changes === SloMoSnail [n=slomo@p5487E286.dip.t-dialin.net] has joined #ubuntu-devel [03:50] elmo: please sync rafkill from unstable, ok to override ubuntu changes === powerj [n=powerj@81-233-225-143-no38.tbcn.telia.com] has joined #ubuntu-devel [04:02] g/night all [04:03] Hello fellows! [04:03] Anyone around. [04:03] ?? [04:04] Anyone awake? [04:09] elmo: please sync vile and tse3 from Sid, overriding Ubuntu changes, thanks [04:09] is flight1 out yet? [04:09] elmo, its done, but not out yet [04:09] I woud like some gentoo devs opinions about some new software i wrote.. Anyone around? [04:09] Kamion wanted to announce it tomorrow morning [04:10] powerj: wrong channel [04:10] very wrong channel [04:10] elmo, is it not here you find the ubuntu devel staff? [04:11] crimsun: queued [04:11] elmo: thank you. [04:11] powerj: you mistyped "gentoo" [04:12] Oh, sorry i was thinking ubuntu.. === StoneTable [n=stone@c-24-14-85-48.hsd1.il.comcast.net] has joined #ubuntu-devel [04:13] I am writing an replacement for sysvinit, that boots the system in parraler, and heavy reduces boot time. [04:13] Maby you devs, can tell me a feature list you want to have in a sutch system. [04:13] Things that i missed. [04:14] Have a look: http://initng.thinktux.net/ [04:15] issue has been raised in the channel previously and on the mailing lists [04:16] Ok? [04:16] just letting you know it has been raised. Timeframe is not within Dapper. [04:19] crimsun, do you have any url to the debate on the mailinglist, or an irc log? === spstarr_home [n=sh0n@CPEdeadbeef0000-CM000039d4cc6a.cpe.net.cable.rogers.com] has joined #ubuntu-devel [04:20] powerj: http://people.ubuntu.com/~fabbione/irclogs/ and lists.ubuntu.com [04:21] sorry I don't have them handy [04:23] powerj, http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/thread.html#7410 is one [04:27] mpt, thanks, but these mails are back from may, anything fresh? [04:28] powerj, see http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013072.html w.r.t. Dapper [04:28] Are there any intrest what you know, to include an alternative init system in ubuntu? [04:33] People from linspire distro, walked by my #initng and sad that they are working for a complete switch to #initng, actually i would like to see it if even optionally in ubuntu sience its my default distro. [04:36] That i calually want to say here is that i woud like some feedback, and possibly some directions of what shud be done to my project, towars the integration in ubuntu. [04:37] powerj, I am in no way an expert on the subject, but from what I have read, the plan is to work on simple improvements to the current system for 6.04 (and there's substantial room for improvement in the current system), then do something less hackish than init-ng for Dapper+n, where n is approximately 1. [04:39] see for example http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013021.html [04:39] less hackish than init-ng? === mgalvin [n=mgalvin@cpe-69-205-47-165.nycap.res.rr.com] has joined #ubuntu-devel [04:43] and http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013053.html [04:43] but I have my own work to do now, so excuse me :-) [04:44] mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable. [04:44] mpt, okay thank you for your time. [04:44] If you want to discuss that, the best person to discuss it with would be the Scott James Remnant who wrote that message, aka Keybuk in IRC [04:45] he's the one doing a lot of the work to reduce startup time for Ubuntu at the moment. [04:46] ogra: did you test the ppc CD? === spacey [n=spacey@flits101-191.flits.rug.nl] has joined #ubuntu-devel [04:46] Riddell, just finished [04:47] Riddell, i had only one problem ... there was KDE on my ubuntu ;) [04:47] Riddell, its fine :) [04:47] :o [04:48] whole night messing around with migrating ADS to Samba stuff, i look and feel like a zombie now [04:48] good night [04:48] night spacey [04:48] night spacey :) [04:48] and night world, i'm off as well ... [04:49] see you later [04:49] mpt, thank you, i drop him a mail. [04:51] ogra: great, thanks [04:51] ogra: how come you can't do an install? [04:52] Kamion: kubuntu x86 install/live, amd64 install/live and ppc live all work === apokryphos [n=apokryph@70.85.216.98] has joined #ubuntu-devel === Erlang [i=neumann@toronto-HSE-ppp4001241.sympatico.ca] has joined #ubuntu-devel === magnon [n=co@photogeeks/magnon] has joined #ubuntu-devel [05:07] Can anyone help my with my Ubuntu/Debian dilemma? [05:07] the answer will always be ubuntu === bmonty_laptop [n=bmontgom@wsip-68-15-230-31.om.om.cox.net] has joined #ubuntu-devel [05:09] I can answer the dilemma myself at the end, but I'm looking for a killer p.o.v. somewhere. === robitaille [n=robitail@ubuntu/member/robitaille] has joined #ubuntu-devel [05:34] Erlang: well, you could start by asking a bit more specific [05:41] magnon: I could... I will be updating my system to AMD64 from 32 bit soon and I need to decide between [05:42] Ubuntu and Debian [05:42] I'm a wannabe Debian developer... === jordi [n=jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #ubuntu-devel === hunger [n=hunger@p54A60195.dip0.t-ipconnect.de] has joined #ubuntu-devel === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #ubuntu-devel [05:54] desrt, ping [06:00] well, right now I'd go for Ubuntu. If I think of a reason I could change my mind, I'll come back here. It'll be more productive that way. [06:00] Erlang, no-one can deny the power of the brown [06:01] the brown? [06:02] the brown! [06:02] hmmm [06:03] whats ... that? [06:04] a nice earthy colour [06:05] o_O === wasabi_ [n=wasabi@207.55.180.150] has joined #ubuntu-devel === Aegir [n=richard@d220-238-232-61.dsl.vic.optusnet.com.au] has joined #ubuntu-devel === minghu1 [n=minghua@ppp-70-247-52-142.dsl.hstntx.swbell.net] has joined #ubuntu-devel === mgalvin [n=mgalvin@cpe-69-205-47-165.nycap.res.rr.com] has joined #ubuntu-devel === powerj is now known as powerj|sleeping === powerj|sleeping [n=powerj@81-233-225-143-no38.tbcn.telia.com] has left #ubuntu-devel ["Lmnar"] === Aegir [n=richard@d220-238-232-61.dsl.vic.optusnet.com.au] has joined #ubuntu-devel === freeflying [n=freeflyi@61.190.65.38] has joined #ubuntu-devel === Maskie [n=Marius@c1-30-5.wblv.isadsl.co.za] has joined #ubuntu-devel === Aegir [n=richard@d220-238-232-61.dsl.vic.optusnet.com.au] has joined #ubuntu-devel === LaserJock [n=LaserJoc@c-67-172-161-28.hsd1.ca.comcast.net] has joined #ubuntu-devel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-devel === Aegir` [n=richard@d220-238-232-61.dsl.vic.optusnet.com.au] has joined #ubuntu-devel [07:31] Flaming mother of mercy. My filesystem just exploded... Well, thats one dapper box thats bit the dust. Time to reformat... === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #ubuntu-devel === retrix [n=sam@ppp219-41.lns1.adl2.internode.on.net] has joined #ubuntu-devel === kyncani [n=kyncani@lns-bzn-35-82-250-211-209.adsl.proxad.net] has joined #ubuntu-devel [09:06] what is the default music app on a fresh install? rhythmbox/totem? [09:08] rob1: rhythmbox [09:08] thanks sabdfl === zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-devel === odeez [n=zeedo@80.68.92.188] has joined #ubuntu-devel === Cimmerian [n=crom@80.239.71.231] has joined #ubuntu-devel === freeflying [n=freeflyi@61.190.65.38] has joined #ubuntu-devel === zakame [n=zak@ubuntu/member/zakame] has left #ubuntu-devel [] === pvanhoof [n=pvanhoof@d54C18307.access.telenet.be] has joined #ubuntu-devel === mvo [n=egon@wtli-d9b997cb.pool.mediaWays.net] has joined #ubuntu-devel === ompaul [n=ompaul@213-202-144-104.bas502.dsl.esat.net] has joined #ubuntu-devel === Seveas [n=seveas@ubuntu/member/seveas] has joined #ubuntu-devel === jsz [n=diego@59.Red-80-36-85.staticIP.rima-tde.net] has joined #ubuntu-devel === Hirion [n=Hirion@p5487E286.dip.t-dialin.net] has joined #ubuntu-devel === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-devel === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #ubuntu-devel [10:58] morning [11:00] morning all === martink [n=martin@p54B3999C.dip0.t-ipconnect.de] has joined #ubuntu-devel === OculusAquilae [n=bastian@p548D005D.dip0.t-ipconnect.de] has joined #ubuntu-devel === Seveas [n=seveas@ubuntu/member/seveas] has joined #ubuntu-devel === tvo [n=tobi@5354EA9B.cable.casema.nl] has joined #ubuntu-devel === zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-devel [11:30] powerpc/install fail due to media problems; my current inclination is to say "sod it", Kubuntu powerpc/install has got further [11:31] Kamion: is there any working hfs+ repartitioner? [11:31] (partition/fs resizer) [11:32] zyga: parted in dapper should do it; not parted in breezy [11:32] Kamion: with user interface in the installer? [11:33] (or the livecd) [11:33] try why not try it? [11:33] (excuse weirdness, slow link) [11:33] breezy does not have any user interface for it and I'm not feeling like loosing my data again [11:33] also breezy's parted can resize hfs+ provided that you disable journalling [11:33] breezy sure does have user interface for it [11:34] hmm [11:34] press enter on the Size: field in the detailed page for the partition [11:34] is that interface available in the debian installer? [11:34] YES [11:34] hmm === zyga needs to try again [11:34] (er, sorry, caps lock) [11:34] can the journal be disabled after installation? === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-devel [11:35] of Mac OS? yes, google for instructions [11:35] right [11:35] there are several ways to do it, both command-line and graphical [11:35] Kamion: if I find such instructions they could be patched as an info node into the installer, do you agree? [11:35] (mornin pitti) [11:35] Good morning [11:35] no, I do not agree [11:35] they could go in the installation manual, but they don't belong in the installer itself [11:36] at least a note that they are in the manual (and how to find the manual) [11:36] no, only in the manual [11:36] hmm === xxenon [i=xxenon@81.13.235.57] has joined #ubuntu-devel [11:36] I never knew about the manual really and I think that's something users might struggle with [11:37] I'm not going to burden our translators with having to translate a million links to the manual from lots of places [11:38] it's sufficient to point to the manual up-front at the very start, in the boot screens (we should add that) [11:38] I see, but if the user does not know how to sucessfuly resize their hfs+ volume he might decide not to install, just as I did. A single sentence that points in the right direction (Like: To find out how to resize your hfs+ volume, take a look at the manual on the CD) could help a lot [11:38] is anyone testing 2.6.15 in dapper ? [11:38] I agree [11:39] zyga: that will no longer be necessary in dapper *anyway* [11:39] oh, why? :-) [11:39] because parted in dapper works even if you leave journalling enabled, as I implied above [11:39] or at least so I am told [11:40] ah, then this is a no-issue :-) [11:40] thanks for the information [11:40] indeed [11:40] meh, kubuntu powerpc/install gets further but still dies due to media problems [11:41] well, I have no reason to believe it will break and we've tested most of the individual pieces, so I'll just release it [11:44] zyga: dapper's parted should also be able to handle HFSX (new variant of HFS+ used in very new versions of Mac OS X) [11:44] breezy's couldn't [11:44] Kamion: hmm, 10.4.3? === jk_ is now known as jk [11:46] http://developer.apple.com/technotes/tn/tn1150.html says it was introduced in 10.3; may not be the default, I don't know [11:46] checking [11:48] 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable. [11:48] 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable. [11:49] (d'oh, sorry) [11:50] Kamion: hfsx is a minor modification, it allows for (bah) case-sensitive file names [11:51] yes (I don't really care about the details), but it still requires explicit support in parted because it's a new filesystem type [11:51] (welcome to the 1970 ;-) [11:51] I also have read the technote I pointed you to ;) [12:01] ooh [12:01] when did lists.uc get prettyfied? [12:01] Keybuk: hi [12:02] that was a "hi, I was looking for you, and you're in trouble" kind of hi, wasn't it? [12:02] :> [12:02] no not really :) [12:02] oh, phew [12:02] I had a few questions but they are not important anymore I guess === neuralis [n=ike@83-131-79-231.adsl.net.t-com.hr] has joined #ubuntu-devel [12:03] I'm all ears [12:03] except for the bits of me that aren't [12:03] because I'm not a grasshopper [12:03] ask away [12:03] It was about non-contiguous malloc, one that doensn't suffer from allocation spikes [12:04] I had a discussion with seb the other day [12:05] if you know of any malloc that's better than current one I'm all ears myself :) [12:06] there's about as many malloc implementations as there are nih libcs [12:06] all equally bad at most things :) [12:06] a totally new malloc implementation sounds about as inappropriate for dapper (a long-term supported release) as it's possible to get [12:07] it's not about dapper at all [12:07] damn I confuse you two [12:07] #define malloc mmap [12:07] easy [12:07] hehe [12:07] almost ;] [12:08] Kamion's the Lord of the Dance, and I'm the Queen of the Dancefloor [12:08] oh, where's buffy then? === zyga hides [12:08] that's elmo [12:08] lol [12:10] Keybuk: http://www.suxx.pl/~zyga/malloc-test/ if you know of anything that can survive this please let me know :) === [splinux] [n=[splinux@153.157-136-217.adsl.skynet.be] has joined #ubuntu-devel [12:11] malloc is about the common case as well as stress-tests [12:11] ? [12:11] ah [12:11] sorry I omitted one word and it didn't make sense [12:11] you can also tune malloc for your process too [12:11] there's a bunch of random options to let you rely less on sbrk, and more on mmap, etc. [12:12] programs that really run into pathological behaviour of malloc often use their own allocators; it's not like there aren't loads around :) [12:12] like the apr pools implementation, talloc, etc. [12:12] zyga, have you looked at google's TC Malloc? [12:12] yes there are a multiudue of them [12:12] neuralis: no :> but it already sounds interesting [12:12] zyga, goog-perftools.sf.net [12:12] zyga, blazing fast, plays well with stl and threads [12:13] in-app allocators are basically because standard allocators are more less bad :/ === cassidy [n=cassidy@f1-pc174.ulb.ac.be] has joined #ubuntu-devel [12:14] standard allocators are generally trying to be simple, so that they can be a common denominator; once you start being clever you often end up de-optimising for cases you didn't think of [12:14] malloc works sufficiently well for the most part [12:15] the glibc one is a little more intelligent than just "sbrk to get more space" [12:15] right but the really messy feature of the standard doug lea's malloc is the dependance on sbrk [12:15] it can use mmap but as far as the source says, it's not that smart [12:16] (especially when it comes to free) [12:16] free is over-rated :) [12:16] yeah ;] [12:16] Linux knows better than to believe an app about how much memory it wants [12:16] and it all gets freed when the app closes anyway [12:16] ? [12:17] what about apps that keep runing and running [12:17] for example I've worked on programs that really heavily use mmap, right up to the limits of the virtual address space; an mmap-based malloc would de-optimise for that [12:17] like browsers and damn text editors in most ofices [12:17] the big pages of unused memory won't be mapped [12:17] and they won't page fault because they're not being used [12:17] ? [12:17] so the app "thinks" it has that memory, when the kernel got rid of it ages ago [12:17] Kamion: good reason to switch to 64-bit then :) [12:17] big pages of previously used memory keep being mapped === chris38 [n=bayle@LSt-Amand-152-31-26-96.w82-127.abo.wanadoo.fr] has joined #ubuntu-devel [12:18] "big pages" ?! [12:18] s/big pages/lots of pages/ [12:18] I of course meant lots of [12:18] yeah I was correcting myself there [12:18] :-) [12:18] jamesh: in some cases that was a win, yes (subject to some other considerations), but it was not always quite so simple, especially five years ago [12:18] nod. [12:18] why would they keep being mapped if they weren't used? [12:18] Keybuck: they were used before, that's why they were mapped [12:19] jamesh: frex on the early Opterons it made almost no difference (curiously enough) [12:19] but after they were freed in the program they are still mapped [12:19] I think that's been sorted out since though [12:19] right, but Linux gets bored quite easily and unmaps them from the real memory if they're not actually used [12:19] and puts them to swap [12:19] so they appear in the process map, but don't actually take up real memory [12:19] that's bad IMHO [12:19] it cannot just discard them, linux doesn't know they are 'free' it just swaps them away, right? [12:20] right [12:20] exactly :/ [12:20] why would an mmap based allocator be bad then? [12:20] the cost-per-map is reasonably high, you wouldn't want a new map per 16 byte struct [12:21] you cannot map such small regions anyway [12:21] but a mmap per 1MB makes more sense [12:21] when such chunk gets free it can be really returned [12:21] 1MB is rather arbitrary [12:21] generally a multi-heap design, in the allocator [12:22] it was an example [12:22] mapping anything other than multiples of 4096 bytes is silly ;) [12:22] (I was really thinking about mapping 4MB jumbo pages) === jsz [n=diego@59.Red-80-36-85.staticIP.rima-tde.net] has joined #ubuntu-devel [12:22] right, 4MB is a reasonably sensible (and common) size [12:22] as is 8MB (default stack, iirc) === seb128 [n=seb128@ANancy-151-1-64-250.w83-196.abo.wanadoo.fr] has joined #ubuntu-devel [12:23] each jumbo page could be freed (even parts of it could be unmaped if necessary) === dr88dr88 [n=gerrit@b86143.upc-b.chello.nl] has joined #ubuntu-devel [12:23] ah, but then you have the fun thing === zeedo [n=zeedo@80.68.92.188] has joined #ubuntu-devel [12:23] allocating space on the page according to where it's likely to be /freed/ [12:24] (BTW: this can go away from #u-d if that's not appropriate here) [12:24] as you'd want to deliberately optimise for clearing pages at once [12:24] yesh :) [12:24] run-time data gathering could help [12:24] you wouldn't want to front-fill pages, you'd want to know in advance the memory usage pattern of the program so that data that is commonly freed together is put on the same page [12:24] or an enchanced malloc api like MALLOC_LONG_LIVED flag [12:24] there are compiler thingies that deal with that [12:25] oh? [12:25] I heard about the sun compiler, that it can optimize away some malloc calls [12:25] (but it was only for loops and trivial cases) === seb128_ [n=seb128@ANancy-151-1-3-186.w83-194.abo.wanadoo.fr] has joined #ubuntu-devel === enrico_ [n=enrico@debian/developer/enrico] has joined #ubuntu-devel [12:26] a generic approach, one that could calculate the probability of long-livedness of an object would be better [12:26] it could minimize living objects in mostly empty pages [12:26] (or simply chunk all long-lived objects together) [12:27] there are many many papers and experiments into it [12:27] see Google [12:27] believe me I did [12:27] I tried citeseer too [12:27] maybe I spell badly [12:27] .. === HiddenWolf [n=HiddenWo@136.135.dynamic.phpg.net] has joined #ubuntu-devel [12:28] the "generic" approach is often to use multiple memory pools [12:29] ie. have a "small shit" pool for fixed-sized blocks that you just reuse over and over [12:29] right :-) [12:29] so whenever you need anything less than 128 bytes, you just grab the first unusued block from that pool === zyga is writing another paper on this topic [12:29] and everything in that pool is 128 bytes long [12:29] I was really looking for some exisitng work but all I could find were multi-processor high-end allocators [12:29] you might also have a long-lived pool, for things you know are going to be around for a while [12:30] interesting but useless stuff for the desktop [12:30] sometimes you have a string pool, where you try some wacky stuff to re-use strings [12:30] I have a more generic approach [12:30] I have governors [12:30] classes and instances [12:30] and each governor is assigned to a fragment of vm space [12:30] each can really do what it wants internally [12:31] the trouble with the more complicated approaches is that you sacrifice speed for vsz [12:31] they have pretty simple outside api [12:31] yes I know [12:31] but that's the part of design [12:31] which de-optimises for something that needs to live fast and die young [12:31] to win speed by doing best not to touch swap as long as that's possible [12:31] well the governor init is pretty fast [12:31] optimise for where it's likely to be freed> this is why application-specific allocators are often superior *anyway* [12:31] I'm still not sure about how to do startup [12:32] grep for example needs to just to allocate until it dies from either lack of memory, or finishes (and lets the kernel free up the memory it used) [12:32] app-specific allocators don't span libraries [12:32] memory allocation patterns usually don't span libraries well either [12:32]