Brian Lunduke hat auf dem Linux-Fest Northwest wieder seinen "Why Linux Sucks"-Talk gehalten.

Verbesserungen

Brian sieht in vielen Bereichen Verbesserungen im Linux-Öko-System:

• Das http://www.humblebundle.com/Humble Indy Bundle hat gezeigt, Spiele-Entwickler können auf der Linux-Plattform Geld verdienen - mehr als auf dem Mac.
• Kommerzielle Software ist endlich über den Ubuntu Software-Center erhältlich.
• Linux-Desktops sehen heute richtig gut aus.

Unity gut für Linux-Neulinge, nicht für Linux-Profis

Sein Verhältnis zu Unity scheint eher ambivalent zu sein: Unity ist sinnvoll für Neueinsteiger, aber für die bisherigen Nutzer ist es ein kleiner Schlag ins Gesicht.

Zu wenig Spitzensoftware unter Linux

Der größte Knackpunkt ist für Brian nach wie vor, dass es an (erstklassiger) Software für Linux fehlt.

Der Grund: es mangelt vielen freien Software-Projekten an Geld. Deswegen können die Entwickler sich leider nicht Vollzeit um die Projekte kümmern - was aber eigentlich notwendig wäre.

Brian nennt als Beispiele Standard-Software; wie die Audio-Software Ardour, die im Vergleich zu Garage-Band auf Mac OS X zu schwierig zu bedienen ist, und Video- und Bildbearbeitung.

Unterschiedliche Lösungsansätze

Hier nennt er unterschiedliche Lösungsansätze:

• Sponsoring durch Unternehmen - der wahrscheinlich erfolgreichste Ansatz bei freier Software
• Verkauf von Software mit Source-Code - gibt es das in der Praxis überhaupt?
• Spenden - aber so, als müsste man sich die Software-Kaufen (So kann man die Spenden-Höhe berechnen)
• klassische closed-source Software, evtl. mit freiem Preis - wie beim Humble Indy-Bundle

Seht euch das Video am besten selbst an. Brian versteht es, seine Aussagen prägnant auf den Punkt zu bringen.

Brian Lunduke hat auf dem Linux-Fest Northwest wieder seinen "Why Linux Sucks"-Talk gehalten.

Verbesserungen

Brian sieht in vielen Bereichen Verbesserungen im Linux-Öko-System:

• Das http://www.humblebundle.com/Humble Indy Bundle hat gezeigt, Spiele-Entwickler können auf der Linux-Plattform Geld verdienen – mehr als auf dem Mac.
• Kommerzielle Software ist endlich über den Ubuntu Software-Center erhältlich.
• Linux-Desktops sehen heute richtig gut aus.

Unity gut für Linux-Neulinge, nicht für Linux-Profis

Sein Verhältnis zu Unity scheint eher ambivalent zu sein: Unity ist sinnvoll für Neueinsteiger, aber für die bisherigen Nutzer ist es ein kleiner Schlag ins Gesicht.

Zu wenig Spitzensoftware unter Linux

Der größte Knackpunkt ist für Brian nach wie vor, dass es an (erstklassiger) Software für Linux fehlt.

Der Grund: es mangelt vielen freien Software-Projekten an Geld. Deswegen können die Entwickler sich leider nicht Vollzeit um die Projekte kümmern – was aber eigentlich notwendig wäre.

Brian nennt als Beispiele Standard-Software; wie die Audio-Software Ardour, die im Vergleich zu Garage-Band auf Mac OS X zu schwierig zu bedienen ist, und Video- und Bildbearbeitung.

Unterschiedliche Lösungsansätze

Hier nennt er unterschiedliche Lösungsansätze:

• Sponsoring durch Unternehmen – der wahrscheinlich erfolgreichste Ansatz bei freier Software
• Verkauf von Software mit Source-Code – gibt es das in der Praxis überhaupt?
• Spenden – aber so, als müsste man sich die Software-Kaufen (So kann man die Spenden-Höhe berechnen)
• klassische closed-source Software, evtl. mit freiem Preis – wie beim Humble Indy-Bundle

Seht euch das Video am besten selbst an. Brian versteht es, seine Aussagen prägnant auf den Punkt zu bringen.

The post Why Linux Sucks Talk 2011 appeared first on Rockiger.

Wer die OpenSource Medien gestern oder heute verfolgt hat, dürfte ja schon mitbekommen haben, dass Nokia Qt 5 für nächstes Jahr angekündigt hat. Das hat natürlich auch Auswirkungen auf KDE. Um die Neuerungen von Qt 5 verwenden zu können, müssen wir gegen die neue Version linken, wodurch unsere KDE Platform eine binär inkompatible Änderung erhält. Die Folge davon ist recht logisch: KDE Plattform 5.

=-=-=-=-=
Powered by Blogilo

