Content-type: matter-transport/sentient-life-form

if SCO isn't right, someone else will be

Mal wieder eine der leidigen Diskussionen darüber, das Open-Source-Projekte notorisch schlecht wären bei der Kontrolle von Lizenzbestimmungen an Code. Bitte was? So langsam wirds nervig. Warum meine eigentlich immer wieder Leute die Klappe aufmachen zu müssen, ohne das Gehirn einzuschalten?

Also erstmal vorweg, es gibt wohl kaum einen Softwarebereich, der stärker auf Lizenzen achtet als der Open-Source-Bereich. Allein schon wegen der diversen nicht kompatiblen Open-Source Lizenzen (jeder Entwickler wird früher oder später über Lizenzkompatibilitätsprobleme mit der GPL stossen - die Diskussionen darüber sind immer wieder zu finden). Auch wird gerade im Open-Source-Bereich in vielen Projekten immer wieder explizit aufgepasst, das keine proprietären Inhalte in den Source wandern - siehe z.B. das Samba Projekt oder Wine. Beide schaffen es, neben Microsoft zu existieren (und die Rechtsabteilung von Microsoft ist nicht gerade schlecht). Und was mich noch viel mehr nervt an der ganzen Geschichte: wieso glauben diese Leute eigentlich immer, das in proprietärer, geschlossener Softwareentwicklung nicht fremder Source geklaut wird? Diese Vermutung ist doch absurd. Im Bereich von Open-Source-Projekten kann jeder den Source lesen - auch die Firmen. Jeder kann es kontrollieren, ob fremder Source verwendet wird. Im proprietären Bereich hingegen geht das nicht. Hier sind aufwändige Gerichtsverfahren nötig, um Sourceprüfungen zu erreichen und der Nachweis ist nicht gerade einfach. Also bitte nicht einfach den FUD von Firmen wie SCO nachplappern, bitte mal erst den Kopf einschalten und nachdenken. Und mal die Faktenlage prüfen.

Bei Cincom Smalltalk Blog - Smalltalk with Rants gibts den Originalartikel.

COW - Programming for Bovines

Muh!

Hier gibts den Originalartikel.

Syndication

Ich spar mir jetzt mal das übliche Gerede von Stop-Energie, weil jemand eine Neuerung blogged (sorry, blockt ) und sag mal, warum ich der Meinung bin, das das Unternehmen Sinn macht.

RSS ist ein Format das von vielen verschiedenen Leuten in verschiedene Richtungen entwickelt wurde. Es gibt zwei Hauptströmungen. Die RDF-basierten Formate mit dem Gipfel in RSS 1.0, mit design-by-company und teilweise sogar by-commitee. Und die keep-it-far-too-simple Strömung von Dave Winer mit dem Gipfel in RSS 2.0, welches zwar versucht RSS und RDF zu verheiraten, aber eigentlich auch nicht so wirklich rund ist (zum Beispiel wird neuerdings von Dave alles was Namespaces benutzt als "funky RSS" tituliert - ich hasse Funk!).

Was kann also ein neues Format bringen? Unter Umständen garnix. Macht dann auch nix, dann weiss man wenigstens (und hat es nachlesbar dokumentiert), das RSS in den vorhandenen Ausprägungen gut genug ist.

Oder man erkennt das es Schwächen und Fehler im vorhandenen Pool an Formaten gibt. Wenn das der Fall ist, gibt es wieder zwei Möglichkeiten:

Die Schwächen lassen sich beheben (zum Beispiel eben durch RSS 1.0 mit voller RDF-Basis oder mit RSS 2.0 und ein paar zusätzlichen Namespaces). Mit Sicherheit wird das gemacht werden - denn nicht jeder will auf ein neues Format aufspringen.

Die Alternative - das neue Format - hat aber auch was für sich: es wird in Community-Technik entwickelt. Ein Wiki, auf dem jeder seinen Senf dazugeben kann. Es kann also ein durchaus interessantes Format werden mit vielen guten Ideen. Warum sollte man es dann nicht implementieren? Wär doch schade, wenn die ganzen Ideen umsonst wären ...

