LWN.net Weekly Edition for January 24, 2008

Ten-year timeline part 3: The Tucows years

• April 13, 2000: Linuxcare postpones its IPO indefinitely and rearranges its management. Minix is released as free software.

• April 20, 2000: Linux Business Expo in Chicago. Microsoft's FrontPage back door is exposed. Devfs flame wars continue. Red Hat fired by its ad agency. Shares of Caldera, VA Linux Systems and Andover.Net all fall below their IPO prices.

• April 27, 2000: Oracle creates Miracle Linux in Japan. Red Hat launches its embedded developer's kit.

• May 4, 2000: Linuxcare lays off 35% of its staff and officially cancels its IPO.

Needless to say, by this time we were happy to have found a relatively stable place to be - times were starting to look a little tough. Between the end of the Linuxcare IPO - once supposed to be the biggest and best of them all - and the fact that other Linux companies had fallen below their initial prices, it seemed that the honeymoon was pretty well over. By this time, LWN's revenue stream from advertising had pretty well dried up too.

Red Hat's embedded business is a classic case of a lost opportunity. The acquisition of Cygnus should have placed Red Hat in a strong position in this sector, but, somehow, it all slipped away.

• May 11, 2000: Red Hat changes direction, dumps its news site, and jumps into the venture capital business. The first public BitKeeper release happens. The Free Standards Group is formed.

• May 18, 2000: Rumors of Wine 1.0. IBM releases the S/390 port. Memory management problems plague the pre-2.4 development kernels.

One might think it cynical and mean-spirited to point out that we're still waiting for Wine 1.0. But we'll do it anyway. The memory management issues with 2.4 were to be with us for some time, as it turned out.

• May 25, 2000: The Linux Mall and EBIZ merge. Lineo files for an IPO. Eric Raymond decides to rewrite the kernel configuration system.

• June 8, 2000: A fight over whether Reiserfs should go into the 2.4 kernel.

• June 22, 2000: British telecom claims to own a patent on linking and starts suing ISPs for being part of the world wide web. 2.4.0 test kernels come out in two flavors with different memory managers. More Reiserfs flames.

Given that the 2.4.0 release was far overdue, one would think that arguments over whether a completely new filesystem should be added would be considered out of place. But they did happen, with Hans Reiser showing a level of anger and paranoia that put much of the community off of dealing with him for years. It is rare that kernel developers are accused of putting corporate interests above those of the kernel as a whole, but that happened here.

It is actually worth reflecting on this a bit: kernel developers work for roughly 200 companies, many of which are direct competitors. But that competition has remained almost entirely absent from the development process. We are very good at developing common resources in a highly collaborative way while competing at different levels.

• June 29, 2000: MySQL switches to the GPL, moves to SourceForge. 2.4.0-test2 is officially blessed with penguin pee.

• July 20, 2000: Miguel de Icaza proclaims that "Unix sucks" at OLS. Sun releases StarOffice under the GPL. Rumors circulate that Caldera might acquire SCO; if only we'd known where that would go. Larry Wall announces that Perl 6 will be a complete rewrite of the language. If only we'd known where that would go - or not go. A set of locking changes goes into the 2.4.0-test kernel - which is allegedly stabilizing for release.

• August 3, 2000: Copyleft is sued by the DVDCCA for putting the DeCSS code on T-shirts. Caldera's acquisition of SCO's Unix business (and name) becomes official.

• August 17, 2000: The GNOME Foundation is formed. Debian 2.2 ("potato") is released.

• August 24, 2000 KDE/GNOME flame wars break out anew. Eric Raymond strongly criticizes Linus's management practices. VA Linux claims that SourceForge hosts "over 76%" of the world's free software. Caldera/SCO announces the "Linux and Unix marriage" - something it will wish to annul later on.

Something which was widely understood, but little talked about, during this time was the great amount of effort VA Linux put into recruiting projects to SourceForge. It was a clear effort to become the home for as much software as possible. Quite a few prominent projects moved over with great fanfare, only to drift away more quietly later on. SourceForge still hosts a great many projects, but it is seen by many now as a home of last resort.

• August 31, 2000: The Open Source Development Lab announces its existence.

• September 7, 2000: Trolltech releases Qt under the GPL. The CueCat saga begins. The RSA patent is released into the public domain - two weeks before it expires.

Lest anybody think that the dotcom silliness was truly over by this point, the CueCat story should convince them otherwise. Digital Convergence spent many millions of dollars sending around free barcode scanners on the idea that people would want to swipe codes from advertisements and be taken to the associated web site. This company considered using the scanner for any other purpose to be a violation of the DMCA, and made loud threats at people distributing drivers which enabled such uses. The company's threats came to nothing, but they foreshadowed the DMCA follies to come.

• September 14, 2000: Linus decrees that the kernel is licensed under version 2 (only) of the GPL.

