Tag Archives: Projects

I wonder …

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

… whether the guys behind this know about this?

It’s a pleasure to see as many projects as possible making use of Avahi.
OTOH I believe that all solutions should speak the same protocol. Using
Apple’s somewhat standardized link-local iChat/XMPP protocol (which is what Telekinesis does) seems to be the
best option to me: because you get MacOSX interoperability for free and
many IM clients (including many on Windows) already contain support for this as
well.

CUPS 1.3b1 gained Zeroconf support

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

Seems CUPS now comes with Zeroconf/Bonjour network printer browsing support included in the upstream tarball. I haven’t
tried this myself, but presumably CUPS should work on Avahi as well, since we ship a — these days nearly
perfect — Bonjour compatibility library.

In Fedora Rawhide this
functionality seems to be enabled already. Other distibutions, please follow!

Seems at least one good thing came from the recent Apple buyout of CUPS/Easy
Software Products: I can now remove one item from my TODO list which has been there for a long time already.

Re: Avahi – what happened. on Solaris..?

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

In response to Darren Kenny:

  • On Linux (and FreeBSD) nss-mdns has been
    providing decent low-level integration of mDNS at the nsswitch level for
    ages. In fact it even predates Avahi by a few months. Porting it to Solaris
    would have been almost trivial. And, Sun engineers even asked about nss-mdns,
    so I am quite sure that Sun knew about this.
  • You claim that our C API was internal? I wonder who told you that. I
    definitely did not. The API has been available on the Avahi web site for ages
    and is relatively well documented [1], I wonder how anyone could
    ever come to the opinion that it was “internal”. Regarding API stability: yes, I
    said that we make no guarantees about API stability — but I also said it was
    a top-priority for us to keep the API compatible. I think that is the best you
    can get from any project of the Free Software community. If there is
    something in an API that we later learn is irrecoverably broken or stupid by design, then
    we take the freedom to replace that or remove it entirely. Oh, and even Sun
    does things like that in Java, Just think of the Java 1.x
    java.lang.Thread.stop() API.
  • nss-mdns does not make any use of D-Bus. It never did, it never will.
  • GNOME never formally made the decision to go Avahi AFAIK. It’s just what
    everyone uses because it is available on all distributions. Also, a lot of GNOME software
    can also be compiled against HOWL/Bonjour.
  • Implementing the Avahi API on top of the Bonjour API is just crack. For a
    crude comparison: this is like implementing a POSIX compatiblity layer on top
    of the DOS API. Crack. Just crack. There is lot of functionality you can
    *never* emulate in any reasonable way on top of the current Bonjour API:
    properly integrated IPv4+IPv6 support, AVAHI_BROWSER_ALL_FOR_NOW, the fact that the Avahi API is
    transaction-based, all the different flag definitions, and a lot more. From a
    technical persepective emulating Avahi on top of Bonjour is not feasible, while
    the other way round perfectly is.

Let’s also not forget that Avahi comes with a Bonjour compatibility layer,
which gets almost any Bonjour app working on top of Avahi. And in contrast your
Avahi-on-top-of-Bonjour stuff it is not inherently borked. Yes, our Bonjour compatibility layer is
not perfect, but should be very easy to fix if there should still be an
incompatibility left. And the API of that layer is of course as much set in
stone as the upstream Bonjour API. Oh, and you wouldn’t have to run two daemons instead of
just one. And you would only need to ship and maintain a single mDNS package.
Oh, and the compatibility layer would only be needed for the few remaing
applications that still use Bonjour exclusively, and not by the majority of
applications.

So, in effect you chose Bonjour because of its API and added some Avahi’sh
API on top and this all is totally crackish. If you’d have done it the other way round
you would have gotten both APIs as well, but the overall solution would not
have been totally crackish. And let’s not forget that Avahi is much more
complete than Bonjour. (Maybe except wide-area support, Federico!).

Anyway, my original rant was not about the way Sun makes its decision but
just about the fact that your Avahi-to-Bonjour-bridge is … crack! And that
it remains.

Wow, six times crack in a single article.

Footnotes:

[1] For a Free Software API at least.

Project Indiana

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

Dear Sun Microsystems,

I wonder if the mythical “Project Indiana” consists of patches
like these which among other strange things make the Avahi daemon just a frontend to the Apple
Bonjour daemon. Given that Avahi is a superset of
Bonjour in both functionality and API this is just so ridiculuous —
I haven’t seen such a monstrous crack in quite a while.

Sun, you don’t get it, do you? That way you will only reach the
crappiness, bugginess and brokeness of Windows, not the power and
usability of Linux.

Oh, and please rename that “fork” of Avahi to something completely
different — because it actually is exactly that: something completely
different than Avahi.

Love,

     Lennart

DMI-based Autoloading of Linux Kernel Modules

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/dmi-based-module-autoloading.html

So, you’ve always been annoyed by the fact that you have to load all those
laptop, i2c, hwmon, hdaps Linux kernel modules manually without having spiffy
udev doing that work for you automagically? No more! I just sent a patch to LKML which adds DMI/SMBIOS-based
module autoloading to the Linux kernel.

Hopefully this patch will be integrated into Linus’ kernel shortly. As
soon as that happens udev will automatically recognize your laptop/mainboard
model and load the relevant modules.

Module maintainers, please add MODULE_ALIAS lines to your kernel
modules to make sure that they are autoloaded using this new mechanism, as soon
as it gets commited in Linus’ kernel.

For a fully automatically configured system only ACPI-DSDT-based module
autoloading is missing. I.e. load the “battery” module only when an ACPI
battery is actually around.

My thoughts on the future of Gnome-VFS

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.

What I miss in GNOME

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>

Avahi on your N800

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.

Releases, Releases, Releases …

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:

Avahi Logo
  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

What’s going on with LinuxTag?

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?

No GSoC for Avahi

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!