linux.conf.au Hobart January 2017

Monday Jan 16

Human-Driven Development

Aurynn Shaw

  • split between dev and ops causes sadness and tears

  • this is caused by split priorities

    • ops doesn't want to break anything, so they say no to new things

    • thus dev isn't allowed to use new things, so they are sad

  • devops solves this problem by aligning development with operations through work flow and tools

  • devops is a culture of collaboration

  • but development culture can get in the way of collaboration due to a culture of dominion

    • many developers gain a sense of control and power through the development domain

    • this leads to a desire to keep the culture exclusive

    • this elitism leads some developers to look down on ops

    • even between developers this elitism exists (contempt culture)

    • asking questions admits to lack of knowledge = loss of status

    • forms the basis of imposter syndrome

  • these attitudes make people unwilling to ask for help and destroy team cohesion

  • in open source communities, this also leads to loss of community members

  • dominion-centric thinking gets in the way of building better communities and better technology

  • How do we fix this?

    • ask questions

    • listen

    • inclusive hiring

  • human-driven development

    • focus on humans

    • admit we don't know everything; ignorance is not status

    • speak up

    • codes of conduct

    • training

    • don't let bad apples ruin the barrel

    • this is critical, because we are building the future of our community

Almost Open - Just close the door behind you

Steven Ellis

  • What does open mean to you?

  • open vs free: just because something is libre doesn't mean it is gratis

    • note that in many cases gratis actually means you are the product

    • e.g. Google, Facebook, etc.

  • the shift from traditional apps to SaaS actually makes it harder to get access to the source and the data

  • if we don't feed the ecosystem that creates libre technology, it will die

  • some high-level security problems (e.g. heartbleed) are results of libre software that isn't being maintained adequately

  • how do we encourage organizations to give back?

    • acknowledge that we use open libraries

    • engage and educate

    • encourage contribution

  • there are many ways to contribute back upstream

    • bugs

    • testers

    • documentation

    • designers

    • marketing

    • project management

    • code

    • open data

    • open APIs

  • change our own practices

  • help change the practices of others

Knit one compute one

Kris Howard

  • knitting is binary: knit and purl

  • cast on x stitches = for loop

  • repeat to end of row = while loop

  • size adjustment by stitch number = switch statement

  • stitch patterns = subroutines

  • more than one pattern at the same time = coroutines/yield

  • there are many different ways of conveying stitch patterns

  • KnitML

Mice and Maps

Rhiana Heath

  • Mouse Guard role playing game, kind of like Lord of the Rings with mice

  • Leaflet: an open-source JavaScript library for mobile-friendly apps

  • Ruby on Rails as the backend

  • maps need to be cut into tiles to enable zoom

The Openness of Closed Systems

Richard Jones

  • aka Minecraft and Open Source

  • Minecraft is closed source, but that hasn't stopped the modders

  • pi.minecraft.net runs on the Raspberry Pi

    • free, but very limited subset of the game

    • not a great programming experience, but low barrier to entry

  • Minecraft is a Java program first released in April 2009

  • Four main developments in Minecraft modding:

    • modified Minecraft: edit the binary; owner reacted by obfuscating the code

    • custom servers: allow mods server side so the client code doesn't need to be changed

    • golden age begins: community removes obfuscation from the source code

    • forge: unified mod loader and mod developer pack

  • bit.do/pycode-minecraft

Hannah gets Going

Hannah Thompson

  • new to Go, new to programming, new to Arduino

  • Gobot is a Go framework for the internet of things

  • Arduino is fun, but probably not the best way to learn a new programming language

  • books are ok but become out of date quickly with a fast moving language like Go

  • online tutorials can be more current, but may not be at the correct level

  • specific goals with an ending are useful

  • changing your learning method is ok

  • don't let tutorials make you feel stupid

  • don't copy and paste: write it again

  • use all the resources available to you

Why Twisted is the best and will make your application awesome

Amber Brown

  • an open source, event-driven networking engine written in Python

  • your application is implemented as protocols connected by transports

  • reactor = event loop

Condensed history of lock picking

Grace Nolan

  • historically locks were a symbol of wealth and power

  • The era of Perfect Security: 1777-1851

  • nothing is truly secure

