Bazaar

In our small company of 9 people, 3 of us are spending most of our time writing code and kicking servers. We are distributed across 5 different states, most of us work from home or from coworking spaces, so it can be a challenge to stay in sync with ... [More] what is happening. When I arrived, one of the first things I set up was HipChat so that we would have a company chatroom, and an engineering channel where we would wire in as much broadcast status or information radiator stuff as we could think of. See also: ChatOps We have GitHub pushes and merge proposals announced in the chatroom, Sprint.ly tickets announced, HelpScout support requests, PagerDuty alerts, and capistrano deploy notifications. Without any extra work for the 3 engineers, anyone in the company can get a fantastic pulse of what is being worked on, what needs attention, etc. The one thing that was totally silent was when someone needed to SSH into a server to do some ops work. Backups stopped working, someone logged in, we didn't get a notification. We did have logs that were reviewed on a monthly basis, but it just wasn't contributing to the real time pulse I otherwise enjoyed being a part of. Here is how I fixed it. Here is a script that is executed by the Linux Pluggable Authentication Module system when someone connects to a server via SSH. I call it login-audit.sh, and I drop it in /usr/local/bin. #!/usr/bin/sh API_KEY=YOUR_HIPCHAT_KEY ROOM=YOUR_ROOM SENDER=LoginAudit if [ "$PAM_TYPE" != "close_session" ]; then curl -d "room_id=$ROOM&from=$SENDER&message=$PAM_USER logged in to `hostname`&color=green" https://api.hipchat.com/v1/rooms/message?auth_token=$API_KEY&format=json fi Then, on each of our servers, I added this line to /etc/pam.d/sshd: session required pam_exec.so seteuid /usr/local/bin/login-audit.sh Presto! Now when someone goes into a server, the rest of the team knows. Of course this wouldn't stop any bad behavior, but it's a great way of keeping folks on the same side in more in sync with each other. Knowing that Joe has been in and out of a server all morning, or that nobody on the team has touched a server in weeks helps a lot with situational awareness when we need to respond to an alert. [Less]

Kudos to all the speakers, panellists, designers and engineers who made ODS Atlanta such a great event last week. And thanks in particular to the team at Canonical that helped pull together our keynote, I had a very large number of compliments that ... [More] really belong to all of you! For those that didn’t make it, here are a few highlights. First, Ubuntu is the leading OpenStack distribution, with 55% of all production are using Ubuntu, nearly 5x the number for RHEL. There is a big squabble at the moment between vendors in the RHEL camp; for the record, Canonical is happy to work with vendors of alternative OpenStack distributions on Ubuntu as long as we have a commercial agreement that enables us to support users. Nonetheless, the standard way to do OpenStack starts with Ubuntu followed by the addition of Canonical’s cloud archive, installing OpenStack using those packages. Second, vendors are focused on interoperability through Canonical’s OpenStack Interop Lab (OIL). We build OpenStack thousands of ways every month with permutations and combinations of code from many vendors. Bring us a Juju charm of your work, sign up to the OIL program and we’ll tell you which other vendors you need to do more work with if you want to be interoperable with their OpenStack offerings. Third, Juju and MAAS are growing support for Windows and CentOS, with other operating systems on the horizon too (patches welcome!). Thanks to contributions from CloudBase Solutions, you’ll get amazing orchestration of Windows and Linux apps on any cloud or bare metal. If you have a Windows app that you want charmed up, they are the guys to talk to! We did a live on-stage install of OpenStack with Ubuntu KVM and Windows Hyper-V with the beta code, and expect it to land in production Juju / MAAS in the coming weeks.   I’m particularly excited about a new product we’ve announced, which is a flat-fee fully managed on-premise OpenStack solution. Using our architecture and tools, and your hardware, we can give you a best-of-breed OpenStack deployment with SLA for a fixed fee of $15 per server per day. Pretty amazing, and if you are considering OpenStack, definitely an option to evaluate.  Give us a call! [Less]

KDE Project: D-BusToday I released the Plasma Next Beta. It's the first major user of KDE Frameworks 5 and tidies up the internal and the externals of the Plasma desktop. At the Kubuntu meeting yesterday we decided not to ship Plasma Next by default ... [More] in October but to make a secondary ISO for those who want to test it out while putting the Plasma 1 version into maintenance mode - updating the version and fixing the major bugs and not much more. It's going to be an exciting release. But not so exciting it'll implode :) To get a sneak preview grab the Neon5 ISO which Rohan updated yesterday especially for this beta. [Less]

KDE Project: DCOPA new cycle and lots of interesting possibilities! Will KF5 and Plasma 5 be supreme? All welcome at the Kubuntu kickoff meeting this european evening and american afternoon at 19:00UTC. Install mumble, get a headset with headphones ... [More] and microphone, adjust volumes to be sane and join us on mumble server kyofel.dyndns.org Chat in #kde-devel Add items to discuss at the meeting notes and review the TODO items on Trello. See you there! [Less]