Mindestens ist es aber ein wunderbares netzpsychologisches Experiment. Ein Haufen von ziemlich abgedrehten Freaks unterschiedlichster Färbung, die in einem Wiki (man erinnere sich: jeder kann alles editieren und ändern!) versuchen zusammen zu arbeiten. Hey, das schreit gerade zu nach Chips und Cola und gemütlichem Zurücklehnen und mitlesen

Teufelsgrinsen

.

Bei Der Schockwellenreiter gibts den Originalartikel.

Charming Python: Using combinatorial functions in the itertools module

Ein recht interessanter Artikel Über die neuen funktionalen Funktionen in itertools in Python 2.3. Mit itertools kann man eine Programmiertechnik anwenden, die aus Common Lisp schon länger als Series bekannt ist und am besten als lazy sequences beschrieben werden kann: Sequenzen von Objekten, die erst bei Bedarf soweit erstellt werden, wie nötig. Das eröffnet eine ganze Reihe sehr interessanter Techniken, die Programme sehr viel lesbarer machen können.

Hier gibts den Originalartikel.

MacOSX Packages for Mozart 1.2.5

Hey, Mozart und Oz gibt es auch für OS X. Ok, nicht direkt für OS X, sondern nur als normale Unix-Portierungen für OS X - das GUI baut weiter auf GTK auf und damit auf X11. Aber immerhin, man kann es auf dem Mac laufen lassen. Es gibt jetzt auch ein interessantes Buch über die Konzepte der Programmierung, welches diese anhand von Mozart und Oz beschreibt. Hier gibts den Originalartikel.

Vim 6: A Great Linux Outliner

Wer einen Outliner für Linux sucht, und VI mag, sollte sich mal den VIM Outliner angucken. Das ist ein Makropaket für VIM 6, mit dessen Hilfe dieser zu einem Outliner mutiert. Leider hat er noch ein paar heftige Defizite, wie zum Beispiel das er nicht speichert, welche Textbereiche collapsed sind und welche nicht. Aber grundsätzlich ist der schon ganz gut zu benutzen. Zumindestens immer noch besser als die Alternativen, die ich bisher gefunden habe. Ausserdem braucht man VIM nicht zu booten, wie Emacs

Hier gibts den Originalartikel.

Swindle - CLOS und mehr für DrScheme

Das hier ist aber wirklich klasse: eine auf Tiny-CLOS aufbauende OO-Erweiterung für DrScheme (wobei Objektorientiert hier der typische Objekt+Funktional-Mischmasch aus CLOS ist - also nicht diese Minimal-OO-Systeme von typischen klassenbasierten Sprachen). Sehr schön. Und noch einen grossen Stapel zusätzlicher Tools und Utilities. Im Prinzip könnte man meinen das der Programmierer versucht hat weite Teile von Common Lisp in DrScheme zu implementieren. Nett, da ich als alter CL-Fan und Scheme-Fan hier das beste aus beiden Bereichen kriege

Leider ist das System nicht auf das GUI-System ausgeweitet worden, das ist noch in der mehr klassischen OO-Form aus DrScheme vorhanden. Ein CLOS-Wrapper darüber (oder womöglich sowas wie ein Tiny-CLIM? Jaja, bin ja schon still, aber man wird ja noch träumen dürfen) wäre ja auch nicht schlecht.

Irgendwie erinnert mich DrScheme fatal an meine netten Xerox 1186-kompatiblen Lispmaschinen mit ihrem Mischmasch aus Interlisp-D und Common Lisp im Betriebssystem. Auch dort ist der Basiskram in Interlisp-D (in DrScheme halt in Scheme) implementiert und dann darüber ein Common Lisp (in DrScheme dann eben Swindle) gelegt. Sehr schöner Ansatz.

Und noch ganz witzig: ein kleines grafisches Werkzeug, das den Lambda-Calculus visualisiert. Programmieren mit farbigen Klötzchen zur Verdeutlichung.

Ich glaub ich mag DrScheme

Hier gibts den Originalartikel.

XchemeRPC

Soll mit DrScheme 200 und neuer funktionieren. Funktioniert natürlich nicht mit 204, die ich laufen habe. Also wieder mal ab in den Softwarekeller und mit der Rohrzange die Probleme beheben

Hier gibts den Originalartikel.

DrScheme

