Feed aggregator

Joe Liau: Utopic Unicron[sic]

Planet Ubuntu - Wed, 07/09/2014 - 21:14

I was playing around with possible designs for a Utopic Unicorn t-shirt when an inevitable (and awesome) typo lead me to…

SVG version here.




Paul Tagliamonte: Dell XPS 13

Planet Ubuntu - Wed, 07/09/2014 - 19:38

More hardware adventures.

I got my Dell XPS13. Amazing.

The good news: This MacBook Air clone is clearly an Air competitor, and easily slightly better in nearly every regard except for the battery.

The bad news is that the Intel Wireless card needs non-free (I’ll be replacing that shortly), and the touchpad’s driver isn’t totally implemented until Kernel 3.16. I’m currently building a 3.14 kernel with the patch to send to the kind Debian kernel people. We’ll see if that works. Ubuntu Trusty already has the patch, but it didn’t get upstreamed. That kinda sucks.

It also shipped with UEFI disabled, and was defaulting to boot in ‘legacy’ mode. It shipped with Ubuntu, a bit disappointed to not see Ubuntu keys on the machine.

Touchscreen works; in short -stunning. I think I found my new travel buddy. Debian unstable runs great, stable had some issues.

Ronnie Tucker: XFCE App Launcher `WHISKER MENU` sees new release

Planet Ubuntu - Tue, 07/08/2014 - 23:58

Whisker Menu is an application menu / launcher for Xfce that features a search function so you can easily find the application you want to launch. The menu supports browsing apps by category, you can add applications to favorites and more. The tool is used as the default Xubuntu application menu starting with the latest 14.04 release and in Linux Mint Xfce starting with version 15 (Olivia).

The Whisker Menu PPA was updated to the latest 1.4.0 version recently and you can use to both upgrade to the latest version obviously, as well as to install the tool in (X)Ubuntu versions for which Whisker Menu isn’t available in the official repositories (supported versions: Ubuntu 14.04, 13.10 and 12.04 and the corresponding Linux Mint versions). For see what is the  difference with the previous release, see the changelog in its main website.



Submitted by: Andrew

Nicholas Skaggs: Utopic Bug Hug and Testing Day

Planet Ubuntu - Tue, 07/08/2014 - 12:38
The first testing day of the utopic cycle is coming this week on Thursday, July 10th. You can catch us live in a hangout on ubuntuonair.com starting at 1900 UTC. We'll be demonstrating running and testing the development release of ubuntu, reporting test results, reporting bugs, and doing triage work. We'll also be availible to answer your questions and help you get started testing as well.

Please join us in testing utopic and helping the next release of ubuntu become the best it can be. Hope to see everyone there!

P.S. We have a team calendar that can help you keep track of the release schedule along with this and other events. Check it out!

The Fridge: Ubuntu Online Summit dates: 4-6 Nov 2014

Planet Ubuntu - Tue, 07/08/2014 - 11:54

in discussions at the last Online Summit and afterwards it became clear that we need to bring the summit dates closer to our release dates again. With the Unicorn being released on Oct 23, we decided to pick the following dates for the next Online Summit:

4th – 6th November 2014

This unfortunately won’t leave too much room for a mid-cycle UOS, as it’d get too close to Feature Freeze and other release/freeze dates. Michael Hall will start a discussion on ubuntu-devel-discuss@ about the subject of Ubuntu Online Summit soon, so we can discuss changes and start general planning. Your feedback and help are much appreciated.

If you should want to have any ad-hoc, public planning sessions before the next UOS, we’d like to remind you of Ubuntu On Air, which is a good way to get your discussion recorded and where you can very easily get people involved for the subject. Find out more info on https://wiki.ubuntu.com/OnAir

Originally posted to the community-announce mailing list on Tue Jul 8 10:42:20 UTC 2014 by Daniel Holbach

Ubuntu Online Summit dates: 4-6 Nov 2014

The Fridge - Tue, 07/08/2014 - 11:54

in discussions at the last Online Summit and afterwards it became clear that we need to bring the summit dates closer to our release dates again. With the Unicorn being released on Oct 23, we decided to pick the following dates for the next Online Summit:

4th – 6th November 2014

This unfortunately won’t leave too much room for a mid-cycle UOS, as it’d get too close to Feature Freeze and other release/freeze dates. Michael Hall will start a discussion on ubuntu-devel-discuss@ about the subject of Ubuntu Online Summit soon, so we can discuss changes and start general planning. Your feedback and help are much appreciated.

