40 Jahre Unix - was war der grösste Reinfall

[soul_rebel]

»Well, it's true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it's a penance.« – Richard Stallman

(Nun, es trifft zu, dass vi vi vi der Editor des Teufels ist, aber einen freien Vi zu nutzen ist keine Sünde, sondern Buße.)

Wobei das Ganze natürlich scherzhaft gemeint ist und Beast/Teufel eine Anspielung auf BSD. Insofern finde ich das ganz lustig, überhaupt das mit der Church of Emacs ist ja eigentlich eine Parodie auf Religion und wahrscheinlich auch auf fast-religiöses Verhalten bestimmter Software-Anhänger, wie halt dem Emacs- und vi-Lagern...

 

[danlei]

http://www.youtube.com/watch?v=S76pHIYx3ik

 

[Tron]

Wobei das Ganze natürlich scherzhaft gemeint ist und Beast/Teufel eine Anspielung auf BSD.

Äh, nein

 

[danlei]

Oh, hat das tatsächlich jemand nicht verstanden?

 

[lme]

@mawei: DeviceKit soll HAL ablösen: http://www.pro-linux.de/news/2008/12692.html

 

[Yamagi]

Was konkret meinst Du damit? Wie wurde X.org sabotiert und zerstört? Und was kommt da in welcher Form zurückgeflogen?

Ausserdem gibt es immer noch XFree86, das auch kontinuierlich weiterentwickelt wird.

Naja, X.org war ein recht ambitionierter Fork von XFree86, der nicht zuletzt auf dem kindischen Lizenzstreit entstanden war. Am Anfang wollte man einfach das besser machen, was XFree86 über Jahre nie hinbekommen hatte. Und das machte man auch. Die ersten X11R6-Releases des X.org-Projektes waren konsequent fehlerbereinigte Versionen des alten XFree86 und gehören nach wie vor zu den besten X11-Versionen, die jemals erstellt wurden. Nur da man das Projekt neuen Entwicklern öffnete, kamen gleich haufenweise junge Entwickler an und setzten ihren Kopf durch. Das führte dann zu den bekannten Problemen des bis heute nicht wirklich funktionierenden X11R7. Das man den Code modularisierte mochte noch sinnvoll gewesen sein, aber das man Auotbreak nutzte, war schon der erste Schlag in das Gesicht der Systeme ohne GNU-Userland. Dann musste man ja unbedingt, ohne erst einmal die unteren Layer aufgeräumt und deren Probleme beseitigt zu haben, ganz viel anderen Kram inkonsequent reinfummeln. Da ist die Automagie in Form des oben schon diskutieren HAL, da ist evdev. Beides läuft unter Linux nur so halb, auf anderen Plattformen ist es ein Krampf, über den man nur heulen kann. HAL will nach wie vor kaum, evdev ist schlicht unportabel. Dann musste man die unsegliche Eyecandy Acceleration Architecture einführen, die neuerding nur noch EXA heißt, da der name ihnen selbst zu peinlich wurde. Wirklich funktionieren tut sie auch nach fast 3 Jahren nur mit wenigen, praktisch neu erstellten Treibern. Nur das alte XAA kann man mit alten Treibern auch kaum mehr nutzen, da es schlicht kaputt ist. Lahm, leckt Speicher, neigt zu Artefakten und Abstürzen. Kaum ist nun Licht am Ende des Tunnels sichtbar, soll EXA schon wieder sterben und durch UXA ersetzt werden... Dann ist da die Katastrophe der XLib, von der es inzwischen eineinhalb Stück gibt. libxcb als Reimplementierung, die nur leider, leider inkompatibel ist. Wodurch libX11 weiterexistieren muss, als ressourcenfressender Wrapper. Und nun überlegen die Herren XCore zu ändern, was so ziemlich jede Anwendung auf dem Planeten brechen würde. Das es viele Programme gibt, die man nicht rekompilieren kann, da sie nicht Opensource sind, wird dabei vergessen... Dann muss man nun neuerdings ja unbedingt größere teile von X11 in den Kernel schieben. An sich nicht einmal doof, wenn man es richtig machen würde. Aber stattdessen hat man da inzwischen 3(!) Kernelspeichermanager, die zueinander inkompatibel sind und hart gegen Linux gecodet sind. Das man damit vielleicht X.org flackerfrei starten kann, aber so ziemlich jeden anderen Kernel abwürgt, ist den Herren egal. Dazu kommt der "Brainrain". In den letzten Jahren haben weitgehend unbemerkt von der Öffentlichkeit sich viele alte Hasen des X11-Projektes zurückgezogen, frustriert, vergrault. Oder sie konzentrieren sich auf sehr kleine Gebiete. Da ist einfach viel Know How verloren gegangen. Oder anders gesagt, in dem krankhaften Verlangen unbedingt ein GDI-Artiges Darstellungssystem für das was Linuxdistributoren als moderne Distro sehen zu frickeln hat man die eigene Eleganz und Stärke völlig aus den Augen verloren und das Projekt gegen die Wand geklatscht. Aber seitdem ausgerechnet Ubuntu im LTS-Release X.org um die Ohren geflogen ist, in Form des zerfrickelten Inteltreibers, ist da wenigstens Tendentiell wieder ein Umdenken zu erkennen. Das Xfree86 "weiterentwickelt" wird ist da keine Hilfe, da es in Sachen moderner Treiber einfach inkompatibel geworden ist. Mein letzter Stand ist, dass die neuen Radeon-Treiber, Nouveau und die aktuellen Intel dort einfach nicht laufen.

