Server Umzug

Die Website von Galactic Developments ist auf einen neuen Server umgezogen. Deshalb diesmal Techno Babble in eigener Sache.

Bisher war die Galactic Developments Website ein Apache Virtual Server auf meinem alten Hetzner Rootserver. Den hatte ich vor 6 Jahren bei einer keine-Setupgebühr-Aktion gebucht (und dann 3 Monate lang nicht installiert, was die keine-Setupgebühr-Aktion für mich ad-absurdum geführt hat, für Hetzner nicht). Inzwischen ist das Betriebssystem (Debian Sarge) aber schon aus den Security-Fixes raus gelaufen.

(Ich finde ja Sicherheitsaktualisierungen für nur 3 Jahre etwas kurz. Sollten sich mal ein Beispiel an Microsoft nehmen. Ich sage nur Windows XP. Naja, ist ja Open Source. Wenn es einem nicht gefällt, dann einfach nicht benutzen oder selbst fixen, wie man so schön sagt, jedenfalls nicht meckern.)

Die Rechner der Rabatt-Aktion waren damals etwas schwach auf der Brust. Das stört nicht, wenn man nicht viel Traffic hat, aber heutzutage will man virtualisieren und mehrere Server gleichzeitig laufen lassen. Dafür ist ein ganzes GB RAM nicht genug. Der neue Server ist wieder bei Hetzner, hat aber 2 TB Platte, 32 GB RAM, 8 CPUs incl. Hyperthreading. Das sollte reichen für ein paar virtuelle.

Ich kann Debian, also weiter Debian-stable, d.h. Jessie 8.2.

Zum Virtualisieren kvm und libvirt drauf. Ein 2 GB Image für das Guest-Template erstellen mit einer Debian-minimal Installation ohne alles außer sshd. Die VMs sind nur über das interne "default" Netzwerk zu erreichen. Alle VMs bekommen statische IP Adressen vom internen DHCP.

Ein VM als Reverse-Proxy, der HTTP-Requests an verschiedene virtuelle Maschinen weiterleitet. Dafür eine iptables-Konfiguration per qemu-Hook, die immer dann die 2 iptables-Regeln setzt/löscht, wenn die VM startet/stoppt. Auf dem Proxy ein nginx, der alle Anfragen für www.galactic-developments.de an die Galactic Developments VM weiterleitet.

Der Galactic Developments Server bekommt eine eigene VM. Hier mit Apache, weil ich Apache schon kann und nicht zu viele Konfiguration ändern muss, dachte ich. Tatsächlich haben sich die Apache Entwickler ein neues Sicherheitskonzept einfallen lassen und erst mal geht gar nichts, bis ich herausfinde, dass man einen neuen Befehl (Require) braucht. Zusätzlich zum Galactic Developments Apache virtual Server gibt es noch einen CatchAll virtual Server, der Adressen wie galactic-developments.de (ohne www.) und *.galactic-developments.com auf den Hauptserver umleitet (401/permanent).

Dateien und Daten der Galactic Developments Website sind in Subversion. Das bleibt erstmal so bis sich die Community mehr beteiligt. Dann will ich git nicht im Wege stehen. Bisher waren SVN Server und Website auf dem gleichen Rechner. Ein Subversion post-commit Hook hat automatisch die Website svn update'd. Poor man's Continuous Delivery. Das geht jetzt nicht mehr, weil es verschiedene Rechner sind und später - wenn der SVN Server auch umgezogen ist - gleicher Rechner, aber getrente VMs. Deshalb muss der post-commit Hook jetzt das Deployment anders triggern. Ich stehe auf Trigger per HTTP-Request. In diesem Fall: ein Einzeiler-PHP in der Galactic Developments Website (Name lang und geheim, Security by Obscurity), das ein lokales Shellscript startet, das wiederum "svn update" macht. Drei Einzeiler hintereinander. Man muss noch die Benutzer-Grenze überwinden vom wwwdata-User des Apache zum Eigentümer des Repositories. Deshalb wird das Shellscript mit sudo ausgeführt. Dafür eine Zeile in /etc/sudoers. Bei jedem svn commit ruft der post-commit Hook das update PHP-Script in der Zielwebsite per wget (-O - nicht vergessen) auf.

Dann noch DNS für www.galactic-developments.de umbiegen von rama.wolfspelz.de auf fred.wolfspelz.de und Galactic Developments ist umgezogen.