Auch wenn ich Phoronix.com nicht unbedingt als seriöse Nachrichtenquelle ansehe, doch in dem folgenden Fall fasst Phoronix nur ein Protokoll des Ubuntu Developer Summit zu Unity 2D zusammen, weshalb man Phoronix.com in diesem Fall trauen kann.

What To Expect Of Unity 2D In Ubuntu 11.10

Ich liste hier einfach mal alle Punkte aus der Nachricht im Original auf:

• A rule in developing Unity 2D will be to assume there is no GPU acceleration support, as to not design effects or other operations that are too taxing on the CPU.
• A common library for settings between Unity and Unity 2D will be worked on so that schemas can be shared. Right now the Unity “3D” version is using CCSM, but it will be moving to GSettings.
• Rather than using Metacity or any other non-accelerated window manager, Compiz will be used. While Compiz is commonly used as a compositing window manager for OpenGL / OpenGL ES, it does support different back-ends. Compiz can target X Render or even the CPU-based QPainter. A goal will be to use Compiz with a non-accelerated back-end as a new fall-back. With Unity 2D using Compiz as well, Metacity can be removed from the LiveCD, thereby slimming down the ISO size a bit as well (large discussions about hitting the 700MB CD ISO limit).
• Falling back to the classic GNOME desktop in Ubuntu 11.10 will be eliminated.
• Unity 2D will further minimize dependencies on X11 and GTK.

Am Interessantesten finde ich den dritten Punkt, dass Compiz auch unter Unity2D zum Einsatz kommen könnte, allerdings dann ohne die 3D-Effekte, sondern nur als reiner Fenstermanager.

Das bringt mich nun zu folgender These (und dem Titel des Artikels):

Wenn Unity2D auch mit Compiz funktionieren kann, warum stampft Canonical dann das Compiz-Plugin Unity nicht einfach ein und konzentriert sich vollständig auf das Qt-basierte Unity2D?

Canonical würde dadurch einer Reihe Probleme aus dem Weg gehen, wie z.B. die dann überflüssige Pflege und Wartung zweier Feature-identischer Produkte. Der Benutzer würde dann immer den gleichen Desktop präsentiert bekommen, egal ob seine Grafikkarte jetzt 3D-fähig ist oder auch nicht. Alles was am Ende fehlen würde, wären einige, weniger wichtige, grafische Effekte.

Das ist eine reine These meinerseits und basiert auf einem Gedankenspiel meinerseits.

Nachdem ich länger überlegt habe, ob ich mein System auf Natty Narwhal aktualisiere habe ich mich nun doch entschlossen einmal was anderes auszuprobieren.
Da mir Flash und anderes proprietäres Zeug in letzter Zeit immer wieder auf die Nerven ging, bin ich bei Trisquel GNU/Linux gelandet.

Der Hauptunterschied zwischen Trisquel und Ubuntu besteht darin, dass Trisquel keine proprietäre Software mitliefert. Somit fallen zahlreiche Pakete aus den Repositories von Trisquel, welche in Ubuntu vorhanden sind. Außerdem wurden auch proprietäre Kernelmodule aus dem System entfernt. Natürlich schränkt sich dadurch auch die Hardware-Unterstützung ein, doch in meinem Fall stellte dies kein Hindernis dar.

Interessanterweise wurde zwar das Firefox-Branding in Trisquel überschrieben (abrowser), doch OpenOffice.org wurde noch nicht durch LibreOffice ersetzt. Vermutlich liegt das daran, dass Trisquel derzeit noch auf Maverick Meerkat basiert. Im Web Browser ist übrigens auch standardmäßig eine Erweiterung namens FlashVideoReplacer installiert welche alternative Wiedergabeformate einsetzt, falls die jeweilige Website welche anbietet. Wenn der FlashVideoReplacer keine Alternative findet wird Gnash als Flash-Player gestartet.

So wie es derzeit aussieht bin ich mit Trisquel sehr zufrieden. Momentan habe ich Trisquel und Ubuntu noch parallel auf meinen Festplatten. Vielleicht werde ich aber in Zukunft kein Standard-Ubuntu mehr haben (je nachdem wie sich die beiden Systeme entwickeln…)

Zu guter Letzt noch ein Screenshot von meinem neuen Desktop direkt nach dem Setup:

(Natürlich lässt sich das System auch in deutscher Sprache installieren!)

Ähnliche Posts:

1. PHP-Code zur Erkennung des Betriebssystems unter Berücksichtigung der Ubuntu-Version in Firefox
2. Wechsel von ubuntu-mozilla-daily auf die offiziellen Quellen

Nach (deutlich zu) langer Zeit habe ich es endlich geschafft eine aktualisierte Version “meiner” Version von Ubuntu zu bauen und hochzuladen. Diese Snapshot-Version beinhaltet alle bis zum 06.Mai 2011 veröffentlichten Sicherheits -und Bugfixupdates von Ubuntu 10.04. Die aktualisierte Fassung dient in erster Linie dazu bei einer Neuinstallation des Systems nicht erst einmal mehrere Dutzend MB an Updates herunterladen und installieren zu müssen, sondern gleich mit einem aktuellen System loslegen zu können.