If you should want to have any ad-hoc, public planning sessions before the next UOS, we’d like to remind you of Ubuntu On Air, which is a good way to get your discussion recorded and where you can very easily get people involved for the subject. Find out more info on https://wiki.ubuntu.com/OnAir

Originally posted to the community-announce mailing list on Tue Jul 8 10:42:20 UTC 2014 by Daniel Holbach

Jorge Castro: Juju 1.20 is out the door!

Planet Ubuntu - Tue, 07/08/2014 - 11:48

The following is a guest post from Curtis Hovey, the Juju release manager. You can find the original announcement on the Juju mailing list.

Juju 1.20.0 is released

A new stable release of Juju, juju-core 1.20.0, is now available.

Getting Juju

juju-core 1.20.0 is available for utopic and backported to earlier series in the following PPA:

  • https://launchpad.net/~juju/+archive/stable
New and Notable
  • High Availability
  • Availability Zone Placement
  • Azure Availability Sets
  • Juju debug-log Command Supports Filtering and Works with LXC
  • Constraints Support instance-type
  • The lxc-use-clone Option Makes LXC Faster for Non-Local Providers
  • Support for Multiple NICs with the Same MAC
  • MAAS Network Constraints and Deploy Argument
  • MAAS Provider Supports Placement and add-machine
  • Server-Side API Versioning
High Availability

The juju state-server (bootstrap node) can be placed into high availability mode. Juju will automatically recover when one or more the state-servers fail. You can use the ‘ensure-availability’ command to create the additional state-servers:

juju ensure-availability

The ‘ensure-availability’ command creates 3 state servers by default, but you may use the ‘-n’ option to specify a larger number. The number of state servers must be odd. The command supports the ‘series’ and ‘constraints’ options like the ‘bootstrap’ command. You can learn more details by running ‘juju ensure-availability –help’

Availability Zone Placement

Juju supports explicit placement of machines to availability zones (AZs), and implicitly spreads units across the available zones.

When bootstrapping or adding a machine, you can specify the availability zone explicitly as a placement directive. e.g.

juju bootstrap --to zone=us-east-1b juju add-machine zone=us-east-1c

If you don’t specify a zone explicitly, Juju will automatically and uniformly distribute units across the available zones within the region. Assuming the charm and the charm’s service are well written, you can rest assured that IaaS downtime will not affect your application. Commands you already use will ensure your services are always available. e.g.

juju deploy -n 10 <service>

When adding machines without an AZ explicitly specified, or when adding units to a service, the ec2 and openstack providers will now automatically spread instances across all available AZs in the region. The spread is based on density of instance “distribution groups”.

State servers compose a distribution group: when running ‘juju ensure-availability’, state servers will be spread across AZs. Each deployed service (e.g. mysql, redis, whatever) composes a separate distribution group; the AZ spread of one service does not affect the AZ spread of another service.

Amazon’s EC2 and OpenStack Havana-based clouds and newer are supported. This includes HP Cloud. Older versions of OpenStack are not supported.

Azure availability sets

Azure environments can be configured to use availability sets. This feature ensures services are distributed for high availability; as long as at least two units are deployed, Azure guarantees 99.95% availability of the service overall. Exposed ports will be automatically load balanced across all units within the service.

New Azure environments will have support for availability sets by default. To revert to the previous behaviour, the ‘availability-sets-enabled’ option must be set in environments.yaml like so:

availability-sets-enabled: false

Placement is disabled when ‘availability-sets-enabled’ is true. The option cannot be disabled after the environment is bootstrapped.

Juju debug-log Command Supports Filtering and Works with LXC

The ‘debug-log’ command shows the consolidate logs of all juju agents running on all machines in the environment. The command operates like ‘tail -f’ to stream the logs to the your terminal. The feature now support local-provider LXC environments. Several options are available to select which log lines to display.

The ‘lines’ and ‘limit’ options allow you to select the starting log line and how many additional lines to display. The default behaviour is to show the last 10 lines of the log. The ‘lines’ option selects the starting line from the end of the log. The ‘limit’ option restricts the number of lines to show. For example, you can see just 20 lines from last 100 lines of the log like this:

juju debug-log --lines 100 --limit 20

There are many ways to filter the juju log to see just the pertinent information. A juju log line is written in this format:

<entity> <timestamp> <log-level> <module>:<line-no> <message>

The ‘include’ and ‘exclude’ options select the entity that logged the message. An entity is a juju machine or unit agent. The entity names are similar to the names shown by ‘juju status’. You can exclude all the log messages from the bootstrap machine that hosts the state-server like this:

