July 23, 2009 - XO Web Sharing / Scratch

Jeff, with all of his experience with Scratch, has come up with a great idea for the further development of the Sugar interface.

Scratch is a programming and animation suite directed at younger children that teaches the basics of programming with a friendly, colorful interface. One of the most important features of this software is its "Share" utility, which allows the user to upload their project to the Scratch website for all to see and comment on, promoting shared learning and communication. When the Scratch file is received on the website, it is then recompiled into a Java applet and is thus usable from the browser.

In addition to the above features, users are then able to take their exploration one step further: by downloading the files for themselves. This allows them to read each other's code and remix each other's projects. This website/client relationship is really the foremost element of the Scratch project, as it provides the users with an integrated, positive environment in which they can share and present. Further, its accessibility over the web allows for what could easily become trans-national, or even global communication, crossing geographical and linguistic barriers with ease.

Jeff's idea is to implement this kind of technology by embedding it in the Sugar interface. Many of Sugar's most prominent activities lend themselves toward sharing and collaboration between children. As such, giving them an integrated collaboration system comparable to Scratch's would only work to expand and support the project as a whole.

Since Sugar 0.84, the user has been asked directly at the end of each session to name and describe each activity they've opened, in order to better organize and save their explorations in the Journal. In an IRC chat with Jeff, it was suggested that the "Name this entry" dialogue box be put to a higher use in setting metadata for works that would be published online, making it even easier for kids to share.

OLPC needs a website comparable to that of Scratch with which to host XO users' projects. This would be the fastest, most reliable method of connecting users and promoting collaboration. Of course, the scope of the OLPC web resource would need to be much greater than Scratch's. Scratch's website only needs to accept and display Scratch files (.sb's), whereas the Sugar site would be able to accept Sugar media of all sorts: "Write" activities, "Paint" drawings, "Physics" projects, and presumably games as well. These different types of media would first be categorized by filetype and then hopefully index by content or topic (Music, History, Science, etc.).

Further, user interaction would have to be both manageable as well as open. For example, students would be able to join Class groups, based on their actual Schools, and Classes. They would thus be able to receive updates about the activities of their group members and collaborate easily as a class. This would be a sort of "Priority" grouping, as the entirety of the user's activities would not be limited to sharing with just their class. In addition to this, users would be able to create groups, invite users, and engage in much of the collaborative networking currently available online.

The homepage of this website could show featured projects of various types, as well as category links, which would lead to content based on filetype (documents, pictures, etc.) or content. This content could of course be searchable, in order to connect the most users to the most relevant content.

The end result of this project would be a web interface, deeply intertwined with Sugar and its activities, that would connect an entire generation and unite them in the spirit of learning.

July 15, 2009 - XS Setup Cont'd.

In order to get the XS to qualify its hostname, its hostname had to be mapped in both /etc/resolv.conf and /etc/hosts. I implanted the following code into /etc/resolv.conf:

search ict.gctaa.net
nameserver 158.59.254.12
nameserver 158.59.255.11

("nameserver" refers to DNS servers, which feed the server web pages. The "search" command above is for the domain suffix, which I believe we needed for network routing.)

The following went into /etc/hosts:

192.168.209.254 schoolserver.ict.gctaa.net

With the hostname now resolved, ejabberd was finally able to run.

Next, we had to setup an administrative account on the Jabber server, via the following command ("admin" is the new username and "password" is the new password):

ejabberdctl --node ejabberd@schoolserver register user admin schoolserver.ict.gctaa.net password

The command given on the OLPC Wiki page didn't have the "--node ejabberd@schoolserver" bit. When I tried it, the command failed. Apparently, the node has to be specified (at least as long as it isn't localhost).

Next we had to grant administrative privileges to our new account (manually). This was done with the following line implanted into ejabberd's config files, /etc/ejabberd/ejabberd.cfg and /etc/ejabberd/ejabberd-xs.cfg:

{acl, admin, {user, "admin", "schoolserver.ict.gctaa.net"}}.

