Tag Archives: Make

Polypaudio 0.9.0 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/polypaudio-0.9.0.html

We are proud to announce Polypaudio
0.9.0
. This is a major step ahead since we decided to freeze the
current API. From now on we will maintain API compability (or at least
try to). To emphasize this starting with this release the shared
library sonames are properly versioned. While Polypaudio 0.9.0 is not
API/ABI compatible with 0.8 it is protocol compatible.

Other notable changes beyond bug fixing, bug fixing and bug fixing
are: a new Open Sound System /dev/dsp wrapper named
padsp and a module module-volume-restore have been
added.

padsp works more or less like that ESOUND tool known as
esddsp. However, it is much cleaner in design and thus works
with many more applications than the original tool. Proper locking is
implemented which allows it to work in multithreaded applications. In
addition to mere /dev/dsp emulation it wraps
/dev/sndstat and /dev/mixer. Proper synchronization
primitives are also available, which enables lip-sync movie playback
using padsp on mplayer. Other applications that are
known to work properly with padsp are aumix,
libao, XMMS, sox. There are some things
padsp doesn’t support (yet): that’s most notably recording,
and mmap() wrapping. Recording will be added in a later
version. mmap() support is available in esddsp but
not in padsp. I am reluctant to add support for this, because
it cannot work properly when it comes to playback latency
handling. However, latency handling this the primary reasoning for
using mmap(). In addition the hack that is included in
esddsp works only for Quake2 and Quake3, both being Free
Software now. It probably makes more sense to fix those two games than
implementing a really dirty hack in padsp. Remember that you
can always use the original esddsp tools since Polypaudio
offers full protocol compatibility with ESOUND.

module-volume-restore is a small module that stores the
volume of all playback streams and restores them when the applications
which created them creates a new stream. If this module is loaded,
Polypaudio will make sure that you Gaim sounds are always played at
low volume, while your XMMS music is always played at full volume.

Besides the new release of Polypaudio itself we released a bunch of
other packages to work with the new release:

  • gst-polyp
    0.9.0
    , a Polypaudio plugin for GStreamer 0.10. The
    plugin is quite sophisticated. In fact it is probably the only
    sink/source plugin for GStreamer that reaches the functionality of the
    ALSA plugin that is shipped with upstream. It implements the
    GstPropertyProbe and GstImplementsInterface
    interfaces, which allow gnome-volume-meter and other
    GStreamer tools to control the volume of a Polypaudio server. The sink
    element listens for GST_EVENT_TAG events, and can thus use
    ID3 tags and other meta data to name the playback stream in the
    Polypaudio server. This is useful to identify the stream in the Polypaudio
    Volume Control
    . In short: Polypaudio 0.9.0 now offers first class
    integration into GStreamer.
  • libao-polyp
    0.9.0
    , a simple plugin for libao, which is used for audio playback by tools like ogg123 and Gaim, besides others.
  • xmms-polyp
    0.9.0
    , an output plugin for XMMS. As special feature it uses the
    currently played song name for naming the audio stream in
    Polypaudio.
  • Polypaudio Manager 0.9.0, updated for Polypaudio 0.9.0
  • Polypaudio Volume Control 0.9.0, updated for Polypaudio 0.9.0
  • Polypaudio Volume Meter 0.9.0, updated for Polypaudio 0.9.0

A screenshot showing most of this in action:

Polypaudio Screenshot.

This screenshot shows: the Polypaudio Manager, the Polypaudio
Volume Control, the Polypaudio Volume Meter, the XMMS plugin, the
GStreamer plugin used by Rhythmbox and gstreamer-properties,
pacat playing some noise from /dev/urandom,
padsp used on MPlayer. (This screenshot actually shows some
post-0.9.0 work, like the icons used by the application windows)

Polypaudio 0.8 Released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/polypaudio-0.8.html

The reports of Polypaudio’s death are greatly exaggerated.

We are proud to announce the release of Polypaudio
0.8, our networked sound daemon for Linux, other Unix-like operating
systems, and Microsoft Windows. Since the last official release, 0.7,
more than a year has passed. In the meantime Polypaudio experienced
major improvements. Major contributions have been made by both Pierre
Ossman and me. Pierre is being payed by Cendio AB to work on
Polypaudio. Cendio distributes Polypaudio along with their ThinLinc Terminal
Server
.

Some of the major changes:

New playback buffer model that allows applications to freely seek in
the server side playback buffer (both with relative and absolute indexes) and to synchronize
multiple streams together, in a way that the playback times are guaranteed to
stay synchronized even in the case of a buffer underrun. (Lennart)

Ported to Microsoft Windows and Sun Solaris (Pierre)

Many inner loops (like sample type conversions) have been ported
to liboil, which
enables us to take advantage of modern SIMD instruction sets, like MMX or SSE/SSE2. (Lennart)

