Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/gnomevfs-future.html

One of the major construction sites in GNOME and all the other free
desktop environments is the VFS abstraction. Recently, there has been
some discussion about developing a replacement DVFS
as replacement for the venerable Gnome-VFS system. Here are my 5 euro
cent on this issue (Yepp, I am not fully up-to-date on the whole DVFS
discussion, but during my flight from HEL to HAM I wrote this up,
without being necesarily too well informed, lacking an Internet
connection. Hence, if you find that I am an uniformed idiot, you’re of
course welcome to flame me!):

First of all, we have to acknowledge that Gnome-VFS never achieved any major
adoption besides some core (not even all) GNOME applications. The reasons are
many, among them: the API wasn’t all fun, using Gnome-VFS added another
dependency to applications, KDE uses a different abstraction (KIO), and many
others. Adoption was suboptimal, and due to that user experience was
suboptimal, too (to say the least).

One of the basic problems of Gnome-VFS is that it is a (somewhat) redundant
abstraction layer over yet another abstraction layer. Gnome-VFS makes available
an API that offers more or less the same functionality as the (most of the
time) underlying POSIX API. The POSIX API is well accepted, relatively
easy-to-use, portable and very well accepted. The same is not true for
Gnome-VFS. Semantics of the translation between Gnome-VFS and POSIX are not
always that clear. Paths understood by Gnome-VFS (URLs) follow a different
model than those of the Linux kernel. Applications which understand Gnome-VFS
can deal with FTP and HTTP resources, while the majority of the applications
which do not link against Gnome-VFS does not understand it. Integration of
Gnome-VFS-speaking and POSIX-speaking applications is difficult and most of the
time only partially implementable.

So, in short: One one side we have that POSIX API which is a file system
abstraction API. And a (kernel-based) virtual file system behind it. And on the other
side we have the Gnome-VFS API which is also a file system abstraction API and
a virtual file system behind it. Hence, why did we decide to standardize on
Gnome-VFS, and not just on POSIX?

The major reason of course is that until recently accessing FTP,
HTTP and other protocol shares through the POSIX API was not doable
without special kernel patches. However, a while ago the FUSE system
has been merged into the Linux kernel and has been made available for
other operating systems as well, among them FreeBSD and MacOS X. This
allows implementing file system drivers in userspace. Currently there
are all kinds of these FUSE based file systems around, FTP and SSHFS
are only two of them. My very own fusedav tool
implements WebDAV for FUSE.

Another (*the* other?) major problem of the POSIX file system API is
its synchronous design. While that is usually not a problem for local
file systems and for high-speed network file systems such as NFS it
becomes a problem for slow network FSs such as HTTP or FTP. Having the
GUI block for various seconds while an application saves its documents
is certainly not user friendly. But, can this be fixed? Yes, definitely, it can!
Firstly, there already is the POSIX AIO interface — which however is
quite unfriendly to use (one reason is its use of Unix signals for
notification of completed IO operations). Secondly, the (Linux) kernel
people are working on a better asynchronous IO API (see the
syslets/fibrils discussion). Unfortunately it will take a while
before that new API will finally be available in upstream
kernels. However, there’s always the third solution: add an
asynchronous API entirely in userspace. This is doable in a clean (and
glib-ified) fashion: have a couple of worker threads which
(synchronously) execute the various POSIX file system functions and
add a nice, asynchronous API that can start and stop these threads,
feed them operations to execute, and so on.

So, what’s the grand solution I propose for the desktop VFS mess? First, kick
Gnome-VFS entirely and don’t replace it. Instead write a small D-Bus-accessible
daemon that organizes a special directory ~/net/. Populate that
directory with subdirectories for all WebDAV, FTP, NFS and SMB shares that can
be found on the local network using both Avahi-based browsing and native SMB
browsing. Now use the Linux automounting interface on top of that directory and
automount the respective share every time someone wants to access it. For
shares that are not announced via Avahi/Samba, add some D-Bus API (and a nice
UI) for adding arbitrary shares. NFS and CIFS/SMB shares are mounted with the
fast, optimized kernel filesystem implementation; WebDAV and FTP on the other
hand are accessed via userspace FUSE-based file systems. The latter should also
integrate with D-BUS in some way, to query the user nicely for access
credentials and suchlike, with gnome-keyring support and everything.

