Archiv der Kategorie: this();

this() is blog-related;

is blog related stuff. hat irgendwie dann mit dem ding hier zu tun, also der domain hier.

english, mukke, this();

kurzweil.-.erster.akt

a friend organized a used kurzweil k2500s, without function, but with a kdfx-card for 50 bugs. even the spare parts would bring some dozen or hundrets on eGay, if the resurrection wont happen. s on the item was the sampler, it was included with some megabytes of ram, to capture sounds from outside the synth. it was a synth workstation with scsi, floppy  disc and some pre-burned rom to create sounds from 48 voices, with several dsp-chips. but actually, not more then noise came out of the headphones and mix-out, this time.

kurzweil from rear
kurzweil on the knees

that machine had a price tag of around 8000 $, when it was available in the stores, but fully equiped it could costs something like 19.995 USD.  after 18 years, since 1996, when it was build ( born ) the inflation and process of development smashed the price, but wait. on the web some people were able to pay something like 600 or 800 bugs, some with hard-disc even for 1500$ or was it €? but first, it needs to be opened and repaired. i heard, that the owner before tried to fix the death buttons with to much „flutschi“ – the expats name for contact spray. that evil stuff killed not even the buttons, the fluid went over the whole pcb and made irregular connections between the input knobs and switches. grant!

kurzweil cables crowded
crowded cables in the kurzweil

so we opened the case carefully, without knowing, where what was placed. some ribbon cables with different sizes, some black audio or what else matter wants to flow thru that line? we would find out later, that the star-scheme of the power distribution was grown by need, so it looked pretty unsorted and far away from engineering forces. but what, where was it from … california … so its all big block here or what? removing cables, writting some hints on the ports or the cable itself should help to re-build that thing, some days later – was the plan. also checking and repairing some of the buttons needs to be done then later on.

kurzweil cabling
inner cabling from the kurzweil

but digging deeper inside the top-half of the case, extracted more and more confused coupled cables between everything. and the best, the input terminal was so retared placed, that the whole thing was needed to dis-assebled, to get in touch with the human-interface. no one during the construction thought about buttons for cents, which gonna die after some thousend or millions of clicks. so, maintanance, patience … hopefully having enuff bread-crumbs droped on the way to the front pcb, and markers, … around. the parts inside had all in all a very cheap optic, the transistors on the output-board, were such 6 cent types, you wouldnt take for your weekly macgyver-course. the ribbon cable and the connectors where fixed with metal-safeties, but that non-flexible line is worse when you want to build something extraordinary.

kurzweil job wheel
k2500s job wheel

but wait, how to clean up that mess – was the first question, when i heard about that beast. unprepared, but motivated, we digged out the pcb after some hours and due the lack of material, we decided to shower everything with hot water and some minutes of dive, we hopefully cleaned the flutschi away of the board.  kurzweil droped a lot of energy inside the psycho-acustic-algorithms, that the discussions from the hife-scene from that time, was less then a farce. the dsp and the software running on them was the fat steak of the machine, the keyboard wasnt even layed on on roses, instead, simple mdf-wood was takes as spacer.

showered input panel
kurzweil in the shower

so, without some fuel of isoprophyl-alcohol, the cleanup would be a mess, but it wasnt that harsh. it took some 15 or 20 minutes, to shower both input boards twice and then the swom in that bath for half an hour or so. drying the boards, wouldnt be a thing, but the cables were somehow sensible to that fluid. so the boards went drying on the heating for 2 weeks or more, then i would be motivated again, to put everything together with the  want and need of harmonic synthesis from that famous piece of hardware.

so, we need to be patient and come back in some days, to take part 2 of that ride.

this();

serverAusschlachtung

doogie macht mir mut, die innereien vom dell-sever bei eGay reinzutun. ich brauch einiges an anlauf, da ich da kaum erfahrung und noch weniger nerv für habe, aber was solls. wenns denn geld einbringen sollte, ist es die paar stunden aufwand vielleicht wert.