Support for channel maps which allow applications to assign
specific speaker positions to logical channels. This enables support
for “surround sound”. In addition we now support seperate volumes for
all channels. (Lennart)

Support for hardware volume control for drivers that support
it. (Lennart, Pierre)

Local users may now be authenticated just by the membership in a
UNIX group, without the need to exchange authentication cookies. (Lennart)

A new driver module module-detect which detects
automatically what local output devices are available and loads the
needed drivers. Supports ALSA, OSS, Solaris and Win32 devices. (Lennart, Pierre)

Two new modules implementing RTP/SDP/SAP based multicast audio
streaming. Useful for streaming music to multiple PCs with speakers
simultaneously. Or for implementing a simple “always-on” conferencing
solution for the LAN. Or for sharing a single MIC/LINE-IN jack on the
LAN. (Lennart)

Two new modules for connecting Polypaudio to a JACK audio server
(Lennart)

A new Zeroconf (mDNS/DNS-SD) publisher module. (Lennart)

A new module to control the volume of an output sink with a LIRC supported infrared remote
control, and another one for doing so with a multimeda keyboard. (Lennart)

Support for resolving remote host names asynchronously using libasyncns. (Lennart)

A simple proof-of-concept HTTP module, which dumps the current daemon status to HTML. (Lennart)

Add proper validity checking of passed parameter to every single
API functions. (Lennart)

Last but not least, the documentation has been beefed up a lot and
is no longer just a simple doxygen-based API documentation (Pierre, Lennart)

Sounds good, doesn’t it? But that’s not all!

We’re really excited about this new Polypaudio release. However,
there are more very exciting, good news in the Polypaudio world. Pierre
implemented a Polypaudio plugin for alsa-libs. This means you
may now use any ALSA-aware application to access a Polypaudio sound
server! The patch has already merged upstream, and will probably
appear in the next official release of alsa-plugins.

Due to the massive internal changes we had to make a lot of modifications to
the public API. Hence applications which currently make use of the Polypaudio
0.7 API need to be updated. The patches or packages I maintain will be updated
in the next weeks one-by-one. (That is: xmms-polyp, the MPlayer patch, the
libao patch, the GStreamer patch and the PortAudio patch)

A side note: I wonder what this new release means for Polypaudio in
Debian. I’ve never been informed by the Debian maintainers of
Polypaudio that it has been uploaded to Debian, and never of the
removal either. In fact I never exchanged a single line with those who
were the Debian maintainers of Polypaudio. Is this the intended way
how the Debian project wants its developers to communicate with
upstream? I doubt that!

How does Polypaudio compare to ESOUND?

Polypaudio does everything what ESOUND does, and much more. It is a
fully compatible drop-in replacement. With a small script you can make
it command line compatible (including autospawning). ESOUND clients
may connect to our daemon just like they did to the original ESOUND
daemon, since we implemented a compatibility module for the ESOUND
protocol.

Support for other well known networked audio protocols (such as
NAS) should be easy to add – if there is a need.

For a full list of the features that Polypaudio has over ESOUND,
see Polypaudio’s
homepage
.

How does Polypaudio compare to ALSA‘s dmix?

Some people might ask whether there still is a need for a sound
server in times where ALSA’s dmix plugin is available. The
answer is: yes!

Firstly, Polypaudio is networked, which dmix is
not. However, there are many reasons why Polypaudio is useful on
non-networked systems as well. Polypaudio is portable, it is available
not just for Linux but for FreeBSD, Solaris and even Microsoft
Windows. Polypaudio is extensible, there is broad range of additional
modules
available which allow the user to use Polypaudio in many
exciting ways ALSA doesn’t offer. In Polypaudio streams, devices and
other server internals can be monitored and introspected freely. The
volume of the multiple streams may be manipulated independently of
each other, which allows new exciting applications like a work-alike
of the new per-application mixer tool featured in upcoming Windows
Vista. In multi-user systems, Polypaudio offers a secure and safe way
to allow multiple users to access the sound device
simultaneously. Polypaudio may be accessed through the ESOUND and the
ALSA APIs. In addition, ALSA dmix is still not supported properly by
many ALSA clients, and is difficult to setup.

A side node: dmix forks off its own simple sound daemon
anyway, hence there is no big difference to using Polypaudio with the
ALSA plugin in auto-spawning mode. (Though admittedly, those ALSA
clients that don’t work properly with dmix, won’t do so with our ALSA
plugin as well since they actually use the ALSA API incorrectly.)

How does Polypaudio compare to JACK?

