got underway on
November 29. The conference got off to a bit of a rough start;
funding problems and travel hassles led to the last-minute cancellation of
a number of talks.
On opening day, glitches in the registration process resulted in hundreds of
attendees standing in line under the strong Bangalore sun while the
(already delayed) sessions began without them. These little problems
notwithstanding, FOSS.IN has the look of a successful conference.
Frequent attendees of technical conferences become used to spending their
days in closed auditoriums and cavernous ballrooms. FOSS.IN, instead,
consists of temporary buildings (essentially large, canvas tents with steel
frames) set up in a dirt field. The Bangalore Palace makes an interesting
backdrop for the event, but it hosts only a few of the sessions. Dogs wander between
the lecture halls, though the cows have, so far, avoided the area in favor
of the traffic-choked roads nearby. Inside, the conference buildings have
all the usual facilities; they are a pleasantly airy space. Just watch out
for the rough floor.
If there is an underlying theme to this event, it is participation.
India's presence in the free software community, and its contributions to
that community, are relatively small relative to its population and its use
of free software. The conference's organizers and speakers would like to
change that. In the opening remarks, organizer Atul Chitnis noted that, if
even ten members of the audience were motivated to start hacking and giving
back to the community, the event could be considered to be a success.
Alan Cox's opening talk on participation focused on nuts and bolts - how
people can participate in the community. There are plenty of reasons for
wanting to be a part of the process, according to Alan. Helping a free
software project can be a way to learn skills, explore ideas and their
implementations, have fun, create employment opportunities, and work for
social good. Writing code is the first and foremost way of participating,
and Alan dispensed a fair amount of advice on how that is best done. But
he also took time to point out the many other ways to help, most of which
do not require programming skills. These range from reporting bugs
through writing documentation, translations and localization, creating
artwork, and helping to maintain the infrastructure needed by free software
projects. Localization was pointed out as an area in constant need of
work. India has a long list of languages to translate into, and the
Indians are the only ones who are well positioned to get that work done.
Danese Cooper continued the participation theme with a talk on "gorilla
tactics." A gorilla, in her terminology, is somebody who stands up for
what is right and helps to push free software forward. Being a gorilla can
hurt sometimes, but it is worth it.
Example: quite a few companies in India are doing free software work, but
they are not contributing their changes back. Many of them, it
seems, are afraid of the possibility that the community might fork their
code. Indian companies fear that possibility so much that they are unable
to relinquish control, and, as a result, keep their code to themselves.
These companies need gorillas, somebody who will make the case for letting
go and giving the code back to the community.
Another problem in need of attention is universities which make claims on
the work done by their students. These universities need to let go and let
their students take their ideas forward. The reputational benefit to the
universities will far exceed the benefits of any revenue which might come
Danese is also concerned about the number of Indian startups which target
the American market. Yes, that market is large, but it is also distant and
highly competitive. Indians would be better advised to work on problems in
The talk also discussed reasons for participating.
By participating in the free software community, countries like India can
reap benefits beyond simply avoiding license payments to distant
companies. Working on free software helps to improve the population's
technical skills. The development of local expertise will lead to local
wealth creation, and the establishment of a reputation for strong software
Zaheda Bhorat talked about how Google participates in the free software
process. The talk covered Google's reasons (most of which will be well
familiar to LWN readers), some of Google's released code (found on code.google.com, and various other
things Google is doing to help. There was also a lengthy discussion of the
"Summer of Code" program and the benefits that have come from it. There
were a few Indian participants in the Summer of Code, but far fewer than
from the US and Europe. Zaheda would like to see that change for any
A final inducement to participation could be seen in the small exposition
area. Many of the participating companies had the obligatory product and
service brochures, but quite a few of them are also using their booths to
recruit developers. It would seem that, for Indian hackers with free
software skills, now is a good time to be looking for a job.
Comments (4 posted)
There are standards and there are standards. They are not all born
What makes one standard open and not another?
Massachusetts, when deciding
to use the OpenDocument Format, as set forth in its Enterprise
Information Technology Architecture (ETRM) document
set the bar here:
[Secretary of Administration
& Finance for the Commonwealth of Massachusetts Eric] Kriss emphasized,
however, that the state is not moving to open standards for economic
reasons but to protect the right of the public to open and free access
to public documents for the foreseeable future. "What we've backed away
from at this point is the use of a proprietary standard and we want
standards that are published and free of legal encumbrances, and we
dont want two standards," Kriss said.
A recent statement
by the Governor's office in Massachusetts, expressing optimistic
hopes that Microsoft's Office Open XML document formats will meet
their standard for an "open format" someday raises two questions: Is
the Microsoft covenant not to
sue, assuming it is someday offered for their new version of XML
schemas, and their plans to submit their XML to standards bodies ECMA
and ISO sufficient to meet the Massachusetts requirements for openness?
If so, what are the implications for the Internet? If not, will
Massachusetts decide their bar was set too high, in order to include
Microsoft? If the bar was set too high, which part shall we lop off?
Shall we say the public has no right to open and
free access to documents their tax money paid for?
Massachusetts has a Public
[PDF] that mandates
[PDF] that "all people have an absolute right of access to public
information". The law doesn't distinguish between paper documents and
digital documents. The disabled have a right of access, but so do the
rest of us.
Are proprietary standards acceptable if
nonproprietary, universally available standards are available?
Can a government dictate which operating system you have to
use to access those documents? More pointedly, can it favor one
proprietary vendor and compel citizens to spend money on a proprietary
system, when they already have a perfectly functional operating system
on their computers already?
We already saw in the Katrina disaster
what happens when a government agency enables Windows-only access. I
wrote about that in "When
Open Standards Really Matter: the Katrina Factor", which begins like
this, trying to explain why standards matter:
If you have
any doubts about the direction Massachusetts is following in requiring
open standards for all government documents, consider what happened when
Hurricane Katrina knocked out almost all communications except the
Internet. Cell phones and walkie talkies failed, once again, just as
they did in 9/11, as David Kirkpatrick tells us in an article in
In the immediate aftermath of the hurricane, much of the regions
communication systems failed or didnt work properly. Water and wind
knocked out power, toppled phone lines, and destroyed cellphone towers.
What systems remained were quickly overwhelmed. When rescue workers did
have working equipment, like walkie-talkies, they often couldnt connect
with others on different communication systems.
Catch that? "On different communication systems." The same thing
happened after the tsunami disaster in Thailand, as a report just
released by the ePolicy Group reports:
"Responding agencies and nongovernmental groups are unable to share
information vital to the rescue effort," the report recalls of the
government in Thailand in the tsunami's immediate aftermath. "Each uses
different data and document formats. Relief is slowed; coordination is
complicated. The need for common, open standards for disaster management
was never more stark or compelling."
Isn't it time, after so much suffering, to recognize that keeping people
alive is more important than allowing private companies to lock in
customers into proprietary systems that don't then work in an emergency?
And why does the Internet always work, no matter who you are or what
operating system you use? Because it was built, not on proprietary
standards, but entirely on open standards. That's why you can send an
email to me, even if you are using Microsoft Outlook. I don't run any
Microsoft products currently, but because of open standards, I can still
read your email, and in an emergency, we will not be disconnected
because we are on "different communication systems."
Accepting Microsoft's proprietary XML *with its proprietary extensions*
as the language of the Internet would certainly alter the openness and
universality of the Internet. Proprietary, by definition, means it
isn't universal. Is that what we want? If Massachusetts accepts
proprietary extensions, it will inevitably be excluding some of its
citizens, I think.
Can any government, including Massachusetts, in
the Internet age, justify telling its citizens, by the decisions it
makes, that they must stop using their operating system of choice --
one used by millions all over the world -- and instead purchase a
proprietary vendor's product instead if they wish to interact with
their government? In any case, in an emergency, it may not be possible
to quickly buy a Windows operating system. People use what they have.
Sometimes it's all they have access to; sometimes it's all they can
afford. On what basis would you argue a government should do that?
More pointedly, on what *legal* basis would you argue they can?
Should Massachusetts wait for a future, yet-to-be-developed
proprietary standard, not yet published, on terms that are not yet
fully known, controlled by a single vendor, when you have one that is
vendor-neutral and is already available? On what basis could the
Commonwealth justify such favoritism to a single company? In the FAQ on
the Commonwealth's ETRM, they state this:
The Final ETRM
Version 3.5 does not require that agencies use only one office product.
To the contrary, it offers agencies many choices. Agencies may choose to
retain their existing MS Office licenses, as long as they use a method
to save documents in Open Document Format. They may also use one of the
many office tools that support Open Document Format in native format---
OpenOffice, StarOffice, KOffice, Abiword, eZ publish, IBM Workplace,
Knomos case management, Scribus DTP, TextMaker and Visioo Writer.
Because the Open Document Format is an open standard, it increases the
vendor pool available to state agencies by encouraging and permitting
vendors not already in this field to develop products that support the
standard. Adoption of the Final ETRM Version 3.5 will greatly
increase competition among vendors for the sale of office applications
What about legal
There are still questions
on the MS XML and related licenses and EULAs. Is that
going to be the part Massachusetts should wink at? They'd likely be
sued if they tried, I think, and I doubt they will try, because it would
be impossible to justify it in public, for one thing. That's the kind
of thing that only works in back rooms, and nothing about this process
will be hidden from the public's gaze.
On the issue of license
clarity, obviously, if you can't understand the license, you won't dare
to use the standard. I don't understand all the legalities of
Microsoft's covenant not to sue and I don't know anyone who does. The
danger is in establishing a standard that would, in effect, block Linux
and GNU/Linux developers from participation. Do you imagine that could
never happen? Consider your history.
Remember the SenderID
flap? Who was to be left out in the EU Commissioner-MS deal?
Do you really want to set up a world where Linux could never happen
again, a world where the Linux we have is exiled to the backwaters of
technology? Just being an ECMA standard doesn't mean it is open
enough for *government* use. ECMA standards, by their own self-description, are for
Ecma is driven by industry to meet the needs
of industry, generating a healthy competitive landscape based on
differentiation of products and services, rather than technology models,
generating confidence among vendors and users of new
The needs of government are not identical
to the needs of industry. It's up to industry to meet the needs of
government, not the other way around. The government is the customer,
after all, so they get to state what they need in a product and to
choose whatever meets their needs best.
Finally, shall we have two standards?
That seems to be
what they are leaning toward. The Commonwealth has already stated that
the disabled can continue to use Microsoft's products, if there are no
better options they like, so that might be one area of carve-out. From
what I've heard, however, that will be a solved problem for ODF by the
time of the 2007 rollout. So again, the issue is going to be: should a
government favor a proprietary solution, when there is a universally
available solution that isn't proprietary and excludes no one? Tim
Bray has made a
The ideal outcome would be a common
shared office-XML dialect for the basicsand it should be ODF (or a
subset), since thats been designed and debuggedthen another extended
vocabulary to support Microsoft features , whether theyre cool new
whizzy features or mouldy old legacy features (XML Namespaces are
designed to support exactly this kind of thing). That way, if you stayed
with the basic stuff youd never need to worry about software lock-in;
the difference between portable and proprietary would be crystal-clear.
And, for the basic stuff that everybody uses, thered be only one set of
This outcome is technically feasible. Who could possibly be against
Let's think about what we should look for in a
standard, what elements justify even calling it a standard. I'd like to
redefine the issue, if I may. I think the sine qua non for a
standard isn't whether it's open or proprietary. If, for example,
Microsoft can open up its XML to match ODF's, that's fine with me. The
real issue isn't openness alone. It's universality. Let me explain.
In trying to understand fully the standards issue in Massachusetts, I
came across a helpful list on Bob Sutor's blog
dating back to September. I hadn't read it, and perhaps you didn't
either, so I'd like to provide here the danger signs that a standard
isn't as open as it needs to be. I think it's pertinent, because
Microsoft folks are telling the world that by applying to ECMA, the
conversation about whether their XML is open enough should be over.
It's only just beginning, actually, as they will discover.
Consequently, let's list the elements Sutor provides that indicate there
is a problem with a standard and you can judge for yourself:
In practice, I think it is probably easiest to tell when a
standards effort is less open than you think it should be. Here are some
control by a single vendor,
- overly complicated license agreements,
- license agreements that reserve certain special rights to
individuals or vendors,
- license agreements that prevent some kinds of implementations,
- overly complicated procedural rules that can allow people to be less
democratic than they should,
- a history of disregard for backward compatibility,
- costs of participation that exclude individuals or small organizations,
- high costs of obtaining copies of the standards,
- standard specifications not being openly available online,
- for XML-based standards, allowance for proprietary, vendor-specific
I see at least 6 items that
would apply to Microsoft's XML. I'm sure I don't have to underline for
you that the last is the deal-breaker, proprietary extensions. It's not
a standard unless it's universally available and usable by everyone. The
whole point of a standard is interoperability. Can everyone use it and
have it work? Proprietary extensions, by definition, hamper
The real question to me isn't just whether a
standard is open. That's a
continuum anyway, with various degrees of openness. The real
question that matters is: is it universal?
Can everyone freely use it? If not, should it be a standard?
XML Standards Impact the Internet, Not Just
When we're talking about XML, we're talking
the Internet, not just about Massachusetts, because XML is the language
of the future Internet. HTML was fine as the universal language for the
Internet for its babyhood, but the future is XML, and so any discussion
about standards for XML involve the Internet too. It's the next step,
because it enables collaborative computing and universal data exchange.
No doubt Microsoft wants its proprietary version of XML to be adopted
as a standard. But seriously, do you want the Internet's common
language to belong, in essence, to one US company? And what a company!
Ask yourself one question, and let your natural, first instinctive
response answer: Do you trust Microsoft?
If you do, kindly tell me
why, in light of their history. This is a company twice found guilty of
antitrust violations, on two continents. What should that tell you?
They had a version of the Internet too, remember? Happily no one was
foolish enough to accept it. The theme of the Internet is universality,
not proprietary walled gardens. Do you remember how Microsoft
added proprietary extensions to HTML and degraded performance for
In the ETRM document, referenced above, the
Commonwealth pointed out something very important:
Initiatives such as Homeland Security rely upon all parties
adhering to Community of Interest XML specifications, defined by open
standards bodies comprised of representatives from Government, Business
and Technology Communities. Open formats for data files ensure that
government records remain independent of underlying systems and
applications thereby preserving their accessibility over very long
periods of time.
Do you really think the Internet
language should be determined by just one US proprietary company
motivated by their own profit? The rest of the world will not go
along with that, even if Massachusetts were to think so. And then how
will they interchange data with countries and governments abroad?
Massachusetts will be odd man out. Accepting Microsoft's version of
XML with its proprietary extensions as the standard will thus result in
serious issues ahead.
The Internet only works well if *everyone*
uses the same language, and frankly, the whole world isn't going to
accept Microsoft's proprietary XML as that common language. Can you
imagine Europe agreeing to that? Or China? Or South America? FOSS
developers? The next question is: Do we want two standards? Two
Internets, in effect? That destroys the very purpose of the Internet,
which is universality. Can there be justification for degrading the
performance of something as important to us as utilities are for the
sole benefit of a single proprietary vendor? I understand why
Microsoft wants that, but why should you?
And there is a choice.
ODF is here right now. There is no pie in the sky about it. It's not a
year away. It's a universal standard, not vendor-controlled, which
everyone can use, including Microsoft, without having to open up in any
We're not just talking about Microsoft and
Massachusetts, then. We're talking about the Internet, which doesn't
belong to any company or any country. It's for everyone, and everyone
uses it. Because it's universally available and usable, shouldn't the
language of the Internet be universal too?
Comments (12 posted)
Your editor's computerized music collection started small - a few CDs
converted to Oggs and placed on the laptop to eliminate the need to carry a
CD player when traveling. Then the live music trading community, of which
your editor is occasionally a part, moved away from complex and unreliable
tape formats to optical media, and, increasingly, online exchange. The
digital music player showed up, replacing the old CD player as another
gadget which must be hauled (along with charger) in your editor's
increasingly heavy backpack; it brought with it a larger collection of
highly compressed music files. Over time, the pile of digital music has
become an unorganized mess of files in several formats, overflowing from
its own, dedicated disk drive. There must be, one would think, a better
In search of better ways, and looking for an excuse to listen to more music
while pretending to work, your editor delved into the world of free music
managers. The manager part of that is key: the world is full of
music players, but they are generally not helpful in organizing that
big pile of music files. Your editor would like a tool which brings some
order to the mess, makes finding and playing music easy, and helps with the
management of one or more digital audio players. The search turned up
three tools, all of which have some nice features, but none of which are,
yet, a full solution.
Before getting into the specific tools, however, please indulge your editor
with a topic which brings out his grumpiest side. Most of the tools
discussed below offer iPod support. They can move files back and forth,
interface with the on-device database, and generally perform the functions
that an iPod owner might like to do.
Your editor does not own an iPod.
None of the applications reviewed has any useful concept of working with other digital
audio players. Supporting only the iPod is as foreign to the free software
way of doing things as supporting, say, only the i386 architecture or the
Word document format. The iPod, as nice as it is, remains a highly
proprietary device in a sea of alternatives. One can understand if iPods
are supported first, since so many of them are out there; your editor very
much hopes, however, that the developers have thought a little beyond the
iPod and designed a digital audio player interface layer which is capable
of a little more flexibility.
Beyond that, few of the managers reviewed appear to have much idea that a
digital audio player is a separate domain, with, perhaps, its own rules.
These players, for example, generally require lossy, compressed audio
formats. But, when using a larger system, the idea that lossy audio is fit
to be pumped through one's $1500 (each) speaker cables is insulting at its
core. If much of one's audio collection is in lossless formats (FLAC,
say), it would be nice to be able to move files to a portable player and
have them automatically transcoded into a format that works on that
player. In the absence of such a feature, it becomes necessary to keep
music around in multiple formats - and most music managers do not deal well
Rhythmbox is a longstanding GNOME music
manager. It contains many of the expected features, but it has also been
subject to a certain amount of muttering in the GNOME ranks. The biggest
complaint appears to be that the pace of development is slower than some
would like. There have been comments to the effect that this project was
slowed down recently by external events, but that development can be
expected to pick up again soon.
The initial Rhythmbox display is sparse, essentially a large, blank
window. Gaining access to music requires "importing" it into the
"library." An entire directory tree can be imported at once, but Rhythmbox
feels the need to complain about every non-music file it finds in the
process. After the import process, the user is presented with a list of
every known track in one very long, scrolling window. There is not a great
deal of organization evident at this point.
A small button marked "show browser" opens a pair of panes allowing the
selection of a subset of tracks based on the artist and/or album. There is
also a "search" blank which restricts the list to tracks which contain (in
the artist, album, or title field) a given string. Searching can be used,
say, to find that recording of "Louie, Louie" that you know you have
somewhere, or, for fans of a certain persuasion, to get a full list of all
performances of "Dark Star" in the collection. The results form a sort of
instant playlist, so one can perform a quick search, hit "play," and get
hours of uninterrupted, out-of-tune Jerry Garcia goodness. Not that your
editor would be into such a thing, of course.
Speaking of playlists: they are created from a menu entry, and appear in
the left side pane. Creating playlists is a simple matter of dragging and
dropping songs into it. It is not possible, however, to see the contents
of a playlist and the library at the same time, so the creation process is
One obnoxious feature of Rhythmbox is how it treats albums: it sorts the
tracks by title if the track files do not, themselves, contain ordering
information. Since much on-disk music is created with file names which
describe the order of the tracks, it would be nice of Rhythmbox would use
The music player itself is functional, if rudimentary. It has repeat and
shuffle modes, as one would expect. There is a scrollbar which can be used
to move within a track, but it is strangely located far from the other
player controls. Rhythmbox, like most of the other applications reviewed
here, puts an icon in the panel tray, allowing it to
be controlled without having a window on-screen.
Rhythmbox also understands (and can "tune into") Internet
radio stations. Of course, the out-of-the-box install fails to cope with
the formats used by most stations, but some quick searching and installing
takes care of that problem. Additional features (help in finding stations,
recording from a stream) would be nice, but what's there is a start.
Rhythmbox has the ability to import tracks from CD - though it outsources
the work to SoundJuicer. It is unable to burn tracks to CD.
Rhythmbox also lacks any sort of digital audio player support; not even
the iPod is supported.
When GNOME users talk about replacing Rhythmbox, the most
commonly-suggested alternative is Banshee. Banshee is a Mono
application which is coming along quickly, but which still lacks some
The initial Banshee experience is similar to what one sees with Rhythmbox.
After an import process, a long list of tracks appears. Unlike Rhythmbox,
however, Banshee has no features for narrowing the list of tracks by artist
or album. The search facility can often be pressed into service to obtain
similar results, but it is more awkward. Playlists are handled in pretty
much the same way as in Rhythmbox. Banshee lacks Internet radio capability.
Banshee does have a couple of nice features. One of those is the ability
to edit the metadata in music files. A CD ripped using information from
one of the online databases often ends up with some very strange metadata:
it's always fun to find that whoever entered the information decided that
Led Zeppelin belongs in the "ambient" genre, or that they decided to change
the spelling of disk set name between the first and second CDs. Once you
find the metadata editor (nicely hidden as "properties" on the "view"
menu), you can fix problems like that.
By most accounts, Banshee has the best iPod support among the available
free music managers. Among other things, it understands that it may have
to transcode music as it moves it between the computer and the player.
Banshee has a few different ways of controlling the movement of music to
and from the iPod; it can be done entirely manually, or the library can be
automatically synchronized with the player.
Banshee has a CD importer built into it, and it can import to a number of
different formats. The ability to burn CDs is also there. At least, the
web page says so; the version of Banshee from the Ubuntu repository does
not appear to be able to perform either task.
Quod Libet is a GTK+
music manager written in Python. Its authors appear to place power and
extendability above eye candy.
Quod Libet resembles other managers at startup time, and users go through
the same sort of import process. Tracks are displayed in one big window.
It is possible to get a browser which narrows based on artist and album,
but the user must explicitly ask for it, and the browser is separate from
the music player controls. In fact, there are two different browsers with
very similar functionality.
When a playlist is created, a separate window is popped up; the usual
drag-and-drop mechanism will populate the list. Access to playlists is via
a pulldown menu slipped in between the player controls and the track list.
It's a somewhat awkward interface, especially as the number of playlists
The distinguishing feature found in Quod Libet, perhaps, is its plugin
mechanism. A simple Python interface makes it easy to add new features to
the system; some of the available
plugins include a song blacklist, various features for obtaining and
displaying album cover art, a CD burning feature, an AudioScrobbler client, and a simple
plugin for copying files to a portable player.
Amarok appears, as of this writing, to
be where much of the
music management action is happening. The Amarok hackers have, in a short
time, put out a number of releases of this increasingly attractive and
Amarok makes an immediate impression when it is started; the developers
have clearly put quite a bit of effort into its appearance. The interface
makes more use of color than the other music managers. It also never sits
still; like a jukebox in a bar, Amarok is always flashing lights and
generally trying to attract attention to itself. Some of the gaudier
features (like the "on-screen display" which comes up every time Amarok
starts playing a new track) can be turned off, but others (the flashing
track name in the playlist display) are seemingly permanent. The work
which has gone into creating a visually appealing tool is appreciated, but
not everybody likes flashing distractions on their screen.
Needless to say, Amarok does album covers. They can be obtained from the
net, browsed, and saved by the user, and come up with the relevant tracks
are played. It also has features for digging up song lyrics and looking up
artists in Wikipedia.
Tracks are imported into the "collection" in the usual way, but things
change after that. The music collection is displayed in the left pane in
file manager-like presentation. Nothing one might try in that pane,
however, will cause a track to be played. In Amarok, everything is a
playlist, and tracks must be added to a list before one can hear them.
Double-clicking on an album will cause all of its tracks to be moved to the
current playlist; from there, they can be heard. Individual tracks can
also be dragged over. The playlist is
cumulative, so a bit of wandering around in the collection can create a
truly eclectic selection of tracks in the list. Playlists can be saved, at
which point they appear in the hierarchical playlist display.
The playlist display includes a section for Internet radio stations.
The music player itself has seen a fair amount of development attention.
There is a small, xmms-like player window, a fancy frequency-amplitude
display, and a built-in graphic equalizer. There is also a "queue manager"
which can be used to program a sequence of tracks to be played; your editor
is not entirely clear on how this feature differs from the regular playlist
mechanism, however. There is a "dynamic playlist" feature which is poorly
documented; it appears to try to find tracks (with help from
AudioScrobbler) which are, in some way,
similar to those which are already in the playlist.
There is reasonable player support built into Amarok, but, of course, it only
supports iPods. Unlike the other players, Amarok allows the user to
configure a mount command to make the player available.
Amarok is scriptable, and has a script manager built into it. Some of the
available scripts can make the player stream out whatever is being played,
perform transcoding of audio files, and more. There is also a "transfer to
media device" script which can make Amarok move audio files to a
USB-storage device. It knows nothing about the filesystem hierarchy on the
destination device, however, not to speak of issues like encodings, so this
script is not particularly useful.
There are many other features to this tool: fancy "visualizations," CD
burning, track metadata editing, cross-fading between tracks, downloadable
themes for the "context" window, automatic track rating (who knows how it
works), basic podcast support, and more.
Hopefully the idea is clear by now.
Readers who are mainly interested in iPod support may also want to have a
look at gtkpod. Those of us with
other devices will have to be content with advanced tools like
Clearly a lot is happening in this particular "type manager" niche. That
is a good thing: computers are increasingly at the center of the audio
experience, and we are going to need good tools to keep our music
collections from looking like those piles of CDs, DATs, cassettes, records,
eight-tracks, and other media that many of us have been surrounded by for
much of our lives. The tools which are available now are far beyond what
was out there even one year ago; once again, the free software community is
showing how well it can create great applications when it gets fired up.
There is still some thinking which needs to be done in this area, however.
The Rhythmbox and Amarok developers have realized that net-based audio is
of increasing importance; their support for Internet radio streams is the
result. Amarok's podcast support is also nice, if a little hard to get
started with. Feed it an RSS file, however, and your playlist will always
have a current listing of what's available from that podcast source. Now
if we could just convince more podcasters to offer something other than the
MP3 format, things would be even nicer.
Most of us want to take our music with us, and, thanks to the availability
of high-capacity digital players, we can. The music management
application developers are still figuring out how to cope with a music
"library" which comes and goes, and which may or may not be a mirror
(perhaps in a different encoding) of a local library. And they all seem to
have difficulty with the idea that some of us folks - the more
unfashionable ones, certainly - might use something other than an iPod.
Your editor is looking forward to improvements in this area. An especially
nice thing would be a cooperation with the Rockbox project to ensure that
Rockbox-equipped players are seamlessly integrated. Given that, soon,
iPods will also be able to run Rockbox, it seems that there should be a
large enough user community to motivate some effort in that direction.
Your editor, if pressed to make a recommendation now, would have to go with
Amarok. It has a feature set and visual appeal which is unmatched
elsewhere. For those looking for a basic manager for music which lives
only on the computer, Rhythmbox is also a stable and functional
alternative. Banshee shows signs of developing into a highly capable
application, but it is not there yet. Given some time, however, along with
a broader willingness to install the whole Mono system, and Banshee may yet
push its way toward the top of the list.
Now, if you don't mind, your editor has some tunes to listen to.
Comments (80 posted)
The Free Software Foundation has sent out a press release
describing the process for the upcoming discussions on the new version of the General Public License. "After publishing the first discussion draft of the GPL in January, the FSF
will begin a structured process of eliciting feedback from the community, with
the goal of producing a final license that best defends freedom and serves
community and business. The process will include public discussion,
identification of issues, considerations of those issues, and publication of
responses. Publication of the second discussion draft is expected by summer
2006 and a last call, or final discussion draft, will be produced in the fall
of 2006. The final GPLv3 license is expected no later than spring 2007.
Comments (2 posted)
Page editor: Rebecca Sobol
Next page: Security>>