Die Versionsnummer der CD entspricht zwar dem der Ubuntu-Version 10.04.2, der Stand der Updates ist aber einige Wochen aktueller (s.o.).

Die wichtigste Änderung der Live-CD sind die Versionsnummern meiner Pakete:

• Der Intel-Treiber hat die Versionsnummer 2.15 erreicht.
• Das DKMS-Paket hat die Versionsnummer 1.0 erreicht. Mit dieser Versionsnummer habe ich auch das experimentelle DKMS-Paket eingestampft, da der zurückportierte Bugfix aus Kernelversion 2.6.38 keine Auswirkungen auf die Geschwindigkeit der Grafikdarstellung mehr hat. Benutzer des experimentellen Pakets wurden schon vor ein paar Tagen automatisch per Metapaket auf die normale Version migriert.

Die aktualisierte ISO-Datei kann man unter dem folgenden Link finden :

Ubuntu ISO-Dateien

PDF-Datei dieses Artikels erzeugen

Gestern Abend habe ich auf meinem Arbeitslaptop Natty installiert. Habe es aber nicht mehr getestet.

Heute Morgen habe ich mit freudiger Überraschung festgestellt, dass es pro Monitor jeweils ein eigenes Panel gibt.

Das ist für mich echt eine Steigerung zu meinem alten Setup.

Vor ein paar Wochen war es soweit: der Quelltext von Communtu wurde veröffentlicht. Nachdem wir intensiv an der Fehlerbehebung und neuen Features gearbeitet hatten, hatten wir uns entschieden Communtu unter die AGPL zu stellen. Somit steht nun jedem interessierten Nutzer die Möglichkeit offen an Communtu mitzuentwickeln. Der Sourcecode ist bei github unter https://github.com/communtu/communtu zu finden und kann von dort aus direkt bezogen werden. Wir bitten vor der Installation die Readme-Datei zu lesen und uns bei Bedarf in unserem IRC-Channel #de-communtu auf irc.freenode.net direkt anzusprechen.

Wer möchte kann uns dieses Jahr auch auf den LinuxTag in Berlin besuchen, diskutieren und uns um Hilfe fragen wenn Schwierigkeiten mit der Benutzung der Communtu-Webseite auftreten. Wir haben, wie letztes Jahr, einen Gemeinschaftsstand (Halle 7.2a, Stand 106) mit der Ubuntu-Community zusammen. Wir freuen uns auf Euren Besuch!

Nach einigen “Klickbunti”-Themen mal wieder ein kleiner Eintrag zur guten alten Shell ;-). Unter Linux kommt man ja fast nicht drum herum, mit dem Terminal und der Bash (Bourne-again shell) in Berührung zu kommen, deswegen ist man gut beraten, sich entsprechend zu wappnen. ;p Ein paar pfiffige Befehle, für das produktive Arbeiten mit der Bash, habe ich versucht hier zusammenzustellen…

Einstieg - Grundbefehle lernen

Wer gerade erst mit Linux anfängt, sollte sich in jedem Fall einmal die Zeit nehmen, die Grundbefehle für die Shell zu lernen. Dazu gibt es viele gute Zusammenfassungen im Netz, z.B.

• http://www.tim-bormann.de/sammlung-konsolen-befehle-linux/
• http://www.helmbold.de/linux/
• http://www.admintalk.de/konsolenbefehle.php
• http://www.cyberciti.biz/tips/linux-unix-commands-cheat-sheets.html

Die richtigen Befehle finden

Als Anfänger tut man sich natürlich schwer, auf Anhieb die richtigen Befehle zu finden. Aber auch wenn man schon mehr Erfahrung hat, passiert es häufiger, dass man auf neue Befehle stößt. Einige Tipps, wie man sich trotzdem zurechtfindet:

• Man-Pages nutzen! mit man befehlxy oder info befehlxy erhält man oft viele Informationen zu einem Befehl und den zugehörigen Flags (zusätzliche Argumente, die mit einem Bindestrich angefügt werden, z.B. ls -la) Mit /suchwort kann man in Man-Pages auch nach geeigneten Schlüsselwörtern suchen.
• oft bekommt man auch mit befehlxy --help oder -h eine Kurzhilfe angezeigt
• apropos suchwortxy - Sucht in den Kurzbeschreibungen der Befehle nach dem Suchwort
• whatis befehlxy - gibt die Kurzbeschreibung eines Befehls aus
• whereis und which - zeigt den (Haupt)Speicherort eines Programms/Befehls an
• ldd /pfad/zu/programm - zeigt Bibliotheks-Abhängigkeiten eines Programmes (Beispiel: ldd /usr/bin/gedit)

Pipe benutzen