~/net/ itself can — but probably doesn’t need to — be a FUSE
filesystem itself.

A shared library should be made available that will implement a few
remaining things, that are not available in the POSIX file
system API directly:

• As mentioned, some nice Glib-ish asynchronous POSIX file system
  API wrapper
• High-level file system operations such as copying, moving,
  deleting (trash!) which show a nice GUI when they are long-running
  operations.
• An API to translate and setup URL <-> filesystem
  mappings, i.e. something that translates
  ftp://test.local/a/certain/path/ to
  ~/net/ftp:test.local/a/certain/path and vice versa. (and
  probably also to a more user-friendly notation, maybe like “FTP Share
  on test.local” or similar). (Needs to communicate with the ~/net/
  handling daemon to setup mappings if required)
• Meta data extraction. It makes sense to integrate that with
  extended attribute support (EA) in the kernel file system layer, which should be used more often anyway.
• Explicit mount operations (in contrast to implicit mounts, that
  are done through automounting) (this also needs to communicate with
  the ~/net/ daemon in some way)

Et voilá! Without a lot of new code you get a nice, asynchronous,
modern, well integrated file system, that doesn’t suck. (or at least,
it doesn’t suck as much as other solutions).

Also, this way we can escape the “abstraction trap”. Let’s KDE play
the abstraction game, maybe they’ll grow up eventually and learn that
abstracting abstracted abstraction layers is child’s play.

Yeah, sure, this proposed solution also has a few drawbacks, but be it that way. Here’s a short incomprehensive list:

• The POSIX file system API sucks for file systems that don’t have “inodes” or that are attached to a specific user sessions. — Yes, sure, but both problems have been overcome by the FUSE project, at least partially.
• Not that portable — Yes, but FUSE is now available for many systems besides Linux. The automount project is the bigger problem. But all you loose if you would run this proposed system on these (let’s say “legacy”) systems that don’t have FUSE or automounting is access to FTP and WebDAV shares. So what? Local files can still be accessed.
• Translating between URLs and $HOME/net/ based paths sucks — yepp, it does. But much less than not being able to access FTP/WebDAV shares from some apps but not from others, as we have it right now.
• Bah, you suck — Yes, I do. On a straw, taking a nip from my caipirinha, right at the moment.

I guess I don’t have to list all the advantages of this solution, do I?

BTW, pumping massive amounts of data through D-Bus sucks anyway.

And no, I am not going to hack on this. Too busy with other stuff.

The plane is now landing in HAM, that shall conclude our small rant.

Update: No, I didn’t get a Caipirinha during my flight. That line I
added in before publishing the blog story, which was when I was drinking my
Caipirinha. In contrast to other people from the Free Software community I don’t
own my own private jet yet, with two stewardesses that might fix me a
Caipirinha.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/what-i-miss-in-gnome.html

A while back there has been a lot of noise about the GNOME
“platform” and what GNOME 3.0 should be. Personally — while I
certainly like the progress GNOME makes as a “platform” — I must say
that the platform is already quite good. In my opinion, what is
lacking right now are more the tools and utilities that are shipped
*with* the GNOME platform than the platform itself. More specifically
there are a set of (rather small) tools I am really missing in the standard set of
GNOME tools. So, here’s my wishlist, in case anybody is interested to
know:

<wishlist>

• A simple, usable VNC/RFB client as counterpart to the VNC server
  vino that has been shipped since early GNOME 2.0 times. Isn’t
  it kind of awkward that we have been shipping a VNC server since ages,
  but no VNC client? What I want is a client (maybe called
  vinagre as a pun on vino) that is more than just a simple frontend to
  xvncviewer, but not necessarily too fancy. Something that
  integrates well into GNOME, i.e. uses D-Bus, gnome-keyring,
  avahi-ui. There seems
  to be a libvncclient library that might make the implementation of
  this tool easy.