Eine sehr schöne Scheme-Programmierumgebung, deren Ziel vor allem das Erlernen von Programmierung an sich ist - aufbauend auf verschieden komplexen Scheme-Sprachumfängen. Das ganze gut daran orientiert was im jeweiligen Level notwendig ist. Dazu dann einen grossen Berg von Bibliotheken an nützlichen Funktionsdefinitionen, eine grafische Programmierumgebung und eine entsprechende Bibliothek für eigene Programme, viele sinnvolle Entwicklertools (und einige optinal zusätzlich installierbare Entwicklertools die man anderswo nicht bekommen kann) und das schönste: jetzt auch unter OS X lauffähig. Nett.

Hier gibts den Originalartikel.

Looking to do web stuff with Python?

Notizgeblogged, im Web-Framework-Shootout gehts um den Vergleich verschiedenster Web-Frameworks für Python. Recht interessant, und vielleicht kann ich ja die eine oder andere Idee für den Python Desktop Server oder den Python Community Server klauen. Bei Richard's stuff : /python gibts den Originalartikel.

Textsatzsysteme wie man sie nicht machen sollte?

Ich bin ja ein Lisp-Fan. Ich liebe Lisp-ähnliche Sprachen und benutze nach Möglichkeit nur Sprachen die zumindestens einen gewissen Grundschatz der Features bieten, die Lisp-Implementierungen auch bieten. Aber das geht zu weit: ein Textsatzsystem in der Struktur von TeX, aber mit Lisp-Syntax.

Irgendwie erinnert mich das an die Probleme, die ich mit Common Lisp habe: ich mag die Sprache, ich finde die meisten Features genial bis göttlich und ich habe durchaus brauchbare Implementierungen zur Auswahl. Ich benutze sie trotzdem nicht: ich müsste einfach zu viel Text schreiben. Die Bezeichner sind so lang wie Cobol Syntax-Elemente. Ihgitt. Ähnlich bei Scribe: zwar sind die Bezeichner kurz, aber ich muss das ganze Geraffel drumherum schreiben. Und habe die tollen Blah-blubb-fasel-blubber Bezeichner für diverse Steuerungszwecke. Wer will den ganzen Mist schreiben? Was bringt mir ein Textsatzsystem, bei dem ich mehr Markup reinschreiben muss, als ich in nacktem HTML schreiben müsste? Wenn ich so viel non-content schreiben wollen würde, könnte ich auch gleich DocBook verwenden ...

Hier gibts den Originalartikel.

Checkpointed Object Database

Klingt recht interessant, eine Datenbank mit pseudo-transparentem Zugriff aus Python. Objekte werden automatisch eingelesen und bei Änderungen automatisch geschrieben. Objekte werden automatisch der Datenbank zugefügt, wenn sie von einem schon gespeicherten Objekt referenziert werden. Die Datenbanken werden per Reference-Counting von Müll befreit (ausser man produziert zyklische Referenzen). Und es gibt ein Checkpointing, mit dem man sicherstellen kann das eine Datenbank mit dem zuletzt konsitenten Zustand wieder hochfährt. Im weitesten Sinne ähnlich zu Metakit, aber ein bischen stärker auf Objekte als auf Tabellen abgestimmt. Dadurch sicherlich eine elegantere Einbindung in Python-Code. Die Frage ist, wie ist die Performance. Denn viele kleine Objektdatenbanken sind fies langsam, wenn die Anzahl der Objekte darin grösser wird. Und grosse Objektdatenbanken sind für sowas wie ein Weblogwerkzeug schlicht overkill. Hier gibts den Originalartikel.

Firebird unter OS X

Also Firebird ist ja ganz niedlich. Allerdings fürchterlich langsam (vor allem das Scrollen von Seiten ist unerträglich durch dieses fürchterliche Ruckeln), da bin ich von Safari schnelleres gewöhnt. Aber eines ist absolute Oberklasse: die Extensions (siehe Link am Titel). Ich hab da mal die Webdeveloper-Extension und die Checky-Extension geladen, mit ersterer gibt es einen ganzen Satz von Webentwicklertools (wie z.B. visuelle Darstellung von Dokumentenstruktur, schnelle Sourceanzeige, diverse Validatoren, Tools für Images, Formulare, enable/disable diversester Features etc.). Checky ist einfach nur eine Erweiterung die in das Popupmenü des Dokumentes einen grossen Stapel von Validatoren für verschiedenste Zwecke einklinkt - incl. Auto-Discovery der entsprechenden Teile (z.B. CSS oder RSS-Feeds werden automatisch gefunden und dann auf Wunsch validiert). Klasse. Bitte jetzt das ganze nur noch schneller, dann bin ich zufrieden