Everytime people discuss sound servers on Unix/Linux and which way
is the right to go for desktops, JACK gets mentioned and suggested by some as a
replacement for ESOUND for the desktop. However, this is not
practical. JACK is not intended to be a desktop sound server, instead
it is designed for professional audio in mind. Its semantics are
different from other sound servers: e.g. it uses exclusively floating
point samples, doesn’t deal directly with interleaved channels and
maintains a server global time-line which may be stopped and seeked
around. All that translates badly to desktop usages. JACK is really
nice software, but just not designed for the normal desktop user,
who’s not working on professional audio production.

Since we think that JACK is really a nice piece of work, we added
two new modules to Polypaudio which can be used to hook it up to a
JACK server.

Get Polypaudio 0.8, while it is hot!

BTW: We’re looking for a logo for Polypaudio. Feel free to send us your suggestions!

Update: The Debian rant is unjust to Jeff Waugh. In fact, he had informed me that he prepared Debian packages of Polypaudio. I just never realized that he had actually uploaded them to Debian. What still stands, however, is that I’ve not been informed or asked about the removal.

Polypaudio 0.8 Released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/polypaudio-0.8.html

The reports of Polypaudio’s death are greatly exaggerated.

We are proud to announce the release of Polypaudio
0.8, our networked sound daemon for Linux, other Unix-like operating
systems, and Microsoft Windows. Since the last official release, 0.7,
more than a year has passed. In the meantime Polypaudio experienced
major improvements. Major contributions have been made by both Pierre
Ossman and me. Pierre is being payed by Cendio AB to work on
Polypaudio. Cendio distributes Polypaudio along with their ThinLinc Terminal
Server
.

Some of the major changes:

  • New playback buffer model that allows applications to freely seek in
    the server side playback buffer (both with relative and absolute indexes) and to synchronize
    multiple streams together, in a way that the playback times are guaranteed to
    stay synchronized even in the case of a buffer underrun. (Lennart)
  • Ported to Microsoft Windows and Sun Solaris (Pierre)
  • Many inner loops (like sample type conversions) have been ported
    to liboil, which
    enables us to take advantage of modern SIMD instruction sets, like MMX or SSE/SSE2. (Lennart)
  • Support for channel maps which allow applications to assign
    specific speaker positions to logical channels. This enables support
    for “surround sound”. In addition we now support seperate volumes for
    all channels. (Lennart)
  • Support for hardware volume control for drivers that support
    it. (Lennart, Pierre)
  • Local users may now be authenticated just by the membership in a
    UNIX group, without the need to exchange authentication cookies. (Lennart)
  • A new driver module module-detect which detects
    automatically what local output devices are available and loads the
    needed drivers. Supports ALSA, OSS, Solaris and Win32 devices. (Lennart, Pierre)
  • Two new modules implementing RTP/SDP/SAP based multicast audio
    streaming. Useful for streaming music to multiple PCs with speakers
    simultaneously. Or for implementing a simple “always-on” conferencing
    solution for the LAN. Or for sharing a single MIC/LINE-IN jack on the
    LAN. (Lennart)
  • Two new modules for connecting Polypaudio to a JACK audio server
    (Lennart)
  • A new Zeroconf (mDNS/DNS-SD) publisher module. (Lennart)
  • A new module to control the volume of an output sink with a LIRC supported infrared remote
    control, and another one for doing so with a multimeda keyboard. (Lennart)
  • Support for resolving remote host names asynchronously using libasyncns. (Lennart)
  • A simple proof-of-concept HTTP module, which dumps the current daemon status to HTML. (Lennart)
  • Add proper validity checking of passed parameter to every single
    API functions. (Lennart)
  • Last but not least, the documentation has been beefed up a lot and
    is no longer just a simple doxygen-based API documentation (Pierre, Lennart)

Sounds good, doesn’t it? But that’s not all!

We’re really excited about this new Polypaudio release. However,
there are more very exciting, good news in the Polypaudio world. Pierre
implemented a Polypaudio plugin for alsa-libs. This means you
may now use any ALSA-aware application to access a Polypaudio sound
server! The patch has already merged upstream, and will probably
appear in the next official release of alsa-plugins.

Due to the massive internal changes we had to make a lot of modifications to
the public API. Hence applications which currently make use of the Polypaudio
0.7 API need to be updated. The patches or packages I maintain will be updated
in the next weeks one-by-one. (That is: xmms-polyp, the MPlayer patch, the
libao patch, the GStreamer patch and the PortAudio patch)

A side note: I wonder what this new release means for Polypaudio in
Debian. I’ve never been informed by the Debian maintainers of
Polypaudio that it has been uploaded to Debian, and never of the
removal either. In fact I never exchanged a single line with those who
were the Debian maintainers of Polypaudio. Is this the intended way
how the Debian project wants its developers to communicate with
upstream? I doubt that!

How does Polypaudio compare to ESOUND?

