CMake Cross Platform Make - Endlich eine brauchbare Alternative zu den GNU autotools?
programmierung - 7.10.2003 - 23.12.2003
Divmod Lupy Overview - Volltextindex in Python - Portierung der Lupene Datenbank aus der Java Welt
Unreliable Guide To Locking - Dokumentation der verschiedenen Lockingmechanismen in Linux 2.6
D. Souflis - TinyScheme Download site - Sehr kompaktes Scheme, gut als Erweiterungssprache für Anwendungen geeignet.
OpenMCL - Leistungsfähiges Common Lisp mit native Code Compiler für den Macintosh und Linux PPC unter GPL
welcome to macscripter.net | applescript and script resource - AppleEvent Monitor zum Debugging von AppleScript und andere Programmverbindungen
Concurrent Versions Librarian - CVS Oberfläche für OS X
MacOS X Smalltalk - Ein neues Smalltalk für Mac OS X Native
ASPN : Python Cookbook : Complex Boolean Regular Expression Class - Eine Klasse für Reguläre Ausdrücke die mit boolschen Ausdrücken kombiniert werden können
ASPN : Python Cookbook : Length-limited O(1) LRU Cache implementation - LRU-Implementation als Python-Klasse
freshmeat.net: freshmeat - freshmeat XML-RPC API available - Freshmeat hat ein XML-RPC Interface um auf die Projektdaten zuzugreifen
Entzauberung der Open Source Entwickler Mythen
Was mich an dieser häufiger auftretenden Mythenentzauberungen stört: diese gehen immer davon aus das jeder Programmierer in der Open Source es darauf anlegt Produktionsqualität abzuliefern. Das ist aber der grösste Mythos, dem all diese Analysten aufsitzen. Die meisten OSS Programmierer programmieren an Programmen herum, weil diese ein Problem lösen, das sie haben. Oder weil sie einfach Spass daran haben, sich mit diesem Thema zu beschäftigen. Oder weil bestehende Lösungen nicht so arbeiten, wie sie sich das vorstellen. Die Gründe sind also meistens erstmal sehr egoistisch. Dabei wird dann zwangsläufig der Endbenutzer und andere Entwickler erstmal ignoriert - und aus diesen Projekten entwickeln sich später vielleicht grössere Projekte. In den seltensten Fällen fängt ein Projekt wirklich bei Null an mit der Prämisse ein professionelles Softwareprodukt zu liefern. Dieser Spieltrieb und der Egoismus der OSS Programmierer ist es aber, der die Vielfalt ausmacht. Aber natürlich auch das Chaos. Witzigerweise sind die gleichen egoistischen Programmierer extrem verteil und verschenkfreudig, weshalb sich aus diesen Projekten überhaupt nur grössere Projekte bilden können. Aber auch da steckt in der Regel ein egoistisches Bedürfnis hinter: das Bedürfnis nach Anerkennung. Ein wesentlicher Antrieb in OSS-Projekten ist die Erlangung von Bekanntheit.
Übrigens sehe ich das ganze absolut nicht negativ, im Gegenteil. Es ist eben das, was die OSS Landschaft so bunt und interessant macht. Projekte zu ignrieren, die einen nicht interessieren, ist definitiv einfacher als rumzumeckern das diese Entwickler in anderen Projekten mitarbeiten sollten - es gibt eben in der OSS keine Verpflichtungen.
Der Sprung zum grossen Projekt ergibt sich oft erst durch eine breitere Benutzerbasis, aus der sich dann nach und nach Mitentwickler rekrutieren. Trotzdem bleiben viele Projekte lange die privaten Projekte einzelner Personen - selbst wenn es schon eine Entwicklergemeinschaft ist. Der Linux-Kernel ist immer noch Linux Projekt, was sich immer dann zeigt, wenn er Maintainer ablehnt, Subsysteme rauswirft und eigenmächtig durch andere Implementierungen ersetzt. Die Frage, warum er das kann, erübrigt sich: es ist sein Projekt, natürlich kann er es.
Bei vielen Diskussionen über die Vorzüge und Nachteile wird immer wieder davon ausgegangen, das OSS Projekte überhaupt vergleichbar zu kommerziell betriebenen Projekten sind. Sind sie auch - dann, wenn hinter dem OSS Projekt eine Firma mit kommerziellen Interessen steht. Aber bei reinen OSS Projekten sind Faktoren mit im Spiel, die mit nichts im Kommerziellen oder Teilkommerziellen vergleichbar sind. Und diese Projekte machen den Grossteil der OSS aus.
Von daher sind Untersuchungen von Mythen in der OSS oftmals selber Mythen aufgesessen
Hugs 98 - Haskell Interpreter Implementation für viele Systeme (sogar Zaurus)
PyObjC - Home - Objective-C Bridge für Python
The HarvestMan WebCrawler Robot - Webcrawler in Python - z.B. für die eigene Suchmaschine
Second p0st: Repairing MetaKit databases - Script zur Reparatur von Metakit-Datenbanken
xsdb html index - kompakte und feature-volle Datenbank in Python
A garbage collector for C and C++ - Garbagecollection für C und C++
"AppleScript: The Definitive Guide" released
Hauptsächlich ein Merker für Jutta, das sie das Buch haben will
Bei The Macintosh News Network gibts den Originalartikel.
Atom-Raumschiff soll Leben finden
Hoffen wir mal das es nicht auch noch das erste abgestürzte Raumschiff und die erste Atomkatastrophe auf einem Jupitermond wird - bei der Erfolgsserie der NASA in letzter Zeit sollten die vielleicht doch lieber ungefährlicheres Gerät auf die Reise schicken ...
Bei Spiegel Online: Wissenschaft gibts den Originalartikel.
JSch -- Java Secure Channel - Java-Implementation von SSH2 mit X-Forwarding
LUFS-Python
Das richtige für den Hacker von heute: Dateisysteme für Linux direkt in Python schreiben. Ich könnte ja mal drüber nachdenken ob ich mein suckfs nicht mal auf LUFS-Python umschreiben sollte. Die jetzige Implementierung über dnotify jedenfalls hat einige seltsame Effekte und Raceconditions, die unter bestimmten Umständen die Datenbestände nicht mehr synchron sein lässt. Allerdings wäre eine LUFS-Python Implementierung dummerweise auch beim Lesen durch Python realisiert, und das wäre höchstwarscheinlich zu langsam für den Anwendungszweck von suckfs(Replikation von statischen Dateninhalten auf einem Zope-Cluster). Hier gibts den Originalartikel.
Neues Feature: Blogmarks
Ich habe den Python Desktop Server um ein weiteres Modul ergänzt: Blogmarks liefert ein Blog mit Minieinträgen. Die Idee dahinter ist es, einfach nur Links zu posten. Dazu dient ein Bookmarklet (ein bischen Javascript, das ein Fenster öffnet und eine URL anspringt), welches den aktuellen Link und den Titel des aktuellen Fensters an den Python Desktop Server übergibt und vom Benutzer noch Kategorien und eine kurze Beschreibung (wird als title-Tag am Linkelement abgelegt und damit bei Mouse-Over angezeigt) verlangt. Das ganze wird in kompakter Form in HTML umgewandelt und steht als Blog zur Verfügung, mit RSS-Feed und allem was dazugehört. Auf Dauer werde ich wohl noch weiter Features wie Caching der Originalseite (falls die mal offline geht) und eine Kategorienübersicht aller Links einbauen, aber erstmal starte ich so wie es jetzt ist. Mal schauen ob das nicht eine sinnvolle Alternative zu privaten Bookmarks ist.
Perthon -- Python to Perl Language Translation
Das interessanteste an diesem Projekt ist die Gegenüberstellung des Python und Perl Sources. Ich mag ja beide Sprachen, aber irgendwie finde ich bei dieser Gegenüberstellung das ich mich dafür das ich Perl auch mag eigentlich schämen müsste
ScummVM - Interpreter für LucasArts Spiele, gibts auch für den Zaurus
Smile von Satimage-software
Das klingt garnicht so schlecht. Ein AppleScript-Editor mit interaktiver Applescript-Shell, diversen Erweiterungen und vor allem einem Interfacebuilder. Und das ganze noch zum kostenlosen Download. Und die Beschreibung klingt so als wäre es für kleine Hacks durchaus eine Alternative zum deutlich dickeren (aber auch deutlich leistungsfähigeren) AppleScript Studio.
Tucholsky hat eben immer noch Recht
Nichts hat sich geändert, die gleichen alten Argumente, die gleichen falschen Schlüsse, die gleichen falschen Forderungen. Schon erschreckend wie Die Freie Wirtschaft immer noch wie Arsch auf Eimer passt, und das nach so vielen Jahrzehnten. Bei gnurps gibts den Originalartikel.
IronPython Benchmarks
Der Programmierer von JPython/Jython (einer Python-Implementierung für die Java Virtual Machine) ist anscheinend an einer Implementierung von Python für die .NET Common Language Runtime dran. Und erste Benchmarks sehen sehr gut aus, besser als erste andere Versuche die bei ActiveState gemacht wurden. Sieht so aus als ob in absehbarer Zeit Python Code sowohl innerhalb von Java-Applikationen als auch .NET Applikationen benutzt werden kann, neben der sowieso vorhandenen nativen Implementierung. Was ich sehr angenehm finde, weil ich damit meine derzeit favorisierte Programmiersprache auch in albernen Windows-Projekten mit denen wir in nächster Zeit zu tun haben weröden benutzen kann.
Im Java-Umfeld benutze ich Jython ja schon als angenehme Alternativsyntax, wenn ich mit irgendwelchen Fremdbibliotheken in Java arbeiten muss - Jython ist da wesentlich komfortabler (und die interaktive Umgebung ist der absolute Hit, wenn man mit fremden Libraries experimentieren muss, weil da mal wieder nicht ausreichend Dokumentation existiert!).
Medley Lisp
Eigentlich nur geblogt, damit ich es später mal wiederfinde. Medley Lisp ist der Nachfolger des Lisps, das auf den Xerox Lispmaschinen läuft. Auf meinen Lispmaschinen laufen zwei Releases: Koto Lisp und Lyric Lisp. Koto Lisp ist eine reine Interlisp-D Umgebung (übrigens hat Rainer Joswig das Einleitungshandbuch online gestellt, auch ist ein Film über die Benutzung von Interlisp-D online), wohingegend in Lyric Lisp noch zusätzlich eine Implementation von Common Lisp hinzugekommen ist. Medley Lisp ist der direkte Nachfolgerelease von Lyric Lisp, also stark Common Lisp zentrisch, wobei die Systembasis immer noch auf Interlisp-D aufbaut. Medley Lisp läuft nicht mehr auf Lispmaschinen, sondern wird über einen Emulator auf verschiedene Plattformen gebracht. Ich habe noch eine Version des Emulators für DOS, verkauft wird nur noch eine alte Solaris-Version und eine Linux-Version (für Intel-Prozessoren). Die Software hat eine lange Historie, die ersten Releases stammen aus dem Anfang der 80er Jahre, viel Code aus der Zeit findet sich immer noch im System (das ganze Interlisp-D eben). Ich schätze aber mal das die Implementation von TCP/IP in Interlisp unter der Emulatorversion nicht mehr genutzt wird, da wird wohl auf den systemeigenen TCP/IP Stack zugegriffen.
Bei mir zu Hause stehen noch immer zwei funktionsfähige Siemens-Nachbauten der Xerox 1186 Kisten und gut ein Meter Dokumentation. Faszinierend was in den Kisten schon alles drinsteckt und welche Leistung die damals schon hatten - und das obwohl der Prozessor nicht der allerschnellste ist. Der Prozessor selber hatte übrigens einen ladbaren Microcode, die Art des Befehlssatzes konnte also an das System (Smalltalk, Lisp oder Prolog) angepasst werden. Im Prinzip war das damals auch ein Emulator, nur in Hardware realisiert.
Slate Language Website
Ok, noch eine Programmiersprache. Aber die Mischung machts: Self, Common Lisp und Smalltalk als Inspirationen zu nehmen trifft schon ziemlich meinen Geschmack. Ich muss mir das ganze mal holen und ausprobieren. Sicherlich wird es nicht die kritische Masse bekommen die nötig wäre um damit ernsthaft was machen zu können - sowas hat in letzter Zeit gerade mal Ruby geschafft, und da wars schon eine kleine Sensation - aber interessant ist es allemall.
MkSQL - SQL für Metakit in Python
Könnte irgendwann mal interessant werden - eventuell könnte ich das in den Python Desktop Server reinmischen, so das man auf Datenbanken auch mit SQL zugreifen kann? Jedenfalls wäre es ein lohnenswertes Tool um Leuten den Einstieg in die Datenbank einfacher zu machen - Metakit ist ja eher ungewöhnlich.
What the heck is: A type
Eine Interessante Aufstellung darüber was überhaupt ein Typ ist und der verschiedenen Begriffe in dem Zusammenhang (static typing, type inference und was es noch so alles gibt) vom Programmierer der Perl 6 virtual Machine (Parrot). Ich finde es faszinierend zu sehen wie in der Perl6 Entwicklung immer mehr Elemente diskutiert werden und umgesetzt werden, die im Lisp-Bereich schon seit den 80ern als Standard betrachtet werden. Irgendwann wird die Mainstream-Programmierung mal endlich zur Lisp-Welt aufschließen
Bei Squawks of the Parrot gibts den Originalartikel.
The Early History of Smalltalk
Stand schon überall sonst, aber als alter Smalltalker muss ich es natürlich auch bloggen.
Wysiwyg-Pionier Simonyi will das Programmieren revolutionieren
Reitet der immer noch auf seinen albernen Ideen rum? Mitlerweile müsste ihm doch mal irgendwann klar geworden sein, das es nur Hirngespinste sind. Programmierung ist ein kreativer Prozess der durch die Ausdrucksmöglichkeit in der Sprache in der man programmiert gravierend mitbestimmt wird. Niemand würde von einem Dichter verlangen seine Kunst im Sprachschatz der Bildzeitung auszuleben, dabei dann noch absolut feste Versmaße einzuhalten und das ganze dann noch mit primitiven Werkzeugen zu schreiben.
Solange die Softwareentwicklung an Primitivsprachen wie C++, Visual Basic oder Java kleben bleibt, wird sich das Problem nicht sinnvoll lösen lassen - wer low-level Sprachen zur Verfügung hat, wird auch immer low-level denken.
Die Lösungen für diese Problematik sind schon seit den 80ern verfügbar, wird Zeit das die Softwarebranche da mal genauer hinguckt ...
Bei heise online news gibts den Originalartikel.
AROS: Amiga® Research Operating System
Mal was für die Amiga-User: ein Open Source System mit dem Ziel kompatibel zum AmigaOS zu sein. Und die hier sind schon richtig weit. Ok, für Amiga-Fans vielleicht ein alter Hut, mir wars aber neu. Mein Amiga ist aber auch im Laufe meines Besitzes nur vielleicht eine Handvoll Male gebootet worden
Python und AppleScript
Garnicht so uncool. Für Perl gabs das ja auch mit den Mac::OSA Modulen. Sehr praktisch das ganze, gerade wenn man sowieso ein Python Script baut, welches nur ein paar Funktionen der Anwendungen braucht. Allerdings bei komplexeren Sachen dann doch oft recht umständlich, speziell wenn Mediadatentypen verwendet werden, für die es einfach im Python keine brauchbaren Gegenstücke gibt.
Bei Der Schockwellenreiter gibts den Originalartikel.
High Performance Computing for Mac OS X
Was für die Numbercruncher unter den OS X Fans. Compiler und Werkzeuge speziell für G4 und G5 kompiliert und zusammengestellt. Alles was das Herz eines Zahlenfressers begehrt
You call that a Monad? This HEREs a Monad.... And a Shell.
Funktionale Shell? Hmm. Interessant - die Shellsprache ist eine funktionale Sprache und bietet typische Kombinatoren zur Verbindung von Systeminformationen, Dateien und Kommandos an. Abgedreht, aber interessant
Bei Lambda the Ultimate fand ich den den Originalartikel.
Rebel With A Cause
Hier berichtet jemand wie er mit einem Apple XServe, OpenMCL(der freien Version von Macintosh Common Lisp) und dem Portable AllegroServe eine Webapplikation aufgebaut hat und was diese so umfasst. Ebenfalls eingesetzt wurde dabei ein selbstgeschriebenes Framework zur Webapplikationserstellung mit Common Lisp - ich bin mal gespannt, ob das auch freigegeben wird. Vielleicht krieg ich doch mal irgendwann einen CLDS zusammen Hier gibts den Originalartikel.
It had to start sometime...
Na toll. Jetzt wird der Python Package Index gespammed - in diesem Fall hat ein Finanzberater sich selbst als Paket an PyPi gemeldet - der Nachteil einer offenen Architektur. Vielleicht wärs doch gut wenn Projekte erst einen Projekt-Key anfordern müssen und nur mit diesem einen Update schicken können - hätte Spam von vornherein vermieden, hätte aber von vornherein mehr Arbeit benötigt, da diese Keys ja manuell freigegeben werden müssen, damit das ganze Sinn macht. Mal schauen wie PyPi das Problem angeht.
Bei Artima Python Buzz fand ich den den Originalartikel.
Home of the 4tH compiler
Ich muss mal wieder meiner - alten und leicht perversen - Neigung zu Forth frönen und hier einen Link auf 4th - einen standalone Forth compiler - posten. So ein Standalone Compiler ist ja was nettes, aber widerspricht eigentlich komplett der Natur von Forth, das ja eigentlich auf einem interaktiven System aufsetzt. Andererseits ist aber ein Compiler, der wirklich minimale Programme erzeugt, doch was ganz nettes. Für kleine Systeme durchaus interessant. Die Website sieht übrigens so aus als wollte sie den ersten Preis für hässlichste Website aller Zeiten belegen Hier gibts den Originalartikel.
Wired News: Anti-Copy Bill Slams Coders
Ein neuer Vorstoss des amerikanischen Rechtssystems jeglichen Kontakt mit der Realität zu verlassen. Nach einer strengen Auslegung der Gesetzesvorlage wäre es dann illegal jeglichen Code zu verbreiten, der nicht Copyprotection-Code enthält, der von einer zentralen Stelle freigegeben ist. Irgendwie hatten wir sowas schon mal mit den Exportbeschränkungen auf Kryptografische Produkte - das Ergebnis war, das ausserhalb der USA die interessanten Projekte entstanden ...
Unsignierte Java-Applets brechen aus Sandbox aus[Update]
Wow, das ist heftig. Durchgriffe durch die Sandbox hat man ja schon ab und an gezeigt bekommen, aber das ein unsigniertes Java-Applet auf die Floppy zugreifen kann, ist definitiv ein Zeichen von Unsicherheit die auch kritische Ausmaße annehmen kann. Das ist schon ein recht heftiger Schlag für die Sicherheit von Java. Aber es ist letzten Endes nicht verwunderlich: auch wenn die virtuelle Maschine in der Spezifikation davon ausgeht das die Sandbox sicher ist, dahinter stecken eben immer Implementationen, die durchaus Fehler auf Java-Ebene oder sogar auf realer Maschinenebene (in der Implementierung der virtuellen Maschine selber) haben können.
Und das der Rechner nach dem Applet dann rebootet werden musste, und das ein Zugriff auf physikalische Medien möglich ist, deutet darauf hin, das hier ein so tiefgehendes Implementationsproblem vorliegt.
Techniken werden eben nicht einfach nur durch Spezifikation und Behauptung sicher ...
Bei heise online news gibts den Originalartikel.
Atom API
Was mich an dem Artikel von Mark Pilgrim stört, hab ich hier geschrieben. Da ist einiges im Artikel nicht so wie ich es mir von einer fachlichen Erläuterung des Atom-API auf http://xml.com/ wünschen würde. Schade, aber so wird es wohl eher zur weiteren Spaltung beitragen als zur gegenseitigen Akzeptanz der beiden API-Lager. Bei Der Schockwellenreiter gibts den Originalartikel.
Microsoft erhält Patent für Cookies
Und wieder ein Patent das die Welt absolut nicht braucht.
Bei heise online news gibts den Originalartikel.
W3C verabschiedet neue Web-Formulare
Meine Gefühle bei sowas sind zwiespältig. Natürlich sind gute Standards hilfreich - vor allem wenn dadurch das Endgerät, der Browser, mächtiger in der Funktion wird und neue, effiziente Benutzeroberfläche auf der Basis implementiert werden können.
Andererseits gibt es aber durch die Vielzahl an Standards und Substandards so viele technischer Overhead, das es für normale Menschen schwerer wird sich hineinzufinden. Und ganz egal wie wir zu dem Ergebnis an invaliden und teilweise wild zusammengehackten HTML-Halden stehen, genau dieser leichte Zugang und die recht tolerante Implementierung in den Browsern hat überhaupt dazu geführt das HTML und das Web so abheben konnte.
Es ist eben für sehr viel mehr Menschen zugänglich dieses Format zu produzieren - notfalls nimmt man eine andere Site, guckt in den Source und macht es ähnlich. Viele sind so angefangen, viele kommen nicht über das Klauen hinaus - aber das ist egal, sie sind präsent.
Klar, Designer wenden sich mit Grausen, HTML-Standard-Puristen auch, genauso wie Softwareentwickler. Ich selber kriege bei manchem Output Schreikrämpfe, wenn ich das im Web mir angucke. Aber es bleibt der Fakt, das mit komplizierteren Techniken diese Menschen garnicht da wären.
Wäre das Web dadurch besser? Ist es tatsächlich sinnvoll sich durch technische Hürden abzuschotten und das Web elitärer zu machen? Oder ist gerade das wild gehackte und teilweise wirklich grausige genau das was das Web zu dem macht, was es ist: ein beinahe Volksmedium?
Die neuen Standards vom W3C werden immer technischer, immer komplexer. Und setzen damit die Hürde für den Einstieg höher. Klar, HTML 4 existiert noch und wird sicher noch lange unterstützt - aber es wird sozusagen die verdummte Version sein. Der Profi wird mit XHTML und XForms um sich werfen, der Amateur mit schmuddeligem HTML 4.
Ich weiss nicht, was mir mehr Spass machen würde. Ich fürchte aber, es wäre das schmuddelige HTML 4 ...
Bei heise online news gibts den Originalartikel.
Loadbalancer in Python
Besonderheit dieses Load-Balancers (neben der Tatsache das er komplett in Python geschrieben ist): er benutzt keine mehrfachen Prozesse oder Threads, statt dessen benutzt er asynchrones I/O. Dadurch werden viele Verbindungen gleichzeitig in nur einem Thread abgewickelt, wodurch das System in der Last viel niedriger ist als klassische Balancer, die pro Verbindung einen Prozess oder Thread starten. Benutzt wird entweder Twisted oder das in Python mitgelieferte asyncore-Modul.Und rasend schnell ist das ganze auch - z.B. wird die gleiche Geschichte im Medusa benutzt, einem Webserver in Python, der bei Auslieferungen von statischen HTML-Seiten durchaus an die Leistungen eines Apache herankommt. Hier gibts den Originalartikel.
Twiki API
Wow. Eine API, mit der man per VoodooPad ein Wiki editieren kann. Ich glaube ich werde da mal tiefer reingucken, das könnte interessant sein für den PyDS. VoodooPad könnte dann als Frontend benutzt werden, ich müsste nur alle wichtigen Objekte über dieses API erreichbar machen. Und für Twiki gibts auch schon eine API. Irgendwas muss man mit sowas doch anfangen können ...
Technische Inkompetenz oder Wunschdenken?
Als ich den verlinkten Artikel gelesen habe musste ich irgendwie grinsen. Dann aber überwog das Kopfschütteln ob soviel Unfug. Der Artikel enthält so viele falsche Ideen und Interpretationen von Open Source, das man sich nur wundern kann wie so viel Fehler in einen so kurzen Artikel passen. Der gröbste Fehler ist wohl die wieder mal irrige Annahme das Open Source ein Business Modell bräuchte um zu funktionieren. Absurde Vorstellung - nach einem Business Model in der Entstehung und Verbreitung von Open Source zu suchen ist genauso sinnvoll wie an der Wertschöpfungskette bei Weblogs zu ziehen. Natürlich gibt es Firmen die ein Business Modell auf der Existenz von Open Source aufbauen - ähnliches gibts ja auch bei Weblogs. Aber das Business Modell ist für den eigentlichen Motor absolut irrelevant.
Ich habe aber daraufhin mal darüber nachgedacht, was es denn wirklich bedeuten würde, wenn SCO gewinnen würde (was ausser der Autorin des Artikels und vielleicht Darl McBride wohl niemand wirklich glaubt). Was würde das für Open Source bedeuten? Nicht viel, die fraglichen Sourcen müssten früher oder später benannt werden und würden einfach aus dem Linux Kernel rausfliegen. Die Version 2.2 ist nach SCO-eigenen Aussagen sauber, die hat auch schon funktioniert, schlimmstenfalls würden Subsysteme auf den Stand von 2.2 zurückfallen. Nicht fatal, allenfalls nervig.
Was würde passieren, wenn der Linux Kernel von SCO verboten würde? Würde das nicht Open Source vernichten? Abgesehen davon das diese Vorstellung ziemlich absurd ist liegt hier der grösste Fehler in dem Artikel - ein Fehler allerdings, der in den Medien nahezu durchgängig gemacht wird. Open Source ist nicht Linux - Linux ist nur eine (sogar relativ kleine, wenn auch bedeutende) Komponente des gesamten Open Source Feldes. Linux ist ein Kernel - und damit zwar wichtig, aber eben nur eine mögliche Komponenten, die leicht ersetzt werden kann. Im Intel-Prozessor-Umfeld könnte man relativ schnell einfach den FreeBSD-Kernel (bedingt durch seine Kompatibilitätsfunktionen für das Linux-API) anstelle des originären Linux-Kernels verwenden. Bei anderen Prozessoren nimmt man einfach NetBSD - viele Open Source ist sowieso nicht auf Linux angewiesen, sondern läuft auf fast allem was Unix-ähnlich ist.
Und was passiert, wenn Firmen aufgrund des Verfahrens Open Source nicht mehr einsetzen wollen? Bitte was? Firmen sollen Abstand davon nehmen etwas einzusetzen das sie umsonst bekommen können, nur weil es in einem Randgebiet ein Gerichtsverfahren gab? Warum sollten Firmen das tun? Wie viele Firmen setzen Raubkopien ein, wohl wissend das das illegal ist, wohl wissend was das bedeuten könnte, weil sie das Geld nicht ausgeben wollen? Solange Geiz existiert, wird Open Source auch kommerziellen Einsatz finden. Und Geiz wird so lange existieren, wie wir eine Marktwirtschaft haben. Also noch verdammt lange.
Aber bestimmt werden Firmen ihre eigenen Sachen nicht mehr unter Open Source Lizenzen stellen? Warum nicht? Es ist eine recht günstige Methode für viele Firmen kostenlose Werbung zu bekommen. Ausserdem bauen diese Firmen auf das Projektgeschäft, weniger auf die Softwareerstellung. Daran ändert sich durch das SCO-Verfahren garnichts. Und selbst wenn das weniger wird - viele Open Source ist von Privatpersonen erstellt, an Unis entstanden oder in lockeren Entwicklergruppen erstellt worden. Firmen haben zwar Sachen beigetragen - aber in der Regel nur genau die, an denen sie selber für ihre eigenen Geschäftsfelder Interesse hatten. Wenn Firmen also nicht mehr zur Open Source beitragen, schaden sie sich primär selber. Open Source entsteht in der Regel dadurch, das jemand ein Problem hat, das ihn nervt - und beginnt eine Lösung dazu zu schaffen. Daran soll sich plötzlich was ändern?
Was mich am meisten daran nervt was in der Presse über Open Source geschrieben wird, ist die völlige Borniertheit der Autoren über die Fakten der Open Source - das es weitaus mehr als Linux gibt, das die auf Linux aufbauenden Firmen absolut nicht zwingend notwendig für den Bestand von Open Source sind und das die Motivation von Open Source absolut garnichts mit Business Modellen zu tun hat: Open Source ist die Begeisterung von Menschen etwas zu schaffen, das andere Menschen genauso begeistert anwenden. Diese Motivation, der Kern der Open Source, kann weder durch Gerichtsverfahren noch durch Verbote gestoppt werden. Open Source würde selbst dann weiter existieren, wenn es per Gesetz verboten würde - dann eben im Untergrund. Denn schöpferische Leistungen von Menschen lassen sich nicht verbieten oder unterdrücken - das gilt in der Softwarewelt genauso wie bei Schriftstellern, Malern oder Musikern.
Open Source wird - egal was die Vertreter der proprietären Software versuchen zu unternehmen - weiterexistieren. Stellt euch darauf ein. Es gibt kein Zurück.