Mamas don't let your babies grow up to be rock star developers

Rikki Endsley

  • people are still recruiting for rock stars

  • but rock star programmers are an unfortunate myth

  • the rest of the team loses motivation if one person gets all the attention

  • we need Willie Nelson developers:

    • help others succeed

    • learn new skills

    • accessible

    • use the best tool for the job

    • lead

    • collaborate with a diverse mix of people and groups

Tuesday Jan 17

Choose your own adventure, please!

Pia Waugh

  • we need to make active choices about our future

  • with great power comes great inequality, and we periodically break down the system to redistribute power

  • individuals have more power now than at any point in history

  • technology, especially the internet, has enhanced individual power

  • all our human systems are self-created; we can recreate them as we wish

    1. we should embrace a technological existentialism

  • We are only as free as what we do

    1. technological existentialism is a humanism

Docs Down Under Miniconf

Brian Moss and Lana Brindley

Stephen King's Practical Advice for Tech Writers

Rikki Endsley

  • opensource.com

  • opensource.com/stephen-king

  • before you start writing you need to ask the what, why, who, and how

  • research

  • create an outline

  • write

  • revise

  • 3 main categories of reader:

    • lay audience

    • managerial

    • experts

  • http://netpress.org/care-feeding-press/

  • opensource.com/write-better-docs

  • On Writing: A Memoir of the Craft by Stephen King

  • "If you want to be a writer, you must do two things above all others: read a lot and write a lot. There's no way around these two things that I'm aware of, no shortcut." Stephen King

  • be clear on expectations and read examples

  • opensource.com/write-event-recap

  • consider how your content might be reused

  • write the longest, hardest version of a piece first

  • "An opening line should invite the reader to begin the story. It should say: Listen. Come in here. You want to know about this." Stephen King

  • useful to define the audience at the start of an article so the reader knows if it applies to them

  • "When you write a story, you're telling yourself the story. When you rewrite, your main job is taking out all the things that are not the story." Stephen King

  • "This suggests cutting to speed the pace, and that's what most of us end up having to do (kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart, kill your darlings.)" Stephen King

  • given less experienced writers an outline to work with can save time and heartache

  • use signposts and subheadings to give people guidance as they work through an article

  • "To write is human, to edit is divine." Stephen King

  • "The scariest moment is always just before you start. After that, things can only get better." Stephen King

Sorting out the mess: How information architecture can help

Darren Chan

  • information architect can be a good career path for writers who want to progress in a technical direction rather than a management direction

  • IA is the structural design of information or objects

  • IA can be applied anywhere that information is being conveyed

  • IA is critical for making information findable and understandable

  • information is subjective, not objective

    • e.g. is tomato a vegetable or a fruit?

  • Factors that impact IA design:

    • context

    • content

    • users

  • IA design process:

    • user research

    • content analysis

    • designing

    • testing

Kernel documentation: what we have and where it's going