Polypaudio does everything what ESOUND does, and much more. It is a
fully compatible drop-in replacement. With a small script you can make
it command line compatible (including autospawning). ESOUND clients
may connect to our daemon just like they did to the original ESOUND
daemon, since we implemented a compatibility module for the ESOUND
protocol.

Support for other well known networked audio protocols (such as
NAS) should be easy to add – if there is a need.

For a full list of the features that Polypaudio has over ESOUND,
see Polypaudio’s
homepage
.

How does Polypaudio compare to ALSA‘s dmix?

Some people might ask whether there still is a need for a sound
server in times where ALSA’s dmix plugin is available. The
answer is: yes!

Firstly, Polypaudio is networked, which dmix is
not. However, there are many reasons why Polypaudio is useful on
non-networked systems as well. Polypaudio is portable, it is available
not just for Linux but for FreeBSD, Solaris and even Microsoft
Windows. Polypaudio is extensible, there is broad range of additional
modules
available which allow the user to use Polypaudio in many
exciting ways ALSA doesn’t offer. In Polypaudio streams, devices and
other server internals can be monitored and introspected freely. The
volume of the multiple streams may be manipulated independently of
each other, which allows new exciting applications like a work-alike
of the new per-application mixer tool featured in upcoming Windows
Vista. In multi-user systems, Polypaudio offers a secure and safe way
to allow multiple users to access the sound device
simultaneously. Polypaudio may be accessed through the ESOUND and the
ALSA APIs. In addition, ALSA dmix is still not supported properly by
many ALSA clients, and is difficult to setup.

A side node: dmix forks off its own simple sound daemon
anyway, hence there is no big difference to using Polypaudio with the
ALSA plugin in auto-spawning mode. (Though admittedly, those ALSA
clients that don’t work properly with dmix, won’t do so with our ALSA
plugin as well since they actually use the ALSA API incorrectly.)

How does Polypaudio compare to JACK?

Everytime people discuss sound servers on Unix/Linux and which way
is the right to go for desktops, JACK gets mentioned and suggested by some as a
replacement for ESOUND for the desktop. However, this is not
practical. JACK is not intended to be a desktop sound server, instead
it is designed for professional audio in mind. Its semantics are
different from other sound servers: e.g. it uses exclusively floating
point samples, doesn’t deal directly with interleaved channels and
maintains a server global time-line which may be stopped and seeked
around. All that translates badly to desktop usages. JACK is really
nice software, but just not designed for the normal desktop user,
who’s not working on professional audio production.

Since we think that JACK is really a nice piece of work, we added
two new modules to Polypaudio which can be used to hook it up to a
JACK server.

Get Polypaudio 0.8, while it is hot!

BTW: We’re looking for a logo for Polypaudio. Feel free to send us your suggestions!

Update: The Debian rant is unjust to Jeff Waugh. In fact, he had informed me that he prepared Debian packages of Polypaudio. I just never realized that he had actually uploaded them to Debian. What still stands, however, is that I’ve not been informed or asked about the removal.

Adding Extended Attribute Support to Apache 2.0

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/mod-mime-xattr.html

I updated my little Apache module mod_mime_xattr to be compatible with Apache 2.0.

What is it useful for? Linux (2.4 with patch, 2.6 out-of-the-box) has been supporting extended attributes for files (EAs) for ages, but very few applications use them. To change that I wrote a small module for Apache which interpretes the EA user.mime_type and uses its value as MIME type for all files served by Apache. The EA has been standardized by the XDG MIME system, but apparently neither Gnome nor KDE support it right now.

Usage of mod_mime_xattr is simple. To enable interpretation of the EA on the entire tree use something like this in your Apache configuration file:

<Directory />
XAttrMimeType On
</Directory>

That’s all that is required to make use of user.mime_type on all files where it is set. To set the EA use a command like this one:

setfattr -n “user.mime_type” -v “text/html” foo.txt

And foo.txt will become a file with the MIME type of text/html, although its suffix is .txt!

Adding Extended Attribute Support to Apache 2.0

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/mod-mime-xattr.html

I updated my little Apache module mod_mime_xattr to be compatible with Apache 2.0.

What is it useful for? Linux (2.4 with patch, 2.6 out-of-the-box) has been supporting extended attributes for files (EAs) for ages, but very few applications use them. To change that I wrote a small module for Apache which interpretes the EA user.mime_type and uses its value as MIME type for all files served by Apache. The EA has been standardized by the XDG MIME system, but apparently neither Gnome nor KDE support it right now.

Usage of mod_mime_xattr is simple. To enable interpretation of the EA on the entire tree use something like this in your Apache configuration file:

<Directory />
XAttrMimeType On
</Directory>

That’s all that is required to make use of user.mime_type on all files where it is set. To set the EA use a command like this one:

setfattr -n "user.mime_type" -v "text/html" foo.txt

And foo.txt will become a file with the MIME type of text/html, although its suffix is .txt!

