The OSTEP Team Wed, Nov 28. 2012
The Open Source Technology for Emerging Platforms (OSTEP) team at Seneca consists of four research assistants who work with me on projects related to enabling Linux and related open source technologies on emerging ARM systems - specifically working with the Fedora ARM Secondary Architecture initiative.
Since I haven't had an opportunity to introduce the team recently, I thought I would (very briefly) do so here.
Andrew Green (agreene) is our repo guru and is currently composing and testing the Raspberry Pi Fedora Remix 18. He is working part time with the OSTEP team while completing the CTY program at Seneca.
Dmitry Kozunov (DarthJava) works full-time with OSTEP. His main area of responsibility is the Fedora ARM buildsystem infrastructure, which means he wrestles heroically on a daily basis with unstable dev boards and multi-terabyte backups. He will be continuing his studies in the Seneca IFS program in January.
Jon Chiappetta (fossjon) is working full-time on a zippy armv6hl optimized build for the Raspberry Pi, and simultaneously experimenting with alternate approaches to koji queueing for secondary architectures. Jon is a graduate of our IFS program and our resident Python pro.
Jordan Cwang (frojoe) is a graduate of the Seneca CTY program and works part-time with the OSTEP team on infrastructure issues. He's is our bcfg2 whiz and is currently working on several infrastructure projects including improving security with measures such as two-factor authentication.
When is an SRPM not Architecture-neutral? Fri, Nov 23. 2012
Source RPM packages -- SRPMs -- have an architecture of "src". In other words, a source RPM is a source RPM, with no architecture associated with it. There's an assumption that the package is architecture-neutral in source form, and only become architecture-specific when built into a binary RPM (unless it builds into a "noarch" RPM, which is the case with scripts, fonts, graphics, and data files).
An SRPM contains source code (typically a tarball, and sometimes patch files) and a spec file which serves as manifest and build-recipe, plus metadata generated from the spec file when the SRPM is built -- including dependencies (which, unlike binary RPMs, are actually the build dependencies).
However, the build dependencies may vary by platform. If package foo is built against bar and baz, and baz exists on some architectures but not others, then the spec file may be written to build without baz (and the accompanying features that baz enables) on some architectures. The corresponding BuildRequires lines will also be made conditional on the architecture -- and this make total sense. However, querying an SRPM on a given platform may give incorrect build dependency information for that platform if the SRPM was built on another platform -- and only rebuilding the SRPM on the target arch will correct the rpm metadata (and possibly render it incorrect for other platforms). Thus, I've come to realize, SRPMs are not truly architecture-neutral -- and I'm not sure if all our tools take this into consideration.
Edit: I know that not all of our tools take this into consideration.
Interested in buying a Raspberry Pi? Mon, Sep 10. 2012
Measuring the Raspberry Pi's Current Consumption Wed, Jun 20. 2012
The Raspberry Pi has a micro-USB jack for power input. This can be used with any recent mobile phone adapter. If you use a two-part adapter, with a plug-in AC-DC converter and a USB A to micro-USB A cable, it's easy to measure the current drawn by the Pi.
To do this, you'll need a USB A male to USB A female extension cord and an ammeter or multimeter with a 1A or 10A range.
1. Remove the outer insulation in the middle of the USB extension cable. Peel back the shielding (silver braid and/or foil) to one side.
2. Cut the 5V supply wire (usually coloured red).
3. Connect your ammeter or multimeter to the cut 5V line.
4. Insert this cable between your AC-DC converter and the USB cable going to your Raspberry Pi.
So, how much current does the Raspberry Pi draw?
It looks like the Pi can draw anywhere from 250 to 500 mA in normal operation, though I did see smaller values in the early stages of startup. When idle, my Pi draws 320-380 mA; with a basic Logitech keyboard and mouse attached and in use, and with the CPU and GPU fairly active, it comes close to 500 mA.
Update: Powering the Pi from a Laptop
The fact that the Pi's current consumption is reliably under 500 mA means that it is actually safe to power from the USB port of another system. This is convenient for developers on the go: for example, I'm in an air-conditioned library escaping the current Toronto heatwave, and have my Pi connected to the back of my laptop with a micro-USB cable for power and a crossover ethernet cable for data.
New Role: Industrial Research Chair - Open Source Technology for Emerging Platforms Thu, May 10. 2012
On Tuesday, the Natural Sciences and Engineering Research Council (NSERC) announced a number of grant awards at the Polytechnics 2012 conference, including the new Industrial Research Chairs for Colleges (IRCC) grants. I am honoured to be selected as the chairholder for the NSERC Industrial Research Chair for Colleges in Open Source Technology for Emerging Platforms in the Centre for Development of Open Technology at Seneca College.
This five-year renewable applied research grant enables me to continue and expand upon the work that I have been doing, along with a talented team of research assistants, with Fedora ARM and related projects. My goal is to bring the wealth of open source software currently available for x86 PCs and servers to emerging ARM based general-purpose computers. Although ARM architecture chips are the most popular CPUs made (more ARM chips shipped last year than there are people on this planet), most of these went into dedicated devices, and ARM chips are just starting to appear in general purpose computers. In order to make the transition to general-purpose ARM systems viable, industry-standard software stacks are needed. Fedora is a perfect fit for this purpose, because it encompasses both a large collection of cutting-edge open source software and a vibrant community, and it feeds many downstream distributions and projects.
My work in this new role will start with an expansion of existing work, including operating the Fedora ARM Koji buildsystem and improving the Raspberry Pi Fedora Remix, but I will additionally be focusing on Fedora on ARM server-class systems. In future phases, this will encompass working with the Fedora ARM project to promote ARM to primary architecture status, extending existing open source system management (and possibly virtualization/cloud management) frameworks to manage high-density ARM clusters, doing field trials of ARM-based data centre solutions, and bringing Fedora to the next generation of ARM technology.
Although the majority of my activity will shift from teaching to applied research, I will continue to teach the SBR600 Software Build and Release course in order to bring the research experience back into the classroom. I'll also continue to participate in the TeachingOpenSource.org initiative. As an Industrial Research Chair, I will also have a bit more of a public-facing role, representing CDOT and advocating the use of energy-efficient systems to local SMEs.
Many thanks to Red Hat for partnering with Seneca on this initiative, and I look forward to (continuing to!) work closely with Red Hat's incredible technical staff. I also thank the many companies and organization who wrote letters of support for the grant application, and look forward to collaboration and possible future partnerships with those organizations. And I particularly want to thank Seneca for its support of applied research, my colleagues at CDOT for their encouragement and for creating such an awesome environment to do applied research, and for the team that wrote the grant application under intense pressure and tight deadlines last November.
Watch this space for updates!
Element 14's Wonderful Forums Considered Harmful Fri, Mar 9. 2012
This understandable requirement, probably a result of US legislation (and perhaps legislation in other jurisdictions?), is at odds with the Raspberry Pi's stated focus on children (hence the "considered harmful" jab).