Das System erinnert mich an die Softwareinstallation unter MacOSX. Da lädt man sich das Programm auch als eine Datei runter, mountet diese und schiebt das Icon aus dem gemounteten Laufwerk in seinen "Application-Ordner" wo es dann installiert ist. Was das angeht ist klik sogar noch einfacher, da hier die Programmdatei direkt ausgeführt werden kann.
Tja, Jahrelang war die Softwareinstallation unter Linux eine Qual. Jetzt schwingt das Pendel in die andere Richtung bzw. ins andere Extrem. Vielleicht schafft es klik ja, ein Distributionsübergreifendes Packetformat durchzuboxen. Wäre für Linux auf dem Desktop ein Quantensprung.
Tja, dafür ist die Softwareaktualisierung in Mac OS X eine Qual. So schön, die Installation per Drag and Drop auch sein mag, spätestens, wenn man seine 50 oder mehr Programme alle einzeln und zu verschiedenen Zeiten upgraden und sich selbst um verfügbare neue Versionen und Sicherheits-Updates kümmern muss, spielt eine zentrale Paketverwaltung, wie Linux sie hat (und auch die Mac OS X-Distribution ohne Drittbrogramme), seine stärken aus.
dennoch ein paar Fragen, hofffentlich kann Sie jemand beantworten
1. Hat jemand schon mal versucht Wine Applikationen in einer Klick Datei zu installieren?, Gibts eine Kurze Anleitung, wie man IE5,6 bzw Elster oder so'n Zeug installiert ?
2. können Klik Dateien sich selbst verändern, also einfach eine sqlite DB rein, in die man dann auch Daten schreiben könnte, Also eine Datenbankanwendung mit Datenbank in einer einzigen Datei?
3. Könnte man das 8 loop Problem (2.11) dadurch umgehen, daß man cmg Dateien auspackt und und den Wrapper direkt startet?
Von Kurt Pfeifle am Mo, 17. Oktober 2005 um 01:57 #
zu 1.) Ja, hat. Nein, es gibt keine kurze Anleitung. Und es waere auch nicht legal, fertige .cmg-Dateien zu verteilen (ein "Rezept" vielleicht schon).
zu 2.) Nein, die klik-Dateien koennen sich nicht selbst aendern. Allerdings könnte ein modifiziertes wrapper-Script die sqlite-DB aus der .cmg zur Laufzeit rauskopieren, nach $HOME oder /tmp, und dann dort bearbeiten.
zu 3.) Richtig, das geht. Man kann auch manuell die Anzahl der möglichen cloop mounts erhöhen.
> zu 3.) Richtig, das geht. Man kann auch > manuell die Anzahl der möglichen cloop > mounts erhöhen.
Zum Beispiel, indem man options loop max_loop=32 in /etc/modprobe.conf (/etc/modutils.conf auf 2.4er-Systemen) plaziert. Hätte man auch ins FAQ reinschreiben können.
Huebi's Frage "Könnte man das 8 loop Problem (2.11) dadurch umgehen, daß man cmg Dateien auspackt und und den Wrapper direkt startet?" ist doch in 2.7 ganz klar beantwortet.
Wenn Huebi schon bis 2.11 gekommen ist, warum hatter dann 2.7 uebersprungen?
Von Kurt Pfeifle am Mo, 17. Oktober 2005 um 02:04 #
"Dies nutzen unter anderem die Macher von Enlightenment, die schon heute eine aktuelle Entwicklerversion ihres Windowmanagers als klik (...) zur Verfügung stellen." ----
Dieser Satz suggeriert eine falsche Urheberschaft des klik-Packets für Enlightenment.
Das Packet hat probono (Hauptentwickler von klik) gebaut, um zu zeigen, wie leistungsfähig klik ist. Die Enlighten-Entwickler wurden dann nachträglich darauf aufmerksam gemacht....
...allerdings auf http://www.dachboden-wg.de/forum/viewtopic.php?t=14929
Und in deren Version ging noch "grosses Dankeschön geht an Kurt Pfeifle aus dem klik Entwickler-Team für die Mithilfe per e-mail". Dieses ist nun weggefallen... ich kann mir kaum vorstellen, dass ein Neuling wie Marcel Urech einen so umfangreichen Artikel ohne fremde Mithilfe schreiben kann...
Von Kurt Pfeifle am Mo, 17. Oktober 2005 um 02:29 #
ac,
beruhige Dich wieder, es ist schon in Ordnung so.
Ich bin nicht im Geringsten beleidigt, schliesslich nennt er meine Mithilfe auf seiner Webseite -- und ich habe Marcel sogar *vorgeschlagen*, mit seinem "dachboden-wg.de"-Artikel an Pro-Linux heranzutreten, und ihn dort zur Veröffentlichung freizugeben.
das ist richtig so, ist ja sogar im Artikel verlinkt. Die FAQ habe ich allerdings nicht nur in der Dachboden-WG veröffentlicht, sondern auch schon in ein paar anderen Foren, sehe da nichts schlimmes dran. Die beiden Versionen sind auch nicht 1:1 identisch. Ein Artikel auf pro-linux eignet sich für die Berichterstattung zu klik aber einfach besser, darum kam die ganze Sache auch zu Stande.
Auch das mit der Mithilfe von Kurt ist richtig und war so abgemacht. Er hat mich auf noch vorhandene Fehler hingewiesen und ein paar Dinge ergänzt, nochmals Danke. Den Artikel an sich habe ich aber komplett selbst geschrieben, ich hoffe, er ist mir einigermassen gelungen, war auch mein erster auf pro-linux.de! Für Kritik und Anregungen bin ich natürlich immer offen... :)
Von Kurt Pfeifle am Mo, 17. Oktober 2005 um 02:25 #
"Ein Uninstall-Skript gibt es leider noch nicht." ---- Doch, gibt es. Es ist allerdings noch ziemlich elementar (z. B. macht es die Änderungen in der /etc/fstab nicht rückgänig). Versuche folgendes, um es direkt auszuführen:
--> wget klik.atekon.de/client/uninstall -O -|sh
Mach folgendes, um es zuerst anzuschauen, und erst dann auszuführen:
--> wget klik.atekon.de/client/uninstall --> cat uninstall --> sh -x uninstall
nennt sich Zero Install. Funktioniert wunderbar mit Rox und einigen anderen Applikationen, sogar solchen, die erst noch aus den Sourcen generiert werden müssen (wird automatisch beim ersten Aufruf erledigt).
Schön, dass das Rad immer noch mehrfach erfunden werden kann.
Nicht ganz falscher Hinweis, mal eine kleine Vergleichstabelle die ich per Google gefunden habe (keine Ahnung wie alt die ist, sehe kein Datum auf der Seite zum Inhalt):
Klik funktioniert aber dank "Serverbased-APT" mit wesentlich mehr Applikationen out-of-the-Box ohne, dass für jede ein extra Paket geschnürt werden muss und (um in deiner Schreibweise zu bleiben) damit das Rad (hier das Paket) wieder neu geschnürt werden muss ...
Das ist das eigentlich revolutionäre an Klik (neben der one-klik methode). Vielleicht lässt sich das sogar mit 0Install verknüpfen um die weiteren Vorteile von klik und 0install zu kombinieren.
Anders als die Paketmanager lauft klik nicht als root, kann also das System nicht veraendern.
klik fuehrt keine Dateien von beliebigen Quellen aus, sondern nur vom klik-Server. Ausserdem zeigt es die URLs der verwendeten Pakete an. Als naechstes ist eine digitale Signatur angedacht.
... wird leider nicht erwähnt: klik-Pakete können sich nicht gegenseitig zur Laufzeit aufrufen und man kann sie kaum konfigurieren bzw. ihnen Parameter/Optionen mitgeben.
Ein Beispiel: Wenn ich Kpovmodeller als klik installiere benötige ich natürlich Povray für die Ausgabe der Bilder, Kpvmodeler.klik kann aber NICHT povray.klik aufrufen - povray müsste also wie immer via Paketmanagement oder Eigenbau installiert werden. Noch absurder ist die Situation bei Audioanwendungen, die Jack verwenden, weil Jack ein Server ist, der nur über Aufrufparameter gesteuert wird. Alle (leider ohne Kommentar) auf der Klik-Website angebotenen Jack-Audiopakete sind damit unbrauchbar (Es sei denn, man installiert Jack selber "richtig" ).
Klik könnte allerdings für viele Programme eine sehr interessante Lösung sein, wenn solche Fallstricke angemessen dokumentiert und deren Umgehung vernünftig beschreiben wäre...
Genau da kommt aber die Tatsache der manuellen Klik-Pakete zum Tragen.
KPovmodeller sollte eigentlich von povray (hart) abhängen.
Damit sollte er povray nutzen können ... (Pfade werden durchs Wrapper-Script gesetzt)
Auch für Jack sollte es meines Wissens möglich sein ihn zu verwenden. Einfach auf der Kommandozeile das Klik-Run-Script ausführen und die Parameter angeben.
Wenn das nicht möglich ist, halt die Scripte patchen ...
>KPovmodeller sollte eigentlich von povray (hart) abhängen.
povray ist ein ganz schöner Brocken, beim kpovmodeler von atekon ist es jedenfalls nicht dabei.
>Auch für Jack sollte es meines Wissens möglich sein ihn zu verwenden.
Jack muss schon laufen, bevor z.B. muse.klik gestartet wird - jetzt könnte man sagen: "OK - dann muss das Muse-Paket eben Jack mitbringen und vor dem Start von muse muss dar Wrapper eben Jack starten..." Jack kann aber nur einmal laufen (genauso wie viele andere daemon/server ) - wenn also der Jack von Muse.klik läuft, müsste der Jack von z.B. Ardour.klik auf den Start verzichten und stattdessen Ardour an den (schon laufenden) Muse-Jack anschliessen.
Voraussetzung wäre immer, das klik-Pakete wie "richtig" installierte miteinander kommunizieren, sich gegenseitig aufrufen und, wenn nötig umkonfigurieren können. Das ist meines Wissens aber nicht möglich.
Um es ganz deutlich zu machen:
1.) Pakete wie Ardour.klik oder Kpovmodeller.klik sind so, wie sie zur Zeit angeboten werden, unbrauchbar
2.) folgender code, vor den Start des jeweiligen Programmes gesetzt, würde das Problem lösen:
kdialog --msgbox "Wenn Sie dieses Programm nutzen wollen, müssen Sie das Paket Jack installiert und gestartet haben. Jack finden Sie unter http://jackit.sourceforge.net";
Von Kurt Pfeifle am Di, 18. Oktober 2005 um 11:38 #
zettberlin,
Du hast voellig Recht mit den Beispielen muse, ardour und kpovmodeller. Es gibt noch viele mehr...
klik stellt beinahe seine komplette Palette aus dem Debian-Repository zusammen -- automatisch, über Skripte. Da kann dann z.Zt. sowas dabei rauskommen, ja. Was erforderlich ist: die entsprechenden "Rezepte" manuell anpassen. Entweder so wie Du vorgeschlagen hast, oder (mehr im Sinne der Benutzerfreundlichkeit) durch Bündeln von jack mit muse, so dass ein sofort funktionsfähiges .cmg entsteht (wie etwa das neuere(!) enlightenment-1.6.999.cmg, das auch noch einen Xnest-basierten X-server mitbringt und startet).
Für die meisten Pakete braucht's nicht mehr als 1-5 Zeilen Änderungen im Shell-code des "Rezeptes"....
Der Weg nach vorne für klik ist: Maintainer gewinnnen für diese "problematischen" Pakete. Das kleine Team wie es gegenwärtig ist, schafft das nicht alleine.
>klik stellt beinahe seine komplette Palette aus dem Debian-Repository zusammen -- automatisch
davon habe ich schon im Forum auf atekon gelesen - automatisch ist eben problematisch Je weniger Lernaufwand man dem Nutzer zumuten möchte, desdo mehr Planungs/Konstruktionsaufwand muss man selber treiben (zugespitzt könnte man sagen, " je weniger Intelligenz und Kenntnisse der Nutzer haben darf, desdo mehr Intelligenz muss ich der Methode/Software etc mitgeben"). Ich denke allerdings, das das alles lösbare Probleme sind, an sich ist klik eine gute Idee und für Standalonepakete bewährt es sich erstaunlich gut
Um ehrlich zu sein: ich habe nicht sehr viel Zeit und selber bin ich mit apt, YAST und Selberbauen sehr gut versorgt. Zumindest für die JACK-Pakete eine geeignte Anleitung zum Umschiffen der jetzt noch vorhandenen Probleme könnte ich aber durchaus liefern. Ich schreibŽ mal eine Mail an Kurt...
Von hans maulwurf am Mo, 17. Oktober 2005 um 19:52 #
> Das Skript war ursprünglich dazu gedacht, die Software-Installation für Knoppix-Live-CDs zu vereinfachen. Mittlerweile ermöglicht es aber auch die Verwendung von Debian-Paketen auf beliebigen Distributionen mit einem bequemen »one-klik-setup«
Wenn ich mich recht erinnere gibt es diese Technik bei Lindows schon recht lang unter dem Namen: "click and run"
Es reicht, das Desktop-Icon zu löschen, um ein klik-Programm restlos zu entfernen
Clever oder nicht Clever?!
Tja, Jahrelang war die Softwareinstallation unter Linux eine Qual. Jetzt schwingt das Pendel in die andere Richtung bzw. ins andere Extrem. Vielleicht schafft es klik ja, ein Distributionsübergreifendes Packetformat durchzuboxen. Wäre für Linux auf dem Desktop ein Quantensprung.
Gruß, nidhoegg
Wahnsinn, in welchen Zeiten wir inzwischen leben...
1. Hat jemand schon mal versucht Wine Applikationen in einer Klick Datei zu installieren?, Gibts eine Kurze Anleitung, wie man IE5,6 bzw Elster oder so'n Zeug installiert ?
2. können Klik Dateien sich selbst verändern, also einfach eine sqlite DB rein, in die man dann auch Daten schreiben könnte, Also eine Datenbankanwendung mit Datenbank in einer einzigen Datei?
3. Könnte man das 8 loop Problem (2.11) dadurch umgehen, daß man cmg Dateien auspackt und und den Wrapper direkt startet?
danke schon mal
viele Grüße
zu 2.) Nein, die klik-Dateien koennen sich nicht selbst aendern. Allerdings könnte ein modifiziertes wrapper-Script die sqlite-DB aus der .cmg zur Laufzeit rauskopieren, nach $HOME oder /tmp, und dann dort bearbeiten.
zu 3.) Richtig, das geht. Man kann auch manuell die Anzahl der möglichen cloop mounts erhöhen.
> manuell die Anzahl der möglichen cloop
> mounts erhöhen.
Zum Beispiel, indem man options loop max_loop=32 in /etc/modprobe.conf (/etc/modutils.conf auf 2.4er-Systemen) plaziert. Hätte man auch ins FAQ reinschreiben können.
Mal gucken, ob ich das noch reineditieren kann...
Wenn Huebi schon bis 2.11 gekommen ist, warum hatter dann 2.7 uebersprungen?
Weil ich nicht halb so klug bin wie Du
entschuldige meine Unzulänglichkeit.
liebe Grüße
----
Dieser Satz suggeriert eine falsche Urheberschaft des klik-Packets für Enlightenment.
Das Packet hat probono (Hauptentwickler von klik) gebaut, um zu zeigen, wie leistungsfähig klik ist. Die Enlighten-Entwickler wurden dann nachträglich darauf aufmerksam gemacht....
der Satz ist so tatsächlich misslungen, sorry und Danke für den Hinweis!
Und in deren Version ging noch "grosses Dankeschön geht an Kurt Pfeifle aus dem klik Entwickler-Team für die Mithilfe per e-mail". Dieses ist nun weggefallen... ich kann mir kaum vorstellen, dass ein Neuling wie Marcel Urech einen so umfangreichen Artikel ohne fremde Mithilfe schreiben kann...
beruhige Dich wieder, es ist schon in Ordnung so.
Ich bin nicht im Geringsten beleidigt, schliesslich nennt er meine Mithilfe auf seiner Webseite -- und ich habe Marcel sogar *vorgeschlagen*, mit seinem "dachboden-wg.de"-Artikel an Pro-Linux heranzutreten, und ihn dort zur Veröffentlichung freizugeben.
das ist richtig so, ist ja sogar im Artikel verlinkt. Die FAQ habe ich allerdings nicht nur in der Dachboden-WG veröffentlicht, sondern auch schon in ein paar anderen Foren, sehe da nichts schlimmes dran. Die beiden Versionen sind auch nicht 1:1 identisch. Ein Artikel auf pro-linux eignet sich für die Berichterstattung zu klik aber einfach besser, darum kam die ganze Sache auch zu Stande.
Auch das mit der Mithilfe von Kurt ist richtig und war so abgemacht. Er hat mich auf noch vorhandene Fehler hingewiesen und ein paar Dinge ergänzt, nochmals Danke. Den Artikel an sich habe ich aber komplett selbst geschrieben, ich hoffe, er ist mir einigermassen gelungen, war auch mein erster auf pro-linux.de! Für Kritik und Anregungen bin ich natürlich immer offen... :)
----
Doch, gibt es. Es ist allerdings noch ziemlich elementar (z. B. macht es die Änderungen in der /etc/fstab nicht rückgänig). Versuche folgendes, um es direkt auszuführen:
--> wget klik.atekon.de/client/uninstall -O -|sh
Mach folgendes, um es zuerst anzuschauen, und erst dann auszuführen:
--> wget klik.atekon.de/client/uninstall
--> cat uninstall
--> sh -x uninstall
Schön, dass das Rad immer noch mehrfach erfunden werden kann.
Gruß, Alex
http://0install.net/matrix.html
Und hier eine kleine Diskussion zu diesem Thema:
http://dot.kde.org/1126867980/1126955369/
Das ist das eigentlich revolutionäre an Klik (neben der one-klik methode). Vielleicht lässt sich das sogar mit 0Install verknüpfen um die weiteren Vorteile von klik und 0install zu kombinieren.
cu
Fabian
Wie sieht es mit der Sicherheit aus? Wie wird die Integrität der Dateien überprüft?
klik fuehrt keine Dateien von beliebigen Quellen aus, sondern nur vom klik-Server. Ausserdem zeigt es die URLs der verwendeten Pakete an. Als naechstes ist eine digitale Signatur angedacht.
Ein Beispiel:
Wenn ich Kpovmodeller als klik installiere benötige ich natürlich Povray für die Ausgabe der Bilder, Kpvmodeler.klik kann aber NICHT povray.klik aufrufen - povray müsste also wie immer via Paketmanagement oder Eigenbau installiert werden.
Noch absurder ist die Situation bei Audioanwendungen, die Jack verwenden, weil Jack ein Server ist, der nur über Aufrufparameter gesteuert wird. Alle (leider ohne Kommentar) auf der Klik-Website angebotenen Jack-Audiopakete sind damit unbrauchbar (Es sei denn, man installiert Jack selber "richtig" ).
Klik könnte allerdings für viele Programme eine sehr interessante Lösung sein, wenn solche Fallstricke angemessen dokumentiert und deren Umgehung vernünftig beschreiben wäre...
KPovmodeller sollte eigentlich von povray (hart) abhängen.
Damit sollte er povray nutzen können ... (Pfade werden durchs Wrapper-Script gesetzt)
Auch für Jack sollte es meines Wissens möglich sein ihn zu verwenden. Einfach auf der Kommandozeile das Klik-Run-Script ausführen und die Parameter angeben.
Wenn das nicht möglich ist, halt die Scripte patchen ...
cu
Fabian
>KPovmodeller sollte eigentlich von povray (hart) abhängen.
povray ist ein ganz schöner Brocken, beim kpovmodeler von atekon ist es jedenfalls nicht dabei.
>Auch für Jack sollte es meines Wissens möglich sein ihn zu verwenden.
Jack muss schon laufen, bevor z.B. muse.klik gestartet wird - jetzt könnte man sagen:
"OK - dann muss das Muse-Paket eben Jack mitbringen und vor dem Start von muse muss dar Wrapper eben Jack starten..."
Jack kann aber nur einmal laufen (genauso wie viele andere daemon/server ) - wenn also der Jack von Muse.klik läuft, müsste der Jack von z.B. Ardour.klik auf den Start verzichten und stattdessen Ardour an den (schon laufenden) Muse-Jack anschliessen.
Voraussetzung wäre immer, das klik-Pakete wie "richtig" installierte miteinander kommunizieren, sich gegenseitig aufrufen und, wenn nötig umkonfigurieren können. Das ist meines Wissens aber nicht möglich.
Um es ganz deutlich zu machen:
1.) Pakete wie Ardour.klik oder Kpovmodeller.klik sind so, wie sie zur Zeit angeboten werden, unbrauchbar
2.) folgender code, vor den Start des jeweiligen Programmes gesetzt, würde das Problem lösen:
kdialog --msgbox "Wenn Sie dieses Programm nutzen wollen, müssen Sie das Paket Jack installiert und gestartet haben. Jack finden Sie unter http://jackit.sourceforge.net";
Du hast voellig Recht mit den Beispielen muse, ardour und kpovmodeller. Es gibt noch viele mehr...
klik stellt beinahe seine komplette Palette aus dem Debian-Repository zusammen -- automatisch, über Skripte. Da kann dann z.Zt. sowas dabei rauskommen, ja. Was erforderlich ist: die entsprechenden "Rezepte" manuell anpassen. Entweder so wie Du vorgeschlagen hast, oder (mehr im Sinne der Benutzerfreundlichkeit) durch Bündeln von jack mit muse, so dass ein sofort funktionsfähiges .cmg entsteht (wie etwa das neuere(!) enlightenment-1.6.999.cmg, das auch noch einen Xnest-basierten X-server mitbringt und startet).
Für die meisten Pakete braucht's nicht mehr als 1-5 Zeilen Änderungen im Shell-code des "Rezeptes"....
Der Weg nach vorne für klik ist: Maintainer gewinnnen für diese "problematischen" Pakete. Das kleine Team wie es gegenwärtig ist, schafft das nicht alleine.
Machst Du mit?
davon habe ich schon im Forum auf atekon gelesen - automatisch ist eben problematisch
Je weniger Lernaufwand man dem Nutzer zumuten möchte, desdo mehr Planungs/Konstruktionsaufwand muss man selber treiben (zugespitzt könnte man sagen, " je weniger Intelligenz und Kenntnisse der Nutzer haben darf, desdo mehr Intelligenz muss ich der Methode/Software etc mitgeben").
Ich denke allerdings, das das alles lösbare Probleme sind, an sich ist klik eine gute Idee und für Standalonepakete bewährt es sich erstaunlich gut
Heh. Du hast Kurt's Frage elegant umschifft ;-P
Heh. Du hast Kurt's Frage elegant umschifft ;-P
hmmmm... tatsächlich ;-)
Um ehrlich zu sein: ich habe nicht sehr viel Zeit und selber bin ich mit apt, YAST und Selberbauen sehr gut versorgt.
Zumindest für die JACK-Pakete eine geeignte Anleitung zum Umschiffen der jetzt noch vorhandenen Probleme könnte ich aber durchaus liefern.
Ich schreibŽ mal eine Mail an Kurt...
Wenn ich mich recht erinnere gibt es diese Technik bei Lindows schon recht lang unter dem Namen:
"click and run"
Inwiefern stehen diese beiden Sachen zueinander?
http://0install.org/injector.html