Resümee der ersten vier Wochen Soundpark. Soundpark ist wie der Rest der FM4-Site auf Hop gebaut. Wäre interessant von Stefan Pollach zu erfahren, wie lange er daran gearbeitet hat.

Gestern auf Salon.com Andrew Leonards How Big Blue fell for Linux
gelesen. Aufschlussreiche und gut recherchierte Geschichte.

Ich habe vorläufig genug von der Verehrung obskurer Xerox PARC-Götter und Göttinnen in meinem engeren Umfeld. Wie wäre es zur Abwechslung mit etwas, das dann auch tatsächlich funktioniert hat? Worse is better, remember? Ich würde euch ganz gern mal von Andrea Arcangeli reden hören. Andrea hat in einer Aktion, die an Dramatik und Bedeutung kaum zu überbieten ist, dem lebenden Linux-Kernel völlig neuen Virtual Memory-Code eingepflanzt. Die Ergebnisse sprechen für sich. Zu technisch? Oder noch nicht genug Zeit vergangen um das richtig gut verklären zu können?

Danke, Chris!

Dass Alan schon in den 70ern die Idee hatte, einen Laptop zu bauen ist eh schön und bewundernswert und alles. Aber hey: der Mann wurde dafür bezahlt, hochfliegende Ideen zu haben. Das war sein Day-Job.

Ach ja. Ich gebe mich geschlagen und zieh sie mir rein, die Dynabook Chronicles. "Kay himself was a compulsive promoter, producing a steady stream of articles and conference abstracts, often illustrated with his own hand drawings of children in bucolic settings playing with their Dynabook, to proclaim the death of the mainframe and the advent of the "personal computer"." Irgendwie ist mir der Mann nicht geheuer.

Bei katatonik gibt es fünf oder sechs Schwänke zur Aufklärung.

Slashdot-Diskussion über Programmieren als "Ingenieurswissenschaft" (NOT!) Zwei essentielle Postings: Ja, aber. Softwares sind nicht Brücken. Es ist nicht möglich, rechnerisch herauszufinden, ob Software hält oder nicht. Bislang jedenfalls.

Der "Cadillac unter den Putern". (Laut Megnut.)

BBC: US shuts down Somalia Internet.

Ich wollte etwas auf tiny@antville schreiben. ist es nicht moeglich, etwas passport aehnliches (redirects zu einem auth host und wieder zurueck) fuer henso,p3k,motz,tinytalk,.... einzufuehren ? Daran koennten auch andere weblogs teilnehmen. Ich moechte nicht auf jedem weblog einen account anlegen. Dies sollte doch sehr einfach zu implementieren sein (< ein wochenende)

brüten überm soundpark seit anfang september, die effektive programmierarbeit war dann ca zwei wochen. die applikation ist sehr eng mit dem fm4-storyserver verzahnt, die beiden apps teilen sich diverse einige prototypen und editoren.

Merci für die Info. Zwei Wochen finde ich sehr ok für eine real-world/production site. Schätze das war auch irgendwie dein Brain-Child, oder?

funzel: Interessante Idee. Bin mir aber nicht sicher, ob es den Aufwand wert wäre. Käme auf einen Versuch an.

Das mit der Verehrung der PARC Götterinnen ist doch nur ein blöder Nebeneffekt der Beschäftigung damit, was Leute mit Computer und drum Computer so tun oder tun sollen. Es ist ja gerade die Crux, dass Computing heutzutage immer noch total von den Ideen aus den 60er und 70er Jahren dominiert wird und sich fast alle fast nur mit Implementierung rumschlagen. mehr in kürze auf tiny

hns: alle reden ueber passport. man sollte die gute idee nehmen und selber verwenden. und zeigen, dass man kein .NET dafuer braucht.
ich bewege mich (wie viele hier) im LNGR, henso, scripting, searls, joel, usw. umfeld. diese koennte man zumindest versuchen mit gemeinsamen logins zu unterstuetzen, da die meisten die sich mit diesen themen beschaeftigen, auch die gleichen webseiten lesen (= meta-community?). ich denke dass das ganze schon praktisch waere. netter ist natuerlich der irgendwann auf scripting besprochen ansatz des auth ueber p2p zu machen, wobei jeder seine daten und den zugriff selbst kontrolliert. ich glaube es ist aber besser, mit etwas einfachem anzufangen und das dann zu verbessern als lange ueber die optimale loesung nachzudenken. ich koennte z.B. in einem config auf dem auth host (erstmal einer, dann verteilt, evtl. als hop etc. komponente) festlegen, welche websites meine daten bekommen. und wenn man sich den ablauf der passport auth ansieht, erscheint mir die sehr einfach gemacht und kopierbar.

Ich weiss ehrlichgesagt nicht viel von den technischen Details der Passport-Authentifizierung. Würde dem Versuch aber sehr wohlwollend gegenüberstehen.