Jonathan Corbet

  • the kernel is a huge project that requires a lot of documentation

  • 90% or more of kernel code is written by paid developers

  • but nobody is paid to write kernel documentation

  • the kernel has a well-defined maintainer model that is very hierarchical

  • the maintainer model closely matches the kernel file hierarchy

  • but documentation does not fit this model because it crosses various trees and often deals with multiple parts of the kernel

  • everybody touches documentation in some way or another

  • although Linux is at the forefront of OSS in some ways, kernel developers tend to be very conservative

  • so moving to a new documentation model takes some convincing

  • Docs are made up of 2000+ .txt files, some more useful than others

  • docs are formatted using Docbook, which uses 34 template files to build the docs into various outputs

  • Docbook also pulls from kerneldoc comments, of which there are about 55,000

  • so the kernel has lots of documentation but it is difficult to work with, as it has no IA design. Things have just been thrown in as they happened.

  • there is also no cross-document linkage. They are truly 2000+ individual docs.

  • basically, this is a documentation system written by kernel developers

    • there is specialized code in the XML, so the source cannot use standard Docbook tools

    • no formatting in kerneldoc comments

    • ugly output

    • hard to set up and make work

    • slow

    • brittle

    • no integration with rest of Documentation directory

  • toward better kernel docs

    • clean up the mess

    • better formatted output with a logical tool chain

    • must retain a plain text format

  • Recent work

    • added Markdown (later AsciiDoc) to processing kerneldoc comments

    • but this added more tools and dependencies to the docs build, still slow, still no linkage between documents, conflicts between tools

  • Ideal

    • dispense with Docbook entirely

    • but using what?

  • Sphinx and ReStructured text

    • designed for documenting code

    • designed for large documents in multiple files

    • widely used, well supported

    • output to HTML, ePub, PDF

  • Jon put together a POC, discussion ensued, POC was expanded, consensus was formed

  • kerneldoc comments work as always using kernel-doc directive, so no need to change them

  • but those comments can now contain RST directives

  • cross-references now available

  • function / data structure indexes

  • much nicer output

  • simpler, faster document build

  • uses the RTD theme

  • to add to the docs just drop an RST file in the Documentation directory and add it to index.rst

  • Current status:

    • merged for 4.8

    • Sphinx documents, kernel documentation HOWTO, GPU documentation, Media subsystem

  • For 4.9:

    • Documentation/driver-api

    • merge disparate files so HSI is documented in one place

    • dev-tools book

    • PDF output (painful, using LaTex)

  • For 4.10:

    • process book

    • core-api book

    • admin-guide book

  • Future work:

    • convert other DocBook docs and eventually eliminate DocBook entirely

    • rethink the kernel-doc utility (20 years of Perl cruft)

    • incorporate more plain-text documents

    • bring some order to the Documentation directory

    • more and better documentation

Writing less, saying more: UX lessons from the small screen

Claire Mahoney

  • in UX the small stuff is actually often the big stuff

  • think of the user as someone to help, someone you want to give a good product experience

  • you don't want them to spend time in docs; they need the answer and they need to get back to work

  • mobile user "on the go" is a misconception - really, mobiles are used everywhere - device + location + what the user wants to do

  • "lite is alright": myth that mobiles are for casual stuff; people will go to bigger devices for real work

    • but this is not necessarily true; we want the same functionality regardless of the device

    • mobile users are very needy humans: they want parity between devices

  • parity is great, but not always realistic. It can lead to excess noise.

  • so simplification of the interface while retaining features is important

  • shake to send feedback is a neat way to hide some of the complexity of the full UI

  • context can be better than words

    • screen design and function can be better than words

  • context can't do everything, sometimes you need words

    • but it can be very challenging to reduce text down to the appropriate size

    • you need to sweat the details, like push notifications

  • UX testing takes place in Atlab in Sydney

  • Style nests

    • Atlassian (ADG)

    • Native (iOS and Android)

    • Web mirroring style

    • Discretionary styles

  • patterns are good, repetition is not

  • voice and tone are important and form a pattern as a well. For example, Atlassian uses "practical with a wink".

  • it is important to remember that you are not your customer; you are not your user

  • ease of use and clear purpose > attractive design and quality of microinteractions

  • user -> app -> objective

Effective docs writing: Practical writing style explained with computer science

Joe Robinson

  • inspired by Squirrel Girl, Joe explained sentence construction using code logic

  • this is a great approach for understanding language syntax, especially for people who may know programming logic better than English grammar

  • unfortunately I couldn't take more detailed notes because I was at the back of the room without my laptop

Helping Caterpillars Fly

