Sunday, December 14th, 2008, 7:00pm (1900) PST

Summary

1. 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!
2. 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)
3. UDS recap (Not previously on the agenda)

   • The Jaunty Ubuntu Developer's Summit (UDS) took place at the Google campus in Mountain View from Monday December 8, 2008 to Friday December 12, 2008 Schedule | Videos

   • 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.

4. Case badges (Also not really on the agenda, but tangentially brought up)
   • We still have 'em!

Original Agenda

1. SCaLE Planning!
2. December 28 meeting?
3. UDS recap (Not previously on the agenda)
4. Case badges (Also not really on the agenda, but tangentially brought up)
5. 'Buntustand
6. Join us after this meeting for some planning and/or discussion about 'buntustand! Which we hope to have functional in time for SCaLE.

Logs

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