|
|
|
|
|
|
|
|
Last fall, several companies in the newly emerging embedded Linux market approached me to request that I help create a vendor-neutral Embedded Linux trade association. Initially, I used the resources of my newly established Embedded Linux Portal web site (http://www.LinuxDevices.com/) to propose the establishment of a group called the ``Embedded Linux Consortium'' (ELC). The idea for the ELC rapidly picked up momentum.
Next, I scheduled an ELC organizational meeting to be held at the Chicago Embedded Systems Conference in March. The purpose would be to create a formation committee to fund the ELC and share responsibility for it until it was incorporated and a proper Board of Directors was elected.
March 1 came, and the ELC organizational meeting drew an overflow crowd--nearly double the expected turnout. We could instantly see that the ELC is destined to be a major force in the embedded market. During the first hour of the meeting, more than $100,000 was pledged to initially fund the organization. Also, Lineo donated the domain name, embedded-linux.org.
A week later, the birth of the ELC was broadcast via a press release that received extensive worldwide coverage (read it at http://www.embedded-linux.org/). The announcement lists the Formation Committee members, summarizes the organization's goals and includes this supporting statement from Linus: ``This new Embedded Linux Consortium is an expression of the current explosion of interest in using Linux in thousands of specialized embedded, mobile and appliance applications. The ELC provides a valuable resource in advancing the growing use of Linux in embedded applications, an area where Linux can provide enormous benefit.''
Although official Vision and Mission statements will be established by the soon-to-be-elected Board of Directors, I indicated my thoughts on the subject in an ``ELC Manifesto'' posted at LinuxDevices.com and distributed at the ELC organizational meeting:
We currently plan to have three membership categories: Corporate Executive Member ($5,000 per year), Corporate Affiliate Member ($1,000 per year) and Individual Member ($150 per year). Recognizing there are many individuals who contribute to the open-source code base which is the basis of Linux itself, I've also proposed that the $150 annual membership fee for Individual Members be waived in the case of individuals who have contributed significantly to the open-source code base.
The ELC's activities are likely to be along two main threads: technical and promotional. It's likely (although not required) that the Individual Members will be focused mostly on technical activities, whereas promotional and marketing activities will probably be more of a concern of the Corporate Members and, appropriately, funded primarily by them.
On the promotional side, I expect we'll have a marketing task force concerned with evangelizing embedded Linux. Most likely, there will be a web site, PR, trade shows, collateral materials and membership growth.
The technical role of the ELC is less clear than the evangelical role, in light of the enormous success the existing open-source development process has had in bringing Linux (and its related technologies) to where they are today. Nonetheless, it is certainly possible that technical committees or special interest groups will coalesce around issues of interest to multiple ELC members. Whether these translate into standards activity remains to be seen. In any case, the existing Linux and open-source development process must be supported, not circumvented or undermined.
The ELC is now officially incorporated as a non-profit trade association in the state of California, and has the beginnings of a web site in operation. For the latest ELC news and info, or to obtain a membership application, visit http://www.embedded-linux.org/.
--Rick Lehrbaum
Brian Behlendorf is one of the chief software architects behind the Apache project and is the instigator of SourceXchange. This project provides a method for programmers to get paid while writing open-source software. As such, we would like to see it succeed. We talked with Brian by e-mail at the end of March to see how things were progressing.
Margie: SourceXchange started as a project of O'Reilly and HP, and then was spun off as Collab.Net. What was the reasoning behind this move?
Brian: I incubated the ideas behind the company while employed by O'Reilly, and worked with people there to develop a business plan, which we then shopped to a couple of investment firms. After selecting Benchmark, we spun the company out into its own entity, and I moved to CTO when we found a CEO.
It was always the plan that I would be working on some ideas at ORA, and then we'd spin them out when there was sufficient interest. There was much more interest much sooner than we thought there would be. SourceXchange is one service of Collab.Net--there will be more.
Margie: Do O'Reilly and HP still participate?
Brian: Yes. Tim O'Reilly is on our board, and we have lots of communication with ORA. HP is still involved as a sponsor in SourceXchange and is also involved in some of our additional products. They are the first customer of our open-source project hosting infrastructure, on which their new web site (http://www.e-speak.net/) and open-source project sit.
Margie: Has the change proved of benefit to the project?
Brian: Becoming our own company has helped us hire the people we needed to, and focus more deeply on this as a business, which we feel it needed to be long-term.
Margie: Tell us exactly how SourceXchange works.
Brian: Well, the http://www.sourcexchange.com/ site goes into quite a bit of detail on this, so I won't repeat what's said there. The short answer is:
Sponsor submits an RFP (request for program)-->Developers submit proposals/bids on that RFP-->Sponsor selects a proposal.-->Project begins.-->Developers work towards a milestone, then upload their code.-->Sponsors review it and approve or disapprove.-->If they disapprove, developer keeps working until the sponsor is happy, or until a peer reviewer says the milestone is met.-->Repeat until all milestones are approved and project is completed.-->Sponsors, developers and peer reviewers rate each other.Margie: How many programming projects have actually been finished? Which ones?Repeat. =)
Brian: Two--the Generic Data Packet Recorder, sponsored by Sparks.com and completed on 2/18/00; and a Test Suite Framework for the Apache Web Server, sponsored by HP and completed on 11/20/99. For details, see http://www.sourcexchange.com/ProjectBrowse?Button=Search&browse_status=Completed&browse_status=Archived.
Margie: What is the biggest project to be finished at this time?
Brian: Both of them were $5,000 US projects, but there are now some in the $25,000 US range in the system.
Margie: Which project have you personally been the most interested in?
Brian: The test suite for Apache was fairly interesting to me. Right now, the most interesting one is probably the Apache 2.0-related handler (Listener Module) for a protocol called BXXP, sponsored by Invisible Worlds (project #13). I've also got a project of my own I'm pretty happy about, a Java servlet- and WebMacro-based browser for UNIX mbox-format mail archives, sponsored by Collab.netproject (project #11).
Margie: Does SourceXchange take up all your time, or do you still get to do some programming?
Brian: Collab.Net in general, as well as doing all the political and back-end work for Apache, consumes most of my time. I haven't done serious programming in a long time, but still write the odd Perl script each week.
Margie: Obviously, you are still involved with Apache. What's going on there?
Brian: Tons--ApacheCon was just completed and was a resounding success, with over 1000 attendees and some great sessions. Apache 2.0 is in alpha. XML and Jakarta are taking off.
Margie: Do you feel the SourceXchange project is a success? (Are programmers actually getting paid?)
Brian: Yes. There is over $300,000 in the system right now for developers, and it's just the beginning, really.
Margie: Do you see this project as leading the way for how all programming will be done in the future?
Brian: No, but it will be an important component. Sometimes you are willing to trade off quality and correctness for determinism and speed, and thus you need in-house developers. Sometimes the software you're developing needs to be done in-house for proprietary reasons. I'm not one to state that all software will be free in the future, although I think most of it will be.
Margie: What do you see in the future for open-source software and Linux?
Brian: Great things. Further expansion. As software becomes infrastructure, it becomes commoditized, and open-source software is the most stable state of infrastructure because of its ubiquity and low cost to use.
Margie: Anything you'd like to add?
Brian: Not really; I've done an awful lot of proselytizing over the last few years, and now feel a need to turn that energy toward making sXc and other Collab.Net projects a success, so I've been more quiet recently.
Margie: To wrap up, how about some personal-type information?
Brian: I've been married for almost five years, have a house in San Francisco, am really into DJ'ing ambient and dub music, use a Sony Vaio C1-XS as my laptop, drive a Jeep, and enjoy microbrew root beer.
Margie: Thanks very much for taking the time to answer our questions. --Marjorie Richardson
``I'll say this about Linux: it's the first time I've seen UNIX on the right platform.''
--Steve Ballmer, Microsoft
``No marketing organization can withstand the effects of a community which generates an ever increasing number of effective advocates.''
--Russ Pavlicek, Compaq
``There's an opportunity for China to play a significant role in the Linux world... That certainly could allow China to take its place on the world stage as a software-producing country.''
--Dan Kusnetzky, International Data Corp.
``I'm glad IP isn't IP.''
--Dan Lynch, in a meeting about the Internet and patents
In April, Netcraft reported that over half of the exhibitor companies at the last Linux Expo in London were running Microsoft IIS web servers (which runs on Windows 95, 98 and NT) rather than Apache or some other appropriate server on Linux. Among other interesting discrepancies, Netcraft noted these:
Other items:
--Doc Searls
Mandrake held its number-one position in total downloads (measured in MB) from Tucows in March. Even though it's down a couple of points from its January high, it still accounts for over a third of the downloads total. Red Hat held even with 15% at #2. Corel slipped a point to 12% in the #3 spot. Phat Linux dropped three points, but still held the #4 position at 10%. Debian and SuSE follow with 5% apiece. The rest are between 3% and 1%.
What were Linux people talking about in March and early April? Below is a sampling of some of the hotter news stories over the past few weeks, as reported in ``The Rookery'', Linux Journal's on-line source for news, notes and reports from the field (updated daily and found at our web site http://www.linuxjournal.com/):
Hello, and welcome yet again to another episode of Stupid Programming Tricks! Last month, which I hope you didn't miss, we got a wee bit complicated, making a sine scroller by plugging sine functions into each other. The process involved lots of variables and functions, and really taxed the processor. This month, it's time to relax a bit from complicated things, but nevertheless we'll do something cool, and it will involve sines.
Former demo-sceners may have noticed a trend in this column: that much of what we do is passed down from a certain tradition. Where is the 3-D <\#224> la Quake? Where are the filled vector graphics? Where are the trippy acid effects? Alas, your amiable author missed the PC scene for a short-lived adventure in, well, something else, before discovering Linux, so we still believe a demo should have a scrolltext and that 2-D is okay. Now, we've done more with scrolltexts than most people can stand; however, there is a tradition just as ubiquitous as the scrolltext, and probably even easier: the raster bar.
A raster graphic is basically a bitmapped graphic (as opposed to a vector graphic), thus a raster bar is a bitmapped graphic of a bar. Usually we draw these bars with cool, shaded colors, so that they look like horizontal pipes or laser beams, and we make them bounce up and down on the screen, which looks rather cool. What is the point of such bars? There is none! Well, actually, sometimes it's to show off the computer's colors; sometimes to delineate different areas of the screen; sometimes it's just to add something interesting and technological to look at. When the palette is properly set up, the bars can look like shiny metallic pipes or perhaps glorious rainbows. You can even scroll the colors inside of raster bars for all kinds of funky effects. You could sync the color scrolling to the vertical position of the bar, as though the passing raster bar uncovered hidden colors in the screen. You could cycle the colors in numerous ways inside the bar (turning blue pipes to purple, red, orange, yellow, green and back to blue), or you could pass colors between several raster bars on the screen.
Another clever trick is to include a scrolltext inside of a raster bar. This has numerous advantages; for one thing, you don't have to worry about making sure the background shows up properly in the black space underneath the letters, since you're filling the whole thing up with raster color. You don't need to clean up areas before writing with raster bars, because the bars overwrite whatever's there initially. And, the colors of the raster bar can highlight the text like a high-energy laser beam.
One influential demo for me on the Amiga was Hot Copper by Acro of Rigor Mortis. It used several large raster bars of different colors scrolling up the screen and then falling down again in order to display several different scrolltexts of varying speeds with different text. In the days before the Net as we know it, words were rare and meant much more; scrolltexts were like messages in bottles found at the beach, greetings from faraway shores, by people you actually knew! How did the text travel so far? Who passed what disk to whom at what party, how many boards did it go through, how long until it got to you? If only Amiga emulation weren't so harassed by copyright zealots, we'd have a more open time enjoying these (the Amiga ROMs are still copyrighted, but at least the demos aren't). Alas, I degenerate.
We're going to make six bars, each 320 pixels wide by 17 pixels high. Each bar will get to use nine colors, running from darkest at the top to lightest in the middle and dark again at the bottom (that's eight colors which get used twice in each bar, with one bright color right in the middle). This makes the shiny, pipe-looking effect for our bars. In honor of Roy G. Biv, we'll have red, orange, yellow, green, blue and purple bars, even though logically we should use red, yellow, green, cyan, blue and purple. Of course, cool Commodore coders made rainbow bars, but they're too cool for us. Still, we are fairly daring in our own right; after all, we're using ``runs-as-root-can-really-destroy-your-system'' SVGAlib. Let's look at our algorithm.
Step one is to draw the bars. We'll make six arrays to store our six different bars: redbar, orangebar, yellowbar, greenbar, bluebar and purplebar. We could dynamically allocate the memory, but why bother, since we already know the size of our graphics? Well, it's in case we change graphic size, but let's be lazy this time around. First, we have to set the palette properly, so we'll do nine shades of red, nine shades of orange, nine shades of green, nine shades of blue and nine shades of purple. A simple loop fixes this, rendering 54 colors total, starting at palette color #192, because it's nice to save the earlier palette colors in the event we add something else. Once we've set the palette, we draw the red bar in red color, store it in the redbar array, then loop through and do the same for the other colors. When we're finished, we'll have six bars in memory, ready to be blitted wherever we like!
Step two is to draw the bars on the screen in our never-ending loop of joy. We'll set a loop that increments a variable called X, needed because the vertical positions of our bars will be based on a sine function of X, shifting the phase a bit for each bar so that we get a wave-like effect (instead of having every single bar on top of the other). We'll draw the bars, starting with purple and working toward red, hold the screen still for a vertical refresh (usually 1/60th of a second), then clear the screen and repeat the loop until someone exits.
Raster bars, alas, have little practical value; in fact, they're an epitomic cliché, but I sincerely hope we can continue this cliché into the 21st century and beyond. Perhaps we should put raster bars in rocket ships and send them out into the galaxy as evidence of our civilization...
--Jason Kroll
// gcc -Wall -O2 raster.c -lvgagl -lvga -lm
#include <vga.h>
#include <vgagl.h>
#include <math.h> /* sines! */
#include <stdlib.h> /* malloc */
#define GMODE G320x200x256
GraphicsContext *virtualscreen;
GraphicsContext *physicalscreen;
{
char *redbox, *orangebox, *yellowbox;
char *greenbox, *bluebox, *purplebox;
char c, d; /* to keep track of color */
short int x; /* a counter for our sine */
vga_init(); /* start svgalib */
gl_enableclipping(); /* just in case */
vga_setmode(GMODE); /* set mode */
gl_setcontextvga(GMODE);
physicalscreen = gl_allocatecontext();
gl_getcontext(physicalscreen);
gl_setcontextvgavirtual(GMODE);
virtualscreen = gl_allocatecontext();
gl_getcontext(virtualscreen);
/* Allocate the memory for our bars! */
redbox = malloc(WIDTH*17*BYTESPERPIXEL);
orangebox = malloc(WIDTH*17*BYTESPERPIXEL);
yellowbox = malloc(WIDTH*17*BYTESPERPIXEL);
greenbox = malloc(WIDTH*17*BYTESPERPIXEL);
bluebox = malloc(WIDTH*17*BYTESPERPIXEL);
purplebox = malloc(WIDTH*17*BYTESPERPIXEL);
/* set up the palette! */
c=0; /* red */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
7*d, 0, 0);
c=1; /* orange */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
7*d, 3.5*d, 0);
c=2; /* yellow */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
7*d, 7*d, 0);
c=3; /* green */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
0, 7*d, 0);
c=4; /* blue */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
0, 0, 7*d);
c=5; /* purple */
for (d=1; d<10; d++)
gl_setpalettecolor(191+c*9+d,
7*d, 0, 7*d);
/* Now is when we draw the bars! */
for (d=0; d<9; d++) {
gl_hline(0,d,WIDTH-1,192+d);
gl_hline(0,16-d,WIDTH-1,192+d);
gl_hline(0,17+d,WIDTH-1,201+d);
gl_hline(0,33-d,WIDTH-1,201+d);
gl_hline(0,34+d,WIDTH-1,210+d);
gl_hline(0,50-d,WIDTH-1,210+d);
gl_hline(0,51+d,WIDTH-1,219+d);
gl_hline(0,67-d,WIDTH-1,219+d);
gl_hline(0,68+d,WIDTH-1,228+d);
gl_hline(0,84-d,WIDTH-1,228+d);
gl_hline(0,85+d,WIDTH-1,237+d);
gl_hline(0,101-d,WIDTH-1,237+d);
}
/* copy the bars to our arrays */
gl_getbox(0,0,WIDTH,17,redbox);
gl_getbox(0,16,WIDTH,17,orangebox);
gl_getbox(0,34,WIDTH,17,yellowbox);
gl_getbox(0,51,WIDTH,17,greenbox);
gl_getbox(0,68,WIDTH,17,bluebox);
gl_getbox(0,85,WIDTH,17,purplebox);
/* the main loop. This severely and
* inefficiently burns CPU but we're
* feeling sadistic on the chip today.
* 12 raster bars is a lot, so comment
* out a few if your computer grinds
* to disastrous effect.
*/
for (x=d=0; d==0; d=vga_getkey()) {
x++;
gl_putbox(0,40*sin((x+0)/24.0)+40,
WIDTH, 17, purplebox);
gl_putbox(0,40*sin((x+10)/24.0)+40,
WIDTH, 17, bluebox);
gl_putbox(0,40*sin((x+20)/24.0)+40,
WIDTH, 17, greenbox);
gl_putbox(0,40*sin((x+30)/24.0)+40,
WIDTH, 17, yellowbox);
gl_putbox(0,40*sin((x+40)/24.0)+40,
WIDTH, 17, orangebox);
gl_putbox(0,40*sin((x+50)/24.0)+40,
WIDTH, 17, redbox);
gl_putbox(0,-40*sin((x+0)/24.0)+144,
WIDTH, 17, purplebox);
gl_putbox(0,-40*sin((x+10)/24.0)+144,
WIDTH, 17, bluebox);
gl_putbox(0,-40*sin((x+20)/24.0)+144,
WIDTH, 17, greenbox);
gl_putbox(0,-40*sin((x+30)/24.0)+144,
WIDTH, 17, yellowbox);
gl_putbox(0,-40*sin((x+40)/24.0)+144,
WIDTH, 17, orangebox);
gl_putbox(0,-40*sin((x+50)/24.0)+144,
WIDTH, 17, redbox);
gl_copyscreen(physicalscreen);
gl_clearscreen(0);
vga_waitretrace();
}
return 0; /* it's almost a tradition! */
}
Installing Window Maker by Michael Hammel is a tutorial on the basics of getting started with the Window Maker window manager. It is an excellent companion to the third part of his ``Artists' Guide to the Desktop, Part 3'' in this issue.
Data and Telecommunications: Systems and Applications is a book review by Derek Vadala.