Avahi Gains Compatibility Layers for Apple Bonjour and HOWL

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-compat.html

A short while ago I checked in to SVN two API/ABI compatibility
modules which implement the HOWL and the Apple
Bonjour (dns_sd.h)
DNS-SD/mDNS APIs on top of Avahi’s
native API. Effectively this means that you can run *all*
Zeroconf-enabled software that is available for free operating systems
seamlessly on top of Avahi. Or at least the software that uses the
limited subset of API functions we support. Missing functions will be
implemented on an on-demand basis. Gnome-VFS/Nautilus works
perfectly, as does Gobby, which are the only real-world applications
we tested until now.

The list of supported/unsupported functions is available from SVN for HOWL and for
dns-sd.h.

The compatibility layers are actually pretty interesting pieces of code: for
compatibility with the way HOWL/Bonjour integrates with event loops we had to
hook up the timeout and I/O watches D-BUS depends on to a single file
descriptor. This involves all kinds of ugly things like threading and
“creative” ways to use the event loop abstraction Avahi provides. Some might
call this “cracktastic”, but it actually works pretty well.

The compatibility layers are not intended to be long term solutions. For
every session object we create a background thread that polls for events and a
DBUS session object. This is an utter waste of resources, especially on
dns_sd.h where every basic operation uses a session object of its own.
In addition, our compatibility layers are incomplete. We do not offer the full
set of functions or the full semantics. Our compatibility is just good enough
to make most Zeroconf-aware programs work with Avahi right now.

We consider neither dns_sd.h nor the HOWL API a “well designed”
API and encourage people to port their programs to our more powerful native
API. To stress this the two modules will warn the user about their usage and
write a warning line to STDERR and syslog. Hopefully this will annoy
people sufficiently that Avahi adoption speeds up a little.

To our own surprise we actually support at least one API function more than each of the
reference implementations! From dns_sd.h we support
DNSServiceEnumerateDomains() which is actually unsupported by
Apple Bonjour on POSIX/Linux systems. The documented HOWL function
sw_ipv4_address_decompose() is actually a NOOP in the
reference implementation, but isn’t in our compatibility layer.

Since dns_sd.h is the only file licensed under a BSD license in the otherwise APSL-licensed
mDNSResponder distribution, we were able to copy it into our sources untouched.

Here’s a screenshot of
Nautilus and Gobby
running on top of Avahi through the HOWL compatibility
layers.

Avahi Gains Compatibility Layers for Apple Bonjour and HOWL

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-compat.html

A short while ago I checked in to SVN two API/ABI compatibility
modules which implement the HOWL and the Apple
Bonjour (dns_sd.h)
DNS-SD/mDNS APIs on top of Avahi’s
native API. Effectively this means that you can run *all*
Zeroconf-enabled software that is available for free operating systems
seamlessly on top of Avahi. Or at least the software that uses the
limited subset of API functions we support. Missing functions will be
implemented on an on-demand basis. Gnome-VFS/Nautilus works
perfectly, as does Gobby, which are the only real-world applications
we tested until now.

The list of supported/unsupported functions is available from SVN for HOWL and for
dns-sd.h.

The compatibility layers are actually pretty interesting pieces of code: for
compatibility with the way HOWL/Bonjour integrates with event loops we had to
hook up the timeout and I/O watches D-BUS depends on to a single file
descriptor. This involves all kinds of ugly things like threading and
“creative” ways to use the event loop abstraction Avahi provides. Some might
call this “cracktastic”, but it actually works pretty well.

The compatibility layers are not intended to be long term solutions. For
every session object we create a background thread that polls for events and a
DBUS session object. This is an utter waste of resources, especially on
dns_sd.h where every basic operation uses a session object of its own.
In addition, our compatibility layers are incomplete. We do not offer the full
set of functions or the full semantics. Our compatibility is just good enough
to make most Zeroconf-aware programs work with Avahi right now.

We consider neither dns_sd.h nor the HOWL API a “well designed”
API and encourage people to port their programs to our more powerful native
API. To stress this the two modules will warn the user about their usage and
write a warning line to STDERR and syslog. Hopefully this will annoy
people sufficiently that Avahi adoption speeds up a little.

To our own surprise we actually support at least one API function more than each of the
reference implementations! From dns_sd.h we support
DNSServiceEnumerateDomains() which is actually unsupported by
Apple Bonjour on POSIX/Linux systems. The documented HOWL function
sw_ipv4_address_decompose() is actually a NOOP in the
reference implementation, but isn’t in our compatibility layer.

Since dns_sd.h is the only file licensed under a BSD license in the otherwise APSL-licensed
mDNSResponder distribution, we were able to copy it into our sources untouched.

Here’s a screenshot of
Nautilus and Gobby
running on top of Avahi through the HOWL compatibility
layers.