Just saw http://sny.no/2014/04/dbts and I feel compelled to note that distributed bug trackers are not new – the earliest I personally encountered was Aaron Bentley’s Bugs everywhere – coming up on it’s 10th birthday. BE meets many of the criteria in ... [More] the dbts post I read earlier today, but it hasn’t taken over the world – and I think this is in large part due to the propogation nature of bugs being very different to code – different solutions are needed. XXXX: With distributed code versioning we often see people going to some effort to avoid conflicts – semantic conflicts are common, and representation conflicts extremely common.The idions Take for example https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/805661. Here we can look at the nature of the content: Concurrent cannot-conflict content – e.g. the discussion about the bug. In general everyone should have this in their local bug database as soon as possible, and anyone can write to it. Observations of fact – e.g. ‘the code change that should fix the bug has landed in Ubuntu’ or ‘Commit C should fix the bug’. Reports of symptoms – e.g. ‘Foo does not work for me in Ubuntu with package versions X, Y and Z’. Collaboratively edited metadata – tags, title, description, and arguably even the fields like package, open/closed, importance. Note that only one of these things – the commit to fix the bug – happens in the same code tree as the code; and that the commit fixing it may be delayed by many things before the fix is available to users. Also note that conceptually conflicts can happen in any of those fields except 1). Anyhow – my humble suggestion for tackling the conflicts angle is to treat all changes to a bug as events in a timeline – e.g. adding a tag ‘foo’ is an event to add ‘foo’, rather than an event setting the tags list to ‘bar,foo’ – then multiple editors adding ‘foo’ do not conflict (or need special handling). Collaboratively edited fields would be likely be unsatisfying with this approach though – last-writer-wins isn’t a great story. OTOH the number of people that edit the collaborative fields on any given bug tend to be quite low – so one could defer that to manual fixups. Further, as a developer wanting local access to my bug database, syncing all of these things is appealing – but if I’m dealing with a million-bug bug database, I may actually need the ability to filter what I sync or do not sync with some care. Even if I want everything, query performance on such a database is crucial for usability (something git demonstrated convincingly in the VCS space). Lastly, I don’t think distributed bug tracking is needed – it doesn’t solve a deeply burning use case – offline access would be a 90% solution for most people. What does need rethinking is the hugely manual process most bug systems use today. Making tools like whoopsie-daisy widely available is much more interesting (and that may require distributed underpinnings to work well and securely). Automatic collation of distinct reports and surfacing the most commonly experienced faults to developers offers a path to evidence based assessment of quality – something I think we badly need. [Less]

This upstirring undertaking Ubuntu is, as my colleague MPT explains, performance art. Not only must it be art, it must also perform, and that on a deadline. So many thanks and much credit to the teams and individuals who made our most recent release ... [More] , the Trusty Tahr, into the gem of 14.04 LTS. And after the uproarious ululation and post-release respite, it’s time to open the floodgates to umpteen pent-up changes and begin shaping our next show. The discipline of an LTS constrains our creativity – our users appreciate the results of a focused effort on performance and stability and maintainability, and we appreciate the spring cleaning that comes with a focus on technical debt. But the point of spring cleaning is to make room for fresh ideas and new art, and our next release has to raise the roof in that regard. And what a spectacular time to be unleashing creativity in Ubuntu. We have the foundations of convergence so beautifully demonstrated by our core apps teams – with examples that shine on phone and tablet and PC. And we have equally interesting innovation landed in the foundational LXC 1.0, the fastest, lightest virtual machines on the planet, born and raised on Ubuntu. With an LTS hot off the press, now is the time to refresh the foundations of the next generation of Linux: faster, smaller, better scaled and better maintained. We’re in a unique position to bring useful change to the ubiquitary Ubuntu developer, that hardy and precise pioneer of frontiers new and potent. That future Ubuntu developer wants to deliver app updates instantly to users everywhere; we can make that possible. They want to deploy distributed brilliance instantly on all the clouds and all the hardware. We’ll make that possible. They want PAAS and SAAS and an Internet of Things that Don’t Bite, let’s make that possible. If free software is to fulfil it’s true promise it needs to be useful for people putting precious parts into production, and we’ll stand by our commitment that Ubuntu be the most useful platform for free software developers who carry the responsibilities of Dev and Ops. It’s a good time to shine a light on umbrageous if understandably imminent undulations in the landscape we love – time to bring systemd to the centre of Ubuntu, time to untwist ourselves from Python 2.x and time to walk a little uphill and, thereby, upstream. Time to purge the ugsome and prune the unusable. We’ve all got our ucky code, and now’s a good time to stand united in favour of the useful over the uncolike and the utile over the uncous. It’s not a time to become unhinged or ultrafidian, just a time for careful review and consideration of business as usual. So bring your upstanding best to the table – or the forum – or the mailing list – and let’s make something amazing. Something unified and upright, something about which we can be universally proud. And since we’re getting that once-every-two-years chance to make fresh starts and dream unconstrained dreams about what the future should look like, we may as well go all out and give it a dreamlike name. Let’s get going on the utopic unicorn. Give it stick. See you at vUDS. [Less]