Hier gibts den Originalartikel.

Nochmal zum Validator

Hier hab ich den Grund gefunden: SCRIPT ist ein Element das sowohl als Block-Element als auch als Inline-Element benutzt werden kann. A ist ein Inline-Element. Also kann ich SCRIPT innerhalb A benutzen. NOSCRIPT hingegen ist ein Block-Element. Darf also nicht innerhalb eines A benutzt werden. Das ist Moppelkotze!

Blödes W3C. Gibt es bei denen keinen der denken kann? Das SCRIPT Tag hat sein Gegenstück im NOSCRIPT. Also macht es nur Sinn, wenn ich das NOSCRIPT auch an der gleichen Stelle benutzen kann wie das SCRIPT. Das geht aber nicht. Im Python Desktop Server wird in den Links für die Kommentare mittels Javascript die Anzahl vorhandener Kommentare eingefügt. Dazu soll es eine alternative Darstellung geben (einfach nur ein Fragezeichen), damit da nicht leere Klammern stehen. Nur da das ganze innerhalb eines A Tags liegt, darf ich da zwar SCRIPT benutzen, aber nicht NOSCRIPT. Das ist Moppelkotze!

Ja, ich weiss, ich wiederhole mich, aber bei soviel Blödheit kann man nur schreien. Ich darf mir jetzt aussuchen ob ich validierendes HTML haben will, oder welches das den Accessibility-Guidelines gehorcht. Die Technik im Python Desktop Server umzustellen ist leider nicht so einfach, da der Python Community Server nur statisches HTML ausliefert und daher dynamische Inhalte per Javascript eingefügt werden müssen. Das ist ja auch genau das, wofür Document.write() erfunden wurde. Und es liesse sich völlig trivial durch eine NOSCRIPT Alternative sauber für die abbilden, die kein Javascript haben oder wollen. Irgendwelche Vorschläge (ausser den Beruf zu wechseln)? Nachtrag: hier hat jemand sich dazu auf den W3C Listen geäussert. Der Vorschlag: den ganzen Absatz als Alternativblock zu setzen. Nein danke. Dann fliegt NOSCRIPT eben raus - denn es gibt eine Reihe von Browsern die den Inhalt von NOSCRIPT auch dann rendern, wenn Javascript aktiviert ist. Hier gibts den Originalartikel.

Sandbox für Python

Notizgeblogged, weil ich damit evtl. mal rumspielen will - z.B. um User-Code im Python Community Server laufen lassen zu können. Hier gibts den Originalartikel.

Another Smalltalk?

Interessant - nur ein paar Screenshots, aber was die zeigen, wäre wirklich nett: ein natives Smalltalk für Mac OS X. Ich habe ja schon ein bischen mit VisualWorks rumgespielt, aber das ist eben nicht native - dort wird immer noch die eigene Systemwelt gesehen, und es ist mehr schlecht als recht in das OS X integriert. Ein Smalltalk, das vom Look-and-Feel eine OS X Applikation ist, und das dann vielleicht noch über eine entsprechende Bridge die ganzen Objective-C Klassen mitnutzen könnte, das wär noch was. Bei Cincom Smalltalk Blog - Smalltalk with Rants fand ich den den Originalartikel.

PEAK / PyProtocols

Muss ich mir mal angucken, klingt etwas wirr, aber recht interessant. Eventuell ist das ein Weg einige der etwas sehr engen Koppelungen und Bindungen von Modulen im Python Desktop Server aufzubrechen. Und noch ist der Python Desktop Server ja Beta, da darf man sowas

Bei Tao of the Machine fand ich den den Originalartikel.

Python und curses - und eine Python-Implementation von readline

Hmm. Schade - es wird über eine klasse Library für Python berichtet, die eine weitaus bessere Alternative zu readline (der Eingaberoutine die im Python Interpreter benutzt wird) bietet. Da kann man dann auch Multiline-Editing machen und zum Beispiel per Tab Python-Namen vervollständigen (Module und andere Globals). Nachteil: es braucht curses. Und komischerweise wird Curses beim Build vom privaten Python für den PyDS nicht generiert. Seltsam.

