Dies ist eine AlteSeite aus unserem UseModWiki bei Sourceforge.
Bitte überarbeite die Seite, passe die Formatierung für das JSPWiki an
und entferne diesen Text.
Vielen Dank!
{{{
= Organisation der LUG
=
Wir haben bis auf Weiteres festgelegt, dass wir uns am ersten und
dritten Montag öffentlich im Limericks treffen.
Erster Montag: Klönen und Biertrinken
Dritter Montag: Themen-Abend
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. ->
[http://www.lug-kr.de/cgi-bin/lugwiki.pl?action=browse&diff=1&id=LugAnregungen&diffrevision=8&revision=7
Testaufruf zu linuxproject.de] von ThomasBayen
: ambivalenter Einschub von MarkusMonderkamp:<br>
: '''Haftungsaspekt''':<br>Es gibt genug Zeitgenossen, die
ihre Einnahmen aus Abmahnungen gesetzeswidriger Webspace-Inhalte
finanzieren.<br>Fehlendes Impressum, urheberrechtliche
Begriffe, One-Click-Techniken ... und schon darf der Provider
haften.<br>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:<br>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, <b>Thomas' Idee zu bejubeln</b>:
: 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 á la
[http://peoples.mandriva.com/~ayo/distant_file/dessins/gallery/stand_debian.png
www.3labs.com] (Debian-Logo von
<nowiki>FrozenBubble</nowiki>-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
:: [http://lug-kr.linuxproject.de/cgi-bin/twiki/bin/view TWiki] 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ülle diese Seite noch mehr und fasse den
[http://www.wikimatrix.org/compare/JSPWiki+TWiki+UseMod
Wiki-Vergleich] zwischen '''JSP-, T-''' und '''Usemodwiki'''
zusammen.
==== [http://www.usemod.com/cgi-bin/wiki.pl Usemod-Wiki] ====
Das hiesige Usemodwiki erscheint mir mit besserem Antwortverhalten
zur Zeit für die jetzigen LUG-Beiträge als
angemessen, d.h. es entfaltet IMHO (tm) seine
größ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)
==== [http://jspwiki.org/ JSP-Wiki] ====
* JSP-WIKI besticht durch seine vielseitigen Datenbankplugins:
<br><nowiki>MySQL, Pg, Oracle, SQLite, BDB per
PlugIn.</nowiki>
: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. <nowiki>RecentChanges, PageIndex,
Inhaltsverzeichnisse</nowiki> und vieles mehr sind im JSPWiki
als Plugins realisiert. Es gibt aber auch Blog, Kalender etc.
'''''Jedoch'''''
* Keine Festlegung von "<nowiki>MinorChanges</nowiki>"
bei der Veröffentlichung
* keine freien Links
: Was sind "freie Links"? --PeterHormanns
:: ...ein Zitat aus der o.g.
[http://www.wikimatrix.org/compare/JSPWiki+TWiki+UseMod
Wiki-Matrix]
* Textsuche nur ü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 übel, jetzt habe ich Sand unter den
Fingernägeln;-) -- MarkusMonderkamp
:: Ungewohnt: Links werden erst in der Reihenfolge
''Linknamen|URL'' eingegeben.
==== [http://twiki.org TWiki] ====
Im Unterschied zu den bisher genannten Wikis sind
* RCS fest eingebaut, d.h. Seiten-Versionen sind schnell mit RCS
verwaltet
* eingebaute Mail-Encryption
* Änderungs-Zusammenfassung per Mail
* Konfliktauflösung bei gleichzeitigem Schreibzugriff
* In der aktuellen Version 4.0 unterstützt ein
[http://internetwoordenboek.kennisnet.nl/look2/show.asp?i=1024&qu=WYSIWYD
WYSIWYD]-Editor den Seitenautor
* PDF- und XML-Export per Plugin
* Textsuche über den kompletten Inhalt
* Serienmässige Plugins: Calender, Spreadsheet
(Tabellenkalkulation), Diashow- und Tabelleneditor
* brauchbare Geschwindigkeit, '''wenn''' der Werbserver
mitspielt<br>(Momentan -24.08.2006- kaum mit
[http://lug-kr.sourceforge.net/cgi-bin/twiki/bin/view TWiki auf
Sourceforge]!)
----
== weitere
<nowiki>(Themen-/Projekt-)</nowiki>Anregungen ==
* XEN
* UML - hier: UserModeLinux
: Apropos:
[http://www.archive.org/download/SeanKellyGettingYourFeetWetwithPlone/wetfeet.mov
Irre] finde ich die automatisierte Produkterstellung von
[http://plone.org/documentation/tutorial/archgenxml-getting-started
ArchGenXML] aus XMI-Dateien von [http://argouml.tigris.org/
Argouml] für [http://plone.org/
Python].<br>'''Update'''
Ähnlich:[http://search.cpan.org/author/KSTEPHENS/UMMF-1.02/lib/UMMF.pm
Perl-Konverter] 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ürden in dem Zusammenhang [http://www.ltsp.org/
LTSP] und [http://www.skolelinux.org/de/documentation/howtos/freenx
FreeNX] vom Skolelinux-Projekt interessieren. (MarkusMonderkamp)
* EmbeddedLinux
}}}