Nicola Nye

  • Cyrus is an open source email providing platform

  • the life cycle of a caterpillar is similar to the life cycle of software

  • FOSSy the Caterpillar

  • you have a good idea and get it upstream, then it starts catching on and people start adding to it until it gets so big it forms a cocoon.

  • it will either turn into a butterfly, or it will fail to hatch

  • so how do we turn into a butterfly?

  • reasons for failure and how docs can help:

    • poor documentation -> better documentation

    • contributor turnover -> knowledge sharing

    • creeping feature bloat -> define core goals

    • poor quality -> document standards

    • poor usability -> feedback to developers

    • no users -> marketing docs - explain what and why

  • people

    • paid technical writer (identify stakeholders, make a business case, cost/benefit analysis, company already 'paying' for FOSS)

    • audiences (existing user, marketing, new user, administrator, contributors, 'help me, I saw an error message this one time')

    • communication (global contributors and users, community, tools like IRC, MLs, bug trackers, etc.)

  • processes

    • curators (developers, users)

    • regular reviews (out of date is worse than none, last reviewed date, SME vs fresh eyes vs users)

    • cleanup (remove old docs and clean up your search results)

  • tools

    • selection (consider your users, consider your contributors)

    • templates (document types, style guides, support tools, feed processes; these lower the barrier to entry)

  • danger!

    • not all documentation is good documentation

    • danger signs include lots of FAQs, no introduction for new folks, docs not with code, lack of clear categorization (IA)

  • Three most important doc things:

    • paid documentation advocate

    • make it easy

    • regular reviews

Wednesday Jan 18

Designing for Failure

Dan Callahan

  • Persona was an open source authentication system that let you log in to an email provider, then use those credentials to log in to other sites

  • Persona arose because 5 years ago site-specific passwords were causing serious problems with security and there were many password breaches

  • we needed to move away from the traditional password per site approach

  • Persona allowed users to identify using any email address they chose

  • Persona has now been decommissioned

  • free licenses are not enough:

    • persona had an intractable point of centralization

    • bits rot more quickly online

    • complexity limits agency

    • in other words, a free license doesn't further freedom if people can't run the software

  • prolong your project's life:

    • measure the right thing

    • explicitly define and communicate your scope

    • ruthlessly oppose complexity

  • plan for your project's failure:

    • if you know you're dead, say so

    • ensure your users can recover, without your involvement

    • use standard data formats

    • consider how to minimize the harm caused when your project goes away

  • talk about failures and learn from the experiences of others

Listening to the Needs of Your Global Open Source Community

Elizabeth K. Joseph

  • provides simple way for contributors to contact project owners

  • acknowledge every piece of feedback

  • stay calm

  • communicate changes and ask for feedback

  • check in with your teams

  • document your processes

  • but don't beat people with the documentation, still be polite and responsive to questions

  • read between the lines; understand what isn't being said

  • developing principles:

    • have clear software choices

    • establish an open source policy

    • boundaries for support

    • define what you're willing to compromise on

    • trust your high level view

    • consider your users: what makes your life easier as a developer may not be the best option for your user

Stranger in a strange land: Breaking language monocultures with open source

Russell Keith-Magee

  • Python is a very popular language because it is both powerful and accessible

  • Python works for many purposes, but does not work natively on many platforms

  • polylingualism is required to work on multiple platforms

  • for professional devs this isn't necessarily a problem, but for other people this is a barrier to multi-platform development

  • and it is not really polylingualism, it is parallelized monolingualism

  • BeeWare: The IDEs of Python

  • what is python?

    • a language specification

    • a reference implementation (CPython)

    • this distinction is useful, because it means Python can be run using different implementations

  • monolingualism isn't healthy for platforms

JavaScript is Awful

Katie McLaughlin

  • variables are global by default

  • duck typing can be confusing

  • == is not the same as ===

  • JavaScript was developed in 10 days and has no versions

  • it has been owned by a few different companies over time, and its evolution reflects this

  • ECMAScript is the name of the actual standard

  • because there are no versions, you can never make an update that breaks the API because the internet would break

  • CSS and HTML5 can implement most of what JavaScript can do

  • Or you could use a cross-compiler, such as Skulpt or Batavia (part of BeeWare), which cross-compile Python to JavaScript

  • for a list of Python to JavaScript cross-compilers, see https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js

Challenges when scaling: Continued adventures in Swift's sharding

Matthew Oliver

  • at Geelong last year Matt claimed he had a solution. It didn't quite pan out. So he is back to talk about his new solution.

  • Journey so far:

    • object hashing: shard_no = md5(object) >> shard_power

    • distributed prefix trees

    • pivot points / split tree: this worked fine in small scale testing but didn't scale

    • snipping: but at any point in time primary nodes could be in any other state

  • current POC:

    • read only DB to hold metadata, pivot references, and objects

