Work shuffle

Work recently had a bit of a reorg and my “infrastructure” team (me and two other guys who look after the hardware, network, database,  OS and everything apart from the the actual website code) were moved from the “online” division to “Central IT” . Next week we physically move down to the basement (yes, really) to be with the rest of IT.

Note: One of my rules of seating is “always be as close to marketing as possible” . This is because marketing (usually) have a bit of clout in any organisation and will always get at least semi-decent offices with things like windows, pool tables, working lifts etc. Departments like IT, Helpdesk, accounting and security on the other hand have no pull and will get pushed into windowless dungeons whenever the reorganisations happen.

The main thing I’m worried about with my new job is that I’m not cut of from my “platform users” , we are about 2 minutes walk away (for now, potentially more later) so it’s not too far for meetings but certainly too far for unsceduled chats. So I won’t know if a major stoary is breaking (with the potential load on the system) just by watching frantic acticity any more, nor will I be able to walk a few metres to check a bug, ask somebody a questions etc.

Just last week we had a bug on the site for a few minutes that caused one article to 302 (temp redirect) to itself for about 10 minutes. I noticed the big jump in hits and was able to talk to the 2 editors in charged or the article and the head programmer right away. As of next week something similar will take much longer as I would either have to run upstairs (and be offline) or phone/skype people until I got hold of the right ones.

It’s a common situation with disjointed teams but it means that things have to get a lot more formal in order to keep the site reliable. So I’ll probably be spending the next few weeks going over rollout, escalation, ticketing and similar procedures because I’ll no longer be able to just turn around and yell to find out if somebody is running something causing a problem.

At least one good thing that’ll come out of this is that we won’t be doing the “level 1” helpdesk stuff for the dept any more, so we’ll be able to concentrate on our actual job.

Share

lca2011 – Fri Close

Apology re keynote material

Lightning talks

  • New policy on open source software in Govt, stronger, participate in community
  • Linux.conf.au in antartica. Cooler than brisbane, drier than wellington
  • other conferences by lca drupal down under, wordcampe, pycon. You run your own conf, LA may even support. Join planet LA, Join a LUG
  • Next 12 months in IP law: ACTA will happen in next 12 months. TPP might be stopped by NZers. Iinet decission very soon. DRM [cutoff]..
  • usbdoodad.info . Surface mount soldiering help, kits available
  • macbook people. not too hard these day. Get hold of reefer bookloaded. partition under OSX. Leave a gap between linux and OSX partition. testing many common distributions
  • LDAP. ldapauthmanager software
  • OSIA Open source industry australia. Join for advocacy & networking
  • Debian 6.0 released next week!
  • Donna promoting “Digitise the Dawn”
  • secan does ipv6 now says Rusty
  • Women in Open source, under-represented still. No funding. Suggested ideas if they had money. training courses. adainitiative.org – looking for funding for 2 years of full time work on women in open source.
  • SUDE studio – create virtual appliances
  • new conference in australia – oct 2011 – Sydney – php conf australia – twitter.com/phpconfau

Closeup

  • lca2012 in Ballarat
  • http://lcaunderthestars.org.au
  • 2013 bid process in next few weeks
Share

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