Avahi 0.2 Release

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.2-release.html

Yesterday we released Avahi 0.2. Get it while it is hot! Full announcement here.

In related news: Jakub Stachowski is working on a kdnssd-to-Avahi bridge. Soon KDE applications will be able to make use of Avahi without even knowing.

Sebastien’s Zeroconf Gnome Applet now has an SVN repository: svn checkout svn://svn.0pointer.de/service-discovery-applet/trunk service-discovery-applet.

Avahi 0.2 Release

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.2-release.html

Yesterday we released Avahi 0.2. Get it while it is hot! Full announcement here.

In related news: Jakub Stachowski is working on a kdnssd-to-Avahi bridge. Soon KDE applications will be able to make use of Avahi without even knowing.

Sebastien’s Zeroconf Gnome Applet now has an SVN repository: svn checkout svn://svn.0pointer.de/service-discovery-applet/trunk service-discovery-applet.

Linking pyblosxom to SVN

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pyblosxom-svn.html

If you run a pyblosxom blog with auto-copied stories from SVN you are
probably interested in getting stable story dates that don’t change every time
you update a story. The date of the initial SVN log entry of a story is
something like the “day of birth” of a story, so it’s a good value to use.
Christopher Baus implemented a plugin for pyblosxom, which looks
overly complicated to me: it depends on memcached and comes in two large python
scripts.

To simplify things I wrote this minimal replacement:

import pysvn, os, sys, anydbm

from config import py

def get_mtime(fname):
cache_fname = os.path.join(py[‘datadir’], ‘SVNDATES’)
cache = anydbm.open(cache_fname, “c”)

if cache.has_key(fname):
d = float(cache[fname])
else:
client = pysvn.Client(fname)
l = client.log(fname)

if len(l) > 0:
d = l[0][‘date’]
cache[fname] = str(d)
else:
d = -1

del client

del cache
return d

def cb_filestat(args):
args[“mtime”] = list(args[“mtime”])
d = get_mtime(args[“filename”])
if d >= 0:
args[“mtime”][8] = d
return args

Since accessing SVN logs is quite slow the script caches the “date of birth”
in a dbm file. Make sure that your web server has enough priviliges to access
that database file which is stored in $datadir/SVNDATES by
default.

Linking pyblosxom to SVN

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pyblosxom-svn.html

If you run a pyblosxom blog with auto-copied stories from SVN you are
probably interested in getting stable story dates that don’t change every time
you update a story. The date of the initial SVN log entry of a story is
something like the “day of birth” of a story, so it’s a good value to use.
Christopher Baus implemented a plugin for pyblosxom, which looks
overly complicated to me: it depends on memcached and comes in two large python
scripts.

To simplify things I wrote this minimal replacement:

import pysvn, os, sys, anydbm

from config import py

def get_mtime(fname):
        cache_fname = os.path.join(py['datadir'], 'SVNDATES')
        cache = anydbm.open(cache_fname, "c")

        if cache.has_key(fname):
                d = float(cache[fname])
        else:
                client = pysvn.Client(fname)
                l = client.log(fname)

                if len(l) > 0:
                        d = l[0]['date']
                        cache[fname] = str(d)
                else:
                        d = -1

                del client

        del cache
        return d

def cb_filestat(args):
        args["mtime"] = list(args["mtime"])
        d = get_mtime(args["filename"])
        if d >= 0:
                args["mtime"][8] = d
        return args

Since accessing SVN logs is quite slow the script caches the “date of birth”
in a dbm file. Make sure that your web server has enough priviliges to access
that database file which is stored in $datadir/SVNDATES by
default.

Avahi 0.1 Looming

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.1.html

Avahi 0.1 is due in
the next few days. The last missing piece is a simplifying C wrapper around the
DBUS API. Though Avahi is currently pre-0.1 it is already quite complete and
mature. To put it with Ross Burton: “… this doesnt count as 0.1 because it
has docs, man pages *and* works”

Unfortunately python-dbus has quite a few bugs which make it very difficult
to code with. e.g. it doesn’t handle sending empty arrays, fails to send byte
values and so on. It is difficult to work around all these issues, therefore
the Avahi client tools will not work with an unpatched python-dbus. You need to
apply this
patch
(applying to 0.35.2) to fix at least the byte value bug to get
them working.

Avahi 0.1 Looming

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.1.html

Avahi 0.1 is due in
the next few days. The last missing piece is a simplifying C wrapper around the
DBUS API. Though Avahi is currently pre-0.1 it is already quite complete and
mature. To put it with Ross Burton: “… this doesnt count as 0.1 because it
has docs, man pages *and* works