Das Terminal hat zwar keine grafischen Effekte, dafür jedoch andere Vorteile. Diese liegen unter Anderem bei der einfachen Manipulation der Eingabe- und Ausgabekanäle. Natürlich ist es besonders effektiv, wenn man diese Vorteile gezielt einsetzt. Grob gesagt gibt es 3 Standardkanäle unter Linux für Eingabe & Ausgabe. Eingabe (“STDIN”, meist mit der Nummer 0 gekenntzeichnet), Ausgabe (“STDOUT”, Nummer 1) und Fehlerausgabe (“STDERR”, Nummer 2). Normalerweise gibt der Benutzer etwas über die “Standardeingabe” (einen Befehl) in das Terminal ein und bekommt eine Ausgabe oder einen Fehler zurückgeliefert. Das alleine wäre nichts besonders, allerdings lässt sich die Ausgabe auch über sogenannte Pipes - gekenntzeichnet durch einen senkrechten Strich | an den Eingabekanal eines anderen Befehls umleiten. So kann man Befehle unter Linux einfach verketten.

ls | sort				# gibt den Ordnerinhalt aus uns sortiert die Ausgabe alphabetisch
cat file.txt | grep apfel		# gibt eine Datei aus und sucht dann nach dem Textausschnitt, der den Begriff "apfel" enthält
history | less				# listet die zuletzt eingegebenen Befehle auf, mit less kann man komfortable in der Ausgabe scrollen oder suchen

Neben der “Pipe” gibt es auch noch andere Möglichkeiten, die Ausgabe umzuleiten. Zum Beispiel kann man mit dem Zeichen > auch Ausgaben in Dateien weiterleiten, wenn diese nicht direkt auf dem Bildschirm erscheinen sollen. So kann man z.B. auch Fehler in einer extra Datei sammeln, indem man die oben genannte Nummer der Fehlerausgabe benutzt:

CMD  2 > errors.txt

Bang-Operator: !

Der oben angesprochene history-Befehl zeigt vor jedem früheren Befehl eine Nummer an. Mit einem Ausrufezeichen und einer passenden Nummer kann man den Befehl so auch später erneut aufrufen und erspart sich unnötige Tipparbeit:

$ history | more 10  2011-04-20 10:37:42 sudo pacman -Syu 11  2011-04-20 11:04:06 ls 12  2011-04-20 11:04:18 cd tmp/ 13  2011-04-20 11:04:19 ls 14  2011-04-20 09:44:04 cd .config/autostart/ 15  2011-04-20 09:44:05 ls $ !12 cd tmp/

!-3      # fuehrt den drittletzten Befehl aus

$ pacman -Syu error: you cannot perform this operation unless you are root. $ sudo !! sudo pacman -Syu Password:

mkdir newdir cd !!:1       # erstes Argument vom letzten befehl, wechselt in das neu erstelle Verzeichnis (alternativ "cd !$")

!ssh  :p     # letzten befehl zeigen, der ssh enthielt (ohne :p wird der Befehl direkt ausgeführt)

Dateiverwaltung

Wildcards

Wildcards (erkennbar z.B. an dem Sternchen: ) werden verwendet, wenn bestimmte Buchstaben nicht klar festgelegt werden sollen. Mit ihnen ist es möglich, verschiedene Dateien auf einmal zu behandeln. Beispiele:

Bash-Scripts und Automatisierung

Ein riesiger Vorteil beim Benutzen der Bash ist die Möglichkeit, mehrere Befehle mit Scripts zu automatisieren. Das verkleinern von vielen Bildern oder ein regelmäßig erstelltes Backup sind so sehr bequem möglich. Natürlich erhöht es auch die Produktivität stark, wenn man solche Scripts an den richtigen Stellen einsetzt. Zudem ist es für Jeden, der schonmal mit dem Terminal gearbeitet hat und bereits einige Befehle kennt, kein großer Schritt mehr, Shell-Scripting zu lernen. Gute Anlaufstellen sind beispielsweise:

• http://selflinux.org/selflinux/html/shellprogrammierung.html - deutsche Einführung in die Shellprogrammierung
• http://tldp.org/LDP/abs/html/index.html - umfangreiche Referenz zum Thema Bash-Scripting (englisch)

alias la='ls -lahg --color=auto --group-directories-first'

vim - Befehle für den Texteditor

vim ist ein sehr umfangreicher Texteditor für die Konsole, der durch eine angepasste Konfigurationsdatei sowie etliche Plugins noch erheblich erweitert werden kann. Da bei Linux öfter mal vorkommen kann, dass man Konfigurationsdateien anpassen muss, hier ein kurzer Überblick. Zum Einstieg ist es wichtig zu wissen, dass es im Wesentlichen 2 Modi gibt: einen Befehls-/Kommandomodus (in dem vim auch startet) zur Eingabe von Befehlen und einen Eingabemodus zur Textbearbeitung. Mit der Taste i wird standardmäßig in den Eingabemodus gewechselt, die Taste ESC bringt einen zurück in den Befehlsmodus.

