[Printing-architecture] [Announcement] IPP Sample Tutorial (using an AppImage)
kurt.pfeifle at googlemail.com
Fri Jan 5 20:27:35 UTC 2018
Attn., cross-posting ahead about this
I've sent the same message to the "cups" / "cups-devel" lists too.
Just right for the start of 2018 I want to introduce two little things to
you all. I created...
* ...a prototype of an 'AppImage' package for the IPP Sample software
* ...a short mini-tutorial introducing some of the IPP Sample utilities.
An AppImage is a cross-distro Linux packaging method which follows the
philosophy of "One App == One File".
Imagine a macOS ".app" AppDir (application directory) which holds all the
required files for the application at runtime that are not provided by the
base system in the default installation. A Linux AppImage provides a
similar structure -- but with the added improvement of keeping everything
in a single SquashFS-compressed image. This saves disk space and makes
managing the file trivially easy. When executed, the AppImage gets mounted
automatically and its payload application gets invoked by an embedded
"AppRun". Apple and Mac users will most likely feel very comfortable with
The AppImage technology is not a competitor to the Snap and Flatpak
packaging, but it is a different thing altogether:
+ It is not and does not want to be a package manager.
+ It does not need any specific preparation for the target system in
order to work.
+ It does not require any extra framework or runtime environment to be
present in order to function.
+ It does not need "installation".
+ It does not need root privileges for preparing it to work on a system
-- runs completely in user space.
+ Not being a "package", it simply is an executable which directly runs
on almost any recent Linux distro from the last 3 years.
+ It can run from any location (USB thumb drives -- even from remote
+ It can run different versions of the same software without conflict.
+ It usually saves disk space (IPP Sample "installed" the traditional
way occupies about 22 MByte on disk; my equivalent AppImage takes only
+ It does not mess with a sytem's core libraries and leaves them alone
and untouched, leaving $PackageManager in firm control over them.
+ It is easy to get rid of again, should you not like it (just delete
that One File).
AppImages are an ideal package format for "bleeding edge" software which
developers want to get into the hands of end-users fast: since they cut
short any detour around Linux distribution packager middle-men, and since
the source code maintainers have direct control about what's contained in
an AppImage, developers also can more easily support and debug stuff when
communicating with their users: after all, every user, independent of
$WhateverDistro they use, have the same AppImage. They also can easily
swap the AppImage for a bug-fixed one (after all, it's only "One File").
Moreover, end-users do not endanger their system and its core libraries
which firmly remains under the control of their distro package manager.
I can hardly imagine any simpler and more elegant method for distributing
any software from developers to its users. Thinking of it, an
"installation-less" software package is the perfect match for
"driver-less" printing :-)
The AppImage project now has more than 13 years of development under its
belt (though the name is relatively new). AppImages have become pretty
popular in the last 6 months. Meanwhile even Linus Torvalds uses it for an
(almost not-known) end-user GUI application he started a few years ago
(which is a logging, reporting and planning software for hobby and
professional divers called "Subsurface"). He switched to AppImage because
he famously thinks that "Linux sucks" when it comes to the desktop eco
system created by the many competing Linux distro packaging formats and
their library naming crazyness. Another prominent AppImage user is
Microsoft -- they build an AppImage to provide their PowerShell v6.0.0rc
for various Linux distros.
With THIS AppImage I "pushed the envelope" a bit:
1. AppImages originally were designed for packaging desktop GUI
applications. However, I packaged CLI software with it. This works
even pretty well -- as you will see if you decide to give my IPP
Sample AppImage a spin.
2. While AppImages usually embed ONE executable, I stuffed SEVERAL into
THIS one: you can invoke them as 'sub-commands' to the shell
'ippsample', similar to how 'busybox' works:
ippsample ipptool [ipptool args ...]
ippsample ippproxy [ippproxy args ...]
ippsample ippfind [ippfind args ...]
ippsample ippserver [ippserver args ...]
This is implemented by way of a custom "AppRun" script I wrote for this
AppImage. It also added a few convenience parameters, which may be used:
--listtest List all '.test' files embedded in AppImage
--listtestdoc List all documents which may be used for tests
--listman List all manpages embedded
--listhtml List all HTML docs embedded
--listexe List all executables ('sub-commands') which can be invoked
--listreadme List all embedded README and other text files
--listdir List all directories making up the AppImage
--listfile List all files which make up the AppImage
Additional options then are:
--man <manpage-name> Display named manual page in terminal
--html <HTML-doc-name> Show named HTML doc in default browser
--readme <README-name> Display named README in terminal
Every (recent) AppImage supports these generic CLI parameters:
--appimage-help List other CLI params with short description
--appimage-extract Extract AppImage into the AppDir 'squashfs-root'
This last option, after extraction, lets you hack on my AppRun script
should you feel an itch for this :-)
My tutorial comes in the shape of an "ASCIInema" asciicast, running about
7 minutes. It should serve as an introductionary HOWTO for the IPP Sample
utilities, as well as a short intro into IPP in general.
Since it uses an AppImage, it can be reproduced immediately after
download, by almost any Linux user who is interested to play with IPP
Sample software. You can watch it here:
Two usage tipps:
1. You can pause or scroll back and then replay a scene it any time if it
was passing by too fast.
2. You can copy'n'paste whatever is interesting for you directly from the
My AppImage is automatically built by Travis CI from a forked
istopwg/ippsample repository on GitHub. If you like it well enough, I can
prepare a pull request for the official istopwg/ippsample repo, and a
working AppImage will automatically be built and published upon each push
("continuous" release), or upon each officially tagged release, or both.
I'm planning to add a few more functions in future releases for user
convenience to play with this AppImage. Mainly, these will be to provide
several working samples of several pre-defined print queues having
different extended properties, which then can then be used with
'-C config-dir' invocations of 'ippserver'.
The download location of my current 'xperimental' AppImage is here:
Please do not miss to read the text-style supplement to the tutorial on
the asciinema.org website. I'd like you to check (and tell me about) if I
have any factual errors in it.
URL to ASCIIcast one more time: https://asciinema.org/a/155588
1. Also please tell me about any other issues you may encounter  --
unless it is a problem with the IPP Sample software itself .
2. I promise to not take offense if you consider both, my ASCIIcast and the
AppImage, as two things which put some more weight behind my request from
10 weeks ago to provide *official* AppImage releases by the PWG ;-)
(see issue on GitHub: https://github.com/istopwg/ippsample/issues/56)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Printing-architecture