juju debug-log --exclude machine-0

The options can be used multiple times to select the log messages. This example selects all the message from a unit and its machine as reported by status:

juju debug-log --include unit-mysql-0 --include machine-1

The ‘level’ option restricts messages to the specified log-level or greater. The levels from lowest to highest are TRACE, DEBUG, INFO, WARNING, and ERROR. The WARNING and ERROR messages from the log can seen thusly:

juju debug-log --level WARNING

The ‘include-module’ and ‘exclude-module’ are used to select the kind of message displayed. The module name is dotted. You can specify all or some of a module name to include or exclude messages from the log. This example progressively excludes more content from the logs

juju debug-log --exclude-module juju.state.apiserver juju debug-log --exclude-module juju.state juju debug-log --exclude-module juju

The ‘include-module’ and ‘exclude-module’ options can be used multiple times to select the modules you are interested in. For example, you can see the juju.cmd and juju.worker messages like this:

juju debug-log --include-module juju.cmd --include-module juju.worker

The ‘debug-log’ command output can be piped to grep to filter the message like this:

juju debug-log --lines 500 | grep amd64

You can learn more by running ‘juju debug-log –help’ and ‘juju help logging’

Constraints Support instance-type

You can specify ‘instance-type’ with the ‘constraints’ option to select a specific image defined by the cloud provider. The ‘instance-type’ constraint can be used with Azure, EC2, HP Cloud, and all OpenStack-based clouds. For example, when creating an EC2 environment, you can specify ‘m1.small’:

juju bootstrap --constraints instance-type=m1.small

Constraints are validated by all providers to ensure values conflicts and unsupported options are rejected. Previously, juju would reconcile such problems and select an image, possibly one that didn’t meet the needs of the service.

The lxc-use-clone Option Makes LXC Faster for Non-Local Providers

When ‘lxc-use-clone’ is set to true, the LXC provisioner will be configured to use cloning regardless of provider type. This option cannot be changed once it is set. You can set the option to true in environments.yaml like this:

lxc-use-clone: true

This speeds up LXC provisioning when using placement with any provider. For example, deploying mysql to a new LXC container on machine 0 will start faster:

juju deploy --to lxc:0 mysql Support for Multiple NICs with the Same MAC

Juju now supports multiple physical and virtual network interfaces with the same MAC address on the same machine. Juju takes care of this automatically, there is nothing you need to do.

Caution, network settings are not upgraded from 1.18.x to 1.20.x. If you used juju 1.18.x to deploy an environment with specified networks, you must redeploy your environment instead of upgrading to 1.20.0.

The output of ‘juju status’ will include information about networks when there is more than one. The networks will be presented in this manner:

machines: ... services: ... networks: net1: provider-id: foo cidr: vlan-tag: 42 MaaS Network Constraints and Deploy Argument

You can specify which networks to include or exclude as a constraint to the deploy command. The constraint is used to select a machine to deploy the service’s units too. The value of ‘networks’ is a comma-delimited list of juju network names (provided by MaaS). Excluded networks are prefixed with a “^”. For example, this command specify the service requires the “logging” and “storage” networks and conflicts with the “db” and “dmz” networks.

juju deploy mongodb --constraints networks=logging,storage,^db,^dmz

The network constraint does not enable the network for the service. It only defines what machine to pick.

Use the ‘deploy’ command’s ‘networks’ option to specify service-specific network requirements. The ‘networks’ option takes a comma-delimited list of juju-specific network names. Juju will enable the networks on the machines that host service units.

Juju networking support is still experimental and under development, currently only supported with the MaaS provider.

juju deploy mongodb --networks=logging,storage

The ‘exclude-network’ option was removed from the deploy command as it is superseded by the constraint option.

There are plans to add support for network constraint and argument with Amazon EC2, Azure, and OpenStack Havana-based clouds like HP Cloud in the future.

MAAS Provider Supports Placement and add-machine

You can specify which MAAS host to place the juju state-server on with the ‘to’ option. To bootstrap on a host named ‘fnord’, run this:

juju bootstrap --to fnord

The MAAS provider support the add-machine command now. You can provision an existing host in the MAAS-based Juju environment. For example, you can add running machine named fnord like this:

juju add-machine fnord Server Side API Versioning

The Juju API server now has support for a Version field in requests that are made. For this release, there are no RPC calls that require anything other than ‘version=0’ which is the default when no Version is supplied. This should have limited impact on existing CLI or API users, since it allows us to maintain exact compatibility with existing requests. New features and APIs should be exposed under versioned requests.