Ok, also die Dateien einfach aus dem Standardpython das mit OS X 10.2 mitkommt rüberkopiert, schon geht es. Schönes Modul. Nur: wieder mal keine Ahnung der Programmierer von ungewöhnlicheren Umgebungen wie z.B. 8bit-Zeichensätzen. Umlaute gehen nicht. Backspace geht nicht, statt dessen muss Ctrl-H benutzt werden.

Aber komfortabler ist es definitiv, auch wenn es beim Laden etwas länger braucht. Mal schauen ob das evtl. im Python Desktop Server in den Monitoring-Client integriert werden kann, denn der krankt vor allem an der absolut spartanischen Eingabemöglichkeit.

Hier gibts den Originalartikel.

Dynamically Scoped Variables

Genau dieses Problem hatte ich im Python Desktop Server auch. Ich habe dafür dann PyDS.Context geschrieben. Dort wird flet definiert und als neues Builtin aktiviert. Über flet kann man einen dynamischen Kontext erzeugen:

 > > > try: > > > _flet.begin(variable="wert") > > > ... > > > finally: _flet.end()

Nicht die eleganteste Version, aber immerhin benutzbar. Mir wäre es aber lieber wenn es in Python echte fluid lets wie in Scheme gäbe.

Bei PragDave gibts den Originalartikel.

This is just cool - ST-80in VW 7

Das ist wirklich cool. Ein Smalltalk-80 das unter einem in Smalltalk (Visual Works 7) geschriebenem Emulator für eine Xerox Alto läuft. Wow. Die in dem Artikel genannte Dolphin gehört zu den D-Maschinen von Xerox. Ich hab zwei kompatible Systeme hier rumstehen. Leider habe ich nie die Smalltalk-Disketten bekommen mit dem Microcode und dem Image, sondern habe bisher nur das Lyric und das Koto Lisp. Lyric ist eine ganz nette Common Lisp Umgebung, aber Koto ist wirklich klasse: eine reinrassige Interlisp-D Umgebung (ok, die ist in Lyric und in dem späterem Medley Common Lisp noch mit drin, aber in Koto ist es eben alles pures Interlisp-D!).

Bei Cincom Smalltalk Blog - Smalltalk with Rants fand ich den den Originalartikel.

20 years of Smalltalk-80

Smalltalk 80 hat 20jährigen Geburtstag. Da gratulier ich doch gleich mal und lach mal kurz Java aus

Bei Cincom Smalltalk Blog - Smalltalk with Rants gibts den Originalartikel.

SAP setzt auf MySQL

Naja. Bisher war SAPDB eine durchaus interessante Datenbankalternative (ok, ich mag PostgreSQL wesentlich lieber, aber was solls). Aber wenn die MySQL-Leute da jetzt dran rumfummeln, dann kann das nur schlechter werden. Ob die wohl outer joins aus dem SQL der SAPDB ausbauen? Und Transaktionen rauswerfen? Weil das braucht ja sowieso niemand, wie sie früher immer gerne argumentiert haben

Teufelsgrinsen

Bei heise online news gibts den Originalartikel.

Eiffel releases beta of EiffelStudio for OS X

Ok, die Entwicklungsumgebung ist interessant und die Implementierung klingt gut. Eiffel ist eine nette Sprache (etwas sehr geschwätzig, aber dafür auch deutlich lesbarer als z.B. C++). Und durch die integrierten Tools bietet so eine Umgebung natürlich mehr als nur einen nackten Compiler - Case-Tools etc. sind mit drin.

Trotzdem ist der Preis von 4800 US Dollar meiner Meinung nach eher ein Argument das nicht zu kaufen. Sorry, Leute, aber für den Preis kriege ich eine komplett ausgestattete Lizenz für Allegro Common Lisp, und das bietet deutlich besseren Komfort und deutlich nettere Sprachfeatures und Ausdrucksmöglichkeiten als EiffelStudio.

Und ich finde den Preis für Allegro Common Lisp schon deutlich zu teuer ...