also nehmen wir das ding gemeinsam auseinander, fotografieren es und schätzen grob, was wir als wunsch oder zielpreis uns vorstellen können. wir kommen auf sagenhafte 100 euro, die wir den teilen noch an wert zuschanzen, besser gesagt er. ich schätze nicht, dass für einen 8 oder 9 jahre alten bausatz noch jemand wirklich geld ausgeben will. sind doch alles füchse da bei den auktionen, die warten lieber ab und schießen es ein paar tage oder wochen später für n euro. was die dinger teilweise noch an geld im netz kosten und was sie mal gekostet haben, darf man garnicht so genau wissen – da wird einem nur üble.

perc scsi controller
perc scsi controller

also tippel ich ein wenig text in die artikelbeschreibung, lad die bilder hoch, die ich vorher noch ein wenig aufgehübscht habe und lass 10 tage zeit, für die rally. nichts passiert, kaum einer klickt auf die teile, beobachter finden sich kurz vor schluss, letztendlich gibts nur interessenten für die cpu und den raid-controller. jeweils für ein euro – hurra. tolle wurst.

cpu 64 bit
sockel 804 xeon

versprochen ist versprochen, ich pack die beiden dinger also ein, trödel ein bisschen mit dem versand und schick sie dann den neuen besitzern zu. glücklicherweise sind die anderen artikel, die automagisch verlängert wurden bzw neu eingestellt wurden, zu stornieren. noch so ein desaster fürn euro tu ich mir nicht an. schade, ists wohl nur noch elektronikschrott ….. zumindest kann ich die gehäuse und die netzteile gebrauchen, auch wenn 550 watt wohl mehr als genug sein dürften.

die anderen drei server brauch ich dann weder ausschlachten, noch die innereien verticken, die landen dann wohl direkt in der orangen tonne….

cloud, mukke, this();

ownCloud

für escii hab ich da grad owncloud installiert. eher durch zufall fiel mir das auf, als ich die verfügbaren softwarepakete bei seinem provider durchsah. also klick-klack gleich mal installiert.

owncloud ist php-basiert und läuft auf nur einer maschine und ist damit nicht wirklich „cloud“ … klingt aber trotzdem toll. es gibt eine community und eine professionell version. die kostenlose v5 hab ich dann gleich mal drauf getan und es lief auf anhieb.

flux ein paar benutzer eingerichtet, plugins nachgeladen und die ersten samples mit ihm geshared. ging alles relativ flott und auch via webdav auf mobilen geräten recht flüssig. bei vielen benutzern kommt jedoch einiges an traffic zusammen, wenn man seine arbeitsverzeichnisse/repositories darüber synchronisieren will. aber für den augenblick war das 1 gigabyte webspace ausgenutzt. also den uralten vertrag beim provider aktualisiert und schon 10 gb gehabt. damit kann er wohl erstmal ne weile leben und brauch keine one-click-hoster mehr, wenn er seine mukke ( tracks oder mixe ) mit anderen teilen möchte.

cloud, coding, this();

conceptProgressFiles

um die arbeiten an der cloud auch ein wenig dokumentiert zu haben, hab ich das single-page-design noch einmal verwendet und für die konzeptuelle beschreibung online gestellt.

das konzept, welches sehr grob und auch ein bisschen vage oder schwammig die vorstellungen von der private cloud skizziert, beschäftigt sich mit den verschieden modulen. diese sind vorläufig mit

  • 1. frontend
  • 2. backend/datamodell
  • 3. cluster
  • 4. mechanics
  • 5. cdn

umrissen. das frontend soll schlank sein und möglichst in einem rutsch, in einer datei ausgeliefert werden. da dynamische anfragen an die cloud möglichst minimal gehalten werden sollen, ist die anlieferung der inhalte – wenn statisch – dann durch einige cache-layer abgefedert. da die dateien auf verschiedenen knoten verteilt sind, kann es bei ungecachten dateien durchaus 2-3 sekunden dauern, bis diese verfügbar sind. ein prefetch oder precache ist daher sinnvoll. die dynamischen inhalten werden durch ein nosql schema realisiert. das datenmodell ist in verschiedenen schichten sowohl im front- als auch im backend nutzbar und ist teilweise durch generische klassen oder reflektive methoden ergänzt. die dateiablage kann man als flatfile ansehen, die durch map-reduce-aufbau oder ein denormalisiertes modell gekennzeichnet ist.