For details on the internals (for people writing API clients), see this document.


We encourage everyone to subscribe the mailing list at juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.

PS. Juju just got 20% more amazing.

Colin King: more stress with stress-ng

Planet Ubuntu - Tue, 07/08/2014 - 02:27
Since my last article about stress-ng I have been adding a few more stress mechanisms to stress-ng:
  • file locking - exercise file locking with one or more processes (the more processes the better).
  • fallocate - this allocates a 4MB file, sync's, truncates to zero size and syncs repeatedly
  • yield - this loops on sched_yield() to repeatedly relinquish the CPU forcing a high context switch rate when run with multiple yielding processes.
Also, I have added some new features to tweak scheduling, I/O characteristics and memory allocations of the running stress processes:
  • --sched and --sched-prio options to specify the scheduler type and priority
  • --ionice-class and --ionice-level options to tweak I/O niceness
  • --vm-populate option to populate (pre-fault) page tables for a mapping for the --vm stress test.
If I think of other mechanisms to stress the kernel I will add them, but for now, stress-ng is becoming almost feature complete.

Ronnie Tucker: Linux Kernel 3.15.3 Is Now Available for Download

Planet Ubuntu - Mon, 07/07/2014 - 23:58

Greg Kroah-Hartman had the pleasure of announcing earlier today, July 1, that the third maintenance release for the current stable 3.15 branch of the Linux kernel is available for download, urging users to upgrade as soon as their Linux distributions update the respective packages on the official software repositories.

The Linux kernel 3.15.3 is a pretty standard release that introduces various updated drivers, some filesystem improvements, especially for Btrfs and EXT4, random mm and Bluetooth fixes, and the usual architecture enhancements (ARM, ARM64, IA64, SPARC, PowerPC, s390, and x86).

Be aware, though, that upgrading to a new Linux kernel package might break some things on your system, so it is preferable to wait a few days and see if anyone complains about it on the official channels of your distribution.



Submitted by: Marius Nestor

Ubuntu Server blog: 2014-07-01 Meeting Minutes

Planet Ubuntu - Mon, 07/07/2014 - 20:35
  • Review ACTION points from previous meeting
  • U Development
  • Server & Cloud Bugs (caribou)
  • Weekly Updates & Questions for the QA Team (psivaa)
  • Weekly Updates & Questions for the Kernel Team (smb, sforshee)
  • Ubuntu Server Team Events
  • Open Discussion
  • Announce next meeting date, time and chair
  • bug 1317587 is in progress
Next Meeting

Next meeting will be on Tuesday, July 8th at 16:00 UTC in #ubuntu-meeting.

Additional logs @ https://wiki.ubuntu.com/MeetingLogs/Server/20140701

The Fridge: Ubuntu Weekly Newsletter Issue 374

Planet Ubuntu - Mon, 07/07/2014 - 17:52

Ubuntu Weekly Newsletter Issue 374

The Fridge - Mon, 07/07/2014 - 17:52

The Fridge: New Ubuntu Membership Board Members

Planet Ubuntu - Mon, 07/07/2014 - 09:44

Back in April and June the Community Council put out a call to restaff the Ubuntu Membership Board for several open spots on the board.

Today I’m happy to announce that the Community Council has appointed (or renewed membership of) the following individuals:

For the 1200 UTC time slot:

For the 2200 UTC time slot:

Thanks to all nominees for putting their names forward for consideration and thanks to the outgoing members who have served on the board these past couple of years!

Elizabeth K. Joseph, on behalf of the Community Council

New Ubuntu Membership Board Members

The Fridge - Mon, 07/07/2014 - 09:44

Back in April and June the Community Council put out a call to restaff the Ubuntu Membership Board for several open spots on the board.

Today I’m happy to announce that the Community Council has appointed (or renewed membership of) the following individuals:

For the 1200 UTC time slot:

For the 2200 UTC time slot:

Thanks to all nominees for putting their names forward for consideration and thanks to the outgoing members who have served on the board these past couple of years!

Elizabeth K. Joseph, on behalf of the Community Council

Jonathan Riddell: Frameworks 5 and Plasma 5 almost done!

Planet Ubuntu - Mon, 07/07/2014 - 07:42
KDE Project:

KDE Frameworks 5 is due out tomorrow, the most exciting clean-up of libraries KDE has seen in years. Use KDE classes without brining in the rest of kdelibs. Packaging for Kubuntu is almost all green and Rohan should be uploading it to Utopic this week.