Bei The Macintosh News Network gibts den Originalartikel.

Microsofts Protokoll-Peepshow

Na klasse. Da guck ich doch lieber in die Samba-Sourcen, wenn ich Informationen über die Microsoft-Protokolle brauche, die Sourcen sind wenigstens kostenlos.

Teufelsgrinsen

Bei heise online news gibts den Originalartikel.

On Lisp Reprint

Cool. Wer das Buch noch nicht hat und sich mal tiefer mit Common Lisp beschäftigen will: zuschlagen und kaufen! Eines der besten Bücher über Common Lisp und definitiv die beste Beschreibung über die Möglichkeiten von Common Lisp Macros.

Bei lemonodor gibts den Originalartikel.

Python-Panik rund um Jülich?

Also bei uns bricht auch hin und wieder die Python-Panik in der Firma aus, vor allem wenn ich mal wieder mit Python 1.5 arbeiten muss

Bei WDR.de gibts den Originalartikel.

Donald E. Knuth über signifikanten Whitespace

We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language. Donald E. Knuth, "Structured Programming with goto Statements", Computing Surveys, Vol 6 No 4, Dec. 1974 Fresst das, ihr Perl-Hacker!

Teufelsgrinsen

(BTW: bin selber auch Perl-Hacker, ich darf lästern )

(re)StructuredText

Als Antwort an den Kollegen auf seine Frage (weil er ja immer noch keine Kommentare an seinen Beiträgen ermöglicht und sein Forum eine Anmeldung verlangt und ich mich nicht anmelden will

Teufelsgrinsen

): (re) Structured-Text wird in den Python DocUtils mitbenutzt. Das wird auch im Python Desktop Server benutzt, damit ich nicht die Inhalte mit HTMl schreiben muss. Im Python Desktop Server ist auch ein Modul StructuredText.py mit dabei, welches für Standalone-Einsatz benutzt werden kann - es hat zwar minimale Abhängigkeiten vom Python Desktop Server, aber die werden bei Standalone-Verwendung automatisch abgeschaltet (es geht dabei hauptsächlich um Anreicherung und automatische Verlinkung auf Inhalte aus dem Weblogtool - könnte also auch bei anderen Projekten benutzt werden).Generell kann ich (re) StructuredText nur empfehlen, es ist sehr komfortabel - meiner Meinung nach von allen derzeit für Python verfügbaren Text-HTML Konvertern der fortgeschrittenste. Es gibt eine freigegebene Version 0.2 und eine CVS-Version 0.3 - der Python Desktop Server basiert auf der 0.2er Version, also beim Ausprobieren des Moduls darauf achten die richtige Version zu benutzen!

Vom Python Desktop Server hingegen sollte die CVS-Version des Moduls StructuredText.py benutzt werden, weil dort massive Änderungen von Garth T. Kidd drin sind, die die Funktionalität deutlich erweitern - die bisherige Release-Version vom Python Desktop Server hat noch einen von mir selbstgestrickten HTML-Konverter mit reduzierter Funktion.

Bei Der Schockwellenreiter gibts den Originalartikel.

Hackers and painters

Endlich mal ein Text der sehr gut das wiedergibt, wie bei mir das Programmieren funktioniert. Programmieren ist weitaus mehr ein ästhetischer und kreativer Prozess als ein rein technischer - viele Aspekte der Programmierung haben bei mir mehr mit künstlerischer Tätigkeit als mit technischer Umsetzung zu tun. Je tiefer ich in ein Programm einsteige und in den "Hackmode" gehe, desto weiter bin ich von der klassischen Lehre der Softwarentwicklung entfernt - da ist nix mit Design und Analyse, da ist aber sehr viel mit Intuition am Werke.

Wer die Programmierung auf den rein technischen Aspekt reduziert und meint man könne vorher alles planen und analysieren, am besten bevor man sich überhaupt an den Rechner setzt, der schliesst einen wesentlichen Anteil der Programmierung aus: nämlich den Dialog mit der Maschine, mit dem Problem.

Programmiersprachen sind ein Kommunikationsmittel, also sollten wir lernen mit diesen Sprachen auch zu kommunizieren. Nicht Radebrechen und Babelfish-Übersetzen!

Bei Tao of the Machine fand ich den den Originalartikel.

