Andrew Pollock: [tech] A geek Dad goes to Kindergarten with a box full of Open Source and some vegetables
Zoe's Kindergarten encourages parents to come in and spend some time with the kids. I've heard reports of other parents coming in and doing baking with the kids or other activities at various times throughout the year.
Zoe and I had both wanted me to come in for something, but it had taken me until the last few weeks of the year to get my act together and do something.
I'd thought about coming in and doing some baking, but that seemed rather done to death already, and it's not like baking is really my thing, so I thought I'd do something technological. I just wracked my brains for something low effort and Kindergarten-age friendly.
The Kindergarten has a couple of eduss touch screens. They're just some sort of large-screen with a bunch of inputs and outputs on them. I think the Kindergarten mostly uses them for showing DVDs and hooking up a laptop and possibly doing something interactive on them.
As they had HDMI input, and my Raspberry Pi had HDMI output, it seemed like a no-brainer to do something using the Raspberry Pi. I also thought hooking up the MaKey MaKey to it would make for a more fun experience. I just needed to actually have it all do something, and that's where I hit a bit of a creative brick wall.
I thought I'd just hack something together where based on different inputs on the MaKey MaKey, a picture would get displayed and a sound played. Nothing fancy at all. I really struggled to get a picture displayed full screen in a time efficient manner. My Pi was running Raspbian, so it was relatively simple to configure LightDM to auto-login and auto-start something. I used triggerhappy to invoke a shell script, which took care of playing a sound and an image.
Playing a sound was easy. Displaying an image less so, especially if I wanted the image loaded fast. I really wanted to avoid having to execute an image viewer every time an input fired, because that would be just way too slow. I thought I'd found a suitable application in Geeqie, because it supported being out of band managed, but it's problem was it also responded to the inputs from the MaKey MaKey, so it became impossible to predictably display the right image with the right input.
So the night before I was supposed to go to Kindergarten, I was up beating my head against it, and decided to scrap it and go back to the drawing board. I was looking around for a Kindergarten-friendly game that used just the arrow keys, and I remembered the trusty old Frozen Bubble.
This ended up being absolutely perfect. It had enough flags to control automatic startup, so I could kick it straight into a dumbed-down full screen 1 player game (--fullscreen --solo --no-time-limit)
The kids absolutely loved it. They were cycled through in groups of four and all took turns having a little play. I brought a couple of heads of broccoli, a zucchini and a potato with me. I started out using the two broccoli as left and right and the zucchini to fire, but as it turns out, not all the kids were as good with the "left" and "right" as Zoe, so I swapped one of the broccoli for a potato and that made things a bit less ambiguous.
The responses from the kids were varied. Quite a few clearly had their minds blown and wanted to know how the broccoli was controlling something on the screen. Not all of them got the hang of the game play, but a lot did. Some picked it up after having a play and then watching other kids play and then came back for a more successful second attempt. Some weren't even sure what a zucchini was.
Overall, it was a very successful activity, and I'm glad I switched to Frozen Bubble, because what I'd originally had wouldn't have held up to the way the kids were using it. There was a lot of long holding/touching of the vegetables, which would have fired hundreds of repeat events, and just totally overwhelmed triggerhappy. Quite a few kids wanted to pick up and hold the vegetables instead of just touch them to send an event. As it was, the Pi struggled to play Frozen Bubble enough as it was.
The other lesson I learned pretty quickly was that an aluminium BBQ tray worked a lot better as the grounding point for the MaKey MaKey than having to tether an anti-static strap around each kid's ankle as they sat down in front of the screen. Once I switched to the tray, I could rotate kids through the activity much faster.
I just wish I was a bit more creative, or there were more Kindergarten-friendly arrow-key driven Linux applications out there, but I was happy with what I managed to hack together with a fairly minimal amount of effort.
I've been thinking about this since reading The Origins of Political Order: From Prehuman Times to the French Revolution by Francis Fukuyama. The basis of my comment is that in some ways, our KDE community is like a state.
Modern political order ...consists of ...[first] a modern state, with competent and honest officials, not prone to nepotism, corruption, and clientelism. Second is the rule of law, or binding constraints upon the rulers as well as the ruled. Third is accountability, usually via elections but also via a sense of responsibility towards the people, a sense of ruling for the common good. - from http://www.history.ac.uk/reviews/review/1261, a review of the book.
What supports and keeps a state alive are institutions. According to the Stanford Encyclopedia, social institutions are ... sets of rules and norms that organise human activities within a society. These rules and norms aren't just written law, such as our Code of Conduct and Manifesto, but also the unwritten "way we do things here." We have our habit of collaboration, our e.V., Akademy, our infrastructure, our coding style, APIs, documentation, and so forth.
And what is cool is to see that we continue to adapt to a changing world. I see the Frameworks effort as leap forward in our ability to adapt. The Plasma 5 work has flexibility written into it from the beginning, especially important as new form factors come onto the market. And we seem to be doing this within our community as well as in our code.
Fukuyama spoke not only about the development of the major institutions: the state, the rule of law, and accountability, but also of political decay, which happens when institutions grow rigid, and don't change with the times. I see the opposite with KDE.
Randa Meetings are a beautiful example of how one great idea has grown into something people look forward to, plan for, and support in many ways. We've had sprints for a long time, but now the year's calendar feels empty if there is no Randa meeting planned. The teams there not only do a sprint as usual, but also feed on the energy of the other teams around them, and collaborate on the fly. The Randa Meetings, like Akademy, have become indispensable; a norm. And that's a good thing.
What a wonderful all hands we had this past week. The entire week was full of meetings and planning and I must say I was exhausted by Thursday having been up each day working by 6:00am and going to bed by midnight.
I’m very happy to report that I made a lot of progress on meeting with more people to discuss the future of Firefox Extended Support Release and how to make it a much better offering to organizations.
I also spent some time talking to folks about Firefox in Ubuntu and rebranding Iceweasel to Firefox in Debian (fingers crossed something will happen here in 2015). Also it was great to participate in discussions around making all of the Firefox channels offer more stability and quality to our users.
It was great to hear that we will be doing some work to bring Firefox to iOS which I think will fill a gap that has existed for our users of OSX who have an iPhone. Anyways, what I can say about this all hands is that there were lots of opportunities for discussions on quality and the future is looking very bright.
Also a big thanks to Lukas Blakk who put together an early morning excursion to Sherwood Ice Arena where Mozillians played some matches of hockey which I took photos of here.
In closing, I have to say it was a great treat for Macklemore & Ryan Lewis to come and perform for us in a private show and help us celebrate Mozilla.
I want to add my two cents and say I really do not think that the Ubuntu Community has suffered from a lack of leadership and good governance, both separate things. I think Jonathan Carter (Highvoltage) really nailed it when he said this in the Community Council meeting “if you visit a canonical page on community and how to get involved, it’s *full* of whatever’s important to canonical right now” and he went on to add some examples on where Canonical has in the past just made important decisions without input from Community and pointed out there are even more recent examples he could offer.
So the real issue is if the Ubuntu Community wants to tackle it is not leadership or governance because we have brilliant leaders and members of governance but instead it is making contributors feel like they are stakeholders again and kept in the loop. Mind you, the Canonical Community Team has repeatedly promised to help Canonical employees get better at keeping the community in the loop even promising such at UDS-P but my experience has been they never really got better.
Finally, I think an Ubuntu Foundation is still a great idea and could create some harmony between Canonical’s commercial interests and the community interests of the project. Projects that have had companies controlling the project have never had great success at sustaining a community because the commercial interests always win at the end of the day.
Something needs to be done otherwise there will be a continued decline in participation in Ubuntu. Let me say the only reason Ubuntu Membership has not had the same downtrend as UDS participation and governance participation is because you do not need to be re-vetted to be an Ubuntu Member. We have folks who are Ubuntu members who have not been on IRC, Mailing List or anywhere in the project in years but are still members. The reality is that if we just looked at contributions, the actual amount of contributors today is far less than the member rolls represent.
And remember you can use it with any Linux distro! Download it while it's hot.
I do hang out in #debian-women on IRC, which shouldn't be much of a surprise after my last blog entry about my Feminist Year. And for readers of my blog it also shouldn't be much of a surprise that Music is an important part of my life. Recently a colleague from Debian though asked me in said IRC channel about whether I can recommend some female artists or bands. Which got me looking through my recommendations so far, and actually, there weren't many of those in here, unfortunately. So I definitely want to work on that because there are so many female singers, songwriters and bands out there that I totally would like to share with the broader audience.
I want to start out with a strong female voice who was introduced to me by another strong woman—thanks for that! Fiona Apple definitely has her own style and is something special, she stands out. Here are my suggestions:
- Hot Knife: This was the song I was introduced to her with. And I love the kettledrum rhythm and sound.
- Criminal: Definitely a different sound, but it was the song that won her a Grammy.
- Not About Love: Such a lovely composition. I do love the way she plays the piano.
Like always, enjoy!
If there's anything I learned from hack.summit() (more on that soon), it's that we need more mentorship opportunities. The Ubuntu community informally offers mentorship opportunities, but with the loss of the Ubuntu Beginners Team, the amount of mentorship, I believe, has declined. Without a formal and inviting place, I think a lot of people are left to kind of figure it out on their own. With so many documents being written to a more higher level of user, I think we really lose potential contributors.
With the goal of having Linux users also be Linux contributors, a band of friends and I (mostly from the Lubuntu Team) have put together a new project we call Linux Padawan. You might remember that padawans were apprentices to the Jedi Masters in Star Wars. So we seek to unite masters with padawans to be mentored in their learning and contributors to their respective community.
Note that wording. Linux Padawan is distro-agnostic. There are certainly many of us who are from various parts of the Ubuntu community, but not all of us are. Additionally, we don't want to shut the door on people who are not or may not be interested in joining the Ubuntu community. Of course, we'll continue to invite them in. ☺
I've set myself up there with the following areas of expertise: testing & bug squashing, community, programming, Lubuntu, BSD (yes, we're even going to support BSD!). If you need mentoring on any of these, please let me know.
I really want to focus my efforts on programming, though. I'm not the world's greatest programmer (yet), but I know enough that I can help foster people to become programmers. hack.summit() focused on how we need mentorship in programming. I couldn't agree more. Learning how to program is relatively easy. Taking that to the next level and actually making a contribution is a whole different story.
To that end, over the past couple of days, I have developed a fairly general introduction to the subject, with plenty of links. Please take a look at that here and let me know if you know of any other resources that can be added.
Most of all, I encourage you to consider learning programming. It's not as scary as it seems. Additionally, learning some of the tools and processes that programmers use can help you to successfully contribute to things like documentation. An exmaple is the Ubuntu Server Guide which is "programmed" in XML and whose development happens on Launchpad.
I guess I'm taking this a little farther than the Hour of Code which happens next week. I don't just want to contribute an hour to get kids into programming. Instead, I'd like to donate whatever time I need to help everyone find the resources they need to contribute code to open source projects. How can you refuse that offer?
Google Code-in is a project for school pupils (age 13 to 17) who are interested in helping out with open source projects. KDE is taking part in Google Code-in and Kubuntu is posting projects as part of KDE. If you want to help out Kubuntu or KDE sign up and pick a project to help out with. They only take a few days each.
As we come to the end of 2014, looking forward to new devices running Ubuntu in our immediate future, it’s time for one last set of Hack Days of the year.
Next week, from Monday 8th December till Friday 12th we’re going to be having another set of Core Apps Hack Days. We’ve had a few of these this year which have been a great way to focus attention on specific applications and their dependent components in the platform. They’re also a nice gateway for getting new people into the Core Apps project and Ubuntu development in general.
The Core Apps are community maintained Free Software applications which were created for Ubuntu devices, but also work on the Ubuntu desktop. We welcome new developers, testers, autopilot writers, artists and translators to get involved in these exciting projects.The schedule
As with previous hack days we’re going to focus on specific apps on each day, which we run from 9:00 UTC until 21:00 UTC. In summary our schedule looks like this:-
- Monday 8th – Calculator, Terminal & Clock
- Tuesday 9th – File Manager & Calendar
- Wednesday 10th – Music & Document Viewer – QA Day Workshop: writing tests for the core apps (18:00UTC)
- Thursday 11th – Shorts & Reminders
- Friday 12th – Weather & Dekko (email)
Creating core apps involves close coordination between developers and designers to provide the right set of features, high usability and appealing visuals. All these would be nothing without a suite of automated tests that are run to ensure the features are rock-solid and that no regressions are introduced with new development.
All core apps include Autopilot and QML tests that we are constantly expanding to increase test coverage. Writing tests for core apps is a nice way to get started contributing. All you’ll need is some Python knowledge for Autopilot tests or QML for QML tests. Our quality man, Nicholas Skaggs will be running a live video workshop on Wednesday Dec 10th, at 18:00UTC, as an on-ramp to learn how to create tests.Join the fest
The Hack Days will be happening live at the #ubuntu-app-devel IRC channel on Freenode
The QA Workshop will be happening also live on Ubuntu On Air. You can watch the video and ask your questions on the same IRC channel.
We’ll blog more details about the apps each day next week with links to specific bugs, tasks and goals, so stay tuned!
As always we greatly appreciate all contributions to the Core Apps project during the Hack Days, but welcome community efforts all year round, so if this week doesn’t work for you, feel free to drop by #ubuntu-app-devel on Freenode any time and speak to me, popey.
Autopilot is a test running that we at Canonical use for the UI testing at the integration level. This nice tool is pretty fun and easy to use with some basic knowledge of python. After using it to write automation for more than a year, I finally ended up contributing to the test runner code itself.
One of the issues that was discovered while writing tests with autopilot that when it was doing multiple clicks continuously there was very little gap between the events. Imagine a test where the phone dials a long number in less than a second ? Not so human, is it ?
The solution that was agreed upon, was to introduce a reusable mechanism in autopilot where it would try to "humanize" the click/tap events. So now, when you dial a number or do some calculation in calculator app with autopilot, it will have at least a delay of 100 ms between those events. The below code sample would make it easy to understand.
# lets assume 'pointer' is the input emulator for Mouse
# This click will happen after somewhat ~2 seconds.
The feature is in trunk and will hopefully be released with the next autopilot version.
Hello everyone. After a bit of silence I'm super pleased to announce that Checkbox [Touch] is now in the Ubuntu Click store. Get it on all your devices running Ubuntu RTM or newer.
Our hybrid QML + Python3 application is available on x86 , amd64 and armhf alike, from one .click file. Bugs and any other feedback can be reported on https://bugs.launchpad.net/checkbox-touch/+filebug The code is available, under the GPLv3 license, in the lp:checkbox repository.
Thanks a lot to everyone that made this possible!
Matt Bruzek and Jose Antonio Rey have now updated the tests and charm for Owncloud for 14.04, you can find it here at the snazzy new jujucharms.com.
Note that this does use upstream’s packages and you can set the version of Owncloud in the charm itself, so it doesn’t go out of date!
Folks, I need to ask for some help.
Like many, I have some go-to examples of great communities. This includes Wikipedia, OpenStreetmap, Ubuntu, Debian, Linux, and others. Many of these are software related, many of them are Open Source.
I would like to ask your feedback for other examples of great communities. These don’t have to be software-related…in fact I would love to see examples of great communities in other areas and disciplines.
They could be collaborative communities, communities that share a common interest, communities that process big chunks of data, communities that inspire and educate certain groups (e.g. kids, under-privilaged), or anything else.
I am looking for inspiring examples that get to the heart of what makes communities beautiful. These don’t have to be huge and elaborate communities, they just need to demonstrate the power of people sharing a mission or ethos and doing interesting things.
Please share your examples in the comments, and in doing so, please share the following:
- The name of the community
- A web address / contact person
- Overview of the community, what it does, and why you feel it is special
understand the commitment you are making to pay for the entire 1-3 years
Amazon just announced a change in the way that Reserved Instances are sold. Instead of selling the old Reserved Instance types:
- Light Utilization
- Medium Utilization
- Heavy Utilization
EC2 is now selling these new Reserved Instance types:
- No Upfront
- Partial Upfront
- All Upfront
Despite the fact that they are still called “Reserved Instances” and that there are three plans which sound like increasing commitment, the are not equivalent and do not map 1-1 old to new. In fact the new Reserved Instances are not even increasing commitment.
You should forget what you knew about Reserved Instances and read all the fine print before making any further Reserved Instance purchases.
One of the big differences between the old and the new is that you are always committing to spend the entire 1-3 years of cost even if you are not running a matching instance during part of that time. This text is buried in the fine print in a “**” footnote towards the bottom of the pricing page:
When you purchase a Reserved Instance, you are billed for every hour during the entire Reserved Instance term that you select, regardless of whether the instance is running or not.
As I pointed out in the 2012 article titled Save Money by Giving Away Unused Heavy Utilization Reserved Instances, this was also true of Heavy Utilization Reserved Instances, but with the old Light and Medium Utilization Reserved Instances you stopped spending money by stopping or terminating your instance.
Let’s walk through an example with the new EC2 Reserved Instance prices. Say you expect to run a c3.2xlarge for a year. Here are some options at the prices when this article was published:Pricing Option Cost Structure Yearly Cost Savings over On Demand On Demand $0.420/hour $3,679.20/year No Upfront RI $213.16/month $2,557.92/year 30% Partial Upfront RI $1,304/once + $75.92/month $2,215.04/year 40% All Upfront RI $2,170/once $2,170.00/year 41%
There’s a big jump in yearly savings from On Demand to the Reserved Instances, and then there is an increasing (but sometimes small) savings for the more of the total cost you pay up front. The percentage savings varies by instance type, so read up on the pricing page.
The big difference is that you can stop paying the On Demand price if you decide you don’t need that instance running, or you figure out that the application can work better on a larger (or smaller) instance type.
With all new Reserved Instance pricing options, you commit to paying the entire year’s cost. The only difference is how much of it you pay up front and how much you pay over the next 12 months.
If you purchase a Reserved Instance and decide you don’t need it after a while, you may be able to sell it (perhaps at some loss) on the Reserved Instance Marketplace, but your odds of completing a sale and the money you get back from that are not guaranteed.
Original article: http://alestic.com/2014/12/ec2-reserved-instances
The manifest file
Click packages follow a specific format. Click packages contain a payload of an application's libraries, code, artwork and resources, along with its needed external dependencies. The description of the package is found in the manifest file, which is what I'd like to talk about. The file must contain a few keys, but one of the recognized optional keys is architecture. This key allows specifying architectures the package will run on.
If an application contains no compiled code, simply use 'all' as the value for architecture. This accomplishes the goal of running on all supported architectures and many of the applications currently in the ubuntu touch store fall into this category. However, an increasing number of applications do contain compiled code. Here's how to enable support across architectures for projects with compiled code.
The click format along with the ubuntu touch store fully support specifying one or more values for specific architecture support inside the application manifest file. Those values follow the same format as dpkg architecture names. Now in theory if a project containing compiled code lists the architectures to support, click build should be able to build one package for all. However, for now this process requires a little manual intervention. So lets talk about building a fat (or big boned!) package that contains support for multiple architectures inside a single click package.
Those who just want to skip ahead can check out the example package I put together using clock. This same package can be found in the store as multi-arch clock test. Feel free to install the click package on the desktop, the i386 emulator and an armhf device.
Building a click for a different architecture
To make a multi-arch package a click package needs to be built for each desired architecture. Follow this tutorial on developer.ubuntu.com for more information on how to create a click target for each architecture. Once all the targets are setup, use the ubuntu sdk to build a click for each target. The end result is a click file specific to each architecture.
For example in creating the clock package above, I built a click for amd64, i386 and armhf. Three files were generated:
Notice the handy naming scheme allows for easy differentiation as to which click belongs to which architecture. Next, extract the compiled code from each click package. This can be accomplished by utilizing dpkg. For example,
dpkg -x com.ubuntu.clock_3.2.176_amd64.click amd64
Do this for each package. The result should be a folder corresponding to each package architecture.
Next copy one version of the package for use as the base of multi-arch click package. In addition, remove all the compiled code under the lib folder. This folder will be populated with the extracted compiled code from the architecture specific click packages.
cp amd64 multi
rm -rf multi/lib/*
Now there is a folder for each click package, and a new folder named multi that contains the application, minus any compiled code.
Creating the multi-arch click
Inside the extracted click packages is a lib folder. The compiled modules should be arranged inside, potentially inside an architecture subfolder (depending on how the package is built).
Copy all of the compiled modules into a new folder inside the lib folder of the multi directory. The folder name should correspond to the architecture of the complied code. Here's a list of the architectures for ARM, i386, and amd64 respectively.
You can check the naming from an intended device by looking in the application-click.conf file.
grep ARCH /usr/share/upstart/sessions/application-click.conf
To use the clock package as an example again, here's a quick look at the folder structure:
The contents of lib/* from each click package I built earlier is under a corresponding folder inside the multi/lib directory. So for example, the lib folder from com.ubuntu.clock_3.2.176_i386.click became lib/i386-linux-gnu/.
Presto, magic package time!
Finally the manifest.json file needs to be updated to reflect support for the desired architectures. Inside the manifest.json file under the multi directory, edit the architecture key values to list all supported architectures for the new package. For example to list support for ARM and x86 architectures,
"architecture": ["armhf", "i386", "amd64"],
To build the new package, execute click build multi. The resulting click should build and be named with a _multi.click prefix. This click can be installed on any of the specified architectures and is ready to be uploaded to the store.
Caveats, nibbly bits and bugs
So apart from click not automagically building these packages, there is one other bug as of this writing. The resulting multi-arch click will fail the automated store review and instead enter manual review. To workaround this request a manual review. Upon approval, the application will enter the store as usual.
In summary to create a multi-arch click package build a click for each supported architecture. Then pull the compiled library code from each click and place into a single click package. Next modify the click manifest file to state all of the architectures supported. Finally, rebuild the click package!
I trust this explanation and example provides encouragement to include support for x86 platforms when creating and uploading a click package to the store. Undoubtedly there are other ways to build a multi-arch click; simply ensure all the compiled code for each architecture is included inside the click package. Feel free to experiment!
If you have any questions as usual feel free to contact me. I look forward to seeing more applications in the store from my unity8 desktop!
Release Metrics and Incoming Bugs
Release metrics and incoming bug data can be reviewed at the following link:
Status: Vivid Development Kernel
The master-next branch of our Vivid kernel has been rebased to the
v3.18-rc7 upstream kernel. We have pushed uploads to our team’s PPA
for preliminary testing. We have still withheld uploading to
the archive while we iron out some final issues.
Important upcoming dates:
Thurs Dec 18 – Vivid Alpha 1 (~2 weeks away)
Thurs Jan 22 – Vivid Alpha 2 (~7 weeks away)
Thurs Feb 5 – 14.04.2 Point Release (~9 weeks away)
The current CVE status can be reviewed at the following link:
Status: Stable, Security, and Bugfix Kernel Updates – Utopic/Trusty/Precise/Lucid
Status for the main kernels, until today (02-Dec):
- Lucid – Verification & Testing
- Precise – Verification & Testing
- Trusty – Verification & Testing
Utopic – Verification & Testing
Current opened tracking bugs details:
For SRUs, SRU report is a good source of information:
cycle: 21-Nov through 13-Dec
21-Nov Last day for kernel commits for this cycle
23-Nov – 29-Nov Kernel prep week.
30-Nov – 13-Dec Bug verification; Regression testing; Release
Note: Utopic and LTS-Utopic kernels are being respun due to a verification
Open Discussion or Questions? Raise your hand to be recognized
No open discussions.