I was reading a disambiguation page in Wikipedia today. I quote:
SAD is a three letter acronym.

• Seasonal affective disorder


• Schizoaffective disorder


• Sexual arousal disorder


• Social anxiety disorder


• Systems Analysis and Design


And here is where my jaw dropped on my desk.

This is no good if you have HIST_IGNORE_DUPS or HIST_IGNORE_ALL_DUPS set.

precmd ()  
  [[ $ #$ (M)$ $ (v)history [1,20] :%w  -gt 10 ]] && figlet Stop typing w
 

The Philadelphia Orchestra just announced the launch of an online store, where they are selling tracks directly from their own website. Following in the tentative steps of MySpace, eMusic, and Yahoo!, the Orchestra is selling unencumbered (i.e., DRM-free) MP3’s. Even better, for a slightly higher price, you can download content in the higher quality (lossless) FLAC format. Performances currently seemed to be priced at approximately $5 for the MP3 version and $6 for the FLAC version. This seems just about right to me. As an added bonus, they’re offering Beethoven’s Fifth in C minor for free. I’d love to see more of the industry move in this direction, particularly for longer-tail type cultural content like classical and world music. These recent developments are certainly a good start. It will be interesting to see if the iTunes Store eventually is forced to respond to these pressures.

I've been looking at getting eclim working on my laptop... haven't yet worked it out, can't get the eclimd to run as expected - it's looking very much like I might need to actually do a central install which means creating a package (stuff does not get installed on this machine in central locations unless it's packaged, hopefully for obvious reasons) so I may take some time out to package it over the next week or so. As far as Java IDEs go, eclipse is where it's at, but I don't like the UI and so, being able to use the useful bits of eclim from a text editor that I use for everything seems to me like a fantastic idea... especially now that I'm editing more Java than previously - my current dev environment it purely vim with a reasonable vimrc that sets expandtab, sw=4, ts=4 to fit with the company policy on java development - would occasionaly be useful to use eclipse to manage various things for me though - so that's why I'm looking at it (thanks for pointing me at it Joe!).

There are a lot of beautiful fall colors that will be showing up in forests around the world shortly.

But here in Kansas, we get a little jump on the colors because this is sunflower season.

If you drive around Kansas this time of year (roughly August and September), you'll see sunflowers all over the place. The wild sunflowers thrive anywhere there's nobody to plow them under or mow them down. If you pick the right country road, you can drive along and see what looks like a yellow wall in the distance. As you get closer, you realize that you're seeing sunflowers growing along a small stream or creek, though they've completely hidden it.

Although I grew up here, I had never really paid attention to the sunflowers. Back in 2002, as we were moving to Kansas from Indiana, Terah noticed the wild sunflowers. She'd never seen wild sunflowers and has really enjoyed them ever since (and so have I).

So, here are some sunflower photos, for those of you that have never had the chance to travel some of the back roads of Kansas.

First we start with a small bunch of wild sunflowers:



This small patch is growing in the ditch by our farm (our house is in that clump of trees in the background). These sunflowers are pretty young, so they aren't very tall yet. Also, there's a butterly fluttering around in that photo.

Most of the wild sunflowers get much taller than these. They seem to usually grow to about 5 to 7 feet (1.5 - 2.1m) tall. Here's a taller patch, about 1/2 mile away from the first one:



Neither of these two example photos show a very "deep" view of a group of sunflowers, because they are so dense that it's hard to really see what the individual plants look like in such a photo.

But here's a photo of a sunflower field:



These sunflowers don't grow as tall as their wild cousins, but their flower heads are quite a bit larger. This type of sunflower can be found many places. Wild sunflowers like we have here can be found in different places, too, but I've never seen them so common as here in Kansas.

Update It helps if you give sort a -n option apparently. The results make a bit more sense now. Well it kind of varies, because I have a weird mode of operation. I SSH into caesar, in my cupboard, which is my local general purpose box. It runs a screen session, which includes an SSH session with daedalus, my server co-located back in Australia, where I read my email via mutt, and then I do really local stuff on my laptop, icarus.

daedalus

     37 fg
     32 ls
     31 sudo
     19 blog
     12 cd
      7 df
      6 vi
      6 mutt
      5 less
      4 man

Unsurprisingly, fg wins out here, because I'm usually in mutt and just background it to get a shell prompt. blog is a funky shell script I wrote to better manage blog posts with Blosxom.

caesar

    152 sudo
     61 ls
     38 less
     35 cd
     27 screen
     19
     13 dpkg
     11 apt-cache
     10 man
      9 ssh

icarus

156 play 103 ls 54 sudo 45 ssh 12 cd 12 apt-cache 10 dpkg 8 wget 8 host 6 telnet play ranks so highly because I was recently listening to all of the audio files that come with Asterisk to stitch together a particularly hellish purgatory for telemarketers.

So it's interesting seeing how the different machines get totally different use.

Tato, Raquel and me headed to Cat Power’s concert last Wednesday. Luckily, I won two tickets for the concert on a morning radio show (it was around 6 am, so when the speaker asked a question, I had plenty of time to open my notebook, confirm the answer on Wikipedia and call the station; because of the time, the call entered quite quickly, on the 3rd try). It was a double, so Tato had to buy his own ticket. Chan Marshall, Cat Power’s real name, is quite interesting. She asked previously that people people should be quiet while performing because of her stage fright (!). She also likes to cut her songs abruptly complaining on the sound of the piano, tunes on the guitar, her voice, the accoustics on the place, etc. We also realized that her live performance is completely depressive, and the ambient of people (quiet, clapping to support her, proposals to marry her from girls) makes an outstanding and not common at all atmosphere. She played for like two hours in complete absense of noise (except when people clapped or shouted to ask for some songs, or to laugh at her jokes -like the one asking people what would be a better place to live, Mexico or Japan, guess the answer of people-). You could even hear beer bottles rolling in the halls and people doing like “shhhh”: the silence was terrific. She also played the day after, but that date was announced like one week before and didn’t get much people. No pics since from previous experiences, photos of my cell phone are completely sucky in darkness. Other concerts I’ve gone in the last weeks: The Strokes and Babas nicos. Next concerts I’ll be going: Yeah Yeah Yeahs (that’ll be fucking awesome, can’t wait for it). MiG and his girlfriend went yesterday to watch the Kung Fu Monkeys, a nice ska-punk band from Tijuana, but we were too tired to show up in the place. The day before, on Thursday, he also invited us to watch some surf bands, which scene is awesome in Mexico City, it was really nice and we had the chance to dance a bit.

Note: the script posted originally had a bug in sorting, as seen here. I used history 1 awk ' print $2 ' awk 'BEGIN FS=" " print $1 ' sort uniq -c sort -nr head -10 (this is for zsh history; the fix is the -n flag to sort)

    254 ls
    141 cd
    131 vim
     86 svn
     77 grep
     70 apt
     65 sudo
     60 ssh
     51 rm
     45 dpkg

Boring meme. I work on files, edit files, use subversion, grep and eventually run apt-get or dpkg. "apt" is a small script of mine which will call apt-cache search or "sudo aptitude" as appropriate; somewhat merging the functionality of these into one command). Followers up:

     45 cat
     43 man
     33 debuild
     28 apt-cache
     18 dch

debuild, dch - yeah, I have been doing some Debian work recently. Mostly SELinux, like a week ago or so. [Clint, I didn't invent that double-awk pipeline. I just fixed the sort issue. I'm currently more annoyed by awk because it uses isatty() on regular files, which in turn does ioctl, which in turn triggers SELinux audit errors...]

I haven't heard too many people asking if GNOME 2.16 will make etch. Maybe everyone just assumes it will, because the latest transitions have been pretty good, or maybe everyone just assumes it won't because nobody would expect Debian to ship with a current GNOME release, right? Or maybe Debian is immerse in what looks like the beginnings of a civil war, and that is more interesting. The Debian GNOME team has been preemtively working on GNOME 2.16, though, as the release clock is ticking. Lo c has spent a big amount of time revamping the packaging of GTK+ and Pango, finally resulting in sane source packages people can look at. Joss, Guilherme, Lo c and others have worked on the rest of the Developer Platform packages, which is now ready for testing in experimental. The evolution team has also been rocking and all the associated packages are ready to go in experimental as well. The GNOME 2.16 status page still shows quite some red for Desktop packages, which are now being worked on, with GTK+ 2.10 in place. But we still haven't decided if we can go ahead and attempt a 2.14 -> 2.16 transition in time for etch. Our biggest concern are the known problems of GTK 2.10's file chooser regarding cancelling of operations. Apparently, other distributions are getting bad bug reports due to these, so we need to be very careful about it. We know there are people working on an upstream fix as I write, but we don't know when there'll be a patch for GTK+ and libgnomeui available. If we learn it's due soon, we might start speaking to our release managers about the possibility of starting a transition. If we have no news, it'll probably be too late.

IBM has a nice article called UNIX productivity tips. The article mentions this one-liner, which shows the shell commands you use most often:

$ history awk ' print $2 ' awk 'BEGIN  FS=" "   print $1 ' sort uniq -c sort -rn head -10
    471 sl
    222 cd
    217 csl
    155 vi
    140 ..
    112 ls
    106 cls
     70 rm
     64 mv
     58 xpdf

Gee, I didn't know I'm that boring... Note how I mistype "ls" way more often than I type it correctly. Luckily my .bashrc fixes this for me :) Update 2006-09-25: When I posted this, I didn't intend to start a meme, but it seems I did: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14. (via Lifehacker)

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

Lots of happy GRs! It's GR season, and everyone is rushing to produce a nice GR that would make Debian oh so much better than it already is. But some of us either lack the fantasy, or the grammatical competence, or just the time to contribute to this important effort. For those people, I prepared a handy polygen grammar that they can use. Here is today's GR:

1. After the release, the Donors widly do not take the Community in order to overruling this resolution in the interest of the Debian Release Managers for the purpose of promoting more prompt action.
2. The Debian Project Leader has the support of Debian for apologising the funds as seems subsidiary and reasonable for the purpose of promoting cooperation between Debian and the Debian Release Managers.
3. The Delegates broadly fund the swift funds for funding the Debian FTP Masters for the duration of the mandate for the purpose of the RMs.
4. For the purpose of being 100% Free Software, the Debian Project subsidiaryly can overrule the core proprietary drivers in main in order to apologising the needed funds for the Cabal promptly in the benefit of having a more harmful Project.
5. As seems harmful and experimental, the Debian Release Managers are devalued by the Debian FTP Masters in order to disbursing the copyright holder for the duration of the mandate for the purpose of Debian.
6. The Leader lets it be known that the Developers are approved by the Donors to reasonably revoking the Developers-controlled plan during the forthcoming release in the benefit of promoting more potential action.
7. Promptly, the Debian FTP Masters can be approved by the Delegates to establishing the reasonable Developers following internal discussion in the interest of our users and Free Software.
8. Effectively, the Delegates have the reasonable support of the Developers for neededly cooperating with the firmware in main with immediate effect, during the forthcoming release of Debian for the purpose of Everyone.
9. Debian reasonably funds the Community for broadly revoking the donations in the interest of Everyone for the purpose of having a more appropriate Debian Secretary.
10. In the interest of promoting more needed action, Everyone is of the core opinion that the Developers cannot be authorised by the Delegates to establishing the Developers-controlled Debian Release Managers as seems reasonable and needed for the purpose of reducing the delays of the New Maintainer queue.

I wish this GR generator helps to satisfy all our GR needs, and will finally free some time for people to work on making etch a really great distribution for all of us to run and love.

Joey Hess from Debian has come up with a pretty nifty analysis of thread patterns in email. This is a great example of the geek technique to transform what seems like chaos (and can surely be experienced as such) into something more categorical, segmentable, and thus manageable.

It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include: » All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3). » A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months. » We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run. To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months. To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions. At a high level, then, the LSB roadmap looks something like this:

LSB 3.x (2006-2008)	LSB 4.x (2008-2010)
Asianux 2.0 Debian 4.0 (”etch”) Mandriva Corporate 4.0 Red Hat Enterprise Linux 4 & 5 SUSE Linux Enterprise 9 & 10 Ubuntu 6.06 LTS (”dapper”) […]	Asianux 3.0 Debian “etch” + 1 Mandriva Corporate 5.0 Red Hat Enterprise Linux 6 SUSE Linux Enterprise 11 Ubuntu LTS “dapper” + 1 […]

» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly. » We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month. » In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future. » Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here. I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.