Plasma 5 packages are being made now. We're always looking for people to help out with packaging, if you want to be part of making your distro do join us in #kubuntu-devel

Ronnie Tucker: Valve Updates SteamOS With the Latest NVIDIA, AMD, and Intel Drivers

Planet Ubuntu - Sun, 07/06/2014 - 23:57

The Beta version of SteamOS, a Debian-based distribution developed by Valve to be used in its hybrid PC / console, has just received an update and numerous packages.

Valve has two builds for SteamOS. One is a stable version (sort of) and the other one is a Beta (Alchemist). The two versions are not all that different from one another, but the Valve developers are using the Beta release to test some of the new updates before they hit the stable branch.


This is just the Beta version of SteamOS and not all of the packages included are stable. It will take a while until all these chages will be added to the Stable branch. The system requirements for Steam OS haven’t changed and have been pretty much the same since the beginning: an Intel or AMD 64-bit capable processor, 4GB or more memory, a 250GB or larger disk, NVIDIA, Intel, or AMD graphics card, and a USB port or DVD drive for installation. Check the official announcement for more details about this release.



Submitted by: Silviu Stahie

Daniel Pocock: News team jailed, phone hacking not fixed though

Planet Ubuntu - Sun, 07/06/2014 - 01:20

This week former News of the World executives were sentenced, most going to jail, for the British phone hacking scandal.

Noticeably absent from the trial and much of the media attention are the phone companies. Did they know their networks could be so systematically abused? Did they care?

In any case, the public has never been fully informed about how phones have been hacked. Speculation has it that phone hackers were guessing PIN numbers for remote voicemail access, typically trying birthdates and inappropriate PIN numbers like 0000 or 1234.

There is more to it

Those in the industry know that there are additional privacy failings in mobile networks, especially the voicemail service. It is not just in the UK either.

There are various reasons for not sharing explicit details on a blog like this and comments concerning such techniques can't be accepted.

Nonetheless, there are some points that do need to be made:

  • it is still possible for phones, especially voicemail, to be hacked on demand
  • an attacker does not need expensive equipment nor do they need to be within radio range (or even the same country) as their target
  • the attacker does not need to be an insider (phone company or spy agency employee)
Disable voicemail completely - the only way to be safe

The bottom line is that the only way to prevent voicemail hacking is to disable the phone's voicemail service completely. Voicemail is not really necessary given that most phones support email now. For those who feel they need it, consider running the voicemail service on your own private PBX using free software like Asterisk or FreeSWITCH. Some Internet telephony service providers also offer third-party voicemail solutions that are far more secure than those default services offered by mobile networks.

To disable voicemail, simply do two things:

  • send a letter to the phone company telling them you do not want any voicemail box in their network
  • in the mobile phone, select the menu option to disable all diversions, or manually disable each diversion one by one (e.g. disable forwarding when busy, disable forwarding when not answered, disable forwarding when out of range)

Ubuntu GNOME: [Guide] Learn About Ubuntu GNOME Community

Planet Ubuntu - Sat, 07/05/2014 - 07:05

Hello and welcome to Ubuntu GNOME Community Guide for Newcomers

If you are interested to join Ubuntu GNOME Community as a volunteer to help ‘or’ you have joined already and you are a newcomer to Ubuntu GNOME Community, then this simple guide is for you.

3-Simple Simple Steps:

  1. First, you need to read Ubuntu GNOME Community Wiki Page.
  2. If you require further details, here is a list of ALL Ubuntu GNOME Wiki Pages.
  3. If the above two steps were not enough, please Contact Us.

That is all what you need to know and/or do if you are interested to join Ubuntu GNOME Team or you have already joined but you can’t find your way easily and need some help

For those who would like even further details, here is our Getting Involved Guide. This guide will explain to you from A-Z how to get involved with Ubuntu GNOME.

As always, thank you for choosing and joining Ubuntu GNOME!

Ubuntu GNOME Leaders Board

Duncan McGreggor: Uncovering Inherent Structures in Organizations

Planet Ubuntu - Fri, 07/04/2014 - 16:31
Vladimir LevenshteinThis post should have a subtitle: "Using Team Analysis and Levenshtein Distance to Reveal said Structure." It's the first part of that subtitle that is the secret, though: being able to correctly analyze and classify individual teams. Without that, using something clever like Levenshtein distance isn't going to be very much help.

But that's coming in towards the end of the story. Let's start at the beginning.