was heute cloud heißt, war vorher ein cluster, davor ein grid und irgendwann bestimmt auch mal ein mainframe 🙂 die heut noch üblichen architekturen, mit application-server <-> database-server, network-attached-storage und ftp-backup wird verglichen mit dem konzept, welches meiner entwicklung zu grunde liegt. die skalierung von 6-10 maschinen ist dort skizziert, die 5.000 maschinen, die bei hadoop-clustern durchaus üblich sind, muss sich der geneigte leser dann vorerst doch noch vorstellen.

der workflow oder die sequenzen, die für die arbeit zwischen den layern benötigt wird, kann man als mechanik in diagrammen aufzeigen, so können für verschiedene anwendungszenarien die beteiligten komponenten identifiziert, beschrieben und ausgebaut werden. da alles in einer sprache verfasst ist, ist ein medienbruch oder andere dialekte vorerst nicht nötig.

ist die orchestration dann über verschiedene kontinente und mehrere rechenzentren verteilt, so können funktionen eines cdn implementiert werden. dort werden dann ungesehener und gesehener inhalt ausgetauscht, statistiken für die optimierung und auswertung angelegt und die günstigsten, schnellsten oder besten routen für die anlieferung der daten gewählt.

mit dieser infrastruktur kann dann auch streaming betrieben werden, da die signallaufzeiten und die kapazitäten den anforderungen des marktes angepasst sind und entsprechend flexibel dimensionierbar sind.

this();

singlePageHTML

beim rumsurfen und vergleichen von downloadgeschwindigkeiten einzelner webseiten, der zeit bis der dom-tree geladen ist und die seite fertig gerendet ist, hat mich von der singlepagevariante überzeugt, die auf ioioioio.eu nun sichtbar ist.

das ding heißt bootstrap und bezeichnet sich als framework. ( wir erinnern uns, framework calls you – you call the library ) … nunja, es soll wohl der komplette baukasten gemeint sein. jquery und kompiliertes javascript tun ihr übriges. die seite ist mit ihrem brutto-volumen von einem megabyte in etwa einer sekunde geladen. die g+ einbettung dauert dann ein wenig länger. gecached ( wiederholt geladen ) ist sie in etwa 500ms aufgebaut und dauert mit dem gugl-geraffel dann knapp über eine sekunde und braucht dann nur noch ein paar kilobyte zu laden.

mir gings im wesentlich darum ein seitendesign zu nutzen, welches in einer datei ausgeliefert, dennoch eine simple navigation ermöglicht. grund ist, das ich solche seiten mit generieren will, die dann statisch auf dem file system vorliegt und daher ultra-fast ausgeliefert werden kann. da es sich jedoch um pures html handelt, ist die erstellung des inhaltes im editor dann nicht so lecker.

die nutzung eines rich-text-clients ( wysiwyg editor ) ist da dann immer noch notwendig, eine synthese aus diesen beiden habe ich bisher noch nicht entdeckt, aber auch noch nicht konkret danach gesucht. ich wollte meine landing page erneuern, mit jquery rumspielen und das ist dann halt dabei rausgekommen. könnte schlimmer sein 🙂

eine der möglichen templates für die seiten in der cloud könnte dann in etwa so aufgebaut sein und in aussehen und verhalten durchaus ähnlich sein. als passive oder statische seite sehe ich dieses design für brauchbar an.

cloud, coding, this();

eisenBahnPlatte

„was ist eigentlich eine holzeisenbahn?“

das projekt der private cloud den menschen zu vermitteln und dann noch zu erklären, dass man damit seine freizeit gestaltet, ist mir über die jahre nicht einfacher gefallen.

