Glick 0.2 released

There was two really embarrasing bugs in the 0.1 release. First of all the argument order was switched around in the description of how to create glicks in the README. Secondly, a bug in the fuse filesystem implementation made it hang after 10 files had been opened.

So, a quick release is in order. Get your fresh new code at the glick home page.

Thanks to  Stefan Westerfeld for finding these issues.

12 Responses to “Glick 0.2 released”

  1. nqully says:

    Great! It will be really fantastic to have some single applications installed on top of a standard system. Glick is not meant to replace deb or rpm, but could be very useful to quickly install some programs without dependancy hassle.
    Sometimes I want to test some new software versions but then give up because the dependencies are too widely spread across my system and it would be too much work compiling and installing many libraries.

  2. Renaud says:

    You go from a vacation-written klik alternative to a new Linux toy.

    Hats off to you, sir. You just gave me back programming inspiration.

    ^o^

  3. KillerKiwi says:

    Can glik work with klik recipes?

    Or do apps have to be compiled with a known location?

    http://klik.atekon.de/wiki/index.php/Recipe_Files

  4. alexl says:

    KillerKiwi: I don’t really know klik recipies.

    However, glicks have to be built with a specific prefix (/proc/self/fd/1023), or be relocatable.

  5. […] “Glick” continua ad essere sviluppato :) 24 Agosto 2007 @ 13:43 Posted by felipe in News e altre Sciccherie, Klik, GNOME. trackback Speravo tanto che Alexander non abbandonasse il frutto del suo piccolo hack estivo/vacanziero (cfr “Klik esce dal buio?¬†Notizione!“) …e infatti ecco che ha rilasciato la versione 0.2 di Glick. […]

  6. probono says:

    Is there a way to have the glick binary part precompiled, so that to create a glick bundle one would only have to do something like (you get the idea):
    cat glickheader > my.glick
    cat my.ext2 >> my.glick
    cat glickfooter >> my.glick
    ?

    This way, a machine wouldn’t need a full compiler toolchain in order to produce a glick bundle.

  7. probono says:

    Minor point, please add gcc and fuse-devel as dependencies to the RPM.

  8. alexl says:

    probono:
    The binary is mostly precompiled already in glick. Its a single statically linked library that is just combined with the filesystem image with the linker. You do need the linker though.

    You can never do it with a simple cat, as there are some things in the ELF header that depends on how large the filesystem is.

    However, it is probably possible to write a small application that knows a bit about ELF and can do the required file merging without relying on the linker, but thats a bit of work.

  9. denodas says:

    How hard would it be to add a -zisofs switch (to use that filesystem instead of ext2)? Should give much smaller binaries, and zisofs is probably available everywhere.

  10. probono says:

    How hard would it be to add a -zisofs switch (to use that filesystem instead of ext2)? Should give much smaller binaries :-)

  11. probono says:

    Wouldn’t it be great if one could make glick bundles without having to recompile the binaries using a new target=?

    Well, that’s actually possible. The trick is using a three-character patch instead of “/proc/self/fd/1023″ and a bit binary-patching.

    I prepared a (11.2 MB compressed, 30.4 MB uncompressed) glick bundle of gobby, the collaborative editor: http://klik.atekon.de/glick/gobby_0.4.5-1.tar.gz

    What is special about it? I didn’t recompile it (using a new target=), but used existing binaries (from debian sid in this case). The glick bundle runs nicely on Fedora 7, Ubuntu Feisty, and Kubuntu Feisty. In order to use it, you need to set up your system for glick (fusermount must be 4755 and /dev/fuse must be 777), and do once (as root): ln -sf /proc/self/fd/1023 /xxx

    How could it be further improved? First, by removing the need for the /xxx symlink in the base system (how? ), second, by replacing ext2 with a compressed filesystem such as zisofs, and third, by removing the need for a compiler on the machine that converts existing binaries into glick bundles.

  12. alexl says:

    ziso support would need someone to implement zisofs as a fuse filesytem. Maybe that exists already though.

    I don’t see the big problem with requiring the linker installed to create glick bundles. Thats not something most people will do anyway.