I am pleased to announce the linux.conf.au 2015 OpenStack miniconf programme. This will appear on the main conference schedule as well, but I am posting it here so I can provide the talk abstracts as well.09:00 – 10:00 Main conference keynote by Eben Moglen 10:00 – 10:40 …morning tea… 10:40 – 11:00 Welcome by Michael Still
Welcome to the OpenStack miniconf. This talk will outline the plan for the day, and then briefly introduce the various components of OpenStack to be covered for those who haven’t seen them before. 11:00 – 11:30 TBA 11:30 – 11:35 …five minute break… 11:35 – 12:00 Introducing OpenStack Swift by John Dickinson
Swift is the OpenStack object storage system. It’s perfect for unstructured data like backups, server images, documents, and media. Swift is built for scale (including global deployments!) and handles all the placement, durability, and failure conditions so applications don’t have to worry about it. This talk will introduce Swift, as well as covering all the things the Swift PTL wished people knew before they deploy Swift for the first time. 12:00 – 12:20 Juju Deployments at Canonical by Brad Marshall
This talk with cover a brief history of Openstack deployments at Canonical and show how it has changed over time. It will focus on our current deployment methodology using Juju and MaaS, and the HA features we are taking advantage of. 12:20 – 13:20 …lunch… 13:20 – 13:45 Deploying Nova by Michael Still
Nova is one of the most commonly deployed components of OpenStack, as most installs want to provide access to compute resources. This talk by the Nova PTL will cover the various hypervisor options, what instance storage backend might meet your needs, and all those other decisions you need to work through when deploying nova. 13:45 – 14:10 Introducing OpenStack Neutron by Mark McClain
Neutron is the OpenStack networking component. It is responsible for creating tenant networks that separate traffic between tenants, as well as advanced features like load balancing and VPN as a service. Neutron is incredibly flexible, which comes at the cost of some complexity. Join Mark the former Neutron PTL as he walks through the
deployment options available to OpenStack users. 14:10 – 14:15 …five minute break… 14:15 – 14:40 Extending Horizon to work in your Deployment by David Lyle
Horizon out of the box doesn’t fully meet the needs of a running cloud and looks rather generic. Product managers complain that Horizon’s base theme does not meet corporate guidelines and administrators complain that they need more tools to manage the cloud. How does Horizon help solve this?
One of the main tenants of the Horizon program is extensibility. There are several established ways to get custom content into Horizon depending on your goals. External extensions, template customization and custom stylesheets can meet most customization needs.
The talk will present these methods for adding custom content and updating the style, point out the potential pitfalls, and share knowledge as a Horizon developer and a Horizon deployer.
14:40 – 15:00 Handling RabbitMQ Failures Gracefully with HAProxy : Sachi King
Almost all communication between services in OpenStack transverse though a message queue. The current default is RabbitMQ.
The RabbitMQ implementation in OpenStack currently lacks support for both Heartbeats and TCP Keepalive. Without these features, the RabbitMQ clients do not reconnect on failure, thus resulting in a complete API outage.
This talk will cover how we worked around this limitation to allow for graceful recovery on failure with HAProxy. While there are many ways to architect HAProxy in the RabbitMQ path, we’ll touch on what worked, and what did not.
15:00 – 15:40 …afternoon tea… 15:40 – 16:30 Selling Mist: Better Metering Through Ceilometer by Sharif Olorin
Recording usage measurements with high resolution and granularity provides many advantages for both public and private OpenStack deployments. External customers are happier because they know what they’re being billed for. Internal customers are happier because they can receive immediate feedback on efficiency improvements. System
operators are happier because they can diagnose problems more effectively, get woken up less frequently and be more confident about who to cluebat when they do.
Achieving this at scale with Ceilometer is nontrivial without sacrificing either data longevity or resolution. This talk presents one solution to the problem of storing high-resolution metrics from OpenStack over the long term using the Vaultaire time-series datastore. I’ll talk about the architecture of our metering system, a few of the challenges we faced getting this system into production, and what we learned from doing so.
Finally, I’ll talk briefly about the Gnocchi time-series-database-as-a-service project, why I think it’s awesome,
and how we at Anchor intend to integrate it into our OpenStack architecture.
16:30 – 16:35 …five minute break… 16:35 – 17:20 OpenStack Operations for Engineers by Alex Tesch, Daniel Martushev, and Anthony Rees
We will discuss the most popular installation tools for OpenStack based on Puppet and Ansible and the key advantages for each of them, as well as give a quick demo of a PackStack installation in 5 minutes. We will also delve into HEAT and run through a HOT example that will orchestrate a full two tier architecture in 5 minutes. The session will close with a tech preview talk of Sahara and a quick demo to provision a Hadoop cluster in OpenStack.
I got a bit of bonus time to myself in the morning, because Zoe had a late breakfast out with Sarah for her birthday, so I used the time to finish off another unit of my real estate licence course and get it into the mail.
After Sarah dropped Zoe off, she watched a bit of TV before we headed off to the doctor to have another go at freezing off the wart on her hand, and to follow up on the suspected chicken pox.
Zoe's fever had resolved itself, and her spots looked like they were starting to fade. The doctor thought she probably just had a viral rash, and it definitely wasn't chicken pox.
Armed with that good news, I definitely wanted to get out of the house in the afternoon, because Zoe had been watching far too much TV.
Zoe said she wanted to go to the park over at West End, and I wanted to take her into the city in the evening to look at the lights, so I thought a good way to achieve both goals would be to take public transport over to West End and then back to the city.
As the Hawthorne ferry terminal is closed for some upgrades, and I didn't fancy walking home with a tired Zoe from Bulimba late at night, we drove as close to the Bulimba ferry terminal as we could find a park, which was incidentally right next to the Love Street park. Zoe had a bit of a play there, before we walked to the Bulimba ferry terminal and took the cross river over to Teneriffe, and jumped on the CityGlider all the way to the park at West End.
Zoe had a great time playing in the park, which was nice and cool and shady, before we jumped on a CityCat back to the city. We got off at North Quay, and walked down to the Mall and into the Myer Centre to escape the heat.
I'd promised Zoe a bubble tea the next time we were in the Myer Centre, so we went to the bubble tea place and shared one of them.
After that we were just sitting on the Mall taking a break, and Anshu's Mum happened to wander past, so she hung out with us. We went and grabbed some sushi for dinner and then Anshu met up with us.
I wanted to catch the Myer Christmas Parade and Pantomime while we were in there, so we assumed a spot where the parade was due to turn right onto Albert Street and head to King George Square.
The Mall was absolutely packed by the time the parade made it up to where we were, and if Zoe hadn't been on my shoulders she wouldn't have seen anything. I'm glad she got to see though. It was pretty impressive, and even had a Santa sleigh with a couple of deer.
After that we headed over to King George Square with the intention of seeing the Christmas tree get lit up. First we had to sit through the pantomime, which wasn't really worth it. Visibility of the stage was poor, but we sat (or rather stood) through it. Then we had to watch the Gold Lotto City Hall Light Spectacular, which was actually pretty good. All sorts of stuff projected onto City Hall.
That all finished, and everyone started leaving, but the tree still didn't get lit up. Upon enquiry, it seemed that it hadn't survived the most recent storm or something. So that was a bit disappointing.
Anshu and her Mum had headed home during the pantomime, and we headed back to North Quay to get a CityCat back to Bulimba. There was quite a wait. I think the CityCat was running behind schedule or something, and Zoe was getting quite tired and having a bit of a meltdown. Then the fireworks started as a welcome distraction. I didn't even realise there were fireworks scheduled, so that was a pretty cool added bonus.
Zoe fell asleep on the CityCat when I was staring out the window. I had to wake her up when we got to Bulimba, and that didn't go terribly well either, and we had a messy trip back to the car.
We made it back home, and I managed to get Zoe into bed without too much more fuss.
Have been struggling to come up with ideas for establishing myself within the music sector. Have been going through the possibilities and some of the following options look interesting.
When you are ready (have something worthy of selling to the public), submit your work to various music aggregators (and media outlets) for more advertising.
Hook up with relevant social groups to get you some interest.
Other options include the usual web specific blogs.
I've sometimes seen MIDI files being sold online. Who's to say that up and coming artists can't do the same for themselves. Even if you are just a composer or soemthing who's beginining to learn the business you still need to create stems and samples that may be worthy of selling (sample some of the discs from some music magazines) and you'll understand what I mean. Besides, a lot of the time you need composition pieces to be able to audition for music school (if you ever intend to do so). The easiest way that I can think of at the moment to gather interest is to basically, stick the sample on loop and then stick it on YouTube. You can sell it via an online market or else via something like, https://selz.com/
You may need to think about copyright difficulties if you decide to 'cover/copy' from another artist though.
Sell sound samples if you have anything worth sampling.
Sell synthesiser patch sets. Problem is that you often may not be able to sell anything if you don't have any music to be able to advertise your 'wares'. Stick the sample on loop on a group of notes and then run it through a presets at regular intervals to provide a sample of what the customer is being offered on YouTube.
Sell music making templates. Problem is that like a lot of other things there is a huge market to that you need to deal with. It's a bit of a chicken and egg problem here. You need music to have people want to purchase the template?
Another way is to simply make synthesiser software which is easily possible via Reaktor, create sample packs via Kontakt. A lot of the required documentation actually comes with the software to enable you to be able to create.
Have been having significant troubles with regards to running CPU load when running certain software synthesiser VSTs. 'Freezing' seems like the easiest option without having to upgrade hardware.
If you can't figure anything else for the moment try to monetise you're musical journey in the meantime.
Which reminds me there are some interesting options out there for those of you looking to simplify you're blogging environment (if you're running multiple blogs. Note that some of these options are no longer relevant and some services such as Tumblr and YouTube already have such facilities builtin).http://tweetymail.com/
I started the day off with my last yoga class of the year. It was a really nice one.
Zoe still had a bit of a low-grade fever when Sarah dropped her off, but her spots didn't look any worse.
We watched Frosty the Snowman on Netflix, and then had some lunch and popped out to the library to refresh Zoe's library books. After we got home, we watched The Polar Express on QuickFlix.
Zoe then took another longish nap.
After she woke up, she watched a DVD from the library for a bit.
Sarah arrived to pick up Zoe just before the latest storm of the season was about the hit, so they made a hasty departure.
Modems are an interface between theoretical physics and what can actually be built. The laws of physics set the limits of modem performance, and ultimately the amount of power you need for a certain bit error rate at a receiver. With the right algorithm, we can reach the limits of modem performance.
I think that’s kind of cool. There aren’t many fields where we can do the best the Universe can offer with 20th century technology. For example an internal combustion powered car is only about 15% efficient in converting chemical energy into motion. Solar cells on your roof are also about 15% efficient. We can’t do practical nuclear fusion. But 6 billion GSM mobile phones have a modem that is 100% efficient in converting received radio energy into bits. Unless you are my 16 year old son and keeping forgetting to charge it.
This week I’ve been getting my head around GSM modems, and have worked up an Octave simulation of a couple of GMSK modems called gmsk.m. I started with this commonly used, non-coherent algorithm for GSM demodulation:
It has the advantage of being compatible with data-port capable legacy FM radios. However the best I can do in my simulations is 4.5dB away from theoretical. So I went looking for a better (hopefully close to ideal) demodulator. After some reading about MSK and GMSK and several days of confusion I eventually managed to make this “coherent” demodulator work (from the 1981 Murota paper listed below):
The adders on the RHS operate on bits and are implemented as XORs. I don’t fully understand the processing steps, especially the XORs at the end. It’s derived from an interpretation of MSK as a form of Offset QPSK, and mysteriously the inphase and quadrature arms operate at half the bit rate. But it works really well, so that’s enough for now.
The term “coherent” means we know the phase and frequency of the received signal. Coherent PSK and FSK modems have ideal performance, and often have matched filter and “integrate and dump” stages. The integrator can be seen as summing all of the energy in the bit, that’s the “Eb” part in Eb/No.
Here are the performance curves for the two modems on Eb/No and C/No:
The non-coherent modem is a leaving a lot of bits on the floor. I also note my coherent demod outperforms the laws of physics at high Eb/No. I think I’ll build a warp drive next.
These simulations are some distance from a practical modem. The coherent demod needs clock and phase recovery and a lot of real word testing. However this is all quite possible (it’s in every mobile phone) and I’ve worked through similar steps for the HF FDMDV modem.
The non-coherent modem starts to perform (a BER of less than 1E-2) at a C/No of around 50dB. Curiously, this is where analog FM modulators start to get happy, from the recent post on FSK over FM:
So the non-coherent demod is a nice match to legacy FM radios. I’m not sure if analog FM demodulators would be effective at lower C/Nos, even when teamed with the coherent demod. So I’m not convinced it’s possible to retrofit the coherent demod to existing FM radios, but it’s certainly realisable with a $20 SDR dongle.
GMSK Demod Walk Through
This section has some screen shots of the two demodulators in action. First, here is (one half) of the GMSK signal spectrum:
The lower plot is the cumulative power, and 99% of the power is at the 2460 Hz point, making 4920 Hz bandwidth total. This gives a BW/Rs ratio of 1.02, close to the 1.04 expected for BT=0.5 GMSK at Rs=4800Hz. Nice.
Here is the “eye diagram” of the non-coherent demod:
This explains why the non coherent demod struggles. The low pass filter introduces significant inter-symbol interference. One symbol affects the next one as the LPF smears the symbols into each other. The eye is quiet narrow, even with no noise. A modest amount of noise can close the eye and we get bit errors. We can’t widen the filter as it will let more noise power in.
Here is the filter and integrator outputs from the coherent demod, one plot for the cos (real) and sin (imaginary) arms, with no channel noise:
Here are the integrator outputs with an Eb/No of 8dB:
It’s almost the same! Quite a lot of noise hardly bothers it, the BER is about 1E-3 (1 in 1 thousand)!
Ideas for VHF FreeDV
Now Codec 2 at 1200 bit/s sounds OK at an error rate of 1% (1E-2). Reading off the curves that’s a C/No of 42.5dBHz at 4800 bit/s or 42.5 – 10log10(4800/1200) = 36.5dBHz at 1200 bit/s. We need about 47dBHz for a 12dB SNR (ie scratchy) analog FM copy, or 50dBHz for a good FM copy. So that makes a proposed 1200 bit/s Codec 2 system 10dB ahead of analog FM. I can currently work the local repeater on 500mW with my $50 FM HT, so this proposed system could do it on 50mW. Cool.
Hard to say if people will actually like using Codec 2 over VHF. Quality expectations are different to HF SSB, and people are used to high SNR FM. If most FM signals are strong the extra low level performance of a new digital mode may not be useful.
However if speech quality is king with all that system gain we could user higher quality speech codecs at a higher bit rate. If we have a good C/No would can increase the bit rate and hence speech quality, push against the “digital ceiling” in speech quality. One disadvantage of GMSK is that we can’t scale the bit rate in high C/No channels without making the RF bandwidth wider. mPSK is better at this, we can raise the number of bits/symbol and get a greater data throughput in the same RF bandwidth.
The extra system gain allows us to to explore other options. For example two channel TDMA would let us build diplexer free repeaters. This would require running the modem at 2400 bit/s, to get an average of 1200 bit/s. The hardware complexity would be similar to a $50 HT. A 1 watt TDMA repeater based on SDR could be built for $100, and do all sorts of clever things like form mesh networks with adjacent repeaters. Sprinkle them about hill tops in a humanitarian disaster situation, they could be treated as disposable.
I do think a new VHF DV mode must have some significant advantages to gain traction. Here are my current ideas:
- An entry level implementation using freely downloadable software that runs on a PC, a sound card, and legacy FM radios through the mic/spkr ports. People get frustrated when told to upgrade all of their radio hardware to one particular brand to use DV.
- Be an open standard, with a high performance open source implementation. No annoying closed source components, license fees, and encouraging rather than prohibiting experimentation.
- Outperform legacy analog and digital modes.
- Diplexor less, trivially simple repeaters.
- Variable speech quality levels.
GMSK Modem Resources
Here is a good treatment of various Digital Modulation schemes from Atlanta RF. The Dsplog site has a good explanation and Octave simulation of MSK that helped me get my head around coherent (G)MSK demodulators. I implemented the demodulator from the 1981 IEEE Trans paper “GSM Modulation for Digital Radio Telephony” from Murota and friends. I think this paper originally proposed using GMSK for digital mobile phones.
Have created 'Classical' and 'Soundtrack' playlists on my YouTube profile. Not much there at the moment. I'll add more as time goes on.
I've been looking at doing a music course of some sort for a while now (short course or even a degree). Fees can range from several hundred to several thousand dollars.
There may be some government help but you must fit specific criteria.
There are, of course, some online options which will also provide certification of skills if you aren't keen on spending too much time on campus and/or don't have the time/dedication to go the other way. In most cases, you'll have to pass an audition of some sort though which involves a demonstration of proficiency, a portfolio, as well as possibly an academic pedigree (high school or private tuition).
There will be some websites which will often place there reference materials behind walls of some sort but with intelligent searching you can often find a way around these limitations without having to register/signup for further marketing material.
Some material on programming synthesisers.
A place where you can purchase parts to experiment with .
There are a lot of tablet based music making applications now .
Sometimes you don't have a vocalist nearby. An option is to try computerised vocals.
Sometimes, I have difficulties with getting the type of sound that I want and/or need. Here are some itneresting manuals.
Having being having some frustrations with sound libraries being built with later versions of Kontakt/Reaktor. Has been frustrating me to the point where I thought is there a way to bypass the checks (easily possible with many simple system checks. I only investigated as I'm on a mobile prepaid connection at the moment which means that I am trying limit my downloads.).
Some interesting tips with regards to 'House Music'.
Setup a new Tumblr account. Basically, a mirror of my Twitter account.
To fix this, WordPress 4.1 now includes a shiny new function that we recommend for all plugins and themes:
Usage for wp_json_encode() is identical to json_encode(). It works by trying a json_encode(), then checking if that encoded properly. If it failed, wp_json_encode() will go through whatever lump of data you passed to it, convert it to UTF-8, then return it as JSON.
Have fun with WordPress 4.1, and see you next year for new and exciting functionality coming to a WordPress install near you!
1:20 pm Friday 16 January 2015
Andrew is a Linux addict who has become obsessed with autopilots. When not coding he is testing (and sometimes crashing!) search and rescue aircraft in an attempt to bring affordable search and rescue UAVs to the world.
For more information on Andrew and his presentation, see here.
Daniel Vetter Botching up IOCTLs
3:40 pm Friday 16 January 2015
Daniel Vetter started to contribute to the linux kernel a few years ago when the graphics stack rewrite broke his old laptop and all the developers were busy fixing newer machines. From then on it went all downhill and since 2011 he's enjoying the fun and frustration of working on the Linux graphics driver stack professionally at Intel's OTC. Since 2012 he is also the kernel maintainer of the Intel graphics driver.
As the i915 maintainter Daniel managed to get the quality issues under control and the driver off the infamous No. 1 spot on the kernel's regression list - where it beat entire subsystems. He established solid testing procedures, created an entire new testsuite for the kernel and enforced strict requirements for merging patches.
Additionally Daniel spent a lot of time improvimg the drm (direct rendering manager) subsystem. Daniel was a major driver behind the effort to write documentation for all driver interfaces. He removed lots of old cruft and separated the new-world modesetting driver from the horror show of the legacy drivers and reducing the rather hapzardous ioctl interface surface for drivers.
For more information on Daniel and his presentation, see here.You can follow him as @danvet and don’t forget to mention #lca2015.
Zane Gilmore FLOSSing in the lab – What Plant and Food Research does with FLOSS
3:40pm Thursday 15th January 2015
Zane is a developer and computer consultant for scientists working for the Plant and Food Research Institute. He writes software (mostly in Python) and advises scientists on how to facilitate their science. He has worked as a developer since 2000 after he got a degree in Computer Science at University of Canterbury.
For more information on Zane and his presentation, see here.
I work with lots of different teams and different developers. I usually know innately, as does the team around me, whether the teams we’re working with are good or not. We rarely disagree on the evaluation.
But what does good mean?
I find that the most valuable web developers interact with each other along a kind of implicit contract, the tenets of which are based upon web standards and proven ways of doing things that we’ve cobbled together collectively over the years. Most of the time, good isn’t generated by an individual in isolation—it’s the plurality of tandem efforts that hum along to a shared, web-driven rhythm.
When things are ticking along smoothly among devs, I find we have a common underlying way of talking and thinking about the web. We fit together in human and technical ways, upholding a shared understanding about how best to make pieces of the web fit together.
In contrast to the tired stereotype of genius coming in the form of a lone, intense hacker, much of the effective work done on the web is done within the bounds of a certain kind of communal conformance. In a good way.Working together
A heap of obvious things goes into making an individual web developer seem good: An innate understanding of time and effort. An indestructible drive to self-educate. A lick-smart, logical mind quick to spot and take advantage of patterns. I think we look for these talents naturally.
And yet when devs work together, those skills fade back just a bit. In a (grossly oversimplified) way, as part of a larger team each developer is a miniature black box. What comes fiercely front-and-center are the interfacing edges of the people and teams. The way they talk to each other and the timbre of what they build, what they disclose and what they don’t think they need to mention.
When something unexpected pops up between healthy teams—which happens, because this is a complicated world—a communication like, “Hey, when I poke this service in this way, it throws a 500 at me” as often as not is enough information for the recipient to go off and fix it, because we have have similar scars to reference and a shared vocabulary built on common ground.
A common vernacular and communication style is an echo of a common thinking style. Underneath the chatter are cognitive technical models of the metaphors at hand, based on each team member’s perception of how the web fits together—REST, modular patterns, progressive enhancement, etc.—and how those components apply to the current project. Happy days when those internal archetypes align.
When you run into misaligned teams it is obvious. There’s a herky-jerky grating to communication. Seemingly dashed-off emails that don’t quite dig into the problem at hand. Teams where you can tell each member’s mental context differs. Code that feels weird and wrong.A common ground engenders brilliant ideas
Unless it is the actual goal of the project, I don’t care too much if you can come up with a Nobel-worthy new implementation of a basic CRUD feature. In most cases, I’ll happily accept something predictable and expected.
This is not an argument for ignorance or apathy. Ideally, everyone should be pretty good at what they do—those individual technical skills do of course matter. I mean, part of the contract here does involve boots-on-ground time—to understand the lay of the land, to break HTTP into bits and pieces, leak some memory, screw up DNS a few times. We break and heal frequently as we gain deeper web mastery.
But having a web set of conceptual building blocks—standards, patterns, conventions—upon which we can frame and build gives us the freedom to focus on where we really need to be creative: the particular task, product, or site at hand. Common components, shared notions.
After all, the best chefs in the world don’t reinvent carrots. Instead, they identify what other remixed food components might plug into a carrot to make it divine.
Likewise, good developers are mixing up agreed-upon technical ingredients into the soup of the day. And just as a talented cook knows how to explain to the waitstaff the nuances that thyme brings to the potato, good devs know how to talk to those around them, team members both in the kitchen and beyond, about why today’s menu includes OAuth or moment.js.It’s not just touchy-feely
It used to be that I would think, “Hey, these people seem like they’re on the same wavelength as my team; that’s cool,” but now I realize it’s likely that what seems merely like good vibrations saves prodigious time and money on projects.
In damaged teams, mental reference dissonance carries through to the outcome, manifesting itself in jarring technical mismatches, poorly-thought-through integration seams and, frankly, bugs. It’s as if people are thinking about the web in different internal language systems.
So? Things take longer, often a lot longer. Teams become frustrated with each other. Meetings and discussions are drawn-out and less fruitful. The results suffer. Things break.
I’m not suggesting we all link arms and plow out code from a single hive mind. In fact, I’d argue that the constraints imposed by a common perspective help to drive a certain kind of unique brilliance.
AUCKLAND, New Zealand – Thursday 18th December 2014 – linux.conf.au 2015 organisers are proud to announce an update to our funding programme!
Python Software Foundation Outreach Programme
LCA 2015 and the Python Software Foundation are proud to support our community. To supplement the existing InternetNZ Diversity fund the PSF have donated additional funds for candidates within the Python community.The Python Software Foundation appreciates LCA 2015's commitment to diversity, and is proud to add its own contribution in the form of the Python Software Foundation Outreach Fund. Much system software for Linux is written in Python (including both distro level tools and open source system management projects like OpenStack, Salt and Ansible), and Linux is often the default choice for deployment of Python web services and other networked applications. This contribution is intended to strengthen ties between the Python and Linux communities by assisting under-represented delegates who participate in the Python community in the region but, without financial assistance, would not be able to attend LCA 2015.
For more information please see our funding registration page.
linux.conf.au is one of the world's best conferences for free and open source software! The coming linux.conf.au; LCA 2015 will be held at the University of Auckland, New Zealand from Monday 12 January to Saturday 16 January 2015. LCA 2015 will be fun, informal and seriously technical, bringing together Free and Open Source developers, users and community champions from around the world. LCA 2015 is the third time linux.conf.au has been held in New Zealand. The first was in Dunedin in 2006 and the second was in Wellington in 2010.
For more information please visit our websiteAbout Linux Australia
Linux Australia is the peak body for Linux User Groups (LUGs) around Australia, and as such represents approximately 5000 Australian Linux users and developers. Linux Australia facilitates the organisation of this international Free Software conference in a different Australasian city each year.
For more information see: http://www.linux.org.au/Emperor Penguin Sponsors
LCA 2015 is proud to acknowledge the support of our Emperor Penguin Sponsors, Catalyst IT, HP and IBM, and our diversity sponsor Internet NZ.
For more information about our sponsors click below -
At bath time last night, Zoe had some spots on her torso. Interestingly, he first reaction upon seeing them in the mirror was "Chicken!". I was more sceptical, because she's been vaccinated for chicken pox, and wasn't showing other symptoms. I thought it may have been from crawling along the tree branch. So I put her to bed and said we would check them in the morning.
After a good night's sleep, but a ridiculously early start at 5am, she still had spots, but was otherwise fine, so I decided to make a doctor's appointment. I managed to get one for 12:15am, so we just hung out at home in the morning, and Zoe watched some TV. It was ridiculously hot, so it was a good day to be indoors with the air conditioning cranked up.
After an early lunch, we went to the doctor. She said that Zoe had a slight fever, but she was also doubtful if it looked like chicken pox. She said to give it 48 hours to see what happened. She said if it was chicken pox, it'd be a mild case, given she's vaccinated.
I guess the school holidays is as good a time as any to be out of commission. Hopefully we both won't go too stir crazy.
She also said that given how Zoe was presenting we didn't need to go too overboard on isolation, so we made a quick trip out to Westfield Carindale to pick up some birthday cards, before heading home again.
Zoe's temperature got a bit higher in the afternoon, and she ended up taking a long, late nap on the couch. I used the time to work on the next unit of my real estate licence course, and made some good progress.
I pretty much had to wake her up when it was time for Sarah to pick her up, and she still had a low grade fever, but was otherwise in good spirits.
1:20pm Wednesday 14th January 2015
Brenda Wallace is an Open Source contibutor from Wellington. She likes all the programming languages, but especially the ones beginning with P. Brenda works with the mighty wonderful people at Rabid Tech. Also, she's not a werewolf.
For more information on Brenda and her presentation, see here.
David Airlie Displayport MST: why do my laptop dockoutputs not work?
2:15pm Wednesday 14th January 2015
David Airlie is the upstream kernel graphics maintainer and work for Red Hat out of their Brisbane office. He is part of the maintainer team for Red Hat Enterprise Linux graphical components. He recently branched into virtualisation for graphics project and is trying to create a fully open source virtualised 3D graphics device capable of supporting modern operating-system requirements. He also gets distracted from this task my many random other graphics projects, of which support for Displayport MST is one.
For more information on David and his presentation, see here.
Dirk Hohndel Sustaining Momentum - or the Gap Between User Request and Developer Capacity
3:40pm Friday 16th January 2015
Dirk is Intel's Chief Linux and Open Source Technologist. He has been an active developer and contributor in the Linux space since its earliest days, among other roles, he worked as Chief Technology Officer of SuSE and as Unix Architect at Deutsche Bank. Dirk joined Intel in 2001 and since then has been working in the Software and Services Group with a focus on the technology direction of Intel's Open Source Technology Center and Intel's engagements in open source. His interests range from kernel to user interaction, from massively scalable cloud services to mobile operating systems. He is an active contributor in many open source projects and organizations, various program committees and advisory boards and currently maintains the Subsurface dive log project. Dirk holds a Diploma in Mathematics and Computer Science from the University of Würzburg, Germany. He lives in Portland, OR, USA.
For more information on Dirk and his presentation, see here.
It has been an extremely long time between beers (10 months!). I’ve gotten out of the habit of blogging and somehow I never blogged about the talk I co-presented at PyCon AU this year on Pallet and Forklift the standard and tool we’ve developed at Infoxchange to help make it easier to develop web-applications on Docker1.
Infoxchange is one of the few places I’m aware of that runs Docker in prod. If you’re looking at using Docker to do web development, it’s worth checking out what we’ve been doing over on the Infoxchange devops blog.
- There’s also Straddle Carrier, a set of Puppet manifests for loading Docker containers on real infrastructure, but they’ve not been released yet as they rely too much on our custom Puppet config.
A couple of years ago, I was asked to help put together a code of conduct for the IA Summit. I laughed.
We need a code of conduct here? The IA Summit is the nicest, most community-friendly conference ever! Those problems happen at other conferences! And they want me to help? There are sailors jealous of my cussing vocabulary—surely I was not PC enough to be part of such an effort. But the chairs insisted. So, being a good user-centered designer, I started asking around about the idea of a code of conduct.
I found out design conferences are not the safe meetings of minds I thought they were.
One woman told me that she had been molested by another attendee at a favorite conference, and was too scared to report it. “No one will ever see me as anything but a victim,” she said. “I’ve worked too hard for that.”
At another conference, a woman was woken up in the middle of the night by a speaker demanding that she come over. When she told the organizer in the morning, he said, “We were all pretty drunk last night. He’s a good guy. He just gets a bit feisty when he’s drinking.”
Then there was my own little story. Years ago at the IA Summit, I went to talk to a speaker about something he’d said. I’m a tall, tough lady. But he managed to pin me against a balcony railing and try to kiss me. I started wondering, what if there had been a code of conduct then? What if I had had someone to talk to about it? What if I hadn’t said, “Oh, he’s just drunk”?
Maybe I wouldn’t have spent the past seven years ducking him at every event I go to. And maybe he wouldn’t have spent those same years harassing other women—women who now were missing out on amazing learning and networking opportunities because they thought they’d be harassed.
The idea of a code of conduct didn’t seem so silly anymore.A wicked problem
Unfortunately, it still seems silly to others. Recently I was talking to another conference organizer about setting up codes of conduct, and he said, “That doesn’t happen at our conferences. People know me, and they know they can talk to me. A code of conduct will make people nervous that we have a problem. And we don’t.”
I wonder how he knew that, since most victims don’t come forward. They don’t want to be seen as a “buzzkill,” or be told that what they wore or what they drank meant that they asked for it. This is not unusual; every day we see examples of women whose reputations are trashed for reporting rape and harassment. On Twitter, women who talk about sexism in games or even think a woman should go on a stamp are given death threats. Reporting carries consequences. Reporting is scary.
In order to feel safe enough to come forward, attendees and speakers need to know that the conference organizers are paying attention. We need a guarantee that they’ll listen, be discreet, and do something about it.
In her recent piece, “Why You Want a Code of Conduct & How We Made One,” Erin Kissane frames precisely why codes of conduct are absolutely necessary:To define a code of conduct is to formally state that your community—your event or organization or project—does not permit intimidation or harassment or any of the other terrible things that we can’t seem to prevent in the rest of the world. It’s to express and nurture healthy community norms. In a small, limited way, it’s to offer sanctuary to the vulnerable: to stake out a space you can touch, put it under your protection, and make it a welcoming home for all who act with respect.
A code of conduct is a message—not a message that there is a problem, but a message that there is a solution. As much as a label on a button or a triangle with an exclamation point in it, a code of conduct tells you how a conference works.Tweaking the UI
We are designers.
That means we make choices about the interface that sits between the people and the thing they want. We mock interfaces that aren’t clear. We write books with titles like Don’t Make Me Think. Yet when we hold conferences, we seem to assume that everyone has the same idea of how they work.
Why do we expect that people will “just know” how to use this complex build of architecture and wetware? There is a lecture; that means professional behavior! There is a bar; that means drinking and flirting! There is a reception; that means…alcohol plus speakers…network-flirting? A conference can be a complex space to understand because it mixes two things that usually have clear boundaries: social and work. If one person is working and another is looking to get social, conflict will happen.
These fluid boundaries can be particularly hard on speakers. Attendees often approach speakers with questions inspired by their talk, which could start a conversation that leads to work…or a date. It’s hard to tell; cautious flirting and cautious networking often look the same. People can feel uncomfortable saying no to someone who might hire them—or keep them from being hired.
Sometimes after giving a talk, I’ve mistaken admiration for flirtation, and the other way around. A wise speaker stays neutral, but it can be hard to be wise after a few glasses of wine. A code of conduct is useful because it spells out parameters for interaction. Some codes have even gone so far as to say if you are a speaker, you cannot engage in romantic activities like flirting. Clarity around what is expected of you leads to fewer accidental missteps.Set expectations
A good code, like a good interface, sets clear expectations and has a swift feedback loop. It must:
- Define clearly what is and isn’t acceptable behavior at your con. “Don’t be a dick” or “Be excellent to each other” is too open to interpretation. The Railsconf policy offers clear definitions: “Harassment includes, but is not limited to: offensive verbal comments related to gender, sexual orientation, disability, physical appearance, body size, race, or religion; sexual images in public spaces; deliberate intimidation; stalking; following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact; and any unwelcome sexual attention.”
- Set expectations for what will happen if the code is violated, as the O’Reilly code of conduct does: “Conference participants violating this Code of Conduct may be expelled from the conference without a refund, and/or banned from future O’Reilly events, at the discretion of O’Reilly Media.”
- Tell people how and to whom to report the incident. The Lean Startup Conference’s code includes: “Please contact a staff member, volunteer, or our executive producer [name], [email] or [phone number].” Providing a phone number is a massive signal that you are willing to listen.
- Set expectations about how it will be handled. The World IA Day code is very clear:
First we will listen.
Then, we will help you to determine the options that we have based on the situation. We will also document the details to assure trends of behavior are uncovered across locations.
Lastly, we will follow the situation to a resolution where you feel safe and you can remain anonymous if you wish to be.
A code of conduct is a little like a FAQ or a TOS. It’s clunky, and I hope someone comes up with something better. But it’s instructions on what to expect and how to behave and, most importantly, what to do when something breaks. Because, as we keep seeing, something will eventually break. It’s better if it’s not people.
A lot of conferences are adopting codes of conduct now. The Lean Startup Conference one mentioned above is heartfelt and crafted based on their values. The art and technology festival XOXO has an excellent one, based on the template from Geek Feminism. Yes, there’s a template. It’s not even hard to write one anymore. It doesn’t even take a long time.Meet (or exceed) expectations
Any good experience designer knows that setting expectations is worthless if they aren’t immediately met. Beyond writing a code of conduct, conference organizers must also train their team to handle this emotionally charged situation, including making sure the person reporting feels safe. And there needs to be a clear, established process that enables you to act swiftly and decisively to remove violators.
So how should a conference handle it when the code is violated? There are a couple of telling case studies online: one from Elise Matthesen at the feminist science fiction conference WisCon, and another from Kelly Kend at XOXO.
In both cases, these women were immediately supported by the people they spoke with—a critical first step. In Kelly’s case, she brought her situation directly to the organizers, who listened to her and made it clear they weren’t going to blame her for the incident. Once the organizers had made her feel safe, they removed the harasser. It was improvised action, but effective.
In Elise’s case, it’s clear that WisCon was well-prepared to handle the incident. The first part of the story is exemplary:
- The conference staff member (called a “safety staffer”) asked if Elise wanted someone there while she reported.
- The safety staffer asked if she wanted to report it formally, or just talk it through first.
- The safety staffer asked if she wanted to use her name, or remain anonymous.
- And the safety staffer and the conference organizers kept checking in with her to make sure she was doing okay.
Unfortunately, WisCon fell down when it came to acting on the report. Eventually the harasser was banned, but only after a slow and onerous process. And the ban isn’t permanent, which has infuriated the community.
It is hard work to get the poison out of the apple. Elise writes, “Serial harassers can get any number of little talking-to’s and still have a clear record,” which has been my experience as well. Since I started writing about conference harassment, a number of women have spoken to me about incidents at various design conferences. Two names keep coming up as the abusers, yet they continue to get invitations to speak. Until more people step forward to share their stories, this won’t change. And people cannot step forward until they are sure they won’t be victimized by the reporting process.
If you are a conference organizer, it is your job to make sure your attendees know you will listen to them, take them seriously, and act decisively to keep them safe.
If you are an attendee who sees harassment, stand up for those who may be afraid to step forward, and act as a witness to bad behavior.
And if you are harassed, please consider coming forward. But I can’t blame you if you choose not to. Keep yourself safe first.A promise
John Scalzi, author of several best selling sci-fi novels, made a pledge to his community that he would neither speak at nor attend any conference without an enforced code of conduct.
I will make the same pledge now. I will honor any commitments I’ve made previously; all new ones are subject to the pledge.
I will neither speak at nor attend conferences that do not have and enforce a code of conduct. This may prove hard, as many conferences I’d love to speak at do not have a code yet. But change takes sacrifice. Integrity takes sacrifice.
If you believe, as I do, that it is critical to make a safe place where everyone can learn and grow and network, then leave a comment with just one word: “cosigned.”