Das mit zurückgeflogen war so gemeint, dass wir uns hier jahrelang ungeniert und ohne nachzudenken bei für Linux entwickelter Software bedient haben. X.org ist da ja nur die Spitze des Eisbergs, FreeBSD hat das größe Softwarerepo aller freien Betriebssysteme. Nur das immer mehr dieser Software qualitativ nachlässt, unportabler wird, uns den Boden unter den Füßen wegzieht. Man denke nur an Gnome, was imo einie einzige Katastrophe ist. An irgendwelche Anwendungen, die unbedingt das "gute" Pulseaudio verlangen. Etc.

 

[bofh_hannibal]

Naja, X.org war ein recht ambitionierter Fork von XFree86, der nicht zuletzt auf dem kindischen Lizenzstreit entstanden war. Am Anfang wollte man einfach das besser machen, was XFree86 über Jahre nie hinbekommen hatte. Und das machte man auch. Die ersten X11R6-Releases des X.org-Projektes waren konsequent fehlerbereinigte Versionen des alten XFree86 und gehören nach wie vor zu den besten X11-Versionen, die jemals erstellt wurden. Nur da man das Projekt neuen Entwicklern öffnete, kamen gleich haufenweise junge Entwickler an und setzten ihren Kopf durch. Das führte dann zu den bekannten Problemen des bis heute nicht wirklich funktionierenden X11R7. Das man den Code modularisierte mochte noch sinnvoll gewesen sein, aber das man Auotbreak nutzte, war schon der erste Schlag in das Gesicht der Systeme ohne GNU-Userland. Dann musste man ja unbedingt, ohne erst einmal die unteren Layer aufgeräumt und deren Probleme beseitigt zu haben, ganz viel anderen Kram inkonsequent reinfummeln. Da ist die Automagie in Form des oben schon diskutieren HAL, da ist evdev. Beides läuft unter Linux nur so halb, auf anderen Plattformen ist es ein Krampf, über den man nur heulen kann. HAL will nach wie vor kaum, evdev ist schlicht unportabel. Dann musste man die unsegliche Eyecandy Acceleration Architecture einführen, die neuerding nur noch EXA heißt, da der name ihnen selbst zu peinlich wurde. Wirklich funktionieren tut sie auch nach fast 3 Jahren nur mit wenigen, praktisch neu erstellten Treibern. Nur das alte XAA kann man mit alten Treibern auch kaum mehr nutzen, da es schlicht kaputt ist. Lahm, leckt Speicher, neigt zu Artefakten und Abstürzen. Kaum ist nun Licht am Ende des Tunnels sichtbar, soll EXA schon wieder sterben und durch UXA ersetzt werden... Dann ist da die Katastrophe der XLib, von der es inzwischen eineinhalb Stück gibt. libxcb als Reimplementierung, die nur leider, leider inkompatibel ist. Wodurch libX11 weiterexistieren muss, als ressourcenfressender Wrapper. Und nun überlegen die Herren XCore zu ändern, was so ziemlich jede Anwendung auf dem Planeten brechen würde. Das es viele Programme gibt, die man nicht rekompilieren kann, da sie nicht Opensource sind, wird dabei vergessen... Dann muss man nun neuerdings ja unbedingt größere teile von X11 in den Kernel schieben. An sich nicht einmal doof, wenn man es richtig machen würde. Aber stattdessen hat man da inzwischen 3(!) Kernelspeichermanager, die zueinander inkompatibel sind und hart gegen Linux gecodet sind. Das man damit vielleicht X.org flackerfrei starten kann, aber so ziemlich jeden anderen Kernel abwürgt, ist den Herren egal. Dazu kommt der "Brainrain". In den letzten Jahren haben weitgehend unbemerkt von der Öffentlichkeit sich viele alte Hasen des X11-Projektes zurückgezogen, frustriert, vergrault. Oder sie konzentrieren sich auf sehr kleine Gebiete. Da ist einfach viel Know How verloren gegangen. Oder anders gesagt, in dem krankhaften Verlangen unbedingt ein GDI-Artiges Darstellungssystem für das was Linuxdistributoren als moderne Distro sehen zu frickeln hat man die eigene Eleganz und Stärke völlig aus den Augen verloren und das Projekt gegen die Wand geklatscht. Aber seitdem ausgerechnet Ubuntu im LTS-Release X.org um die Ohren geflogen ist, in Form des zerfrickelten Inteltreibers, ist da wenigstens Tendentiell wieder ein Umdenken zu erkennen. Das Xfree86 "weiterentwickelt" wird ist da keine Hilfe, da es in Sachen moderner Treiber einfach inkompatibel geworden ist. Mein letzter Stand ist, dass die neuen Radeon-Treiber, Nouveau und die aktuellen Intel dort einfach nicht laufen.