• I am one of the (apparently not so few) people who run their GNOME
  session with LANG=de_DE and LC_MESSAGES=C, which
  enables german dates and everything else, but uses english
  messages. Right now it’s a PITA to configure GNOME that way. It’s not
  really documented how to do that, AFAIK. The best way to do this I
  found is to edit ~/.gnomerc and set the variables in there. A
  simple capplet which allows setting these environment variables from
  gnome-session would be a much better way to configure
  this. Nothing to fancy again. Just two drop down lists, to choose
  LANG and LC_MESSAGES and maybe a subset of the other
  i18n variables, and possibly G_FILENAME_ENCODING (although I
  might be the only one who still hasn’t switched his $HOME to
  UTF-8)
• There’s no world clock in GNOME. Sure, there are online tools for
  this, but I am not always online with my laptop.
• There is no simple tool to take photo snapshots or record short videos
  from webcams. I want to see something like camorama in
  gnome-media. Nothing too fancy again. No filters, no TV
  functionality. Just a small but useful GStreamer frontend.
• I’d like to see a simple BitTorrent client shipped with GNOME, which is
  integrated well into the rest of GNOME/Epiphany, so that downloading files from
  FTP or HTTP looks exactly like downloading them from Bittorrent.

</wishlist>

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

I’d love to see proper Avahi support in the Nokia N800 (just think of proper
file manager integration of announced WebDAV shares!), but until now Nokia
doesn’t ship Avahi in Maemo. However, there’s now a simple way to install at
least basic Avahi support on the N800. The INdT includes Avahi in their Canola builds. Hence: just install
Canola and your N800 will register itself via mDNS on your network.

In related news: I am happy to see that Avahi has apparently been included in the just announced GNOME Embedded Platform.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/releases-releases-releases.html

I have just released new versions of a few of my packages:

1. Avahi 0.6.18: The most interesting change is probably
   the addition of avahi-ui, our new GTK library which implements a
   standard dialog for browsing for Avahi services. A quick (albeit slightly out-of-date)
   introduction into avahi-ui (including screenshots) may be found in this old blog
   story of mine. If you are a developer of a GNOME application that acts as network
   client in some way, please consider adding support for avahi-ui to your project. Examples where adding support for avahi-ui makes sense are:
   • Mail applications such as Evolution may use it to browse for POP3, POP3S, IMAP, IMAPS and SMTP servers.
   • VNC applications may use it to browse for VNC/RFB servers
   • Database clients such as Glom may use it to browse for PostrgreSQL servers
   • FTP clients may use it to browse for FTP servers
   • RSS readers may use it to browse for local RSS feeds
   • And lots of others

   There are lots of other small and not so small changes in Avahi 0.6.18.

2. mod_dnssd 0.5: Mostly an update for Apache 2.2
3. mod_mime_xattr 0.4: dito

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/linuxtag.html

Does anybody know what’s going on with LinuxTag? I submitted a presentation
proposal a few months ago. I haven’t yet received an email whether my talk has been
accepted or not. According to their
website notification emails should have been sent out on march 13th. Which
is nearly a month ago now. When I login to the “virtual conference
center” I see that my paper is still “In Review”. They didn’t respond to my emails (twice).

Does anyone have an idea what is going on?

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/gnumeric-psfrag.html

Does anyone know what I can do to get psfrag
work with PostScript files generated from Gnumeric (i.e. Cairo) charts?

Oh, and why does Gnumeric insist on using .ps as suffix for
exported charts, although the files written are perfectly valid .eps
files and presumably everyone uses them as such?

Thanks!

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

As it seems, the Avahi project has not been
accepted as Google Summer of Code
organization, much like the GStreamer project.

Grr, I cannot say I really understand why three wiki engines ^[1] got accepted,
or a UI frontend for nmap – but not important infrastructure projects like
GStreamer or Avahi. Mhmm, maybe I am just envious, and considering these two projects important is just hybris…

