lca2011 – Fri session 5 – Open source in education

Open Source in Education – ASHS One Year On by Patrick Brennan

  • Followup to last year
  • greenfield school – flagship school – no classrooms, learning commons, 2 floors of open plan
  • 2011 enrolments 740 – 16-18 year olds
  • open for teaching 4 days per work, 5th day do “impact projects” eg work to raise money for charity, local video storage system
  • Ubuntu Desktops, teacher laptops
  • Xero for account
  • Mandriva Servers
  • Terminal servers for edge cases
  • Cloud Apps
  • Single sign on
  • Windows remains for building management
  • Education space Microsoft ffocussed
  • Heavily subsidised by the MoE and Microsoft
  • Established Norms / established design refs
  • Perception that students should train with “real world” tools
  • Free as in beer vs free as in freedom
  • Licensing costs – NZ Govt / MS Subsidised – My Opinion underhanded monopoly
  • Learning tax – expensive for software at home – leads to piracy
  • Web filtering
  • MOE funds watchdog to 10Mb/s
  • $5000 to install Cisco device supporting 100Mb/s
  • Coast to support watchdog to 1Gb/swith existing FW $0
  • “Dill” provide no installed OS on desktops
  • Teachers working out how to do with tools, sharing techniques on eduwiki with other schools
  • No learning tax yields freedom
Share

lca2011 – Fri Session 3 – Lightweight messaging

Lightweight messaging for a connected planet – Andy Piper

  • The internet of things, smart devices in our hands
  • Instrumented, interconnect, intelligent
  • MQTT = MQ telemetry transport
  • publish/subscribe paradigm.
  • Optimized for Low bandwidth, high latency, unreliable, high cost networks
  • Expect client apps to have limited processing resources
  • provide QOS where possible
  • simple semantics, minimized format ( 2 bytes minimum packet )
  • “last will and testament” to publish if client goes offline
  • what about HTTP – MQTT much simplier, message not document centric, less verbose, lightweight
  • variable QOS
  • Free Client API / libraries for most languages, various propriety products as well
  • various examples
  • IBM rsmp official client – free for personal use, various binaries for many platforms
  • http://mosquitto.org – packages for various dists, windows, Mac. Open source , python and C++ examples
  • Random stuff – file syncs, desktop notifications, digital to analogue readouts, LEGO microscope control
  • Smart meters, heathcare patient monitoring
Share

lca2011 – Friday Session 2 – & habits of PMs

The 7 Habits of Highly Ineffective Project Managers – Carol Smith

  • Works in summer of code office, previous network operations, enterprise software
  • 11 interviews at google to get her position
  • Habit 1 – spend more than 2 weeks in meetings with engineers, “makers schedule vs managers schedule” by Paul Graham
  • Habit 2 – Assuming all the engineers you work with are purposefully tryin g to do a bad job and sabotage the project
  • Assume competence – People want to take pride in their work and do a good job
  • Habit 3 – Keep a checklist – creates a big gant chart, bugs engineers constantly about status
  • Needs to be familiar with technology and project to understand what engineering is talking about when there are problems
  • Habit 4 – Let middle and senior level managers meddle with timeline
  • maintain credibility and managers will feel less inclined to meddle
  • Habit 5- make everything an emergency
  • Don’t cry wolf – get people to understand if you do say something has to be done today it really does
  • Habit 6 – Break down rapport with engineers whenever possible
  • cookies
  • don’t use small cookies to reward directly, use to build rapport not reward directly
  • Habit 7 – Assume that the dates engineers give you are spot on
  • engineers will try and tell you something will please you, under promise and overdeliver, take past estimates from that person into account
Share

lca2011 – Fri Session 1 – LinuxCNC

All Chips , No Salsa – Bdale Garbee

  • Got tabletop 3-axis mill 2nd hand, sloppy but got useful work
  • Bought new mill in 2006 305x765x560mm working volume + CNC conversion kit
  • EMC2 – open source machine control system
  • EMC2 – HAL between layers – very modular – real time – Linux user interface – “axis” user interface – “trivkins” control module
  • Open vs  closed loop. Closed loop tools feedback to controller to tell it result of commands issued
  • stepping vs servo motors
  • Pluto-P board – parallel port connected – source and open drivers – not open hardware but “obvious” FPGA so transparent
  • Amps boast 3.3 volt to 60-80 volts at several amps
  • Use windshield wiper motors to test before rigging up to big stuff
  • wires enclosed in clear vinyl tubing
  • http://gag.com/homeshop
  • HeeksCAD / HeeksCNC
Share

lca2011 – Fri Keynote – Mark Pesce