Unfortunately python-dbus has quite a few bugs which make it very difficult
to code with. e.g. it doesn’t handle sending empty arrays, fails to send byte
values and so on. It is difficult to work around all these issues, therefore
the Avahi client tools will not work with an unpatched python-dbus. You need to
apply this
patch
(applying to 0.35.2) to fix at least the byte value bug to get
them working.

CP Technologies CP-UH-135 USB 2.0 Hub

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2005/05/10/cp-tech-usb-hub.html

I needed to pick a small, inexpensive, 2.0-compliant USB hub for myself,
and one for any of the users at my job who asked for one. I found
one, the “CP Technologies Hi-Speed USB 2.0 Hub”, which is part
number CP-UH-135. This worked great with GNU/Linux without any
trouble (using Linux 2.6.10 as distributed by Ubuntu), at least at first.


Image of the CP UH 135 USB Hub with the annoying LED coming right at you

I used this hub without too much trouble for a number of months. Then,
one day, I plugged in a very standard PS-2 to USB converter (a
cable that takes a standard PS-2 mouse and PS-2 keyboard and makes
them show up as USB devices). The hub began to heat up and the
smell of burning electronics came from it. After a few weeks, the
hub began to generate serious USB errors from the kernel named
Linux, and I finally gave up on it. I don’t recommend this hub!

Finally, it has one additional annoying drawback for me: the blue LED
power light on the side of thing is incredibly distracting. I put a
small piece of black tape over it to block it, but it only helped a
little. Such a powerful power light on a small device like that is
highly annoying. I know geeks are really into these sorts of crazy
blue LEDs, but for my part, I always feel like I am about to be assimilated by a funky post-modern
Borg
.

I am curious if there are any USB hubs out there that are more reliable
and don’t have annoying lights. I haven’t used USB hubs in the past
so I don’t know if a power LED is common. If you find one, I’d
encourage you to buy that one instead of this one. Almost anywhere
you put the thing on a desk, the LED catches your eye.

IBM xSeries EZ Swap Hard Drive Trays

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2005/05/04/ibm-xseries.html

A few days ago, I acquired a number of IBM xSeries servers — namely x206
and x226 systems — for my work at the The Software Freedom Law
Center
. We bought bare-metal, with just CPU and memory, with
plans to install drives ourselves.

I did that for a few reasons. First, serial ATA (S-ATA or SATA)
support under Linux has just become ready for prime time, and
despite being a SCSI-die-hard for most of my life, I’ve given in
that ATA’s price/performance ratio can’t really be beat, especially
if you don’t need hot swap or hardware RAID.

When I got the machines, which each came with one 80 GB S-ATA drive, I
found them well constructed, including a very easy mounting system
for hard drives. Drives have a blue plastic tray that looks like
this (follow link of image for higher resolution shot).


Image of the IBM xSeries Easy Swap Tray

These so-called “EZ Swap” trays are not for hot-swap; the big IBM swap
trays with the lever are for that. This is just to mount and unmount
drives quickly. I was impressed, and was sad that, since IBM’s goal
is to resell you hard drives, they don’t make it easy to buy these
things outright. You have to look on IBM’s
parts and upgrade site for the x206
, you’ll find that they offer
to sell 26K-7344, which is listed as a “SATA tray”, and a 73P-8007,
which is listed as a “Tray, SATA simple swap”. However, there is no
photo, and that part number does not match the part number on the item
itself. On the machines I got, the tray is numbered 73P-9591 (or
rather, P73P9591, but I think the “P” in the front is superfluous and
stands for “Part”).

I spoke to IBM tech support (at +1-800-426-7378), who told me the
replacement part number he had for that tray I had was 73P-8007.
Indeed, if you look at third
party sites, such as Spare Parts Warehouse
, you find that number
and a price of US$28 or so. Spare Parts Warehouse doesn’t even sell
the 26K-7344.

It seemed to me strange that we had two things described as SATA tray
could be that different. And the difference in price was
substantial. It costs about US$28 for the 73P-8007 and around US$7
for the 26K-7344.

So, I called IBM spare parts division at +1-800-388-7080, and ordered
one of each. They arrived by DHL this morning. Lo and behold, they
are the very same item. I cannot tell the difference
between them upon close study. The only cosmetic difference is that
they are labeled with different part numbers. The cheaper one is
labeled 26K-7343 (one number less than what I ordered) and the other
is labeled 73P-9591 (the same number that my original SATA drives
came with).

So, if you need an EZ Swap tray from IBM for the xSeries server, I
suggest you order the 26K-7344. If you do so, and find any difference
from the 73P-8007, please do let me know. Update: on 2005-06-22, a
reader told me they now charge US$12 for the 26K-7344 tray. Further
Update: The prices seem to keep rising! Another reader reported to me
on 2005-08-08 that the 26K-7344 is now US$84 (!) and the 73P-8007 is now
only US$15. So, it costs twice as much as it did a few months
ago to get these units, and the cheaper unit apperas to be the 73P-8007.
It’ll be fun to watch and see if the prices change big again in the months
to come.