(Don't forget the period at the end of the line.)

For some reason, we couldn't connect to the web interface, albeit that we had an account, and a connection to the XS. Turns out that the hostname also had to be set in ejabberd's config files:

{hosts, ["schoolserver.ict.gctaa.net"]}.

The above line had to replace a similar line that had "schoolserver.random.xs.org" in place of our new hostname. (Again, don't forget the period at the end of the line.)

After all that, we were finally able to connect to the Jabber server via the administrative web interface at the following address (on port 5280, with the administrator's username behind it):

http://schoolserver.ict.gctaa.net:5280/admin/

This opened the (almost useless) Jabber web interface, from which we were able to create a Shared Roster Group with the following attributes:

Name: Online
Members: @online@
Displayed Groups: Online

The above attributes cause the server to show all connected users in a normal XMPP (instant messaging) client, such as Pidgin.



Pidgin really fits the bill perfectly here, since any user (like a teacher using the administrator account) can log on to the XS from their desktop and will immediately be able to see all of the students that have logged on. Furthermore, being that XMPP is a messaging protocol, the teacher can select any student from their "Buddy List" and send them a message over the server. This causes a Chat Activity icon to appear on the student's XO and thus enables private communication. It can then be postulated that the teacher could create a chatroom from Pidgin and invite all of the students to join, thus creating a unified chatroom from the teacher's desktop. The students can communicate and collaborate to their hearts' content, and afterwards a transcript of the chatroom can be saved on the teacher's computer for later reference.

A wee bit of troubleshooting:

Some of the XOs were initially unable to connect to the Jabber server. Connecting to the server requires two elements:

1) The XO must be connected to the same wireless network as the XS (in our case, the "sugar" AP at 192.168.209.1).
2) The XO's collaboration (Jabber) server must be set to the XS's hostname or IP address (schoolserver.ict.gctaa.net, or 192.168.209.254).

The first element can be achieved from the "Neighborhood" window on the XO, by clicking on the correct access point. The second element can be achieved in one of two ways:

From the Favorites (Home) view of the XO, right-click on the stick figure (I don't know a better word for it), and select "Control Panel". Click on "Network" and set the Collaboration Server to the XS' hostname.

OR

From the Terminal Activity, type

sugar-control-panel -s jabber YOUR.XS.HOST.NAME

(But I prefer the GUI tool.)

After ALL that, the majority of the XOs (with one faulty-hardware exception) were visible from a Pidgin client, and were able to receive and send messages to/from the admin account. Success!

July 7, 2009 - XO School Server

Today we began work on the XO School Server (XS) which Jeff needs for his students to be able to collaborate on projects. The server runs on Fedora 9 and is available as an integrated OS/XO script ISO image on the OLPC wiki.

The first thing we did was install the server (after much tampering with the box's BIOS). I named it schoolserver.ict.gctaa.net and gave it a static IP address by writing a new network script (ifcfg-eth0-local) and by editing /etc/resolv.conf.

The static IP address was set with the following code in /etc/sysconfig/network-scripts/ifcfg-eth0-local:

IPADDR=192.168.209.254
NETMASK=255.255.255.0
NETWORK=192.168.209.0
BROADCAST=192.168.208.255
GATEWAY=192.168.209.1

For the sake of later convenience, I commented out the original contents of resolv.conf and simply appended the new domain and (school) DNS servers beneath:

search ict.gctaa.net
nameserver 158.59.255.11
nameserver 158.59.254.12

Being that Jabber is going to be one of the main applications of this server, I set the ejabberd daemon to automatically start at boot:

chkconfig --level 345 ejabberd on

When trying to check whether Jabber was actually working or not after applying all these changes to the server, I received an error that I interpreted to mean that Jabber couldn't qualify its new hostname, which I will look into shortly.

Otherwise, everything went very well, and I expect great things for tomorrow.

June 8, 2009 - Karmic Server and Ethernet Fix

Upon installing Alpha 1 of Karmic Server, I faced a unique problem in that it was unable to connect to the internet.

Matt told me to use the following tools to diagnose the problem:

lspci (to look for a working Ethernet controller)
modprobe (to make sure the module is installed correctly)
ifconfig (to read actual network interface info)

From lspci's output, I could tell that there was an Ethernet controller installed.

Unfortunately, I still couldn't connect to the internet, and ifconfig showed only the loopback device as functioning.

I looked in /etc/network/interfaces to see if eth0 initialized and, from its contents, I had a sneaking suspicion that it had not:

auto lo
iface lo inet loopback

I added the following lines underneath:

auto eth0
iface eth0 inet dhcp

Everything works fine now. Sweet...

June 1, 2009 - Installing Fluxbuntu, Setting Repositories

After downloading the Fluxbuntu 7.10 ISO image from the Fluxbuntu release page, I burnt it to a blank disk. The image is about 306 MB. The first laptop I attempted to install on seemed to be working fine until I booted it up for the first time and gave me a screenful of cascading static. This led me to believe that its video card had finally reached the end of its life, and so I moved on to another laptop: a Compaq Armada.

The install went perfectly, and the machine seems to work fine, except for one buggy Up Arrow.

My first assignment was to re-enable my laptop to update, which involves finding the old Ubuntu 7.10 repositories and pointing my laptop toward them to fetch updates. My fix went as follows (thank you, Jeff):

Opening /etc/apt/sources.list, I found the first few lines had been commented out.

# Line commented out by installer because it failed to verify:
#deb http://us.archive.ubuntu.com/ubuntu/ gutsy main restricted
# Line commented out by installer because it failed to verify:
#deb-src http://us.archive.ubuntu.com/ubuntu/ gutsy main restricted

As it says above, these had been commented out because an attempted update had failed the very first time the laptop tried to connect.

Jeff found through his own development ninja skills where the repositories had moved to. This eluded me, because I didn't use the word "apt" in my Google searches. I edited sources.list to reflect the new location.

deb http://old-releases.ubuntu.com/ubuntu/ gutsy main restricted
deb-src http://old-releases.ubuntu.com/ubuntu/ gutsy main restricted

Lo and behold, it updated. Phase 1 of my Fluxbuntu adventure is complete.

May 18, 2009 - Wireless Printing

The printer's been acting up again. When we first installed the printer, it connected wirelessly to our router, and thus to the rest of the house. Unfortunately, this was a remarkably slow, unreliable connection. In the original instructions for installation, it gave us three choices: 1) connect via USB to the computer, 2) connect via Ethernet to the computer, and 3) connect wirelessly.

The manual was incredibly poorly written (and the hardware was incredibly poorly made).

Our intent was to install this printer (the HP Photosmart C309a described earlier) in the kitchen and put it on our wireless network, and thus have everyone in the house connected to it. With this in mind, we looked at our three options.

Option 1 was unacceptable because it meant only my mom's computer would be connected to the printer. Option 2 was described as only working in a 1:1 connection (one printer connected to one computer). This was unacceptable for the same reason. Option 3 was described as the only one that could work for our situation.

The wireless connection was so slow that when any of us tried to print, we would stare blankly at the printer for 4-5 minutes, waiting for any signs of life. After this inordinate wait, the "Now Printing" alert would pop up, and it would take about a minute of actual printing to get the finished product. My mom was so dissatisfied with this performance that she wanted to commandeer the printer solely for herself, being that it would print faster over a wired connection.

To solve the problem, I plugged the printer in via Ethernet to the router, which kept it broadcasting.

This caused the printer to change IP addresses, so after re-finding it on all of our computers, printing resumed. Print speed picked up by about 200%, and happiness returned to the Eddy household.

May 13, 2009 - Fluxbuntu

The Fluxbuntu project has been around for several years now. This Linux distro is best known for being versatile and light-weight, requiring very little in the way of memory or CPU power.

This distro puts fast, simple computing ability into the realm of possibility for older machines, which have a terrible tendency to get scrapped at the first sign of trouble. The main reason for this is Fluxbuntu's bloat-free software accessories and the Fluxbox display manager, which runs several orders of magnitude lighter than Gnome, KDE, or Xfce.

Jeff and I have recently contacted the Fluxbuntu team, with the hope of putting me to work developing a Linux distro. I believe we spoke with project driver Joe Jackson, who encouraged our participation.

Fluxbuntu was last released for Ubuntu 7.10, and as such is obsolete. Were the project to be revitalized and a Hardy release to come out, the project would be able to hold up on normal LTS updates until the release of Karmic Koala, becoming an LTS-only project. This would be much more sustainable, as the Fluxbuntu team is currently short-handed.

It is my hope that the Fluxbuntu team will have some use for my meager Linux skills, and that if nothing else I am able to provide support, even if a new release is too far off.

May 13, 2009 - Jaunty and X

I recently took a peak at the Ubuntu-X Team's page on the Ubuntu Wiki. I've been told that Jaunty handles XConfig differently than Intrepid or any of the other releases. Unfortunately, I'm an X novice and so can't see any discernible difference between X now and X then. xorg.conf seems to remain the central setup, and it doesn't seem that there are any new programming parameters for it. The greatest change seems to be the new "automagical" behaviors that ship with Jaunty.

Hotplugging

One of the greatest achievements made with X seems to be "input-hotplug," which should automatically configure new devices. If this doesn't work out, though, "xinput list" seems to be the fastest output for X device issues. The Ubuntu-X team describes this particular process like this:

"Historically, X probes input devices on X startup, so devices attached subsequently may not function. To overcome this in situations like a laptop with external mouse, the kernel emulates a PS/2 mouse at /dev/input/mice (or /dev/psaux) with events coming from ANY mouse connected to the system. This mostly works, but doesn't handle multi-protocol situations perfectly (other protocols can be translated, but some events can be lost in the process)... Without input-hotplug, all input devices need to be configured in xorg.conf, thus adding a new device or reconfiguring a device would require an X restart."

Manual Configuration

Not everything has been automated as of yet, though. "Virtual" framebuffers, such as dual-screen output, need to be defined manually in xorg.conf (which, I will attest, is a veritable impossibility for casual home users).

DontZap and Sticky Keys

In addition, die-hard X users will notice that CTRL-ALT-BACKSPACE does nothing now (Wha?!). The Ubuntu-X team describes their reasoning for this revision:

"The DontZap option in the /etc/X11/xorg.conf file enables or disables the CTRL-ALT-BACKSPACE shortcut to restart the X-server. In previous Ubuntu releases, this shortcut was enabled by default, however this will change starting with 9.04 "Jaunty", as a number of users have complained about accidentally restarting their X-Server."

The fix for this is simple, though.

Sticky Keys is part of the impetus for this revision. Holding down the shift-key for 8 seconds enables Sticky Keys, making the CTRL key "sticky," for the purposes of keyboard shortcuts. Apparently, a sizable number of people enable this option, then accidentally restart their X-Servers.

There's probably more to the new X configuration than I've flushed out. More to follow.

May 12, 2009 - Sparticus and ParanoidLinux

I recently happened onto a book called Little Brother, by Cory Doctorow, which inspired me to theorize a wee bit on Linux and its place in our future. The book is somewhat of a remake of George Orwell's 1984, but remixed for the modern day, and heavily focused on technology. Specifics about the book aside, there is a mention in the book of a new-age operating system (the main character's favorite): ParanoidLinux.

There's one pertinent quote in the book that describes the idea behind this distro:

"ParanoidLinux is an operating system that assumes that its operator is under assault from the government... and it does everything it can to keep your communications and documents a secret. It even throws up a bunch of "chaff" communications that are supposed to disguise the fact that you're doing anything covert. So while you're receiving a political message one character at a time, ParanoidLinux is pretending to surf the Web and fill in questionnaires and flirt in chat-rooms. Meanwhile, one in every five hundred characters you receive is your real message, a needle buried in a huge haystack."

Now, the idea may be a little outlandish, but I am thoroughly supportive of it. In fact, after reading the book, it occurred to me that I may not be the only person in that situation, and hence found the real ParanoidLinux project. (What's more: it's an Ubuntu derivative!!!)

I kept digging after I found out about this distro-in-the-making. Unfortunately, the project seems to be stagnating due to a lack of interest and a lack of developers. A search for ParanoidLinux returns copious amounts of forum posts discussing the idea, which is apparently taking a lot of heat.

The main issue universally had is possibly best characterized in an article I found on OStatic:

"[T]he project feels a like a waste of human resources -- why is it necessary to put the applications and services designed to protect anonymity, to encrypt files, to make the user nameless and faceless, all together, in one distribution? Let's think in a truly paranoid manner. Wouldn't it be far easier for a nefarious government organization to target that distribution's repositories, mirror that singular distribution's disk images with files of its own design, and leave every last one of that distribution's users in the great wide open? It would take more effort, it would seem, for a despotic goverment to hit every last repository of every last distribution with a bogus security application."

I support most anything that defends the privacy and civil liberties of the people, which is why I am so enamored with the project and so reverent towards the few developers working on it. But it occurs to me that ParanoidLinux would be, in and of itself, a veritable bullseye painted on the back of any paranoid, security-conscious user, such as myself.

The problem hearkens back to the tales of old: Sparticus. Any distribution of a distro that was inherently paranoid would have to be done on a massive scale. Among uniformed civilians, people wearing red stand out. But among people wearing red, nobody stands out.

It is this kind of solidarity that has been the vanguard of Linux development: Ubuntu has long been called the best distribution not for its technical prowess, but for its (massive) community of developers and the wealth of helpful information available to users.

With enough users, ParanoidLinux would make "paranoia" the norm; complacency might even become an outlyer.

The proud and the paranoid face a unique logistical problem then. ParanoidLinux would be almost impossible to ship in the necessary quantity to overwhelm mainstream computing. Though this distro may be doomed to fail, paranoid packages might work out instead. In place of the outwardly provocative idea of a devotedly paranoid distribution, an inwardly secure, but popular, distribution would bring the best of all worlds.

The quote from OStatic above really lays it all out. Paranoidbuntu packages would be able to fortify already Jaunty-riffic desktops. SneakyDebian repositories would bring such advantages to Debian users. "BlackHat" rpms for Fedora would help, too. The more the merrier!

The peak of security comes from invisibility. ParanoidLinux is too bold, and serves only the idea of a massive underground community. Normal users need to protect themselves as well, and cannot be bothered to wait for en masse distribution. "Plain-clothes" distros are the easiest to fortify, and the most difficult to subvert.

Fortunately, most of the technologies that would ship with ParanoidLinux are already in existence (and, more importantly, in the Synaptic repositories). Everything short of chaff net traffic is already at the disposal of the casual user.

Now we just have to teach people to use these great tools, and privacy starts to protect itself.

May 10, 2009 - Printer Installation and Linux DJ-ing

This last week I've been busily applying my tech support skills around the house. We recently purchased an HP Photosmart C309a printer to replace our old Photosmart C7100. Upon its entering the house, I was tasked with setting it up. The technology must be rapidly advancing, because this new printer was able to connect to our router wirelessly, as opposed to the older model, which was only able to broadcast via wired connection to the gateway.

My laptop (a solid Linux machine) was the first to find the new printer, and so the first to send a victorious test page. The Linux printing utilities (ie, System > Administration > Printing) are remarkably advanced.

My parents' machines (a Windows Vista desktop and XP laptop, respectively) were not so able-bodied. My mom (using the Vista desktop) installed the new printer (with the included disk, and none of the auto-detection or online download utilities native to Linux) on her machine and was (after an inordinate amount of time) able to print.

My dad (on his XP laptop) was entirely unable to connect. He put the disk into his machine and followed all the same steps as my mom, but the installation consistently stalled out about halfway there. All of my attempts to remedy the situation failed, and so we took the drastic route of hosing his computer, which was filthy with Windows malware. After the reformatting, we were faced with an opportunity to upgrade him to Vista (Linux was apparently out of the question). My mom has wanted him to do this for a while, so we took the opportunity as it presented itself.

Vista (looked like it) worked. The install was painless enough, and my dad was able to print, but he had lost all of his audio capabilities. "No Audio Devices Installed" is a particularly disturbing notice, especially when the speakers are sitting in plain sight on either side of the screen.

Utterly baffled, we turned to Dell's Tech Support, which was surprisingly helpful. We were told, plainly and simply, that there were no device drivers written for Vista that worked on my dad's particular laptop. Saddening as this was, it did prevent several hours of painstaking patch-hunting. Once again, we hosed his laptop. 32-Bit XP was probably the sturdiest OS Micro$oft ever wrote.

Trouble follows my dad.

This time, we've got printing, we've got sound, and have no Internet. This is eventually solved by a call to Earthlink, but is nonetheless disconcerting. From this point on, my dad's computer is (basically) okay. My mom's, of course, takes a nosedive, losing Internet. She fixed this herself, though.

In other news, I've put Ubuntu to the test DJ-ing a dance. This last Friday, we held a dance in the cafeteria and operated entirely off of my laptop. This experience has brought several pieces of software to my attention:

First and foremost, Rhythmbox, which is solid as a rock and basically cruft-free. I've fallen head-over-heels for this music player, which will not only play but visualize music files (I assume in every filetype, though I haven't had an opportunity to test this).

Mixxx, the Linux DJ-ing instrument of choice, which is actually cross-platform. This mixer was able to give me total control over the mixing of my songs, though DJ-ing directly from this turned out to be overly labor-intensive.

Ubuntu screensavers are by far the best I've ever seen. The reason I found this out was because I was unable to project the visuals from Rhythmbox through the school projector we were using.

Our original plan was to project Rhythmbox visuals over a serial cable through a standard school projector. We had already made a final playlist with all of our desired songs on it and set it to shuffle while the Visualization function was engaged. What happened was my screen was projected entirely, except for the actual visual. The Rhythmbox window was there, but no visual, only a blank space. I tried to adjust what screen was projected, but this was of no use, and we eventually scrapped the Rhythmbox visuals and backed up on a couple of especially flashy Ubuntu screensavers. I believe that this projection problem was an X-related issue, but I couldn't for the life of me figure out how to fix it.