Smoke Signals – Mark Pesce

  • 1 billion seconds since learned to code ( 1979 )
  • Programmed for wide range of platforms
  • Inspired to “Neuromancer” to get into VR, Setup Ono Sendai to create VR game console
  • Companies failed cause they wanted whole market, locked down with patents etc
  • Tried more open method, created 3D browser for VRML over www. 17 years ago
  • “a resource shared is a resource squared”
  • Tried to give away as much as possible, the richer I become, more ways than financially
  • smoking habit picked up from our friends, spreads like a epidemic
  • Similar affect for overweight people
  • Similar for divorce
  • What we choose to imitate is determined by the network of our peers
  • Choose your friends carefully
  • Digital social network can be bigger than 150 limit. Average facebook 30 though
  • Facebook itself is part of your social graph
  • facebook knows stuff about you that you would never tell any one friend
  • We surrendered all our personal details to a closed source system
  • wikileaks kicked off various commercial service, coincidental terms of service violations presumably under govt pressure
  • “The Internet is fundamentally not free”
  • The internetv is now hostile since it is controlled by govts etc
  • Distribute everything – lesson of Napster, no central target, break up components, whole greater than parts, redundant parts, extension of unix progs, pipes, widely distributed
  • Transport Independence – cellphone networks central org able to be controlled by govt, uucp and fidonet decentralized communication networks,. hierarchy efficient but vulnerable. Must look at alternatives, speed and convince might have to be sacrificed
  • Secure everything – Security for simplicity is a false tradeoff. Personal data is valuable
  • Open everything
  • Resilience – above principles led to this. may be less efficient.
  • Resilience , safe, fast – pick 2
  • Plexus – Mange you own social graph
  • Number of people with mobiles = Number of people earning more than $1.50 per day
Share

lca2011 – Thus session 6 – Building RPMS

Building RPMS – How Fedora’s Koji Works, and how you can use it to build your own software – Dennis Gilmore

  • Koji – task scheduler, results tracker, used by fedora and redhat as a build system
  • Not – no software release life cycle, not deployment, repo mngt, continuous integration
  • Goals – build repoducability
  • Components – mock, yum, rpmbuild, createrepo
  • mock – creates a chroot for each build, executes commands, out->results location, ensures output is controlled and repeatable, builds on yum
  • yum – reads software metadata, installs rpm packages
  • rpmbuild – converts bare components into binary package , spec file + tarball + patch files – scrpm and binary rpm
  • various koji components
  • kojihub – xml-rpc – passive application – controls wring to fs – talks to DB
  • kojira – manages repo
  • kojid – runs mock to build rpms, createrepo to general repos, polls hub for new tasks
  • koji-web view status of things, can sign up for notifications, cancel and resubmit tasks
  • koji cli – users, tasks, permissions
  • Other tools can use koji
  • Other tasks  – live CDs – Appliance creation – Maven builds – windows builds(!)
  • koji org – tags ( pack name and option additional arch) – targets ( build tag and destination ) – unique nvra ( name version release arch) for all rpms
  • Live demo
  • mash tool to get things out
  • extend via koji-api
Share

lca2011 – Thur session 4 – Changing X dev process

Changing the X server development process – Keith Packard

  • Old Old model – Everybody commits to master, at some point only do “necessary patches” , release manger
  • cuts release at some point – didn’t scales to lots of devs
  • Old model – everybody to master – release branch made – additions by editing wiki page adding ids –
  • release manger cherry picks
  • lack of testing of release branch, a bit of overhead, 4-5 releases
  • Idea to copy Linux kernel
  • New Model –
  • only one person commits to master
  • Some people publish own trees
  • Some people send patches to xorg-devel, easy entry
  • All patches need to be reviewed before being merged
  • Not quite the Linux model – only general agreement needed to merge – release management more
  • mechanical, just checking patches have review, merge cleanly, testing after each patch
  • Why Change?
  • bad at hitting scheduled dates
  • git master frequently unstable, sometimes not even build-able
  • little discussion about even major changes
  • limited release testing, largely caused by instability of master
  • 6 month release period, aligned with fedora, ubuntu, meego
  • last 2 releases 4 days slip and 0 day slip
  • Context 1-5 – 1.7 very active dev period, 100,000s LOC removed
  • all commits are supposed to be reviewed
  • not to worried if reviewer comes from same company as long as they are credible and know that area.
  • contributors 50-100 per release, dropping a bit in 1.8 and 1.9
  • Big jump is patch related threads and other threads on mailing lists?
  • Success?
  • dramatic reduction in LOC changes
  • Dramatic increases in communication
  • Hitting releases on time
  • Meet original objectives
  • lack of useful test suite
  • testing to just make sure basic build
Share

lca2011 – Thur session 3 – Open dev at apache