Speicherprobleme lösen

Für die aktuelle Datei fehlen die nötigen Schreibrechte:

  :shell     # wechseln in die Shell, ohne vim zu beenden
  chmod u+w filename.txt     # gibt dem aktuellen benutzer Schreibrechte
  exit     # kehrt zu vim zurück
  :w!     # Dateiänderungen speichern

Für die Aktuelle Datei fehlen die Rootrechte (Konfigurationsdateien usw.):

  :w !sudo tee %

(tee schreibt standardausgabe in eine datei, in diesem Fall die aktuelle (%), alternativ kann nach dem tee befehl natürlich auch ein anderer Befehl angegeben werden)

• http://marketplace.tutsplus.com/item/venturing-into-vim-4part-video-series/131400
• http://net.tutsplus.com/sessions/vim-essential-plugins/ - Vorstellung einiger Plugins
• http://net.tutsplus.com/articles/web-roundups/25-vim-tutorials-screencasts-and-resources/ http://www-user.tu-chemnitz.de/~hot/VIM/VIM/vikurz.html
• http://www.oualline.com/vim-cook.html
• Suchmaschine des Vertrauens ;)

Nützliche Tastenkombinationen (u.A. Gnome-Terminal)

• Strg + A oder Strg + E - an das Anfang oder Ende einer Eingabe springen
• Strg + Shift + T - neuen Tab mit  eigenem Terminal anlegen
• Strg + R <suchwort> - History/letzte Eingaben nach einem Befehl durchsuchen
• Tab - versucht einen Befehl zu vervollständigen - hier empfhiehlt es sich auch, bash-completion installiert zu haben, was dieses Feature noch erweitert
• Strg + D - Eingabe von aktuellem Befehl beenden ("End-of-File", schließt die Standardeingabe - und damit häufig auch das Programm)
• Strg + C - Laufendes Kommando abbrechen (sendet das Signal "SIGINTR" am das Programm)
• F11 - Vollbild
• Strg + Z - gerade im Terminal aktiven Prozess schlafen legen (es wird eine Nummer angezeigt (z.B. [1]) über die der Prozess wieder im aktuellen Terminal: fg %1 oder im Hintergrund: bg %1 fortgesetzt werden kann)
• CMD & - oeffnet einen Befehl nicht im Terminal sondern im Hintergrund, sodass man im Terminal weiterarbeiten kann. Bei Erfolg wird die ProcessID des neuen Prozesses angezeigt.
• Strg+U / Strg +W - gesamten Text nach/vor dem Curor löschen
• Alt + F / Alt + B - ein Wort in der Eingabe vor / zurueck springen

Fehlerbehandlung

Viele Fehler, die einem bei der Shell-Benutzung über den Weg laufen, sind die Ursache ähnlicher Fehlerquellen und deswegen oft einfach lösbar. Generell empfiehlt es sich (sofern im Terminal keine Fehlermeldung aufgetaucht ist), einmal in den Logfiles (i.d.R. zu finden im Verzeichnis /log), z.B. in Kombination mit dem grep-Befehl nachzusehen. Für ehemalige Windows-Nutzer ist wahrscheinlich das Rechtesystem erst einmal ungewohnt:

Rechteverwaltung

chmod u+rwx file   # dem benutzer Lese (r) Schreib (w) und Ausführungsrechte (x) für die Datei file geben

chown und chgrp # Besitzer und Gruppe einer Datei festlegen

su user  # als benutzer user anmelden. su ohne Parameter gibt dauerhafte Rootrechte

Programme “killen”

Programme kann man auf verschiedene Weise zum Beenden zwingen:

pkill -f programm     # versucht "programm" zu beenden

killall programm

kill -9 ID

Andere (System)tools und Weitere Quellen

Um den Artikel möglichst allgemeingültig zu halten, habe ich mich bemüht, hier nur die “Standardbefehle” zu erwähnen. Natütlich gibt es noch etliche gute Bash-Tools, die die Produktivität nochmal verbessern. Statt der normalen Systemüberwachung top benutze ich z.B. htop, welches mehr Funktionen bietet. Für Systemtools gibt es bereits einen guten Blogartikel, welchen ich hier gerne verlinke: http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html.

Weitere Querverweise

• http://www.commandlinefu.com/ - Website, auf der interessante Bashbefehle gesammelt werden
• http://presentations.codeinthehole.com/confoo2011/ - 60 Folien lange & interessante Präsentation zum Thema "commandlineflue for web developers"
• http://linux.101hacks.com/ - Anwendungsbespiele bekannter Befehle

Ich hoffe die Tipps in diesem Artikel kann dem Einen oder Anderen die Arbeit in der Bash erleichtern. ;) Wie immer freue ich mich über Kommentare: Gibt es noch Befehle oder Tricks, die ihr weiterempfehlen könnt oder für erwähnenswert haltet?

