LCA 2017 Day 5

A turn to the wet weather in Hobart today, with rain that reminded me firmly of home.

Opening Matters

Multiple folks missing out on thier raffled goodies because apprently no-one wants free stuff.

The MONA festival is on this week across Hobart, with installation art across the city, and will run through the weekend.

Keeping Linux Great

Robert M. “r0ml” Lefkowitz

This was one of the densest (in terms of idea per minute) talks I’ve seen at a conference. I think I may have sprained something in my wrist trying to keep up, and I’m going to have to go back and update them after re-watching. And even then I don’t think I’ll get more than a fraction of it.

“The three talks that went before raised deep, insightful questions about the future of open source; rather than pose questions I’m going to provide answers. Since I have so many answers, because there are so many questions, I will not explore them in depth. The other difference is that the three people who have gone before have been nice people.”

“If satire is a problem, now would be a good time to leave.”

• Pia said we do not have to go into the future encumbered by the past.
• Dan Callahan said free licenses are not enough, and he was so correct.
• Nadia said we have to think about uncomfortable issues.

“What is the future of free and open source software? [FOSS] has no future.”

1. FOSS is yesterday’s gravy; therefore we should:
2. …build small pieces on an expanding base
3. …so we can have free running software
4. …because we really want end user development.

The run of free and open software is coming to an end. I’m not saying this because I dislike FOSS; free software had a great run, from about 1984 to 1998; it did a great job at liberating techology. Open software had a great run, maybe twenty years, invented in 1998. Before all that, we had public software.

The reason it’s coming to an end is because the norms and techniques of free software have been based on the state of technology when they were developed. You couldn’t have done a merge in the days of punch cards; free software has been enabled by the ability to merge code, to do pull requests. As tech changes, we need to change strategems.

Yesterday’s Gravy

If you think r0ml is just a bozo, bear in mind he’s not the only one saying this; Tim O’Reilly, Doc Searls, and many others are saying the same thing.

We won the battle for Linux, but we’re losing the battle for freedom - Doc Searls

If you all you care about is Linux, yay! But if you care about freedom, it’s not so good.

In fact, not just “open software”, but “free software”, and even software itself is becoming less popular and interesting to people. Software is eating the world? The world has lost interest in software.

(r0ml shows this with a long succession of Google Trends showing that everything except applications is declining. “This is just Google Trends, right. People don’t need to search for software. They know what it is, right?” r0ml has answers for that objection, too; pointing out that Trends also shows a some trends we do like, such as the loss of popularity of CVS vs Subversion.)

But people are getting more and more interested in apps. Aren’t apps just software? Is r0ml a bozo? Well… sure, apps are software. And yet no, they aren’t. (And r0ml isn’t a bozo).

“For those of you who think apps and software are the same thing, I have to call up the ghost of William of Ockham”: when he was alive, he was famous not for the idea of Occam’s Razor, but rather for his role in the debates between ontologists (who believed that things have a discoverable, categorisable nature) and nominalists (who believe that things are what people believe them to be; categories are purely a social construct we lay over things).

The nominalists would say that apps and software are two different things; what people think is the reality. The ontologists would say that the distinctions are artificial and wrong and needless. Do we think they’re really the same thing… in which case you should ask yourself “is Linux an app?”

Lithification

On of the powerful parts of the Unix design is the idea of small pieces loosely joined. It’s an idea which has also been argued as the success of the web: loose coupling between many composable elements.

Lithification is a geological process by which sand - sediment - is compressed into sedimentary rock, which is going to be the metaphor we use to discuss what’s happening with software.

Using intents on an Android device can mimic this behaviour: you can open an app, work on a thing, and then send that thing to another app for something else to happen. This is very much in the spirit of CMS pipes, Unix pipes, and so on. Mind you, that contrasts with Emacs, which expanded to send email (per Zawinski’s Law). But you don’t have to build things into other things, you can just have one appplication know how to talk to another application.

r0ml wants to introduce another myth, to supplant the founding printer myth¹; r0ml has a penchant for including book covers in his slide decks. To make this easier he wanted to write an app that would pull book covers off the Internet based on a barcode lookup.

In modern phone and tablet OSes the API can provide far richer information than that: rather than having to work out how to go from a scanned bardcode to a usable barcode string, you can just ask the camera if there’s a barcode visible, and, if so, what it is. It will also tell you if there’s a face, and if the phone OS recognises it, whose face it is. [I was not aware of this, which is pretty amazing]