Anyway, we had already prepared a list of exciting ^[2] GSoC project
ideas for Avahi. If anyone is interested to work on one of these there might be a small chance to get this done under the GNOME umbrella. Feel free to contact either me or Trent if you are interested!

Footnotes:

[1] If there is something we already have enough of in Free Software – then it is Wiki engines. just check the output of apt-cache search wiki | wc -l on a recent Debian system.

[2] In our definition of exciting, of course – which doesn’t seem to be the same as Google’s. Grrrh!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/foms-lca-recap.html

Finally, here’s my linux.conf.au 2007 and FOMS 2007
recap. Maybe a little bit late, but better late then never.

FOMS was a very well organized conference with a packed schedule
and a lot of high-profile attendees. To my surprise PulseAudio has been accepted by the
attendees without any opposition (at least none was expressed
aloud). After a few “discussions” on a few mailing lists (including
GNOME MLs) and some personal emails I got, I had thought that more
people were in opposition of the idea of having a userspace sound
daemon for the desktop. Apparently, I was overly pessimistic. Good
news, that!

During the FOMS conference we discussed the problems audio on Linux
currently has. One of the major issues still is that we’re lacking a
cross-platform PCM audio API everyone agrees on. ALSA is Linux-specific
and complicated to use. The only real contender is PortAudio. However,
PortAudio has its share of problems and hasn’t reach wide adoption
yet. Right now most larger software projects implement an audio
abstraction layer of some kind, and mostly in a very dirty, simplistic
and limited fasion. MPlayer does, Xine does it, Flash does
it. Everyone does it, and it sucks. (Note: this is only a very short
overview why audio on Linux sucks right now. For a longer one, please
have a look on the first 15mins of my PulseAudio talk at LCA, linked
below.)

Several people were asking why not to make the PulseAudio API the
new “standard” PCM API for Linux. Due to several reasons that would be a
bad idea. First of all, the PulseAudio API cannot be used on anything
else but PulseAudio. While PulseAudio has been ported to Win32, Vista
already has a userspace desktop sound server, hence running PulseAudio
on top of that doesn’t make much sense. Thus the API is not exactly
cross-platform. Secondly, I – as the guy who designed it – am not
happy with the current PulseAudio API. While it is very powerful it is
also very difficult to use and easy to misuse, mostly due to its fully
asynchronous nature. In addition it is also not the exactly smallest
API around.

So, what could be done about this? We agreed on a – maybe –
controversional solution: defining yet another abstracted PCM audio
API. Yes, fixing the problem that we have too many conflicting,
competing sound systems by defining yet another API sounds like a
paradoxon, but I do believe this is the right path to follow. Why?
Because none of the currently available solutions is suitable for all
application areas we have on Linux. Either the current APIs are not
portable, or they are horribly difficult to use properly, or have a
strange license, or are too simple in their functionality. MacOSX
managed to establish a single audio API (CoreAudio) that makes almost
everyone happy on that system – and we should be able to do same for
Linux. Secondly, none of the current APIs has been designed with
network sound servers in mind. However, proper networking support
reflects back into the API, and in a non-trivial way. An API which
works fine in networked environment needs to eliminate roundtrips
where possible, be open for time interpolation and have a flexible
buffering (besides other minor things). Thirdly none of the current
APIs offers enough functionality to properly support all the needs of
modern desktop sound systems, such as per-stream volumes, stream names
and notifications about external state changes.

During FOMS and LCA, Mikko Leppanen (from Nokia), Jean-Marc Valin
(from Xiph) and I sat down and designed a draft API for the
functionality we would like to see in this API. For the time being we
dubbed it libsydney, after the city where we started this
project. I plan to make this the only supported audio API for
PulseAudio, eventually. Thus, if you will code against PulseAudio you
will get cross-platform support for free. In addition, because
PulseAudio is now being integrated into the major distributions (at
least Ubuntu and Fedora), this library will be made available on most
systems through the backdoor.