PDF-Datei dieses Artikels erzeugen

Puppy Linux ist eine blitzschnelle Linux-Distribution mit geringer Anforderung an die Hardware. Gerade im letzten Jahr hat sich bei Puppy (englisch für “Welpe”) viel getan. Wegen seiner Kompatibilität zu den Paketquellen von Ubuntu (seit Puppy Version 5.x.) bietet Puppy inzwischen auch eine große Flexibilität in Bezug auf Treiber und andere Software.

Puppy beobachte ich nun schon seit ein paar Jahren und habe es immer mal wieder mit Freude genutzt. Auch wenn das sicher Geschmackssache ist, hat Puppy einen riesigen Charme-Faktor, alleine schon dafür, was das Look and Feel angeht. Dies ist für mich persönlich mit weitem Abstand das Beste, was Linux zu bieten hat.

Auf einem alten Acer Aspire mit 384 MB RAM fühlt sich das System (hier im Test: “Puppy-Lucid” 5.2.5) schneller an als z.B. eine der großen, gängigen Distributionen mit 1 GB RAM. Aber auch schon auf Systemen mit 128 MB (oder gar weniger) kann Puppy brauchbare Ergebnisse vorweisen.

Dafür muss man natürlich gewisse Abstriche in Kauf nehmen. Für Schlankheit und Tempo muss man ein bisschen Tribut zollen. So kommt z.B. der schlanke Dateimanager ROX zum Einsatz – Mit “Drag and Drop” usw. wird man hier nicht verwöhnt. Klar, dass Gnome, Unity oder KDE auf einem solchen System nicht zu finden sind.

So genial Puppy in den alten Versionen bereits war, so war es einfach nicht möglich, bestimmte Pakete problemlos zu installieren. Mit dem Schritt, neben dem Puppy-eigenen Paketsystem auch Ubuntu-Paketquellen nutzen zu können, hat Puppy einen ganz wichtigen Schritt nach vorne getan.

Puppy kommt zunächst mal als Live-System (i.d.R. als ISO-Datei für CDs) mit der Option, es komplett in den Speicher zu laden. Puppy kann aber auch installiert werden – z.B. auf Platte, USB oder SD-Card. Außerdem ist es möglich, Puppy als Live-CD zu booten, dann zu konfigurieren (Netzwerk usw.) und diese Einstellungen so auf der (als Multisession angelegten) CD zu speichern. Alle Einstellungen werden beim nächsten Boot wieder geladen – ideal für temporäre Konstellationen mit historischer Hardware, die man bei Bedarf aus dem Hut zaubern kann.

Auch die Konfiguration des Netzwerkes (v.a. was WPA2 angeht) scheint inzwischen problemlos zu funktionieren. Gerade WPA2 ist von Puppy noch nicht sooo lange gut unterstützt, was es für mich im Heimgebrauch bisher zum Killerkriterium werden ließ.

Download Puppy Linux 5.2.5 (ISO-Datei, 128 MB)

Ach ja: Wer einen EeePc als Netbook besitzt, kann sich eine eigens für den EeePc angepasste Puppy-Variante (Puppeee Linux) ansehen. Wehrmutstropfen ist allerdings, das diese noch auf der Version 4.x beruht. Und das bedeutet: Keine Ubuntu-Paketquellen!

Backups sollte man regelmäßig machen um im Falle eines System-Zusammebruchs o.ä. alle mehr oder minder wichtigen Dateien wieder aufspielen zu können. Wie ärgerlich ist es da, wenn die letzte Sicherung dann doch über ein Jahr oder länger zurück liegt, da man sich zwar vorgenommen hatte, das Backup durchzuführen, aber dieses letztendlich dann doch (un)absichtlich verschoben hat.

Wer nicht ständig daran denken möchte, kann nun unter Ubuntu auf eine Vielzahl von Programmen zurück greifen. Diese reichen von Shell-Scripten ohne graphische Oberfläche bis zu ausgeklügelten Klick n' Do Programmen, welche eigentlich durchweg mit der Maus konfiguriert werden können.

Nach einiger Überlegung die sich eigentlich auf pro und contra einer graphischen Oberfläche bezog, habe ich mich für "Back In Time" entschlossen: http://wiki.ubuntuusers.de/Back_In_Time

sudo apt-get install backintime-gnome

PDF-Datei dieses Artikels erzeugen

…oder: Der Fall Canonical und die Community.

Und wieder einmal zeigt sich der Unsinn der Copyright-Assignments für FLOSS-Projekte. Während mittlerweile alle großen OpenSource-Projekte  mit vielen Mitarbeitern (OpenCore-Projekte ausgeschlossen) entweder direkt ohne CAs gestartet sind oder aber diese mit der Zeit aufgegeben haben oder dies planen (z.B. Qt), verlangt Canonical, die Firma hinter Ubuntu, für jede von ihr initiierte OpenSource-Software ein Copyright-Assignment. Das Spektrum reicht dabei von einfachen Bibliotheken zum Transfer von Menüs über DBus über die Indikator-Applets bis hin zu Großprojekten wie Unity.