What You're Going to SeeThis post is a bit long. Here are the sections I've divided it into:

  • What You're Going to See
  • Premise
  • Introducing ACME
  • Categorizing Teams
  • Category Example
  • Calculating the Levenshtein Distance of Teams
  • Sorting and Interpretation
  • Conclusion

However, you don't need to read the whole thing to the main benefits. You can get the Cliff Notes version by reading the Premise, Categorizing Teams, Interpretation, and the Conclusion.

PremiseCompanies grow. Teams expand. If you're well-placed in your industry and providing in-demand services or products, this is happening to you. Individuals and small teams tend to deal with this sort of change pretty well. At an organizational level, however, this sort of change tends to have an impact that can bring a group down, or rocket it up to the next level.

Of the many issues faced by growing companies (or rapidly growing orgs within large companies), the structuring one can be most problematic: "Our old structures, though comfortable, won't scale well with all these new teams and all the new hires joining our existing teams. How do we reorganize? Where do we put folks? Are there natural lines along which we can provide better management (and vision!) structure?"

The answer, of course, is "yes" -- but! It requires careful analysis and a deep understanding every team in your org.

The remainder of this post will set up a scenario and then figure out how to do a re-org. I use a software engineering org as an example, but that's just because I have a long and intimate knowledge of them and understand the ways in which one can classify such teams. These same methods could be applied a Sales group, Marketing groups, etc., as long as you know the characteristics that define the teams of which these orgs are comprised.

Introducing ACMEACME Corporation is the leading producer of some of the most innovative products of the 20th century. The CTO had previously tasked you, the VP of Software Development to bring this product line into the digital age -- and you did! Your great ideas for the updated suite are the new hottness that everyone is clamouring for. Subsequently, the growth of your teams has been fast, and dare we say, exponential.

More details on the scenario: your Software Development Group has several teams of engineers, all working on different products or services, each of which supports ACME Corporation in different ways. In the past 2 years, you've built up your org by an order of magnitude in size. You've started promoting and hiring more managers and directors to help organize these teams into sensible encapsulating structures. These larger groups, once identified, would comprise the whole Development Group.

Ideally, the new groups would represent some aspect of the company, software development, engineering, and product vision -- in other words, some sensible clustering of teams doing related work. How would you group the teams in the most natural way?

Simply dividing along language or platform lines may seem like the obvious answer, but is it the best choice? There are some questions that can help guide you in figuring this out:
  • How do these teams interact with other parts of the company? 
  • Who are the stakeholders in feature development? 
  • Which sorts of customers does each team primarily serve?
There are many more questions you could ask (some are implicit in the analysis data linked below), but this should give a taste.

ACME Software Development has grown the following teams, some of which focus on products, some on infrastructure, some on services, etc.:
  • Digital Anvil Product Team
  • Giant Rubber Band App Team
  • Digital Iron Carrot Team
  • Jet Propelled Unicycle Service Team
  • Jet Propelled Pogo Stick Service Team
  • Ultimatum Dispatcher API Team
  • Virtual Rocket Powered Roller Skates Team
  • Operations (release management, deployments, production maintenance)
  • QA (testing infrastructure, CI/CD)
  • Community Team (documentation, examples, community engagement, meetups, etc.)

Early SW Dev team hacking the ENIACCategorizing TeamsEach of those teams started with 2-4 devs hacking on small skunkworks projects. They've now blossomed to the extent that each team has significant sub-teams working on new features and prototyping for the product they support. These large teams now need to be characterized using a method that will allow them to be easily compared. We need the ability to see how closely related one team is to another, across many different variables. (In the scheme outlined below, we end up examining 50 bits of information for each team.)

Keep in mind that each category should be chosen such that it would make sense for teams categorized similarly to be grouped together. A counter example might be "Team Size"; you don't necessarily want all large teams together in one group, and all small teams in a different group. As such, "Team Size" is probably a poor category choice.
Here are the categories which we will use for the ACME Software Development Group:
  • Language
  • Syntax
  • Platform
  • Implementation Focus
  • Supported OS
  • Deployment Type
  • Product?
  • Service?
  • License Type
  • Industry Segment
  • Stakeholders
  • Customer Type
  • Corporate Priority
Each category may be either single-valued or multi-valued. For instance, the categories ending in question marks will be booleans. In contrast, multiple languages might be used by the same team, so the "Language" category will sometimes have several entries.

Category Example(Things are going to get a bit more technical at this point; for those who care more about the outcomes than the methods used, feel free to skip to the section at the end: Sorting and Interpretation.)

In all cases, we will encode these values as binary digits -- this allows us to very easily compare teams using Levenshtein distance, since the total of all characteristics we are filtering on can be represented as a string value. An example should illustrate this well.