Which raises an interesting question. Is that a Linux capability? What is Linux? Is Ubuntu Linux? Sure! Is Android Linux? Well, maybe? We have a vested interest in this because we’d like to believe weve won.

The problem is that Google Trends tells us that people don’t see Android as Linux. They see at as another thing, which gets us lined up with the nominalists. So what should we do about that?

Well, the reason these commercial Linuxes are succeeding and the traditional ones aren’t is what Google call vendoring, r0ml argues: Google bundles (and encourage app makers) to bundle everything up, into cleanly distributable, fully-functional units. That’s lithification.

So we don’t do in the free software world. Because it feels wrong. Even though there’s no technical reason for it to feel wrong.

Butler Lampson argues that “Only the giants survive.” Eliminate your dependencies. Bundle everything in your project, unless it’s so huge - say 5 million lines of code, maybe 20 million, maybe even more - that it’s worth leaving as an independent unit. Lampson argues for a bifurcation, where everything is either a giant, or very small, with nothing mid-sized in-between. [This feels intuitively like what goes on with text editors: I know how to drive nano and enough of vim to edit system files when I need. Otherwise I resort to a bigger unit like Visual Studio Code. It’s hard to imagine being in a half-way house between the two. Others would probably argu even VSC is too small and one should go straight to a heavyweight IDE.]

Small apps with well-defined communication channels can use the huge, low-level monoliths. You can have Android or iOS. But you can’t have much in-between.

r0ml cites the “left-pad problem” - we create needless entities because of our fear of repeating ourselves, so when we go to build a small to-do application we find that it pulls in thousands of libraries and hundreds of thousands of lines of code, none of which we really understand, and most of which we don’t actually use.

Now, we may not be able to individually build anything as huge and complex as Android. But we can think about eliminating dependencies, by using lithification. When we’re tempted to bring in dependencies because we need a couple of functions, just vendor them up: copy the code from the two functions we need from the twenty it provides. Instead of thousands of lines of code, weve imported two dozen, and we know what it’s doing. Even if it feels wrong at first.

App Freedom

We are continually faced with a series of great opportunities brilliantly disguised as insoluble problems - John W. Gardener

Which leads us to app freedom. Bret Victor argues that:

“advanced programming environments conflate the runtime with the devtime.”

This is antithetical to free software as we understand it through the four freedoms. These assume a world where there is a clean seperation between a compiler environment and the executable environment.

We don’t live in that world any more. (And we didn’t live it in the past, really: Smalltalk, for example, shipped whole images.)

r0ml talks about the point in the 80s when people realised that programs were becoming to complex to continue with the model of one or two people maintaining them, or letting everyone see the source and hoping that would work, with reference to Brad J Cox’s Object Oriented Programming: An Evolutionary Approach. This aimed for an industrialised model of development, where you defined interfaces between components of code and you could just rely on interfaces, and we could avoid these problems. Pity it didn’t work out.

The other thing that happened around that time was that the FSF could charge hundreds or even thousands of dollars for CD-ROM copies of source (or binaries!) to a GNU or Linux distro. Downloading was expensive, compiling was hard and expensive. But we don’t live in that world any more. The hard part is no longer downloading and building source. You don’t use your own computer any more. You use someone else’s computer, someone else’s runtime environment. Gmail, Office 365, Trello, you name it.

The hard part is replicating the runtime environment. Consider what would happen if you wanted to replicate Gmail. Google in your basement is hard. That’s the bigger impediment than the fact you don’t have access to Google’s code. So you want to be able to modify and run the code elsewhere.

In a world where the runtime is complex and hard is freedom to access the source more valuable, or freedom to modify the runtime? Would it be better to have access to GitHub’s source code and assemble a GitHub in your basement, or to be allowed to modify the way GitHub itself works?

If you can set up those things on your computer, would you let other people run software in your basement? [I do, as it happens, but I acknowledge that, in general, we don’t.] Are you providing freedom if you just provide people with software they can’t run because the environment is too complex?

