Sunday, December 14th, 2008, 7:00pm (1900) PST
- SCaLE Planning!
Floor Map Our booth for SCaLE will most likely remain this year as #31, as corners are very beneficial.
With the advent of new, improved CD cases with the LoCo's contact info, we hope to give out fewer business cards, however, we should have a healthy supply just in case...
- It's in 10 weeks! We need to start getting ready!
- December 28 meeting?
- Discussion on whether to cancel a meeting on the 28th for holiday reasons will be moved to the list (It was canceled)
- UDS recap (Not previously on the agenda)
For increased LoCo involvement to share best practices, there might be a "LoCo weekend" similar to "Open Week" for LoCos around the world to collaborate and share their ideas to spread Ubuntu even further.
- Case badges (Also not really on the agenda, but tangentially brought up)
- We still have 'em!
- SCaLE Planning!
- December 28 meeting?
- UDS recap (Not previously on the agenda)
- Case badges (Also not really on the agenda, but tangentially brought up)
- Join us after this meeting for some planning and/or discussion about 'buntustand! Which we hope to have functional in time for SCaLE.
19:06 < Flannel> Alright, thank you all for joining us tonight. We've got a few things on the agenda for tonight: tidbits from UDS, discussion about the next meeting, and discussion and planning about SCaLE. 19:07 < sn9> ok 19:07 < Flannel> I'd also like to mention that we'll be doing some developer stuffs immediately following the meeting, you're all welcome to stick around and join in, even if you're not necessarily a coder, nor necessarily interested. 19:08 < grantbow> Is anyone attending this meeting for the first time? 19:08 < Flannel> If anyone has anything to add, you're welcome to do it now. We'll likely slot most new topics before the SCaLE stuff, since that may run long. 19:09 < nhaines> I guess I'd like to mention that I started using the identi.ca account for the LoCo today. 19:09 < nhaines> So if you're on identi.ca, feel free to subscribe to ubuntucalifornia. 19:09 < grantbow> I saw that nhaines, looks great! 19:09 < Flannel> No hyphen support at the moment, but that may change in the future. 19:09 < AlgorithmicContr> Flannel: so what's UDS? excuse my ignorance 19:09 < sn9> nhaines: i must say, i agreed with everything you said on the matter on the mailing list 19:09 < grantbow> UDS = Ubuntu Developer Summit 19:10 < nhaines> sn9: thanks. Feel free to say so on the mailing list too. :) 19:10 < Flannel> With that, jjpeters had the oppportunity to attend UDS (Ubuntu Developers Summit) in mountainview this past week. He's offered to give us a recap sort of thing. 19:11 < jjpeters> yup, just got back from a fun and tiring week 19:11 < jjpeters> its amazing how much can happen in a week, so i'm just going to report on a few interesting things related to locos. tho ask if there's something else you want to know. 19:11 < grantbow> I saw a url for videos from UDS earlier in this channel 19:12 < Flannel> Videos are http://videos.ubuntu.com/uds/jaunty 19:12 < jjpeters> yeah, all the sessions were recorded too, the should be up soon, i think. 19:12 < Flannel> with the schedule available...... 19:12 < grantbow> thanks Flannel 19:12 < Flannel> http://summit.ubuntu.com/uds-jaunty/ 19:12 < Flannel> There's the schedule (you need the schedule to navigate through the videos) 19:12 < nhaines> I found that the videos generally failed in the department of audible audio, but maybe they're not all that way. 19:13 < Flannel> For those with no idea what UDS is... It happens every release. They try and figure out which blueprints are set for this release, what the goals are, etc. 19:14 < jjpeters> yes, and this time it was at google campus, 6 tracks, 230 developers, all day discussions planning Jaunty and figuring out things like how to improve community as ubuntu grows. and a bit of time at the bar. 19:14 < nhaines> The combination of face-to-face discussions, hackfests, and after-hours entertainment helps drive collaboration and friendship. 19:15 < jjpeters> and listen to SADFL butcher a version of "american pie" :) 19:15 < nhaines> Which is available here, btw: http://people.ubuntu.com/~kirkland/Ubuntu_Allstars/2008-12/ogg/ ;) 19:15 < sn9> um, don't forget B for Benevolent 19:16 < jjpeters> anyway, in community track, lots discussion of "making locos rock." 19:16 < jjpeters> sn9: oops. :) 19:16 < jjpeters> there will likely soon be an "loco weekend" (like "open week") for locos to share practices, hang out, bring locos together. 19:16 < grantbow> for those that don't know, SADFL = self appointed dictator for life aka. MarK Shuttleworth 19:16 < Flannel> !sabdfl | for those of you who have no idea 19:16 < LikeTotally> for those of you who have no idea: Mark "sabdfl" Shuttleworth is our favourite cosmonaut, the founder of Canonical and the primary driver behind Ubuntu. You can find pieces of his thinking at http://www.markshuttleworth.com 19:16 * grantbow bows to LikeTotally 19:17 < jjpeters> thanks LikeTotally 19:17 < AlgorithmicContr> Hehe 19:17 < jjpeters> the french loco provides inspiration, they had 4000 at their last release party! http://fridge.ubuntu.com/node/1759 19:17 < jjpeters> i still can't believe 4000 19:18 < jjpeters> other cool events like : maryland loco does field trips; d.c. loco (and others) do booths at community fairs 19:19 < jjpeters> and there will be lots of future efforts for locos to share best practices. 19:19 < nhaines> Ooh, what kind of field trips? 19:19 < jjpeters> like to space museums 19:19 < Flannel> jjpeters: That's what the US Teams Project is already doing, by the way. 19:20 < grantbow> http://dc.ubuntu-us.org/ 19:20 < jjpeters> Flannel: yes, there was talk of expanding that effort 19:21 < jjpeters> one last thing: i met the guy from the MA loco who got those nice case badges made (canonical does not make or seel them, for OEM related reasons) 19:21 < jjpeters> https://wiki.ubuntu.com/MassachusettsTeam/Projects/AluminiumCaseBadges 19:21 < Flannel> jjpeters: Right, its sort of gone by the wayside, and the recent revival efforts have gone less than swimmingly, mostly due to unemployment of a few people. 19:21 < grantbow> err, http://www.ubuntu-maryland.org/ 19:21 < Flannel> That'd be doctormo, and we have many of them still. 19:21 < jjpeters> yeah, he is interested in someone taking over to make a new batch ... 19:22 < jjpeters> thats most of what i have. jaunty looks cool, fast boot times should be great, lots of good effort to improve communication. 19:22 < nhaines> I hadn't heard of Canonical's OEM-related reasons. 19:23 < Flannel> If anyone's interested in them, we've been selling them for a dollar a piece, to raise money to cover our expenses, etc. 19:23 < Flannel> (the case badges, that is) 19:23 < Flannel> Not that its particular important, but while we're on the issue. 19:23 < nhaines> Jaunty will focus on faster boot times and web application integration. 19:23 < jjpeters> nhaines: canonical does not want to sell badges, because they look very "official" and they have actual certification programs. 19:23 < nhaines> Oh, and all of Ubuntu will be in bzr. 19:24 < nhaines> jjpeters: That on the other hand makes perfect sense. Too bad they don't sell them to certified Ubuntu partners. :) 19:24 < rww> Flannel: how do I go about buying them? they look shiny... 19:24 < jjpeters> and if anyone uses amazon EC2 there is a big push to make "cloud computing" easy in the server edition. 19:25 < AlgorithmicContr> Flannel: wait, we can still buy them? I thought you ran out? 19:25 < jjpeters> http://aws.amazon.com/ec2/ 19:25 < Flannel> rww: They are shiny. Talk to me after the meeting and we'll see about specifics. In person is easiest, since most other forms of money transfer eat a sizable portion 19:25 < Flannel> AlgorithmicContr: Yeah, we've got them. 19:26 < Flannel> AlgorithmicContr: We bought a bunch extra when we did, because we assumed there wouldn't be another batch for a while. 19:26 * Flannel doesn't remember specifics anymore, but I can look them up later. 19:26 < AlgorithmicContr> Oh okay cool, I'll nag you about that later 19:27 < jjpeters> thats all i have on UDS, unless anyone had any questions? 19:28 < Flannel> jjpeters: Looking forward to the collaboration. I know there's a few projects that are starting up having to do with global LoCo collaboration (Spread Ubuntu repository, for instance). Was that a jono thing? 19:29 < Flannel> Or, do you remember which day it was talked about? I can just go watch for myself 19:29 < jjpeters> Flannel: yes, exactly. it was in the "loco directory" session on monday 19:29 < Flannel> Alright. I'll be sure to check it out. 19:29 < nhaines> I think they said it should be more of a spreadubuntu.ubuntu.com type of thing? 19:30 < Flannel> nhaines: It'd end up being spread.ubuntu.com, but there are some other issues with that, we'd sort of like spreadubuntu.com and diy.spreadubuntu.com, but we're digressing 19:30 < jjpeters> nhaines: yes, the loco directory would be the primary loco contact point for new people 19:31 < Flannel> Alright, thanks again jjpeters for keeping us all up to date on that. 19:31 < nhaines> Thanks, jjpeters. :) 19:32 < jjpeters> my pleasure :) 19:32 < Flannel> Next topic is a smaller one: Do we want to have a meeting on the 28th? (That'd be in two weeks) It's close to ... all sorts of holidays. We don't have to decide now (but we could). What are everyone's thoughts? 19:32 < nhaines> We should probably handle it like the Thanksgiving meeting. Wait and see if anything comes up that can't wait. 19:33 < grantbow> Even if we have a small meeting we can still have a meeting. 19:34 < nhaines> No sense in having a meeting if there's no quorum and no agenda. 19:34 < grantbow> informal meetings have no value? interesting perspective 19:34 < Flannel> grantbow: We have an informal meeting 24 hours a day here. 19:34 < nhaines> grantbow: that's called "IRC" and we're in it the rest of the time. 19:35 < nhaines> Heya, Yasumoto! Glad you could make it. :) 19:35 < Flannel> Yasumoto: You're more or less just in time. 19:36 < Yasumoto> Heya guys, sorry about that. I think I screwed up my network settings from when I was working on my openmoko ~_~ 19:36 < Flannel> Yasumoto: Topic at hand: What are your thoughts on the Meeting on the 28th? 19:36 < Yasumoto> usb networking ftl 19:36 < Yasumoto> thanks Flannel and nhaines :-) 19:36 < grantbow> uh oh 19:36 < Yasumoto> Flannel: regarding social networking? 19:36 < Flannel> Yasumoto: No. Two weeks. Holidays. 19:36 < Yasumoto> mm 19:36 < nhaines> Yasumoto: this 28th. 19:37 < Flannel> We don't have to decide tonight, but we'd like people to express opinions, etc. 19:37 < Yasumoto> that's actually my birthday, for what it's worth 19:37 < Yasumoto> so I'll probably be running about with other things 19:38 < Flannel> Alright. So, we'll wait and see. Make a decision this Sunday afternoon based on the current agenda. If there's nothing time-sensitive, we'll just postpone the items until the 11th. 19:38 < Flannel> Sound good to everyone? 19:39 < Yasumoto> +1 19:39 < nhaines> +1 19:39 < grantbow> +1 19:39 < AlgorithmicContr> =2+1 19:39 < jjpeters> +1 19:39 < AlgorithmicContr> er 19:39 < Flannel> AlgorithmicContr: e^(j2pi)? 19:39 < AlgorithmicContr> aye 19:39 < AlgorithmicContr> hehe, good one 19:40 < Flannel> Alright. That settles that. Next topic: SCaLE! 19:40 < Flannel> SCaLE is 20-22 of February. We're attending! 19:40 < sn9> yes indeedy 19:40 < Flannel> Yasumoto has told me that he can likely get us preference for a booth. 19:40 < nhaines> Yay 19:41 < Flannel> I thought the corner spot we had last time was perfect. It wasn't in the middle of everything, and the corner gave us two sides to work with. 19:41 < Flannel> I'd actually preferthat to a "real" corner (not a T), or to one of the busy ones near the door. 19:41 < Flannel> But that's just my thoughts. Anyone else? 19:42 < nhaines> The opposite corner might be nice, too, since it's more trafficked. I think we could manage having more visitors. 19:42 < Flannel> nhaines: opposite being all the way on the other wall? or what? 19:42 < Flannel> We could certainly handle more visitors, especially with some of the improvements we're hoping to have 19:43 < Flannel> http://www.flickr.com/photos/nathanhaines/2352797777/in/set-72157604204639748/ 19:43 < sn9> Secutor submitted a booth paper himself, but last i heard, had not heard back 19:43 < nhaines> Flannel: being the opposite side of the block of booths we were in. 19:44 < Yasumoto> I love those tablecloths :-) 19:44 < Flannel> That was our booth location last year. We used the yellow table facing to the left (to the wall) with demo computers, the red table for stuff, and the orange table for our CD stash. 19:44 < Flannel> Yasumoto: We'll get them again ;) 19:44 < nhaines> Yasumoto: weren't they awesome? :) Jono liked them too. 19:44 < Flannel> nhaines: opposite side... like, where the photographer was standing? 19:44 < Yasumoto> (behind the photographer?) 19:44 < Flannel> Or where debian was? 19:45 < nhaines> Like all the way to the right, relative that photo. 19:45 < nhaines> Better view of the booth setup: http://www.flickr.com/photos/nathanhaines/2353642188/in/set-72157604204639748/ 19:45 < Flannel> nhaines: so, the other wall. Uh, the west wall? 19:45 < Flannel> (the wall to the left in that photograph is the east wall, I believe... or I'm assuming, with my "west wall" comment 19:46 < Flannel> Oh hey, That is a much better shot 19:46 < nhaines> Flannel: the other aisle. 19:46 < AlgorithmicContr> How about where Linux Astronomy was working? 19:47 < Flannel> http://www.socallinuxexpo.org/scale6x/images/maps/expo_floor_map.png 19:47 < Flannel> !! pick a number ;) 19:47 < LikeTotally> Flannel: Error: I am only a bot, please don't think I'm intelligent :) 19:47 < AlgorithmicContr> hehe 19:47 < AlgorithmicContr> So we were 31 19:47 < Flannel> We're booth 31 (top) the entrance is on the left 19:47 < nhaines> 35 19:48 < Flannel> nhaines: Those were all big name people, from what I remember 19:48 < AlgorithmicContr> 61 19:48 < nhaines> Even 66 wouldn't hurt. 19:48 < nhaines> It'd just be nice to have a bit more traffic. 19:49 < nhaines> As long as we have a corner we'll be fine. :) 19:49 < Flannel> nhaines: 66 is less of a corner though. People'd have to walk around (to the bottom of the booth on that page) to do demo computers probably 19:49 < Flannel> I'd prefer 31 to 45, for instance. Since I think we got more traffic. 19:49 < Flannel> and also prefer 31 to 60 19:50 < Flannel> but, we're obviously not cherry picking, just discussing general feelings. 19:50 < nhaines> Yeah, 31's better. 19:50 < Flannel> I don' twant to make Yasumoto feel like he's being put under pressure here ;) 19:50 < nhaines> Well, the closer we can get to center of the floor is better, but 31 was a very nice booth and worked well fo rus. 19:50 < AlgorithmicContr> No one thinks 61 is a good spot? 19:51 < Flannel> nhaines: but I really think the corner (two outside walls) worked very nicely for us. Moreso than 34 would, for instance. 19:51 < nhaines> Flannel: I entirely agree. 19:54 < nhaines> I'll probably know by the next meeting if any of my two talks were accepted for SCaLE. 19:54 < AlgorithmicContr> nhaines: what about? 19:55 < Yasumoto> nhaines: *crosses fingers* :-) 19:55 < nhaines> AlgorithmicContr: one's about the role Free Software can have in driving the Open Content trend and empowering young people. 19:55 < nhaines> AlgorithmicContr: The other's a talk about going from Windows to Linux, for beginners. 19:55 < nhaines> Yasumoto: thanks. I hope it drives people to our booth. ;) 19:56 < rww> nhaines: "Open Content" meaning stuff like the creative commons people? 19:57 < nhaines> rww: exactly. The focus is on how someone growing up with only Free Software, combined with CC stuff, might view the world. 19:57 < Flannel> Alright. Um, other SCaLE stuff... I've (technically) set up a page: https://wiki.ubuntu.com/CaliforniaTeam/Projects/Scale7x Once it's properly populated with wants/haves/etc (mostly the same from last year), I'll send out an email to the list. Hopefully people can start figuring out what they can bring/loan/whatever. 19:58 < Flannel> I think that's all I have for SCaLE for today. Didn't mean to step on nhaines and rww there. 19:58 < Yasumoto> nhaines: for sure 19:59 < nhaines> Flannel: Nah, that's okay. We can discuss more after the meetings, for sure. 19:59 < Flannel> Oh. nhaines, how many LoCo business cards do you still have? 19:59 < Flannel> We may need to get another batch printed 20:00 < Flannel> although we can use CD cases for a good deal of the info, so we probably won't need as many. 20:00 < nhaines> A little less than 100, I think. 20:01 < Flannel> I think Ive got about a box. But I'll double check. We won't need to give them out with every CD though, just when people want a card (because the cases will have that info on them) 20:02 < Flannel> mmmm. Yeah. I'll move this next topic to the list, I believe, but: SCaLE is in *10* weeks. So we need to figure out what, if anything, we want to get professionally printed. 20:03 < rww> ah 20:03 < rww> (eep, wrong window. ignore that) 20:03 < Flannel> That'd be business cards, origami sleeves (or other sleeves), flyers, etc. 20:03 < Yasumoto> holy cow, I didn't even realize it's so soon 20:03 < Flannel> I think I'm going to make a cardboard Ubuntu Logo for the wall, so we won't need to figure out banner stuffs, unless we want one instead. 20:03 < Flannel> But yeah. I'm moving this to the list. 20:04 < Flannel> Please comment on it there ;) 20:04 < Flannel> Anyone else have anything for the meeting? 20:04 < nhaines> Cardboard might be cool. :) 20:04 < Flannel> nhaines: I figure 3d logo thing hanging on the wall would look nice yeah. 20:04 < Flannel> and it'd be cheaper than a banner, and probably more wow-facto 20:04 < Flannel> factor, that is. 20:05 < Flannel> not that "higher" means by much ;) 20:05 < nhaines> We need a bit more punch than last time, definitely. 20:06 < Flannel> Alright. So, that about does it for this meeting. Thank you all for coming. Next meeting may be in two weeks, keep your eyes on your inboxes in about 8 days.
After-Meeting Discussion Regarding 'buntustand
20:26 < nhaines> Okay, so last year we got to SCaLE and everyone had brought laptops and PCs with Ubuntu and Ubuntu ISOs, and we were ready to start burning CDs for the show. 20:26 < nhaines> Except nobody had any idea which ISOs they hand, and it was sort of unorganized chaos, but good chaos. And it gave me an idea. 20:27 < nhaines> What if I could write a program that would quickly tell me what ISOs I had on a computer? And that program's called 'Buntu List and available for download and in a very hacky way it does its job. 20:28 < nhaines> But then I thought, well, once I know what ISOs I have, why not have a slick way to burn CDs as well? What if someone could walk up, click a couple buttons, and get the burned CD he wanted, or read a blurb about different variants of Ubuntu? 20:28 < nhaines> So then I thought such a program would be better. And that's what 'Buntu Stand is all about. 20:29 < nhaines> So this year for SCaLE we want some software that will be able to know what ISOs are on each machine, and coordinate burning between them, as well as potentially have a pretty interface we can use to wow booth visitors. 20:29 < nhaines> Bonus: at the end of the day we count our leftover CDs and know how many of each we've given out. 20:29 < Flannel> We ran into another problem at SCaLE, and that was that we never really had enough CDs on hand (we only had two computers doing the burning) 20:29 < Flannel> and poor cactaur had to sit there and start all of the burns by hand, etc. 20:31 < Flannel> buntustand will also solve that issue, because we can have a bunch of computers burning CDs with minimal intervention from us. To keep up with the demand (which is going to be more this year) 20:31 < nhaines> So this way we can tell the system "I need 5 more Ubuntu Desktop CDs", and each computer will be able to say "I can burn one" and it'll be automatic. 20:31 < Flannel> Obviously, this is going to be a client/server sort of thing, so we can have one server (with a frontend) controlling multiple clients (with the burners) 20:32 < Flannel> (even if the client and server are on the same machine) 20:32 < Flannel> I *believe* for SCaLE this year, we're looking for functionality, instead of prettiness. But we'll see how development goes. 20:32 < Flannel> Obviously, a pretty frontend is useless iwthout the functionality. 20:33 < Flannel> So at the moment ( nhaines stop me if I'm wrong) we're concentrating on a frontend that's meant for use by us, not by 'general public' 20:33 < nhaines> Flannel: Right. With the right interface, we don't have to worry about the frontend too much. 20:33 < Flannel> None of the "This is what this iso is good for, this is what it provides you with" etc, just "What sort of CDs do I want to burn, and how much" 20:34 < nhaines> Because we can just build a new interface later while keeping the same backend. 20:34 < rww> How many computers are going to be burning at Scale this year? More than two, I'd guess? 20:34 < Flannel> So it has two uses: inventory tracking and control (and semi-automatic queueing) and the second is "regular person" use, where htey can burn on-demand 20:34 < Flannel> http://www.flickr.com/photos/nathanhaines/2353642188/sizes/l/in/set-72157604204639748/ 20:35 < Flannel> Last year we had two computers on the yellow table (facing left), that were burning, and then the table on the right (with the red), was displaying the slideshow 20:35 < Flannel> so, we had two computers burning 20:35 < Flannel> I have a few computers that aren' 20:35 < Flannel> aren't really "fit" for showing off at SCaLE, but they'd do just fine burning, etc. 20:36 < Flannel> So there's at least two more computers to burn this year... probably three, from me. 20:36 < Flannel> And the slideshow one (its a client program that runs as a daemon, so it can burn and do slideshow at the same time, etc) 20:37 < Flannel> The other benefit is that we'd only need to communicate through one point to get more cDs burned 20:37 < nhaines> Ask for them and then get the machines loaded up with CDs. 20:37 < Flannel> Whether thats hijacking a mouse for a minute, or text messages, or ... who knows what. It'll be much less intrusive 20:38 < Flannel> Each client will recieve a signal from the server to burn a CD, open its tray, we put in a CD,it burns, spits it out, we label it, put it in a sleeve, and put another blank in the tray 20:38 < Flannel> rinse, repeat. 20:39 < Flannel> The server program does all the logic (at this point, not much logic, later... maybe more, so it plans ahead, etc) 20:39 < nhaines> Flannel: I preferred a method where each computer has a burn queue, and if it's advertised, then any other computer with buntustand can say "I'll burn that one for you" and take it off the other queue. 20:39 < Flannel> nhaines: so more of a mesh sort of thing? 20:40 < nhaines> Right, we could initiate on all computers individually if we wanted, but if the others had blank CDs and no queue they could start burning. 20:40 < Flannel> (The rest of you,as you can see, we're still figuring this out, so feel free to ask questions/suggestions/etc) 20:40 < nhaines> That way we can still only use one computer. 20:40 < nhaines> As far as the queueing goes. 20:40 < Flannel> nhaines: That seems like it'd be more complicated with not much more, if any, benefit 20:41 < rww> nhaines: wouldn't that make it more difficult to tell which computer is burning which CD? 20:41 < nhaines> rww: That's part of the challenge. 20:41 < Flannel> I don't see a point of making something artifically difficult 20:41 < Flannel> nhaines: What sort of benefit would that provide though? 20:41 < nhaines> Flannel: I'm not convinced it'd be that much more complicated, but it might be something we worry about after SCaLE. 20:42 < nhaines> Good right now is better than perfect later. 20:42 < Yasumoto> I think having one main server with a single queue is a good idea 20:42 < Flannel> cactaur: We're talking about 'buntustand, feel free to join in 20:42 < Flannel> (not during the LoCo meeting, just informal afterwards) 20:42 < cactaur> I'm guessing 'buntustand is some program nhaines wrote in python. 20:43 < nhaines> cactaur: It's one we're going to write. 20:43 < Flannel> cactaur: Some program we're all writing, in python (yes, I learned python, thats how excited I am about it), to help you enjoy SCaLE 20:43 < cactaur> Oh, it's the auto-CD-burner? 20:43 < nhaines> 'buntustand burns CDs, so cactaur doesn't have to! :D 20:43 < Flannel> cactaur: Yeah, distributed, etc. 20:44 < cactaur> Cool. I was wondering, how exactly is that gonna work? 20:44 < Flannel> nhaines: What benefit would individual queues provide? (am I understanding that correctly?) 20:44 < nhaines> Flannel: The same program works the same way on non-networked computers. 20:44 < Flannel> cactaur: We're figuring it out. Single server machine with a GUI, with client machines doing the burning. 20:44 < nhaines> But with a network, they can help each other out. 20:44 < Flannel> nhaines: On a non-networked machien, you start the server, then start the client. 20:45 < cactaur> And the burning is done over the network? 20:45 < Flannel> and the client conencts to the server on loopback 20:45 < Flannel> and then it works the same. 20:45 < Flannel> There's definate benefit in separating the client and server programs as far as simplicity goes 20:45 < nhaines> Right, the burners would only need the server. 20:45 < nhaines> But the servers would, when idle, see if it could burn any other computers' queues. 20:46 < Flannel> wait, wait 20:46 < Flannel> clients are the programs doing the burning. 20:46 < Flannel> yes? 20:46 < Flannel> or are we talking Xorg here, where theyre switched? 20:46 < nhaines> Not in the original plan. Client was the GUI, and server was the main program. The benefit would be that each computer knows which set of ISOs it has. 20:46 < Flannel> er... 20:47 < nhaines> Or rather, it wasn't conceived of as a client/server interface. 20:47 < Flannel> ok, let me fully explain my idea on it then, now that I know I need to specify what a client is and what a server is 20:47 < nhaines> More like a distributed whatsit. 20:48 < nhaines> More like a daemon/interface sort of deal. 20:48 < Flannel> A client is a program that polls a server asking what to burn. It knows what isos it has (and knows the checksums of those ISOs), it can download more ISOs from the server if need be. The clients are the only things running on a machine that is only doing burning (headless box, etc) 20:49 < Flannel> a server communicates with the outside world. Knows what CDs it wants to burn, etc. It tells the clients what to do, and recieves inputfrom the users (that's us) about what it should do in the future, etc. 20:49 < Flannel> The server only runs on the single master machine. Which a client cna be running on as well (so that machine can do burning) 20:50 < Flannel> Actually, the server doesn't have to be tied to a frontend, but could have a number of frontends 20:50 < Flannel> but, its thething that somehow communicates to us, and tells the clients what to do. 20:51 < Flannel> (in the future, it'd keep track of stats about the clients, burn speeds, etc, to be smart about burning things most efficiently, etc) 20:51 < AlgorithmicContr> ah, that is wise 20:51 < Flannel> That's my proposal/understanding of what we ought to do. 20:51 < AlgorithmicContr> it's going to have integrity checks, right? 20:51 < AlgorithmicContr> or 20:52 < nhaines> AlgorithmicContr: implementation detail of the client. 20:52 < AlgorithmicContr> would that take too much time? 20:52 < Flannel> AlgorithmicContr: burning programs should also, after burning, mount and check the md5, yes. 20:52 < rww> How would you deal with machines with more than one CD drive? Run one client for each drive? 20:52 < Flannel> rww: That'd be one way to do it, yeah. 20:52 < Flannel> That'd probably be the simplest way to do it 20:53 < Flannel> each client will control one burning device 20:53 < AlgorithmicContr> they'll be servers with more than one CD drive, right? 20:53 < Flannel> nhaines: So, now that I understand difference between our ideas, care to fully explain your idea? 20:53 < nhaines> Sure. My proposal is a standalone daemon that knows what ISOs it has and can start burning when a request is queued by an interface on the same computer. 20:53 < Flannel> AlgorithmicContr: Mine only have one burner each, actually. But... I do have some more burners, I could see if they work 20:54 < nhaines> It can advertise its queue on the network, and other computers running buntustand can negotiate to burn a disc from another's queue. 20:54 < nhaines> Based on whether or not it has the ISO and can fulfill the request. 20:55 < nhaines> This way we can still just have one interface on one system. 20:55 < Yasumoto> well, technically, if it's the server that has the main queue, then the other computers wouldn't have another queue 20:56 < Flannel> so, nhaines, a monolithic program that plays well with othes? 20:56 < Flannel> others 20:56 < nhaines> Flannel: precisely. 20:56 < nhaines> It would also work in the same way: we can use only one computer to queue up CDs. 20:57 < nhaines> The main computer wouldn't even need to have a burner. In that case, it wouldn't burn, just enqueue. 20:57 < Flannel> (I think I've already said this but) I think that's complexity for the sake of complexity (both in the figuring out what to do, and the program itself, trying to determine which role it fills) 20:58 < Flannel> nhaines: What benefits do you think would come from that over the other separate client/server proposal? 20:58 < nhaines> Flannel: I think it'd mean no client/server setup. 20:58 < Flannel> What sort of set up? 20:59 < nhaines> We'd have to worry about IP addresses and network settings and so forth. 20:59 < Flannel> Each computer runs the client on boot, and then we strt up the server on the GUI box as needed. 20:59 < Flannel> Avahi will solve that problem 20:59 < Flannel> but, even before avahi, I don't think that's a huge problem, there are workarounds if we can't get avahi to behave 21:01 < nhaines> Hm. I think what I'd like to avoid with my proposal is the need to maintain network sessions. 21:01 < Flannel> What do you mean? 21:01 < Yasumoto> nhaines: sorta like everything can be self contained if need be? 21:02 < Flannel> I didn't ever intend them to communicate through sessions. Probaby more like UDP or something 21:02 < nhaines> Yasumoto: yes. 21:02 < nhaines> Flannel: So do I. 21:02 < Flannel> So, in the "I'm all alone" case, not having to worry about connecting on loopback? 21:03 < nhaines> My initial spark of inspiration was that each machine could manage its own CD set, so that we wouldn't have to worry what everyone had brought. 21:03 < nhaines> So the idea was that each machine pitched in with what it could burn. 21:04 < Flannel> right, that'd be fully possible with the other one too. 21:04 < Flannel> The server technically would only need to know "about" each CD typ 21:04 < Flannel> and then the clients will burn what they have if we don't implement the download thing 21:04 < Flannel> (I assumed just calling a wget or something) 21:05 < Flannel> but we can always sneakernet images as well 21:05 < nhaines> Flannel: will the server keep track of what each machine has? 21:05 < Flannel> It wouldn't have to. 21:06 < Flannel> (It might be a good idea to, for plannign purposes) 21:06 < Flannel> Although, to be honest, for this upcoming SCaLE I assumed we'd take away all of the "real world" situations, and provide each computer will all the images we'd be offering. 21:06 < nhaines> That'd probably be for the best anyhow. 21:06 < Flannel> Since we're on an extremely short timeframe 21:06 < nhaines> Yup. 21:07 < Flannel> And in the futre, deal with the real world errors, etc. 21:07 < Flannel> But, as far as future is concerned: server would have a benefit to know, because it'd mean that it could give the machine with the obscure ISOs all the obscure jobs 21:07 < nhaines> I'd had a vision of people using the software at installfests, just bring your computer and plug it into the network and it can start offering CDs. 21:08 < Flannel> nhaines: I don't see why that wouldn't be possible with the separate version 21:08 < nhaines> Flannel: in the distributed model, each server could advertise its own collection and any interface could include it as well. 21:09 < nhaines> I'd still like to go my way. But we don't have forever. If we can get the CD burning stuff polished, we can do that for SCaLE and worry about fancy standalone stuff later. I mean, it's Python, it's not like it's not extensible. 21:09 < Flannel> nhaines: As far as that's concerned, the GUI will have to "know" about the CDs to provide info ("Edubuntu is for kids!"), it'd be easy enough to transfer a 700MB file as well 21:09 < Flannel> I just don't see the benefit of having a monolithic program 21:10 < Flannel> but, I might just be missing the point 21:10 < nhaines> nhaines: the idea was that the plugins (Python modules) that knew how to detect the CDs would provide a logo and blurb. 21:10 < Flannel> talking to yourself now, eh? 21:11 < nhaines> I'm not really sure how I manage to get irssi to do that. ;) 21:11 < Flannel> nhaines: Wouldn't it be just as easy to download the iso from the other machien too? we're generally talking about CAT5 here, so it wont take long. 21:11 < nhaines> Anyway, so that if someone wanted to offer a Windows OSS sampler or something they could write a quick Python module and drop it in the right folder. 21:12 < nhaines> Flannel: That was something I was thinking about in a more long-term fashion. 21:12 < nhaines> wget or bittorrent is always fun over local. 21:13 < Flannel> nhaines: So if 5 people showed up and want to provide CDs, one person decides to include an oddball ISO, 21:13 < Flannel> The other four could advertise for it? 21:13 < nhaines> Ultimately it seemed like more fun to have people bring their machines and decide whether to burn for others or not, or allow others to burn for them, and whether or not to receive ISOs from others. 21:13 < nhaines> Flannel: right. 21:14 < Flannel> nhaines: Ok, so... take my doohickey, and then make the servers play well with other servers. 21:14 < Flannel> but the clients still just grind out CDs and take orders 21:14 < nhaines> Well, that's basically all I had in mind in the first place. :) 21:14 < nhaines> I'm not thinking of one monolithic program that does backend burning plus interface. 21:14 < Flannel> That's a server/frontend implementation detail thing, as far as I'm concerned. (frontend: ncurses, web, GUI, "cloud") 21:15 * Flannel feels dirty. 21:15 < Yasumoto> haha 21:15 < nhaines> Well, that's what I was saying. :) 21:16 < Flannel> nhaines: You made it sound monolithic. And never corrected me when I said "monolithic" :P 21:16 < Flannel> monolithic GUI + logic + burn (or even logic + burn) is too complicated 21:16 < nhaines> The line of development idea was that one program that can burn CDs is easier to write, and when there's time, add support to ask others if it can burn a CD for them. 21:16 < nhaines> For me, logic means "know what CDs you have" and "burn when requested" 21:17 < Flannel> burn-slave is a perfect size/complexity for a burning program, and then the logic could be a daemon with separate frontends, or (likely more for this SCaLE) and integrated frontend 21:17 < Flannel> logic is planning how many to burn, etc. 21:17 < nhaines> Interface does that. 21:17 < Flannel> knowing we're losing 10 Ubuntu CDs per minute, and 4 Kubuntu CDs per second, so we need to burn X and Y 21:17 < Flannel> Not if we make it think ahead 21:18 < nhaines> Yeah, but I never had any intention of having it do that. 21:18 < Flannel> burning should simply poll and burn (and check integrity) 21:18 < nhaines> The main bottleneck was always everyone forgetting to check for finished CDs and restarting burns. 21:19 < Flannel> however, logic in that sense is far off. In this case, we're going to use puny hoomans for logic ("burn me 4 ubuntu, 1 kubuntu, and 1/2 edubuntu") 21:19 < Flannel> and that'll actually be external to the GUI all together 21:19 < Flannel> (since it'll be in your head) 21:19 < nhaines> Agreed. 21:20 < Flannel> So burn basically polls, will reject bad requests (or downloads the ISO from somewhere) (except we won't have bad requests right now), burns, and verifies burn. 21:20 < Flannel> We've... settled on that, yes? 21:20 < nhaines> And manages its own inventory. 21:20 < Flannel> and then some stats reports (50% done, I've got a bad burn, etc) 21:21 < Flannel> inventory being which isos it has? 21:21 < nhaines> Yeah. (If we drag more ISOs into the right folder, it starts handling more types of discs) 21:21 < Flannel> It'd have to do that to reject bad requests 21:21 < Flannel> right 21:21 < Flannel> but for SCaLE we won't need to implement that 21:22 < nhaines> It's pretty automatic if you do it right. :) 21:22 < nhaines> But agreed. 21:22 < Flannel> Yeah, it shouldn't be difficult. but... milestones ;) 21:22 < Flannel> If we exceed milestones, that's fine. 21:22 < Flannel> Alright, and then for SCaLE... just a simple master queue? 21:22 < Flannel> with a GUI? 21:23 < nhaines> Okay. 21:23 < Flannel> (and tracking software) 21:23 < Flannel> yeah? no? maybe? 21:23 < Flannel> ncurses? 21:23 < Flannel> web? 21:23 < nhaines> Tracking software might be harder. 21:23 < nhaines> I'll say ncurses. 21:23 < Flannel> Tracking-- "I burned 4 Ubuntu CDs" 21:23 < Yasumoto> (master queue + gui)+1 21:23 < Flannel> not whateve relse you're thinking 21:23 < Flannel> basically just logging what it does 21:24 < nhaines> Yeah, that we need. 21:24 < Flannel> and just dumping to logs is fine 21:24 < Flannel> that's all the tracking I'm interested in at the moment 21:24 < nhaines> Yeah. 21:25 < Flannel> so, you think ncurses is the best way to go then? 21:25 < nhaines> I want to be able to walk up to a master computer and say "we have 5 Ubuntu CDs left" and then it'd be all like "Okay, you gave out 123 Ubuntu CDs." 21:25 < Flannel> nhaines: Eh, we can grep logs for that 21:25 < Flannel> Of course, keeping a tally isn't diffcult either 21:25 < nhaines> Flannel: Yeah, ncurses is best. 21:26 < nhaines> Flannel: I'm concerned that some computers go home after a day and then we don't have logs. 21:26 < Flannel> nhaines: Right. Well, log would be on server, 21:26 < Flannel> I... guess logs would be on clients too 21:26 < Flannel> They can both have logs. Clients will keep track of individual stuff, server will be able to keep track of all clients 21:26 < Flannel> (because they'll say "I burned successfully" or "I failed" 21:27 < nhaines> Okay, sounds good. 21:28 < Flannel> So, ncurses is the GUI. Do we know how to burn in python? 21:28 < Flannel> from what I found, its all through external programs 21:28 < nhaines> yeah. 21:28 < nhaines> We basically steal however Brasero does it. 21:28 < Flannel> Right, thats what I assumed 21:29 < Flannel> And then... networking. avahi has that demo python client and server on their site. 21:29 < Flannel> If we can get that to work, we'll be able to let avahi take care of all of the low level crap 21:29 < Yasumoto> isn't there a command to burn a disc? 21:29 < Yasumoto> maybe we can use that too 21:29 < Yasumoto> that'd be sweet 21:30 < Flannel> Yasumoto: not that I found. There's no "cdburn" module or whatnot 21:30 < nhaines> Yasumoto: not in Python, no. 21:30 < Yasumoto> mm 21:30 < Flannel> http://avahi.org/wiki/PythonPublishExample and http://avahi.org/wiki/PythonBrowseExample 21:30 < Yasumoto> i mean, we can also use normal programs, just construct the command line statement 21:30 < Flannel> are the examples I'm talking about 21:31 < nhaines> Yasumoto: that's what we're talking about. 21:31 < Flannel> Although, if avahi acts stupidly (I haven't had a chance to play with it yet), we can use UDP broadcasts for the time being. That'd likely be theeasiest... 21:31 < nhaines> We'll use wodim. 21:31 < Flannel> thats cdrecord, yes? 21:33 < Flannel> Although, we'd end up doing UDP with confirmation, sort of silly, but still likely simpler than TCP streams 21:33 < Flannel> Avahi is our target through, right? Or is there something better for our "ideal"? 21:33 < nhaines> Avahi was the target, but it may end up being a little too complicated. 21:34 * Flannel fully admits that UDP with a confirm-reply is hackish, and is fully proud to pervert it in such a way. 21:34 < nhaines> wodim is a fruntend to everytihng else. 21:34 < Flannel> nhaines: oh, right. I misspoke earlier when I defined logic. 21:35 < Flannel> nhaines: It'd also be the ability to divvy out jobs to get the required CDs burned at the proper times. 21:35 < nhaines> Hrm. 21:35 < Flannel> (Fast CD burner gets the single Kubuntu image, slow CD burner gets one of the ten Ubuntu CDs, etc) 21:36 < Flannel> but, that's likely not for SCaLE. 21:36 < Flannel> but is a realistic, and useful (as opposed to silly pie-in-the-sky) server level logic 21:36 < nhaines> Yeah, that I don't worry about any time soon. 21:36 < Flannel> a simple FIFO will work fine for that now 21:37 < Flannel> but some sort of priority queue would likely be good in the future 21:37 < Yasumoto> avahi sounds like a good idea 21:37 < Yasumoto> Flannel: yeah, that sounds good 21:38 < Flannel> (that's why "I've finished burning, and am verifying" and "My CD passed/ My CD failed" responses are good) 21:38 < nhaines> Yup. 21:39 < Flannel> So.... now. Hooray for abstraction! 21:39 < Flannel> While we don't need to figure out communication details right away, I think that should probably be the first thing we focus on. 21:40 < Flannel> Figure out if Avahi willwork for us for SCaLE, 21:40 < Flannel> and figure out a protocol (either for Avahi or UDP) 21:40 < Flannel> They'll still need some sort of protocol, regardless of how they get sent 21:40 < nhaines> Yup. 21:41 < Flannel> We can do that (And test it) with stubs for most of the other functions 21:42 < Flannel> I'm not really sure how functional programming works in a daemon sort of program. 21:42 < Flannel> nhaines: care to enlighten? 21:42 < nhaines> heh 21:43 < nhaines> Usually there's a main loop, and a thread for each network request. 21:43 < Flannel> If I was coding this on a microcontroller I'd be fine. But I'm trying to get the full python experience ;) 21:43 < nhaines> I'm going to be investigating this thoroughly when I write FlingURL. 21:44 < Flannel> So, are we just pretending we've never heard of python then, and I can write like a regular person? (for the time being?) 21:45 < Flannel> Just standard OO sorts of stuff? 21:45 * Flannel isn't sure the client needs to be OO, actually. 21:45 < Flannel> just procedural 21:45 < nhaines> Heh. Just right it normally, and yeah, we can make the code more Pythonic later. 21:46 < Flannel> Woohoo. 21:46 < nhaines> Oh, Python fully supports both procedural and OO programming. 21:46 < nhaines> Didn't you know? :) 21:46 < Flannel> No, I know that 21:46 < Flannel> but python "is" functional 21:46 < Flannel> but... state-less + networking + Cd recording... just doesn't sit right. 21:46 < Flannel> Too many state based doohickeys 21:48 < nhaines> That's why I wanted to do it the way I did. 21:48 < nhaines> It'll all work out. 21:48 < Flannel> Well, python is procedural, you just said that ;) 21:48 < Flannel> right tool for the job, etc. 21:49 < Flannel> burning slaves are glorified state machines, really. They don't need overhead for other stuff 21:50 < nhaines> Ah, engineers. :) 21:50 < Flannel> Mhmm. 21:50 < Flannel> nhaines: Did you hear my talk with jess earlier? 21:50 < Flannel> About the hardware I'd like to make for this in the future? (it'd be an interface to the server, basically) 21:51 < nhaines> Flannel: Oh, just briefly. Sounded fun! 21:53 < Flannel> Yeah. Although if we're doing it over ncurses, it may not be needed 21:53 < Flannel> I assumed we could use USB/serial port instead of a monitor to display stuffs 21:54 < nhaines> That would be awfully nice. 21:54 < Flannel> but I imagine you'll just wind up using your phone ;) 21:54 < nhaines> heh 21:54 < nhaines> That could also be possible. ;) 21:54 < nhaines> Although battery life is rather disappointing. 21:55 < Flannel> but yeah. It (the interface box) is definately doable. Just probably not for this year, especially because we have to worry about the core before the accessries 21:55 < Flannel> Hmm, so... anything else? 21:55 < nhaines> Not too much. 21:56 < nhaines> I don't like the way buntulist works, but it's more than enough for ISO detection. 21:56 < Flannel> Well, we don't have to really use it. Especially for SCaLE 21:56 < Flannel> We can more or less sanitize everything. 21:56 < Flannel> as far as ISO stuff is concerned 21:57 < nhaines> It just does a little regex over some directories. 22:00 < nhaines> I like it, just not how it works. :) 22:01 < Flannel> Gah. Now I'm coding like it'd be VHDL 22:02 < Yasumoto> Flannel: AHHH! VERILOGG! :-X 22:02 < Flannel> booo verilog 22:02 < nhaines> We'll get it cleaned up. Which part are you working on? 22:02 < Flannel> Just... a generic pseudocode thing for the client 22:03 * Flannel is a firm believer in top-down 22:03 < Flannel> Although, I'm not quite doing top-down. More... medium-down 22:03 < Flannel> I just realised how long its been since I've coded something that wasn't VHDL 22:04 < nhaines> heh 22:04 < nhaines> Python nearly *is* pseudocode. 22:04 < Flannel> blah blah blah 22:04 < Flannel> my pseudocode uses squirrely brackets 22:04 < Flannel> (my pseudocode tends to be C/C++, without implementation details usually) 22:06 < nhaines> >>> from __future__ import braces File "<stdin>", line 1 22:06 < nhaines> SyntaxError: not a chance 22:19 < Flannel> nhaines: http://paste.ubuntu.com/85439/ 22:19 < Flannel> I... think that's it? 22:20 < Flannel> Like I said... it looks like hardware. And some of the assignments are == (although I think I got rid of them) because in vhdl = is compare, an <= is assign. 22:31 < Flannel> That assumes some tidbits about the tray, how we check MD5s, and how we burn. And that they're started, and then get polled 22:32 < nhaines> Well, I suppose that's one way to do it! 22:32 < Flannel> Heh 22:32 * nhaines isn't used to writing state machines. 22:32 < Flannel> I didn't used to be either. But... I haven't done "real" software coding... well, in a while 22:33 < Flannel> and Ive been doing VHDL for a year and a quarter now. Well, plus uC stuff, but many times thats more functional programming than otherwise. 22:34 < Flannel> please come up with another quick version so I can... come back to the real world 22:35 < nhaines> Hrm. 22:35 < Flannel> Next week I'll have to revisit all of my pre- EE code, and remember software 22:38 < nhaines> I'm trying to think of what we'd do for cleanup before quitting. 22:38 < Flannel> what do you mean? 22:39 < nhaines> I'm trying to think of how to kill the service. 22:39 < Flannel> server or client? 22:42 < nhaines> Client. 22:42 < Flannel> Issue a command from the server (instead of "burn this CD" issue "Go away") 22:43 < Flannel> We can't count on clients having keyboards, etc. 22:43 < Flannel> Also, 22:43 < nhaines> That's what SSH is for! 22:43 < Flannel> you can have, before checking the internet for commands, it checks a file 22:43 < Flannel> if the file exists (or contains something) 22:43 < Flannel> it does that. 22:44 < Flannel> So, locally, you can have it go away as well 22:44 < Flannel> echo "close" > /whatever/path/command 22:45 < Flannel> or echo "ubuntu 8.04" > /whatever/path/command 22:46 < Flannel> nhaines: That would mean that you'd have to give ssh access to your box to arbitrary people 22:46 < Flannel> having a way to hang up from "either" end, is a good idea. 22:47 * Flannel enjoys putting random commas, places