der begriff „eisenbahnplatte“ trifft vermutlich noch am ehesten dass, was otto normal bereits von anderen kennt, wenn es um viel arbeit, geld und liebe geht, das in ein projekt fließt, welches vermutlich nie wirtschaftlichen bedingungen unterworfen ist. man könnte es auch luxus nennen oder wie es allgemein genannt wird: hobby.

da ich mich nicht nur auf arbyte, sondern auch am wochenende oder nach feierabend mit den themen hier beschäftige, sah ich diesen begriff noch am dichtesten an dem, was eh schwer zu beschreiben ist. da dazu jede menge programmierung gehört, die erst gut läuft, wenn die konfiguration ein mindestmaß erreicht hat, ist die komplexität in zusammenhang mit der hardware und den modulen, die extern verwendet werden immens. ich hab garnicht präzise vor augen, wie viele schichten / layer nun tatsächlich involviert sind, manche sind absichtlich eingezogen, um module zu entkoppeln, andere lassen sich vielleicht auch reduzieren und einsparen.

da mir in den verschiedenen phasen schon beinahe der kopf geplatzt ist, hab ich teilweise oder an bestimmten punkten, die arbeit ruhen lassen und dinge aufgemalt, beschrieben oder sonstwie umrißen oder skizziert, damit nicht nur ich die dinge verstehe, sondern eben auch andere.

daher ist die eisenbahnplatte all das, wozu ich nach dem 3. oder 5. mal keine lust oder kraft hab, es zu schildern oder zu erklärbärn. daher auch der blog hier, um einsicht zu schaffen und ansichten zu vermitteln, die aussenstehenden oder interessierten die möglichkeit gibt, dinge zu erfahren, die sonst nur schwer oder schwierig zu erfassen oder gar zu finden sind.

„die eisenbahnplatte fuhr schonmal“ mit drei nodes, doch sind mittlerweile alle server vom netz und derzeit wird neue hardware getestet und konfiguriert, damit der wirtschaftliche aspekt nicht zu kurz kommt.

cloud, english, this();

anotherServerInstance

as a friend from a provider in berlin gave me the access to a vhost he had, i received another donation from him. a vhost instances with some more ram, as i had on the machine since now was now in the park.

so i had three machines to build my cloud further. since 2010 i was working with big-data tools and the hadoop-framework, a distributed file-system was the main aspect to build such thing. with the new server, i was able to raise the replication from 1 to 2. that was not the replication-factor of 3, which could be seen as minimum for hot-fail-over redundancy systems, but on the right way.

i introduced the machine to the cluster and configured the redirect-proxy the same way, as the machine in jena. after some tests, i had failures with „to many open files“ and i noticed, that the vhost-guest-system was heated to much with the hdfs, so i configured them further.

beside the cluster, i was able to use them as streaming-server for the radio as well, as i switched chromanova.fm on, with two channels as well. that was nice, to have capacity in bandwith that way and the scale was nearly linear to the count of machines.

now i was able to play harder with the layer between the tomcat-servlet and the byte-stream, given by the filesystem. the new machine had 4 gigabytes of ram and i gained the headroom for the caching on tomcat much higher then possible before.

 

cloud, english, this();

anotherWebServer

as i patched lighthttpd to work with the servlet and the next patches discontinued over a period, i was somehow motivated to check another services, for the same reason.

i just needed the webserver to redirect and reverse proxy the requests and responses from the different instances/services to the client. no php, just port handling and some folder/path specialties. so i kicked lighty and droped nginx on the system.

the configuration wasnt that re-usable as i hoped, but the plenty examples on the web made it possible to came up with the service after two weekends. nginx performed well in the official benchmark examples and i was happy with the result, ive seen on my own on the examples i made. handling the j-session-id was done with a patch and the round-robbin worked much more smooth, then before.

the delivered pages were quick and the hunger for ram was low, so i raised the caching on the webserver a bit higher and played with different configurations between tomcat and nginx over the next weekends. i was ok with what ive seen, so the need to dive into the apache config was not a topic anymore.