Das mit zurückgeflogen war so gemeint, dass wir uns hier jahrelang ungeniert und ohne nachzudenken bei für Linux entwickelter Software bedient haben. X.org ist da ja nur die Spitze des Eisbergs, FreeBSD hat das größe Softwarerepo aller freien Betriebssysteme. Nur das immer mehr dieser Software qualitativ nachlässt, unportabler wird, uns den Boden unter den Füßen wegzieht. Man denke nur an Gnome, was imo einie einzige Katastrophe ist. An irgendwelche Anwendungen, die unbedingt das "gute" Pulseaudio verlangen. Etc.

ACK :-)

Ich finde es leider auch sehr traurig von den ganzen Linux Entwicklern wie arrogant sie geworden sind. Jahre lang auf Microsoft schimpfen zwecks Closed-Source, und heute machen sie fast schon das selbe. Andere Kernel sind den Typen scheiß egal, hauptsache der Dreck läuft irgendwie unter Linux.

Und hauptsache die Linuxer können jede Hardware unterstützen, egal welche Linzenz vorliegt.
Ich nenne sowas HURE. Mit allen Herstellern schlafen, nur damit man den Treiber bekommt.
Das ist nicht der gedanke von OpenSource und Unix.

Ich werd jetzt auch Arroganter BSD'ler, die Frickler kotzen mich alle an mit ihrem scheiß.
Am besten wir passen den Xorg auch an BSD an. Mit allen Features die BSD bietet, und nicht dieses Verhurte linux.

Mfg,

 

[Athaba]

@Athaba: Dein Hader mit C erinnert mich irgendwie hier dran: http://blog.schalanda.name/uploads/20081021-programmerhierarchyg.jpg *SCNR*

Ja, genau! Ich finde, dass Perl und Ruby überlegene Sprachen sind
Allerdings ist Ruby eigentlich nur Smalltalk im Perlgewand.