Noirin Shirley – Baby steps in Open source development at apache

  • 90 projects, starting with every letter but “y”
  • various types of projects
  • No corp members or contributers
  • Decisions only on mailing list
  • From inside – national building
  • Not insistent on using specific technology
  • How to do open source the apache way
  • need to cooperate, follow directions, communicate,
  • reading docs, look at existing coding style, read list for a while
  • Mind you manners, careful of mis-understandings
  • communicate clearly – email guidelines
  • apache incubator – projects first entry, existing codebase, time to get up and running, legal and other
  • formal procedures
  • play well with others, consensus on change to code etc, can’t veto a release (just 3 members needed)
  • Google summer of code.
  • Apache mentoring program
  • Accepts none pure “code” projects like documentation, testing
  • Working with formal education, two classes of students being mentored
  • Meetups encouraged, works well if you meet people in person
Share

lca2011 – Thur Session 5 – Use the force

Use the force Linus – Jon Oxer

  • Usability, computing falacies
  • The best UI is no UI
  • Things should just work, you should have to do anything.
  • eg your door should just unlock for you, not for others
  • eg your TV should just play what you are watching, stop when you move away
  • Story about reverse engineering of Kinect scanner for linux
  • Demo of controlling helicopter via gesture
  • Demo of controlling curtains
Share

lca2011 – Thur Session 1 – Kernel Development

Kernel Development – How things go wrong – Jonathan Corbet

  • Kernel dev a success – ~4.5 releases/year
  • Linux soon to your toothbrush
  • Why talk about failure? Gives kernel process a bad name, scares people off, bad press, failure can teach us
  • Note: The kernel community does not lack for clowns – won’t be covering them, names named here are people he respects
  • Example 1 – tux3 file systems by Daniel Phillips –
  • 2008/07 announced , 2008/11 booting , 2009/08 last commit – project now dead
  • Do NOT add stuff to out-of-tree project, merge early
  • Lesson out of tree code – for users, few contributers, invisible, have to keep sync’d with mainline, harder work
  • Lesson – get in mainline early
  • Example 2- em28xx video4linux driver
  • 2005/11 merged , 2008/01 last patch by ori author, 2009/08 author leaves completely
  • “People submitting code have to be aware they will lose control”
  • eg 2004/05 Hans Reiser tries to block updates to reiser3 fs , wanted to keep control and concentrate on reiser3
  • maintainership does NOT mean ownsership
  • Example 3 – 2.5.x IDE
  • 2002/02 Martin Dalecki’s IDE cleanups , 2002/03 IDE18 subsystem takeover , 2002/08 IDE115 merged, 2002/08 Martin’s quits all IDE work reverted
  • What happened? – “Breakage is the price you have to pay for advancements” – martin Daleski .
  • Kernel intolerant towards regressions, listen to people who complain
  • Example 4 – Deadline Scheduler
  • 2007/03/ first post, 2 days later Linux likes, 2 weeks later Linus get irritated (due to regressions), 2007/04 Molnar posts CFS, 2007/07 CFS merged, 2007/07 Con leaves
  • Con leaves unhappily
  • Lessons – Improve for everybody, not just a small set, at least don’t make it worse
  • Lessons – Some parts of the kernel are hard to change
  • Lessons – Participate in the wider kernel mailing list discussion, not just list that is for your changes, subsystem
  • Lessons: Aim for the solution to the problem, not for the inclusion of specific code
  • Example 4 – reiser4
  • 2002/10 First code post, 2003/07 merge request, 2004/08 added to mm, 2005/09 push 2.5.14 , 2006/07 push 2.6.19 , 2006/10 arrested
  • Problems – Non-POSIX behavior , numerous technical difficulties , hard-to-reproduce benchmarks, antagonistic approach to others, memories of reiser3
  • lessons – Linux is not a research system
  • Lesson – visionary brilliance will not excuse pore implementation
  • lessons – it’s best not to access others of conspiring against you
  • lessons – community remembers the past and thinks far into the future
  • Example 5 – systemtap
  • 2003/11 Dtrace debuts, 2005/10 rhel4 introduces systemtap, 2008/07 Ftrace merged, 2009/06 perfevents merged, 2009-09 systemtap 1.0 released, Not yet merged possibly never
  • 2008 kernel summit, 50% had used systemTap, 20% had succeeded
  • bad sign if even kernel devs can’t make it work
  • lesson- if kernel dev community doesn’t see value, it won’t go in
  • Example 6 – Talpa – provide hooks for anti-virus
  • posted in Aug 2008, never merged as such
  • Problems – Kernel devs didn’t like, why broken security model, badly expressed requirements
  • But – fanotify is accepted, same authors, similar code
  • What changed – cleaned up file event notification (replace inotify and dnotify)
  • What changed – Enable virus scanners to hook into file ops without using rootkit techniques
  • lesson – sell to developers not to mangers or customers
  • lesson – user-space API matters, hard to change later
  • Example 6-15 posted
  • Why bother? – “Why not hack on CMSses or something else where the standards are a little lower”
  • Fun!
  • Elite club
  • you will get job offers
  • Influence – how the kernel meets your needs
  • VFS filesystem patches by Nick Hagen(sp) – worked – intrusive and tricky code – good code – listened to people – didn’t behavior for people, all behind the scen
Share