• September 21, 2000: Sun acquires Cobalt Networks. Caldera dumps $3 million into EBIZ. Linus proclaims the kernel to be in "final freeze," with only critical fixes being accepted.

• September 28, 2000: the Red Hat Network launches. Red Hat 7 is released, featuring "gcc-2.96," a release which the GCC project never made.

The Red Hat Network was the core of what was to become the subscription services which support the company so nicely now. Back then, though, that outcome still was not clear, and Red Hat continued to experiment with a number of business ideas.

• October 26, 2000: KDE 2.0 is released. LynuxWorks files for an IPO.

• November 2, 2000: Turbolinux files for an IPO. Linuxcare shuts down its European operation. Linus describes the 2.4.0-test10 kernel as having "no known bugs."

• December 7, 2000: The 2.4.0-test12 prepatches include the new PA-RISC architecture and rework of the task queue API - both of which, apparently, were fixes for critical problems. EBIZ tells its shareholders that things will get better soon, honest.

• December 21, 2000: Corel sells its Linux business to (what becomes) Xandros.

• January 11, 2001: the 2.4.0 kernel is released at last. Linus warns that it's not yet open season for new patches. The first SELinux prototype is released.

Many people had begun to worry that 2.4.0 would never come. The story of the development of this kernel, though, was not done yet.

• January 18, 2001: The Ramen worm attacks Red Hat Linux systems. Turbolinux and Linuxcare agree to merge. Lineo withdraws its IPO application. VA Linux warns that earnings will not be up to expectations. Helix Code gets $15 million in venture investments. The InterBase backdoor is discovered. Reiserfs gets merged for the 2.4.1 kernel. The first linux.conf.au happens.

• February 8, 2001: SUSE (still SuSE then) lays off most of its US staff.

• February 22, 2001: VA Linux lays off 25% of its staff, gets a new CEO. Turbolinux cancels its IPO. Microsoft's Jim Allchin calls Linux "un-American".

• March 15, 2001: Eazel releases Nautilus 1.0, lays off half its staff.

• March 22, 2001: The Stanford Checker surfaces with a long list of potential kernel bugs. EBIZ announces a plan to acquire Linux NetworX.

By this point, things were looking downright scary. During the bubble days, almost anybody who wanted to work in free software development could get a job somewhere. By this point, though, quite a few people were without jobs and some of them were leaving the community altogether.

The Stanford Checker was a GCC derivative which could do static analysis; for many, it was the first real demonstration of what that kind of tool could do. Despite some early reassurances, this code was never released; instead, it was used to found Coverity. The community has benefited strongly from Coverity's work, but imagine what we could have done with the source to the Checker. It is a little sad that we have been unable to develop similar capabilities in free software.

• April 5, 2001: Wind River Systems buys BSDi. The first kernel summit is held. Alan Cox states that the 2.4 kernel is not yet stable. Larry Wall begins to post the design of Perl 6.

• April 19, 2001: Wind River Systems lays off the Slackware staff. MandrakeSoft starts asking for donations from users.

• April 26, 2001: Ed Felten receives DMCA threats over his breaking of the Secure Digital Music Initiative watermarking scheme. Eric Raymond proclaims his intent to hack the kernel's social systems.

The threats against Ed Felten - who had participated on a contest put on by SDMI proponents - were a strong signal that, in the U.S., the DMCA could bite developers hard. Worse was to come, though. Meanwhile, Eric Raymond's attempts to "hack" a rather unimpressed kernel community provided a steady stream of comic relief.

• May 3, 2001: Turbolinux and Linuxcare cancel their merger. VA Linux posts horrific quarterly earnings. Sony releases Linux for the Playstation 2 console.

• May 10, 2001: EBIZ cancels its acquisition of Linux NetworX. The Bergen Linux Users Group implements RFC 1149.

• May 17, 2001: Eazel shuts down. Enhanced Software Technologies - owned by Atipa - shuts down.

• May 24, 2001: MandrakeSoft lays off 20% of its employees, including its CEO.

Your editor has said previously that Eazel's plan never seemed (to him) to make sense; the investors finally came to the same conclusion and pulled the plug. Another plan which did not make sense was what had happened to MandrakeSoft: outside managers placed in the company by its venture capitalists had decide that Mandrake should be an e-learning company - not exactly its area of core expertise. That strategy just about destroyed MandrakeSoft before the decision to go back to its distributor roots was made. The company has taken many years to recover from that mistake.

• June 21, 2001: Red Hat turns a profit. GCC 3.0 is released.

• June 28, 2001: Caldera announces plans to move its distribution to per-seat licensing. Linus announces that the 2.5 development series will open "in a week or two." Meanwhile memory management problems continue to plague the 2.4 kernel (now at 2.4.5). VA Linux leaves the hardware business. MandrakeSoft announces plans for an IPO. LynuxWorks withdraws its IPO application.

