From Michael.Paoli at cal.berkeley.edu Tue Jan 10 10:27:15 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Tue, 10 Jan 2012 10:27:15 -0800 Subject: [buug] BALUG Tu 2012-01-17: Grant Bowman[1] on Spreading Open Source in Nairobi, Kenya Message-ID: <20120110102715.44785v5p33ltc4kk@webmail.rawbw.com> BALUG Tu 2012-01-17: Grant Bowman[1] on Spreading Open Source in Nairobi, Kenya Bay Area Linux User Group (BALUG) meeting Tuesday 6:30 P.M. 2012-01-17 Please RSVP if you're planning to come (see further below). For our 2012-01-17 BALUG meeting, we're pleased to present: Grant Bowman[1] on Spreading Open Source in Nairobi, Kenya Mr. Bowman spent September, October and November 2011 working with young adult graduates of a technology school (Nairobits)[2] hosted by Dreamfish[3] CEO Dr. Tiffany von Emmel in Nairobi, Kenya thanks to the generous support of Dreamfish members and donors. Nairobi is one degree below the equator eleven time zones away just inland from the Eastern coast of Africa. Dreamfish is a global peer development network connecting entrepreneurs and individuals working together to realize their dreams. Dreamfish is co-owned by hundreds of women entrepreneurs, youth entrepreneurs and professionals in 26 countries. The Community Tech project's goal is to use open source to connect people working all over the world, from the Rift Valley to the Silicon Valley using web and mobile technologies. Primary PHP software packages being customized are status.net[4], wordpress.org[5] and more. Working five days a week the graduates were exposed to many ideas and topics including ica.coop[6], English language classes, revolution-os.com[7], laptop.org[8] (OLPC) / olpcsf.org[9] / give one get one, toms.com shoes one for one[10], ARRL[11], Wi-Fi and Ubuntu[12], Fedora Project[13], Android. Mr. Bowman used the ground breaking Safaricom M-PESA branchless banking system popular in Kenya, Tanzania & Afghanistan - M stands for mobile and pesa is Swahili for money. During his stay he, Tiffany and the graduates presented at Nairobits, introducing 47 students to open source software, user focused design (UX), web development infrastructure and the command line. Ubuntu Hour[14]s were held every other week at *iHub_Nairobi[15] helping the Ubuntu Kenya Local Community Team[16] become more active again with the support of Ubuntu California[17]. Mr. Bowman has been a consultant and Internet professional for over twenty years including a former Director of Silicon Valley Public Access Link (SV-PAL)[18] ISP serving Santa Clara County and a present Director of Partimus[19] serving San Francisco and Alameda County middle schools with recycled computers, open source software, training and support. He is an OLPC Developer, Ubuntu Member, Fedora Ambassador, Debian Developer and former employee of SUSE[20]. Active Habits[21] is a forthcoming Android app. He is also active with Berkely Linux Users Group[22], Berkeley Unix User Group (BUUG)[23], Noisebridge[24], San Francisco Linux Users' Group (SF-LUG)[25] and also Diablo Valley Linux Users Group (DVLUG)[26] (every Friday in Walnut Creek). His website is: http://www.grantbow.com/[27] 1. http://www.grantbow.com/ 2. http://nairobits.com/ 3. http://dreamfish.com/ 4. http://status.net/ 5. http://wordpress.org/ 6. http://www.ica.coop/ 7. http://www.revolution-os.com/ 8. http://one.laptop.org/ 9. http://olpcsf.org/ 10. http://www.toms.com/our-movement/movement-one-for-one 11. http://www.arrl.org/ 12. http://www.ubuntu.com/ 13. http://fedoraproject.org/ 14. https://wiki.ubuntu.com/Hour 15. http://ihub.co.ke/ 16. https://wiki.ubuntu.com/KenyanTeam 17. https://wiki.ubuntu.com/CaliforniaTeam 18. http://www.svpal.org/ 19. http://partimus.org/ 20. http://www.suse.com/ 21. http://www.activehabits.com/ 22. http://www.berkeleylug.com/ 23. http://www.buug.org/ 24. http://www.noisebridge.net/ 25. http://www.sf-lug.com/ 26. http://www.dvlug.org/ 27. http://www.grantbow.com/ So, if you'd like to join us please RSVP to: rsvp at balug.org **Why RSVP??** Well, don't worry we won't turn you away, but the RSVPs really help BALUG and the Four Seas Restaurant plan the meal and meeting, and with sufficient attendance, they also help ensure that we'll be able to eat upstairs in the private banquet room. Meeting Details... 6:30pm Tuesday, January 17th, 2012 2012-01-17 Four Seas Restaurant http://www.fourseasr.com/ 731 Grant Ave. San Francisco, CA 94108 Easy PARKING: Portsmouth Square Garage at 733 Kearny: http://www.sfpsg.com/ Cost: The meetings are always free, but for dinner, for your gift of $13 cash, we give you a gift of dinner - joining us for a yummy family-style Chinese dinner - tax and tip included (your gift also helps in our patronizing the restaurant venue and helping to defray BALUG costs such treating our speakers to dinner). ------------------------------ CDs, etc.: Additional goodies we'll have at the meeting (at least the following): CDs, etc. - have a peek here: http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc We do also have some additional give-away items, and may have "door prizes". ------------------------------ Want to volunteer to help out BALUG? (quite a variety of opportunities exist) Drop us a note at: balug-contact at balug.org Or come talk to us at a BALUG meeting. ------------------------------ Feedback on our publicity/announcements (e.g. contacts or lists where we should get our information out that we're not presently reaching, or things we should do differently): publicity-feedback at balug.org ------------------------------ http://www.balug.org/ From Michael.Paoli at cal.berkeley.edu Wed Jan 18 20:18:45 2012 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Wed, 18 Jan 2012 20:18:45 -0800 Subject: [buug] UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time) Message-ID: <20120118201845.199123u3axdiey00@webmail.rawbw.com> UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time) So ... one of the things I brought up at last BUUG meeting (unfortunately looks like I won't make this week's meeting - have a calendar conflict ... hopefully someone there can bring or fashion some reasonable facsimile of a BUUG sign/placard) ... setting system default "local" time to UTC - various pros and cons and considerations (and for system that's typically not physically located in UTC/GMT0 - and may or may not travel about and/or be relocated). Teensy background - I've been setting up my new personal laptop ( Debian GNU/Linux 6.0.3 "Squeeze" - Official amd64; old (over 8 years old) personal laptop started seriously failing 2011-11-27) ... and when it came to matter of setting default "local" system timezone, I was thinking, why *not* UTC? :-) Decision's not exactly cast in stone, but thus far I've set it up using UTC. So, ... considerations, advantages, disadvantages, etc. Pros: o system log submissions/comparisons: a key advantage of UTC is system (and security) logs. E.g., in many cases, other organizations/entities/person(s) won't even look at, review, consider, or accept log data, unless it's UTC. This is, e.g., particularly the case often when reporting Internet security incidents. o fairly logical timezone for system that does or may travel a fair bit (e.g. laptop) o fairly logical timezone for organization(s)/entities, etc., that span multiple timezones o relative immunity to relocations and timezone law changes (e.g. corporate headquarters or data center moved to a different timezone? Or changed one's country's timezone due to primary economic trading partners?) o general reduction in ambiguity and confusion - e.g. timezone of PST8PDT / US/Pacific - log indicates Sun Nov 6 01:30 or 1:30 AM ... was that PDT or PST ? - as both occurred. o cron/crond/crontab - avoid all that ambiguity about when stuff will run across time or timezone changes or transitions - e.g. to/from Daylight Saving Time / Summer Time, or if changing system timezones due to travelling/moving/moved system (e.g. laptop) or political/legal reasons (changes in law). Cons(?): Not a whole lot, but here are the ones I'm aware of: o cron/crond/crontab - it has and runs in just one timezone at any given time, might be confusing - particularly for mere mortal regular users, if it's not running in the actual local timezone where system is (or at least primarily is) located. (There are probably ways to partially mitigate that - but not fully - at least presently?) o "user" confusion(?) - some/many users may be at least somewhat (more) confused if the default system timezone isn't the actual local time where the system is (or typically is) located. There are, however, ways to (mostly) mitigate that. E.g. /etc/skel files can be set up so that by default, regular user accounts are configured to use a more customary timezone, e.g.: ! [ -r "$HOME"/.TZ ] || ! [ -f "$HOME"/.TZ ] || . "$HOME"/.TZ and with suitable .TZ default file. Also PAM or similar might be potentially quite useful to generally ensure "regular user" sessions have a suitably set timezone, at least initially by default, and pretty much regardless of at least most of the various means by which such a "user session" was initiated. Various communication(s) - particularly when account is first issued, and perhaps at least occasionally or more often thereafter (e.g. a reminder line in /etc/issue and/or equivalent(s)) - perhaps also with pointer(s) to relevant information/documentation o with a UTC system default timezone, and (many/most) users using other timezone(s), examining/comparing/contrasting - especially directly user generated - logfile information and the like, may be a bit more confusing. But do note however that generally users can always set their timezone anyway, so there's always at least some ambiguity or potential confusion there anyway. o "localtime" - for many utilities, library calls, even some filename(s), etc. - if UTC is system default timezone (but system isn't physically in UTC timezone), then "localtime" is a bit misleading. Maybe those ought instead to say systemdefaulttimezone or something like that ;-) ... but a wee bit late to change that :-/. Anyway, those are most of my thoughts on the matter. Thus far I'm using and generally leaning towards UTC for default "local" system timezone. If the user base were broader, I'd probably also have some /etc/skel adjustments - and some communication/notification bits in place, and likely also some scripts/hooks in place on setting up accounts - e.g. for "regular user" accounts, would likely want them to have a customary local timezone set up for them (at least by default), but, e.g., various system utility accounts that may get created - would probably want most of those to generally default to using the system default "local" timezone. Oh, and hardware clock - let's not even get into that :-> UTC is and always has been the right way to do that. :-) (possibly notwithstanding some occasional twisted desires to be compatible and relatively co-existent with some drain bamaged excuses for an operating system - or maybe even very broken hardware?) So, ... curious, ... your thoughts? :-) From nick at zork.net Thu Jan 19 02:44:45 2012 From: nick at zork.net (Nick Moffitt) Date: Thu, 19 Jan 2012 10:44:45 +0000 Subject: [buug] UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time) In-Reply-To: <20120118201845.199123u3axdiey00@webmail.rawbw.com> References: <20120118201845.199123u3axdiey00@webmail.rawbw.com> Message-ID: <20120119104445.GQ1974@zork.net> Michael Paoli: > Pros: [...] > o general reduction in ambiguity and confusion - e.g. timezone of > PST8PDT / US/Pacific - log indicates Sun Nov 6 01:30 or 1:30 AM ... > was that PDT or PST ? - as both occurred. Don't forget that with UTC you're guaranteed a 24 hour day. This means that you won't wonder over the 4% anomalies in statistics on the DST switchover days. A 23 hour or 25 hour day will make it hard to compare apples to apples in your data. -- "Ill-informed qmail-bashing is better than no qmail-bashing at all." --Don Marti From togo at of.net Thu Jan 19 17:14:19 2012 From: togo at of.net (Tony Godshall) Date: Thu, 19 Jan 2012 17:14:19 -0800 Subject: [buug] the 24 hour day, and even missing days [Re: UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time)] Message-ID: > ... Don't forget that with UTC you're guaranteed a 24 hour day. ?... Well, there will be a leap second or two later this year... Also with UTC you are guaranteed you won't have a whole day lost or gained. Samoa skipped a day last month[1]- I'll bet Samoan sysadmins are UTC proponents. T [1] https://en.wikipedia.org/wiki/International_Date_Line#Samoan_Islands_and_Tokelau From excelblue at gmail.com Fri Jan 20 23:28:39 2012 From: excelblue at gmail.com (Mark Lu) Date: Sat, 21 Jan 2012 07:28:39 +0000 (UTC) Subject: [buug] Invitation to connect on LinkedIn Message-ID: <2044661192.428852.1327130919990.JavaMail.app@ela4-app0128.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Mark Mark Lu Software Engineer at Famo.us San Francisco Bay Area Confirm that you know Mark Lu: https://www.linkedin.com/e/3r6trd-gxobhfle-17/isd/5602760116/isp6HEHv/?hs=false&tok=0EkgvUEXv0wl41 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/3r6trd-gxobhfle-17/Lj5Q6HByeC6bC-zQMJ1SuRy/goo/buug%40weak%2Eorg/20061/I1948892535_1/?hs=false&tok=2WpPDL_pX0wl41 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: