With electricity prices in Australia seeming to be only going up, and solar being surprisingly cheap, I decided it was a no-brainer to invest in a solar installation to reduce my ongoing electricity bills. It also paves the way for getting an electric car in the future. I'm also a greenie, so having some renewable energy happening gives me the warm and fuzzies.
So today I got solar installed. I've gone for a 2 kWh system, consisting of 8 250 watt Seraphim panels (I'm not entirely sure which model) and an Aurora UNO-2.0-I-OUTD inverter.
It was totally a case of decision fatigue when it came to shopping around. Everyone claims the particular panels they want to sell at the best. It's pretty much impossible to make a decent assessment of their claims. In the end, I went with the Seraphim panels because they scored well on the PHOTON tests. That said, I've had other solar companies tell me the PHOTON tests aren't indicative of Australian conditions. It's hard to know who to believe. In the end, I chose Seraphim because of the PHOTON test results, and they're also apparently one of the few panels that pass the Thresher test, which tests for durability.
The harder choice was the inverter. I'm told that yield varies wildly by inverter, and narrowed it down to Aurora or SunnyBoy. Jason's got a SunnyBoy, and the appeal with it was that it supported Bluetooth for data gathering, although I don't much care for the aesthetics of it. Then I learned that there was a WiFi card coming out soon for the Aurora inverter, and that struck me as better than Bluetooth, so I went with the Aurora inverter. I discovered at the eleventh hour that the model of Aurora inverter that was going to be supplied wasn't supported by the WiFi card, but was able to switch models to the one that was. I'm glad I did, because the newer model looks really nice on the wall.
The whole system was up at running just in time to catch the setting sun, so I'm looking forward to seeing it in action tomorrow.
Apparently the next step is Energex has to come out to replace my analog power meter with a digital one.
I'm grateful that I was able to get Body Corporate approval to use some of the roof. Being on the top floor helped make the installation more feasible too, I think.
The problem: Some time ago, I had a server “in the wild” from which I
wanted some data backed up to my rsync.net account. I didn’t want to
put sensitive credentials on this server in case it got compromised.
The awesome admins at rsync.net pointed out their subuid feature. For
no extra charge, they’ll give you another uid, which can have its own
ssh keys, whose home directory is symbolically linked under your main
uid’s home directory. So the server can rsync backups to the subuid,
and if it is compromised, attackers cannot get at any info which didn’t
originate from that server anyway.
Those of you who follow this blog since some time know for sure that the preferred language is English (a little number of posts in the early stages are an exception). Things are changing though.
It’s not that difficult to understand: if you go on it.deshack.net you can see this website in Italian. I’ve been thinking about giving a big change to this little place in the web for a while, as I want it to become more than a simple blog. I am working on a new theme for business websites, but I’ll let you know when it’s time. In the mean time, don’t be amazed if you see some small changes here.Note
Now it’s time for me to ask something to you: do you think this is an interesting change? Let me know with a comment!
Release Metrics and Incoming Bugs
Release metrics and incoming bug data can be reviewed at the following link:
Status: Utopic Development Kernel
The Utopic kernel has been rebased to v3.16-rc6 and officially uploaded
to the archive. We (as in apw) has also completed a hurculean config
review for Utopic and administered the appropriate changes. Please test
and let us know your results.
Important upcoming dates:
Thurs Jul 24 – 14.04.1 (~2 days away)
Thurs Aug 07 – 12.04.5 (~2 weeks away)
Thurs Aug 21 – Utopic Feature Freeze (~4 weeks away)
The current CVE status can be reviewed at the following link:
Status: Stable, Security, and Bugfix Kernel Updates – Trusty/Saucy/Precise/Lucid
Status for the main kernels, until today (Jul. 22):
- Lucid – Released
- Precise – Released
- Saucy – Released
Trusty – Released
Current opened tracking bugs details:
For SRUs, SRU report is a good source of information:
14.04.1 cycle: 29-Jun through 07-Aug
27-Jun Last day for kernel commits for this cycle
29-Jun – 05-Jul Kernel prep week.
06-Jul – 12-Jul Bug verification & Regression testing.
13-Jul – 19-Jul Regression testing & Release to -updates.
20-Jul – 24-Jul Release prep
24-Jul 14.04.1 Release 
07-Aug 12.04.5 Release 
cycle: 08-Aug through 29-Aug
08-Aug Last day for kernel commits for this cycle
10-Aug – 16-Aug Kernel prep week.
17-Aug – 23-Aug Bug verification & Regression testing.
24-Aug – 29-Aug Regression testing & Release to -updates.
 This will be the very last kernels for lts-backport-quantal, lts-backport-raring,
 This will be the lts-backport-trusty kernel as the default in the precise point
Open Discussion or Questions? Raise your hand to be recognized
No open discussions.
So, given Jono’s departure a few weeks back, I bet a lot of folks have been wondering about the Canonical Community Team. For a little background, the community team reports into the Ubuntu Engineering division of Canonical, which means that they all report into me. We have not been idle, and this post is to discuss a bit about the Community Team going forward.What has Stayed the Same?First, we have made some changes to the structure of the community team itself. However, one thing did not change. I kept the community team reporting directly into me, VP of Engineering, Ubuntu. I decided to do this so that there is a direct line to me for any community concerns that have been raised to anyone on the community team.
I had a call with the Community Council a couple of weeks ago to discuss the community team and get feedback about how it is functioning and how things could be improved going forward. I laid out the following for the team.
First, there were three key things that I think that I wanted the Community Team to continue to focus on:
- Continue to create and run innovative programs to facilitate ever more community contributions and growing the community.
- Continue to provide good advice to me and the rest of Canonical regarding how to be the best community members we can be, given our privileged positions of being paid to work within that community.
- Continue to assist with outward communication from Canonical to the community regarding plans, project status, and changes to those.
Secondly, while individuals on the team had been hired to have specific roles in the community, every one of them had branched out to tackle new challenges as needed.
Thirdly, there is no longer just one “Community Spokesperson”. Everyone in Ubuntu Engineering can and should speak to/for Canonical and to/for the Ubuntu Community in the right contexts.So, we made some small, but I think important changes to the Community Team.
First, we created the role Community Team Manager. Notice the important inclusion of the word “Team”. This person’s job is not to “manage the community”, but rather to organize and lead the rest of the community team members. This includes things like project planning, HR responsibilities, strategic planning and everything else entailed in being a good line manager. After a rather competitive interview process, with some strong candidates, one person clearly rose to the top as the best candidate. So, I would like formally introduce David Planella (lp, g+) as the Community Team Manager!
Second, I change the other job titles from their rather specific titles to just “Community Manager” in order to reflect the reality that everyone on the community team is responsible for the whole community. So that means, Michael Hall (lp, g+), Daniel Holbach (lp, g+), and Nicholas Skaggs (lp, g+), are all now “Community Manager”. What's Next?This is a very strong team, and a really good group of people. I know them each personally, and have a lot of confidence in each of them personally. Combined as a team, they are amazing. I am excited to see what comes next.
In light of these changes, the most common question I get is, “Who do I talk to if I have a question or concern?” The answer to that is “anyone.” It’s understandable if you feel the most comfortable talking to someone on the community team, so please feel free to find David, Michael, Daniel, or Nicholas online and ask their question. There are, of course, other stalwarts like Alan Pope (lp, g+) and Oliver Grawert (lp, g+) who seem to be always online :) By which, I mean to say that while the Community Managers are here to serve the Ubuntu Community, I hope that anyone in Ubuntu Engineering considers their role in the Ubuntu Community to include working with anyone else in the Ubuntu Community :)
Want talk directly to the community team today? Easy, join their Ubuntu on Air Q&A Session at 15 UTC :)
Finally, please note that I love to be "interrupted" by questions from community members :) The best way to get in touch with me is on freenode, where I go by rickspencer3. Otherwise, I am also on g+, and of course there is this blog :)
Yesterday’s autopkgtest 3.2 release brings several changes and improvements that developers should be aware of.Cleanup of CLI options, and config files
Previous adt-run versions had rather complex, confusing, and rarely (if ever?) used options for filtering binaries and building sources without testing them. All of those (--instantiate, --sources-tests, --sources-no-tests, --built-binaries-filter, --binaries-forbuilds, and --binaries-fortests) now went away. Now there is only -B/--no-built-binaries left, which disables building/using binaries for the subsequent unbuilt tree or dsc arguments (by default they get built and their binaries used for tests), and I added its opposite --built-binaries for completeness (although you most probably never need this).
The --help output now is a lot easier to read, both due to above cleanup, and also because it now shows several paragraphs for each group of related options, and sorts them in descending importance. The manpage got updated accordingly.
Another new feature is that you can now put arbitrary parts of the command line into a file (thanks to porting to Python’s argparse), with one option/argument per line. So you could e. g. create config files for options and runners which you use often:$ cat adt_sid --output-dir=/tmp/out -s --- schroot sid $ adt-run libpng @adt_sid Shell command tests
If your test only contains a shell command or two, or you want to re-use an existing upstream test executable and just need to wrap it with some command like dbus-launch or env, you can use the new Test-Command: field instead of Tests: to specify the shell command directly:Test-Command: xvfb-run -a src/tests/run Depends: @, xvfb, [...]
This avoids having to write lots of tiny wrappers in debian/tests/. This was already possible for click manifests, this release now also brings this for deb packages.Click improvements
It is now very easy to define an autopilot test with extra package dependencies or restrictions, without having to specify the full command, using the new autopilot_module test definition. See /usr/share/doc/autopkgtest/README.click-tests.html for details.
If your test fails and you just want to run your test with additional dependencies or changed restrictions, you can now avoid having to rebuild the .click by pointing --override-control (which previously only worked for deb packages) to the locally modified manifest. You can also (ab)use this to e. g. add the autopilot -v option to autopilot_module.
Unpacking of test dependencies was made more efficient by not downloading Python 2 module packages (which cannot be handled in “unpack into temp dir” mode anyway).
Finally, I made the adb setup script more robust and also faster.
As usual, every change in control formats, CLI etc. have been documented in the manpages and the various READMEs. Enjoy!
I picked up Zoe from Sarah this morning and dropped her at Kindergarten. Traffic seemed particularly bad this morning, or I'm just out of practice.
I spent the day powering through the last two parts of the registration block of my real estate licence training. I've got one more piece of assessment to do, and then it should be done. The rest is all dead-tree written stuff that I have to mail off to get marked.
Zoe's doing tennis this term as her extra-curricular activity, and it's on a Tuesday afternoon after Kindergarten at the tennis court next door.
I'm not sure what proportion of the class is continuing on from previous terms, and so how far behind the eight ball Zoe will be, but she seemed to do okay today, and she seemed to enjoy it. Megan's in the class too, and that didn't seem to result in too much cross-distraction.
After that, we came home and just pottered around for a bit and then Zoe watched some TV until Sarah came to pick her up.
Welcome to the Ubuntu Weekly Newsletter. This is issue #375 for the weeks July 7 – 20, 2014, and the full version is available here.
In this issue we cover:
- 12.04.x HWE Stack EOL Notification
- Ubuntu 13.10 (Saucy Salamander) End of Life reached on July 17 2014
- Ubuntu Stats
- Ubucon LatinAmerica Speakers! #1
- Juju 1.20 is out the door!
- Brightbox now offering official Ubuntu images
- Jonathan Riddell: Frameworks 5 and Plasma 5 announcements
- The Fridge: New Ubuntu Membership Board Members
- The Fridge: [Proposed] Ubuntu Online Summit dates: 4-6 Nov 2014
- Lubuntu Blog: PCManFM 1.2.1
- Ubuntu App Developer Blog: Content Hub to replace Friends API
- Lubuntu Blog: Box support for MATE
- Nicholas Skaggs: A new test runner approaches
- Upstart 1.13 released
- Unity8 & Mir update July 8 & 15, 2014
- Canonical News
- This Feisty Linux Company Has An Interesting Plan To Topple Android
- In The Blogosphere
- Featured Audio and Video
- Weekly Ubuntu Development Team Meetings
- Upcoming Meetings and Events
- Updates and Security for 10.04, 12.04, 13.10 and 14.04
- And much more!
The issue of The Ubuntu Weekly Newsletter is brought to you by:
- Elizabeth K. Joseph
- Jose Antonio Rey
- And many others
Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License
I have a couple of virt-manager virtual machines for doing DHCP-related work. I have one for the DHCP server and one for the DHCP client, and I have a private network between the two so I can simulate DHCP requests without messing up anything else. It works nicely.
I got a bit carried away, and I use LVM to snapshots for the work I do, so that when I'm done I can throw away the virtual machine's disks and work with a new snapshot next time I want to do something.
I have a cron job, that on a good day, fires up the virtual machines using the master logical volumes and does a dist-upgrade on a weekly basis. It seems to have varying degrees of success though.
So I fired up my VMs to do some investigation of the problem for #749410 and discovered that they weren't booting, because the initramfs couldn't find the root filesystem.
Upon investigation, the problem seemed to be that the logical volumes weren't getting activated. I didn't get to the bottom of why, but a manual activation of the logical volumes allowed the instances to continue booting successfully, and after doing manual dist-upgrades and kernel upgrades, they booted cleanly again. I'm not sure if I got hit by a passing bug in unstable, or what the problem was. I did burn about 2.5 hours just fixing everything up though.
Then I realised that there'd been more activity on the bug since I'd last read it while I was on vacation, and half the investigation I needed to do wasn't necessary any more. Lesson learned.
I haven't got to the bottom of the bug yet, but I had a fun day anyway.
When life gives you a sunny beach to live on, make a mojito and go for a swim. Since KDE has an office that all KDE developer are welcome to use in Barcelona I decided to move to Barcelona until I get bored. So far there's an interesting language or two, hot weather to help my fragile head and water polo in the sky. Do drop by next time you're in town.
Also new poll for Plasma 5. What's your favourite feature?
Plasma 5 Release Party Drinks
This past spring I had the great opportunity to work with Matthew Helmke, José Antonio Rey and Debra Williams of Pearson on the 8th edition of The Official Ubuntu Book.
In addition to the obvious task of updating content, one of our most important tasks was working to “future proof” the book more by doing rewrites in a way that would make sure the content of the book was going to be useful until the next Long Term Support release, in 2016. This meant a fair amount of content refactoring, less specifics when it came to members of teams and lots of goodies for folks looking to become power users of Unity.
Quoting the product page from Pearson:
The Official Ubuntu Book, Eighth Edition, has been extensively updated with a single goal: to make running today’s Ubuntu even more pleasant and productive for you. It’s the ideal one-stop knowledge source for Ubuntu novices, those upgrading from older versions or other Linux distributions, and anyone moving toward power-user status.
Its expert authors focus on what you need to know most about installation, applications, media, administration, software applications, and much more. You’ll discover powerful Unity desktop improvements that make Ubuntu even friendlier and more convenient. You’ll also connect with the amazing Ubuntu community and the incredible resources it offers you.
Huge thanks to all my collaborators on this project. It was a lot of fun to work them and I already have plans to work with all three of them on other projects in the future.
So go pick up a copy! As my first published book, I’d be thrilled to sign it for you if you bring it to an event I’m at, upcoming events include:
- August 9, Philadelphia: Fosscon
- August 27-31, Portland, OR: Debconf 14
- September 11-13, Orlando: Fossetcon
- September 23, San Francisco: PuppetConf
- October 22-23, Raleigh: All Things Open
And of course, monthly Ubuntu Hours and Debian Dinners in San Francisco.
Technically a fork is any instance of a codebase being copied and developed independently of it’s parent. But when we use the word it usually encompasses far more than that. Usually when we talk about a fork we mean splitting the community around a project, just as much as splitting the code itself. Communities are not like code, however, they don’t always split in consistent or predictable ways. Nor are all forks the same, and both the reasons behind a fork, and the way it is done, will have an effect on whether and how the community around it will split.
There are, by my observation, three different kinds of forks that can be distinguished by their intent and method. These can be neatly labeled as Convergent, Divergent and Emergent forks.Convergent Forks
Most often when we talk about forks in open source, we’re talking about convergent forks. A convergent fork is one that shares the same goals as it’s parent, seeks to recruit the same developers, and wants to be used by the same users. Convergent forks tend to happen when a significant portion of the parent project’s developers are dissatisfied with the management or processes around the project, but otherwise happy with the direction of it’s development. The ultimate goal of a convergent fork is to take the place of the parent project.
Because they aim to take the place of the parent project, convergent forks must split the community in order to be successful. The community they need already exists, both the developers and the users, around the parent project, so that is their natural source when starting their own community.Divergent Forks
Less common that convergent forks, but still well known by everybody in open source, are the divergent forks. These forks are made by developers who are not happy with the direction of a project’s development, even if they are generally satisfied with it’s management. The purpose of a divergent fork is to create something different from the parent, with different goals and most often different communities as well. Because they are creating a different product, they will usually be targeting a different group of users, one that was not well served by the parent project. They will, however, quite often target many of the same developers as the parent project, because most of the technology and many of the features will remain the same, as a result of their shared code history.
Divergent forks will usually split a community, but to a much smaller extent than a convergent fork, because they do not aim to replace the parent for the entire community. Instead they often focus more on recruiting those users who were not served well, or not served at all, by the existing project, and will grown a new community largely from sources other than the parent community.Emergent Forks
Emergent forks are not technically forks in the code sense, but rather new projects with new code, but which share the same goals and targets the same users as an existing project. Most of us know these as NIH, or “Not Invented Here”, projects. They come into being on their own, instead of splitting from an existing source, but with the intention of replacing an existing project for all or part of an existing user community. Emergent forks are not the result of dissatisfaction with either the management or direction of an existing project, but most often a dissatisfaction with the technology being used, or fundamental design decisions that can’t be easily undone with the existing code.
Because they share the same goals as an existing project, these forks will usually result in a split of the user community around an existing project, unless they differ enough in features that they can targets users not already being served by those projects. However, because they do not share much code or technology with the existing project, they most often grow their own community of developers, rather than splitting them from the existing project as well.
All of these kinds of forks are common enough that we in the open source community can easily name several examples of them. But they are all quite different in important ways. Some, while forks in the literal sense, can almost be considered new projects in a community sense. Others are not forks of code at all, yet result in splitting an existing community none the less. Many of these forks will fail to gain traction, in fact most of them will, but some will succeed and surpass those that came before them. All of them play a role in keeping the wider open source economy flourishing, even though we may not like them when they affect a community we’ve been involved in building.
Why oh why are they so hard to write?
Even using the built in modules it is insanely hard to debug. Playing a bootsplash in X sucks and my machine boots too fast to test it on reboot.
Basically, euch. All I wanted was a hackers zebra on boot :(
Friday was my last day at Collabora, the awesome Open Source consultancy in Cambridge. I’d been there more than three years, and it was time for a change.
As luck would have it, that change came in the form of a job offer 3 months ago from my long-time friend in Open Source, Miguel de Icaza. Monday morning, I fly out to Xamarin’s main office in Boston, for just over a week of induction and face time with my new co workers, as I take on the title of Release Engineer.
My job is to make sure Mono on Linux is a first-class citizen, rather than the best-effort it’s been since Xamarin was formed from the ashes of the Attachmate/Novell deal. I’m thrilled to work full-time on what I do already as community work – including making Mono great on Debian/Ubuntu – and hope to form new links with the packer communities in other major distributions. And I’m delighted that Xamarin has chosen to put its money where its mouth is and fund continued Open Source development surrounding Mono.
If you’re in the Boston area next week or the week after, ping me via the usual methods!
So it's that time of year again, it's my ex-smoker-versary. Okay I'll come up with a better name for next year but for now you'll have to make do with my reflection on smoking and why it's really not that hard to quit, as well as a few silly numbers.
Thirty-six-score-and-ten days ago I stopped smoking.
- I stopped picking them up.
- I stopped buying them.
- I stopped doing things that made me want to smoke.
- I stopped cold turkey. No NRT, no e-cigs.
I just stopped and braced for the worst.
And I was expecting the worst.
It took me quitting to realise that it was probably that fear of unworldly cravings that kept me smoking for 10 years. When I got to 4 weeks without any nicotine I realised hadn't been that bad at all... Anything that says otherwise is probably either trying to keep you smoking or is trying to sell you something to do instead.Quitting is easy, just stop smoking and you'll realise that
And this isn't a silly confidence trick. I'm not going to get all happy-clappy and woosah about this. Just stop smoking and you'll see that after a week you won't physically crave (the worst bit), after two or three you stop thinking about them, and after four weeks you're awesome...
Just don't start smoking again. A sober, smoke-free mind is jubilant you're not smoking, and under its sole influence you'll do anything to avoid clouds of smoke... But have a couple of drinks and you can very quickly find yourself drifting intimately close to smokers.
I've also heard from more than a couple of people who "tried to quit" but were still surrounded by cigarettes. Quitting does take willpower and few have enough to resist that "emergency packet" especially in the first couple of weeks. Chuck them all, avoid your triggers and make it easy on yourself.
You have to be vigilant. And consistent.
One cigarette is the end of the world. No, you cannot have a cigar.
Now onto the fun stuff. There's a silly little tray application called QuitCount in the Ubuntu repos that I set up when I quit. It just keeps track of the number of days, an accumulated number of cigarettes (based on my rate of ~13 a day) and works out how much that would cost, as well as using some formula to work out how much less dead I'm going to be.
- 9490 cigarettes have gone un-smoked
- 94.9g of tar not in my lungs
- An extra £3368.95 cluttering up my bank account (I wish), which is good because I also get:
- An extra 66 days cluttering up the planet.
And I wasn't a heavy smoker. If you're on 20 or 40 a day, those numbers could be a whole lot higher if you quit today.
Photo credit: mendhak
My first Erlang Factory, the event lasted for two fun-filled days and culminated with a stroll in the evening sun of San Francisco down to the Rackspace office where we held a Meetup mini-conference (beer, food, and three more talks). Conversations lasted until well after 10pm with the remaining die-hards making a trek through the nighttime streets SOMA and the Financial District back to their respective abodes.
Before the close of the conference, however, we managed to sneak a ride (4 of us in a Mustang) to Scoble's studio and conduct an interview with Joe Armstrong and Robert Virding. We covered some of the basics in order to provide a gentle overview for folks who may not have been exposed to Erlang yet and are curious about what it has to offer our growing multi-core world. This wend up on the Rackspace blog as well as the Building 43 site (also on YouTube). We've got a couple of teams using Erlang in Rackspace; if you're interested, be sure to email Steve Pestorich and ask him what's available!
This is a follow-up to the End of Life warning sent last month to confirm that as of today (July 17, 2014), Ubuntu 13.10 is no longer supported. No more package updates will be accepted to 13.10, and it will be archived to old-releases.ubuntu.com in the coming weeks.
The original End of Life warning follows, with upgrade instructions:
Ubuntu announced its 13.10 (Saucy Salamander) release almost 9 months ago, on October 17, 2013. This was the second release with our new 9 month support cycle and, as such, the support period is now nearing its end and Ubuntu 13.10 will reach end of life on Thursday, July 17th. At that time, Ubuntu Security Notices will no longer include information or updated packages for Ubuntu 13.10.
The supported upgrade path from Ubuntu 13.10 is via Ubuntu 14.04 LTS. Instructions and caveats for the upgrade may be found at:
Ubuntu 14.04 LTS continues to be actively supported with security updates and select high-impact bug fixes. Announcements of security updates for Ubuntu releases are sent to the ubuntu-security-announce mailing list, information about which may be found at:
Since its launch in October 2004 Ubuntu has become one of the most highly regarded Linux distributions with millions of users in homes, schools, businesses and governments around the world. Ubuntu is Open Source software, costs nothing to download, and users are free to customise or alter their software in order to meet their needs.
Originally posted to the ubuntu-announce mailing list on Thu Jul 17 16:19:36 UTC 2014 by Adam Conrad
In this week’s show:
- We interview David Hermann about his MiracleCast project…
We also discuss:
- We share some Command Line Lurve: YouTube-Upload to upload videos to YouTube from the command line:
And we read your feedback, including:
- Simon’s link to Seafile
- ”’full screen cast email here when we have permission”’
Thanks for sending it in!
We’ll be back next week, so please send your comments and suggestions to: firstname.lastname@example.org
Join us on IRC in #uupc on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: email@example.com and skype: ubuntuukpodcast
Follow us on Twitter
Find our Facebook Fan Page
Follow us on Google+
Barcelona Free Software Users & Hackers are having a Barcelona Free Software Users & Hackers mañana, see you there!