Linux: Keine Chance für Buffer Overflows

Das wurde auch langsam Zeit. Denn der beste Ansatz ist immer noch im OS selber, nicht im Vertrauen auf bessere Applikationsentwickler. Leider.

Bei heise online news gibts den Originalartikel.

80x86 ASM for ASP.NET

Autsch. ASP.NET Seiten in Assembler schreiben. Klar. Davon träume ich. Nachts. Wenn ich vorher zu viel Pizza gegessen habe. Mit Pepperonis.

Teufelsgrinsen

Bei Lambda the Ultimate fand ich den den Originalartikel.

Schemix - A Scheme In The Linux Kernel

Ok. Ich liebe Lisp. Und ich liebe Scheme als einen sehr schönen, schlanken Lisp-Dialekt. Aber ein Scheme-Interpreter integriert im Kernel geht selbst mir ein bischen zu weit

erstauntes Gesicht

Obwohl - das könnte doch ein Startpunkt für die OpenSource-Lispmaschine sein

Bei Lambda the Ultimate fand ich den den Originalartikel.

py-xmlrpc 0.8.8.3

Jupp, unbedingt angucken ob ich das nicht in den Buildprozess vom Python Community Server und vom Python Desktop Server aufnehmen sollte - die haben zwar beide noch keine Performanceprobleme, aber es schadet ja nix wenn es noch schneller wird

Bei Der Schockwellenreiter fand ich den den Originalartikel.

Pyro 3.2

Und auch das sollte ich mir mal angucken, auch wenn mir im Moment die Anwendung fehlt (meist reicht mir XML/RPC oder SOAP aus).

Bei PyPI recent updates gibts den Originalartikel.

GSM/GPRS on an SD card

Ok. Wann gibts Treiber für Linux, die auch im Zaurus funktionieren?

Bei Gizmodo fand ich den den Originalartikel.

Nur mal wieder ein bischen Eigenwerbung

Pssst. Neue Beta. Willste eine haben?

Bei PyPI recent updates fand ich den den Originalartikel.

Mac OS X und Darwinports

Mit den darwinports steht eine Umgebung zur Installation von Unix-Programmen vom Source ähnlich der BSD Ports Struktur zur Verfügung.

Was das ist? Mit den DarwinPorts kann man sehr einfach Unix-Software direkt aus den Sourcen heraus installieren, ohne sich mühsam die Sourcen erst holen und patchen zu müssen. Das ist die Idee.

Im Prinzip eine sehr komfortable Installationsstruktur ähnlich den Debian-Paketen nur auf Basis des Sources. In dem Aspekt ist Darwinports sehr ähnlich zu Fink. Wozu braucht man dann Darwinports? Ich war zuerst recht begeistert, da ich annahm es wäre die echte Ports-Umgebung (ähnlich wie GNU-Darwin zum Beispiel die Ports von FreeBSD benutzt und damit einen riesigen Satz von fertig compilierbaren Programmen schon hat - wesentlich mehr als Fink) von BSD. Nix da - es ist eine eigene Entwicklung. Und nicht mal mehr Software drin als Fink. Und noch besser: der make install stirbt bei mir mit einem Bus-Error im pkg_mkindex.tcl

Ganz ehrlich: wir brauchen nicht zehn verschiedene Installationssysteme für Mac OS X, wir brauchen eines das wirklich glatt läuft und funktioniert. Und da nehme ich dann doch lieber wieder Fink, das funktioniert tadellos und ist mitlerweile auch schon etwas voller in der Liste der unterstützten Pakete.

Bei Der Schockwellenreiter fand ich den den Originalartikel.

Aus der Traum: Keine US-Gelder für OpenBSD

Hätte mich auch gewundert, wenn das wirklich geklappt hätte - Theo ist nicht unbedingt der umgänglichste und kooperativste Mensch und Konflikte mit der Idee von " wer nicht für uns ist ist gegen uns " waren ja vorprogrammiert. Trotzdem schade das die Amerikaner sich einmal mehr von Ideologie und Nationalismus haben leiten lassen, anstelle eine ansich gute Idee einfach mal umzusetzen. Von der Arbeit an OpenBSD profitiert immerhin die gesamte OpenSource-Gemeinschaft - man denke nur an OpenSSH.