Das Diagramm ist echt cool, nur gefällt mir die Notiz nicht so, weil ich einam eine Webapplikationen in Assembly geschrieben habe.

Aber den Teil mit Ajax kapier ich nicht. Ada (und Eiffel) sollte man IMO an die Spitze setzen.

Athaba, der gerade Eiffel unter die Lupe nimmt
Sieht mir nach OOP-Ada aus

 

[danlei]

Allerdings ist Ruby eigentlich nur Smalltalk im Perlgewand.

Naja. Zwar bedient sich Ruby einiger Konzepte Smalltalks, aber »MatzLisp« als »Smalltalk im Perlgewand« zu beschreiben, finde ich dann doch etwas gewagt. Von anderen Unterschieden abgesehen ist Smalltalk homoikonisch und konsequent objektorientiert (macht z.b. nicht vor Verzweigungen halt).

Des Weiteren umfasst Smalltalk – von nicht unbedingt überzeugenden »Exoten« wie GNU Smalltalk abgesehen – nicht nur die Sprache an sich, sondern auch die damit verbundene graphische (zur Laufzeit veränderbare) Umgebung, sowie generell das Arbeiten in einem Image. Dem steht der unixtypische dateiorientierte Ansatz Rubys kontrastierend gegenüber.

Alles in Allem ist es schon ein riesengroßer Unterschied.

 

[Athaba]

Naja. Zwar bedient sich Ruby einiger Konzepte Smalltalks, aber »MatzLisp« als »Smalltalk im Perlgewand« zu beschreiben, finde ich dann doch etwas gewagt. Von anderen Unterschieden abgesehen ist Smalltalk homoikonisch und konsequent objektorientiert (macht z.b. nicht vor Verzweigungen halt).

Des Weiteren umfasst Smalltalk – von nicht unbedingt überzeugenden »Exoten« wie GNU Smalltalk abgesehen – nicht nur die Sprache an sich, sondern auch die damit verbundene graphische (zur Laufzeit veränderbare) Umgebung, sowie generell das Arbeiten in einem Image. Dem steht der unixtypische dateiorientierte Ansatz Rubys kontrastierend gegenüber.

Alles in Allem ist es schon ein riesengroßer Unterschied.

Ich sagte ja uch nicht, dass Ruby Smalltalk ist.

Smalltalk ist vor allem DIE objektorientierte Sprache. Sie ist kaum vergleichbar mit dem was in C++ oder Java an C rangepatzt wurde. Ich weiß, was Smalltalk noch alles ist (ich beschäftige mich schon lang genug mit Smalltalk (vor allem Sqeak)), aber es ging mir vor allem darum. Außerdem sieht man da für gewöhnlich auch schönes MVC, was ja der Hauptgrund für die Verwendung von Ruby (bzw. Rails) ist.

Auch Ruby schreibt objektorientiere Programmierung (und MVC in Rails) groß. Du tust dir sicher leichter von Ruby zu Smalltalk und umgekehrt zu wechseln, als bei den meisten anderen breit verwendeten Sprachen. Deshalb Smalltalk.

Ich spreche höufig von Perl, Python, PHP und Ruby in einem Atemzug, weil sie sehr vieles teilen. Sie sind (standardmäßig) dynamisch und werden sehr häufig in Skripten (u.a. als Shellalternative) und Webapplikationen genutzt. Sie haben allesamt relativ große Standardbibliotheken und viele Keywords (im Gegendatz zu Smalltalk).

Vielleicht hätte ich eher Sagen sollen, dass Ruby eine experimentelle Kreuzung von einigen Smalltalk-Konzepten und Skriptsprachen, wie Perl ist. Es ging mir um den "Alles ist ein Objekt"-Ansatz, der in Smalltalk (und Ruby) wesentlich stärker ausgeprägt ist, als zum Beispiel bei Python.

