| abogani | persia: Do you have kernel-team's ml subscribed? | 13:41 |
|---|---|---|
| persia | abogani: I don't, but I occasionally read archives | 14:33 |
| abogani | persia: Ok. So I CC you in my next email. | 14:33 |
| persia | Why> | 14:33 |
| persia | ? | 14:33 |
| abogani | persia: About kernel replacement for -preempt (which is died). | 14:34 |
| persia | No need to cc: me | 14:35 |
| persia | I think we all reached a sensible consensus on IRC | 14:35 |
| persia | And I think that the people who care (you, apw, rtg, ogarasawa) all have a common undrestanding. | 14:36 |
| persia | The email discussion is just for the record, isn't it? | 14:36 |
| abogani | It is also about packaging. | 14:36 |
| abogani | persia: ^ | 14:36 |
| abogani | In any case I think to have done a good job. | 14:37 |
| persia | How about the packaging? Wasn7t the agreement to use one git tree and just pull two source packages from it, for the different flavours? | 14:37 |
| abogani | persia: I have done a better job: My (source) package is weight only 2.3 MB. That approach require a full copy of linux source code. | 14:38 |
| persia | I know. | 14:39 |
| persia | I don't currently have the willpower to make a huge fuss at the kernel team about the horrid ways they package,. | 14:39 |
| persia | I'm becoming increasingly convinced that the vanilla source ought be packaged and produce headers and a source, and all the flavours should build-dep on that source and apply patches. | 14:40 |
| abogani | persia: What exactly I have done in my package. | 14:40 |
| abogani | persia: In any case I'll propose to UKT a working package: choice is theirs. | 14:41 |
| persia | But the kernel team has the way they do things, and for all it's not ideal, I think it7s probably better to work with that method for the social integration value rather than do it the packaging-clean way. | 14:41 |
| persia | This doesn't make me happy, but it's a long, hard fight to make it sane, and it will be easier to have that dicsussion later, once you are integrated as part of the teeam. | 14:41 |
| persia | Your choice, really. I think that they will prefer to continue with their solution, for all that it's not as clean as it could be. | 14:42 |
| persia | And I think there's a better chance for you to be part of UKT if you're doing things their way, rather than suggesting alternates. | 14:42 |
| * abogani is really starting to think to isn't part of that Team. | 14:44 | |
| persia | So, for all that I agree with you technically, I'm unsure it's the best social path, or the fastest way to get to the eventually correct technical solution. | 14:44 |
| abogani | persia: Convert to the "stupid duplicate linux source code" method require to remove 3 lines in my patch. So I can switch in any moment. | 14:45 |
| persia | That makes it easy :) | 14:45 |
| abogani | if *they* want. | 14:45 |
| persia | My recommendation would get it uploaded including the stupid duplicate source code, and then apply the 3-line patch as a later update "to improve archive quality" or some such. | 14:45 |
| persia | That saves the discussion for *after* the users have been served. | 14:45 |
| abogani | I never obtain something in this way because all postponed things are ignored completely (when they think that the jos is done they close mind and ears). | 14:52 |
| abogani | I'll propose the smart package. If someone show complaints about it I'll switch immediately. | 14:53 |
| persia | OK. | 14:54 |
| * persia tends to make lists of unfinished stuff, and tries to address them later, in order to allow for staged implementations, because most people fear change | 14:55 | |
| abogani | Some news about kernels: | 14:56 |
| abogani | 1) linux-rt will be updated by smb soon (I hope) | 14:56 |
| abogani | 2) Probably we'll have got a low latency kernel for i386 and amd64 and we'll can use it as default for Studio | 14:56 |
| abogani | 3) I would want rename old -rt into -realtime | 14:56 |
| abogani | scott-work, ScottL, rlameiro, jussi : ^ | 14:57 |
| rlameiro | thats great news | 14:58 |
| rlameiro | why the renaming abogani ? | 14:58 |
| abogani | rlameiro: I would want change approach in the realtime kernel maintenance and I would want let users notice it. | 14:59 |
| rlameiro | ok | 15:00 |
| rlameiro | is it the hardcore realtime patch? | 15:00 |
| abogani | rlameiro: -rt and -realtime are the same kernel with the same "hardcore" realtime patch. | 15:01 |
| rlameiro | ok then, i dont see any problem with that then, -realtime can be more persuasive | 15:02 |
| rlameiro | altough i would like to stress the possible need of having 2 kernels installed if you are using a laptop, since rt harcore is very power hungry :D | 15:03 |
| persia | -realtime is not appropriate for the vast majority of our users. | 15:04 |
| persia | The only folks that need it are those who are pushing the absolute limits of their hardware (for Studio) | 15:04 |
| persia | -realtime is much more interesting in other contexts (VoIP server, industrial process monitor, robotics, etc.) | 15:05 |
| rlameiro | persia: not only studio, you need realtime if you are performing on show with eavy processing (my case) | 15:05 |
| persia | rlameiro: You fall into that minority who are pushing the limits of their hardware. | 15:05 |
| scott-work | abogani: what kerenl version is the -rt based on? | 15:05 |
| rlameiro | persia: yes i know, but that minority is not only studio, that can be misleading | 15:06 |
| persia | rlameiro: By "Studio" I mean Ubuntu Studio, rather than use in a studio. (note the capital S) | 15:07 |
| rlameiro | and there is alot of people using laptop for effects and gigs recording so if you use ubuntustudio, usually you would like to use some of them | 15:07 |
| persia | Sorry for the confusion. | 15:07 |
| rlameiro | ahhhhhh] | 15:07 |
| rlameiro | ok | 15:07 |
| abogani | scott-work: 2.6.31 in Lucid and 2.6.33 in Maverick. | 15:07 |
| persia | I know lots of folks who do recording (even with some effects) using the -generic kernel with success. it all depends on hardware/filter relations. | 15:07 |
| rlameiro | well, the idea of 2 kernels is if you are working on hardcore audio you boot with rt, elese boot with generic for genpurpose usage | 15:08 |
| scott-work | i have had respectable success using -generic kernel to record on a P4/2.3 ghz machine (granted I was only recording two inputs max at a time) | 15:08 |
| * rlameiro is thinking on the help/wikis piling up to do after delivering the thesis.... | 15:09 | |
| abogani | scott-work: -lowlatency works better than -generic and it is equally rock-solid. | 15:09 |
| persia | rlameiro: Right, but my point is that we don't want to suggest most folks use -realtime. -preempt is sufficient. | 15:09 |
| * persia agrees with abogani | 15:09 | |
| * abogani agress with persia | 15:09 | |
| persia | rlameiro: Those few folks who *need* -realtime should use it, and I am glad it's available, but... | 15:10 |
| rlameiro | persia: for sure that is in line with my statement | 15:10 |
| scott-work | *me agrees with abogani and by association agrees with persia | 15:10 |
| rlameiro | have 2 kernels and only use rt when strictly necessary | 15:10 |
| * scott-work fail | 15:10 | |
| persia | rlameiro: And that should be best practice, indeed. | 15:10 |
| rlameiro | so maybe at install time rt kernel should never be put as the default boot | 15:11 |
| persia | Note that there's a side issue with DKMS, that makes it annoying to do that, because one needs to find a way to make sure modules are built for all installed kernels. | 15:11 |
| rlameiro | on grub | 15:11 |
| persia | It hasn't been since Hardy, and I don't believe we're changing that. The current plan for Maverick (as I understand it) is to have abogani merge -preempt and -lowlatency into a single -preempt, and have that default for the install. | 15:12 |
| rlameiro | abogani: is it plausible that in the next future mainstream kernel have the RT capabilities and be started on the fly? | 15:12 |
| rlameiro | like only use RT when we need? | 15:13 |
| persia | That's far future. | 15:13 |
| * rlameiro admits i dont get kernel stuff deeply... | 15:13 | |
| rlameiro | sad... | 15:14 |
| persia | Short term, we need different kernel sources. | 15:14 |
| persia | Medium term, realtime will be selectable at compile time | 15:14 |
| rlameiro | well at least we have it, others doesnt have kernels for that | 15:14 |
| persia | I've heard of plans to make the scheduler selectable at runtime, but that's an interesting issue (how do you maintain context over the switch) | 15:15 |
| rlameiro | and hopefully longterm it will be hardcoded into the main kernel and fired up when needed :D | 15:15 |
| abogani | ehhhh | 15:15 |
| persia | Well, kinda, but not really. | 15:15 |
| rlameiro | maybe using flags on the sofware startup... | 15:15 |
| * rlameiro is dreaming to much | 15:15 | |
| abogani | rlameiro: :-) | 15:15 |
| persia | It may be possible, long-term, to have a userspace utility that can switch between realtime and non-realtime, and use a wrapper around stuff, but by that point, I hope we don't care. | 15:16 |
| rlameiro | persia: for instance puredta by default doesnt use rt capabilities, but if i run it with "-rt" it will use it :D | 15:16 |
| persia | rlameiro: That's entirely different. That's about the RT capabilities in the kernel, rather than about whether the kernel scheduler is actually realtime. | 15:17 |
| rlameiro | persia: at that point we wont need realtime anymore, the kernel will absorb it already :D | 15:17 |
| persia | All modern kernels have RT capabilities, so you can do very tight scheduling, if you request it. | 15:17 |
| rlameiro | persia: i know, i just wanted to ilustrate a possible switching technique | 15:17 |
| persia | That said, it's usually soft realtime, so you end up missing by microseconds. | 15:17 |
| persia | That's not how it would work. | 15:18 |
| persia | Hard realtime vs, soft realtime isn't something you can switch on a per-process basis. it can only be for the entire system. | 15:18 |
| rlameiro | or maybe having a wrapper like $rt ardour-gtk | 15:18 |
| persia | Hard realtime typically imposes an overall performance penalty, in exchange for improved reliability of scheduling. | 15:19 |
| rlameiro | well, that may be true, but even with rt posibilities not all software use it | 15:19 |
| rlameiro | most of them are unaware of that | 15:19 |
| persia | Soft realtime fails to have perfectly reliable scheduling, but with better performance. | 15:19 |
| persia | This isn't fixable: it's the nature of how it works. | 15:19 |
| * abogani notice than persia is really well informed. :-) | 15:20 | |
| rlameiro | i would like to try the soft scheduling on 192khz recording | 15:20 |
| scott-work | but what is the order of magnitude in the delta between soft and real time? | 15:20 |
| persia | scott-work: In what sense? | 15:20 |
| scott-work | time? | 15:20 |
| abogani | scott-work: Don't exist. | 15:20 |
| persia | overall time-to-complete-a-process or time-between-desired-process-start-and-real-process-start? | 15:21 |
| scott-work | that shouldn't have been a questions on my part | 15:21 |
| * abogani would want let you noticed than lowlatency/preempt will be a great kernel. It have only a little more power consumption so for laptop users it is still suggest to use -generic when they working on battery. | 15:21 | |
| persia | rlameiro: 192kHz means that you have 5microseconds per sample. | 15:21 |
| rlameiro | persia: i know :D | 15:21 |
| persia | rlameiro: So, if you use soft realtime, you'll end up losing samples if you try to do too much processing. If you use hard realtime, you'll end up losing processing if you try to do too much. | 15:22 |
| rlameiro | on full duplex you get 2.5uS | 15:22 |
| persia | No. | 15:22 |
| persia | the entire point of jack is to be sample-accurate for N channels. | 15:22 |
| persia | So within an individual timeslice, there's no per-channel scheduling. | 15:23 |
| rlameiro | yeah | 15:23 |
| persia | That said, you may have to monitor your time-to-complete-the-filter vs. number-of-channels. | 15:23 |
| rlameiro | well i did recordede in 192khz on the 9.10.. | 15:23 |
| persia | If it worked, it probably didn't matter if it was hard realtime or soft realtime | 15:24 |
| rlameiro | persia: hard realtime kernel | 15:24 |
| rlameiro | it matters if you have 8 audio inputs at the same time | 15:24 |
| persia | Because if you go overlimit on processing availability in either case, you get artifacts. | 15:24 |
| persia | depends on your codec, amount of CPU requirements for the codec, number of cores, etc. | 15:25 |
| rlameiro | you need to clear the audio buffres really fast and for that you need a tight schedule | 15:25 |
| persia | If you have an external firewire audio interface and a multicore machine, it likely doesn't matter. | 15:25 |
| rlameiro | yes i have... busted | 15:25 |
| persia | If you have such a device, you'll do better with soft realtime, as your interface (should) be buffering, and you're just pulling samples off the firewire network, so throughput should be more important than schedule. | 15:26 |
| rlameiro | well anyway, the idea is to advice for the generic kernel, then having the lowlatency kernel as a second choice and only if the user wants have the -realtime kernel isnt that? | 15:27 |
| persia | If you are using an AC'97 codec or other CPU-intensive AD conversion, you'd need hard realtime. | 15:27 |
| persia | No. | 15:27 |
| persia | For Maverick, we'll recommend -preempt, and have -realtime available for folks who need it, and -generic for folks who care more about battery life than performance. | 15:27 |
| rlameiro | abogani would want let you noticed than lowlatency/preempt will be a great kernel. It have only a little more power consumption so for laptop users it is still suggest to use -generic when they working on battery. | 15:28 |
| rlameiro | so do we need to diferentiate laptop users and desktop? | 15:28 |
| rlameiro | is it possible to do on the alternate install? | 15:28 |
| scott-work | that is something i have been thinking about because they have appreciably divergent needs | 15:29 |
| * scott-work is catching up on backscroll now | 15:30 | |
| scott-work | persia, abogani: my questions was somewhat rhetorical, i'm thinking that with new, faster machines and improved kernel code that the possible differences between -hard and -soft might not be appriciable for most people | 15:32 |
| * abogani never use the term "soft"... | 15:33 | |
| rlameiro | abogani: i think he is refering to the aproach of the kernel config | 15:34 |
| rlameiro | soft beeing more conventional | 15:34 |
| rlameiro | hard with hard config plus patches | 15:34 |
| abogani | I totally miss the point. | 15:35 |
| abogani | Could we speak about *user requirements* instead of *soft vs hard* ? | 15:36 |
| rlameiro | maybe scott-work is trying to point that as the hardware become better the need for realtime kernels decreases | 15:36 |
| rlameiro | or the generic can do better... | 15:36 |
| persia | abogani: By "soft" realtime I mean a non-realtime kernel attempting to satisfy scheduling requests made with RT_CAP | 15:37 |
| abogani | rlameiro: I don't agree: people surely find a way to use the new power. | 15:37 |
| rlameiro | abogani: i was trying to disect scott-work statement | 15:37 |
| persia | People will always need to be able to choose between optimising for performance vs. optimising for schedule reliability. | 15:37 |
| rlameiro | i am sure i would find a way to use the power :D | 15:37 |
| scott-work | there is a hard limit to all kernel achievements in scheduling (you can consider this to be perfect physics in a vacuum or textbook if you like) | 15:37 |
| persia | But for our purposes, as devices become more powerful and more distributed, we care less. | 15:38 |
| scott-work | the ignio's patch gets us most of the way there i believe | 15:38 |
| scott-work | but we will keep making improvements in other methods until the delta isn't appreciable (in a newtonian's method) | 15:38 |
| scott-work | this, i believe | 15:38 |
| scott-work | sorry that i'm talking like yoda, i keep getting interrupted today | 15:40 |
| scott-work | i've been looking into the ardour mute bug #581786 | 15:41 |
| ubottu | Launchpad bug 581786 in Ubuntu Studio "Mute button not enabled by default in Ardour 2.8.6 Lucid AM64" [Undecided,New] https://launchpad.net/bugs/581786 | 15:41 |
| scott-work | and i need some advice from those who are knowledgable in packaging and bug fixing | 15:41 |
| scott-work | the problem seems to stem from the ardour.rc file which shows several mute options with "yes", which does not parse well | 15:41 |
| scott-work | s/ardour.rc/ardour.rc.in | 15:42 |
| scott-work | these get written to the users home directly as "0" in an ardour.rc file | 15:42 |
| scott-work | i made a patch in my ppa which corrects this BUT the existing ardour.rc file in the user's home needs to be deleted or renamed first for it to be effective for new projects in ardour | 15:43 |
| scott-work | someone on #ubuntu-motu suggested using a wrapper script since maintainer scripts shoudl *NOT* touch home, but a wrapper script (if careful) could | 15:43 |
| scott-work | before going any further, is this a solid methodology (the wrapper script adjusting settings on home directory)? | 15:44 |
| persia | I prefer not to do that | 15:44 |
| abogani | I hate sw than to that. | 15:44 |
| persia | I prefer to set defaults correctly, and tell users who have already the wrong default to adjust it manually | 15:44 |
| persia | otherwise we risk the chance of overwriting the choice of a user who deliberately set it that way. | 15:45 |
| abogani | it is the right way. | 15:45 |
| rlameiro | persia: do you know when is due 10.04.1? | 15:45 |
| persia | Not offhand. Schedule should say. | 15:45 |
| persia | https://wiki.ubuntu.com/LucidReleaseSchedule | 15:45 |
| scott-work | july 29th | 15:46 |
| rlameiro | it doesnt persia | 15:46 |
| scott-work | according to the maverick schedule | 15:46 |
| scott-work | https://wiki.ubuntu.com/MaverickReleaseSchedule | 15:46 |
| persia | Bother. Someone failed to update all the schedules. | 15:46 |
| persia | rlameiro: Feel like fixing it :) | 15:46 |
| rlameiro | no not now :D | 15:47 |
| scott-work | persia: okay, i'll drop the wrapper script direction and fixing users local files, get a patch for ardour, and mail/post users about it | 15:47 |
| rlameiro | so until when can we send updtes for 10.04.1 | 15:47 |
| persia | scott-work: The key bit is to find out where the bug really exists. Is it an Ubuntu bug? A Debian bug? An Upstream bug? Who authored the .rc file? | 15:48 |
| persia | rlameiro: Usually about a week beforehand, but we can only do that if we are doing image testing. | 15:48 |
| scott-work | this is from the source and others have reported the same problem on other distributions (including debian and arch) | 15:48 |
| persia | Best to check with the release team to find out the requirements for us to participate in 10.04.1 | 15:48 |
| rlameiro | i can test images | 15:48 |
| rlameiro | well we do have very urgent bugs to solve there | 15:49 |
| persia | scott-work: That's what I thought. I've had others suggest upstream claims it's an Ubuntu thing. Maybe good to submit a patch upstream so that they ship a different default. | 15:49 |
| rlameiro | at least the network manager and this ardour | 15:49 |
| persia | Right, but unless the release team agrees to spin us images, etc., the date doesn't matter. | 15:50 |
| persia | We can post to -updates at any time, and users who install after a post to -updates and do an upgrade will get the right results. | 15:50 |
| jussi | didnt the release team just do that? | 15:50 |
| scott-work | persia: http://tracker.ardour.org/view.php?id=2832 this shows that it's fixed in "A3", which I don't know what it is, I could presume ardour-3.0 but i haven't had time to email the guy who made the post | 15:50 |
| rlameiro | dont they do it automatically when there are bugs on the already shipped distros? | 15:50 |
| rlameiro | *isos | 15:50 |
| persia | jussi: Where/How? | 15:50 |
| persia | No. | 15:50 |
| rlameiro | persia: again the same problem, you dont have network to do updates | 15:51 |
| persia | scott-work: Cool! that's a big step forward from last I saw. You may want to get quadrispro to update that in Debian. | 15:51 |
| scott-work | persia: in that url you will find paul stating that is a problem and a "fix" was implemented and was hoping for confirmation | 15:51 |
| persia | rlameiro: I understand, *but* it depends on whether we have images. | 15:51 |
| scott-work | after i get the form of the patch determined i was going to work with debian, i.e. hoping to regiester with debian/bugs, file a report, post the patch, tell quadrispro | 15:52 |
| scott-work | persia: ^ | 15:52 |
| persia | No registration needed for Debian BTS: it accepts mail from anyone | 15:52 |
| scott-work | persia: BUT, my next question is about the patch, i was going to make a debdiff | 15:53 |
| scott-work | can i do this from two source packages via the *.dsc file? | 15:53 |
| persia | I believe you must, in fact. The debdiff program expects two .dsc files as arguments. | 15:54 |
| scott-work | oh, i was worried that this will not catch all pervasive changes throughout all the subdirectories and files | 15:55 |
| scott-work | and i thought you could actually run debdiff on the actual .deb files? | 15:55 |
| persia | You can, but that's not the sort of debdiff anyone wants to apply as a fix. | 15:56 |
| scott-work | persia: fantastic! did you see my previous comments about the network bug as well? | 15:56 |
| scott-work | short story: i found network-admin on the studio dvd but it was not installed on a vanilla lucid install | 15:57 |
| persia | No. I'm on my fourth computer in as many weeks, and have not managed to follow backscroll well. | 15:57 |
| scott-work | that would lead me to think that unapplying a patch would not adversely affect vanilla users :) | 15:57 |
| persia | OK. We need to hunt down why and fix that. | 15:57 |
| persia | Oh, no it oughtn't. | 15:58 |
| rlameiro | scott-work: http://pastebin.com/iumf644y | 15:58 |
| persia | Mostly just needs discussion with the Desktop folks (#ubuntu-desktop) | 15:58 |
| rlameiro | can i post this comment to the ardour bug? | 15:58 |
| rlameiro | just for peace of mind of the reporter? | 15:58 |
| persia | Please don't do it that way. Please add an upstream task to the bug instead. | 15:59 |
| persia | "Also affects project..." is the way to start. | 15:59 |
| rlameiro | ok | 15:59 |
| persia | The folks in #ubuntu-bugs tend to be experts at doing this (much more than I) | 15:59 |
| persia | That links it in a way that shows up on all sorts of reports, etc. | 16:00 |
| rlameiro | persia: https://bugs.launchpad.net/ardour/+bug/581786 | 16:01 |
| ubottu | Ubuntu bug 581786 in Ubuntu Studio "Mute button not enabled by default in Ardour 2.8.6 Lucid AM64" [Undecided,New] | 16:01 |
| persia | rlameiro: You might also want to open an Ardou (Ubuntu) task ("Also affects Distribution ..."), and set the Studio task to Triaged, and the Ubuntu task to Confirmed. | 16:02 |
| persia | Might be good to set some importances as well. I'd say "High" for Studio and "Medium" for Ubuntu, but that's just my opinion. | 16:03 |
| scott-work | i have ardour built already with a patch, hopefully i'll clean up the changelog (from ~ppa1) and submit the patch to the bug and file a bug with debian as well | 16:03 |
| scott-work | ...early this week | 16:03 |
| rlameiro | i cant touch on importances | 16:04 |
| rlameiro | persia: can you do it? | 16:04 |
| persia | I can. | 16:09 |
| persia | You should be able to set Importance for Studio, I think. Talk to ScottL about getting that. | 16:09 |
| persia | For Ubuntu, you'd have to work with the bugsquad (who hang out in #ubuntu-bugs) | 16:09 |
| persia | To get the ability to change importance, you have to have a record of 5 well-triaged bugs. | 16:10 |
| rlameiro | well i cant triage on any of them also | 16:10 |
| rlameiro | just in progress fix comitted fix...etc | 16:10 |
| persia | same permission issue | 16:11 |
| persia | same folks to talk to about it | 16:11 |
| scott-work | shouldn't we also add Debian on the bug report, wouldn't that preclude having to create a debian bug? | 16:12 |
| persia | No. One creates a Debian bug and then links it in LP | 16:13 |
| scott-work | okay, i'll take of that then | 16:16 |
| scott-work | persia: you mentioned talking to #ubuntu-desktop about the network bug, shall I do that as well? | 16:17 |
| persia | Someone needs to. You'd be a good candidate, if you have time. | 16:17 |
| scott-work | for this i will make time :) | 16:20 |
| rlameiro | i am on the ubuntu-bugs channel | 16:20 |
| rlameiro | waiting som charity person to help me :D | 16:20 |
| scott-work | i think persia might have changed some of the settings rlameiro | 16:21 |
| rlameiro | scott-work: i think this is nice... seeing the channel and the people working together and helping each other and trying to fix problems | 16:37 |
| scott-work | haha, i was just thinking the same things and almost typed it as well :) | 16:37 |
| scott-work | i was thinking about how effective it is and how much power it has | 16:37 |
| rlameiro | yeah, it makes me confident on the future | 16:37 |
| scott-work | i believe the more effective we are (and the more we show and demonstrate that effectiveness) the more others will be attracted to it | 16:38 |
| rlameiro | persia is indeed a valuable friend :D I have a lot to learn with him, and with all of you guys :D | 16:38 |
| scott-work | +1 for persia :) | 16:40 |
| rlameiro | i think to big problem we have its that the eavy work is limited to few persons | 16:40 |
| rlameiro | so, the most people learning to do things the better | 16:40 |
| rlameiro | even if the things are simple it is a little help | 16:41 |
| abogani | Did you notice than seems he never sleep? Perhaps he have got some supernatural power... | 16:41 |
| rlameiro | yeah | 16:42 |
| rlameiro | persia: do you sleep ???? | 16:42 |
| rlameiro | hehe persia rocks | 16:42 |
| scott-work | he commented that he isn't diurnal (which means he doesn't divide his day into two parts, awake and asleep) | 16:43 |
| rlameiro | interesting? | 16:43 |
| rlameiro | so i makes periods of sleep and awake | 16:43 |
| persia | Rather, I don't have a 24-hour cycle. | 16:43 |
| rlameiro | i eared about that | 16:43 |
| persia | A common week is usually 4-5 days for me. | 16:43 |
| rlameiro | where do you live? | 16:44 |
| rlameiro | on the north? | 16:44 |
| rlameiro | abogani: do you know if the realtime patches can be applied on other architectures? | 16:46 |
| rlameiro | say ARM?? | 16:46 |
| scott-work | in my old(er) age i certainly have a 24-hour cycle, if i don't get to bed by 11:00 i start to get cranky :P | 16:46 |
| rlameiro | scott-work: :D from friday to saturday i made it withou sleep | 16:47 |
| rlameiro | i went to sleep at 19:30 and get up at 5 morning | 16:47 |
| rlameiro | then i go to sleep at 7 again untill 11 | 16:47 |
| rlameiro | lol | 16:47 |
| rlameiro | i cant get also with it. | 16:47 |
| rlameiro | i am getting old... | 16:48 |
| scott-work | but i also get up before 6:00 even on weekends | 16:48 |
| persia | It's really not an age thing. When I was younger, I did it differently. | 16:49 |
| scott-work | later at night and early in the morning is when i can get the most done while the family is asleep :) | 16:49 |
| persia | When I was in uni, I used to go to bed around 19:00 or 20:00 and get up around 2:00 | 16:49 |
| rlameiro | i do enjoy working during the night | 16:49 |
| rlameiro | i prefer night hours than day | 16:49 |
| rlameiro | i am much more efficient | 16:50 |
| persia | But as I get older, I find it's harder to get my body to follow a schedule, and it's better to sleep when tired, do stuff when awake. | 16:50 |
| rlameiro | yea, i hear guitarman talking about power naps | 16:50 |
| persia | (although I do tend to try to go to bed earlier to give time before I have to meet folks) | 16:50 |
| rlameiro | and caffeine naps | 16:50 |
| rlameiro | like take a coffe go to sleep 15 minutes and then you wake up energized with the caffeine making the effect :D | 16:51 |
| rlameiro | well i am aproved on the ubuntu bugsquad :D | 16:52 |
| persia | Cool! | 16:53 |
| scott-work | wtg! oh, i should do that too, how did you do it? | 16:53 |
| rlameiro | now i need to do some bugs to get into the bugscontrol | 16:54 |
| rlameiro | sign ubuntu COC rea the triage wiki and join the mailing list, then apply on the team launchpad and send a mail to mailing list and wait for approval | 16:55 |
| rlameiro | https://wiki.ubuntu.com/BugSquad | 16:55 |
| rlameiro | lol the guy that accept me is also portuguese | 16:57 |
| rlameiro | hehe | 16:57 |
| persia | I don't believe he lives there anymore, but yes. | 16:58 |
| rlameiro | he is living in Texas | 16:58 |
| falktx | (outro portugues...) | 17:03 |
| rlameiro | yeap falktx | 17:04 |
| rlameiro | we are everywhere | 17:04 |
| rlameiro | i was amazed when some days ago on the train i noticed a guy using a strange OS on a netbook, guess what ubuntu :D i even tought to aproach him, but we where getting at the final station | 17:05 |
| rlameiro | it nice to see normal peopl using it :D | 17:05 |
| rlameiro | and in portugal even more, people in here use a lot of pirated software, a lot.... i even had an answer about floss software like this | 17:06 |
| rlameiro | why would i intall it if i can have the others for free... | 17:07 |
| rlameiro | scott-work: :D one more :D | 17:23 |
| scott-work | yay! | 17:23 |
| rlameiro | thats the portuguese guy | 17:24 |
| falktx | hm, scott? | 17:28 |
| rlameiro | scott-work: ping | 17:29 |
| scott-work | hello falktx | 17:29 |
| falktx | are you portuguese? | 17:29 |
| scott-work | no, i'm american, from texas | 17:32 |
| falktx | so, who's the other portuguese guy? | 17:33 |
| rlameiro | falktx: its one of the leaders of the ubuntu bugsquad | 17:34 |
| falktx | so we have a lot of pt guys in ubuntu! | 17:35 |
| rlameiro | yeap | 17:35 |
| falktx | also nuno-pinheiro from kde | 17:35 |
| falktx | he's one of the designers | 17:35 |
| falktx | http://pinheiro-kde.blogspot.com/ | 17:36 |
| rlameiro | falktx: #ubuntu-pt | 17:37 |
| falktx | nice | 17:47 |
| falktx | one more channel to the list | 17:47 |
| abogani | ScottL, scott-work: ping | 20:03 |
| scott-work | hi abogani: pong | 20:43 |
| * scott-work has been in a meeting disucssing upcoming reviews | 20:43 | |
| === irvie is now known as irv | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!