So, what will this new API offer? Firstly, the buffering model is
much more powerful than of any current sound API. The buffering model
mostly follows PulseAudio’s internal buffering model which
(theoretically) can offer zero-latency streaming and has been
pioneered by Jim Gettys’ AF sound server. It allows you to seek around
in the playback buffer very flexibly. This is very useful to allow
very fast reaction to the user’s playback control commands while still
allowing large buffers, which are good to deal with high network
lag. In addition it is very handy for the programmer, such as when
implementing streaming clients where packets may arrive
out-of-order. The API will emulate this buffering model on top of
traditional audio devices, and when used on top of PulseAudio it will use
its native implementation. The API will also clearly define which
sound formats are guaranteed to be available, thus making it a lot
easier to code without thinking of different hardware supporting
different formats all the time. Of course, the API will be easier to
use than PulseAudio’s current API. It will be very portable, scaling
from FPU-less architectures to pro-audio machines with a massive
number of synchronised channels. There are several modes available to
deal with XRUNs semi-automatically, one of them guaranteeing that the
time axis stays linear and monotonical in all events.

The list of features of this new API is much longer, however,
enough of these grand plans! We didn’t write any real code for this
yet. To make sure that this project is not another one of those which
are announced grandiosely without ever producing any code I will stop
listing features here now. We will eventually publish a first draft of
our C API for public discussion. Stay tuned.

Side-by-side with libsydney I discussed an abstract API
for desktop event sounds with Mikko (i.e. those annoying “bing” sounds
when you click a button and the like). Dubbed libcanberra
(named after the city which one of the developers visited after
Sydney), this will hopefully be for the PulseAudio sample cache API
what libsydney is for the PulseAudio streaming API: a total
replacement.

As a by-product of the libsydney discussion Jean-Marc
coded a
fast C resampling library supporting both floating point and fixed
point and being licensed under BSD. (In contrast to
libsamplerate which is GPL and floating-point-only, but which
probably has better quality). PulseAudio will make use of this new
library, as will libsydney. And I sincerly hope that ALSA,
GStreamer and other projects replace their crappy home-grown
resamplers with this one!

For PulseAudio I was looking for a CODEC which we could use to
encode audio if we have to transfer it over the network. Such a CODEC
would need to have low CPU requirements and allow low-latency
operation, while providing hifi audio. Compression ratio is not such a
high requirement. Unfortunately, as it seems no such CODEC exists,
especially not a “Free” one. However, the Xiph people recommended to
hack up a special version of FLAC for this task. FLAC is fast, has
(obviously) good quality and if hacked up could provide low-latency
encoding. However, FLAC doesn’t compress that well. Current PulseAudio
thin-client installations require 170kB network bandwidth for each
client if hifi audio is used. Encoding this in FLAC this could cut
this in half. Not perfect, but better than nothing.

So, that was FOMS! FOMS is a definitely highly recommended
conference. If you have the chance to attend next year, don’t miss it!
I’ve never been to a more productive, packed conference in my life!

At LCA I met fellow Avahi coder Trent Lloyd for the first time. Our
talk about Avahi went very well. During my flights to and back from
.au I hacked up avahi-ui
which I also announced during that talk. Also, in related news,
tedp started to work on an implementation of NAT-PMP
(aka “reverse firewall piercing”; both client and server) for
inclusion in Avahi. This will hopefully make the upcoming Wide-Area
DNS support in Avahi much more useful.

linux.conf.au was a very exciting conference. As a speaker
you’re treated like a rock star, with stuff like the speakers dinner,
the speakers adventure (climbing on top of Sydney’s AMP tower) and
the penguin dinner. Heck, the organizers even picked me up at the
airport, something I really didn’t expect when I landed in Sydney,
which however is quite nice after a 27h flight.

Two talks I particularly enjoyed at LCA:

• nouveau – reverse engineered nvidia drivers (Ogg Theora)
• burning cpu and battery on the gnome desktop (Ogg Theora)

And just for the sake of completeness, here are the links to my presentations:

• The PulseAudio Sound Server (Ogg Theora; Slides)
• Using Avahi the “Right Way” (Ogg Theora; Slides)

