!!!alte LUG Anregungen

die Seite mit den LugAnregungen ist inzwischen sehr unübersichtlich geworden.

Deshalb habe diese Unterseite angelegt, um alte Diskussionen hier zu dokumentieren. Dann wird die Hauptseite wieder etwas übersichtlicher.

!!Wiki bei Sourceforge

Für unsere Aktivitäten im Internet nutzen wir zur Zeit die Dienste von Sourceforge. Leider gibt es mit der Mailingliste immer mal wieder Probleme, weil der Kai keinen Postmaster hat. Aber schwerer wiegt zur Zeit, dass dieses Wiki regelmäßig 50x-Returncodes liefert und die Arbeit damit keinen Spaß macht.
** ''Diese Returncodes gehören verboten, volle Zustimmung'' -- MarkusMonderkamp
*** Wie habt ihr das erlebt: Ich habe die Returncodes in den letzten drei Tagen nicht mehr erlebt. Sollte sich ein Teil der Diskussion erledigt haben? --PeterHormanns

Daher die Idee -- Webspace kostet ja fast nichts mehr -- von Sourceforge wegzugehen. -> [Testaufruf zu linuxproject.de|http://www.lug-kr.de/cgi-bin/lugwiki.pl?action=browse&diff=1&id=LugAnregungen&diffrevision=8&revision=7] von ThomasBayen
** ambivalenter Einschub von MarkusMonderkamp:
**
** __Haftungsaspekt__:
** Es gibt genug Zeitgenossen, die ihre Einnahmen aus Abmahnungen gesetzeswidriger Webspace-Inhalte finanzieren.
** Fehlendes Impressum, urheberrechtliche Begriffe, One-Click-Techniken ... und schon darf der Provider haften.
** Solange wir bei Sourceforge (kostenfrei) hosten, sind wir fein aus dem Schussfeuer, denke ich.
*** Ich bin ja nicht wirklich juristisch firm, aber meiner Meinung nach gilt die Haftung erstmal für den Inhalteanbieter. Wenn dieser nicht spurt, kann man sich dann auch an den Provider wenden. Dieser hat aber nur insofern Haftung, als das er im Zweifel bei Kenntnisnahme die Seite z.B. abschalten kann. Ich vermute also, daß wir auch heute schon für ungesetzliche Inhalte in unserem Wiki haftbar sind, sobald wir davon wissen und nichts dagegen tun.-- ThomasBayen
**** O.k., da lag ich falsch. Ich vergass das Motto von Dieter Nuhr:
**** Wenn ich von irgend etwas keine Ahnung habe, einfach mal Fresse halten. -- MarkusMonderkamp()
** Die fehlende Java-Unterstützung bei Sourceforge gibt mir jedoch wieder Grund, __Thomas' Idee zu bejubeln__:
** dann müssen wir also ein separates Web-Standbein realisieren.-- MarkusMonderkamp
*** Ähem - Danke für die Lorbeeren, aber die Idee kam erstmal von PeterHormanns. Und Java-Unterstützung gibt es bei mir als Provider nicht (bei Peter (Hostsharing) aber vielleicht doch?!?)
**** Ja so ist es. Bei Hostsharing kann man einen eigenen Tomcat betreiben. --PeterHormanns

!!Mailingliste

Ich (PeterHormanns) betreibe bei Hostsharing ecartis mit etwa einem guten halben dutzend Mailinglisten. Da würde eine mehr nicht auffallen und der DNS für lug-kr.de ist sowieso schon bei mir...
** MarkusMonderkamp an Peter: Wie steht ecartis zu Java-Unterstützung?
*** Ich verstehe den Zusammenhang nicht, Ecartis (vgl. http://www.ecartis.org) ist ein Programm für Mailinglisten, vergleichbar mit Mailman, aber etwas einfacher gestrickt.
**** Kannst Du auch nicht verstehen, weil ich Ecartis für den Codenamen des Hostsharing-vereins gehalten habe. Ein mal kurz googeln hätte mich vor diesem hoffentlich verzeihbaren Fehler bewahren können. Danke immerhin für Deinen Link. Meine Frage, ob Euer Hostsharing Java anbietet, hast Du dann jedenfalls oben positiv beantwortet. Womit ich Dich dann zum Installateur für JSP-Wiki ernenne. Das LUG-KR TWiki läuft zum Vergleich der Wikis zumindest als Proof of Concept auf Sourceforge, mangels eigenem Webspace.
** ThomasBayen an Peter: Wie stehts denn da mit Spamschutz? Ich weiss nicht, wie Sourceforge das macht, aber obwohl die Listenadresse sowas von öffentlich ist, kommt da nur selten was.
*** Sourceforge ist da sehr restriktiv, Kai kann ein Lied daven singen ;-) Bei Hostsharing hätten wir die Möglichkeit Spamassassin oder etwas anderes vorzuschalten und / oder können die Mailingliste als geschlossene Liste (nur für eingeschriebene Teilnehmer) betreiben. --PeterHormanns

!! Website und Wiki

Ich (ThomasBayen) bin Mini-Internetprovider und habe einen großzügig bemessenen Webspace zur Verfügung. (Ich kann auch Mailinglisten mit allem Pipapo einrichten, allerdings wäre das das erste Mal, also wäre das ggf. besser beim Peter untergebracht.) In meinem Webspace ist wie bei Sourceforge kein Java möglich (also kein JSPWiki) und auch kein ssh, aber natürlich CGI. Ich könnte einen oder mehrere ftp-Accounts für LUG-Mitglieder einrichten, so daß die Wartung der Seite nicht nur von einer Person vorgenommen werden kann.

Die Probleme mit dem Wiki treten offensichtlich nur bei CGI-Seiten auf. Vielleicht teilt man den Webspace ja auch auf und läßt die normalen Seiten bei Sourceforge und lagert lediglich das Wiki aus.

Ein Wiki mit History braucht übrigens schnell einige MB an Webspace (oder Datenbank).

MarkusMonderkamp ist dabei mit anderer Wiki-Software zu experimentieren (nur TWiki oder auch andere?). Ich selbst (PeterHormanns) würde ja ein JSPWiki bevorzugen. Vielleicht versuchen wir im Rahmen des September-Themenabends über die Zukunft unseres Wikis (und unserer Rest-Website) zu entscheiden.

! Eine Lanze für Sorceforge von ThomasBayen

Einer muss hier glaube ich mal eine Lanze brechen: - Knack! -. Wir arbeiten jetzt seit Juli 2000 mit Sourceforge, das sind 6 Jahre. In all der Zeit haben Sie uns einen recht verlässlichen Service zukommen lassen. Sie bieten eine Mailingliste, die jeder von uns administrieren kann, als wir Krefix-Images ins Web stellen wollten, hatten wir Ruck-Zuck einen hunderte MB grossen Download-Bereich. Wir alle können auf den Webspace zugreifen (man sieht sogar an den Benutzerkennungen, wer was gemacht hat). Wir haben einen funktionierenden öffentlichen CVS (und demnächst auch SVN) und und und... Als wir die Seite eingerichtet haben, war Andi Steinscherer der Domaininhaber (ist er heute noch) und Andreas Beckermann hat das Projekt eingerichtet. Beide sind keine aktiven LUG-Mitglieder mehr und trotzdem haben die aktuell aktiven Mitglieder immer noch vollen Zugriff auf alles. Ich würde diese ganze seit Jahren gut funktionierende Infrastruktur wegen ein paar Wochen CGI-Problemen nur ungern komplett über Bord werfen.

Wie gut kann Peter versprechen, daß CGI-Probleme bei Hostsharing (mit seinen pömeligen paar Rechnern) nicht auch auftreten? Und wie gut kann ich versprechen, daß das bei Domainfactory (wo ich nur ein pömeliger kleiner Kunde bin) nicht auch passiert? Andererseits: Wer kann versprechen, daß VA Linux nicht nächstes Jahr Sourceforge schließt (oder ganz konkurs geht)?

Wir sollten auch darauf achten, daß wir uns nicht von einer einzelnen Person abhängig machen. Andi und Andi sind gute Beispiele dafür, daß auch aktive, wertvolle Mitglieder nicht für ewig im Kern der LUG bleiben. Wenn also einer von uns Webspace, Mailinglisten oder irgendwas zur Verfügung stellt, sollte klar sein, daß diese Ressourcen langfristig zur Verfügung stehen müssen und von allen anderen (d.h. den LUG-Kernmitgliedern) konfiguriert und verwaltet werden können.

Mein Vorschlag dazu ist, daß wir die LUG-Seite an sich lassen wo sie ist und damit die Infrastruktur des Sourceforge-Projektes erhalten. Dann können wir gerne spontan entscheiden, daß wir bestimmte Ressourcen auslagern, wenn wir damit experimentieren wollen oder SF Probleme hat. Das hiesse, man könnte das jetzige Wiki z.B. auf wiki.lug-kr.de auslagern und diese Domain dann woandershin routen (z.B. in meinen grossen Webspace). Dann könnte man einen javaserver.lug-kr.de einrichten, der dann ein JSPWiki und andere Java-Spielereien beheimatet (z.B. bei Hostsharing). Man könnte auch experiment.lug-kr.de einrichten und dieses auf einen dyndns-Zugang umleiten, der bei einem von uns im Keller steht (vielleicht auf Franz UML/XEN-Maschine). Dort könnte man experimentell z.B. Java 6 und Tomcat 4711.x auf Debian unstable einsetzen, ohne die Integrität der gesamten Website aufs Spiel zu setzen.

Hat Sourceforge seine Probleme behoben, würde das Perl-Wiki wieder zurückwandern und gut ist. :-)
*** volles ACKnowledge - ich möchte Sourceforge nichts böses und hoffe, dass die Performance- und Zugriffsprobleme bald gelöst sind. --MarkusMonderkamp
** Die Argumente von Thomas finde ich richtig. Wenn wir den Internet-Auftritt der LUG vom Engagement einzelner Leute in der LUG abhängig machen, könnte das irgendwann Probleme bereiten. (Jetzt könnte ein Plädoyer für eine Vereinsgründung folgen ;-) ...) --PeterHormanns
*** Ich stelle einen Antrag zur Vereinssatzung an den Schriftführer und beantrage unter Verschiedenes, sofern die Versammlung stimmberechtigt ist, eine Senkung der nicht vorhandenen Mitgliedsbeiträge, die Streichung des Wortes "Gemein" aus der Gemeinnützigkeit, dreifache Steuerpflicht der Spenden für die Patentanwälte im Europaparlament, die Umbenennung der Jahreshauptversammlung in Lichtjahreshauptversammlung, Umbennung der Protokollsoftware von MS-Schriftführer in iSchriftführer, und alles, was Vereinsmüde noch anführen können. Falls Dein Vereinsvorschlag ernst gemeint ist: wo liegt der Vorteil gegenüber der jetzt existierenden Interessngemeinschaft? Mit dem Ausscheiden des letzten Vereinsmitgliedes hat jeder Webspace und jedes Wirtschaftsgut der Lug-KR e.V. seine Zugehörigkeit zum Verein und zur Vereinsgedanken verloren. Eine Stiftung würde weiterleben, aber dazu ein anderes Mal mehr, z.B. von Mark Shuttleworth-- MarkusMonderkamp alias Schandmaul Eric
** Ich würde gern die alte Rest-LUG-Website ganz über Bord werfen und lieber eine Startseite ins Wiki oder vor das Wiki setzen. --PeterHormanns
*** Gerne! Muss nur mal jemand machen. ''(Wenn wir das Wiki evtl. auf eine andere Domain umbiegen wollen, besser "vor")'-- ThomasBayen
*** Peter's Vorschlag gefällt mir, dann brauche ich kein separates Lesezeichen, um aus dem Knebel-Frame der Lugseite eine Voll-Wiki-Anzeige zu erzeugen. Als Einstiegslogo schlage ich ein Signet &aacute; la Debian-Logo[www.3labs.com|http://peoples.mandriva.com/~ayo/distant_file/dessins/gallery/stand_debian.png]>> <<(Debian-Logo von <<{{{FrozenBubble}}}-Designern{{{FrozenBubble}}}-Designern) vor --MarkusMonderkamp
** Den Ansatz der Subdomains finde ich gut, wenn es sich lohnt, könnten Projekte der LUG einen eigenen Internetauftritt irgendwo unter einprojekt.lug-kr.de haben -- wenn es sich wirklich lohnt... --PeterHormanns

