Facebook

Sugar on a Stick is a project which aims to create a live learning environment on a USB stick. This environment is a Fedora spin hosting the Sugar environment (the learning software original created as part of the OLPC project).

In previous versions of SoaS, the activities were not thoroughly screened before inclusion in the Spin, and so the SoaS Activity Criteria were introduced. I've been working with some other POSSE RIT participants to try and get three activities - Abacus, Maze, and Memorize - to the point of meeting the criteria. It's been a frustrating experience, but we've made some progress:

• Abacus
• Performed a package review (not passed, but close) of Peter Robinson's sugar-abacus package in Fedora
• Created a basic page for recording smoke test results
• Maze
• Filed a bug against the sugar-maze package in Fedora (apparently missing an essential .py file)
• Memorize
• This activity meets most of the criteria, but we weren't able to save to the journal (know issue) and could not confirm that collaboration works (might have been our Sugar configuration or networking)

It's apparent that the Sugar project needs more contributions, including wiki gardening, testing, and documentation -- all of which are areas in which new contributors can become quickly involved.

One interesting find I made while working with the Seneca students on Fedora ARM was that a loopback filesystem hosted on top of an NFS share can outperform the NFS share. Yes, it's counter-intuitive, because that would seem to introduce additional layers of processing, but I think it makes sense.

When using NFS, file metadata management is performed by NFS. When loopback-mounting a filesystem in a file hosted on NFS, the file metadata management takes place entirely on the local system -- NFS merely provides a data store. In this sense, it's not much different from iSCS, because the loopback filesystem can't be readily accessed by two separate hosts at once.

In fact, on a small ARM system such as an OpenRD-Client, loopback-ext3-on-NFS over GigE handily outperforms both Class 6 SD and a local USB-PATA drive.

Why not just use iSCSI? Well, for reasons I haven't yet determined, the Fedora iSCSI initiator doesn't work reliably on ARM-- under heavy load, it sends invalid opcodes to the target. This sounds like an alignment issue, but alignment fixups don't cure it. Investigation continues...

ARM processors power the digital mobile age. Billions are produced per year, ending up in the majority of cellphones as well as in e-book readers, plug computers, the OLPC XO 1.75, tablets, netbooks, intelligent RJ-45 network jacks, and even microSD cards.

The Fedora ARM Secondary Architecture project has done a great job of porting Fedora releases to ARM. To assist this initiative, this semester's Software Build and Release course at Seneca (SBR600) put together a new Koji build farm for the ARM architecture in preparation for using koji-shadow to follow the primary architectures. It's been a fascinating and challenging project -- working with cross-compilers, emulators, and hardware with much smaller configurations than standard PCs. A large amount of effort was spent benchmarking various configurations to determine optimal memory and storage arrangements and to compare emulated vs. hardware ARM performance to guide the configuration of the build farm.

So now we're at the end of the semester. Where do things stand?

• We have a working Koji build system, with two hardware builders plus emulated (VM) builders
• Since we're at the end of the semester, things will be quiet for the next week and a half, but then we've hired a graduate to work on this full-time (intros coming up shortly )

What's next? In May-June we expect to:

• set up FAS2 certs
• add 10+ hardware builders
• implement koji-shadow

I like TigerDirect stores: they're like geek supermarkets. However, they have some really annoying practices, such as entering my card number into their POS system, separately from their POS terminal; the terminal receipt shows only the last 5 digits of the card number, and the cash register receipt shows all but the last 6 digits. Anyone with those two receipts and the Luhn algorithm has the full card number.

But the practice that annoys me the most is having a person at the door "check the receipt" of each person making a purchase. The receipt-checker is standing only a few meters away from the cash register -- what is there to check? Is this an effective loss-prevention practice, or just a way to annoy customers?

Today I bought a micro-SD flash card with adapter for an Open-RD Client system that Seneca just purchased. The sales guy was helpful, and as I took the purchase to the lone cashier on duty, I found her talking to the receipt-checker. She shuffled over to the cash register. I paid and made my way to the door, and the receipt checker smiled at me and popped the top off his blue highlighter. I smiled back.

"May I check your receipt?" he asked.

"No," I answered, continuing to the door. I figured that the purchase has already been made, as far as I know they have no right to search or detain me, the receipt checker saw me pay the cashier, and it's obvious that I have one purchased item and one receipt in my hand.

Thinking he'd heard wrong, he again asked, "May I check it?"

"No," I replied, walking out.

"Thank you," he yelled after me as I left the store.

The Fedora qemu-system-arm package provides pretty good ARM processor emulation, which can be used to run the Fedora ARM secondary architechture. This is an easy way to get started working with ARM -- for example, while waiting for your plugcomputer, beagleboard, or OLPC XO 1.75 to arrive

The previous wiki notes on using ARM with QEMU didn't cover using qemu-system-arm under libvirt management. This meant that you couldn't easily take advantage of libvirt benefits such as automatic network setup (with DHCP and NAT), the virt-manager GUI tool, guest autostart, or disconnection/reconnection to the console.

I've updated https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu to include some basic notes on setting this up, and provided some files to simplify and speed up the process. Jump in and join Fedora-ARM, the water's nice!

I've met my share of error dialogs through the years. Ones that say "Something bad has happened. Ok?" are annoying but understandable.

However, one in gpk-update-viewer, which I encountered yesterday, is a real head-scratcher:

This dialog sometimes appears when you try to close the gpk-update-viewer window while updating and it reads:

Cannot cancel running task

There are tasks that cannot be cancelled.

[Cancel]  [Quit]

Quite apart from the fact that this dialog shouldn't appear at all -- packagekit will continue the update in the background -- the two buttons appear to mean the same thing, both of which are (according to the dialog) impossible.

(bug 567135)

Update: Richard Hughes noted in the comments that this is fixed upstream