Ok, that’s it for now. Thanks go to Silvia Pfeiffer, the rest of
the FOMS team and the Seven Team for organizing these two amazing
conferences!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/avahify-your-app.html

It has never been easier to add Zeroconf service discovery support to your GTK application!

The upcoming Avahi 0.6.18 will ship with a
new library libavahi-ui which contains a GTK UI dialog
AuiServiceDialog, a simple and easy-to-use dialog for
selecting Zeroconf services, similar in style to GtkFileChooserDialog and friends. This dialog should be used whenever there is an IP
server to enter in a GTK GUI. For example:

• Mail applications such as Evolution may use it to browse for POP3, POP3S, IMAP, IMAPS and SMTP servers.
• VNC applications may use it to browse for VNC/RFB servers
• Database clients such as Glom may use it to browse for PostrgreSQL servers
• FTP clients may use it to browse for FTP servers
• RSS readers may use it to browse for local RSS feeds

So, how does it look like? Here’s a screenshot of a service dialog browsing for FTP, SFTP and WebDAV shares simultaneously:

The dialog properly supports browsing in remote domains, browsing for
multiple service types at the same time (i.e. POP3 and POP3S) and supports
multi-homed services. It will also resolve the services if requested. Avahi
will ship a (very useful!) example tool zssh.c which
if started from the command line allows you to quickly browse for local SSH
servers and connect to one of those available. (Short Theora screencast of zssh –
Please excuse the strange cursor, seems to be a bug in Istanbul 0.2.1,
which BTW is totally broken on multi-headed setups):

A simple application making use of this dialog might look like this:

#include <gtk/gtk.h>
#include <avahi-ui/avahi-ui.h>

int main(int argc, char*argv[]) {
    GtkWidget *d;

    gtk_init(&argc, &argv);

    d = aui_service_dialog_new("Choose Web Service");
    aui_service_dialog_set_browse_service_types(AUI_SERVICE_DIALOG(d), "_http._tcp", "_https._tcp", NULL);

    if (gtk_dialog_run(GTK_DIALOG(d)) == GTK_RESPONSE_OK)
        g_message("Selected service name: %s; service type: %s; host name: %s; port: %u",
		aui_service_dialog_get_service_name(AUI_SERVICE_DIALOG(d)),
		aui_service_dialog_get_service_type(AUI_SERVICE_DIALOG(d)),
		aui_service_dialog_get_host_name(AUI_SERVICE_DIALOG(d)),
		aui_service_dialog_get_port(AUI_SERVICE_DIALOG(d)));
    else
        g_message("Canceled.");

    gtk_widget_destroy(d);

    return 0;
}

A more elaborate example is zssh.c. You
may browse the
full API online.

AuiServiceDialog is not perfect yet. It still lacks i18n and a11y
support. In addition it follows the HIG only very roughly. Patches welcome! I
am also very interested in feedback from more experienced GTK programmers,
since my experience with implementing GTK controls is rather limited. This is
my first GTK library which should really feel like a GTK API. So please, read
through the
API and the
implementation and send me your comments! Thank you!

If you want to integrate AuiServiceDialog into your application and
don’t want to wait for Avahi 0.6.18, just copy avahi-ui.h
and avahi-ui.c into your sources
and make sure to add avahi-client, avahi-glib, gtk+-2.0 to your pkg-config dependencies.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/freedom-lovers.html

On popular request, the slides of my PulseAudio talk at linux.conf.au 2007 are now available
for download. And here are the
slides of the Avahi talk Trent and I did on GNOME.conf.au 2007. Videos will hopefully be available shortly from the LCA web site.

… Horses? Did anyone say “Horses”?

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/foms-lca-2007.html

On Wed, January 17th, I will be speaking at linux.conf.au 2007 about the PulseAudio sound server. Before that, on Mon January 15th, I will do a presentation about Avahi, together with Trent Lloyd, at GNOME.conf.au 2007. And even before that, I will attend FOMS 2007, and probably say a word or two about PulseAudio, again.

Can’t wait for those 25h+ of flying from .de to .au!