Mit Unterzeichnung des Canonical Contributor Agreements tritt ein Entwickler,  Grafiker oder Übersetzer quasi sämtliche Rechte an dem von ihm geschriebenen Code oder sonstigem Inhalt an Canonical ab. Canonical als alleiniger Rechteinhaber kann damit dann z.B. die Software unter einer beliebigen (auch proprietären) Lizenz relizensieren, was ansonsten ohne Zustimmung aller Beitragenden nicht möglich wäre. Aber es gibt noch weitere Probleme mit dieser CAs:

Ich entwickle selbst aktiv im AppStream Projekt mit. Dieses Projekt wird die Installation von Software unter Linux wesentlich vereinfachen und “social features” wie z.B. Bewertungen und Reviews Distributionsübergreifend zu Verfügung stellen. Auf dem AppStream Treffen wurde das “Ubuntu Software Center“, welches unter Ubuntu standardmäßig installiert ist, als grafische Oberfläche für AppStream ausgesucht, da es den Zielen der Initiative in hervorragender Weise entspricht. Um das SC auch für andere Distributionen nutzbar zu machen, müssen einige Codeänderungen getätigt werden, die auch für Ubuntu schon länger geplant sind, wie z.B. die Portierung des SC auf PackageKit und die Nutzung der AppStream Infrastruktur. Michael Vogt, der Autor vom Software Center und Canonical-Angestellter (und APT-Mitautor) wollte sich bei Canonical dafür einsetzen, das CA vom Software-Center zu entfernen, sodass auch andere Entwickler Code dazu beitragen können.

OpenSUSE hat daher für das AppStream-Projekt über den GSOC einen Studenten gefunden, der alle fehlenden Funktionen in das Software-Center implementieren wird – was an sich schonmal super ist. Dann erreichte uns jedoch eine Mail von Vincent Untz:

[..] I’ve been involved in several discussions with Canonical about this, and
the result appears to be that this [the CA] won’t change in the near future. What
might happen, but keep in mind that it’s just my understanding, is a
transition to Harmony once it’s ready:
http://www.harmonyagreements.org/ [...]

Canonical wird also das CA nicht entfernen, allenfalls das Projekt unter ein neues CA des eigens geschaffenen Harmony-Project stellen. Das ist aus folgenden Gründen schlecht:

• Es gibt viele Entwickler, die ein CA nicht unterschreiben wollen – warum sollte jemand die Rechte an von ihm geschriebenen Code an eine Firma abgeben?
• Es gibt bereits einige interessierte Entwickler, die aus dem einzigen Grund, dass es ein CA gibt, nichts zum Software-Center beitragen.
• Angestellte OpenSource-Entwickler (z.B. von RedHat) dürfen generell keine CAs ohne spezielle Ausnahmegenehmigung unterschreiben. Das bedeutet z.B. dass Entwickler wie Richard Hughes oder Vincent keine einzige Zeile Code beitragen dürfen.

Aufgrund dieser Tatsache wird momentan überlegt, entweder das CA allgemein zu akzeptieren und damit eine sehr langsame Entwicklung des Projektes in Kauf zu nehmen, einen Haufen von Patches zu verwalten, die jeder selbst dem SC hinzufügen muss, um die fehlende Funktionalität hinzuzufügen oder aber einen Fork des Projektes zu erstellen.

Das pikante daran: Im Grunde hätten das USC und der (mögliche) Fork die gleichen Ziele. Es würde also vermutlich unnötige Doppelentwicklungen geben. Der einzige Grund für dieses Dilemma ist, dass Canonical sein CA nicht entfernen will (warum auch immer). Darum wird die Entwicklung eines gesamten Projektes unnötig ausgebremst. Außerdem ist dieses Verhalten absolut nicht fair gegenüber der anderen Distributionen, die ja ihre eigenen Ressourcen (es ist z.B. OpenSUSEs GSOC-Student! Richard ist RedHat/Fedora Entwickler, Vincent bei OpenSUSE tätig…) in ein Ubuntuprojekt stecken würden. Zudem tritt Canonical wieder einmal die eigene “Ubuntu-Philosophie” mit Füßen.

Eine Entscheidung über das weitere Vorgehen mit dem USC ist noch nicht gefallen, ich habe selbst jedoch für einen Fork plädiert, obwohl ich es eigentlich hasse, doppelt zu entwickeln. Aber in diesem Fall ist es alleine schon deshalb nötig, um klare Verhältnisse in Sachen CA zu schaffen und keine halbgare Patchsammlung zu verwalten. Die meisten anderen Entwickler scheinen in eine ähnliche Richtung zu denken.