So how do we leave people with the freedom to tinker? Well, we could demand that GitHub give us their software, replicate their infrastructure in our basement, and then insist all our friends use our BasementHub. Or not, because they’ve all got their own BasementHub. r0ml does not see the need to spell out why he thinks that doesn’t work at scale, leaving a pause for the audience to chuckle.

As an alternative, consider this: what if we could convince GitHub to let us patch the functionality of their software, and to run our modifications in their complex, hard-to-replicate environment. To give users the freedom, not via modification of the source code, but modification of the runtime environment.

Unfortunately the GPL not only doesn’t solve this, but Section 6 of the GPL v3 actively forbids you from making modifications that may interfere with the runtime - and since the owner of the runtime makes that decision, it pretty much forbids freedom.

How could that work? Well, imagine a world where you can decide which version of GitHub you requested! Good news, you can. r0ml’s mod_git allows you to serve arbitary versions of the web site; you can see HEAD, or TIP, or particular versions. That doesn’t, admittedly, solve the problem of needing the source code today, but it’s a first step. It’s a way, like lithification, to exercise that muscle.

r0ml calls this…

Liberal Software

But how do we make this work in practise? Wouldn’t it be great if we had some sort of organisation that were committed to solving this problem? We couldn’t call it the free software foundation, because people see “free” and they think “costs nothing”. We could use a word derived from the Latin for free².

“If you think I’m a bozo, you need to join Software Freedom Conservancy, because they’re the vanguard of trying to push free and open software into the future and preventing people like me from ruining it. And if you think that I have an excellent point and that this might be the future, we still need free software to build it. We still need somebody to be the rearguard to prevent the barbarians from overruning us while we build this future. So if you agree with me you should join software convervancy.”

End-User Development

Computer programming for everyone: we’d have a lovely utopian world where everyone would learn to program. It dropped off from a utopian ideal, but has returned with programming bootcamps and such, with a new driver: not a better future, but to keep our job. There’s an idea everyone needs to become aprogrammer to keep their job. But is it true? After all, r0mz’s son is studying to be a ballet dancer. No-one asks about Python in his interviews.

And, by the way, Google Trends shows jobs for programmers are going down, while ballet dancers are on an uptick. “I don’t make this up, I just struggle with the answers.”

And when ordinary people become programmers what do they use? Excel. More people have solved problems with spreadsheets than with anything else. And yet you don’t hear free software people advocating for spreadsheets.

Well, one problem is the code is mixed with the data. I may want to share my macros for calculating my tax return, but probably not my financial details.

But other than that… well, most of our requirements can be met through spreadsheets and Access, and such. And most customisation that meets the remaining needs of users (the 25% of requirements that can’t be met with Excel, for the sake of the argument) is probably not met by traditional software development³.

In fact, the idea of source code release becomes antithetical to freedom: if I want to customise my thermostat I do not want to read 100 page EULA and 20 million lines of code. In fact, ideally r0ml wants is a Star Trek universe where just as one can ask for tea and get perfect tea, one can ask for an app and get an app, tailored to one’s needs⁴

The problem is that this future requires tremendous amounts of information to be held about us, and processed by complex AI-level back ends. Do we want those fully disclosed? Is that wise? After all, the source won’t run without the environment and the data, and the environment and the data know a lot about us. In fact, in a world where the code and the data are so tightly coupled, free software implicitly requires a data release. Do we want that? Isn’t that a bit Big Brother? Or is it more radical transparency? Either way, if the only way to get your freedom to tinker is to allow the freedom for others to know everything about you, is that a freedom you want?

We’re already starting on the path of reliably generating libraries and applications and deploying them to environments we don’t control. So how do we give people freedoms that matter to them?

This was one of the densest (in terms of idea per minute) talks I’ve seen at a conference. I think I may have sprained something trying to keep up, and I’m going to have to go back and update them after re-watching.

Publicly Releasing Government Models

Audrey Lobo-Pulo

We live in a complex society; when we vote, how well do we understand what we’re voting on and what effects it might have. Compare that with an admittedly simpler model of computer games - where we can understand the rules and how to optimise for the outcomes we want⁵

“We cannot see the path of individual drops of rain falling into a valley - but we can see where they will go in aggregate.” Policy modelling using analytics tend to live in this arena.

There are a lot of reasons for policies to be proposed; but we live in a qualitative world. As computational has improved, we can analyse and test policy options more quickly and thoroughly than before; ideally we would present better, more thoroughly and intelligible analysis to the public.