In these difficult days, the fact that Red Hat could produce a profit - even a tiny one - offered a ray of hope. The failure of VA Linux to make it in the hardware business was a sobering counterexample, though, given that VA was once the most prominent company selling Linux-installed systems.

• July 4, 2001: Version 1.0 of the Linux Standard Base is released.

• July 12, 2001: The Mono project is launched. Atipa shuts down.

• July 19, 2001: MySQL and NuSphere end up alleging GPL violations (and more) in court. Dmitry Sklyarov is arrested on DMCA charges in Las Vegas. EBIZ warns stockholders that more money must be found or the company will not be viable.

More than anything else, the arrest of Dmitry was a wakeup call for the community. It seemed that, in the U.S., any developer could be arrested for interfering with the business plans of large companies. As a result of this action, some developers still refuse to travel to the U.S.

• August 2, 2001: MandrakeSoft completes its IPO, raising €4.2 million.

• August 16, 2001: LWN co-founder and editor Liz Coolbaugh leaves LWN.

We still miss Liz - but she remains a good friend.

• August 30, 2001: Dmitry Sklyarov is charged with conspiracy and faces 25 years in prison. VA Linux takes the SourceForge software proprietary.

• September 6, 2001: IBM and others put millions of dollars into SUSE to keep it from bankruptcy. Sistina takes its Global Filesystem (GFS) proprietary.

• September 13, 2001: Caldera turns in horrific quarterly earnings; layoffs and a reverse stock split follow. Lineo lays off a large portion of its staff. Great Bridge, a company seeking to commercialize PostgreSQL, shuts down entirely. EBIZ goes into chapter 11 bankruptcy.

• September 27, 2001: The 2.4.10 kernel is released.

Few people remember September, 2001, as one of their favorite months. Beyond the terrible events occurring in the wider world, the problems in the commercial Linux sector just seemed to get steadily worse.

The 2.4.10 kernel release is an important point as well. Here is where the longstanding memory-management problems came to a crux; Linus responded by ripping out the 2.4.9 VM code and replacing it with a completely different implementation. What followed may be the closest we ever came to a fork in the Linux development process. Some distributors stayed with 2.4.9 for a long time - RHEL 2 systems (still supported by Red Hat) are still running a kernel which, at least, claims to be 2.4.9. The worst passed, however, and this is the point at which 2.4 started toward something resembling stability.

• October 4, 2001: The World Wide Web Consortium proposes allowing patented technology with proprietary licensing into web standards. SUSE brings in another round of funding and announces the layoff of 120 people.

• October 11, 2001: Michael Hammel leaves LWN.

Tucows, which had not been helped by having launched a major new offering on September 11, laid off a number of people, including Michael. His desktop columns had been a welcome addition to LWN, and his departure was a big loss.

• October 18, 2001: Progeny stops development of its Debian-based distribution.

• October 25, 2001: Lindows announces its existence.

• November 8, 2001: Linus announces that 2.5 will start soon. Marcelo Tosatti is named as the 2.4 maintainer. IBM open-sources Eclipse. The European software patent directive picks up steam.

• November 29, 2001: The 2.5 kernel development series starts - with a filesystem corruption bug.

• December 6, 2001: The Mandrake Club is launched as a fund-raising initiative.

Initially the Mandrake Club was meant to function as a sort of tip jar. As financial problems at MandrakeSoft got worse, though, it became the storefront through which the Mandrake distribution was sold. Not everybody liked how the Club was run, but it doubtless helped MandrakeSoft to survive into the present.

• December 20, 2001: Charges against Dmitry Sklyarov are "deferred" and he returns home to Russia.

• January 17, 2002: DeCSS creator Jon Johansen is indicted in Norway.

• January 31, 2002: LWN is unacquired. 2.5 kernel patches get dropped, leading to another "Linus does not scale" discussion.

The indictment of Mr. Johansen made it clear that DMCA-like problems were not limited to the USA.

Meanwhile, by this time, Tucows had come to terms with the fact that its acquisition (and ongoing operation) of LWN was not helping it, given the directions its business was taking. So, after some discussion, LWN was unacquired - it was given back to its creators, with Tucows holding on to a small piece just in case. The parting was on the best of terms; it revalidated our decision to go with Tucows in the first place. But, after almost two years, it was time for LWN to venture back out into a scary world as an independent business. That was the beginning of a new phase, with its own ups and downs, which will be discussed in the next installment.

Comments (12 posted)

The Grumpy Editor's video journey part 2: Video editors

The task to be accomplished is relatively simple: for each video clip, trim off the extra junk at the beginning and the end. Some of them also require internal editing; there were signs of operator error in the form of, say, extended sequences where the sole subject matter was the floor and, perhaps, the cinematographer's shoe. Nice transitions between the clips were desired - a basic fade to black at the end, if nothing else. The addition of titles is useful. And, as an added bonus, the video clips needed to be deinterlaced before being written in a form suitable for passing to the dvdauthor utility.