(The Levenshtein distance between two words is the minimum number of single-character edits -- such as insertions, deletions or substitutions -- required to change one word into the other. It is named after Vladimir Levenshtein, who defined this "distance" in 1965 when exploring the possibility of correcting deletions, insertions, and reversals in binary codes.)
Let's say the Software Development Group supports the following languages, with each one assigned a binary value:
  • LFE - #b0000000001
  • Erlang - #b0000000010
  • Elixir - #b0000000100
  • Ruby - #b0000001000
  • Python - #b0000010000
  • Hy - #b0000100000
  • Clojure - #b0001000000
  • Java - #b0010000000
  • JavaScript - #b0100000000
  • CoffeeScript - #b1000000000
A team that used LFE, Hy, and Clojure would obtain its "Language" category value by XOR'ing the three supported languages, and would thus be #b0001100001. In LFE, that could be done by entering the following code the REPL:

We could then compare this to a team that used just Hy and Clojure (#b0001100001), which has a Levenshtein distance of 1 with the previous language category value. A team that used Ruby and Elixir (#b0000001100) would have a Levenshtein distance of 5 with the LFE/Hy/Clojure team (which makes sense: a total of 5 languages between the two teams with no languages shared in common). 

Calculating the Levenshtein Distance of TeamsAs a VP who is keen on deeply understanding your teams, you have put together a spreadsheet with a break-down of not only languages used in each team, but lots of other categories, too. For easy reference, you've put a "legend" for the individual category binary values is at the bottom of the linked spreadsheet.

In the third table on that sheet, all of the values for each column are combined into a single binary string. This (or a slight modification of this) is what will be the input to your calculations. Needless to say, as a complete fan of LFE, you will be writing some Lisp code :-)

Partial view of the spreadsheet's first page.(If you would like to try the code out yourself while reading, and you have lfetool installed, simply create a new project and start up the REPL: $ lfetool new library ld; cd ld && make-shellThat will download and compile the dependencies for you. In particular, you will then have access to the lfe-utils project -- which contains the Levenshtein distance functions we'll be using. You should be able to copy-and-paste functions, vars, etc., into the REPL from the Github gists.)
Let's create a couple of data structures that will allow us to more easily work with the data you collected about your teams in the spreadsheet:

We can use a quick copy and paste into the LFE REPL for two of those numbers to do a sanity check on the distance between the Community Team and the Digital Iron Carrot Team:

That result doesn't seem unreasonable, given that at a quick glance we can see both of these strings have many differences in their respective character positions.

It looks like we're on solid ground, then, so let's define some utility functions to more easily work with our data structures:

Now we're ready to roll; let's try sorting the data based on a comparison with a one of the teams:

It may not be obvious at first glance, but what the levenshtein-sort function did for us is compare our "control" string to every other string in our data set, providing both the distance and the string that the control was compared to. The first entry in the results is the our control string, and we see what we would expect: the Levenshtein distance with itself is 0 :-)

The result above is not very easily read by most humans ... so let's define a custom sorter that will take human-readable text and then output the same, after doing a sort on the binary strings:

(If any of that doesn't make sense, please stop in and say "hello" on the LFE mail list -- ask us your questions! We're a friendly group that loves to chat about LFE and how to translate from Erlang, Common Lisp, or Clojure to LFE :-) )

Sorting and InterpretationBefore we try out our new function, we should ponder which team will be compared to all the others -- the sort results will change based on this choice. Looking at the spreadsheet, we see that the "Digital Iron Carrot Team" (DICT) has some interesting properties that make it a compelling choice:
  • it has stakeholders in Sales, Engineering, and Senior Leadership;
  • it has a "Corporate Priority" of "Business critical"; and
  • it has both internal and external customers.
Of all the products and services, it seems to be the biggest star. Let's try a sort now, using our new custom function -- inputting something that's human-readable: 

Here we're making the request "Show me the sorted results of each team's binary string compared to the binary string of the DICT." Here are the human-readable results:

For a better visual on this, take a look at the second tab of the shared spreadsheet. The results have been applied to the collected data there, and then colored by major groupings. The first group shares these things in common:
  • Lisp- and Python-heavy
  • Middleware running on BSD boxen
  • Mostly proprietary
  • Externally facing
  • Focus on apps and APIs
It would make sense to group these three together.

