=== dendrobates is now known as dendro-afk [03:20] lool: your udev upload to precise seems to include a lot of changes not explained in the changelog, including the disappearance of the entire test/ tree from bzr - was this intentional? [03:29] slangasek: infinity: thanks for taking care of tzdata [03:48] micahg: no problem [04:04] Can someone upgrade this http://bigbrovar.aoizora.org/index.php/2011/05/24/better-clickpad-support-for-ubuntu-11-04/ patch for 11.10 please ? [04:06] http://tinyurl.com/1104patch [04:55] hiii everyone, i want to know how i can become ubuntu developer [04:57] f0x: https://wiki.ubuntu.com/UbuntuDevelopers [04:58] actually michag i am much more noob, i want to know how much programming should i knw to contribute to ubuntu..?? [04:59] f0x: not necessarily much, but it helps (BTW, there are many non-programming ways to contribute to Ubuntu) [05:00] i want to contribute in programming, i will learn stuffs that is needed for it.. [05:01] i knw cmd line prograaming in c/c++, a little bit of python and php too [05:02] f0x: that should be plenty :) [05:02] sure..?? i can start contributing to developing with this mch..?? [05:03] f0x: there are 2 types of components to programming in Ubuntu: packaging and fixing bugs, which would you be interested in (both is fine :)) [05:03] i don't knw if this programming does ever do any important stuffs, [05:06] sorry, was disconnected [05:07] i will like to do both, i am currently reading stuffs on exploitation, buffer overflow and stuffs , i think may be i would learn more in that way too, so both bug finding and programming [05:09] micahg, there..?? [05:09] f0x: sorry, in the middle of dinner, can we chat in a bit? [05:10] sure.. sure, thanks for reply anyway, and please carry on with your dinner, sorry to disturb you in between your dinner :) [06:03] f0x: so, you mentioned C++ and PHP, are there apps in either of those languages that have open bugs in Ubuntu that you use (and would like fixed)? [06:05] after finishing the setup of tools like bzr and pbuilder, what next..?? [06:05] https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings [06:07] * micahg wonders where that new developer guide is [06:08] f0x_: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html [06:10] how is this..?? http://developer.ubuntu.com/resources/ [06:12] that's good information, most of the site is geared towards people who want to make apps for Ubuntu, but there's plenty of good information for Ubuntu Developers as well [06:13] can't find any documentation focused on ubuntu developer's :( [06:15] f0x_: http://developer.ubuntu.com/packaging/html/ [06:15] looks informative [06:18] i think , i will have to start with bug fixing first. [06:19] f0x_: sounds good, feel free to ask any questions here or in #ubuntu-motu [06:20] thanxx a lot micahg , [06:20] f0x_: you're welcome === bryceh is now known as bryce_away === htorque__ is now known as htorque === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [21:01] Anyone know what the current de-facto method is in Linux to hook into the kernel and intercept file system access? [21:01] That's fuse, right? [21:15] bluefoxicy: Depends on what you mean - fuse is for implementing userspace filesystems, so you can certainly hook into a filesystem you *write* [21:26] RAOF: upon executing /usr/bin/chromium-browser, it is recognized that an updated version is available and has been downloaded, that it is a security update, and the update is applied before launching. [21:27] RAOF: upon mmap(PROT_EXEC...), same is done for libraries [21:27] * micahg turns his head towards the chromium update discussion [21:28] bluefoxicy: And you want to work out...? [21:28] RAOF: how to implement that [21:29] because I'm not sure what kernel facility lets me pause exec() or mmap() while i do other crap [21:30] Why would you pause exec()? Wouldn't you just check for updates, download it, and then exec() the new thing? [21:30] maybe you need a LD_PRELOAD library which overwrites the libc calls, like libfakeroot= [21:31] RAOF you'd still need to intercept exec() with another command and possibly tell the kernel not to exec() or to exec() something else so the parent process doesn't return a "not found" error and then 5 minutes later your stuff magically launches [21:31] bluefoxicy: are you trying to implement a new feature here or is this something that exists? [21:31] bluefoxicy: What, why? [21:32] micahg: new feature [21:32] magic management [21:32] RAOF: Because I wrote some silly description of a non-existent Linux distro a decade ago that included all kinds of crazy shit as features and I want to try implementing some of it [21:32] bluefoxicy: You could resolve a longstanding FIXME in the dynamic loader by figuring out how to reload libraries :) [21:33] bluefoxicy: No, I mean why would you need to intercept exec()? [21:33] things like being nigh-invulnerable to certain classes of exploits (Ubuntu has that now, full ASLR and stack smash detection and the like), or having fancy administrative tools [21:33] RAOF how would you do it? [21:33] how would Drepper do it [21:33] just have the application check by itself, and then re-exec [21:34] intercepting exec is massively overthinking the problem [21:34] How would you make a system that detects the execution of a program, makes sure it's up to date before it's executed, update it if not, and do all this seamlessly [21:34] I wouldn't [21:34] Oh, man. That would be a nightmare! [21:34] accounting for any shell, any UI, and any programmatic method ever coded or possible to code into any program attempting to exec() that binary [21:35] I think that's actually a bad idea; you're adding an indeterminate latency to all execute calls. [21:35] Because "makes sure it's up to date" involves hitting the internet. [21:35] probably [21:35] you're underthinking the problem though [21:35] And if it *doesn't* involve hitting the internet, then we've already solve this. [21:36] 1) This would be configurable, and has many ways of being implemented (including grabbing from a local repository in a large network) [21:36] * cjwatson suggests not starting out with a solution statement [21:36] ("intercept execve") [21:36] mmmm, oh yes! [21:36] and 2) "checking" for things being up to date doesn't mean "run apt-get update every time someone calls exec()" [21:37] bluefoxicy: But it fundamentally means "hit the network everytime someone calls exec()" - otherwise you'd just configure apt to check every 15 minutes and automatically install updates. [21:37] (also, the consideration of checking, downloading, installing, etc, has all kinds of error conditions that need consideration, such as what to do if the package isn't downloaded already and the network is not working--obviously, you recognize that, and continue on yourway) [21:37] * cjwatson can think of at least one application where execve is performance-critical - it's spectacularly the wrong layer for this [21:38] shrug [21:38] All I'm hearing is "this can't be done" [21:38] cjwatson: what application is this anyway? Curious. [21:38] man-db [21:38] I think we're saying that this *shouldn't* be done. [21:38] not to mention zillions of little sysadmin scripts [21:38] I don't see how man-db is critical on execve [21:39] I dod [21:39] I do [21:39] besides what's the worst that can happen [21:39] Or, rather, that you should back up and describe the problem you're trying to solve at a higher level. [21:39] it's already the slowest thing in Ubuntu upgrades [21:39] it checks if ls is up to date one time? [21:39] the worst that can happen is that your code to do the checking, downloading, installing becomes a fun target for security exploits [21:39] sorry, but you know, I've actually analysed this. [21:40] execve is an inappropriate place for this, but that doesn't mean that if you back up and start out from a problem statement rather than a solution statement, that you can't still achieve your goal [21:41] I would suggest considering things in terms of applications rather than executables [21:41] how I wish I had web space [21:42] http://img403.imageshack.us/img403/369/screenshotat20111030174.png THIS is from 2003-2004 [21:43] JIT updating and installation is a feature of Windows too isn't it [21:44] I don't believe so, no? [21:44] published applications? [21:44] Published where? [21:44] When you run them they update or install automatically from network media [21:44] it's an active directory function [21:45] you get an icon for Microsoft Word on your desktop, but if you run it Word isn't installed. or it's the new version of word but you have the old version. [21:45] That might be why I don't know it. [21:45] but when you run it, the new version runs, installed or not. [21:45] there's a big difference between having a system that causes selected applications to auto-update/install and doing it for every executable [21:45] you could do the former today with a wrapper script, quite seasily [21:45] *easily [21:45] whoa [21:46] Korean [21:46] what? [21:47] you could do the former today with a wrapper script, quite s[korean]easily [21:47] er, no [21:47] it was probably some lag-induced representation of a backspace [21:47] 日本語 が じょ ありません。 [21:48] anyway [21:49] http://0install.net/ this is still interesting. [21:51] cjwatson: I seem to recall a guy that told people he was going to make buffer overflow vulnerabilities completely elective in about 2 months time [21:51] that was in August 2001 ... he got laughed at if I remember right. [21:52] in October 2001, he released PaX, which implemented a NX bit on i386 and a security policy that limited buffer overflows to causing program crashes. [21:52] right, but it doesn't follow from that that everything that is criticised is correct :-) [21:52] There are things that can be done, and there are things that haven't been done. [21:52] cjwatson of course not [21:53] but it does seem to be a design pattern that every significant invention is said to be impossible or at least a very bad idea before it's done [21:53] confirmation bias [21:53] I don't think that's true at all. [21:54] (if that implication holds, it doesn't hold the other way round) [21:54] the light bulb. Batteries. Radio. [21:54] Right. You don't see the vast majority of bad ideas which go on to become... bad ideas. [21:54] A computer fast enough to make use of more than 32 megabytes of RAM in any meaningful way. [21:54] * cjwatson would not be inclined to compare himself to Marconi, even by implication [21:55] Man in space. Government. [21:55] I'm not familiar with all of those, but were any of the actually considered to be impossible or a bad idea? [21:56] Radio was not only considered to be impossible (communications at a distance), but also repeatedly considered impossible WHILE IN USE [21:56] you're seriously advancing this as a defence of your idea? [21:56] it's the cold-fusion defense [21:57] the lower frequency bands were the only bands for a while. FM radio operates over a garbage band that's impossible to make use of. VHF is completely useless because it breaks down out of direct unobstructed line of site and doesn't reflect off the ionosphere. Same with UHF. [21:57] a working implementation would be a better defence [21:57] again and again with radio lol... [21:57] * cjwatson tends to take the IETF line on this - rough consensus and running code [21:57] cjwatson: no, I just think it's worthwhile arguing that many good ideas are killed or just an uphill development battle because the vast majority of the world doesn't believe in them :P [21:58] it's an utter fallacy though [21:58] people are less interested in how to achieve a goal than they are in why that goal is unachievable [21:58] and it's a waste of time [21:59] if you seriously think it's a good idea, and don't think it's worthwhile listening to others, then just do it [21:59] to the point that some ideas have faced such scrutinty in the past by which very rich folk have spent lots and lots of money campaigning against them because they're ridiculous, only to have some hack make it work and also have the market find out the end product is the most useful thing in the world at the time. [21:59] ee what happens [21:59] *see (gah, lag) [21:59] People don't spend money campainging against things which they consider impossible. [22:00] but you can't expect to persuade other people by comparing yourself to the inventor of radio - if people dived head-first into every crazy idea that came along, they'd never have time for anything else :) [22:00] Global warming, solar power versus the clean coal industry, there's a lot of people out there saying solar/nuclear/whatever doesn't work or is too far off or has hidden problems. [22:00] And if you *made* this work - or semi-work - then people would be more likely to take it seriously. [22:00] (though that's mostly business and politics) [22:01] ideas that are demonstrated to actually work, by means of a real implementation, have a better chance of people paying attention to them; that's an excellent filter [22:01] heh [22:01] anyway this tangent has gone too far [22:01] I guess the only working hook is LSM [22:01] We don't, in general, have a shortage of good ideas; we've got a shortage of implementor-time. [22:02] RAOF: I've always got a shortage of implementor-time :P [22:02] but that's what happens when people have day jobs [22:02] I was a lot more useful when I didn't have a job :( [22:05] ah well. Maybe I'll do something easier, like write a stock market analysis program that implements pivots and strength/weakness arcs. [22:10] cjwatson: could you slap zinoviev for not git tagging his console-setup uploads? :) [22:10] if he ever came on IRC I would :) [22:11] drat :) [22:16] micahg: FWIW, my reading of the xine-lib changelogs you quote is that the situation in natty was exactly the same as now; which doesn't mean we shouldn't fix it, but I don't think siretart's recent merge changed anything [22:16] cjwatson: I am tired, maybe I misread, looking again [22:17] cjwatson: ah, indeed, I took the don't build against system libs to mean don't build :(, but 1 new library was added [22:17] * micahg will double check and then send a followup mail clarifying [22:18] cjwatson: thanks :) [22:18] are you sure? he said "remove build-dependency on libvcdinfo-dev", which to me means probably building against the internal version [22:18] ah, yes, probably... [22:19] I guess a diff would be worthwhile to make sure, but it looks like four either way [22:20] * micahg is doing that now [22:29] cjwatson: verified that the same libs are being used (at least as far as the rules file goes), apology E-mail sent [22:38] hey, can anybody here tell me why sensible-browser doesn't detect the default system browser in oneiric? And what to use instead to open urls in the default browser? [22:40] sbte: xdg-open? [22:41] micahg, that works with http:// prefixed indeed [22:42] but most applications do use sensible-browser or x-www-browser, and I think it was handled correctly in natty [22:43] we really should standardize on something, but I think that needs to happen in Debian first [22:43] x-www-browser is alternative based so that usually will not DTRT [22:45] sensible-browser should I guess. The webbrowser module in python seems to use it through the default url-handler for http which is set to sensible-browser %s [22:47] sbte: sensible-browser defaults to alternatives, seems to be used to pick one out of a list of browsers passed to it and use what it finds or fall back to an alternative [22:48] micahg, so maybe /desktop/gnome/url-handlers/command should be set to the xdg-open %s? [22:50] micahg, do you know if xdg-open is installed on all gnome based systems? gnome-open seems to be the default, but it's not installed on oneiric at least [22:51] not sure, it seems to be installed on most Ubuntu systems though [22:54] * micahg will be back later