In the process, your editor encountered several tools in varying states of readiness. He has become better acquainted than ever with the notion of "build hell." A rather more than passing acquaintance with the behavior of the out-of-memory killer in 2.6.24-rc kernels has also been achieved. And, at the end, your editor believes he has a reasonable sense of the state of the art in Linux video editing.

Avidemux

Avidemux is a GTK-based editor which, according to its web page, is "designed for simple cutting, filtering and encoding tasks." It is an interesting combination of simplicity in some areas combined with great power and complexity in others. It has a lot of potential, but it also has a few rough edges.

For example, Avidemux handles DVD-style MPEG2 files without trouble. But a reader who digs far enough into the documentation (which is extensive and useful, incidentally) finds a warning that one must exercise the "build VBR time map" option, or audio and video will become unsynchronized in the final product. This operation is nearly instantaneous on a five-minute clip; given the problems which can result from not doing it, why does Avidemux not just build this "time map" when the file is loaded? Why set a trap like that for your users?

The actual video editing operations are quite simple. Avidemux can only handle a single video clip, and that clip has a single set of begin/end points. It is possible to delete from the middle of a clip using those endpoints; deletion is instantaneous and leaves no sign on the timeline. There is no "undo" operation, but there is an option to dump all changes made to the file. There is a scrollbar which enables quick movement through the clip; the arrow keys move by single frames. In general, the interface is responsive on your editor's machine.

Before
After

A fade-to-black ending was achieved with another filter. It works beautifully, if one does not mind that (1) there is no choice of what to fade to beyond a "fade to black" toggle, (2) the portion of the clip to be affected must be identified by typing in frame numbers, and (3) those frame numbers are not adjusted should somebody, say, delete some video from an earlier part in the clip. The capability is there, but the interface needs some work.

Other filters allow cropping, mirroring, color modifications, noise removal, sharpening, blurring, addition of subtitles, the addition of logos from image files, the creation of animated DVD menus, etc. Should all of those be inadequate, the "swiss army knife" filter is there for more general low-level processing. There is also a scripting interface for Avidemux, though your editor did not attempt to make use of it.

The interface allows the user to view the video either before or after the filters have been applied - or both together. The latter mode, though, tends to run slowly, though the post-filter output, by itself, worked just fine.

In the end, saving the file out as a DVD "video object" does the job - though one has to assume that the rather spartan "save" dialog will do that. Like most (but not all) video editors, Avidemux does not actually change the video data until told to render a new file. The list of edits, filters, etc. can be saved as a "project" file (an Avidemux script, really) so an editing session can be resumed at a future point using the original material.

The bottom line is that Avidemux is a capable and reasonably solid tool - your editor was not able to make it crash. Its long list of filters will be appealing to some users. Its inability to work with more than one clip at a time will rule it out for many others, though. Like so many other tools in this category, it's almost there.

Cinelerra

The Cinelerra tool has an interesting history. It was once known as "Broadcast 2000," before being withdrawn because somebody was worried about legal liability. Now it is available as "Cinelerra," but in two versions. The "official" version is published by a company named Heroine Warrior, which has no real interest in the hassles of dealing with a community or making regular releases. Heroine Warrior is, however, generous enough to make the code available under the GPL; a group of developers has taken the code and made Cinelerra CV - the "community version." This version is supposed to be under active development and move more quickly, but it still doesn't seem to be moving all that fast, unfortunately.

There are some good documents for Cinelerra, but, reading them, one starts to encounter certain themes. For example:

Or this one:

Cinelerra is by far the most complex - and capable - of the tools available for Linux. If you are looking for an editor designed for the creation of complicated video with lots of effects, Cinelerra is the tool for you. Unfortunately, Cinelerra does not appear to have a development community which is up to the maintenance of a tool of this size. So it is difficult to work with and not particularly robust.

At startup, Cinelerra puts up four individual windows. The "timeline" shows all of the tracks being edited, and is the place where much work actually gets done. There are two video windows; one displays the current state of the timeline, while the other can be used to look at individual clips outside of the timeline. Then the "resources" window holds everything else.

The timeline display is quite nice. Video thumbnails along the line give a rough sense of what is happening in each clip. The display of audio levels is also highly useful when one is trying to find specific events; it would be nice if other tools picked up this idea. A number of editing operations can be performed directly on the timeline; each track, for example, has a horizontal line which can be manipulated to adjust the (audio or video) levels at any given point. So a fade-to-black, for example, is a simple matter of ramping the video level down at the right place.

For more complex operations, there is a large list of effects which can be applied. These effects show up on the timeline next to the tracks they operate on; their end points can easily be dragged around. Cinelerra will attempt to render effects when the timeline is being played, but that tends to slow the program (not the fastest tool to begin with) to a point where it cannot keep up with normal video rates.

