Luke Faraone

I’m the package maintainer for Autokey in Debian. Upstream recently changed from using GTK+ to Qt4, which caused more than one complaint from users of testing.

The GTK+ version of the package is published in Ubuntu 9.10 Karmic. While upstream is continuing to do regular releases of the GTK version, they are focusing on the KDE version and have changed autokey to refer to the KDE version, while renaming the GTK version (formally autokey) to autokey-gtk. To make matters worse, upstream releases both as separate tarballs, and the packages conflict with one another.  (due to technical limitations)

What’s the proper proceedure for handling this in Ubuntu? Should -gtk conflict with autokey, replace it, with  autokey-qt being available as an option, or should I just keep things as they are and have the package “change out from under” users when they upgrade?

Looks like someone took the prompt at xmarks‘ GetSatisfaction site literally:

This really burns me up!? What kind of craptacular beta is this? Do you kiss your mom with this kind of code? You developers will be the first up against the wall when the revolution comes!?

Chrome Beta: password sync failed with horrible javascripty error message. [via Google]

I’ve been getting increasing numbers of requests from donors in the first OLPC Give 1 Get 1, many of whom are just getting around to opening their XOs, to have their laptops repaired. As is now widely known, due to a manufacturing glitch the first few batches of OLPC XO-1s that were shipped to consumers had a faulty motherboard battery holder. This alone wouldn’t be a problem, if only two other things hadn’t happened at the same time:

• The XO-1s were shipped with Open Firmware’s security enabled. This caused them to have the same anti-theft protection as laptops deployed in the third world, without any of the benefits of a remote killswitch or tracking
• The XO-1s had a version of OFW which would fail to boot when the clock was below a certain value

The above two issues combined with the manufacturing fault was a recipe for disaster. Owners who discovered this in the first 30 days were able to get a RMA and a working laptop, but OLPC lacked the resources to support those outside of this minimal warranty. I’ve been running an OLPC repair center, OLPC DC Repair, (charging only minimal fees for labor and shipping) since mid-2008, and have handled dozens of these “unbricking” problems.

The procedure for repairing the above is straightforward and well documented. However, it can be tedious, especially for those who are unfamiliar with the tools involved. Since I needed the programming practice anyway, I decided to write a rudimentary Python script to automate the process.

Thus enters d6.py. d6.py makes it (hopefully) amazingly simple to unbrick your XO, so that you can get up and running as soon as possible. You can clone the git repo, or download it directly (permalink). To download and run in a single command:

python -c "import urllib2; exec urllib2.urlopen('http://dev.laptop.org/git/activities/olpc-contrib/tree/d6.py').read();

Plug in your OLPC Serial Adapter (or one of the compatible alternatives), and run the script as a user which has access to /dev/ttyUSB0 (or as root, not recommended) or change the path inside the script to something suitable to your system. This script is in the alpha state, is poorly documented, and may not handle all edge cases (read: other people’s systems) well. I’m not responsible if it kills your cat, lights your XO on fire, or makes your wife leave you, but hopefully it’ll be of some use. Expect a GUI shortly.

Limitations:

• Does not handle all error conditions
• No command line params
• Hard-coded path to serial adapter

Therefore, the code does not run on other platforms other than Linux. You might also encounter problems if you’re running it on a system with brltty installed, removing it should fix the conflict.

Feedback is more than welcome in the comments.

NB: the following is an essay I wrote for an AP Psychology class. I’m publishing it here to get feedback on my terrible writing style.

The primary purpose of attending school is to learn new ideas, concepts, and methodologies. Ideally one should retain everything one learns in the classroom, so that one may do well in the short term, eg. on an exam, as well in the long term, in college and beyond. Unfortunately, there are a number of constraints on a person’s time and energy, such as after school activities and biological necessities. Therefore it is highly desirable if there are means by which we can increase our information retention with a minimal increase in the amount of time or effort spent learning.

An example of such tool is the Spacing Effect. It essentially states that one has a higher level of retention if one spaces periods of study over a longer period of time, contrasted with “cramming” everything in one go. Even if the total amount of time spent studying is the same, one will remember more if said time is spread across a wider period. While it is very easy to procrastinate, it is important to pace oneself and not “leave it all ’till the last minute” before an exam, essay, or other assessment. While one may still pass the assessment, they will probably not exhibit long-term recall, and will have to mostly relearn the material when it comes time for a final exam or standardized test. Read the rest of this entry »

Apologies for not posting recently, but I’ve been really busy with various events and tasks for the summer. I just got back from NECC09, where ISTE had been nice enough to give Sugar and other FLOSS projects their own presentation room, gratis.

While assisting with the various presentations at the Open Source Center and staffing the Sugar/OLPC booth, I ran into some of the folks from NComputing. Their corporation has some similiar goals with that of OLPC, as both involve low-cost computing for the third world and elsewhere. Providing multi-seat technology, which is similar to thin-clients without the lag and network overhead, they enable multiple displays and mice to function off a single computer. Since they support both Ubuntu and SuSE Linux with their (admittedly closed) hardware, I decided to investigate their technology as a means of enhancing deployment of Sugar.

The method to activate the NComputing software (requires registration to download) is not obvious; one must navigate to the console, select “Serial Numbers” from the side menu, and then right click the empty license list and choose “Manage”. Many users would not be able to do so without the manual; maybe it would be easier to prompt for a license key in the debconf install process?