Non-native English speakers in Open Source communities: A True Story

Masayuki Igawa, Dong Ma, Samuel de Medeiros Queiroz

Cultural challenges

Japanese

  • NOT say "yes/no" clearly

  • tend to be perfect

  • keep intonation

  • size of economy

  • focus on reading and writing

  • pronunciation and grammar are very different

Chinese

  • Confucian culture

  • Doctrine of the Mean: one guideline is Leniency

  • like to say yes, don't like to say no

  • like to listen, don't like to negotiate

  • pronunciation not well understood

  • grammar is quite different from English grammar; this makes writing and speaking difficult

Brazilian - Portuguese

  • not as big differences as Asian cultures, but still some differences

  • short/direct responses may sound rude

  • "i" (Portuguese) is pronounced like "e" (English)

  • grammar: adjective position is opposite to English

  • some phonemes do not exist in Portuguese, e.g. th vs f

  • regular schools in Brazil do a poor job of teaching English

Language challenges

Reading

  • easiest most of the time

  • one of the most important

  • IRC conversation goes fast

  • long emails are tiring and conclusions can be difficult to follow

  • difficult to read between the lines

Writing

  • grammar

  • idiomatic English and/or long sentences is difficult

  • the speed of conversation in IRC is a challenge

Listening

  • variety of accents is harder for non-English speakers

  • speed

  • vocabulary, slang, idiomatic phrases and grammar

  • noisy environments make it much harder to hear accurately and it is difficult for non-native speakers to fill in the gaps

Speaking

  • vocabulary and idiom

  • grammar

  • pronunciation

  • speed and fluency

Overcoming obstacles

  • cultural challenges are harder than language challenges

  • language immersion is the best approach to learning

  • forget limitations; do your best and you will eventually improve

  • reading improves vocabulary

  • communicate daily

  • use available tools

  • practice with yourself and others

  • one-to-one conversations are really good practice

How newcomers can help themselves

  • be friendly

  • find a mentor

  • share your opinion

  • prepare in advance

  • ask questions

  • brush up on your English skills

Tips for native speakers

  • be patient

  • speak slowly

  • use simple words and sentences

  • encourage communication

  • do not make fun

Thursday Jan 19

Consider the Maintainer

Nadia Eghbal

  • is it alright if a project struggles or dies because a maintainer can't keep up with it anymore

  • is it alright to compromise or even deliberately ignore the happiness of maintainers so that we can enjoy FOSS?

  • more people are consuming open source than ever before

  • two-thirds of top GitHub projects are maintained by one or two people

  • why haven't the number of maintainers grown in proportion with consumption?

    • style of production has changed (more small projects)

    • maintaining isn't glamorous

    • maintainers lack support and mentoring

    • the open source ecosystem encourages contribution but not maintenance

    • both free and open source software are oriented around the user, not the producer

  • four proposed freedoms of open source producers:

    • to decide who participates in your community

    • to say no to contributions or requests

    • to define the priorities and polices of the project

    • to step down and move on from a project, temporarily or permanently

  • things maintainers need help with:

    • community best practices

    • project analytics

    • tools and bots

    • conveying support status

    • finding funding

    • existential questions

  • "What is clearly missing from [Eric Raymond's] statement, and is ultimately as important, is how those eyeballs are organized."

  • everyone is a potential contributor in open source software

Reproducible Builds for a Better Future

Valerie Young

  • reproducible-builds.org

  • "a build is reproducible if given the same source code, build environment and build instructions, any party can recreate it."

  • Goals:

    • reproducible binaries

    • reproducible build environments

  • reproducible builds improve security and reliability

  • Debian started continuous testing of all packages at the end of 2014

  • 2013: 24% reproducible

  • 2017: 97% reproducible

  • tested by building twice then comparing the bits

  • diffoscope is used to compare diffs of binaries

  • common issues:

    • build timestamps: these are not really necessary; better to use SOURCE_DATE_EPOCH

    • build paths: no solution yet, but SOURCE_PREFIX_MAP variable is in development

  • but reproducible binaries are not enough, you also need reproducible build environments so all users can reproduce the build

  • a sandbox (bundled the environment) is one approach

    • but can you trust the bundled OS?

    • the process may be big and/or slow

  • .buildinfo files

    • standard in Debian

    • created and signed when building a binary

    • links source, binary, and build environment

    • ongoing work to improve .buildinfo file distribution, provide RPMs and create tools to build the environment from a .buildinfo file

  • delivering build environment metadata with binary software delivers the freedom to users to study and modify the software

  • makes GPL compliance easier

  • guaranteed compilation

  • easier to audit binaries

  • insurance against compromised developers and tools; you would need to compromise everything, otherwise the bit difference would flag a problem