Cinelerra does not modify any data until told to render the project. It cannot create DVD video objects directly; one must render audio and video separately, then multiplex them outside of the program. The edit list can be saved separately.

There is a whole host of features in Cinelerra not found anywhere else. For example, it can be used to drive a rendering farm for those big production jobs. There is a motion tracking subsystem built into it ("The intricacies of motion tracking are enough to sustain entire companies and build careers around"). There's a set of options for audio and video capture. And so on.

But your editor could never get all that far with Cinelerra before it ran the system out of memory. One does, indeed, become familiar with its tendency to crash, but it's especially annoying when it takes the rest of the system down with it. Cinelerra should really be one of the star applications in the free software world. It has a great deal of power and can do amazing things; it could be a professional-quality tool. What it needs is for the community to truly take charge of the "community version" and turn it into a system which is fast, robust, and easier to use. To that end, it would help if the two people on the planet who can succeed in actually building this system would clean up that process and, in general, make Cinelerra more welcoming to new developers. The foundation for a great video editor is here, but there is a lot of finishing work to be done.

Kdenlive

Kdenlive is a KDE-based editor under active development; version 0.5 was released in August, 2007. Having not found a version for Rawhide, your editor set out to build this tool, only to give up in despair. So, as an aside, your editor would like to offer a helpful suggestion to developers who want people to actually use their code: if you absolutely must use your own build tool instead of make, and there is just no alternative to using a tool which nobody has heard of or packages and which does not have a web site or working download location, please consider just packaging said tool with your code. Your editor is sure that "unsermake" is vastly superior to the alternatives which we all have on our systems already, but it doesn't help if you can't find it.

Of course, even after solving that problem, your editor was not able to build this tool. Fortunately, Ubuntu ships it, so that is the version which was used here.

The initial Kdenlive experience is a little rough; it asks for a set of default parameters. How is one to choose between, say, "CIF NTSC" or "DV NTSC" or "DV NTSC Widescreen"? There is no help on offer to guide the user toward the right choice. Once past that, the user sees a window with three major panes which offer functionality similar to that available from Cinelerra.

The first step is to bring one or more video clips into the "project tree," which is (usually) visible in the upper left pane. These clips can be viewed in the "clip monitor" on the right. A clip of interest can then be dragged down to the timeline area, where it can be easily positioned relative to any others which are already there.

Kdenlive uses the "divide and conquer" editing method. To remove a section of a clip, the user positions to one end of that section, then selects "razor" to split the clip in two at that point. Another split at the other end isolates the section to be removed, which can then be deleted with a separate operation. There is (with the exception of transitions) no way to apply an operation to a part of a clip - the area of interest must always be razored out first.

As a result, the fade-to-black effect is not quite as easily achieved in Kdenlive as with some other tools. There is a "brightness" effect, but it changes the brightness to a constant value through the entire clip. The way to fade out a scene is to add a new clip with a solid color (easily done in Kdenlive), then use a crossfade transition to join the two clips together.

Transitions are added by selecting the first track and, via the right-button menu, selecting the desired transition. Various parameters (such as the time required for the transition) can then be tweaked. It all works easily; Kdenlive is a fun tool for quickly piecing together different bits of video into a coherent whole.

There are separate video windows for displaying individual clips and the timeline as a whole; by default, they cannot both be viewed at the same time. Playback is responsive. It's a little more awkward than with some tools, though: the position cursor is small and hard to grab, and there is a shortage of keyboard shortcuts for moving around. The timeline is less informative and less functional than Cinelerra's, but the information one really needs is there.

When the project is done, there is a nice "export to DVD" option there to do the rest of the work. Kdenlive can create the video object files and fire up Qdvdauthor to do the rest, or it can create a basic, single-title DVD internally and (using k3b) burn it to a disc. Your editor, thus, should have mentioned Kdenlive in the DVD authoring article, but he was unaware of this feature at that time. It all works easily; your editor was able to make a playable DVD with minimal trouble.

It was not the most beautiful DVD, though, because Kdenlive has no deinterlacing capability. Those of us unlucky enough to be starting with interlaced video must handle that operation separately, before or after the editing process.

While any of the editors discussed here could conceivably work with high-definition video, Kdenlive is the only one which appears to have been written with that in mind. Projects can be set up in HD formats without undue tweaking. Your editor was not in a position to test this capability, though.

All told, Kdenlive comes across as one of the most finished of the free editing tools. It is relatively straightforward to use and it has all of the features that most people are likely to need. For many applications, this could well be the first tool to reach for.

Kino

Despite its "K" name, Kino is a GTK-based video editor. It is quick and easy to use, but also lacking somewhat in power.