Unfortunately, I wasn’t able to test their software with Sugar; the most recent version of Ubuntu they support is 8.04, and I can’t even insmod their kernel module on 9.04.

aside: meant to put this out an age ago, just got around to hitting “publish” today. (2009-08-16)

In this session, we’ll explore some parts of infosec which should be taught in primary school.

We’re all too smart to use the same password on multiple sites, right?

While most people, I included, cannot say “yes” to the first question (at least not for everything), that alone is not enough. This is because no matter how secure your password is, be it 20 letters long with various dingbats and 中文 characters, there is a weak link in this system. Or rather, two:

Your email is an obvious vulnerability: if someone was able to gain access to that, it would be trivial to reset your password for Facebook, YouTube, Meebo, etc.

What if you have a strong email password, you ask? In that case, we get on to the heart of the matter (which is also the most relevant to all those social networking users out there): secret questions.

Secret Q&As (SQAs) were initially a good idea: provide an alternative in case one has lost access to one’s email, or never set one in the first place. (as with Gmail or Yahoo) It presents an interesting problem, however: while the average netizine is unlikely to know the mother’s maiden name of dogggzlover98382374@hotmail.com, if even your name can be figured from your email address (or the attacker knows you personally), it is trivial to use sites such as Facebook and MySpace to find the answers to SQAs. A rather public example of this vulnerability can be seen when Sarah Palin’s email account was broken into last summer: all of the information needed could be found out using public records.

An example of a possible attack against Facebook in particular:

• Gain access to someone’s profile by either friend-requesting outright them or by masquerading as someone they know (and don’t already despise)
• Look for an email address on the profile or in wall posts.
• Visit their email provider and reset their email password via the information in their profile.
• Now reset their Facebook password. This will send an email to their address, which you already have access to.

This works against any site that uses a email-loop, even if it is well designed to avoid common SQAs. Social networking sites, however, are particularly vulnerable because of the wealth of personal information one shares freely on them.

This is because, as they are part of your personal history and not transactional, SQAs are almost always the same between sites. So, if you’re truly concerned about your information security: use something random for your SQAs and store them in a safe place.

Recently I got a notification on my Jaunty box that unattended-upgrades had crashed, and eventually trased the problem to apt-get: while I could update my sources I was unable to upgrade, apt would segfault while reading the sources list.

While I still have no idea what the cause was, the solution was a simple `sudo rm /var/cache/apt/*cache.bin`.

Sugar on a Stick (SoaS) is a great product in development at Sugar Labs which enables children to take the Sugar Learning Environment with them wherever they go. SoaS suffers from deployment issues in some use cases, namely that it can be difficult to manage a school full of them; the maintenance from having to update Sugar, back it all up, etcetera easily becomes an IT person’s nightmare.

I’m working on a series of projects to make the use of SoaS inside the school itself easier from a setup perspective, as well as solving the management problems I mentioned earlier. This solution comes in a few components:

• SoaS-helper – modified Fedora OS which runs on the school lab computers. When booted, it prompts the user to plug in a USB key containing their SoaS USB stick (which will work with *any* stick that has the proper files). After detection, it will set the user’s home directory to the loopmounted partition and start the Sugar environment as well as update the SoaS installation to the latest image. May also be extended to create USB sticks, or also allow local profiles to be created for users without sticks.
• SoaS-admin – system by which the SoaS-helper machines themselves are updated. Keeps a registry of all sugar sticks. (Key escrow maybe?)
• SoaS-emu – provides a GUI installer for SoaS’s appliance as well as for the SoaS-helper. This will install VirtualBox and configure it for Sugar, making Sugar very easy to demo in schools and at roadshows.

These are all currently in the planning stage, but expect an alpha of some of the components in a bit.

Over the course of my browsings I’ve often found a useful MIDlet on the internet that ships a JAR file, but not a JAD.

For some reason a few CDMA carriers have a pedantic policy whereas locked phones must use over-the-air-provisioning (OTAP) using JADs, being unable to extract the info they need from the JAR file themselves.  After a good bit of searching, I found an article on the Nokia wiki which explained how to properly create a JAD from the JAR’s manifest file.

However, if you’re lazy, you might just want to go to the automated JAD generator.

EDIT: http://rumkin.com/tools/sprint/index.php seems to do a better job than any of the above tools, with the added bonus of emailing a link to the JAD to your phone.

For those of you who missed the announcement a few weeks ago, the DC LoCo will be hosting an Ubuntu 9.04 “Jaunty Jackalope” bug jam at Gallaudet University in the Student Union Building.

The meeting will immediately follow that of the OLPC Learning Club, and we’re expecting some spillover. In addition to packaging mentoring offered by several Ubuntu MOTUs and Developers, we’ll be teaching basic QA during the event. Our *specific* QA focus is that of the Sugar packages for jaunty (which are being hammered out as we speak by Morgan Collett), but the bug jam aspect of the meeting will be more open ended.

Gallaudet University
Student Academic Center / Student Union Building (SAC/SUB)
Lower Level, Flex Rooms A and B
Saturday, February 21, 2009
10:00-13:00 OLPC LCDC
13:30-18:00 Ubuntu Bug Jam