Persönlich bin ich schwer enttäuscht von Canonical – und das nicht zum ersten Mal. Zu Unity werde ich später nochmal was schreiben, wenn ich das jetzt tue, wird diese Artikel zu lang. Aber Canonicals Umgang mit dem Banshee-Projekt und vor allem Marks in meinen Augen unangebrachte Antwort darauf, sowie zahlreiche weitere Fälle (z.B. die AppIndicator-Diskussion) und ihre CAs auf allen Code, den sie schreiben hat dafür gesorgt, dass Canonical inzwischen wirklich sogut wie alles Ansehen, das sie noch bei mir hatten, verspielt hat. Zuvor habe ich in vielen Diskussionen Canonical verteidigt, denn es ist ihr gutes Recht, profitabel werden zu wollen und die Mittel, die sie einsetzen, dürfen sie auch frei wählen. Aber der miserable Umgang mit der Community, die Uneinsichtigkeit von Fehlern, das bewusste Übergehen der Community (z.B. kontroverse Einstellungen der Distro absichtlich so kurz vor dem Freeze ändern, dass sie nicht mehr rückgängig zu machen sind) und diese Heuchelei von der “Ubuntu-Philosophie” sind mir inzwischen zu viel. Mittlerweile sehe ich an allen Ecken die Mitglieder verschwinden, beispielsweise nahm der Gründer von GetDEB vor einem Monat seinen  Hut und übergab das Projekt an seinen Stellvertreter, da er sich Ubuntu nicht mehr zugehörig fühlte. COO und CTO von Canonical sind gegangen. (Obwohl die Gründe da – zugegeben – reine Spekulation sind) Bisher mit Ubuntu zufriedene GNOME-Entwickler wechseln – als logische Konsequenz aus Natty – zu Fedora (ich habe die letzten zwei Monate 13 Wechsel gezählt – und ich bin kein bisschen in GNOME involviert) und Nutzer stellen fest, dass “Debian ja doch gar nicht so schlimm ist” oder dass Linux Mint, Arch und OpenSUSE das gleiche wie Ubuntu bieten können.

Für mich ist der Wechsel zurück zu den Wurzeln schon fast abgeschlossen: Fedora und Debian Testing (oder Debian Rolling demnächst ) werden es wohl werden. (Obwohl ich natürlich auch weiter zu Ubuntu beitragen werde, vor allem wegen der tollen Ubuntu-Community)

Zum Schluss eine Frage an Alle da draußen: Findet ihr eine logische Erklärung für Canonicals Verhalten? Profitgier ist es jedenfalls nicht, da sich z.B. über CAs kaum was verdienen lässt und die Banshee-Beträge marginal sind. In meinen Augen geht es Canonical viel mehr darum, die Kontrolle über Ubuntu und das Ubuntuversum zu behalten – aber warum? Und vor allem: Wenn es wirklich um die Kontrolle ihrer Produkte, ihrer Distribution geht, dann haben sie das FLOSS-Prinzip wirklich nicht verstanden.

UPDATE: Zum selben Thema zu empfehlen ist auch ein Blogpost von Aaron Seigo. Desweiteren möchte ich nochmal klarstellen, dass es sich bei dem Beitrag oben natürlich um meine eigene, persönliche Meinung handelt. (Sollte aber eigentlich klar sein…) Zudem muss man natürlich zwischen CAs, die einer Firma z.B. das Recht zur Änderung der Lizenz innerhalb gewisser Grenzen (nur OSS z.B.) zugestehen (KDE) und CAs bei denen man das Copyright am Code abtritt (Canonical) unterscheiden. Und nicht zuletzt stelle ich natürlich auch nicht alles, was Canonical je geleistet hat in Frage, vor allem nicht als zufriedener Launchpad-Nutzer. (Aber auch das ist eigentlich klar im Artikel formuliert)

Das Full Circle Magazine hat die Spezialausgabe 2 zu Python veröffentlicht.

Bei der vorliegenden Ausgabe handelt es sich um eine Zusammenstellung verschiedener bereits veröffentlichter Artikel der Serie „Programming in Python“ aus den Ausgaben 35 bis 42.

• Program in Python - Part 9
  (MP3-Katalog 1)
• Program in Python - Part 10
  (MP3-Katalog 2, XML-Dokumente)
• Program in Python - Part 11
  (aktuelles Wetter von Webseite lesen)
• Program in Python - Part 12
  (Wettervorhersage von Webseite lesen)
• Program in Python - Part 13
  (Ausgaben mit Curses 1)
• Program in Python - Part 14
  (Ausgaben mit Curses 2)
• Program in Python - Part 15
  (Programmieren mit Pygame 1)
• Program in Python - Part 16
  (Programmieren mit Pygame 2)

Full Circle Magazine wird in englischer Sprache veröffentlicht.

Das Full Circle Magazine wird bereitgestellt unter Creative Commons Attribution-Share Alike 3.0