[00:55] kees: while trying to merge ipsec-tools I got this error - cc1: warnings being treated as errors [00:55] policy_token.c: In function '__libipseclex': [00:56] kees: http://paste.ubuntu.com/11039/ [00:56] kees: is this related to the new hardening flags ? [00:57] mathiaz: https://wiki.ubuntu.com/CompilerFlags <- -D_FORTIFY_SOURCE=2 seems to be relevant here. [00:59] james_w: thanks :) [01:05] Who is it that actually decides what goes onto the Ubuntu CD, and how do us mortals go about understanding (and potentially altering) their reasoning processes? [01:05] As opposed to universe etc. [01:08] <_MMA_> The Tech Board and or Desktop team I believe. [01:08] <_MMA_> And nothing from Universe goes on to the disks. [01:09] not true [01:09] _MMA_: well - it depends which iso you're refering to [01:09] xubuntu is in universe [01:09] <_MMA_> Oh jesus. Nit-pick. He said Ubuntu. ;) [01:10] hehe [01:10] <_MMA_> So :P [01:10] * Amaranth pokes _MMA_ [01:10] _MMA_: it was true that nothing from universe could be on the cd. But this has been changed during the last release cycle so that xubuntu, ubuntustudio and other derivatives can be built [01:11] ubuntustudio is in main, no? [01:11] No. [01:11] Its the primary reason that universe packages can be on disks. [01:11] most of it is :P [01:11] <_MMA_> mathiaz: I'm sorry. You obviously don't know who you're talking to. [01:11] The reason I'm asking is that to some extent the remote recovery issue is about defaults and policies rather than optional components, and I'd like to understand a little about that side of the process. [01:12] <_MMA_> andrew___: I think people like Colin are the best resource for that. [01:12] <_MMA_> A post to ubuntu-devel-discuss might be in order. [01:13] There've been a few on the issue already :) [01:13] what, specifically, do you want changed? [01:14] Well, I'm still going through the understanding stage... [01:14] I've been bugging anyone that will listen for the past few days about ways to do better tech support for friends. [01:15] andrew___: technically, a ubuntu-core-dev has to make a change to the seeds - so you'd have to convince a core-dev to make that change. [01:16] core-dev has access to the seeds? [01:16] How do they tend to feel about new packages getting accepted into main? [01:16] <_MMA_> No. It's not that simple. It is a team decision. [01:16] Amaranth: yes [01:16] andrew___: To get a package into main you have to file a main inclusion report [01:16] Do they prefer packages that are small, or well established, or well-maintained...? [01:16] andrew___: then you need to talk to the relevant team [01:17] if it's in main it should be well maintained and have no crazy security issues [01:18] andrew___: https://wiki.ubuntu.com/MainInclusionProcess [01:19] Thanks - I think that's what I needed to know. [01:19] that page is no longer valid [01:19] Or at least, it'll shut me up for another few hours :) [01:19] not everything in main is supported by canonical [01:20] Amaranth: huh - that page is still valid IIRC [01:20] the steps are right, the reasons are not [01:20] Amaranth: what do you refer to by 'supported by canonical' ? [01:23] commercially supported by commercial support people, commercially :) === foka_ is now known as foka [01:31] <_MMA_> mathiaz: ie: There are things in Main you can't get paid support from Canonical on. [01:34] _MMA_: im sure if you name the right price you can? [01:36] hmm, compiz runs a LOT slower with DDR-533 unmatched sticks of RAM [01:36] on the GMA950. [01:36] time to revert this setup [01:37] gma950 uses RAM? [01:37] pwnguin: GMA950 uses only RAM [01:37] pwnguin: it has no dedicated graphics RAM [01:37] <_MMA_> pwnguin: Who knows. I haven't talked to the support guys enough to know. [01:37] im sure handing off hard stuff to the CPU doesn't help [01:38] pwnguin: so I guess having dual-channel interleaved RAM is important [01:38] double throughput is important -- 3d stuff is very bad at caching [01:39] oddly seems like Firefox is the only major offender [01:39] hmm [01:40] * TheMuso has never liked shared RAM. [01:40] lots of pixmaps in ff [01:41] anyone here willing to help me debug a kernel-related suspend/resume problem on 2.6.24-17 on Hardy? It appears to be scheduler-related, but debugging it beyond what I can see in the log is a bit tricky. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/212660 has details -- the short version is that suspend/resume last worked properly on 2.6.24-12 for me. [01:41] Launchpad bug 212660 in linux "kernel 2.6.24-16 fails suspending" [Undecided,Confirmed] [01:41] vlowther: You may get more help in #ubuntu-kernel. [01:42] heh, did not know that channel existed. [01:42] I will ask there. [01:43] TheMuso: that assertion is tenous at best [01:44] vlowther: you may get better help in the ubuntu-kernel mailing list. [01:45] pwnguin: indeed. [01:46] as far as i can tell, the ubuntu kernel team uses IRC to communicate with other ubuntu kernel team members, and anyone else's best hope is getting ogarasawa's attention =( [01:47] pwnguin: ? [01:47] TheMuso: i'm just suggesting that i see unanswered calls for attention plenty in that channel. [01:48] wn that case, why bother with a public channel at all? [01:48] pwnguin: Right. [01:49] well, this channel is the same way, really [01:50] except nobody says "go to ubuntu-devel for bug help", that I know of [01:57] well, I come here because people only want to look at easy things on #ubuntu [02:20] _MMA_: do you have example of such packages ? [02:20] _MMA_: got an example? [02:20] hahahahahahahaha! [02:20] * mneptok bops mathiaz on the nose [02:24] I did before hardy [02:24] maybe that's changed now, i dunno [02:24] Amaranth: examples of unsupported packages in Main? [02:25] yeah, xubuntu stuff :P [02:25] uh .. [02:25] fark you, too. ;) [02:25] *smewch* [02:25] * mneptok beams brightly at Amaranth [02:25] * Amaranth gets confused [02:26] do i have someone on ignore? cuz this isnt making sense =/ [02:26] Amaranth: you had me wracking my brain for Main packages i didn;t think of. [02:26] and then ... "Xubuntu." [02:26] pwnguin: same here ;-) [02:26] there is no support for Xubuntu. [02:26] any pacakges. at any time. [02:27] so the slap was for making me start to actually think ;) [02:27] I believe there are other packages in Main Canonical doesn't support [02:27] and Xubuntu is in Universe now right? [02:27] LaserJock: do you have an example? [02:27] LaserJock: 'cos i don't [02:27] well [02:27] i'm not saying i couldn;t have overlooked something. [02:28] do you have a list of things Canonical *does* support? :-) [02:28] packages in Main. [02:28] a short list of vital Universe stuff. [02:28] that's it. [02:28] (slmodemdaemon, when that was in universe) [02:29] Main/Universe is not how Canonical support is defined [02:29] it is here. [02:29] how interesting [02:29] mdz said it wasn't [02:30] and I would think he'd know [02:30] LaserJock: like i said, it doesn;t break out exactly along repo lines [02:30] sure [02:30] LaserJock: but we still use repo names to define things [02:30] like "a few critical packages from Universe" [02:31] mneptok: and some Main packages that aren't supported ;-) [02:31] i know of none [02:31] i await an example. [02:31] (not to make that sound like a stupid challenge) [02:31] (I presume a support contract w/ Canonical overrides component lines anyhow.) [02:32] well, is abiword and gnumeric supported? [02:32] yes. [02:32] you sure? [02:32] *blink* [02:32] well, stupid question [02:32] but I wasn't aware that it was [02:33] all fourteen users of both apps are entitled to support. [02:33] * mneptok runs [02:33] overall I'm not sure that Canonical knows what's supporte [02:34] +d [02:34] we do not fully support anything with a non-Free license [02:34] as we cannot guarantee resolution [02:34] sure [02:35] *with* a free license, it basically breaks out along repo lines, but with some exceptions. hence mdz's comment. [02:36] personally, i'd like to stop supporting GUI environments and server daemons. when i mentioned it, sabdfl asked me to wait in the lobby for the adults to finish their conversation. [02:37] If I allow untrusted users SSH access to an account on my computer, where the account is in a chroot jail, they can only run a specific command I specify (not a shell), and remote and X11 forwarding are disabled (but local forwarding is enabled), have I compromised the security of my computer in any way? [02:38] mneptok: well, there have historically been examples like Xubuntu [02:38] Xubuntu != Ubuntu [02:38] so? [02:38] Canonical Support offers commercial support for Ubuntu, Kubuntu, and Edubuntu [02:39] For bandwith challanged users, it'd make sense to just download the compressed differences between an old package in the apt cache and a new version of a package. Could an rsync method driver to apt be a solution, for instance? [02:39] <_MMA_> mneptok: re: "Example packages" when Xubuntu went to Universe there was a big chat in here and people like Matt Z. Colin and Scott R. mentioned a good few I believe. Besides the previously mentioned Xubuntu packages. Making a list of unsupported packages was mentioned but I don't know if anything came of it. [02:39] right, but Xubuntu was in main and dragged in quite a bit [02:39] _MMA_: Xubuntu is not supported. therefore, its packages, regardless of repos, are not supported. [02:39] right [02:40] _MMA_: it's not that "stuff in Main is not supported." it's that "Canonical only supports certain variants" [02:40] <_MMA_> Sure. But that was under contention at the time. [02:40] but you asked for packages in Main that aren't supported by Canonical [02:40] <_MMA_> No. I don't think it's that cut and dry either. [02:40] or did I get the question wrong? [02:40] LaserJock: Main/Xubuntu is not the same as Main/Ubuntu [02:40] <_MMA_> As I said others had examples. [02:41] mneptok: so? [02:41] so, when you say "Canonical supported stuff in Main" it assumes a variant that actually has support. [02:41] <_MMA_> I want to get jackd back into Main to be able to build PulseAudio packages that can work with JACK. I doubt that will get support from Canonical. [02:42] mneptok: when people say "Canonical provides support for Main" it implies that *all* of Main is supported, right? [02:42] hi5: Isn't that what jigdo does? [02:42] andrew__: I don't think so, but i might be wrong [02:42] LaserJock: Canonical provides support Main packages on supported platforms. [02:42] LaserJock: therefore, if you install a Main package on Sid, no dice. [02:42] that's more for dividing iso files into .debs and recompiling afaik [02:43] mneptok: Canonical provides support for most of Main on supported platforms [02:43] it doesn't provide 32/64K diff from one .deb to another [02:43] and it's not for apt [02:43] however, I again don't know that it matters much [02:45] <_MMA_> LaserJock: At one point I thought on ubuntu.com it wasn't as clear as that. Hence all the confusion about Xubuntu. [02:45] <_MMA_> I think a bug was even filed. [02:47] _MMA_: the website says "The main distribution component contains applications that are free software, can freely be redistributed and are fully supported by the Ubuntu team" [02:47] <_MMA_> bug 172672 [02:47] Launchpad bug 172672 in canonical-website "http://www.canonical.com/projects claims that Xubuntu is supported by Canonical" [Undecided,New] https://launchpad.net/bugs/172672 [02:48] <_MMA_> Looks like it's been fixed. SHould close the bug. [02:52] one should note that the Ubuntu team and canonical are not identical sets [02:52] Re:rysnc method driver for apt. The context of this can be anything from people over sat connections, 3rd world countries (like iraq where there is no fiber, or copper backbones/lines since the ground is so hard it's almost impossible to run it so everything is expensive sat. based), or saving bandwidth / speeding up updates 1000x for all users / saving money to run repos. Are there no thoughts? [02:52] pwnguin: exactly [02:53] what goes in main is independent of Canonical [02:53] hi5: Depends how much work you're planning to put in. [02:53] though it certainly works well for Canonical to use Main to define support [02:53] andrew__: Well, I've spent days getting enough info to formulate that question properly. [02:54] hi5: Yeah, I know that feeling :) [02:54] hi5: so this means you're doing investing time, or does it mean you're in it for the long haul? [02:54] Annoyingly, people's response of "bandwidth is cheap" is highly beside the point, and innacurate for most of the non-western world. [02:55] hi5: What's the average size of the binary diff between two versions of the same package? How does it differ between packages? How does that compare to the diff between source packages (a la Gentoo)? [02:55] if you're merely looking for counterpoints, CPU time isn't cheap either. [02:56] andrew might have a point -- .debs are compressed and may not make good rdiff candidates [02:56] So I'm pretty invested in this. I should note that I've receive many responses to contact the various devel lists however I'm not a developer. Hence my apprehention about contacting a dev list which a.) may not care b.) would be annoyed I'm just a (l)user [02:56] However, after much research it appears no such solution exists... which is very surprising to me considering how obvious this seems [02:56] (even to a new user) [02:57] it may seem obvious, but the solution is definitely non-trivial to implement. [02:57] As to (b), I'm not much more than a (l)user myself. If they start picking on us, we should unionise ;) [02:57] awaiton: Why? nobody has been able to tell me why? [02:57] im not familiar with how rdiff works, but it may require a non trivial amount of disk space [02:57] hi5, better idea: try it. realize just how hard it really is. [02:58] doesn't it take quite a bit of CPU on the server as well? [02:58] hi5: I'm not sure of the technology details, but here's a thought experiment based on how I would expect it to work: [02:58] LaserJock: indeed [02:58] oh dear [02:58] Imagine a 10MB binary split into 1024 10KB chunks... [02:58] Well, real-time decompression of binaries on the server end, and similar on the client end mean you dont't need 20x the server space i'd think [02:58] but that was a theoretical concern i also had [02:59] though, hdd space is still cheaper than bw for a repo's purpose [02:59] I'm fairly sure the current servers basically out of space [02:59] if there's fifty versions you might upgrade from [02:59] Version n+1 of the file inserts a single byte at the front of the first chunk.... [02:59] this causes every single chunk to appear different, and need to be re-downloaded. [02:59] ideally, packages would be distributed over something like bittorrent, where you don't care so much about compression and on-disk space, but focus on the perfect reproduction of the file and various locations of retrieval. at least, IMO. [03:00] if you imagine having to house diffs for all packages for all versions it can be pretty significant [03:01] LaserJock: wikipedia is enlightening [03:01] awaiton__:no offense, did you even read my post? [03:01] basically, it's compute intensive because it network computes the diff [03:02] Seriously, empathise with someone outside of your country for a moment.. bit torrent doesn't solve a bandwidth issue for a single node. It merely distributes it among many similarly bandwidth endowed nodes [03:02] hi5: wouldn't a CD be just as / more effective? [03:02] pwnguin: yes, i can see that being a minimal issue [03:02] "minimal" [03:02] pwnguin: a cd would not be effective [03:03] hi5, the best way I can sympathize with you is to say, I don't want you wasting any bandwidth on bad downloads [03:03] a cd as a compromise would be a tad bizarre to me in fact [03:03] that "minimal" issue of CPU use very well may kill servers on upgrade day [03:04] take one server and add a couple hundred / thousand users and bam, instant problem [03:04] pwnguin: almost for sure [03:04] bittorrent is designed so files don't 'fail' during download. time sensitivity can come from using the absolute best compression available (something like lzma), but using something like binary diffs is almost never a good idea due to just how tricky they are to get to work... [03:04] so, this avoids the topic at hand doesn't it? [03:04] I think those are administrative issues, and ones that aren't impossible to deal with [03:04] what? [03:04] cpu load vs bw load [03:04] CPU is an administrative problem? [03:04] etc [03:04] hi5: but you wondered why it hadn't been implemented [03:05] that's one very good reason [03:05] First, less defensively folks, is there consensus that this isn't implemented somewhere? [03:05] that's for you to answer. but I doubt it. [03:05] It seems many people say "use jigo" or "debian already does that" and such [03:05] I'm not aware of anything like that for binaries. [03:05] ive seen about a billion attepts at alternative apt transports [03:05] i think i saw an apt-rdiff [03:06] http://www.tjansen.de/debiff/ comes to mind [03:06] Source downloads are a different matter, because that's a much easier problem to solve. [03:06] i know ive seen an apt torrent [03:06] pwnguin: same [03:06] someone tried apt over bittorrent before, but it was pretty poor :/ [03:06] awaiton__: there's better alternatives to that too. it works fine for me ;) [03:06] the idea wasn't bad though, it's just hard to make work. [03:06] agreed [03:07] binary diffs on the other hand, are almost impossibly hard to make work on a widescale. [03:07] the BT problem is one of availability -- you need to be able to trade chunks across packages [03:07] hi5: If you don't mind trading a lot of CPU for less bandwidth, how do you feel about downloading source and compiling it? [03:07] pwnguin, that's not such a hard problem once you realize you have a captive set of mirror servers across the globe to act as seeds... [03:07] ah, a good point about client end cpu [03:08] seems then patching would be possible via using deb-src? [03:08] I still think it's not apple-apples though. Compiling an OS, vs cpu use for making diffs of binaries is not comparable [03:09] hi5: thats not at all the point though. the point is you're asking ubuntu and mirrors to spend massive CPU on behalf of users, and he countered with a scenario where the user spends instead ;) [03:09] well, bandwidth bills are already an issue [03:10] kinda [03:10] a lot of university institutions donate to the cause ;) [03:10] so, i don't see why a bandwidth -> cpu tradeoff would be so unheard of [03:10] you might be better off with the postal system if bandwidth is that big of a problem... [03:10] hi5: more fundamentally, I'm not sold on rdiff substantially improving the bandwidth problem [03:10] hi5: Usually since it's CPU hit on both ends of the pipe. [03:10] right, but donate != free [03:10] it's still costly [03:11] just not costly to someone on a wester DSL line [03:11] (again, a tradeoff does exist) [03:11] there is no free lunch [03:11] hi5: And server administrators tend to not like process that constantly chew CPU. [03:11] canonical offers something close with the CDs though ;) [03:11] The claim being made is that binary diffs are a hard problem. You can accept that, or explain what you're not understanding about the problem, or go and prove everyone wrong, but (without wanting to be rude), just dismissing the claim doesn't work. [03:12] hi, anyone here who knows about that broken ubuntu alsa configuration? [03:12] andrew__: the claim being made is unsubstantiated [03:12] andrew___: i think that IF you managed to undo the ar compression on packages, you'd probably see some great gains in bandwidth [03:12] hi5, google it. do some research into the issue. [03:12] so without being rude (which you are) it's not helping me. besides, this isn't my personal pet peeve. i'm trying to help [03:12] i don't think many ppl understand this [03:13] hi5: as a challenger to the status quo, and a champion of the under championed, you'd be well off to substantiate the opposite [03:13] i've seen this topic brought up many times before, and it's odd how there's a peculiarly hostile reaction to it. sorry for being new, i just don't understand why this issue sticks out like a sore thumb [03:13] hi5: I believe the Canonical sysadmins have said that it'd probably be too CPU intensive with what we have now [03:14] if all rdiff/rsync does is transfer modified blocks, compression is likely to nuke that idea in hurry [03:14] laserjock: I appreciate the response, and I've been trying to figure out if that's the case [03:14] hi5: people *have* looked into this issue and it's not that we're saying "it can't be done" but just that "it's probably not feasible at this time" [03:14] does anyone know if the alsa drivers got recompiled for ubuntu hardy or are they just taken from debian? [03:15] although there are significant other concerns about some techniques [03:15] mrec: whats the version of alsa? [03:15] hi5: In fairness to you, there is an issue that this doesn't scratch the itch of many developers, because they tend to be behind fat pipes (or they wouldn't have been able to learn enough to become developers). [03:15] laserjock: interesting [03:15] andrew___: I honestly don't know that that's totally true [03:15] andrew___: yes, this is part of my aggravation. if i had dev skills, i'd work on this. I'm actually reading "Computer Programming for Dummies" right now sadly [03:15] I know of devs on dialup [03:15] if i get the skills, i'll work on this [03:16] pwnguin: that's a good question... [03:16] LaserJock: I'm in Australia, which is worse. [03:16] hi5, that's probably why you don't appreciate just how difficult it is, no offense. [03:16] hehhaha [03:16] it annoys me how selfish and unempathetic ppl can be (no offense to anyone here, it's a general sentiment i get though sometimes) [03:16] I cannot compile external modules against the ubuntu hardy kernel because the alsa headers seem to be out of sync with the binary files [03:16] awaiton__: well, i don't know if you appreciate how easy it can be [03:16] hi5: on the other hand, you'd be surprised I think at how unselfish and empathetic people can be [03:17] hi5, I've done binary patching before, I can tell you just how hard it is. [03:17] whoever build that kernel didn't know what he did [03:17] calling people selfish and unempathetic strikes me as arrogant, on the other hand ;) [03:17] hi5, it's especially not trivial when you realize just how many users there are, how many different versions are in the field, and how hard quilting binary diffs is.. [03:17] built* [03:18] hi5, if it were trivial, it would have been done years ago, and thusly not an issue. [03:18] hi5: I think you need to be reading a book on statistics rather than programming, actually. If you can show that debiff will reduce bandwidth by X% and increase CPU usage by Y%, we can have a proper debate about whether it's worth it. Until then, we're all just hand-waving. [03:18] *not be [03:18] awaiton__: andrew__: well, i can appreciate the science and bit swapping of binary comparisons a lot [03:19] hi5: andrew is right. if you can demonstrate that rdiff is a win or at least a substantial tradeoff, you'd have far fewer opponents. and possibly a few volunteers [03:19] however, tools for doing this already exist it seems [03:19] so it's not like the wheel needs to be reinvented. so i consider some of those points red herrings [03:19] well, without implementation, statistical theory is pulling numbers out of my arse [03:19] i need a test bed [03:19] and i'm trying to build one! [03:19] hi5, just because a peg exists, doesn't mean that it necessarily fits the whole... [03:20] *hole [03:20] right, that's a platitude [03:20] not a response to the problem at hand [03:20] think about it this way: ever had to downgrade a package? [03:20] lol [03:20] yes [03:20] it's a PITA [03:20] pwnguin: just confirmed, switching from 1x2GiB + 1x1GB @533MHzz --> 2x1GB @667MHz made a HUGE difference in GUI performance [03:20] hi5, think about doing a reverse binary patch. [03:20] :) [03:20] jdong: is anyone surprised? ;) [03:20] pwnguin: I sure am [03:21] pwnguin: I didn't expect noninterleaving RAM to have such a big performance impact as to make compiz UNUSABLE [03:21] jdong, pwnguin: As am I. [03:21] I mean, it scrolled at 3 lines a sec in Firefox [03:21] you upped the MHz, and dual channeled it [03:21] hi5: this is a very rough methodology, but try this: check the version history for all the packages in Ubuntu, and see how often they're updated... [03:21] pwnguin: it was dual channeled [03:21] pwnguin: just not interleaved (striped) [03:21] what? [03:21] andrew__: i'm listening [03:21] pwnguin: popular benchmarks "cited" a 5% difference in performance [03:22] pwnguin: what I saw was more like a 75% difference [03:22] jdong: popular benchmarks use gma950 now? [03:22] Then download the current and last-but-one version, compute the diff, and divide by the number of days between updates... [03:22] pwnguin: popular benchmarks OF the GMA950 [03:22] jdong: that sounds seriously broken [03:22] ajmitch: idn if it's an EXA bug or what [03:22] That should put you on the road to a very rough number for bandwidth saved/day. [03:22] ajmitch: OS X felt the same speed [03:22] just Ubuntu crumbled without matched RAM [03:23] Then you publish that, it gets ripped to shreds for being unscientific, you come up with a better methodology, and after half a dozen iterations, people start agreeing with you. [03:23] then calculate the average frustrated user who got smited by a bad binary patch vs. the average user's anger of having to wait a few extra minutes for a package... [03:24] awalton__: wait for the numbers. The conclusion might be something that nobody expects. Like, 90% of bandwidth goes on OpenOffice, and splitting that into yet more packages would cut bandwidth in half. [03:24] (keeping in mind, of course, that the user who got bitten by a bad binary patch now has to download the whole package over again, or hope their file system does automatic revisioning.. or hope for a miracle of some other kind) [03:25] jdong: how do you dual channel sticks of differing size? [03:26] pwnguin: the access to RAM is distributed across to both channels independently, but they are not interleaved (i.e. striped) [03:26] pwnguin: from what I understand on Intel dual channel and interleaving are not the same [03:26] hmm [03:26] ive only got AMD, this may explain things [03:26] pwnguin: the AMD K8 memory controller might treat the situation much differently [03:27] heh, in my experience, i cant boot incompatible ram [03:27] if they wont interleave, it wont boot =/ [03:27] the hidden horrors of on-core memory controllers -_- [03:27] hi5: I already have that methodology licked: it doesn't account for the popularity of each package. Multiplying by the results from popularity-contest will give you a (decidedly biased) way to deal with that. [03:27] awalton__: its' a fairly good win too in a lot of cases [03:27] hmm [03:27] pwnguin, oh of course. [03:28] pwnguin, just not the panacea that everyone makes it out to be... [03:28] as far as compiz performance difference goes, can more than one process render at once? [03:30] if not, then the idea that dual channel non interleaved should be fast might block right there =| [03:31] pwnguin: I'm not sure. It could also be Compiz or EXA doing something underneath that is bandwidth intensive on RAM [03:31] pwnguin: because clearly OS X coped with it fine, just Ubuntu whenever Firefox is visible slows down to like 15fps [03:31] you mean like rendering to a texture and then rendering again? [03:32] pwnguin: I'm not sure, I don't nearly understand enouhg about the backend to make that judgement [03:32] pwnguin: but at any rate, my 3GiB setup finds happy home in a mobility radeon x1400 system :) [03:32] pwnguin: at the same time I had both systems open, I also transplanted an ipw3945ABG into the macbook [03:32] which shall be interesting :D [03:33] how do you transplant a wifi chip? [03:33] pwnguin: both are mini-PCIe [03:34] pwnguin: it was a straightforward swap minus fidgeting with antenna connectors [03:34] wait, do any macbooks ever come with ipw? [03:35] pwnguin nope. [03:35] heh [03:35] pwnguin: so I've created a transvestite mac. I think. [03:35] "osx sucks, my wireless card works fine in linux!!" [03:35] jdong: a frankentosh [03:36] pwnguin: lol currently, wifi support in OS X is a TODO [03:36] (wow, how many times do you get to say *THAT*?) [03:36] I had a friend who build a mac from refurb parts [03:36] sit in the osx86 rooms, you'll see it a lot.. ;) [03:36] awalton__: true [03:36] he mentioned that "it mounted into an ATX case just fine after drilling a few holes in the mobo" [03:40] pwnguin: Surely other changes would have had to be amde to the back of the case for connectors etc? [03:41] i have no idea, i didnt question him too hard after that [03:41] heh right. [03:41] even though it was on the floor and apart, i had seen it working previously [03:41] we built and debugged nachOS on it [03:42] heh, surprisingly Macs have been pretty standard PCs for years. [03:42] the newer ones are even close to ATX inside.. [03:42] awalton__: The mac pros? I woulln't think they were. [03:42] wouldn't. [03:43] TheMuso: they are pretty similar to server xeons [03:43] "pretty standard" would not be the phrase that would come to mind [03:43] TheMuso: at least the one that I peeked inside [03:43] they're close.. the mountings are a bit off, but I managed to put a normal PC board in mine [03:43] I had to put it back together when IS&T gave me a stare for disassembling a public terminal [03:43] they have an x86 chip in them, yes. But so does your washing machine and the space-shuttle booster rockets [03:43] sheesh! [03:43] i recently saw a similar minded, though less capable, person who had affixed an apple logo sticker to an acer laptop [03:44] people [03:44] then again I love apple's hardware, so I probably stick out... [03:45] I'd use them exclusively if I weren't kentucky poor... [03:45] you know, ive had to help look after some macs at a community college, and they don't hold up well [03:46] but perhaps im comparing university lab use to my own standards [03:46] mine have.. well, with the exception of the stupid frat kid who thought it would be a good idea to shatter my iBook's LCD... [03:46] the powerbook I had before it held up to some pretty severe torture though [03:47] pwnguin: we have a lab that's all kerberized Macs and they hold up very well from both a software and hardware point of view [03:47] it's okay [03:47] it's decent hardware, not the best, not the only decent ones [03:48] * jdong has a 1 year old macbook that's holding very well to constant abuse [03:48] well outside the halls of MIT we have to deal with the evils of preferred vendors [03:48] my condolences. [03:48] pwnguin: lol we to. 50% HP 40% Dell 10% mac [03:48] ever heard of atipa? [03:48] gesundheit? [03:49] exactly [03:49] :) [03:49] hi5: I don't suppose you could have a community of people that lack bandwidth who collectively keep a memory stick current? [03:49] i dont think its coincindence that atipa spelled backwards is "a pita" [03:49] So, I've just helped someone unbreak their 3d in #ubuntu-bugs because they installed the fglrx-control package, thinking that it would be awesome. [03:50]