Bei heise online news gibts den Originalartikel.

Technisches vom Rollberg

Also da bin ich ja mal gespannt, wie sich SQLite dabei bewährt. Ich hatte mir das auch schon öfter angeguckt und war bisher noch auf der Suche nach einem Projekt dafür. Es gibt nämlich auch Python-Bindings für SQLite (sogar auf dem Zaurus - ich glaube dort wird es zuerst zum Einsatz kommen bei mir).

Bei Der Schockwellenreiter gibts den Originalartikel.

Interessante Programmiersprache: Goo

Goo ist eine kompakte und simple Programmiersprache aus der Lisp-Familie mit vollständiger Objektorientierung und einigen netten technischen Features (zum Beispiel dynamisches compilieren von Goo-Code in native code mit Hilfe eines C-Compilers). Ein bischen scheint Goo eine Alternative zu Paul Grahams Arc zu sein - Goo mit einem Fokus auf Objektorientierung, Arc mit einem Fokus auf funktionaler Programmierung. Sollte ich mir mal angucken, könnte durchaus interessant sein.

Hier gibts den Originalartikel.

Was hat Trackback mit dem historischen Web zu tun?

Seth Gordon gibt darauf eine Antwort, in dem er Bezüge zu der ursprünglichen Hypertext-Vision von Tim Berners-Lee (aus dessen vorigen Arbeiten zu Hypertext) mit dem Web vergleicht und aufzeigt, wo Trackback dort in die Ideen von Tim Berners-Lee hineinpasst. Interessant, kurz und knackig und ein paar Aspekte werden mit Perl-Code verdeutlicht.

Hier gibts den Originalartikel.

Home is where CVSROOT is...

Garnicht so eine schlechte Idee, einfach das Home-Verzeichnis per CVS auf einen Server synchronisieren und von mobilen Geräten dann aktualisieren.

Und noch eins: der Zaurus speichert sehr viel als XML ab - das kann man auch wunderbar per CVS nutzen. Und damit hätte man dann sogar für Kalender und ähnliches eine Austauschmöglichkeit mit Desktoptools. Und über transconnect könnte ich das auch mit dem Rechner in der Firma synchronisieren.

Hmm ...

Bei [/ndy's Weblog][0] gibts den Originalartikel.

Paul Graham spekuliert über Programmiersprachen in 100 Jahren

Nette Überlegungen vom Lisp-Guy No 1 (ok, er hat den Titel erst seit Guy L. Steele ins Java-Camp übergelaufen ist ).

Hier gibts den Originalartikel.

John C. Dvorak is a blithering idiot

Genau das gleiche dachte ich schon als ich das erste Mal von seiner absurden Prognose das Apple spätestens in 2 Jahren auf Intel-Prozessoren umstellen würde. Ok, jetzt setzt er noch einen drauf und behauptet das Apple pleite geht, wenn die nicht seinen tollen Plan umsetzen. Leicht wirr im Kopf, der Herr Fachjournalist

Teufelsgrinsen

Wobei seine tollen Prognosen und Ideen eine Menge Fehler enthalten: zum Beispiel seine Aussage, das mit der x86-Version von OS X die ganzen Linux-Leute ihre Software portieren können. Hat der Knallfrosch noch nie was von Fink oder GNU-Darwin oder ähnlichen Projekten gehört, die die Portierung von Unix-Software schon heute auf ganz normale PPC-Macs erlauben?

Bei algorhythm fand ich den den Originalartikel.

Microsoft patent on "probabilistic classiffiers"

Ja super, Microsoft hat ein Patent auf statistische Spamfilter

Bei Gary Robinson: Gary Robinsons Spam Rants fand ich den den Originalartikel.

Neue QuickTime-Version

Frage: (Wieso habe ich eigentlich einen Unix-Kernel, wenn ich die Kiste doch wieder neustarten muß?)

Antwort: Weil Apple keine ausgefeilteren Mechanismen (Serverprozess restarten, Services neu laden, Frameworks aktualisieren, etc.) in die Installationsroutinen eingebaut hat, sondern nur ein Neustarten desn ganzen Rechners.

Ja, das ist doof.

Bei Der Schockwellenreiter fand ich den den Originalartikel.

programmierung - 28.3.2003 - 27.6.2003