Content as a driver of change: then and now

Lana Brindley

  • technical documents have long been a part of human communication

  • master and apprentice model is a form of oral technical communication

  • by the time of the industrial revolution, literacy and writing materials became more widely available

  • at this time, journals and letters became more common

  • recipe books became a common form of manual

  • in recent times, paper manuals were the standard for technical manuals

  • whitepapers are halfway between technical writing and marketing

    • printed whitepapers are nearly dead though, as electronic versions are more prevalent

  • training courses are also moving online

  • online books are good, but they are not necessarily the best format for the internet

  • massive open online courses are the future of training courses

    • they can reach more people than traditional training

    • they can offer online labs to supplement the teaching

  • data typing (DITA) allows writers to organize content in useful ways, to streamline content, and to store discreet pieces of content in databases

    • DITA has the benefits of being simple enough to use easily, but complex enough to provide a strong structural model for recording knowledge

  • single sourcing allowed us to move away from telling a story to presenting information in pieces as people wanted it

    • users could access information when they want

    • content could be presented in a variety of ways

  • user-side content curation

    • shifts the responsibility of content curation from the writer to the user

    • Wikipedia is a good example of this model

    • but we do lack tools for doing this well with large sets of technical documentation

  • the future:

    • the internet offers new possibilities for technical communication

    • content development is shifting to consumers

    • users want control of the information they receive

The journey of a word: how text ends up on a page

Simon Cozens

  • text layout doesn't just happen

  • certain characters, such as letters with diacritics, can be represented in multiple ways by Unicode and the displaying application must be able to render it correctly

  • Unicode encodes the semantics of a letter: an 'm' is an 'm' is an 'm'; it does not care how the letters are displayed

  • abugida is a kind of syllabary in which the vowel is changed by modifying the base consonant symbol, so that all the forms that represent a given consonant plus each vowel resemble one another

  • a font is a database, and a font file is a list of database tables

  • advanced configuration options like kerning and diacritic/character attachment positions can be set

  • HarfBuzz works with text and font to shape the output

  • PDFs are flat files that contain metadata in the form of dictionaries, arrays, and objects. PDF essentially is a tree storage format, similar in concept to something like JSON.

At-rest Encryption in OpenStack Swift

John Dickinson

  • at-rest encryption feature landed in 2016

  • Swift is an object storage system that can store unstructured content at massive scale, with redundancy and high availability

  • Swift uses a REST API

    • https://swift.example.com/v1/AUTH_acct/cont/obj

    • this provides us with the account, container, and object

    • client <-> proxy <-> storage node

  • So where should we encrypt the data? Client-side or server-side?

    • answer depends on the threat model

    • Swift needs to secure data on hard drives from being exposed if the hard drive leaves the cluster

    • so Swift needs data at-rest server side encryption

  • data, metadata, and tags need to be encrypted

  • but not everything, such as the size of the object, needs to be encrypted

  • encryption requires a whole lot of keys and keys encrypting keys

  • master and derived keys are kept on the proxy server, so if a storage node leaves the cluster it is physically separate

  • a random key is used to encrypt each object, then the random key is encrypted using a derived key. The encrypted random key is sent with the object to the storage node with the data

  • currently the master key is stored in a configuration file; remember that the threat model is hardware leaving the cluster, not people with access to the server

  • metadata is generally stored in extended attributes on top of the object file

  • performance is good; in fact there is no discernible difference between plain data and encrypted data. This is aided by recent changes in chip design that improve encryption speeds.

Friday Jan 20

Keeping Linux Great