A sort (and thus grouping) by comparison to critical team.Next on the list is Operations and QA -- often a natural pairing, and this process bears out such conventional wisdom. These two are good candidates for a second group.
Things get a little trickier at the end of the list. Depending upon the number of developers in the Java-heavy Giant Rubber Band App Team, they might make up their own group. However, both that one and the next team on the list have frontend components written in Angular.js. They both are used internally and have Engineering as a stakeholder in common, so let's go ahead and group them.
The next two are cloud-deployed Finance APIs running on the Erlang VM. These make a very natural pairing.
Which leaves us with the oddball: the Community Team. The Levenshtein distance for this team is the greatest for all the teams ... but don't be mislead. Because it has something in common with all teams (the Community Team supports every product with docs, example code, Sales and TAM support, evangelism for open source projects, etc.), it will have many differing bits with each team. This really should be in a group all its own so that structure represents reality: all teams depend upon the Community Team. A good case could also probably be made for having the manager of this team report directly up to you. 
The other groups should probably have directors that the team managers report to (keeping in mind that the teams have grown to anywhere from 20 to 40 per team). The director will be able to guide these teams according to your vision for the Software Group and the shared traits/common vision you have uncovered in the course of this analysis.
Let's go back to the Community Team. Perhaps in working with them, you have uncovered a hidden fact: the community interactions your devs have are seriously driving market adoption through some impressive and passionate service and open source docs+evangelism. You are curious how your teams might be grouped if sorted from the perspective of the Community Team.
Let's find out!

As one might expect, most of the teams remain grouped in the same way ... the notable exception being the split-up of the Anvil and Rubber Band teams. Mostly no surprises, though -- the same groupings persist in this model.

A sort (and thus grouping) by comparison to highly-connected team.To be fair, if this is something you'd want to fully explore, you should bump the "Corporate Priority" for the Community Team much higher, recalculate it's overall bits, regenerate your data structures, and then resort. It may not change too much in this case, but you'd be applying consistent methods, and that's definitely the right thing to do :-) You might even see the Anvil and Rubber Band teams get back together (left as an exercise for the reader).

As a last example, let's throw caution and good sense to the wind and get crazy. You know, like the many times you've seen bizarre, anti-intuitive re-orgs done: let's do a sort that compares a team of middling importance and a relatively low corporate impact with the rest of the teams. What do we see then?

This ruins everything. Well, almost everything: the only group that doesn't get split up is the middleware product line (Jet Propelled and Iron Carrot). Everything else suffers from a bad re-org.

A sort (and thus grouping) by comparison to a non-critical team.
If you were to do this because a genuine change in priority had occurred, where the Giant Rubber Band App Team was now the corporate leader/darling, then you'd need to recompute the bit values and do re-sorts. Failing that, you'd just be falling into a trap that has beguiled many before you.

ConclusionIf there's one thing that this exercise should show you, it's this: applying tools and analyses from one field to fresh data in another -- completely unrelated -- field can provide pretty amazing results that turn mystery and guesswork into science and planning.

If we can get two things from this, the other might be: knowing the parts of the system may not necessarily reveal the whole (c.f. Complex Systems), but it may provide you with the data that lets you better predict emergent behaviours and identify patterns and structure where you didn't see them (or even think to look!) before.

Paul Tagliamonte: Apple Hardware: Part II

Planet Ubuntu - Fri, 07/04/2014 - 11:05

A few interesting things happened after I got a macbook air.

Firstly, I got a lot of shit from my peers and friends about it. This was funny to me, nothing really bothered me about it, but I can see this becoming really tiresome at events like hackathons or conferences.

As a byproduct, there’s a strong feeling in the hardcore F/OSS world that Apple hardware is the incarnation of evil.

As a result of both of the above, hardcore F/OSS (and Distro hackers) don’t buy apple hardware.

Therefore, GNU/Linux is complete garbage on Apple hardware. Apple’s firmware bugs don’t help, but we’re BAD.

Some might ask why this is a big deal. The fact is, this is one of the most used platforms for Open Source development (note I used that term exactly).

Are we to damn these users to a nonfree OS because we want to maintain our purity?

I had to give back my Air, but I still have a Mac Mini that i’ve been using for testing bugs on OSX in code I have. Very soon, my Mac Mini will be used to help fix the common bugs in the install process.

Some things you can do:

  • Consider not giving off an attitude to people with Apple hardware. Be welcoming.
  • Consider helping with supporting your favorate distro on Apple hardware. Props to Fedora for doing such a great job, in particular, mjg59 and Peter Jones for all they do with it.
  • Help me make Debian Apple installs one-click.


Subscribe to Ubuntu Arizona LoCo Team aggregator