Ideally, we would do this in the open: allowing for more sophisiticated, intelligble respresentation of policies, driven by more powerful platforms and data management and analysis tools. This also comes with concerns around the management of that data, of course.

Government policy models exist to provide a way of testing policy ideas so we can make better decisions about which policy is most likely to get the oputcomes you care about.

We need useful inputs to be available:

• software to be developed
• economic assumptions to be used
• behavioural economics
• policy implementation

So what if these were freely available? Government Open Sourcce Models (GOSMs) freely available to everyone to use, distribute, and modify.

“Public policy must become multidisciplinary, more agile, more open, and more networked” - Global Digital Foundation.

[I note Audrey makes a throwaway comment that Watson could be a useful tool, but that also highlights a risk; how do you know whether IBM would tweak Watson’s behaviour to skew policy in a direction favourable to Big Blue?]

There are some reasons that government policy models aren’t all equally releaseable, particularly if they depend on data which is inappropriate to publish widely'

Principles of Public Release of GOSMs:

1. Open by default.
2. Community collaboration.
3. Minimum Viable Product release.
4. Easily discoverable.
5. Clearly outlined use and licensing.
6. Maximum possible access.

Whose code is it anyway? Ideally, a public good. Which leads us to licensing the information - so we can’t have entities use enahance public models without sharing them with society.

Which software license would be most appropriate? Does the software matter most? Is requiring the sharing of the code critical? Audrey argues that the policy model is much less intersting than the data; in fact, using the software being used for the policy models with closed data may allow private entities to more effectively game society for their benefit more effectively.

There’s little point releasing code under a license that makes it harder to use and contribute to.

Imagine a Government Open Model Platform, where models and data can be used depending based on which data and models you are able to access; private entities could be encourage to share models and data on this platform, creating a “marketplace of models” for public and private entities to test ideas.

Q&A

• We’ve heard that “people are sick of experts” in the context of the Brexit debate. How do we have people trust this analysis? By making it more transparent and easier for people to understand the drivers for decisions we can perhaps help people understand and trust these things.
• If there is room for exceptions to data and model release, how do we avoid their being wiggle room to avoid openness? This is a more general problem that includes, say, FOIA requests. There’s are no simple answers.
• If a model gives Australia a competitive edge in policy-making, is there a moral obligation to share that internationally? This is a tricky one and, like the model of sharing between companies, reuires more thouht.

The Business of Community

VM Brasseur

Expectations:

• Will provide tips for how to plead the case to support FLOSS projects.
• Will provide tips for how to make that happen.

What is community?

• A self-organised and self-identified collection of people sharing a concern of interest.
  • You cannot assign someone to communities. People will only identify with community they’re interested in, no matter how much you want them to.
• Types of community which are relevant to this talk:
  1. Formed around a product. Often the most enthusiastic; think Apple fans, sports teams, and so on.
  2. Formed around your company-created open source project; you’ve given a thing to the world, and people are working on it with you.
  3. Formed around another open source project.
     • You should focus on the ones which are most strategic to your company.

How do you convince your company? Well, you need a plan.

1. Benefits to the company.
2. Costs.
3. Implementation plan.

If you want to sell to people in your company, you have to speak their language, or you won’t get what you want.

Benefits of supporting a community:

• Word of mouth marketing.
• R&D the community may be doing testing and exotic use cases you haven’t considered yet. “Spin the disruption wheel.”
• Support.
• Recruiting. It’s hard to do and get right. But this introduces you to people.
• Project influence and power.

What are the costs?

It depends, because different communities have different requirements, and you need to listen to them.

• Monetary: event sponsorship, paying contributers, hosting, etc.
• In-kind contibutions: space, services.
• Work contributions: upstreaming code and docs, hirig developers. marketing.
• Guidance, leadership, mentoring.
• Listen and take action.

Build an implementation plan:

• Determine goals. Bad goals drive failures. This is the foundation of everything.
• Determine success criteria.
• Determine who to support, both in terms of communities and within in the community.
• Learn about the community - have they done this before?
• Consult your lawyer & accountant so you don’t commit to anything that will cause you grief; some things can be non-obvious, but they can come back and bite you; is someone gets hurt at a meet-up, who is liable⁶.

HAVE A NO ASSHOLE RULE