Robert M. "r0ml" Lefkowitz

  • FLOSS is yesterday's gravy; it is in decline

  • therefore we should:

    • build: small pieces on an expanding base (lithification)

    • so we can have: free running software (app freedom)

    • because what we really want is: end user development

  • "We won the battle for Linux, but we're losing the battle for freedom." - Doc Searls

  • Dependencies should be >5 million lines of code, 20 better. That way there are only a handful of them. Anything smaller and you should just copy it into your own code.

  • Advanced programming environments conflate the runtime with devtime - Bret Victor

  • open source at devtime isn't enough; we need to ensure open runtime = Liberal Software

  • 35% of needs could be addressed by a high-level development tool that offers basic data collection and manipulation

  • 40% could be satisfied by 5 generic web apps (mail, shopping cart, etc.) that can be customized

  • we had to convince the world that code is literary so we could copyright it; if it was a useful artifact, we would patent it

Data Structures and Algorithms in the 21st Century

Jacinta Catherine Richardson

  • the word algorithm is a Latin transliteration of an Arab scholar's name who was an early father of algebra

  • with scattered points, how do you predict usage? Voronoi diagram.

  • Fourier Transform: decomposes a function of time (a signal) into the frequencies that make it up, in a way similar to how a musical chord can be expressed as the frequencies (or pitches) of its constituent notes. Often used for compression.

    • Nearly Optimal Sparse Fourier Transform: O(K log N)

    • developed in 2012, this can dramatically speed up transforms

  • Single Value Decomposition: a factorization of a real or complex matrix. Used for signal processing, pattern recognition, etc.

  • Genetic algorithms: can be applied to engineering problems, such as designing a better antenna

My personal fight against the modern laptop

Hamish Coleman

  • Ideal laptop:

    • easily portable

    • suitable for all-day use

    • runs Linux

    • no blobs

    • actually a laptop

    • durable

  • Scope:

    • skills to do only one or two things

    • look at needs and focus on the important things

    • what can one do to change the keyboard?

  • connectors were the same, so they could just be swapped in

  • but some key placements were different

  • rather than rewire the board, one could update the software

  • but the initial patch for the firmware didn't work fully

  • so needed to patch some software to enable analysis of firmware

A guide to selecting FOSS licenses for programmers and open culture enthusiasts

James Scheibner

  • ultimately, open source licenses allow developers to control what is done with their code

  • releasing source code without a license != public domain

    • great if you want your software to be used as widely as possible

    • no control over how software is used

    • there is a bare copyright applied

    • may discourage others from using your code

  • license your code if you want to control:

    • who uses it

    • how they use it

    • what software they use it with

  • how do open source licenses work at law?

    • combination of contract and copyright law

    • contract law used to give effect to license formation: "by modifying and distributing the program, you indicate acceptance of this license". Notify users of the license!

    • copyright law gives effect to the conditions that control use of the software and attaches to the originality of the work

  • different types of FOSS license:

    • permissive: includes an attribution requirement only (BSD/MIT)

    • restrictive: includes a relicensing requirement for "derivative works" (GPL/AGPL/LGPL/CC-BY-SA)

  • when is an open source license breached?

    • permissive: breached when there is no attribution; you can only seek damages if there is a breach

    • restricted: remedies for both lack of attribution and for failure to relicense derivative work

  • "derivative work" is still being defined for software as cases are decided

    • is it common or unique?

    • is it a simple or complex?

  • in Australia, the term used is "adaptation", not "derivative work". It is unclear whether these are the same thing

  • open data licensing

    • mere compilations of data are not original

    • note the EU's sui generis rights

  • license choice:

    • public domain: if you don't care about controlling it

    • permissive: if you want attribution but don't care who/how it is used

    • restricted: if you want attribution and some control over the use of your code

    • data: you may want to license data separately from code

Designing a Race Car with Open Source Tools

Dave Chinner

  • building a Locost Clubman

  • it is a simple car built around the design of the 1950s Lotus 7

  • tools used:

    • FreeCAD: includes 3D CAD, finite element analysis software, Python scripting

    • suspension geometry modeling

    • CFD software for aerodynamic modeling

    • CNC controller