News

Posted by Stephen Saville on 10 Apr 2003 % 2:11

Its been awhile since we presented QuuxBox at engineering open house, and we've been spending that time both recovering both our sanity and our grades. Finally, we got our chance to choose a license, find some free fonts, and clear QuuxBox for an early release. What you see is close to the EOH version with a few tweaks and now using freely-distributable fonts. We decided on GPL as the license since we couldn't think of a use of our code that would violate GPL and still be in line with the developer's intentions. Look at the download section to get the source code.

Posted by Stephen Saville on 26 Feb 2003 @ 22:17

Now comes the final stretch of QuuxBox development before Engineering Open House, where it will make its official debut. The runtime and libraries will be put to the ultimate test over the next few weeks as we switch focus towards writing applications. Currently, one application is written and mostly working, an audio cd ripping app that takes music from a cd and stores it in a compressed format on the QuuxBox hard drive. Also, a chooser application, which presents a menu for the user to select an application from is also written, but not yet working. Application programming is pretty straightforward and should progress quickly over the very few days remaining before we must present the project. After EOH, we will lock down for an immediate release, whatever state the project is in, and then work on bugs and performance improvements for a later release. The CVS will most likely move to a more public server like SourceForge at that time so its easier to allow access to outside developers.

Posted by Stephen Saville on 17 Feb 2003 @ 12:11

We've had the quuxbox hardware for about a week now and we have sound and video working under Linux. We've run into difficulties getting the video capture / tv card to work, and the ati drivers won't let us do xv, which is bad for playing DVDs. Also, the onboard network adapter seems to have played out. Aside from those issues, the big problem is power. We got a nice Cubid 2699R case, because its small and quite, but we quickly discovered that the included 60W power supply is not enough to power everything we have connected to it. Currently, we have the hard drive and dvd hooked up to an external AT power supply to lessen the load on the low power one, but we're looking for a better solution. A 100W internal supply would probably be enough, since at 60W everything works . . . for awhile. Software development is also progressing.

Posted by Stephen Saville on 30 Jan 2003 @ 3:03

Well, Monday's QuuxBox talk went pretty well and we got a lot of good information out to developers. A few other extra people also showed up for a while to check out the project. I talked about the QuuxBox runtime system using slides now posted on the sigunix workshops page. Also, Andrew Lusk elaborated on my talk with a demo and explanation of the FrontEnd component he's working on. Recently, I started working on a window manager to handle the windows of X applications we'll be using. The manager is based on plwm and already has some pretty impressive functionality. When I get the chance to update the installation instructions and READMEs I'll post a new snapshot of the source so people out there can get in on the action.

Posted by Stephen Saville on 27 Jan 2003 @ 16:56

Tonight's QuuxBox talk has move to a new location:

1310 DCL (lecture hall next to 1320)
8:00 pm, Monday 27 Jan 2003

Hang around 1225 before 8:00 pm if you don't know where this is.

Posted by Stephen Saville on 20 Jan 2003 @ 23:59

This coming Monday, 27 January 2003 at 8:00pm during the regular SIGUnix meeting, I will be giving a talk introducing the tools and concepts behind QuuxBox and its associated runtime. This will be a great time for new developers to get up to speed on what's already been written and what's in the works. Also, the talk will include a thorough explanation of the QuuxBox Interprocess Communication API starting from general ideas and progressing to some concrete examples of its use, as well as what it will mean to write a QuuxBox "Application". The talk should prove interesting for those following the project and essential for those who want to contribute. Be There!

Posted by Stephen Saville on 10 Jan 2003 @ 5:17

The download page has been edited and a link to a cvs snapshot is up. There are also installation instructions for that snapshot on the new install page. I would encourage anyone planning to do QuuxBox development to try those instructions with the cvs tree. Note: do not edit config.xml inplace with your personal changes. Make a local copy in ~/.quuxbox instead. The local copy will be opened by install.py inplace of the copy in the package directory. We don't want your personal layout in cvs.

Posted by Stephen Saville on 3 Jan 2003 @ 19:00

A lot has been developed before this website got put up, so here's a summary of what what news would say if we started at the beginning, minus the initial indecisiveness, of course.

So what's up with QuuxBox?

Much has been done since the idea for this project initially came out of Andrew Lusk's mouth during a SIGUnix meeting back in September 2002. I, Stephen Saville, started thinking of how such a feat could be pulled off just a bit after the idea was hatched and came up with a runtime architecture on which QuuxBox is being built. I noticed that while other projects, like freevo had nice graphics, when it actually came down to controlling external media apps (i.e. doing neat stuff), they faltered (granted the only one I tried was freevo, its the only open source one I knew existed). So, what I wanted to do with QuuxBox was to build a system that would make it easier, and more straightforward, to curb such flakiness. Thus the idea for a deliberately multitasking runtime.

QuuxBox stands apart from other Open Source ventures is that it admits the fact that a complete media system must perform several tasks simultaneously. That is taken care of by spawning multiple processes and letting Linux handle the rest. However, different processes will need to talk to one another in order to coordinate their actions, and there must also be some standard way to start and stop processes. Thus was born the need for a solid RPC (Remote Procedure Call) mechanism and some sort of process abstraction.

The process abstraction in QuuxBox is objects, implemented using Python's rich class system. Each process the system, or some application, will use is defined within a class. This class includes code which will be called over an over (supposedly to do something useful), but that is not all. The class also may designate some of its methods as "remote methods". Remote methods may be called at certain times by other running processes. Such remote procedure calls are implemented using Unix domain sockets.

So how does this all work?

Well, the remote procedure calls are implemented by sending datagram packets between different Unix domain sockets on the machine running QuuxBox. Arguments and return values are passed using Python's pickle mechanism for object serialization and the API implements control logic to turn these messages into actual method calls at the receiving end. Yet that is not the whole picture, for processes must first know about each other to call methods on one-another.

The AppServer

The AppServer is a long-running process that keeps track of what processes are running at any one time and hands out such information when processes request it. Processes may query the appserver to learn how to communicate with currently-running processes offering a certain functionality by asking for the process by class. Also, the appserver allows processes to start and stop other processes given the class to use. Classes in QuuxBox are distinguished by classid, a 64-bit integer value that is mapped to a class name.

The EventServer

Still, one-on-one communication is not the only way that processes may want to talk to each other. Sometimes, some processes may want to shout out information to anyone who's listening. One possibility would be a process that monitors the status of the dvd-rom drive and would like to tell all those interested when some media is inserted into the drive. In QuuxBox, this is an event which gets sent out to the system at large. Then, any process may select which events it wants to hear and those will be sent to it. There is another long-running process called the EventServer, which handles relaying events between processes. All events get sent to the EventServer, and the server implements remote methods allowing processes to choose which events they will receive.

Is that all?

Well, that's what's been implemented so far, but the full QuuxBox system will include a few more components in addition to the applications (DVD Player, CD Ripper, JukeBox, and more) that we will write. Currently, a configuration and installation system is being finished up, and then several other tasks are on the agenda. These include a logging system (possibly including a daemon) to intelligently keeps tabs on what's up, as well as an init mechanism to bootstrap the system when it starts up, and finally the all important frontend system. This will be the component that controls access to the display and allows user interaction. Application authors will write frontends for their apps and this component will select which one gets displayed onscreen and becomes the target of events. The Frontend is integrated tightly with other components and has been waiting on the more basic parts to get finished before its final design is laid out. Now, it is time for this component to come out. That will be the next major step in the process of development.