You do not want to be the asshole in the project, or be associated with a project of assholes. Consider having a community manager to help guide both your interactions with projects it sponsors, but also that the group are being sponsored affectively. “Community Manager” is an imperfect title for the role, because it implies that the role is managing the comunity on behalf of the company; instead, it’s

Some Pitfalls

• Being unprepared when pitching [see notes below].
• No ROI & metrics. This will make it look like your company is throwing money into a hole.
• Wrong metrics - arguably worse than no metrics.
• Not allowing enough time for results - it’s tempting to promise quick results to get initial backing, but many initiatives will take time to show results.
• Treating the comunity as a market. Contributing to the community is not the same thing as buying a bunch of parts off a shelf.
• Believing communities are interchangable. All communities have their own culture and nuances.
• Ignoring bad behaviour - help out fix the bad behaviour or pull out of the community; if you do nothing you become complicit.
• Messiah complex. Communities existed before you, and they will exist after; you aren’t saving them.
• Misconceptions of control. Contributions don’t mean you’re in charge.

Some thoughts

The one I mentioned to Vicky afterward, which I’ll repeat here is that the most helpful thing I found in learning to do a better job pitching in my workplace was to find mentors who can help beta-test my pitches with the kind of questions they’ll face; those questions will typically be quite specific, not just to your organisation, but to particular people in your organisation. If you can spend time testing your assumptions and pitch with someone who has already had success with those people, and incorporate what they tell you, you’ll have a much more convincing story.

Continuously Delivering Security in the Cloud

Casey West

“May the burning bridges light my path.”

This is a talk about operational excellence.

Casey kicked off by asking “Has your system been attacked?” Wait a beat while about half the hands in the roome go up, “I didn’t ask if you know if your system has been attacked.”

Systems are attacked because they’re there. Which means everything you know about security is wrong (in the cloud).

The grand change of resisting chamge to mitigate risk: we keep stuff small and do point in time tests, and no-one notices. That isn’t how the world works. This is a trap.

You have a choice:

• go fast with unbounded risk.
• go slow with mitigated risk.

This is a false dichotomy (in the cloud).

The scariest thing for security folks is the Advanced Persistent Threat - a small breach that persists and allows gradual, ongoing, increasing compromises. Traditional remedies, such as patching or reconfiguring in an effort to get rid of it don’t work, because it has its hooks too deep into your system.

Successful attacks have three ingredients:

1. Time.
2. Leaked or misused credentials.
3. Misconfigured or unpatched software.

IaaS gives us the opportunity to mitigate this, but only if we’re willing to go fast.

A moving target is harder to hit. Cloud-native operability lets us deliver security faster.

• Composable architecture (call it microservices, serverless, whatever).
• Automated processes - automate the path to ptoduction.
• Collaborative culture.
• Happy production environments (a reliable, structured environment).

The three Rs:

• Rotate. Rotate credentials every few minutes or hours. This requires we move away from hardcoded credentials between application components. Don’t generate them from people, use secrets services, password vaults and the like.
• Repave every server and application every few hours. Have enough instances of everything that you can drop instances on a whim. You should have load balancers that manage that.
• If you turn servers off when they aren’t being used, they can’t be compromised.
• You need to be confident that you can deliver to production reliably.
• From a security perspective, you don’t need to do this with software deployments, you can just do it to make reduce your attack surface.
• Repair. If our application has a flaw, if we need to update the JVM or Ruby interp, or SSL library, we need to update.
  • If you have a strong pipeline you can lower the friction required to push out new copies of these things reliably.
  • That confidence lets you reduce the window of vulnerability.

So the future of security is our build piplines.

• Bake in CVEs, blue/green deployments, credential rotation.

Embrace change to mitigate risk.

Lightning talks

Sorry, but I didn’t recording these; there would be little to no point, given their speed and many of them relying heavily on a visual element to work.

Closing

The raffle, plus various offers to match funds, and a last minute rush of donations started by Martin Kraft quickly snowballed into a final fundraising effort of a little more than $27,000, allowing the conference to sponsor three Tasmainian Outreachy interns, as well as provide them and their mentos with free tickets to LCA next year. Speaking of which…

linux.conf.au 2018

The sucessful bid for Sydney was announced: it will be Sydney in 2018, marking the first time that LCA has visisted a place for the third time.