Host ID: 315
Clinton Roy is an Open Source engineer.
Clinton interviews Nicolas Steenhout about his accessibility workshop, covering the different areas that automated and manual testing can cover. We also talk about the conference in general, and on the different ways that conference get feedback about their speakers.
Clinton interviews Katie McLaughlin at linux.conf.au 2018 on her role with the conference as community liaison and as the lead organiser of PyCon Australia.
Editor's Note: Corrected audio now available
Clinton speaks to three linux.conf.au first timers for their take on the conference: York, Cat and Neeraj.
- The Internet of Houses: Whare Hauora
- Reusable R for automation, small area estimation and legacy systems
Clinton chats with Richard Jones, head of PyCon Australia 2016/17
We talk about PyCon Australia, and microPython.
Clinton speaks with Hugh Blemmings, immediate past President of Linux Australia
- Non-native English speakers in Open Source communities: A True Story
- Rage Against the Ghost in the Machine
- Scientific Hooliganism
- Lightning talks (five minute long talks)
- Community Leadership Summit X at LCA https://lca2017.linux.org.au/presentation/10/
- Handle Conflict, Like a Boss! https://lca2017.linux.org.au/schedule/presentation/37/
- Kathy Sierra: Badass: Making Users Awesome
I am your user. Why do you hate me? https://lca2017.linux.org.au/schedule/presentation/74/
- Material Design https://material.io/
- Moodle learning platform http://moodle.org
- Yahoo UI http://yuilibrary.com/
- Drupal Content Management System https://www.drupal.org/
- Bootstrap HTML/CSS/JS framework http://getbootstrap.com/
Clinton interviews Kathy Reid, the new president of Linux Australia.
I interview Russell Keith-Magee at linux.conf.au 2017 in Hobart, Tasmania, Australia.
- BeeWare http://pybee.org/
- Stranger in a strange land: Breaking language monocultures with open source https://linux.conf.au/schedule/presentation/32/
- Open Hardware miniconf http://www.openhardwareconf.org/wiki/Main_Page
- Wootconf https://linux.conf.au/schedule/presentation/7/
- Knit One, Compute One https://linux.conf.au/schedule/presentation/120/
- Condensed History of Lock Picking https://linux.conf.au/schedule/presentation/122/
- Keynote: Consider the Maintainer https://linux.conf.au/schedule/presentation/106/
- Roads and Bridges report http://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure
I have recently been fortunate enough to give a presentation to two conferences, PyCon Australia and Kiwi Pycon, the Australian and New Zealand Python conferences, respectively. I'm not going to give a talk based around the presentation, as it's rather code heavy, and we know that doesn't translate well to an audio medium.
Instead, what I wanted to do, was to talk a little bit about the presentation pipeline that I used to prepare this talk. The input is a plain text file, edited in Emacs, using a mode called Org mode. The intermediate form is a LaTeX file, using the document class Beamer which is designed for presentations that are going to be projected. Beamer is apparently the German word for digital projector. The final output form is a plain PDF.
HPR isn't known for having many Emacs talks, so I should probably explain the idea of modes. Emacs has major modes and minor modes. For every document that you're editing there's one major mode, and any number of minor modes. So if I was editing a Python file for example, I would have the Python major mode which understands Python and can thus do Python specific things like Python code completion, and I would have a spell checker minor mode to check the spelling of comments, and another minor mode to automatically line wrap comment lines that are very long, and another minor mode to show what line number I'm currently editing, and another minor mode to blink the cursor and so on.
The other topic that I haven't heard too much on is LaTeX. LaTex is the venerable typesetting solution for Unix based systems. LaTeX documents have a single document class, and then any number of packages. In the case of my presentation, the document class is Beamer, which sets up all the margins and fonts to be good for presentations. Some of the packages I'm using are the symbols package, for arrows and maths symbols, and several graphics packages so I can draw trees in my slides.
I'm fairly comfortable with LaTeX, I could certainly write this presentation directly in LaTeX, but I think there are some advantages in using Org mode to generate my LaTeX instead.
As the name suggests, Org mode is designed to be an organisational mode, helping you write TODO lists and organise documents. While the document is just a plain text document that you can read and write with any text editor, the Emacs Org mode understands its own mark up and provides an outlining mode, where you can hide and expand trees of bullet points. The basic layout of a set of slides for a presentation is a tree of bullet points, where the top level bullet points are slides, and the second level of bullet points are lists of information put into each slide.
Another mark up that Org mode understands is that of code blocks, so that we can easily say ``this chunk of code is a Python block''. Org mode understands how to export this Python code block as a separate file, run it under Python, and can even insert the output of the program, or the result of a function, back into the original document as a code output block.
The advantage of having just one file for my presentation, versus one file for my presentation and a separate file for each code block, is that the code examples in my presentation never get out of sync with the code that I'm actually running. This style of programming where the documentation is the primary document, and the code files are generated, secondary documents, is the inverse of the typical way of programming where the code documents are the primary documents, and documentation, the secondary documents, are automatically generated.
This style of programming, where the primary document is documentation is called literate programming. The process of creating the documentation (the PDF in my case) is called weaving. The process of creating the code files is called tangling.
I really like having just one file to generate one PDF presentation file, so I'm going to keep using this technique in the future.
Now, I have to admit that my presentation is not completely literate, there are some bits of output in my presentation that are copied and pasted, rather than automatically gathered, so I've still got some work to do.
Down to brass tacks. The conventional file name extension for Org mode files is dot org. The typical metadata you put in presentations are Author, Email, and Title. In mine I've also added Subtitle and Institute. Now, the interesting one here is Institute, for whatever reason, it's not a piece of metadata that Org mode knows about, but it's really easy to drop down into LaTeX and just use the LaTeX institute command directly.
There's a metadata line that Org understands called Options, I request that my presentation has a table of contents, and that all the bullet points of level two become line items in that table of contents. Then I'm straight into the slides. Bullet points at the first level are converted to sections, bullet points at the second level are turned into slides, and anything deeper than that are turned into contents of that slide. I have many code blocks, and I use options that specify what file this code block is tangled to, and to leave the white space alone when the code block is exported, as white space is critical to Python. I also turn on an option that gets line numbers printed for the code blocks. In a couple of places where I want to highlight certain areas of the code, I add labels to the code, then outside the code block I can refer to the label, and LaTeX will replace this with the line number. I think I'd prefer to do this referencing with highlighting, or an arrow or something, but I'm not sure I can do that.
Engineering is the process of dealing with tradeoffs to get something done, there are many trade offs when writing code to solve a problem, writing code for slides has quite a different set of tradeoffs, you want code to be easy to read, in terms of using long variable names, but you also need code blocks to contain as few lines as possible, so that you can use a large font size on the projector, and you also don't want to have to split an example across multiple slides if you can help it. I'm also of the view that syntax highlighting is a waste of time, it's just a pretty layer of obfuscation that the mind has to understand, then drop in order to actually see the code. This stance of mine was vindicated when several presenters with syntax highlighted code realised on the day that the projected code was impossible to read due to the low contrast projectors used in a reasonably well lit room.
One feature that I would like to add is the ability to reveal new code. It's quite common to have a code block, reveal a problem with it, and display the same code block again, but with a minor change that fixes the previously explained problem. Ideally the old code and new code would be rendered differently, but I don't think that's an option right now. The other thing that I couldn't work out was how to run custom programs on my code blocks, I was wanting to run the Python unit test program, not the Python interpreter, and could not find a way to do that.
There's a single command to run inside Emacs to create the output PDF,
So, overall, I'm very happy with this pipeline. It lets me have a primary document with code snippets, and it lets me have LaTeX snippets wherever I like. It's not perfect, but I'm hoping to find ways to improve it.
This is a very personal podcast, discussing minor surgery. If that sort of stuff makes you cringe at all, this may not be the recording for you. I should also point out that I am not a medical professional, you should not take this recording as medical advice, if you have any concerns about your skin, seek professional medical advice.
I am a very white person living in Queensland, Australia. Our state has amongst the highest rate of skin cancers in the world, I believe we're in a tussle with New Zealand for first place at the moment.
There are two main types of skin cancer, melanoma and non-melanoma. The non-melanoma type is slow growing, and rarely spreads to other parts of the body, while melanoma is fast growing and spreads to the rest of the body.
Both my parents have had multiple lesions excised, so something like this was always on my mind. We live in a sunny, sub-tropical environment, the sort of clothing you'd want to wear for comfort is light, breezy, and not covering much skin, exactly the wrong sort of clothes you'd need to wear to protect yourself from ultraviolet (UV) rays that help cause skin cancer.
According to the Australian BoM FAQ http://www.bom.gov.au/uv/faq.shtml the per capita risk of skin cancer in Australia is ten times higher than America and sixty times higher than the UK.
The UV scale rarely gets above eight in the UK, in Brisbane the UV scale is above eight for roughly eight months of the year.
There are a lot of variables when it comes to UV. Cloud cover is probably the most important. Something that I can't stress enough is that heat and UV are not correlated, you can definitely be exposed to lots of UV when it's cold (see New Zealand, they're much more south, much more cold, and have more exposure due to the ozone hole). Another example is snow, UV will bounce off the snow and back at you.
The link between skin cancer and UV is quite strong, 95-99% of skin cancers are caused by excess sun exposure. (http://www.cancer.org.au)
So, with all that history, I started getting yearly skin checks a couple of years ago. I'd had a couple of skin checks when I was very young, and now that I'm more advanced in years I wanted something less ad-hoc. Someone working for one such organisation gave a talk at one of the user groups I attended, and i made an appointment with Molemap. It's a full on procedure where your entire body is photographed, and each mole, freckle, bump and lump that is of possible concern is photographed from a few centimetres off the skin, and with the magnification lens sitting right on top of the mole.
I have some near 200 spots on myself that are of interest, so my follow up appointments take about two and half hours to go over all these spots, plus looking for new ones. The hope is that, by doing this close to yearly, small changes in all these spots won't go unnoticed, and we can get on top of any cancers early.
Interestingly, the spot that was actually a problem was a new one, so under a year old, and was hiding underneath my beard, so in future I'm definitely going to have my skin checked clean shaven.
The other thing I want to communicate is that early detection is key, all the skin cancers have a 90% plus survival rate (at five years) if caught early enough. This does potentially mean that a yearly check is not enough, but it's already proven it's worth to me.
Molemap only does photography of spots, and visual diagnosis. It does not do any treatment or biopsies or excisions, therefore there it has no self interest in recommending treatment on borderline cases. Molemap sprang out of a University of Queensland project, which is my alma mater. After receiving the diagnosis (via an online form, secured with a second factor sent to my phone) and panicking a fair bit, I contacted my regular doctors practice (we call them general practitioners in Australia, I'm sure they're called different things elsewhere) for an appointment with a GP who had experience with skin cancers. In QLD, most medical centres will have at least one doctor with experience in this area. As it turns out, my regular GP has such experience and I got an appointment for the following week.
I wasn't really sure what to expect from my GP appointment, but I was mostly expecting to get the diagnosis confirmed, and either get sent to a specialist to deal with it, or organise another appointment at the GP.
What actually happened was it took all of five minutes for my doctor to confirm the diagnosis, then work how he had time in his schedule, and there was a nurse free, to excise the lesion straight away. I was given a local anaesthetic, so I felt no pain whatsoever, but you still feel the doctor pulling on your skin up, down left and right, so that the complete lesion can be removed, as well as a small amount of surrounding skin in case the cancer has spread.
Here I should mention that melanomas spread very fast, and when they're excised up to a centimetre of skin may need to be removed, where as for a non-melanomic, a millimetre or so is good enough.
I got four sutures put in, they stayed for a week (we have a long easter break in Australia) so it ended up being closer to a week and a half. I had no problems, my scar healed up quickly and nicely. Now, a couple of months later, there's a little redness along the scar line, but that's about it.
So. The take aways. UV is not correlated to heat, you can get a lot of UV exposure in cold environments. If you're travelling through a high UV area, take precautions (clothes that cover a lot of your skin, hat, sunglasses, sunscreen). If you live in a high UV area, get your skin checked regularly. Also, keep an eye on your own skin. Use a diary to record any new bumps, lumps, spots etc.
Linux.conf.au, is the name and website of my favourite conference. Known by insiders as simply lca, it is an annual technical conference, focusing on Linux and Open Source technologies. LCA is a roaming conference, going to a different city of Australia and New Zealand every year. I've helped organise the two lca's in my home town of Brisbane, Queensland, and it was in fact the first of these that introduced me to lca. This year lca was held in Geelong, down in the state of Victoria and it counts as my fifteenth linux.conf.au. Clearly this conference has become quite a big part of my life and it's probably a mature thing to stand back and have a look at why.
lca is a technical conference, it's not a sales oriented conference, as an engineer having non-salesy, technical content makes me feel at home. For the most part, the paper committee only accept talks from people directly working on a project, so the speakers we select know their topic. lca is explicitly an open source conference, and mostly a low level conference.
lca is a week long conference, so I often add some extra time on the end to make a holiday out of it. A fair percentage of our attendees are from overseas, and it makes sense for them to do the same. I have taken the train to a Perth (Western Australia) lca, that's the Indian Pacific train, a three day trip from one side of the country to the other. I've done a day trip on a train in New Zealand, from Auckland to Wellington. I've done a couple of motorcycle trips, down to Ballarat and Geelong (both cities in the state of Victoria). Those two tours are roughly a 3600km (or 2200 mile) round trips taking three to four days each way.
I've done a motorcycle tour of Tasmania (an island state of Australia) after a Tasmanian lca. Next year, the conference is back in Tasmania for the Hobart lca, I'm planning on doing a week long hike of about 85kms (50 odd miles) before the conference along the South Coast Track.
There are a bunch of people that I only get to see at lca, from year to year, sadly some of these come from my own home town. Keeping these connections strong is an important part of lca for me.
Every year, the parent organisation of lca, Linux Australia holds their Annual General Meeting during lca. I've been an Ordinary committee member on the Linux Australia council a couple of times now. This year I didn't get enough votes, which means I have more time to devote to other things, like HPR recordings :)
Registration for lca normally starts Sunday afternoon, there's often a beginners guide to the conference. After fifteen years, I don't think I've ever attended one, but I should probably help lead it next year..
It's very common for lca to choose a charity to raise money for. For many years this meant a loud, long, often raucous auction. In recent years we've had a raffle over the full length of the conference. We've helped many worthy charities over the years, the one that comes to mind was the 'Save the Tasmanian Devils' fund, for which we raised a substantial amount of money, something around forty thousand dollars, partly based on the auction prize of changing the linux's kernel logo from Tux to Tuz, the lca mascot for that year. Tuz is a Tasmanian devil wearing a costume Penguin beak to cover over his case of the Devil Facial Tumour Disease, a communicable cancer, that is threatening their existence. This was also the conference where Linus shaved bDale's beard off to raise money for the charity.
We often hold lca at a university, and we often use student dormitories as accommodation. If we're lucky, this means that a large percentage of attendees can meet up in common areas of the accommodation at the end of the day and continue the conference long into the night. A particularly memorable lca on this front, somewhere in New Zealand, I forget which city, had a whole level of a student accommodation centre set aside as a common area, so a large percentage of the conference were able to fit and continue the conference late into the evening.
The first two days of the conference are generally reserved for miniconferences, or miniconfs as we refer to them. These miniconfs go for one or two days and are organised around a particular topic, and separately to the main conference. The miniconfs change every year, but commonly include miniconfs focused on the kernel (this is primarily attended by kernel coders), hardware (based around ardunio, raspi, and this year espy), multimedia and music, sysadmin, OpenRadio, Open Source in Government. A highlight from the second Brisbane lca was the rocketry miniconf, where 25 odd rockets were put together and later launched. We've been blessed over the years to have miniconfs working to improve and enlarge our community, including LinuxChix, Haecksen and the Community Leadership Summits.
After the miniconf days are done, the conference proper begins. These days start off with a keynote, have four or more streams of talks during the day, with longer tutorials running for half the day.
My favourite keynote from this year was Genevieve Bell, from Intel. From previous years, Tim Berners Lee, Eben Moglen and Kathy Sierra have left long term marks. These are people who have fundamentally created the world I live and work in now, their contributions cannot be understated.
There are a bunch of talks from every year that change the way I think about something, or the way I work. This year, I reckon the Record/Replay talk will probably change the way I debug programs. RR is a Mozilla tool, you run the buggy program under rr, which records exactly what the system calls the program runs, what state effects the program has, then you run that recording under the standard debugger, gdb. Typically with gdb you can only step forwards into the program, but with rr you can actually step back in time as well!
A hardware talk that really caught my attention this year was the Linux Microwave, a regular microwave with a set of scales and a thermal imaging camera added, so that whenever you heat/warm/defrost something, the microwave will never ever burn/under/over cook the food!
The other bit of hardware that I feel warrants a mention was the large loom that one of our venues, the National Wool Museum was built around. It is programmed by a large bunch of punch cards! There's always local attractions that add something to the conference.
During the week, ad-hoc groups form around common interests, we call these Birds-of-feather sessions. I usually end up attending the Emacs BoF. A recurring BoF is the jobs BoF, where employers and hopeful employees come together.
I don't tend to attend too many tutorials myself. A number of years back I ran a tutorial on Antlr, a recursive descent parser toolkit.
There are a number of social events that happen most years, the conference dinner, the speakers dinner, and the professionals session. These events target the different audiences at the conference. A favourite spin on this was during a Melbourne lca where diners were given food and drink tokens to use around a market, rather than a traditional sit down dinner. The speakers dinner is a smaller, more private thank you to the speakers, many of whom have flown in from overseas. The professionals session tends to be the most varied, as it tends not be a full meal, but just a place where folks can meet, greet and swap business cards.
I can't say it's always been a bed of roses, I've had a couple of hospital trips over the years, one for myself where, along with almost half of the conference, I came down with the dreaded noro-virus, a gastro bug that is prevalent on cruise ships. During another lca when I was chaperoning another attendee to hospital I figured my lca was over, but then I struck up a conversation with our ambulance driver, and it turned out he'd been working on pdp-11s during his uni days!
The other awful lca experience I have to mention was the flooding that occurred just one week prior to our second Brisbane lca. All of our venues were affected, some were destroyed completely. We had to shift our main venue about 5kms up the road, hire buses, find new caterers at the last minute, a whole world of pain.
For many years now, most of our talks have been recorded, using our own recording system. All of these videos are up on the Linux Australia server and youtube. This means that weeks, months after the conference is finished, I find myself watching a recording that someone has recommended, and it takes me back to that one week in every year where the world makes sense to me.
As I mentioned previously, the next linux.conf.au is in Hobart, January 2017, I hope to see some hpr listeners there.
1 What is systemd?
A dependency system for unix services.
And, a set of basic unix services to make a unix system usable.
And, a growing list of not quite so basic services
- NTP, networkd, timers (crond/atd)
From a programmers perspective, it's the mainloop phenomenon.
Solaris: Service Management Facility
Mac OSX: launchd
Ubuntu: upstart (until recently)
LSB (actually implements LSB deps)
- path (inotify triggers)
- timer (crond/atd)
- slice (cgroup)
- replace run levels
- default target at boot
- can isolate to just one target
5 Advantages - Design
Proper, explicit dependencies between system compontents
Starts components in parallel
A proper separation of concerns, lots of situations covered.
- configuration files are regular, simple to understand generally small
- OTOH, there are LOTS of options
Configuration is not runnable shell.
[Unit] Description=CUPS Scheduler Documentation=man:cupsd(8) [Service] ExecStart=/usr/sbin/cupsd -l Type=simple [Install] Also=cups.socket cups.path WantedBy=printer.target
Separate system and user daemons.
6 Advantages - Sysadmins
Modify configuration without modifying upstream configuration
Service watching (startup, watchdog, failure modes)
[EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [EQUIVALENT] /etc/systemd/system/default.target → /lib/systemd/system/default.target 3 overridden configuration files found.
7 Advantages - Programming
Removal of some error and security prone code
- socket activation (e.g. privileged ports)
- user/group changing
8 Advantages - Provisioning
standardized cgroup controls
debootstrap ; systemd-spawn-boot * systemd takes care of all pseudo file systems for you
9 Advantages - Users
quick to boot
can reduce load later on (services start & stop as required)
- black = Requires
- dark blue = Requisite
- dark grey = Wants
- red = Conflicts
- green = After
- It’s really nice in theory, but in practice I’ve found it to be slow and buggy
It’s a little new, so LTS distros necessarily have older versions
- el7 has something like 200 patches
network-online.target is a bit flakey
- Unix is a graveyard of IPC, I don't feel DBUS is much better
- KDBUS means it will probably be around for ever.
Deeply hooked into linux specific details, not portable
- kernel api, cgroups, udev etc.
Some cool features relient on file system e.g. btrfs for snapshot
I haven’t had a chance to play with networkd yet, but it sounds like it’s going to be very good.
- It depends…
- systemd only supports start/stop/reload
- work with the daemon: oneshot/simple/forking/inetd
- integrate with systemd: notify, watchdog
- Every login, a separate systemd -> user is spawned
- Can override with .config/systemd files
The slides that this podcast are based upon can be found here: