Hier noch ein Nachtrag zum Fall GeoGebra. Für die, die es nicht wissen: GeoGebra ist eine weit verbreitete, in Java geschriebene Software für die Erstellung und Berechnung mathematischer Figuren.

Eigentlich sollte GeoGebra in die Debian Paketquellen, jedoch haben sich die Entwickler dagegen gewehrt und wollten GeoGebra auf keinen Fall in den Paketquellen haben. Man sollte nach ihrer Meinung entweder die Java-Webstart Anwendung von GG nutzen, oder aber GeoGebra nur aus den von ihnen bereitgestellten Quellen installieren können.

Die Gründe für dieses Verhalten blieben für mich rätselhaft, das Paket wurde von Giovanni Mascellani trotz Protest in Debian integriert. Inzwischen sind die Entwickler (in der Debianwelt als “upstream” bezeichnet, da sie das “Rohmaterial” für ein Paket liefern) auch mit der Situation zufrieden. Also habe ich mal nachgefragt, warum denn eigentlich die Upstream-Entwickler so gegen eine Aufnahme des Paketes waren: Giovanni meinte, der hauptsächliche Grund dafür, dass die Entwickler GG nicht in Debian haben wollten war das Problem, dass extrem viele Versionen von GeoGebra in Umlauf sind, und man nicht für alle Fehlerkorrekturen bereitstellen kann. Außerdem wäre das verwirrend für die Nutzer.

Inzwischen arbeiten die GG-Entwickler wohl sehr eng mit Giovanni, der Paket-Maintainer für GeoGebra ist, zusammen, und diese Arbeit läuft perfekt.

Im Grunde war der Hauptgrund für dieses Verhalten also in etwa der selbe wie bei Mozillas Firefox: Man wollte schlicht und einfach nicht so viele Versionen lange Zeit supporten. (Was ich auch verstehen kann, vor allem bei kleinen Teams ist das ein unglaublicher Aufwand)

Bei Mozilla kam dann auch noch die aggressive Markenpolitik hinzu, was dann dazu führte, dass Debian seinen eigenen Firefox-Fork pflegt. (Identisch mit Firefox, bis auf Name und Branding) Aber das ist auch ein anderes Thema.

Seit geraumer Zeit ist die Musikvisualisierungssoftware projectM in den Debian-Paketquellen verfügbar. Leider waren die Pakete von projectM verwaist (=niemand, der sich um deren Instandhaltung kümmert), veraltet und zudem zersplittert in viele Einzelpakete.

Dass ein Bedarf an projectM besteht, zeigt ein unglaublich umfangreicher Thread im englischen UbuntuForum, und da ich das Projekt auch gut finde, habe ich neue Pakete für Debian erstellt und mit dem Multimedia-Team die Maintainerschaft über die Pakete übernommen. Soweit, so gut.

Blöderweise gibt es noch einen kritischen Bug, der verhindert, dass die neuen projectM-Pakete in die offizielle Distribution aufgenommen werden können. So crasht das Programm “projectM-pulseaudio” direkt nach dem Start auf manchen Systemen.

Daher ist das neue projectM erstmal nur auf der experimental-”Spielwiese” von Debian enthalten. (Und damit kommt projectM auch nicht in die Ubuntu-Quellen) Bis der Bug behoben ist, wird projectM auch noch in experimental bleiben. Nun haben wir einen Patch erstellt, der den Crash verhindert, was projectM gut genug für Debian unstable machen würde. Das Problem daran wiederum ist, dass Besitzer einiger Grafikkarten projectM dann nicht nutzen können, da der genannte Patch im Grunde nur den Crash verhindert, aber nicht dessen eigentliche Ursache. Leider tritt der Crash nur auf manchen Systemen mit bestimmten Grafikkarten auf, was eine Analyse des Problemes erschwert. Kurz gesagt:

Wer könnte besser die Tools auf Funktionsfähigkeit testen als die späteren Nutzer? Voraussetzung sind grundlegendes Wissen über die manuelle Installation von Paketen und die Bedienung von Terminals, mehr nicht.

Zur Installation müssen folgende Pakete manuell aus Debian-Experimental heruntergeladen & installiert werden: projectm-data, libprojectm2, libprojectm-qt1, projectm-dbg, projectm-pulseaudio und, optional, wer Unterstützung für JACKAudio will: projectm-jack

Dann ein Terminal öffnen und

projectM-pulseaudio

eingeben. Dann entweder über die schöne Visualisierung freuen (man muss natürlich Musik über PulseAudio laufen lassen) oder aber den Absturz des Programmes beobachten. Falls es Probleme gibt, wäre es super, wenn ihr die komplette Terminalausgabe von projectM-pulseaudio zusammen mit der des Befehls

glxinfo | grep -i opengl

an mich senden würdet. Wer Erfahrung damit hat, kann die Daten am besten als Kommentar zu diesem Bug im BTS von Debian eintragen. Alternativ geht aber auch ein Kommentar zu diesem Blogpost, oder aber noch besser über Launchpad. (Betreff: projectM-Testcase)

Damit werden dann bald alle in den Genuss der IMHO besten Musikvisualisierung kommen, die es momentan gibt.

Obwohl ich ja als PackageKit-Fan bekannt bin hielt ich damals, beim Umstieg von KDE3 auf KDE4 in Kubuntu die Ersetzung von Adept durch KPackageKit für nicht wirklich gut. Zu neu war die Technik von PackageKit und zu unübersichtlich die Oberfläche von KPackageKit.

Inzwischen hat sich das Problem erledigt, KPackageKit ist ein sehr gutes Stück Software, welches Spaß macht, es zu benutzen. Trotzdem bleiben einige Probleme. So gibt es bei PackageKit (welches von Richard Hughes, einem Fedora und GNOME-Entwickler gestartet wurde) die Regel, dass eine einmal gestartete Transaktion (=irgendeine Interaktion mit dem Paketmanager) niemals den Nutzer während der Installation etwas fragen darf. Jede Nutzerinteraktion muss vor Beginn der Transaktion erfolgen. Das funktioniert mit Yum, dem Fedora-Paketmanager. Blöderweise hat Debian mit Debconf ein sehr mächtiges Werkzeug für Paketmaintainer, mit welchem Pakete währen der Installation grafisch mit dem Nutzer interagieren können. Das ist in vielen Fällen nützlich, steht aber entgegen der PackageKit-Philosophie. Und genau dies ist der Grund, warum PackageKit nicht in den Debian-Quellen und kein Standard in Ubuntu ist.

Nun aber gibt es Abhilfe für alle Probleme mit APT-GUIs in KDE sowie für das Debconf-Problem.

Dantti schreibt eine Unterstützung für Debconf in PackageKit. (genau genommen wird auch Debconf überarbeitet) Damit wird KPackageKit vielleicht schon in der nächsten Version Debconf unterstützen, GNOME-PackageKit wird folgen. Dieses Problem ist also gelöst. (Gerne hätte ich beim Entwickeln der Frontends geholfen, aber meine Qt4-Kenntnisse sind noch etwas zu gering dafür)

Das andere Problem war, dass es keinen KDE-Paketmanager in Debian/Ubuntu gab, der sich mit Synaptic messen konnte. Jede auf PackageKit aufbauende GUI kann immer nur die Features unterstützen, die von allen Paketmanagern (Yum, Zypper, Emerge, APT, etc.) unterstützt werden. Daher kann KPackageKit die APT-spezifischen Features nur in begrenztem Maße ausnutzen.

Auch das Problem wird angegangen. Schuld daran ist in diesem Fall hauptsächlich Jonathan Thomas, Kubuntu und KDE-Entwickler. Er hat QApt geschrieben, ein generisches API für APT, welches jede KDE-Anwendung nutzen kann. (Zuvor gab es mehrere, halbfertige Implementationen. Z.B. haben wir festgestellt, dass der Debconf-Support in Adept 2 nie wirklich vollständig war…)

QApt selbst ist in zwei Teile geteilt. Es besteht zum Einen aus LibQApt, einem Qt-Wrapper um libapt-pkg mit einem schöneren API als es libapt-pkg hat und APTCache-Support. Damit kann man sämtliche nur-lesen-Aktionen mit APT ausführen. Zum Anderen gibt es jetzt QAptWorker, welcher sich um alle Aktionen kümmert, die etwas an der Paketkonfiguration ändern. (Updates, Paketinstallation/Deinstallation) LibQApt verbindet sich mit QAptWorker über PolicyKit, womit sämtlichen Komfort von PolicyKit nun auch für Paketinstallationen verfügbar ist.

Ein neues Projekt welches das neue QApt nun nutzt, ist Muon, welches der Synaptic-Ersatz für KDE werden könnte. Ich zitiere einfach mal die aktuellen Features von Muon von Jonathans Website:

sudo add-apt-repository ppa:echidnaman/qapt && sudo apt-get update

Allerdings ruft Jonathan dazu auf, beim Testen vorsichtig zu sein, da es eben ein sehr neues, ungetestetes Stück Software ist, welches eben in kritischen Bereichen (Paketmanagement) arbeitet. Auf meinem System funktioniert es zwar recht gut, das muss aber nicht für alle Anderen Installationen auch gelten.

Muon wird in Kubuntu 10.10 nicht enthalten sein. Paketmanagement in Kubuntu war durch den schnellen Wechsel von Adept 2 zu Adept 3 Alpha zu einer Qual geworden, und auch die Situation mit KPackageKit war zu Beginn nicht so toll. Also will man hier nicht den gleichen Fehler machen und Muon lieber noch eine Weile reifen lassen, bevor man es zum Einsatz bringt. (KPackageKit ist in Version 0.6 für die meisten Nutzer auch sehr gut geeignet) Einzig der bisherige Python-Basierte Installer für lokale Deb-Pakete könnte eventuell durch eine QApt-Basierte Lösung ersetzt werden. Die großen Änderungen werden dann mit Kubuntu 11.04 kommen.

Wer noch mehr über QApt/Muon wissen will, dem empfehle ich den Blogeintrag von Jonathan zu dem Thema. Ebenfalls lesenswert ist natürlich auch Danttis Blog.

Insgesamt Hut ab vor dieser genialen Leistung von Jonathan! In Sachen Paketmanagement und Softwareinstallation dürften wir dieses Jahr sowieso noch einiges an coolen Neuerungen zu sehen bekommen…

Ich hatte ja zuvor schon einmal über die Probleme, GeoGebra in die Paketquellen von Debian zu bringen berichtet. GeoGebra ist eine weit verbreitete, in Java geschriebene Software für die Erstellung und Berechnung mathematischer Figuren.

Nun sieht es so aus, als wäre das Problem quasi erledigt. Giovanni Mascellani hatte ja die Paketierung trotz aller Proteste der GeoGebra-Entwickler fortgeführt. Diese wollten nicht, dass man GeoGebra von anderen Quellen als von ihrer eigenen Website beziehen konnte. (Zudem hatten sie das Java-Archiv signiert…) Daher haben sie uns mit mehreren Mails aufgefordert, alle GeoGebra-Pakete aus PPAs zu entfernen und die Paketierung für Debian und Ubuntu sofort abzubrechen. Da das Projekt OSS ist, steht es Debian aber eigentlich frei, GeoGebra in die Quellen zu bringen oder nicht. Einige weitere Probleme haben dann noch eine Menge unfreie Codestücke im GeoGebra-Code bereitet. Jede OpenSource-Software in Debian muss den DFSG (“Debian Free Software Guidelines”) entsprechen. Diese legen fest, ob eine Software wirklich als frei (im Sinne von “Freiheit”) zu betrachten ist oder nicht. In GeoGebra waren nun unter anderem Codestücke drin, die kommerzielle Nutzung verboten. (Was unfrei ist) Dieser Code ist jetzt von Giovanni ersetzt worden, hauptsächlich durch neue Java-Libs. Damit ist das Paket “geogebra” nun schlussendlich doch in den Debian-Repositorien angekommen. Giovanni versucht noch, die GeoGebra-Entwickler davon zu überzeugen, wie viele neue Nutzer sie durch die Integration bekommen können, da es wohl noch etwas Protest gab.

Alles in Allem haben aber die Nutzer “gewonnen”, da sie natürlich den Vorteil aus der Paketierung ziehen. Ich selbst wundere mich nur ein weiteres Mal über dieses seltsame Verhalten eines so renommierten OpenSource-Projektes.

Für Ubuntu-Nutzer gibt es übrigens eine gute und eine schlechte Nachricht: GeoGebra wird mit der kommenden Ubuntu-Version (10.10:Maverick) in den Paketquellen und damit auch im Software-Center zu finden sein. Die schlechte Nachricht ist, dass man momentan wegen der vielen neuen Java-Abhängigkeiten das GeoGebra-Paket nicht besonders einfach aus Debian Testing installieren kann. Bis zu Maverick kann man aber die offiziellen Downloads der Entwickler nutzen.

ACHTUNG! Das ist keine Übersetzung der Releaseankündigung des Listallers! Die Ankündigung findet sich auf dieser Seite. (englisch)

Endlich kann ich mal ein Release des Listallers ankündigen! Es hat über 9 Monate gedauert, dieses Release fertig zu stellen, was vor allem am enormen Schwund an Entwicklern liegt. (viele hatten zu viel an der Uni zu tun, um sich noch weiter um den Listaller zu kümmern)

Der Listaller, für die, die das Projekt noch nicht kennen, ist ein distributionsübergreifendes Tool, um Software auf Linux-Systemen zu verwalten. Das Projekt basiert auf Richard Hughes’ PackageKit und ist quasi eine Erweiterung von dessen Funktionen. Der Listaller stellt ein Metapaketformat zu Verfügung, welches einen sehr einfachen und flexiblen Weg bereitstellt, Software mit nur einem Paket auf vielen Linux-Distributionen zu installieren. Zudem kann man existierende installierte Anwendungen mit dem Listaller verwalten.

Der Listaller 0.4b verfügt über folgende neue Funktionen:

• Generelles Code-Aufräumen: Viele Teile des Listallers sind neu geschrieben worde.
• IPK1.0 Format: Das Paketformat verwendet jetzt eine ähnliche Syntax wie die, die bei Debian-Paketen zum Einsatz kommt. Die neue Formatierung ersetzt das alte XML-basierte Format, wodurch IPK-Scripte besser lesbar werden sollen.
• Vollständige PackageKit-Integration: Die alte Paketinstallationslösung wurde vollständig durch PackageKit ersetzt, welches jetzt fix integriert ist. (und nicht nur als Plugin zu Verfügung steht) In vorigen Versionen hat der Listaller noch direkt Verbindungen zu APT/Yum/Zypper etc. durch eine eigene Abstraktionsschicht hergestellt. Stattdessen wird jetzt PackageKit verwendet.
• Neue libInstaller: Eine Bibliothek, welche alle Listaller Funktionen enthält. Damit sind neue Sprachbindungen (für Python/C++) möglich.
• Katalog entfernt: Die Distributoren haben während der Entwicklungszeit von Listaller 0.4b sehr gute Software-Stores entwickelt. Zudem werden wir mit dem PAPPI-Projekt zusammenarbeiten, welches die nun fehlende Funktion vielleicht ersetzt. Bis jetzt hat keiner der Tester den Software-Katalog vermisst
• Überarbeitete grafische Oberflächen und Qt4-Versionen der GUIs
• IPK-Pakete sind jetzt LZMA-komprimiert (macht sie über 20% kleiner, je nach Inhalt)
• PolicyKit Unterstützung für alle Module des Projektes

Und das sind nur die wichtigsten Punkte. Im Grunde wurde bei der Entwicklung kein Stein auf dem Anderen gelassen.

Mit diesem Listaller-Release können jetzt erstmals sehr einfach IPK-Pakete erstellt werden. Leider kann ich aber eine vollständige Stabilität des IPK-Formates nicht garantieren, obwohl das eines der Ziele des 0.4b Releases war. Dies ist aber wir vieles Andere auch dem Entwicklermangel zum Opfer gefallen. Der Listaller Manager kann in der aktuellen Version mit folgenden 3rd-Party Installationssystemen umgehen: LOKI, Mojo, Autopackage, Natives, IPK. Unterstützung für ZeroInstall ist geplant. Dies bedeutet, dass man mit dem Listaller Anwendungen wie GoogleEarth so leicht entfernen kann wie im Paketmanager, auch wenn sie nicht als Paket installiert wurden.

Wegen der geringen Zahl der Entwickler konnten wir auch einige der Tests auf verschiedenen Distributionen nicht durchführen. Daher hoffen wir darauf, dass die Nutzer den Listaller ausgiebig auf verschiedenen Distributionen testen. (Bis jetzt funktionieren Ubuntu 10.04, Debian Sid und Fedora 13)

Ein der tollsten Neuigkeiten des Projektes ist unsere Kooperation oder unser Zusammenschluss mit dem PAPPI-Project. PAPPI – eine Kurzform für “Personal Applikation Installer” – ist ein Projekt, welches einen distributionsunabhängigen Software-Store für Linux verfügbar machen möchte. Das Projekt ist aus der Ubuntuusers-Community bekannt. Zur Zeit erstellen wir eine Roadmap für die Listaller <> PAPPI Kooperation. So könnte z.B. PAPPI als SoftwareStore in den Listaller integriert werden, währen PAPPI Listallers IPK-Format verwendet. (IPK verfügt über einige Features, die bei PAPPI schon auf der Roadmap stehen, z.B. Signaturen)

Apropos Roadmap: Jetzt wo der Listaller 0.4b fertig ist, werden natürlich erstmal alle Fehler darin behoben, das ist die Hauptaufgabe der nächsten Wochen. Aber auch für Listaller 0.5 existieren natürlich schon Pläne. So könnte der Installer dann Multi-Architektur-IPKs unterstützen, welche binäre Dateien für mehrere Architekturen enthalten, z.B. für AMD64 und i386. Die richtigen Dateien werden dann während der Installation ausgewählt. Das könnte für Firmen, welche Linuxspiele vertreiben sehr nützlich sein. (Wenn man an Ryan Gordon‘s FatELF Projekt denkt, scheint ein Bedarf da zu sein.) Auch verschiedenene Geschwindigkeitsverbesserungen sind geplant. Zudem soll es eine C++-Implementation des Listaller Manager geben, welche sich schön in den KDE-Desktop integriert.

Wer jetzt den Listaller einmal ausprobieren möchste, findet vorkompilierte Pakete für neuere Distributionen (mit PackageKit >= 0.5.6) auf unsererer Downloadseite. Alternativ kann der Listaller natürlich auch direkt aus den Quellen kompiliert werden. Um eine IPK-Installation auszuprobieren, empfehle ich das Spiel “Osmos” bzw. dessen Demoversion. Das IPK-Paket zu Osmos kann von unserem getIPK heruntergeladen werden.

Wer dem Projekt in irgendeiner Form helfen will (Entwickler/Sponsor/Designer) kann mich gerne direkt kontaktieren. Bugmeldungen zum aktuellen Release sind ebenfalls (anders als die Bugs selber) sehr gerne gesehen. Dafür steht der Bugtracker auf Launchpad bereit.

Viel Spaß!

I’m very glad to announce the release of Listaller 0.4b today! It took over 9 months to complete this release, which is basically the result of a great lack of developers. I was working on most parts alone, since the other two developers stopped committing code because of too much work at university.

For those who don’t know: Listaller is a cross-distribution application management and software installation tool based on Richard Hughes’ PackageKit. It provides a meta package format which covers current LOKI and Autopackage setups as well as it is providing a highly flexible way to install software on different distributions needing just one package.

Listaller 0.4b got the following new features since 0.3a:

• General code cleanup: Most parts of Listaller were rewritten
• IPK1.0 standard: The package format uses a similar syntax like Debian packages use. The new syntax replaces the old XML-based files which were hard to read.
• Option to sign IPK packages: Packages can now be signed with GPG by passing the “sign” option to libuild.
• Completed PackageKit integration: We dropped the previous native package installation solution and ported all parts to PackageKit. (In previous versions Listaller connected directly to APT/Yum/Zypper etc. through an own abstraction layer. Now PackageKit is used instead.)
• New libInstaller: A library which covers all Listaller functions. This makes it possible to write more advanced frontends in other languages.
• Removed catalog support: We will do a cooperation with the PAPPI project which will remove the need of a software-store like feature. Also the distributions have very good solutions by their own now.
• Revised GUI surfaces & Qt4 GUIs
• LZMA compressed IPK packages (makes packages over 20% smaller)
• PolicyKit support for all Listaller modules

These are only the most important points. Listaller got that much changes, it is impossible to list all. While the development process of 0.4b we migrated from SVN to Git and restructured the codebase, which will make maintaining the sources a lot easier.

This Listaller release can now be used to create IPK packages for your application. The specifications aren’t stable (which was one goal of this release we couldn’t archive), but we will try to keep backward compatibility if possible. The Listaller manager is a pretty useful thing now, because it is able to remove even native packages quite well. (One of the results of our PackageKit migration) Software management systems supported by Listaller Manager are now: LOKI, Mojo, Autopackage, Natives, IPK. Support for ZeroInstall is planned.

Unfortunately there are some negative points about this release: Originally, this should have been the 0.4 release and not 0.4b. But because we don’t have enough developers, I wasn’t able to do the required tests on all distributions. So I expect a lot of bugs to be filled in the next days. The release has now been delayed for more than five months and it does not help the project to wait until everything has been tested. (Too much effort) I hope this release will bring some more developers.

The 0.4b release also means, that IPK1.0 has not been frozen: One of the goals of 0.4 was to make it API stable and freeze the IPK/IPS specifications. This is impossible at the current state. IPK is usable, but I can’t promise complete backward compatibility of all packages. (But we will try to keep the compatibility – as said before) There might be a lot of changes, as results of the cooperation with the PAPPI-Project. Also I will break the API if there are some security or stability related issues. But we will announce those changes at least two weeks before we apply them, and I guess they won’t happen very often.

One of the very positive points is the cooperation and maybe merge with the PAPPI-Project. PAPPI – short for “Personal Applikation Installer” – is a project which aims to provide a distribution neutral application marketplace for Linux. It features some old games (Atari) and Wine software as well as modern, native Linux software. At time, we’re building a roadmap for the Listaller – PAPPI cooperation. It seems like Listaller will integrate the PAPPI store and PAPPI will use IPK packages. (IPK provides some of the features already planned in PAPPIs roadmap)

Yeah, roadmap! Now, since Listaller 0.4b is out, I will focus on fixing bugs. But there already exist some plans for the upcoming major release of Listaller. Listaller 0.5 might include multi-architecture IPKs, which contain software built for multiple platforms. The appropriate  binaries will be selected by the installer during installation. This might be useful for some game publishers. (Think of Ryan Gordon‘s FatELF project) Then I plan to speed up the installation and software-removal process, maybe by improving the search speed of PackageKit or by prefetching dependencies in Listaller. Release 0.5 might also include dependencies on software groups: At time, e.g. if your application depends on Qt4, you have to include every library name of Qt as dependency. In 0.5, it might be enough to tell Listaller to check if Qt4 >= 4.6.4 is installed. This will also improve the speed of installations. I also plan a C++ implementation of Listaller manager, which will integrate nicely into the KDE desktop. Well, but this are just some thoughts about the future of Listaller. A lot more important is to improve the quality of 0.4b.

If you want to try Listaller, you’ll find precompiled binaries for some major distributions (which already have PackageKit >= 0.5.6) on our Download Page. As alternative, you can compile Listaller from source code, which is available at Gitorious or as tarball on our Download Page. If you want to try some IPKs, I suggest to install the Demo of “Osmos“, a very nice indie game, packaged as IPK. You can download it from our getIPK service, which will fill up with some more IPKs next days.

If you want to help developing Listaller or have anything to tell me, please feel free to contact me! If you find any bugs, report the at our Bugtracker at Launchpad.

Have fun!

Seit einiger Zeit ist ja der GetDeb-Server http://getdeb.net nicht mehr verfügbar. Nutzer des Paketarchives von GetDeb mussten auf Mirrors des alten Servers ausweichen.

Nun aber ist ein neuer Sponsor für die Server gefunden: Nexus Professionals (http://nexusprofessionals.com/) wird ab sofort die Infrastruktur stellen. Leider konnten einige Pakete sowie die Datenbank und die Indizes des alten Servers nicht wiederhergestellt werden. João Pinto kümmert sich aber zumindest schon um die Wiederherstellung der Datenbank. Aus diesem Grund werden in Kürze alle Einträge neu in APT-Portal importiert. Es gibt also einiges zu tun

Ein weiterer wichtiger Punkt für Benutzer einer Ubuntu-Version < 10.04 ist die Entscheidung, alle Pakete vor Lucid Lynx aus dem Archiv zu löschen. Die alten Pakete in Stand zu halten ist eine Menge Aufwand, wenn es um Sicherheitslücken geht. (Außerdem verbrauchen sie viel Platz) Am besten sollte man also jetzt ein Upgrade machen (wenn man eine version benutzt, bei der der Support ausgelaufen ist) oder die benötigten Versionen der Pakete vor dem Cleanup von einem der zahlreichen Spiegelserver ziehen.

Hiermit schonmal vielen Dank für die Geduld und sorry für die Probleme mit dem Server im Namen des Teams. Bald wird es auch wieder neue Pakete in GetDeb geben. Denn auch das Beheben von Bugs ist durch den Ausfall ins Stocken geraten.

Neulich bekam ich ein extrem großes PDF (~24MB) auf einem USB-Stick, welches ich ins Internet hochladen wollte. Bei 24MB ist für ein PDF ist mir da jedoch der Webspace etwas zu schade, außerdem will keiner eine so große Datei laden. Also habe ich mich dumm und dämlich gesucht, eine gute Möglichkeit zu finden, das PDF zu verkleinern. Für die meisten Tipps brauchte man aber leider entweder die Quelldatei des Dokuments (die hatte ich nicht) oder aber Adobe Acrobat, welches nur auf Windows läuft und viel Geld kostet.

Das Problem an meinem PDF waren die vielen übergroßen Bilder, womit auch GZip-Komprimierung natürlich wenig Sinn macht. Irgendwann habe ich dann aber doch noch (nach stundenlangem Suchen) eine gute Möglichkeit gefunden, die Bilder in PDFs zu verkleinern. Die Lösung funktioniert mittels GhostScript, welches auf den meisten Linux-Rechnern vorinstalliert sein sollte. Ich habe die Kommandos mal in ein kleines Bashscript gesteckt:

#!/bin/bash
#
# Shrink filesize of a PDF using GhostScript
#
# syntax :
#    ./shrinkpdf.sh in=[input-file].pdf out=[output-file].pdf res=[resolution]
 
outfile="out.pdf"
res="72"
 
for arg; do
  case $arg in
    in=*) infile=${arg#in=};;
    out=*) outfile=${arg#out=};;
    res=*) res=${arg#res=};;
  esac;
done
 
if [ -z "$infile" ]; then
   usage;
   exit 1;
fi
 
echo "Shrinking pdf..."
echo "This may take some time."
gs -q -dNOPAUSE -dBATCH -dSAFER \
	-sDEVICE=pdfwrite \
	-dCompatibilityLevel=1.3 \
	-dPDFSETTINGS=/screen \
	-dEmbedAllFonts=true \
	-dSubsetFonts=true \
	-dColorImageDownsampleType=/Bicubic \
	-dColorImageResolution=$res \
	-dGrayImageDownsampleType=/Bicubic \
	-dGrayImageResolution=$res \
	-dMonoImageDownsampleType=/Bicubic \
	-dMonoImageResolution=$res \
	-sOutputFile="$outfile" \
	 "$infile"
echo "Finished."
echo "Output data saved to $outfile"

Dieses Bashscript kann man jetzt z.B. in einer Datei “shrinkpdf.sh” speichern und ausfühbar machen. Mittels

shrinkpdf.sh in=/pfad/zur/großen/pdfdatei.pdf out=/pfad/zur/auszugebenden/datei.pdf

kann man nun die PDFs verkleinern. Mit dem “res” parameter kann man auch noch die neue Auflösung der Bilder im PDF einstellen. Gleichzeitig fügt GhostScript dann noch alle nötigen Fonts in das PDF ein.

Ich hoffe, ich konnte irgend jemandem damit die nervige Suche nach einer Lösung für dieses Problem ersparen.

EDIT: Anmerkung von Dee: Noch einfacher kann man die PDF-Größe mit PDFSizeOpt ändern.

Bryan Lunduke, (free) software developer, podcaster and writer, recently gave an update of his presentation “Why Linux sucks” at LinuxFest Northwest 2010. The speech “Why Linux (Still) Sucks.  (And What We Can Do To Fix It)” is, like the last one too, very interesting for me, cause it shows the current status of the Linux desktop in a somehow objective way.

I do not agree with all his points, e.g. he says that users should pay or donate for OSS, to make it better. Of course donation makes the devs happy and can speed up the development a lot, but the success of an OpenSource project depends – in my opinion – never on financial aspects.

In other points, like the cluttered audio library system in Linux, Lunduke has my full agreement. Just watch the video and get an own impression of his points:

Interesting is what he says about installing software on Linux. All stuff which he names in his presentation can be fixed by the Listaller project I develop. I hope Listaller will be successful in creating a basis for software setups on Linux in which distributors, users and developers can agree. To make Linux suck less

I believe, by the current speed of development in OSS projects, the missing parts will be ready in a few years – the most important part is to standardize several important system libraries, to make software easier to maintain and distributions more compatible with each other.

Reference: Lunduke’s Blog

Da in diesem Jahr einiges an Neuerungen und Änderungen auf das Tenstral-Projekt zu kommt, wird es in der nächsten Woche vom 28-30 April einige Änderungen an den Servern geben.

Im moment ist das Projekt Tenstral noch mehr legacy, die Anwendungen werden kaum noch gepflegt und auch die Website erhält nur noch wenige Änderungen.

Das alles soll anders werden, u.A. wird einiges an Code unter OpenSource-Lizenzen veröffentlicht. Damit die Änderungen reibungslos kommen können, muss einiges an der internen Strukturen abgeändert werden.

Deshalb werden alle Tenstral-Seiten, dazu zählt auch dieses Blog sowie eine Reihe weiterer Projekte, entweder kurzzeitig offline sein oder aber langsam oder nicht laufen. Sollte also jemand auf die Services angewiesen sein (warum auch immer), so sollte er etwas Gedult mitbringen. Wenn alles reibungslos läuft, sind die Seiten dann sehr bald wieder online.