Aber cool, dass du offensichtlich Smalltalk kennst. Nutzt du es auch?
Ich glaube häufig, dass es nur von Leuten, die Computersprachen erforschen oder lehren genutzt wird. Das war auch ein Grund, warum ich sie angesprochen habe. Viele Leute sagen, Ruby ist cool, aber hat noch ein paar Kinderkrankheiten und dann frage ich mich, warum man nicht einfach Smalltalk nimmt. Ruby ist ja vor allem deshalb so berühmt, weil es sich einige Ideen von Smalltalk nahm und das ganze so verpackt hat, dass es auch ein C(++/Java)/PHP/Python/Perl/...-Programmierer sofort versteht.

Ich glaube die Anderen Sprachen[1] sind vor allem deshalb nicht so populär, weil sie nicht wie C aussehen. Pseudocode ist immer im C-Stil geschrieben. Ich meine den Programmaufbau. Klar, man kann Klammern verwenden oder mit then, end, ... arbeiten. Man kann das Semikolon nutzen und Sigils können vorhanden sein und verschiedenste Bedeutungen haben. Auch die Typisierung macht nicht viele Unterschiede.

Zur Einsatzerklärung von Smalltalk und Ruby für Leute, die eine der Sprachen nicht kennen reicht es IMO. Es lässt zwar auch vieles ausgeklammert, aber nur weil das eigentlich zwei verschiedene Sprachen sind.

Wenn es mal darum geht, dass man sich Objekte wirklich als Objekte zu sehen und nicht nur als einen Haufen von Variablen und Funktionen und Kontrollstrukturen auf das reduziert werden, was sie wirklich sind, dann meint so mancher Programmierer, dass ihm der Boden unter den Füßen weggezogen wird. Selbst, wenn man das ganze sehr schnell lernen und effektiv nutzen kann.

Das ganze ist jetzt etwas zusammengekürzt, weil es hier ja eigentlich nicht um Programmiersprachen geht. Wenn jemand antworten will, dann bitte per PM (und schreib mir mal einen besseren Vergleich ). Ich lass das jetzt mal hier, damit erklärt ist, was ich mit Smalltalk im Perlgewand gemeint hab und weil ich gern mit anderen Smalltalk-Fans plaudern würde. Ich fühle mich ein wenig isoliert und auch, wenn ich denke das wichtigste verstanden zu haben noch ein Neuling bin. Mir fehlt es an Stoff zum implementieren. Alles was ich mache sind Algorithmen und Snippets, damit ich sie habe, wenn ich sie mal brauche.

[1] also andere, als C(++), Java, Perl, Python, Ruby,...

 

[danlei]

Da Du weitere Antworten per PN wünschst, ich aber der Meinung bin, dass in der Öffentlichkeit beendet werden sollte, was in der Öffentlichkeit begonnen wurde, hier nur eine knappe Antwort:

Mit dem, was Du im letzten Artikel gesagt hast bin ich soweit einverstanden. Kritisiert habe ich Deinen vorletzten Artikel, weil er bei Leuten, die sich nicht eingehender mit der Materie beschäftigt haben, unter Umständen der Eindruck vermitteln könnte, dass Smalltalk im Prinzip eine Art Ruby mit etwas anderer Syntax sei – was natürlich so nicht stimmen würde.

Zur Frage, ob ich denn Smalltalk nutze: Ja, seit ein paar Jahren experimentiere ich des Öfteren in Squeak (bzw. mittlerweile oft auch Pharo). Was ich besonders an Smalltalk (und hier insbesondere an Squeak/Pharo) schätze ist, wie leicht es gemacht wird, im laufenden Image zu experimentieren, Dinge live zu ändern, sich durch eine riesige Sammlung teilweise alten (nicht im negativen Sinne) Codes zu wühlen und immer wieder ein Sahnestückchen zu finden. Die gesamte Umgebung ist schlichtweg genial; vorausgesetzt man kann sich vom (für Viele gewohnten, wenn nicht sogar einzig bekannten) Batch-orientierten Ansatz lösen. (Obwohl ich v.A. Squeak nun schon seit einer Zeit kenne, bin ich z.B. nach wie vor von Kleinigkeiten wie dem Method Finder begeistert)

Ich wünschte, es gäbe solche (freien) Umgebungen auch für CL, meine eigentliche Sprache der Wahl, aber zur Not kann man ja immer Genera oder Medley in ner VM laufen lassen.