__Performance-Test...__ Die Neugier liess mich nicht los: Um zu sehen, ob die Welt durch unser Gerede überhaupt besser wird, habe ich mal den gesamten LUG-Webspace (ca. 52MB, davon ca. 23MB unser Wiki und ca. 19MB TWiki(!?!)) auf meinen Provider kopiert. Interessierte Kreise können also unter http://lug-kr.linuxproject.de mal herumspielen. Ich bitte in nächster Zeit um Tests auch zu unterschiedlichen Tageszeiten. Das dortige Wiki ist natürlich nicht für echte Beiträge gedacht (sonst müssen wir alles doppelt pflegen) und wird nach Ablauf der Testphase ggf. wieder gelöscht. -- ThomasBayen
*** [TWiki|http://lug-kr.linuxproject.de/cgi-bin/twiki/bin/view] war nur eine Technologie-Studie. Es läuft bei uns auffe Schicht wie Schmitz Katze und brummt vor Ideenfluss. Auf Sourceforge sieht die Sache anders aus. Ich bin dafür, es Anfang September von der Sourceforge-Platte zu putzen.
**** Lass erstmal unseren Themenabend dazu vergehen. Vielleicht wollen wir das ja behalten?!? Was die Katze anbetrifft: Ich bin gaz hin und wech über die Antwortzeit der Installation bei http://lug-kr.linuxproject.de. Ein Stück weit liegt das wahrscheinlich auch schlicht an der Signallaufzeit nach USA. Ich denke daher, Geschwindigkeit ist nicht unser Problem.

! Wiki-Meditation von MarkusMonderkamp

Ich f&uuml;lle diese Seite noch mehr und fasse den [Wiki-Vergleich|http://www.wikimatrix.org/compare/JSPWiki+TWiki+UseMod] zwischen __JSP-, T-__ und __Usemodwiki__ zusammen.

__[Usemod-Wiki|http://www.usemod.com/cgi-bin/wiki.pl]__

Das hiesige Usemodwiki erscheint mir mit besserem Antwortverhalten zur Zeit f&uuml;r die jetzigen LUG-Beitr&auml;ge als angemessen, d.h. es entfaltet IMHO (tm) seine gr&ouml;&szlig;te Wirkung bei kleinstem Editieraufwand.

* hohe Geschwindigkeit, __wenn__ der Werbserver mitspielt (Hallo an Sourceforge!)
* Unterseiten
* Sehr einfache Installation
* Sehr einfache Konfiguration
* Nicht auf eine Datenbank angewiesen (aber auch keine möglich)
* Quellcode so übersichtlich, daß Änderungen grundsätzlich möglich sind
* sehr selten neue Versionen (Für ein Werkzeug ist das ein Vorteil, für Technologie-Interessierte ein Nachteil)

__[JSP-Wiki|http://jspwiki.org/]__

* JSP-WIKI besticht durch seine vielseitigen Datenbankplugins:
* {{{MySQL, Pg, Oracle, SQLite, BDB per PlugIn.}}}
** Diese Argument würde ich anders formulieren: Der Page-Provider ist über eine definierte API austauschbar. Daher können Seiten als Textdateien, in RCS oder in nahezu jeder beliebigen Datenbank gespeichert sein.
* Das Menü und der sog. Menü-Footer sind ganz normale Wiki-Seiten. D.h. es gibt ein auf jeder Seite sichbares Menü, das vom Benutzer leicht angepasst werden kann.
* Die Templates (JSPs) sind klar vom Rest der Wiki-Software getrennt und leicht anpassbar. Jedes (naja, ich sage lieber fast jedes) beliebige Layout ist machbar.
* Zusatzfunktionen lassen sich leicht über (Java-)Plugins realisieren. {{{RecentChanges, PageIndex, Inhaltsverzeichnisse}}} und vieles mehr sind im JSPWiki als Plugins realisiert. Es gibt aber auch Blog, Kalender etc.

__''Jedoch''__
* Keine Festlegung von "{{{MinorChanges}}}" bei der Ver&ouml;ffentlichung
* keine freien Links
** Was sind "freie Links"? --PeterHormanns
*** ...ein Zitat aus der o.g. [Wiki-Matrix|http://www.wikimatrix.org/compare/JSPWiki+TWiki+UseMod]
* Textsuche nur &uuml;ber Seitennamen
** Das ist definitiv falsch --PeterHormanns
* brauchbares Antwortverhalten / Geschwindigkeit?
** Die Antwortzeiten sind kein Problem und vom Prinzip her besser als PHP und CGI ohne weitere Hilfsmittel --PeterHormanns
* Was mir eher fehlt sind weitere Stukturierungsmittel, also z.B. die Unterseiten des UseModWiki oder die Namensräume des TWiki --PeterHormanns
*** Wieviel Aufwand ist es denn, mehrere Wikis parallel zu installieren? Geht das in einer Software-Installation und z.B. jeweils anderer Datenbank?
**** Man kann in einem Tomcat beliebig viele Wikis betreiben, unter unterschiedlichen Domains oder Kontexten. Man benötigt dazu nur eine Installation der Wiki-Software und mehrere context.xml-Dateien, die jeweils eine eigene Properties-Datei referenzieren. Die Seiten liegen per Default als Dateien auf der Platte. Datenbanken über zusätzliche Page-Provider. Für die Strukturierung kann man auch Seiten in der Form "Hauptseite.Unterseite" benennen. Plugins können z.B. alle Unterseiten zu einer Hauptseite anzeigen. Aber ich habe diese Plungins nie ausprobiert.
***** Dann nenne ich Deine "Kontexte" jetzt mal "Namensraum" und sehe Deinen Einwand (für unsere Anwendungen) als erledigt an. :-) Was vielleicht fehlt, ist dann höchstens eine Doku bzw. ein Skript, um die Dinger einfach sozusagen "am Fließband" erstellen zu können. -- ThomasBayen
****** Nicht ganz: Es fehlt zum Beispiel eine Suchfunktion über alle Kontexte, ein Index über alle Seiten, ein "RecentChanges" über alle Namensräume... Es bleiben mehrere Wikis... --PeterHormanns

Ein JSPWiki zum Spielen haben wir übrigens unter http://sandkasten.jalin.de/ installiert. Anmeldung mit sandkasten/sandkasten --PeterHormanns
*** Gar nicht &uuml;bel, jetzt habe ich Sand unter den Fingern&auml;geln;-) -- MarkusMonderkamp
*** Ungewohnt: Links werden erst in der Reihenfolge ''Linknamen|URL'' eingegeben.

__[TWiki|http://twiki.org]__
Im Unterschied zu den bisher genannten Wikis sind
* RCS fest eingebaut, d.h. Seiten-Versionen sind schnell mit RCS verwaltet
* eingebaute Mail-Encryption
* &Auml;nderungs-Zusammenfassung per Mail
* Konfliktaufl&ouml;sung bei gleichzeitigem Schreibzugriff
* In der aktuellen Version 4.0 unterstützt ein [WYSIWYD|http://internetwoordenboek.kennisnet.nl/look2/show.asp?i=1024&qu=WYSIWYD]-Editor den Seitenautor
* PDF- und XML-Export per Plugin
* Textsuche &uuml;ber den kompletten Inhalt
* Serienm&auml;ssige Plugins: Calender, Spreadsheet (Tabellenkalkulation), Diashow- und Tabelleneditor
* brauchbare Geschwindigkeit, __wenn__ der Werbserver mitspielt
* (Momentan -24.08.2006- kaum mit [TWiki auf Sourceforge|http://lug-kr.sourceforge.net/cgi-bin/twiki/bin/view]!)

!! weitere {{{(Themen-/Projekt-)}}}Anregungen

* XEN
* UML - hier: UserModeLinux
** Apropos: [Irre|http://www.archive.org/download/SeanKellyGettingYourFeetWetwithPlone/wetfeet.mov] finde ich die automatisierte Produkterstellung von [ArchGenXML|http://plone.org/documentation/tutorial/archgenxml-getting-started] aus XMI-Dateien von [Argouml|http://argouml.tigris.org/] f&uuml;r [Python|http://plone.org/].
** __Update__ &Auml;hnlich:[Perl-Konverter|http://search.cpan.org/author/KSTEPHENS/UMMF-1.02/lib/UMMF.pm] XMI nach Perl (MarkusMonderkamp)
* BootCD
* LFS - Linux from Scratch
** Jens, es wäre schön, wenn deine Texte etwas ausführlicher würden...
** ist ja gut --habe ich nun geändert

* Diskless Client -- hoffe mal das mir der Thomas meine Fragen beantwortet, wenn ich welche habe nach dem Anfangen -- JensKapitza
** Mich w&uuml;rden in dem Zusammenhang [LTSP|http://www.ltsp.org/] und [FreeNX|http://www.skolelinux.org/de/documentation/howtos/freenx] vom Skolelinux-Projekt interessieren. (MarkusMonderkamp)

* EmbeddedLinux
** Ist das Thema noch aktuell und von (allgemeinem) Interesse? Ich fände Linux auf alten PDAs, die man sicher für kleines Geld bekommen kann sehr spannend.

[{Tag LUG Projekte Diskussion}]