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.
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.
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^
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
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.
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.
Minor point, please add gcc and fuse-devel as dependencies to the RPM.
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.
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.
How hard would it be to add a -zisofs switch (to use that filesystem instead of ext2)? Should give much smaller binaries 🙂
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.
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.