Kino only works with a single video format - the digital video (DV) format associated with contemporary camcorders. When started with something else (say, your editor's MPEG files from the capture card), it will offer to convert the file into DV. This process works, but the result is a significant (5-10x) increase in the size of the file.

There is no timeline in Kino; instead, it has a "storyboard" in the leftmost pane. Each video clip becomes a separate scene in the storyboard, with each being played strictly before the one after it. Like Kdenlive, Kino works by dividing clips and applying operations to the pieces. So trimming video is done by "splitting" the scene into wanted and unwanted parts, then deleting the latter. The documents make much of the "powerful" three-point trim feature, but your editor doesn't get it; it just seems like a way to set the beginning and ending split points on the same screen, but the amount of work remains the same.

Moving within clips is quick and easy in Kino. There is also a scrollbar-based "jog wheel" for variable-speed motion in either direction. What your editor really likes, though, are the keyboard shortcuts, including vi-style bindings for moving, frame-by-frame, through the material. It makes finding the exact spot to make a cut a quick affair.

Kino offers a reasonable set of effects, though the interface and implementation are awkward. Most effects apply to a full scene, so the normal mode of operation is to split scenes where an effect is to be placed. There is an option to "limit" an effect to a period of time at the beginning or end of a scene, though, so something like fade-to-black or a crossfade can be done without making new scenes.

Or so one would think. Unlike most other editors, Kino does not apply effects at playback time; instead, an effect must be rendered when it is applied to the scene. The result is a new scene (even if the limit option described above is used) which contains the result of a new DV file created by the effect renderer. For good measure, the rendering code places the rendered file (with a name like 001.kinofx.dv) in the user's home directory, which can quickly become cluttered with them. This approach lets Kino display effects without performance problems, but it is a bit messy and inelegant.

Internal
External

By default, the DVD exporter creates the necessary video object file and a simple dvdauthor script for a minimal DVD. There are options, though, to burn the DVD immediately or to go into Qdvdauthor for further work.

One might mention here that, like most of the other tools discussed here, Kino does not play nicely with others when it comes to the audio subsystem. Each tool has its own way of responding to contention, though. In this case, if Kino is unable to get exclusive access to the audio device, it shows its displeasure by playing video (silently, of course) at ten times the normal speed. After a while one learns to recognize this particular tantrum, but it still would be nicer if the application would say something like "I'm not willing to share the audio device, can you please stop your music player if you want to play back your video?"

Bottom line: Kino is a reasonably capable editor which, after a very short learning period, is quick and fun to use. It may well be the best option for people with relatively simple needs. Those wanting more sophisticated capabilities, though, are likely to see it as an underpowered toy.

LiVES

The Linux Video Editing System (LiVES) is a relatively simple editor with some interesting capabilities. The web page claims:

Your editor, however, is not a VJ. So his experience with this tool was not the best.

The process of importing a video clip into LiVES is slow and disk-intensive. After some investigation, your editor figured out why: LiVES works by converting every video frame into a separate JPEG image file. The end result is a directory containing tens of thousands of images and a massive expansion in the size of the clip. It also cannot be good for system performance in general; your editor can only suggest that using a filesystem with indexed directories would be a good idea.

LiVES is one of those applications with such a sense of its own importance that it comes up maximized from the outset. The interface reconfigures itself on the fly depending on what operations are selected - in particular, video display windows come and go in a frequent and distracting manner. The default directory for video files in /usr/local. Cross-fading one clip into another works, but it loses the synchronization with the audio. Many tasks are done by running external programs; should that program fail, LiVES will tell the user, but it does not pass on the information provided by that program. So figuring out why things fail is a matter of digging through debug and strace output.

Somewhere in this process, your editor decided that, while LiVES may indeed make VJs happy, it is not a serious editing tool for the rest of us. There is the potential for some nice features there, but this application needs a lot of work before it will be ready for general use.

PiTiVi

One gets used to thinking of video editors as being huge programs written in relatively fast languages. PiTiVi, however, is an exception to the rule: it's a smallish application written in Python. Of course, it's only small when one overlooks some of the external pieces - like gstreamer.

This application, too, was a bit of a challenge to get going. It has various dependencies not accounted for in its configure script, including some strange ones: why does a video editor need to import Zope modules? Still, your editor had better luck here than with some of the alternatives.

The good news is that, despite its Python implementation, PiTiVi is responsive when moving around in video clips. On the other hand, moving around in clips is really about all that PiTiVi can do at this point. There is a rudimentary timeline display which does not do anything, and no editing options are available. So PiTiVi, while being a promising start, is not really an editor at this time.

Conclusion

Worth mentioning in passing: the Open Movie Editor looks like a tool with some promise. It disliked your editor's video files, though, claiming that it only supports files with a 25 frames/second rate. Your editor, deep in NTSC country, has no such files. Hopefully, as this project matures, it will achieve the generality this kind of tool must have.

The free software community can be aggravating sometimes. We clearly have the ability and the desire to create top-quality tools for tasks like video editing. But what we get is a half dozen tools, none of which is a complete solution to the problem. Your editor would be the first to say that competition between projects can be a good thing, inspiring everybody involved to push harder and achieve more. But, still, maybe having fewer competing tools might just help people to work together and make tools which are truly great.

That said, the state of the art in Linux video editing is not as bad as one might think. The tools are there to put together a decent video without a great deal of trouble. As mentioned above, Kdenlive is arguably the most polished of these tools, with Kino also being a good candidate for simpler applications. And Cinelerra remains in its position as the application that is going to be truly spectacular, once all of those loose ends finally get tied up.

Your editor once heard Lawrence Lessig say that text is like Latin for younger people today, and that video is the preferred way to communicate. If that is true, then we want to make it possible to communicate as richly as possible while using free tools. We have a good base to build on, and many smart people have solved many of the hardest problems. Finishing the job is well within our capabilities.

Comments (27 posted)

linux.conf.au starts January 28

LWN editor Jonathan Corbet is pleased to be heading back to Australia for his fourth visit to linux.conf.au. Beyond the pleasure of attending one of the best free software events on the planet and meeting LWN readers, there will be the simple joy of going somewhere where the temperature is above freezing. But most pleasing is the opportunity to speak at linux.conf.au on January 30 - they day we have designated as the tenth anniversary of LWN. It will be a celebration for sure.

Stay tuned to LWN for reports from the event as it unfolds.

Comments (none posted)

Page editor: Jonathan Corbet

Security

Web security vulnerabilities and Javascript

Various recent, unrelated security issues seem to have a common thread: Javascript. It is not the fault of the language, exactly, nor of any particular implementation. It is the fundamental nature of how the language is used that often causes it to be "front and center" when security problems are found on the web.

Imagine that your computer reaches out across the net, to an unverified site, over an unencrypted link and grabs code that it executes with little in the way of further inspection. When put that way, it sounds rather dangerous, but that is exactly what browsers do with Javascript code. There are limits to what Javascript is allowed to do—meant to thwart malicious uses—but it has to have some privileges on the local machine in order to be useful.

One of the recent outbreaks is the "random js" attack, which propagates through Javascript served by legitimate websites. It generates a random .js filename for each visitor—which is where the name comes from—inserting a reference to it in a page on the site. It also stores the IP address of the visitor so that it does not repeat the infection multiple times. The payload then tries to exploit a dozen or more Windows vulnerabilities to install malware of various sorts.

The payload is not a problem for Linux users, but the websites hosting the attack are running Apache, many on Linux. The big unresolved question is how the servers were infected. It could be as simple as getting root access via insecure or intercepted root passwords. Or there could be some, as yet unknown, exploit. That certainly bears watching.

Because of the privileges that Javascript has on a local host, it can be used to spread malware, by exploiting the trust that users—those that even concern themselves with such things—have in the website they are visiting. It can also play a role in redirecting traffic away from a trusted site, even though the site itself has not been compromised.

A post by Nat Torkington at O'Reilly illustrates a common problem that content providers need to worry about. O'Reilly's perl.com site carried advertising that required them to load Javascript from the advertiser's site. All was well until the domain expired. A porn site bought it and started providing the required Javascript file with new contents redirecting the users to their site.

A man-in-the-middle or DNS cache poisoning attack could be used for similar results on a smaller scale basis. One can certainly see how it might be used by phishers as well. It is a difficult problem, as website owners need to be able to call out to advertisers' Javascript, but users typically do not expect to run code from a site they did not directly access.

A theoretical attack on home routers has started to show up in the wild. It uses Javascript to exploit a vulnerability in home routers to change the DNS entries for a popular Mexican bank. After that, accesses to the bank would instead go to the malicious website which would collect usernames and passwords, allowing the attacker to access the accounts. Once again, users probably do not expect that surfing to a random site could suddenly expose them to bank account compromise.

There are some things that can be done. For users, if Javascript cannot be disabled entirely—something increasingly difficult in the "Web 2.0" world—it can at least be leashed using NoScript for Firefox.

For website owners, Google's Caja project, seeks to define a subset of Javascript which implements an object-capability language, which would make it easier to sandbox remote code. If this effort succeeds, one can imagine that users could restrict their browsers to only use the Caja subset some day as well.

Comments (2 posted)

New vulnerabilities

apt-listchanges: arbitrary code execution

Comments (none posted)

bind: off-by-one error

Comments (none posted)

boost: denial of service

Comments (none posted)

flac: arbitrary code execution

Comments (none posted)

horde3: remote email deletion

Comments (none posted)

hsqldb: unspecified vulnerability

Comments (none posted)

kernel: local filesystem corruption

Comments (none posted)

libcdio: arbitrary code execution

Comments (1 posted)

mantis: information disclosure

Comments (none posted)

mantis: cross-site scripting

Comments (none posted)

scponly: arbitrary command execution

Comments (none posted)

tomcat: information disclosure

Comments (none posted)

wireshark: denial of service

Comments (1 posted)

wireshark: denial of service

Comments (1 posted)

xine-lib: buffer overflows

Comments (none posted)

Xorg: multiple vulnerabilities

Comments (none posted)

Updated vulnerabilities

acroread: multiple vulnerabilities

Comments (1 posted)

apache2: information disclosure

Comments (2 posted)

apache: multiple vulnerabilities

Comments (1 posted)

apache: cross-site scripting

Comments (none posted)

apache: several vulnerabilities

Comments (1 posted)

apache2: denial of service

Comments (1 posted)

httpd: denial of service, cross-site scripting

Comments (none posted)

asterisk: possible SQL injection

Comments (none posted)

avahi: denial of service

Comments (none posted)

bind: insecure permissions

Comments (1 posted)

cacti: SQL injection vulnerability

Comments (none posted)

cacti: denial of service

Comments (none posted)

cairo: integer overflow

Comments (none posted)

clamav: denial of service

Comments (none posted)

clamav: multiple vulnerabilities

Comments (none posted)

clamav: mystery vulnerability

Comments (1 posted)

clamav: integer overflow and off-by-one

Comments (none posted)

claws-mail: insecure temp file

Comments (none posted)

cpio: arbitrary code execution

Comments (none posted)

vixie-cron: privilege escalation

Comments (1 posted)

cscope: buffer overflows

Comments (none posted)

cscope: buffer overflows

Comments (1 posted)

cups: denial of service

Comments (none posted)

cups: buffer overflow

Comments (1 posted)

cups: multiple vulnerabilities

Comments (none posted)

debian-goodies: privilege escalation

Comments (none posted)

Django: denial of service

Comments (none posted)

dovecot: privilege escalation

Comments (none posted)

dovecot: directory traversal

Comments (none posted)

dovecot: multiple vulnerabilities

Comments (none posted)

drupal: multiple vulnerabilities

Update to 5.6, security fixes:

DRUPAL-SA-2008-005
DRUPAL-SA-2008-006
DRUPAL-SA-2008-007

Comments (none posted)

e2fsprogs: integer overflows

Comments (none posted)

eggdrop: stack-based buffer overflow

Comments (none posted)

elinks: code execution

Comments (none posted)

elinks: arbitrary file access

Comments (none posted)

emacs: buffer overflow

Comments (none posted)

emacs: command execution via local variables

Comments (1 posted)

evolution: format string error

Comments (1 posted)

pop mail man-in-the-middle attacks

Comments (none posted)

exiftags: multiple vulnerabilities

Comments (none posted)

exiv2: integer overflow

Comments (none posted)

fail2ban: denial of service

Comments (none posted)

fetchmail: denial of service

Comments (none posted)

firebird: buffer overflow

Comments (none posted)

firefox: multiple vulnerabilities

Comments (none posted)

firefox: multiple vulnerabilities

Comments (1 posted)

firefox, thunderbird, seamonkey: multiple vulnerabilities

Comments (none posted)

flac: arbitrary code execution

Comments (none posted)

flash-plugin: lots of problems

Comments (3 posted)

freetype: arbitrary code execution

Comments (none posted)

freetype: integer overflows

Comments (none posted)

gallery2: multiple vulnerabilities

Comments (none posted)

gcc: file overwrite vulnerability

Comments (none posted)

gd: buffer overflow

Comments (2 posted)

gd: multiple vulnerabilities

Comments (none posted)

gd: denial of service

Comments (none posted)

gedit: format string vulnerability

Comments (1 posted)

gforge: SQL injection

Comments (none posted)

gftp: buffer overflows

Comments (none posted)

gimp: multiple vulnerabilities

Comments (none posted)

gnome-screensaver: keyboard lock bypass

Comments (none posted)

openssh: inappropriate use of trusted cookies

Comments (none posted)

grip: buffer overflow

Comments (none posted)

gzip: multiple vulnerabilities

Comments (1 posted)

horde-kronolith: local file inclusion

Comments (none posted)

httpd: cross-site scripting, denial of service

Comments (1 posted)

imagemagick: multiple vulnerabilities

Comments (none posted)

ImageMagick: integer overflows

Comments (none posted)

jasper: denial of service

Comments (none posted)

java: multiple vulnerabilities

Comments (1 posted)

java-1.5.0-sun: multiple vulnerabilities

Comments (none posted)

java-1.5.0-sun: multiple vulnerabilities

Comments (1 posted)

JRockit: multiple vulnerabilities

Comments (none posted)

kdebase: denial of service

Comments (none posted)

kdelibs: kate backup file permission leak

Comments (1 posted)

kernel: out-of-bounds access

Comments (none posted)

kernel: ALSA returns incorrect write size

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: remote denial of service

Comments (1 posted)

kernel: several vulnerabilities

Comments (none posted)

kernel: signal handling flaw on PPC

Comments (none posted)

kernel: several vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service