When you call IBM’s spare parts division, they may give you some
trouble about ordering the part. When you call +1-800-388-7080,
they are expecting you to be an out-of-warranty customer, and make
it difficult for you to order. It depends on who you get, but you
can place an order with a credit card even without an “IBM
Out-of-Warranty Customer Number”. If you have a customer number you
got with your original IBM equipment order, that’s your warranty
customer number and is in a different database than the one used by
the IBM Spare Parts Division.

You can just tell them that you want to make a new order with a credit
card. After some trouble, they’ll do that.

The GNU GPL and the American Dream

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2001/02/21/american-dream.html

[ This essay
was originally
published on gnu.org
. ]

When I was in grade school, right here in the United States of America,
I was taught that our country was the “land of opportunity”. My teachers
told me that my country was special, because anyone with a good idea and a
drive to do good work could make a living, and be successful too. They
called it the “American Dream”.

What was the cornerstone to the “American Dream”? It was
equality — everyone had the same chance in our society to choose
their own way. I could have any career I wanted, and if I worked hard, I
would be successful.

It turned out that I had some talent for working with computers —
in particular, computer software. Indoctrinated with the “American
Dream”, I learned as much as I could about computer software. I
wanted my chance at success.

I quickly discovered though, that in many cases, not all the players in
the field of computer software were equal. By the time I entered the
field, large companies like Microsoft tended to control much of the
technology. And, that technology was available to me under licensing
agreements that forbid me to study and learn from it. I was completely
prohibited from viewing the program source code of the software.

I found out, too, that those with lots of money could negotiate
different licenses. If they paid enough, they could get permission to
study and learn from the source code. Typically, such licenses cost many
thousands of dollars, and being young and relatively poor, I was out of
luck.

After spending my early years in the software business a bit
downtrodden by my inability to learn more, I eventually discovered another
body of software that did allow me to study and learn. This software was
released under a license called the GNU General Public License (GNU
GPL). Instead of restricting my freedom to study and learn from it, this
license was specifically designed to allow me to learn. The license
ensured that no matter what happened to the public versions of the
software, I’d always be able to study its source code.

I quickly built my career around this software. I got lots of work
configuring, installing, administering, and teaching about that
software. Thanks to the GNU GPL, I always knew that I could stay
competitive in my business, because I would always be able to learn easily
about new innovations as soon as they were made. This gave me a unique
ability to innovate myself. I could innovate quickly, and impress my
employers. I was even able to start my own consulting business. My own
business! The pinnacle of the American Dream!

Thus, I was quite surprised last week
when Jim Allchin, a
vice president at
Microsoft hinted
that
the
GNU GPL
contradicted
the
American Way.

The GNU GPL is specifically designed to make sure that all
technological innovators, programmers, and software users are given equal
footing. Each high school student, independent contractor, small business,
and large corporation are given an equal chance to innovate. We all start
the race from the same point. Those people with deep understanding of the
software and an ability to make it work well for others are most likely to
succeed, and they do succeed.

That is exactly what the American Way is about, at least the way I
learned it in grade school. I hope that we won’t let Microsoft and
others change the definition.

Finished Thesis

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2001/01/22/masters-complete.html

My thesis is nearly complete. I defend tomorrow, and as usual, I let
the deadline run up until the end. I just finished my slides for the
defense, and practiced once. I have some time in the schedule tomorrow to
practice at least once, although I have to find some empty room up at the
University to do it in.

I’ll be glad to be done. It’s been annoying to spend three or four
weeks here sitting around writing about perljvm, and not hacking on it. I
have a Cosource deadline coming up this week, so now’s a good a time as
any to release the first version of the Kawa-based perljvm.

I am really excited about how Kawa works, and how easy it is to massage
perl’s IR into Kawa’s IR. I got more excited about it as I wrote my thesis
defense talk. I really think great things can happen with Kawa in the
future.

Larry Wall is here, and we’ve had two dinners for the Cincinnati
GNU/Linux Users’ Group (who paid Larry’s way to come here). I was there,
and Larry was asking some hard-ish questions about Kawa. Not hard exactly,
just things I didn’t know. I began to realize how much I have focused on
the Kawa API, and I haven’t really been digging in the internals. I told
him I’d try to have some answers about it for my defense, and I will
likely reread Bothner’s papers on the subject tomorrow to get familiar
with how he deals with various issues.

It’s odd having Larry on my thesis committee. I otherwise wouldn’t be
nervous in the least, but I am quite worried with him on the
committee.

Anyway, so I defend tommorrow, then it’s into perljvm hacking again
right away on Tuesday to make the Cosource deadline, and then I have to
finish preparing my Perl tutorial for LinuxExpo Paris.