KDE Project: DCOPThere's only 1 tool to deal with an unsupported Windows XP...

KDE Project: DCOP Trust in Me You've been waiting for it, we've been working hard on it.. it's the new Long Term Support release of Kubuntu! This means we've been working hard on removing bugs, polishing features and not adding new ones. This will ... [More] probably be the last release before KDE Frameworks 5 and Plasma Next gets introduced so for those who like to live life on the cautious side you'll be pleased to know the Long Term Support label means we'll have important bug fixes and security fixes for the next 5 years. It'll also get backports of important KDE software for the next couple of years. But that doesn't mean there's nothing new. Take a look at the release announcement for a long list. For one thing we're the first distro to ship with KDE SC 4.13 fresh out today. It brings a much nicer desktop search capability that makes search fly. Muon is slicker, all new Driver Manager means hardware works better, Gwenview plugins mean it's easier to upload to Facebook, KDE Connect makes your phone talk to your laptop. All wrapped up with the safety of commercial support if you need it and plenty of community support if you need that. I'd like to thank Harald who put in a lot of effort in this release, even writing up release notes which I've never found anyone to help with before. Rohan did crutial last minute bugfixes including at the last minute and nifty new features like the Driver Manager. Aurelien took care of Ubiquity to get your installs looking nice. We've all new documentation thanks to Aaron and Valerie and others. Scott kept the policy ticking over. Phillip got things packaged, debfx had bug fixes when it was needed most, Michal keeping an eye on the important packages, Scarlett being the Queen of packaging for KF5 and others. Really what a wonderful team effort. And next? We'll be looking at making KDE Frameworks usable, Plasma 2014.6 may be the next desktop and who knows we may even get something working with Wayland. it's exiting! Come and join us, chat in #kubuntu-devel and join the kubuntu-devel mailing list. [Less]

KDE Project: DCOPCandidate images for Kubuntu 14.04LTS are up and need you to test them. Go to the ISO tracking site to download and mark your testing status. Check out the milestoned bugs for issues we are aware of and do report any we are not.

I'm not angry any more. It's because this week I started being less available to people. Counterintuitive, because I like people. Well, I don't like many people but I like the idea of people. I'm happily, peacefully, unavailable for interruption. I ... [More] don't have a quick minute. It's such a relief. Today I sat down and started working on the things I decided to work on. It's about being more present in the now. Paying more attention to the task at hand. Listening to the people here with me, and thinking about them. Not being ripped away from the obligations I have so painstakingly made and scheduled. It was surprisingly hard to give myself permission to be less interruptible. Hard because I have and embrace certain responsibilities where I want to be interruptible. But it's gone too far. Continous availability for interruption any time any one of my friends, colleagues, aquaintances, family members, has any fleeting thought they want to share, any question they want to ask has eroded all of my relationships rather than enhanced them. The damage was subtle, building slowly. Eventually I realized the problem was me, not them. I felt irritated at the friendly hello, the non-urgent question that could have and should have waited for the next in-person meeting, because I had mindlessly accepted the defaults in the technology I used. The problem was how I consumed these communications - as an interrupt that had to be read (if not processed) immediately. The last time a family member was on his deathbed, I wasn't able to answer the phone because I was at an event and didn't get the message for an hour or two. I have never felt regret or wished I had gotten the message sooner. However, my attention and participation at countless other events has been destroyed by interruption with friendly, well-meaning, absolutely trivial messages. The solution is simpler and easier than I ever thought possible. Text messages are now relegated to the same hated status as email. No badges telling me about unread counts. No alert when a new message arrives. No indication of any sort that a message is waiting. I'll read my messages when I remember to go look and see if there are any waiting. It's worth mentioning that I've tried a less severe policy that was a total failure. My previous attempt was to not respond to personal messages while at work. It didn't work because I still knew the messages were there, which yanked my attention over to them and caused an expensive context switch despite my intention to postpone reacting until a more appropriate time. I am partially reachable for emergencies. Call my phone. It's probably in my bag or in my car or on my desk in the other room at home, and I won't answer if I'm in a meeting at work (%50 of the day), spending time with my family (%50 of the evening), riding my bike, eating a meal. If it's truly an emergency, I'll hear about it. The fastest way to get in touch with me just might be to write me a letter. Or make an appointment for coffee. I promise I won't be distracted by text messages while we are talking. [Less]