Nachtrag zum TS3 & MySQL 5.1 “Fix”
Hallo,
ich hatte ja letztens hier erklärt wie ich meine Problem mit TS3 und MySQL 5.1 gelöst habe. Dabei ist mir jetzt ein Problem aufgefallen das zu einigen Problemen geführt hat: /usr/local/bin steht in PATH vor /usr/bin, was im Grunde heißt das bei Executables die in beiden Verzeichnissen liegen die aus /usr/local/bin genommen wird. Das führt mit dem beschriebenen Fix dazu das man der "alte", selbst gebaute mysql-Client verwendet wird statt dem vom portage gebauten.
Das ist aber relativ leicht zu beheben: rm /usr/local/bin/mysql
Da nach einfach die shell neu starten und schon hat man wieder den aktuellen Client.
Teamspeak 3 und MySQL >= 5.1 unter Gentoo
Hallo zusammen!
Ich wollte grade mal auf dem neuen Server hier wieder Teamspeak3 installieren und während der emerge so läuft fällt es mir wieder ein: der TS3 Server braucht die libmysqlclient.so.15 - also die MySQL Client Library zum Server v5.0. Aktuell ist aber v5.1 was einige Verbesserungen mitbringt auf die ich nicht - nur wegen TS3 - verzichten möchte. Da ich das Problem schon beim alten Server hatte, hatte ich aber zum Glück eine Lösung parat. Nämlich die, welche einem überall wenn man nach dem Problem fragt genannt wird: "Kopier einfach die alte Library dazu, passt scho!"
Nun finde ich es nicht so wirklich cool einfach irgendwelche Librarys von irgendwo her zu kopieren und die in mein System zu werfen. Alle "Anleitungen" waren ausserdem nur für CentOS oder Ubuntu oder so. Hier also mal eine für Gentoo:
Momentan sind -zumindest bei mir- alle Versionen vom teamspeak-server-bin noch hard masked. Also erstmal nen passenden Eintrag in die /etc/portage/package.unmask werfen:
echo ">=media-sound/teamspeak-server-bin-3.0.0_rc1" >> /etc/portage/package.unmask
Da nach kann man es ganz normal von portage installieren lassen:
emerge -a teamspeak-server-bin
Dann kann man eigentlich sofort die mysql Sources fetchen:
emerge -f =dev-db/mysql-5.0.91
Nun legt man sich ein Verzeichnis an und entpackt die sources:
mkdir oldmysql mv /usr/portage/distfiles/mysql-5.0.91.tar.gz ./oldmysql/ cd oldmysql tar -xf mysql-5.0.91.tar.gz cd mysql-5.0.91
Jetzt wirds etwas tricky aber nicht wirklich schwierig. Wir müssen dem configure script mitteilen das wir gerne nur die client library hätten. Mittels ./configure --help kann man sich die verfügbaren Optionen anzeigen lassen. Das prefix liegt - per default - auf /usr/local was imho der richtige Ort für von-Hand installierten Libs ist. Also müssen wir nur noch --without-server anhängen. Es hat sich aber gezeigt das es durchaus sinnvoll ist auch noch --with-unix-socket-path=/var/run/mysqld/mysqld.sock mit zu geben da der Client sonst den Socket nicht findet. Wenn jemand weiß wie man das los werden kann möge er es bitte in die Kommentare posten.
Wir bauen uns also unsere Client Library wie folgt:
./configure --without-server --with-unix-socket-path=/var/run/mysqld/mysqld.sock make make install
Das war es im Grunde auch schon, wir sollten nur noch das init-Script fixen damit TS3 die Bibliotheken findet.
Einfach die /etc/init.d/teamspeak3-server aufmachen. Dort drin ist irgendwo eine Zeile wie diese:
export LD_LIBRARY_PATH="/opt/teamspeak3-server:$LD_LIBRARY_PATH"
Bei mir wars Zeile 15. Hier erweitert ihr einfach LD_LIBRARY_PATH durch den Pfad zu den neuen TS3 libs:
export LD_LIBRARY_PATH="/usr/local/lib/mysql/:/opt/teamspeak3-server:$LD_LIBRARY_PATH"
Jetzt müsst ihr eigentlich nur noch eure Configs anpassen. Wie das geht findet ihr etwa hier: http://www.gentooforum.de/artikel/18660/teamspeak-3-server-mit-mysql.html
Ich kann das allerdings auch noch mal hier genauer erwähnen falls das gewünscht ist.
Ich hoffe das dieser Beitrag dem einen oder anderem Serveradmin ein wenig den Tag erleichtert. Vielleicht schaffen es die TS3-Devs ja irgendwann mal MySQL 5.1 zu unterstützen, aber Hoffnung habe ich da wenig.
Details: OVER 9000!!
Momentan verbreitet sich dieses Video von Euclideon wie ein Flächenbrand und das Thema hat mich auf Anhieb gefesselt. Zu behaupten ich hätte von 3D-Grafik wenig Ahnung wäre noch geschmeichelt, daher beruht dieser Blogpost nicht ausschließlich auf meinem eigenen Wissen sondern vor allem auf dem, was ich mir in den letzten Tagen so angelesen habe. Als Quellen dienten mir dabei vor allem die Blogs einiger Leute die sich damit deutlich besser auskennen als ich und die sich teilweise schon länger mit solchen Techniken beschäftigen. Ausserdem auch die Websites einiger großen deutschen Spielemagazine. Ich werde am Ende dieses Posts (möglichst) alle Quellen verlinken und hoffe dabei keine zu vergessen. Im Grunde ist das folgende also nur eine Zusammenfassung von verstreutem Wissen mit meinen bescheidenen Erfahrungen.
Diese Firma behauptet diese Demo wäre mit ihrer neuen Technologie namens "Unlimited Detail" erstellt worden. Angeblich sind alle gezeigen Objekte keine Polygon-Modelle sondern liegen als Punktwolke vor. Das es keine Polymodels sind glaubt ihnen so ziemlich jeder, das wäre ja auch zu einfach. Markus 'Notch' Persson wirft den Australieren hingegen vor es seien keine Point-Clouds sondern "nur" Voxel. Da wären wir als schon beim ersten Problem:
Was sind Voxel, was sind Point-Clouds und was ist der Unterschied?
Fangen wir mal mit den normalen, langweiligen, Polygonmodelen an. So ein Viech besteht aus ein paar (bzw vielen) Punkten die mit graden Linien verbunden sind. Diese wiederrum ergeben Flächen, meines Wissens nach Dreicke. Diese Punkte nennt man dann Vertex, die Flächen "Polygon". Über dieses Gebilde stölpt man dann Texturen und Shader die für Farbe etc. sorgen und dann wird das ganze durch mehr oder weniger aufwendige Verfahren gerastert und man erhält ein 2D Bild von diesem 3D Model. Diese Technik hat den Vorteil das die benötigte Datenmenge überschaubar ist. Zusätzlich sind Animationen denkbar einfach da man nur hier und da ein paar Punkte verschieben muss. Der Nachteil ist der begrenzte Detailgrad. Umso mehr Details man darstellen will desto mehr Polys braucht man. Doch das kostet natürlich Performance.
Anders hingegen sieht es bei den Voxeln aus. Das Ganze muss man sich dann eher wie eine Legowelt vorstellen. Jeder Voxel ist ein Legostein der eine bestimmte Position und eine Farbe hat. Dadurch muss man dann keine Texturen mehr speichern aber verbraucht umso mehr Platz für die ganzen Lego..ähh Voxel. Man kann sich leicht vorstellen das zu jedem Punkt ja Farbe usw. gespeichert werden müssen. Die Position eines Voxels ergibt sich (afaik) aus seinem Speicherort. Die Firma ID (Wolfenstein, Quake, Doom, Rage) setzt bei ihrer kommenden id-Tech-6-Engine auf eine Technik namens Sparse-Octree (SOT) bei der jedem Voxel acht Subvoxel zugeteilt werden. Diesem werden wiederrum jeweils acht Subvoxel zugeteilt usw. Insgesamt geht ID laut einem PCGames Bericht von 2009 davon aus 52 Byte pro Voxel zu brauchen. Der Vorteil dieser Technologie liegt klar beim gigantischen Detailreichtum der damit möglich ist. Außerdem muss man nicht mehr irgendwelche 3D Modelle rastern sondern kann, sogar sehr gut parallelisierbar, mittels Raycasting raus finden welcher Voxel für welchen Pixel auf dem Bildschirm interessant ist und kann damit sehr schnell beliebige Szenen Rendern. Raycasting bedeutet das man einen Strahl von jedem Punkt des Bildschirm aussendet und einfach mal guckt welchen Voxel er trifft. Dieser wird dann genommen um die Farbe des jeweiligen Pixels zu bestimmen. Mittels SOT wird dann dafür gesorgt das nur dort ein Hoher Detailgrad existiert wo er auch gesehen wird, die Subvoxel von Voxeln die nicht getroffen werde müssen somit nicht in betracht gezogen werden was natürlich die Suche nach Treffern beschleunigt. Das ganze hat noch ein paar andere Vorteile die hier aber jetzt nicht Thema sein sollen. Nachteile von Voxeln sind einerseits natürlich die Datenmengen die bei hohem Detailgrad notwendig sind. Schwieriger stell ich mir aber Animationen mit Voxeln vor, da ja die Koordinaten eines Voxels durch seine Position in der Datenmenge bestimmt wird. Eine Animation würde also eine Verschiebung innerhalb der Datenmenge erfordern was natürlich irrsinnig viel Zeit kostet. Einige Leute beschäftigen sich wohl mit Animationen von Voxelobjekten und das scheint vorran zu gehen wenn man seinen Octree sinnvoll aufbaut. Ich werde versuchen da noch etwas mehr Infos zu bekommen und eventuelle diesen Post zu updaten.
Der Unterscheid zwischen Voxeln und Punktwolken liegt jetzt, wenn ich das richtig Verstanden habe, darin, dass bei Punktwolken die Koordinaten des Punktes mit abgespeichert werden. Das ermöglicht zwar eine relative einfache Änderung der Position von Punkten, verbraucht aber noch viel mehr Kapazität.
Was sehen wir denn jetzt in dem Video?
Laut Persson ist es wohl nicht ganz trivial Voxelobjekte zu rotieren, bei Point Clouds wäre das kein Problem da man hier mit ein wenige Mathematik relativ zügig alle Koordinaten umrechnen kann. Sollte das zutreffen könnte es erklären warum in sämtlichen Bildern und Demos dieser Unlimited Detail Leute die Objekte immer gleich ausgerichtet sind. Sieht in der Tat etwas komisch aus.
Weiterhin fällt auf das man ständig die selben Objekte sieht. Diese Säulen aus denen die Insel besteht, die Bäume, Steine etc. Wenn man ein bisschen drauf achtet sieht das ganze, vor allem vom weiten, doch sehr eintönig aus. Damit würde sich natürlich die erforderliche Datenmenge erheblich reduzieren denn wenn ich das selbe Objekt 200 mal darstelle muss ich es trotzdem nur einmal speichern. Diese wurde ebenso von Notch wie auch von @miguelcepero bemerkt, der sich in seinem Blog mit dem generieren von Terrain und Voxeln auseinandersetzt. Die Chancen stehen also gut das wir in dieser Demo keine Punktwolken sehen sondern eher Voxel was ich aber absolut nicht mit Sicherheit sagen kann.
Fest steht aber das beide Techniken enorme Datenmengen verschlucken wenn es abwechslungsreich sein soll. Keiner will in einem Wald hunderte male am selben Baum vorbeilaufen.
Ich stell mir ausserdem die dynamische Beleuchtung von Voxeln schwierig vor da dann für jeden dynamische Lichtquelle wieder extra raycasts gestartet werden müssen was die Performance wieder bremsen wird.
Eine mögliche Lösung für das Animationsproblem wäre laut id die statischen Teile einer Welt mit Voxeln zu bauen und alles was animiert werden muss wird wieder aus Polys gebaut. Dadurch das man aber nun Polys nur noch für einen Teil der Welt braucht werden Kapazitäten frei die man in mehr Details stecken kann. So wie ich das verstanden hab wollen die dann erst die Umgebung aus Voxeln berechnen (raycasting) und auf das Bild dann die Animierten Polygonmodele rastern. Das wirft natürlich neue Fragen nach Schattenwurf usw. auf die ich bisher noch nicht beantworten kann.
Für eine Zusammenfassung ist das jetzt schon echt lang geworden und ich hoffe ich konnte dem ein oder anderem weiterhelfen. Ich würde mich freuen wenn wir in naher Zukunft Detailgrade in Spielen finden die denen in dieser Demo nahe kommen aber ich befürchte das bis dahin noch das ein oder andere Jahr vergeht. Ich bin mal gespannt was die nächsten Wochen und Monate bringen, hoffe das ich total unrecht habe und halte es da wie Notch: "Being wrong is awesome, that’s how you learn."
Hier also mal eine (mit Sicherheit unvollständige) Liste meiner Quellen:
- http://notch.tumblr.com/post/8386977075/its-a-scam
- http://notch.tumblr.com/post/8423008802/but-notch-its-not-a-scam
- http://procworld.blogspot.com/2011/08/unlimited-detail.html
- http://www.pcgameshardware.de/aid,681315/Voxel-Rendering-am-Beispiel-id-Tech-6-erlaeutert/Technologie/Wissen/
- http://unlimiteddetailtechnology.com/home.html
- http://www.gamestar.de/hardware/specials/1956284/neue_id_software_engine_mit_voxel_grafik.html
Vor allem bei Notch und Procworld gibts nen paar nette Links zu wirklich coolen Demos von denen allerdings keine son Aufstand macht wie Euclideon.
Ogred3D Tutorial #01
Um endlich mal was aufs Blatt ins Web zu bekommen schreib ich jetzt erstmal eine kleine Einführung wie Ogre grob funktioniert. Da ich mich wie schon im letzten Post beschrieben, auch grade erst in Ogre einarbeite kann bzw. dieser Überblick natürlich noch recht unvollständig sein. Trotzdem finde ich es enorm praktisch erstmal zu wissen mit was man sich hinterher im Programm auseinander setzen muss bevor man überhaupt anfängt zu Programmieren.
Ein Elementarer Bestandteil von 3D Grafiken, Spielen, Simulationen etc. sind natürlich die 3D Modelle, ohne macht das Ganze recht wenig Freude. Also werden wir uns erstmal ansehn wie Ogre diese handhabt.
Der zentrale Punkt des Ogre3D Render Systems ist wohl der SceneManager. Dieses Objekt hilft uns beim Erzeugen von Objekten (Lichtquellen, 3D Objekten, ...) und verwaltet sie. Eine wichtige Gruppe von Objekten die dieser Manager erstellt sind die sog. Entities was im Grunde alles ist das als 3D Modell dargestellt wird. Lichtquellen und Kameras sind also keine Entites. Jede Entität in Ogre hat einen festen Namen und wird, wie schon gesagt, vom SceneManager erstellt. Um diese Entities nun auch dem gierigen Gamer zeigen zu können muss man sie in den sog. Render-Tree "einhängen". Das ist ein recht simples aber äusserst flexibles Prinzip. Es gibt eine RootSceneNode, also einen Wurzelknoten an die die gesamte Szene angehängt wird. An diesen RootSceneNode können beliebig viele weitere SceneNodes angehängt werden, an den wieder beliebig viele weitere angehängt werden können etc. Ein Baum eben. Die SceneNodes selber haben allerdings keinerlei "Optik", sind also selbst nichts sichtbares. Sie enthalten die Informationen über die Position, Skalierung und Rotation von Entities und anderen Objekten. Die Angaben sind dabei stets relativ zum übergeordneten Knoten. Wenn ich also ein Charakter im Spiel habe und diesem einen Hut aufsetzten möchte hänge ich den Charakter als Entity an einen SceneNode den ich in den RootSceneNode hänge. Nun erzeuge ich mir einen SceneNode, hänge ihn als Kind an den SceneNode des Charakters und gebe ihm das Hutmodell sowie die Koordinaten wo er sich, relativ zum Nullpunkt des Charakters befinden soll. Bewegt sich nun der Charakter, bewegt der Hut sich mit. Klingt komisch, ist aber so!
SceneNodes können also eine beliebige Anzahl anderer SceneNodes und anderer Objekte wie Entities, Lichtquellen oder Partikeln enthalten. Nun haben wir also unsere Objekte irgendwo in unserem imaginären Raum platziert. Nun müssen wir das ganze nur noch in dieses kleine Fenster zwengen. Im Grunde müssen wir dazu Ogre nur sagen was er in welchen Bereich von welchem Fenster rendern soll. Grundlegend dafür sind erstmal natürlich Kameras die bestimmen was sichtbar ist. Eine Camera kann man wie z.B. Entities auch einfach ein SceneNode hängen und mit diesem dann Ausrichten. Dazu erhält eine Kamera weitere Einstellungen wie das Seitenverhältnis oder die Distanzen ab wann Objekte ein- bzw. ausgeblendet werden sollen. Dazu kommen wir aber wenns dann endlich soweit ist. Nun lassen wir uns noch von Ogre ein Fenster erstellen und erzeugen mit diesem einen Viewport in dem alles angezeigt wird was die Kamera "filmt". In den meisten fällen wird man als Viewport das gesamte Fenster nutzten aber es gibt auch etliche Fälle wo man den Fensterbereich aufteilen will. Denkt nur mal an Split-Screen Szenen oder dieses coole "Punkt beobachten"-Feature der frühen Siedler-Teile. Oder die Minimap von SupremeCommander...
So, grob gesagt ist das alles was man für das erste sichtbare Ergebnis so braucht. Damit man damit auch was Sinnvolles anfangen kann ist es natürlich noch ganz praktisch wenn man die Benutzereingaben verarbeiten kann oder allgemein etwas mehr Interaktivität in die schöne heile Scene bringt. Das soll aber erst später Thema hier werden. Im nächsten Teil werden wir (hoffentlich) endlich mal was Programmieren. Ziel wird es dann sein die hier beschriebenen Teile möglichst flexibel zusammen zu kleben so das am Ende ein kleines Programm rauskommt das uns eine noch unserer Vorstellung gestaltete Szene rendert. Sicherlich nichts mit dem man sich bei Blizzard bewerben sollte, aber immerhin ein wichtiger Anfang.
Bis denn!
Ogre3D Tutorial #00
Hallo zusammen,
ich fange momentan an mich ein wenig mit Ogre3d zu beschäftigen. Das bringt für mich einige interessante Dinge zusammen die ich sowieso mal machen wollte. Grafikprogrammierung (und dann noch 3D!) in C++! Da kommen allerlei interessante Sachen zusammen und das Ergebnis ist hinterher hoffentlich Eindrucksvoller und damit auch motivierender als ein schnödes QT Programm.
Ich werde also wohl die bald anfangende Vorlesungsfreie Zeit nutzten und mich mit den Grundlagen von Ogre vertraut machen indem ich einige Tutorials durchacker und nen paar Kisten Code produziere.
Ich hielt es für ne coole Idee wenn ich immer möglichst parallel hier über meinen Fortschritt berichte und damit ein kleines eigenes Schritt-für-Schritt Tutorial aufziehe bei dem ich dann auch immer direkt auf die Probleme die ich hatte eingehen werde.
Ich habe noch keine genaue Idee was am Ende dabei rumkommen soll, eher einige mögliche Kandidaten. Am Anfang werde ich (oder wir?) also erstmal ein wenig mit Ogre rumspielen und dabei sowas wie ein loses Framework bauen mit dem man dann später arbeiten kann. Hierbei kann es aufgrund meiner geringen (lies: nicht vorhandenen) Erfahrung mit Ogre und allgemein Programmierung solcher Projekte natürlich immer dazu kommen das man zuvor programmiertes über den Haufen wirft weil es sich als unsinnig oder unnötig erwiesen hat. Das ist aber meiner Meinung nach nicht weiter schlimm, denn aus Fehlern lernt man und hinterher weiß man es halt dann besser.
Ich denke ich werde zu dem Tutorial ein git Repository aufsetzten und dort die einzelnen Etappen als Branches oder so hinterlegen, mal sehn.
Den ersten richtigen Artikel kann man denke ich Anfang bzw. Mitte nächster Woche erwarten, bis dahin bin ich hier noch ein wenig mit Mathe belastet, wir werden sehn.
Ich hoffe auf Anregungen, Kritik und sonstige Kommentare denn, solang alles konstruktiv bleibt, kann das nur nützen.
Achso, für die die schonmal anfangen wollen sich das ganze anzugucken gibt es ein Wiki mit massig Stoff zum lesen: www.ogre3d.org/tikiwiki/
Bis denn!
Quicktip: curl blabla.tar | tar -x
Man tut es ja quasi täglich, .tar.xyz Dateien runterladen und entpacken. Über die GUI nervt das natürlich weil man ja hinterher eh mit dem Terminal rein will, also habe ich es bis jetzt immer so gemacht das ich mir per wget das Archiv geholt und des dann mit tar -xf foo.tar enpackt habe. Aber dafür zwei Zeilen zu verschwenden und dann auch noch das Archiv da rumliegen zu haben ist doch etwas semioptimal. Schön wäre es wenn ich das Archiv runterladen und sofort entpacken könnte.
Noch schöner das tar problemlos stdin als Input nehmen kann, einfach den -f Parameter weglassen. Wenn man das ganze jetzt noch mit curl kombiniert das per default auch alles was es bekommt in den stdout spammt hat man doch schon einen wunderschönen Einzeiler der endlich alles tut was man will: Runterlade & entpacken. Und das alles noch im Stream, kein lästiges zwischenspeichern auf der Platte!
Das Ganze sähe in etwa so aus: curl http://pfad/zum/tarball | tar -x eventuell natürlich mit beliebigen weiteren tar Parametern wie -j für bz2 Archive oder -z für gzip.
Da ich aber selbst dafür zu faul bin habe ich mir gleich noch nen kleines Shellscript gehackt was das ganze nochmal vereinfacht.
#!/bin/sh CURL=`which curl` TAR=`which tar` path=$1 shift params=$* $CURL $path | $TAR -x $params
Das ganze gibt es zu allem Überfluss auch noch zum selberforken etc. auf GitHub: https://gist.github.com/986609
Wenn mir jemand sagt wie ich in einem alias auf die unterschiedlichen Paramter zugreifen kann wäre das natürlich noch schöner, aber das Shellscript tut seinen Dienst.
FUSSL
Im Rahmen einer fixen Idee von mir bastel ich momentan in Zeiten großer Langeweile an einer kleinen eigenen Skriptsprache. Diese ist keineswegs auf Performance oder ähnliches ausgelegt sondern soll vor allem einfach sein. Das Ziel ist hinterher eine Engine zu haben die ein FUSSL-Skript in einzelne Instruktionen zuerlegt und diese dann absolut deterministisch nach und nach ausführt. Die Ausführung ist von Außen beeinflussbar und der Zustand der Maschine jederzeit abzufragen. Dadurch soll eine Semi-Parallele Ausführung zweier Skripts ermöglicht werde die für die Gesamtidee notwendig ist. FUSSL steht übrigens für FU*king Slow Scripting Language. Zum aussehen der Sprache erstmal nur soviel: Ich orientiere mich an Sprachen wie JavaScript, Java und PHP und merge das was mir von allen gefällt irgendwie zusammen. Es wird also sehr Objekt orientiert. Allerdings soll auch ein prozeduraler Programmierstil funktionieren um es allen Einsteigern möglichst einfach zu machen die Sprache zu erlernen.
Wert lege ich - wie schon gesagt - besonders auf den Determinismus der Sprache. Wird ein Script zweimal mit den selben Rahmenbedingungen aufgerufen sollte es nach exakt der selben Anzahl von Instruktionen genau das selbe tun. Das heißt Methoden wie z.B. ein Math.random() entfallen ersatzlos. Auch das ist für die Gesamtidee notwendig über die ich vielleicht später noch blogge. Erstmal muss FUSSL laufen.
Gedacht habe ich mir das ganze dann so: Das FUSSL Skript wird zuerst interpretiert und in Instruktionen übersetzt. Jede Instruktion hat einen bestimmten Kontext der wieder rum in anderen Kontexten existiert. Des Weitern hat eine Instruktion eine simple Operation die innerhalb der Kontextes ausgeführt wird. Das ganze ist noch sehr Theoretisch, ich hoffe irgendwann einmal Zeit zu finden etwas in der Richtung zu bauen. Ein wenig der Syntax ist schon definiert, das Ganze ist noch weit davon entfernt so etwas wie eine Sprache zu sein. Ich rechne nicht damit noch in diesem Semester einen lauffähigen Compiler & Interpreter auf die Beine zu stellen.
Wenn ich die wieder an die Daten auf der nun ausgebaut hier liegenden HDD rankomme zeige ich hier vielleicht mal Auszüge aus der Syntax.
Ich gehe ganze bewusst total ohne Kenntnisse im Sprachdesign oder Compilerbau an die Sache heran. Ich will erstmal selbst Erfahrungen sammeln und auf die Schnauze fallen bevor ich mir irgendwelche schlauen Bücher kaufe.
Man kann sich natürlich Fragen warum ich dafür ne eigene Sprache basteln will wo es doch soviele fertige gibt. Nun erstmal ist so etwas wie LUA zu implementieren genauso aufwendig wie uncool, vor allem da bestehende Implementierungen wahrscheinlich nicht meine - recht speziellen - Anforderungen ( step by step execution) erfüllen. Ausserdem habe ich so die volle Kontrolle über die Sprache und kann sie an alle Bedürfnisse anpassen. Es hat - im Kontext der ominösen Gesamtidee - auch was mit Chancengleichheit zu tun. Auch wenn die Sprache von vielen anderen "erbt" so ist sie doch etwas eigen. JavaScript Profis haben also gegenüber Pythonhipsters keine gigantischen Vorteile weil sie jeden Trick kenne.n
Ausserdem: Welcher Coder wollte nicht schon immer die Sprache mit der er Arbeitet selbst gestalten und nach seinen Wünschen formen?
Als 3. Ausrede & Totschlagargument hilft wie immer: " Da lernt man auch was bei!"
professionelle Ignoranz
Vor etwa genau einer Woche (28.01.2011, so um 16:40) habe ich sechs Leute bzw. Firmen angeschrieben. Der Grund war, dass ich bei einer harmlosen Recherce per Google zu einen OpenSouce-Online-Belegungskalender über ihre offenen Backends gestolpert bin.
Kurz zur Erklärung für die, die es vielleicht nicht wissen. Ein Backend dient zur Verwaltung von Zeugs. Da stellt man halt die ganze Misere ein und so. Zugang dazu sollten also ausschließlich Leute haben die da auch dran rum fuckeln dürfen. Im Falle dieses Belegungskalenders also die Vermieter oder deren IT oder Firmen die dafür bezahlt werden aber in keinem dieser Fällt sollte ICH dazu Zugang haben. Hab ich aber, und jeder der einen Browser bedienen kann auch!
Spätestens jetzt sollte auch jedem RTL2 süchtigem Analogbürger auffallen das dort was schief läuft. Diesen Leute scheint das aber auch nach einer Woche nicht klar zu sein das sie damit nen Risiko eingehen.
Das ist zwar nicht unbedingt so schlimm wie ein offener Zugang zum Onlinebanking aber auch sowas kann unschön enden.
Kommen wir zu dem Punkt wo wir alle uns mal Fragen "WTF? Wie passiert sowas?". Nun, die Erklärung ist denke ich recht Simpel: Diese Software liefert genau gar nichts mit was als Zugangskontrolle taugt. Das steht sogar auf deren Webseite in der Doku. Da steht übrigens auch ungefährt wie es geht (SelfHTML - .htacces). Daraus folgt dann natürlich das man - Trommelwirbel - selber denken UND lesen muss. Oh shit! Sowas von eine 08/15 "Wir machen ihre Webseite fürn Zehner"-Klitsche zu erwarten ist natürlich vollkommen unverhältnismäßig.
Ich ignoriere jetzt mal dass es grob fahrlässig von den Kalender-Team ist die armen Leute da ins Messer laufen zu lassen. Ein Beispiel für eine .htaccess-Datei wäre ja schonmal ein Anfang. Darum gehts hier ja garnicht, sonst kommen mir gleich die Trollos und rufen "ist doch OpenSource, fix es selbst".
Kommen wir also zurück zu unsereren Vermietern die grade eine E-Mail bekommen haben das ihre Seite unsicher ist. Alternativ ists natürlich eine beliebig große Web-IT-Blafoo-Firma die für den Vermieter arbeitet. Ich gehe mal davon aus das die E-Mail angekommen ist da - auch wenn ich mir die anonyme Adresse fix bei nem Freemailer geklickt habe - kaum ein Spamfilter sie gefressen haben dürfte (kein Viagra drin!). Und selbst wenn sehe ich das nicht als Entschuldigung. Wenn ich mein Geld über irgend welche Webseiten verdiene, dann lese ich auch Spam. Könnte ja nen Kunde sein. Aber ich schweife schon wieder ab. Herr/Frau XY hat also unsere Mail bekommen. Nun gibt es ein paar Handlungsoptionen:
- Stundenlang in Panik rumrennen bis man eingeliefert wird
- wenn manns kann: fixen
- wenn nicht: jemand Fragen ders kann, der "Antworten" Button ist ja nicht weit
- Kurz mal lachen, dann weiter machen.
Ich denke jedem ist klar das 1. und 4. keine ernste Option sind also sollte man davon ausgehen das jeder Mensch dem etwas an seinem Geschäft liegt Option 2 oder 3 wählt.
Da ich keine Antwort bekommen habe muss ich davon Ausgehen das jeder Betroffene also entweder (a) selber in der Lage ist das zu Lösen oder Leute kennt (/bezahlt) die das für in tun, oder (b) es juckt ihn nicht.
Da mir das Ganze doch nicht aus dem Kopf ging habe ich also heute nochmal Onkle Google gefragt ob sich was geändert hat. Und? Röchtöööch: Nix ist passiert, alles noch offen. Warum, wieso, weshalb weiß ich nicht. Was soll man also tun? Ich hatte keine Lust nochmal Mails raus zu senden, ich wollte einfach noch einmal drauf Rumranten und wenns auch weiterhin keinen Juckt, dann geht mir das sonstwo vorbei.
Also, wenn ihr diese Software benutzt, checkt eure Installation und tut endlich was damit nicht jeder Troll drin rum hampeln kann. Notfalls fragt halt jemanden. Ist ja nicht so als wären alle netten Menschen die Ahnung von "diesem Internetz" dort draußen haben nicht zu erreichen.
Achso, ich hab wohl echt vergessen es zu erwähnen: Das System heißt "GuestCal", die passende Google Suche kann sich zwar jeder bauen aber auch hier klicken: "GuestCal Admin -demo"
nodejs installation und deren Probleme
Heute wollte ich bei mir mal nodejs aus dem Portage installieren. Build läuft wunderbar, allerdings startet node genausowenig wie d8, im Terminal werde ich mit einem "Getötet" abgespeist. Da ich allerdings die Tötung von unschuldigen node-Prozessen nicht dulden kann habe ich etwas nachgehakt.
Erster schritt: gdb node
Ergebnis:
Starting program: /usr/bin/node
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
Tatsache: Da schießt jemand auf meine Prozesse! Schweinerei, wer ist die Sau?
Gleich mal dmesg gefragt:
PAX: From AA.BB.CC.DD: execution attempt in:
PAX: terminating task: /usr/bin/node(node):3383, uid/euid: 0/0, PC: 4f923060, SP: 5ab3e5dc
PAX: bytes at PC: 55 9c 51 53 8b ec 9c 58 8b d0 35 00 00 20 00 50 9d 9c 58 33
PAX: bytes at SP-4:
(AA.BB.CC.DD = meine lokale ip)
Uiuiui..PaX greift ein. Wer/Was ist PaX? Google fragen.
Laut Wiki ist PaX "ein Sicherheitspatch für den Linux-Betriebssystemkern, der einen "Geringste-Rechte"-Schutz (engl. least privilege) für Speicherseiten implementiert.". Ahh ja. Schön und gut, darum hab ich hardened, trotzdem möchte ich node nutzten. Ich vertrau der Software einfach mal. Wie kann ich PaX als mitteilen das das schon klar geht? Wieder Onkel google gefragt und prompt fündig geworden. paxctl -m /usr/bin/node BÄM läuft! Danke Internet!