Das hört sich alles locker flockig an, hat mich aber mehrere Tage gekostet. Es gibt fast keine Anleitungen für libvirt/kvm OHNE lokales Display und ohne VNC. Auch virt-manager usw. alles nett gemeint, aber ich will kein Desktop auf meinem Server nur zum Installieren. (Wer bis hier gelesen bekommt von mir ein nagelneues Notebook. Bitte melden bei galdev-admin@heinerwolf.de). Genauso das Netzwerk. Entweder es wird nicht erwähnt, was blöd ist, wenn man die VM vom Netzwerk installieren will oder es wird bridge-Networking vorgeschlagen, was bei mir einfach nicht wollte. Dabei geht das "default" Netzwerk super. Man muss es nur anschalten. Das könnte mal irgendwo stehen. Ein qemu-Hook statt bridge-Netz sehe ich nicht als Hack an, im Gegenteil.

PS: rama.wolfspelz.de war keine Frühstücksmargerine, sondern ein 50 km langes Alien-Raumschiff.

2491 Multitasking Bewusstsein als Genmodifikation

Eine neue Genmodifikation namens Ikenga erweitert das menschliche Bewusstsein. Menschen können mit Ikenga mehrere parallele Gedankengänge gleichzeitig verfolgen. Man kann sich auf mehr als eine Aufgabe konzentrieren, z.B. ein Gespräch führen und gleichzeitig ein Buch lesen. Der erreichbare Parallelitätsgrad ist von Mensch zu Mensch verschieden. Bei machen sind bis zu 6 parallele Gedankengänge möglich. Die meisten Menschen mit Ikenga können 3 Aufgaben gleichzeitig lösen.

Ikenga ermöglicht echtes Multitasking. Dafür werden einige Bereiche des Gehirns durch die Genmodifikationen mehrfach ausgebildet. Das Spektrum der parallelen Fähigkeiten ist nicht vollständig variabel. Bei der Implementierung wählen Eltern, ob das Kind mehrere mathematische, planerische oder emotionale Prozesse ausführen soll. Kombinationen sind möglich. Typisch ist eine Spezialisierung für eine lernende und 2 planerische Aufgaben. Funktionen, die von der Spezifikation der parallelen Implementierung abweichen, sind trotzdem möglich, aber etwas weniger effizient. Unterbewusste Prozesse laufen weiterhin ab. Ikenga schafft auch Verbindungen zwischen dem parallelisierten Neocortex und der unterbewussten Ebene. Alle parallelisierten Prozesse profitieren von Intuition und Assoziation.

Ikenga hat eine lange Entwicklung hinter sich. Erste Anfänge gehen ins 21. Jahrhundert zurück. Praktische Versuche gab es schon im 22. Jahrhundert. Die Fähigkeit war aber sehr lange nicht nebenwirkungsfrei. Es gab fast immer begative Begleiterscheinungen von Persönlichkeitsveränderung bis zu geistiger Instabilität. Echtes Multitasking ohne messbare Ausfälle gibt es erst seit 100 Jahren. Trotzdem war der praktische Nutzen anfangs noch eingeschränkt, weil die Parallelisierung der Verbindung zu anderen Gehirnbereichen unvollständig war. Außerdem gab es vor Ikenga immer einen primären und weitere sekundäre Gedanken. Auch wenn diese echt parallel liefen, waren sie nicht gleichberechtigt. Ikenga ist so ausgereift, dass Intuition, Gedächtnis, Sensorik, Motorik und viele andere Funktionen gleichberechtigt mit den parallelen Gedanken interagieren. Bei Ikenga verzichtet man erstmals auf den originalen, unmodifizierten Primärthread.

Die Entwicklung war besonders schwierig, weil Multitasking natürlich mit diversen anderen Genmodifikationen am Markt kompatibel sein muss. Man will schließlich nicht auf Assoziationsbooster, Lernoptimierung, schnelle Reifung, Schlafreduktion und vieles andere verzichten, was im 25. Jahrhundert zum Alltag gehört.

Multitaskingfähigkeiten wurden zwar auch vorher für Spezialanwendungen implementiert, aber die Alltagstauglichkeit kommt erst mit der Ikenga-Generation von Multitasking-Genmods. Ikenga kommt zwar als erstes voll ausgereiftes Multitasking-Produkt auf den Markt, aber an vielen Stellen wird in die gleiche Richtung geforscht. Innerhalb weniger Jahre folgen viele vergleichbare Entwicklungen.

Ikenga wird entwickelt von Mmelite Ewu Labs und vermarktet von Descartes Jiyin. Am Anfang wird Ikenga nur von lizensierten Gensplicern implementiert. 10 Jahre später ist es aber überall zu haben, wie andere vergleichbare Produkte. Man vermutet, dass die Hälfte aller Multitasking-Genmods von Ikenga abgeleitet ist, entweder als lizensiertes Whitelabel-Produkt oder als Raubkopie.

http://jmp1.de/h/2491

#Genetik #Multitasking #Gehirn #Intelligenz