falls ihr auf gute ansaetze kommt, ich mache gerne vanilla-seitige implementationen ;)

passport arbeitet mit cookies und einer server side component. mir ist allerdings nicht ganz klar, wie das mit den cookies funzen tut. vor laengerer zeit hab ich mal das API interface kurz herausgepickt: Passport SSI. ich waere aber auch sehr wohlwollend, wenn mir wer erklaert wie das cross-domain cookieing machen ;)

der auf scripting angesprochene ansatz, hatte nie etwas mit auth zu tun. da gings nur um prefs.

mein ansatz (irgendwann vor laengerem mal ueberlegt, aber dann wieder verworfen ;) waere ein spezifiziertes auth interface. dieses bietet die registrierung (username, pass, email), die authentifikation (user+pass ok?) sowie die abfrage der registrierten daten. dieses (xml-rpc) interface koennen dann beliebig viele auth-server implementieren.

use cases: webseiten die das system unterstuetzen nenne ich mal kurz affiliates.

uc1 - login bei affiliate: haben weiterhin login seiten. allerdings kommt ein neues feld hinzu: url to auth-server. ist da ein server angegeben, wird die auth ueber den erledigt, falls auth ok, kuemmert sich aber weiterhin der affiliate ums session handling.

uc2 - register bei affiliate: entweder ueber das normale system, oder optional "the new way." beim neuen weg, gibt man nur username, passwort nud auth-server ein. die affiliate-site authentifiziert, holt sich die restliche information und legt benutzerinfo fuer sich lokal ab (und generiert ihre eigene uid oder was auch immer sie noch zusaetzlich braucht).

ist einfach zu implementieren, erschlaegt aber nur ganz wenige punkte. vor allem: eine registrierung kann sich wie ein login anfuehlen ;)

das cross cooking wird glaube ich ueber ein redirect gemacht. Kurz wird jeder der eine passport website besucht (msn, hotmail), auf eine gemeinsame domain umgeleitet. diese liest und schreibt die cookies. dann authentifiziert man sich und wird wieder zurueckgeleitet. wenn man das cookie hat wird man sofort weitergeleitet. durch das redirect funktioniert das mit dem cookie lesen und schreiben (ein cookie, aber verschiedene domains). ein XML-RPC interface koennte man auch hinzufuegen. nur fand ich "schieben" ueber eine gemeinsame domain lustig.

die prefs diskussion ist aelter. die p2p diskussion fuer auth war vor kurzem.

hast vielleicht einen link zur p2p auth diskussion bei der hand ;) ?

ich freu' mich schon besonders auf das login auf LNGR ;-]

ich habe nun auf scripting und jabber und blogger gesucht. nichts gefunden. ich glaube das war auf einer privaten homepage von einem der jabber oder blogger leute. ich such mal weiter.

chris: :-P

götter: meiner meinung nach hat das graben auch dazu geführt, die verherrlichung ein wenig abzukühlen: viele egomanen, teamwork mit für und wider, chancen und kämpfe. erfolge und misserfolge: drama. und wie good old brian quotes: "most papers in computer science describe how their author learned what someone else already knew."
-- peter landin, circa 1967
jo so is

Brücken werden auch nur auf eine Art und Weise (also meistens zumindest) verwendet, man kennt die Umgebung, in der sie sich aufhalten, genau, sie brauchen sich nur um wenige Zentimeter an geänderte Bedingungen anpassen können ...

Hingegen Software! Jeder verwendet Sie anders, baut sie auseinander und wieder zusammen, wirft oft Säue, manchmal Perlen und sonst allerhand zum Frass vor, die Anzahl der Umgebungen, in der ein Stück Software verwendet wird, ist beinahe gleich NUMBER_OF_USERS ...

Irgendwo mal ein Zitat aufgeschnappt, das die Komplexität von Brücken mit der von Software vergleicht. Mal sehen, ob ich das noch auftreiben kann.

Hier mal ein nicht uninteressanter Artikel zum Thema.

Ja oder im Unterschied zum Maschinenbau: Kein Kunde dort erwartet, dass er einen Monat vor Auslieferung noch grundlegende Dinge aendern kann. Bei Software aendert der Kunde dauernd irgendwelche Sachen. Bruecken plant und baut man ueber Jahre. Wenn man heutzutage einem Kunden erzaehlt, er bekommt seine Software in 2 Jahren, kann man wieder heimgehen.

alte Frage, aber all diese Computersachen ohne universelle Flexibilität (appliances oder so) sind meistens ja auch fad und haben gegenüber ihren analogen oft ebenso viele oder mehr Nachteile als Vorteile. Und das kostet halt was. Zuviel Engineering resultiert nicht selten in overdesigned waterfall systems.

Not logged in. Click here to log in.