Nach einem Jahr Linux

Hi,

benutze selber seit 13 Jahren Linux, teilweise sogar als primäres System auf dem Rechner.
AM Anfang habe ich es noch groß in der Bekanntschaft angepriesen. Dachte, noch 1 Jahr und es ist "reif" für die Masse.
Die Jahre vergingen, nichts passierte. Klar sieht KDE 4 wirklich schön aus. Sobald man aber ernsthaft versucht damit zu arbeiten. Ein Graus. Fehlende Funktionalitäten, komplette Abtürze der GUI. Aufgebläht und Träge. Als wieder zurück zu KDE3. Schnell, schlank alles da.

Ach ich könnt mich seitenweise hier auslassen.

Mittlerweile ist meine Empfehlung:
Windows XP/Vista als Desktopsystem und Spielesystem sowie für jeden der kreativ mit dem Rechner etwas erschaffen will.
Linux ist ein UNIX Derivat. Nichts anderes ! Und UNIX wurde schon immer auf SERVERN eingesezt. Hier wird auf der Konsole an Dateien konfiguriert.
Gerade bei der Virtualisierung von mehreren Servern auf einem Host ist Linux momentan das Server OS der Wahl.

Ich kenne viele die vor 10 Jahren mit Linux angefangen haben und jetzt alle bei OSX gelandet sind. Hier stimmt einfach alles. Komfort und alle wichtigen Professinellen Programme sind verfügbar. Ausserdem sind die MAC Rechner einfach nur schön. (Das Air book *träum*) (Okay dafür auch teuer!)

Also, jeder der jammert über Linux, ihr habt Recht.
Linux ist kein Desktop/Benutzer Betriebsystem !

Argumente gegen Linux auf dem Desktop sind:
- komplizierte Bedienung und Konfiguration
- keine API Kompatibilität zu älteren Linux Systemen
- keine komerziellen Spiele
- keine professionellen komerziellen Anwendungen
- kein vereinheitlichtes Linux Desktop für alle Linux Distributionen
- kein Plug&Play von neuer Hardware, im schlimmsten Fall Treiber über Konsole selber per Hand nachinstallieren.
- Es kostet genausoviel wie Windows und bietet weniger komfort. (Suse 11.1 - 80 Euro)
- Das System wird duch ständige Updates instabil.
- Mal eben ein Programm aus dem Netz laden und ausprobieren, Fehlanzeige ! Im schlimmsten Fall müssen 30 Libs mithinzu installiert werden, die wiederum je 2 neue Libs benötigen. Am Ende hat man dann Gnome installiert, obwohl man ja nur "EIN" Programm installieren wollte.
- Die Liste könnte noch Seitenweise länger werden !
 
Ok, ein Beispiel. Ich hab mal versucht Windows einen anderen Standard-Dateimanager beizubringen. Das war wirklich nicht einfach und hat auch nicht 100%ig funktioniert. Bei bestimmten Anwendungen hat sich dann doch wieder der Windows-Explorer geöffnet.


Auch wenn du das Argument leid bist, es ist eins. Ich hab in meinem Bekanntenkreis so viele Leute, die damit schon ein Problem hatten. Ich weiss nicht wirklich was diese damit machen, aber es kommt wirklich häufig genug vor (man muss nur mal in die Windows Kategorie schauen). Und die meisten haben so etwas wie Antivir/AVG drauf. Und unter Linux brauche ich nicht mal einen Virenscanner, dank regelmäßiger Updates, ausgeklügeltem Rechtesystem und geringerer Verbreitung (ja, das muss ich zugeben).

Mit Linux und Mac OS haste so gut wie kaum Virenbefall, weil kein kriminelles Element sich bei seinen Bastelarbeiten die Mühe macht, für Betriebssysteme, die, auch wenn es dir weh tut, einer Minderheit weltweit genutzt wird, da was zu finden. Wo macht Schaden mehr Sinn? bei 90-95% der Nutzer oder bei 5-10% ?

In allen PC Lagern gibt es verbohrte, die keine Argumente zulassen, außer wenn sie für eine gewisse Sache ist, die grade von ihnen geliebt werden. Bei AMD / Intel ist das so, bei nVidia / ATi auch...man praktisch alles auf der Welt hervorholen...auch Erdbeeren / Kirschen. Was weiß ich.

Ich behaupte mal, daß Linux inzwischen ein sehr gutes System ist, nur halt nicht für den "Otto-Normal-Nutzer", der auch mal halbwegs aktuelle Games ohne Emulationen zocken will...

Für Firmen und deren Server ist das eine gute Sache, eben aus dem Grund, den ich im ersten Teil meines Postings nannte, kriminelle Elemente, etc.

Außer daß ich mal Knoppix von CD gebootet habe, hatte ich bisher keine Berührungen mit Linux. Vielleicht ein Fehler, vielleicht auch nicht.

Gruß

Frank
 
Die Jahre vergingen, nichts passierte. Klar sieht KDE 4 wirklich schön aus. Sobald man aber ernsthaft versucht damit zu arbeiten. Ein Graus. Fehlende Funktionalitäten, komplette Abtürze der GUI. Aufgebläht und Träge. Als wieder zurück zu KDE3. Schnell, schlank alles da.
KDE4 ist erst mit 4.2 einigermaßen nutzbar geworden.Und da fehlt immer noch so manches gegen KDE3. Aber das beim Wechsel von KDE2 zu KDE3 auch nicht viel anders.

Mittlerweile ist meine Empfehlung:
Windows XP/Vista als Desktopsystem und Spielesystem sowie für jeden der kreativ mit dem Rechner etwas erschaffen will.
Linux ist ein UNIX Derivat. Nichts anderes ! Und UNIX wurde schon immer auf SERVERN eingesezt. Hier wird auf der Konsole an Dateien konfiguriert.
Ach, die ganzen Unix-Workstations waren nur Einbildung?

Ich kenne viele die vor 10 Jahren mit Linux angefangen haben und jetzt alle bei OSX gelandet sind. Hier stimmt einfach alles. Komfort und alle wichtigen Professinellen Programme sind verfügbar. Ausserdem sind die MAC Rechner einfach nur schön. (Das Air book *träum*) (Okay dafür auch teuer!)
Und MacOS X ist kein Unix? :]

Also, jeder der jammert über Linux, ihr habt Recht.
Linux ist kein Desktop/Benutzer Betriebsystem !
Nö, haben sie nicht. ;D

Ich nehme deine Liste jetzt nicht Stück für Stück auseinander. Die ist hinten und vorne falsch.
 
Mit Linux und Mac OS haste so gut wie kaum Virenbefall, weil kein kriminelles Element sich bei seinen Bastelarbeiten die Mühe macht, für Betriebssysteme, die, auch wenn es dir weh tut, einer Minderheit weltweit genutzt wird, da was zu finden. Wo macht Schaden mehr Sinn? bei 90-95% der Nutzer oder bei 5-10% ?
Das ist sicher ein Grund, warum Linux kaum Virenbefall (eigentlich keinen, zumindest ist nichts bekannt) hat. Aber nicht der einzige. Das wird sicher auch an der Vielfalt an Software und Versionen der Distributionen und dem an dem Rechtesystem liegen, das zwar unter Windows auch vorhanden ist, aber kaum genutzt wird. Linux kommt eben aus der Server Ecke. Das merkt man manchmal auch.

In allen PC Lagern gibt es verbohrte, die keine Argumente zulassen, außer wenn sie für eine gewisse Sache ist, die grade von ihnen geliebt werden. Bei AMD / Intel ist das so, bei nVidia / ATi auch...man praktisch alles auf der Welt hervorholen...auch Erdbeeren / Kirschen. Was weiß ich.
Eigentlich nichts schlimmes daran seine Meinung zu vertreten, solange man sie gut begründen kann. Es gibt leider gerade bei diesem Thema zu viele Leute, die einfach nur nachplappern was sie mal gehört haben.

Ich behaupte mal, daß Linux inzwischen ein sehr gutes System ist, nur halt nicht für den "Otto-Normal-Nutzer", der auch mal halbwegs aktuelle Games ohne Emulationen zocken will...
Ja, für Gamer ist das System ganz sicher nichts. Außer man spielt ausschliesslich ID Games :-)

Für Firmen und deren Server ist das eine gute Sache, eben aus dem Grund, den ich im ersten Teil meines Postings nannte, kriminelle Elemente, etc.

Außer daß ich mal Knoppix von CD gebootet habe, hatte ich bisher keine Berührungen mit Linux. Vielleicht ein Fehler, vielleicht auch nicht.

Gruß

Frank
Solange man kein wirkliches Interesse hat umzusteigen, sollte man es sein lassen. Der Umstieg bedeutet eben doch Arbeit und Umgewöhnung (in beide Richtungen). Aber man kann schliesslich auch mit Windows zufrieden sein.
 
Hi,

benutze selber seit 13 Jahren Linux, teilweise sogar als primäres System auf dem Rechner.
AM Anfang habe ich es noch groß in der Bekanntschaft angepriesen. Dachte, noch 1 Jahr und es ist "reif" für die Masse.
Die Jahre vergingen, nichts passierte. Klar sieht KDE 4 wirklich schön aus. Sobald man aber ernsthaft versucht damit zu arbeiten. Ein Graus. Fehlende Funktionalitäten, komplette Abtürze der GUI. Aufgebläht und Träge. Als wieder zurück zu KDE3. Schnell, schlank alles da.

Ach ich könnt mich seitenweise hier auslassen.

Mittlerweile ist meine Empfehlung:
Windows XP/Vista als Desktopsystem und Spielesystem sowie für jeden der kreativ mit dem Rechner etwas erschaffen will.
Linux ist ein UNIX Derivat. Nichts anderes ! Und UNIX wurde schon immer auf SERVERN eingesezt. Hier wird auf der Konsole an Dateien konfiguriert.
Gerade bei der Virtualisierung von mehreren Servern auf einem Host ist Linux momentan das Server OS der Wahl.

Ich kenne viele die vor 10 Jahren mit Linux angefangen haben und jetzt alle bei OSX gelandet sind. Hier stimmt einfach alles. Komfort und alle wichtigen Professinellen Programme sind verfügbar. Ausserdem sind die MAC Rechner einfach nur schön. (Das Air book *träum*) (Okay dafür auch teuer!)

Also, jeder der jammert über Linux, ihr habt Recht.
Linux ist kein Desktop/Benutzer Betriebsystem !

Argumente gegen Linux auf dem Desktop sind:
- komplizierte Bedienung und Konfiguration
- keine API Kompatibilität zu älteren Linux Systemen
- keine komerziellen Spiele
- keine professionellen komerziellen Anwendungen
- kein vereinheitlichtes Linux Desktop für alle Linux Distributionen
- kein Plug&Play von neuer Hardware, im schlimmsten Fall Treiber über Konsole selber per Hand nachinstallieren.
- Es kostet genausoviel wie Windows und bietet weniger komfort. (Suse 11.1 - 80 Euro)
- Das System wird duch ständige Updates instabil.
- Mal eben ein Programm aus dem Netz laden und ausprobieren, Fehlanzeige ! Im schlimmsten Fall müssen 30 Libs mithinzu installiert werden, die wiederum je 2 neue Libs benötigen. Am Ende hat man dann Gnome installiert, obwohl man ja nur "EIN" Programm installieren wollte.
- Die Liste könnte noch Seitenweise länger werden !

AMEN

Genau das ist auch meine Meinung. Leider muss ich dazu sagen ...

Geh mal mit diesem realistischen Blick in das Ubuntuusers Forum.
Da wirst du für so eine Aussage/Meinung gesteinigt!
.
EDIT :
.

Und MacOS X ist kein Unix? :]
Einerseits ist es doch ein BSD oder so. Wie auch immer!
Andererseits merkt man nix davon, was für ein "kompliziertes" System dahinter läuft.

Dies merkt man auch nicht bei Windows.

Einzig unter Linux kriegt man mit, wie kompliziert ein Betriebssystem sein kann und muss dabei auch noch Hand anlegen.
 
Einerseits ist es doch ein BSD oder so. Wie auch immer!
Andererseits merkt man nix davon, was für ein "kompliziertes" System dahinter läuft.

Dies merkt man auch nicht bei Windows.

Einzig unter Linux kriegt man mit, wie kompliziert ein Betriebssystem sein kann und muss dabei auch noch Hand anlegen.

Wenn man lieber neu installiert, statt Probleme zu fixen, bekommt man das bei Windows sicherlich nicht mit. Ansonst gehört diese Aussage auch ins Reich der Märchen. Was MacOS X angeht, damit hab ich nicht genug Kontakt, um das beurteilen zu können. Allerdings bezweifle ich ernsthaft, dass es immer und zufriedenstellend läuft. Dazu ist hier noch zu bedenken, dass es sein eigenes Biotop hat, und somit ein klein wenig außer Konkurrenz läuft.
 
Dazu ist hier noch zu bedenken, dass es sein eigenes Biotop hat, und somit ein klein wenig außer Konkurrenz läuft.
Das stimmt schon irgendwie. Ich denke mal kein Mac-nutzer würde irgendeine Hardware kaufen (egal ob DVB-T Stick, Webcam, Drucker usw), bei der nicht auf der Packung steht, dass das MacOS dies unterstützt. Im PC-Fall tritt das Treiberproblem normalerweise ja auch dann auf, wenn man sich ein solches Gerät für seinen Windows-Rechner holt und sich im Nachhinein überlegt, dass man auch mal ein Linux aufspielen könnte um sich das mal anzuschauen.
 
Argumente gegen Linux auf dem Desktop sind:
- komplizierte Bedienung und Konfiguration
- keine API Kompatibilität zu älteren Linux Systemen
- keine komerziellen Spiele
- keine professionellen komerziellen Anwendungen
- kein vereinheitlichtes Linux Desktop für alle Linux Distributionen
- kein Plug&Play von neuer Hardware, im schlimmsten Fall Treiber über Konsole selber per Hand nachinstallieren.
- Es kostet genausoviel wie Windows und bietet weniger komfort. (Suse 11.1 - 80 Euro)
- Das System wird duch ständige Updates instabil.
- Mal eben ein Programm aus dem Netz laden und ausprobieren, Fehlanzeige ! Im schlimmsten Fall müssen 30 Libs mithinzu installiert werden, die wiederum je 2 neue Libs benötigen. Am Ende hat man dann Gnome installiert, obwohl man ja nur "EIN" Programm installieren wollte.
- Die Liste könnte noch Seitenweise länger werden !

also die Liste ist echt mal geil. Für jemanden der 13 Jahre, damit arbeitet eine komische Liste.

Das es keine kommerziellen Spiele und Appz gibt, ist kein Grund das es nicht Desktop tauglich ist. Spiele machen keinen Desktop Rechner aus. Und für eine viel Zahl von kommerziellen Appz gibt es OpenSource oder Freie Software.

Wo ist die Bedingung in der Zeit von Ubuntu oder Opensuse noch kompliziert?

Aha, ein Desktop wird also durch einen vereinheitlichte GUI definiert? Was ist den so schlimm daran die Wahl zu haben?

Ein System wird durch Updates instabile? Das musst du mal bitte erklären? Und ständig ist sehr übertrieben.

Plug&Play von neuer Hardware funktioniert einwandfrei.
 
Mein Liebling in der Liste ist:
- Es kostet genausoviel wie Windows und bietet weniger komfort. (Suse 11.1 - 80 Euro)
13 Jahre Linux Erfahrung? *hust*
 
- keine professionellen komerziellen Anwendungen
- komplizierte Bedienung und Konfiguration
- keine API Kompatibilität zu älteren Linux Systemen
- Mal eben ein Programm aus dem Netz laden und ausprobieren, Fehlanzeige ! Im schlimmsten Fall müssen 30 Libs mithinzu installiert werden, die wiederum je 2 neue Libs benötigen. Am Ende hat man dann Gnome installiert, obwohl man ja nur "EIN" Programm installieren wollte.
- Die Liste könnte noch Seitenweise länger werden !

Dann schaue Dir mal Ardour an. Zwar nicht kommerziell wie von Dir gefordert, dafür aber verdamt professionell, wenn es auf Audiobearbeitung ankommt.

Komplizierte Bedienung und Konfiguration? Sicher, wenn Hardware verbaut wird, zu der es keine Dokumentation und keine Treiber gibt, dann ja. Solche Hardware läuft aber genausowenig auf einem Mac, oder Windowssystem. Und Bedienung? Dazu habe ich auch eine Story:
Ich war mal bei einer Bekannten, der ich erklären sollte, wie sie ihre CDs auf einen MP3 Stick bekommt. Unter Windows erstmal bei ihr CDex aus dem Netz geholt, installiert und konfiguriert. Dann habe ich ihr erklärt, dass damit die AudioCD erstmal auf dem Rechner landet und diese nach dem Encodierungsprozess die fertigen MP3 Dateien in ihrem Musikordner landen. Diese muss sie dann auf den Stick kopieren. War alles sehr kompliziert für sie das zu begreifen und das unter Windows. Als ich ihr angeboten habe ihr ein Ubuntu zu installieren hat sie dann darauf geantwortet. Sie sei mit ihrem Windows zufrieden und kenne sich damit schließlich schon aus und möchte sich nicht mehr umgewöhnen. ... Aha. Hat also kein Plan davon wie sie eine CD auf nen Stick bekommt, kennt sich aber schon aus. Sauber. Evtl. gibt es da Parallelen?

Inwiefern Kompatibilität? hääähhh

Programme ausprobieren und installieren geht ja unter Windows einfacher ja? öhmmmm ... alles klar.

Und letzteres. Jaaa bitte mach das.
 
...

Argumente gegen Linux auf dem Desktop sind:
- komplizierte Bedienung und Konfiguration
Je tiefer man in die Windowswelt einsteigt um so mehr sieht man wie kompliziert es auch hier ist.
- keine API Kompatibilität zu älteren Linux Systemen
Ah ja. Weil ja z.b. ein aktuelles Office 2007 noch unter Windows 95/98/ME, NT 3.x, NT4 oder 2000 läuft
- keine komerziellen Spiele
Und Spiele sind natürlich äusserst wichtig. :]
Wer auch spielen will nimmt eben Windows. Spieler sind bei sämtlichen PC Linuxen falsch aufgehoben.
- keine professionellen komerziellen Anwendungen
Definier mal profesionelle Anwendung.
- kein vereinheitlichtes Linux Desktop für alle Linux Distributionen
Das ist sowohl ein Vor als auch ein Nachteil.
- kein Plug&Play von neuer Hardware, im schlimmsten Fall Treiber über Konsole selber per Hand nachinstallieren.
Dann muß es sich um brandneue Geräte handeln. Und eine Treiber über die Konsole installieren wenn vorhanden ist meist recht gut beschrieben.
Aber ja. Die Hersteller könnten ruhig mehr Teiber für Linux anbieten.
- Es kostet genausoviel wie Windows und bietet weniger komfort. (Suse 11.1 - 80 Euro)
Nur kannst du mit einem nackten Windows nix anfangen und mußt erst noch Software downloaden oder kaufen.
Bei der Suse ist fast alles wichtige dabei. Evtl im Yast noch die Community Repos aktivieren und gut ist.
Wenn du aber auf die Idee kommen würdest OpenSuse 11.1 zu nehmen kostet es dich nur die Downloadzeit und einen DVDD Rohling.
Was den Komfort angeht... Ansichtssache. Aber nach 13 Jahren Linux sollte man damit keine Probleme mehr haben.
- Das System wird duch ständige Updates instabil.
Mach aus "ständig" "kann" und ich geb dir Recht. Aber das kenne ich noch schlimmer von Windows.
- Mal eben ein Programm aus dem Netz laden und ausprobieren, Fehlanzeige ! Im schlimmsten Fall müssen 30 Libs mithinzu installiert werden, die wiederum je 2 neue Libs benötigen. Am Ende hat man dann Gnome installiert, obwohl man ja nur "EIN" Programm installieren wollte.
Hier geb ich dir Recht. Das kann teilweise wirklich krass ausarten. Ich kann aktuell Compiz nicht aktualisieren weil Yast dann irgendwas um die 180 Konflikte mit aktuell installierten KDE3/4 Paketen anmeckert.
- Die Liste könnte noch Seitenweise länger werden !
Nu übertreib mal nicht :)
 
Nu übertreib mal nicht :)

Einen Punkt hab ich aber beizutragen:

Bei mir und anderen Leuten "meistens bei einer Vorführung" hängt sich das Ubuntu gerne mal auf, ich glaub sowas nennt man Kernel Panik, oder Vorführeffekt :)
 
Je tiefer man in die Windowswelt einsteigt um so mehr sieht man wie kompliziert es auch hier ist.

Das stimmt natürlich, allerdings bezog ich mich bei der kompliziertheit des normalen Systems. Es ist nunmal etwas anderes unter Linux ein WPA2 Wlan einzurichten (z.B. mit einem USB Stick) als unter Windows. Besonders dann wenn man verschiedenste Linux Distributionen einsetzt. Wenn man wissen will, was man macht, kommt man nicht darum herum die entsprechenden config Dateien per Hand zu editieren. Allerdings ist dies an komplexheit unter Linux kaum zu überbieten. (Bei diesem WPA2 mit usb-stick Wlan zu bleiben). Unter Suse11.1 mag das auch mit 3 Mausklicks gehen, aber wie richte ich das unter Slackware, Debian, Kubuntu ... ein ? Wie gesagt um kompatible zu anderen Distributoren zu sein, muss man config Dateien per HAND selber anpassen. Dies ist bei Windows nicht der Fall. Liegt auch darin begründet das es nunmal nur ein Windows aus einer Hand gibt.

Ah ja. Weil ja z.b. ein aktuelles Office 2007 noch unter Windows 95/98/ME, NT 3.x, NT4 oder 2000 läuft

Dies ist natürlich nicht das Problem, niemand möchte auf einem alten System neue Software ausführen. Das Problem ist, wie bekomme ich auf NEUER Hardware die ALTE Software ans laufen ?
Unter Windows ist es sehr wohl möglich ein Office97 unter Vista zu installieren. Das sind 10 Jahre kompatibilität.

Schauen wir uns nun folgendes praxistaugliche Beispiel an:
Ich habe hier eine KDE1.x/QT1.x Anwendung die von einer Firma (für viel Geld) Entwickelt wurde und unter Suse 6.0 läuft. Quelltexte liegen vor.

Wie bekomme ich dieses Programm unter Suse 11.1 ans laufen ?
Gar nicht !
QT1.x lässt sich nicht unter 11.1 installieren. ( Es kompiliert einfach nicht )
KDE1.x lässt sich nicht unter 11.1 installieren. ( Es fehlen schlicht die Paket+Abhängigkeiten )
Die Anwendung lässt sich nicht neu kompilieren da autoconf + automake + configure das neue system nicht erkennen und kein Makefile erstellen.
Die Anwednung lässt sich auch nicht mehr als bin starten. Von den 50 Abhängigkeiten sind nur 5 auf dem System.

Das Programm lässt sich nur noch in einem Virtualisiertem Suse6.0 starten !
Eine Chroot-Umgebung klappt auch nicht !

Das größte Proglem unter Linux ist tatsächlich die nicht vorhandene kompatibilität mit der Vorgängerversion. Auch die Tatsache dass alles im Quelltext vorliegt und man ja alles neu kompilieren könnte, klappt nicht. Ohne unendliche Wartung der Programme und immer neue Anpassung an neure Linux Versionen ist es nicht möglich ein Programm in die Zukunft zu bringen.
Hätten wir das Programm 1996 unter Windows entwickeln lassen, hätten wir nun sehr viele Probleme nicht.


Und Spiele sind natürlich äusserst wichtig. :]
Wer auch spielen will nimmt eben Windows. Spieler sind bei sämtlichen PC Linuxen falsch aufgehoben.

Es wird sich nur das Betriebsystem verbreiten, welches einen breiten Support der Spielefirmen bietet. 1995 wurde Windows 95 eingeführt. Ausnahmslos alle Spielefirmen entwickelten ab diesem Zeitpunkt keine DOS Spiele mehr. DOS starb c.a. 1998 aus. Alle Games waren zu diesem Zeitpunkt DirectX basiert.
OS2, Beos, AmigaOS, DOS, starben aus wegen mangeldem Spiele support.

Definier mal profesionelle Anwendung.

Das sind alle kommerziellen Programme (auch Speiel) mit denen eine Firma Geld verdient um ihre Programmierer/Designer/usw. damit zu bezahlen.

Dann muß es sich um brandneue Geräte handeln. Und eine Treiber über die Konsole installieren wenn vorhanden ist meist recht gut beschrieben.
Aber ja. Die Hersteller könnten ruhig mehr Teiber für Linux anbieten.

Ich könnte ohne eine langwierige Vorbereitung nicht in den MediaMarkt gehen und mit dort z.b. eine Web-Cam/Wlan-Stick,USB-SAT-Karte, usw, kaufen die unter Linux läuft.

Der erste Schritt den die Firmen bringen müßten, wäre eine Anmerkung auf der Verpackung , "läuft unter Linux". Für OSX ist das schließlich auch der Fall.

Nur kannst du mit einem nackten Windows nix anfangen und mußt erst noch Software downloaden oder kaufen.
Bei der Suse ist fast alles wichtige dabei. Evtl im Yast noch die Community Repos aktivieren und gut ist.

Hier ist natürlich zu klären, was wichtig ist ?
Bei einer Linux Distribution finde ich meißt 1000 Programme, die aber leider nur meißt der 5 Aufguß eines anderen Programms sind. 20 Email clients, 5 Browser, 20 Foto archiver, 30 ftp clients, usw... Aber keines der Programme bietet mir die Funktionalität die ich wirklich will. Meißt muss ich kombinationen aus Programmen einsetzten, oder die Software ist nie aus dem Beta Stadium entlassen worden. An freier Software die benutzbar und praxistauglich ist, kann ich nur Firefox und Gimp erwähnen. Also wozu brauche ich 1000 Programme ?

Wenn du aber auf die Idee kommen würdest OpenSuse 11.1 zu nehmen kostet es dich nur die Downloadzeit und einen DVDD Rohling.
Was den Komfort angeht... Ansichtssache. Aber nach 13 Jahren Linux sollte man damit keine Probleme mehr haben.
Das Problem mit Linux ist einfach, es erfordert zuviel Zeit und Eigenleistung. Das ist in einem Unternehmen wo Zeit=Geld ist, nicht zu vereinbaren.

Hier geb ich dir Recht. Das kann teilweise wirklich krass ausarten. Ich kann aktuell Compiz nicht aktualisieren weil Yast dann irgendwas um die 180 Konflikte mit aktuell installierten KDE3/4 Paketen anmeckert.

Interessant wird die Sache, ob nach so einem Update z.B. das System noch stabil ist. Oder ob z.B. Konfigurationsdateien die vor dem Update noch richtig waren, nach dem Update noch per Hand angepasst werden müssen. Nicht selten passiert es dass man ein Programm/Lib updated und danach an einer anderen Stelle etwas nicht mehr funktioniert.
 
Schauen wir uns nun folgendes praxistaugliche Beispiel an:
Ich habe hier eine KDE1.x/QT1.x Anwendung die von einer Firma (für viel Geld) Entwickelt wurde und unter Suse 6.0 läuft. Quelltexte liegen vor.

Wie bekomme ich dieses Programm unter Suse 11.1 ans laufen ?
Gar nicht !
QT1.x lässt sich nicht unter 11.1 installieren. ( Es kompiliert einfach nicht )
KDE1.x lässt sich nicht unter 11.1 installieren. ( Es fehlen schlicht die Paket+Abhängigkeiten )

Bei solchen Fällen kompiliert man statisch alles mit rein, was das Programm braucht und hat auf anderen Systemen gleicher Architektur keine Probleme.
 
oder auf eine neue QT version portieren
oder wie hoschi gesagt hat, statisch linken, z.B. in einer suse 6.x VM
 
oder auf eine neue QT version portieren
oder wie hoschi gesagt hat, statisch linken, z.B. in einer suse 6.x VM

Portieren ist bei einer Software die aus 1000 Zeilen besteht ja noch möglich. Bei einer Software die aus 100.000 Zeilen besteht, bedeutet dies eine komplette Neuentwickung.
Es darf natürlich nicht der Sinn sein, Software jedes Jahr an Linux/qt/kde/glibc/gcc Änderungen anzupassen. Dies ist Personell gar nicht zu handeln.

Statisch linken ist eine schöne Sache bei Konsolenprogrammen. Sobald eine GUI hinzukommt bringt das leider auch nichts. Wenn ich die qt1.x statisch zum Programm dazu linke, läuft das neue Programm auch nicht unter Suse11.1. In den letzten 10 Jahren haben sie die X11 libs soviel verändert, dass ein Aufruf von X11/Xorg Funktionen aus einer alten qt1.x sofort zum Absturz des Programmes führt. Auch ein noch dazulinken von der x11lib klappt nicht. Irgendwann muss eine lib ja mal mit der Außenwelt kommunizieren und da diese Schnittstellen nicht genormt sind und es keine Garantie gibt, dass diese 10 Jahre kompatible bleiben, ist ein Statisches linken auch keine Alternative.

Es bleibt nur noch der Weg über eine VM. Unschön, aber das Problem ist schnell und günstig gelöst.

Ich denke viele Linux Probleme die wir haben, sind darauf zurückzuführen, das es bei Linux keine Kontrollinstanz gibt, die über die Kompatibilität von Funktionen/Schnittstellen wacht. Wieso muss z.B. Nvidia jedesmal wenn ein neuer Kernel kommt, den Grafiktreiber anpassen ? Das ist doch ein Unding und nicht mehr zeitgemäß. Es wird ganz dringend eine HAL an Linux gefordert. Aber solche Forderungen verpuffen ganz schnell auf Mailinglisten und man widmet sich lieber der 10ten Erneuerung von fuse/dateisystemen/usw... Anstatt die wirklichen Probleme anzugehen. Was wäre schöner als wenn ein Hersteller einen Linux Treiber für ein Gerät schreiben könnte, der 10 Jahre lang, ohne neu zu kompilieren, einfach funktionieren würde ? Aber alles Utpoie, nicht gewollt, Kleinkinder gezanke über freie Treiber...

Sind wir doch mal ehrlich, AMD hat vor einem Jahr ihre Chipsatz Dokumentation zu ihren damals aktuellen 3D Chips herausgegeben. Wo sind die 10 freien 3D Treiber die alle besser sind als die closed Source ? Wo sind die freien alsa - x-fi Treiber, creative hat die Docus vor 2 Jahren frei gegeben. (Okay sind nun endlich eperimentell im aktuellen Kernel und unterstützen so gut wie keine x-fi features).

Aber ich schweife etwas ab. Nur leider sehe ich bei Linux einfach kein weiterkommen. Es wird auch in weiteren 10 Jahren nicht das Desktopsystem der Massen werden. Es wird einfach Zeit für einen kompletten Neuanfang.
 
Portieren ist bei einer Software die aus 1000 Zeilen besteht ja noch möglich. Bei einer Software die aus 100.000 Zeilen besteht, bedeutet dies eine komplette Neuentwickung.
Es darf natürlich nicht der Sinn sein, Software jedes Jahr an Linux/qt/kde/glibc/gcc Änderungen anzupassen. Dies ist Personell gar nicht zu handeln.
Muss sie auch nicht, siehe unten.

Statisch linken ist eine schöne Sache bei Konsolenprogrammen. Sobald eine GUI hinzukommt bringt das leider auch nichts. Wenn ich die qt1.x statisch zum Programm dazu linke, läuft das neue Programm auch nicht unter Suse11.1. In den letzten 10 Jahren haben sie die X11 libs soviel verändert, dass ein Aufruf von X11/Xorg Funktionen aus einer alten qt1.x sofort zum Absturz des Programmes führt. Auch ein noch dazulinken von der x11lib klappt nicht. Irgendwann muss eine lib ja mal mit der Außenwelt kommunizieren und da diese Schnittstellen nicht genormt sind und es keine Garantie gibt, dass diese 10 Jahre kompatible bleiben, ist ein Statisches linken auch keine Alternative.
Das ist schlicht und ergreifend falsch. Es gibt genormte Schnittstellen. Dies ist natürlich zu allererst die libc. Und die ist so was von konservativ gehalten. Binärkompatibilität ist da oberstes Gebot. Auch die xlib ist abwärtskompatibel. Ich habe es jetzt nicht mit Qt1 probiert, aber sämtliche proprietäre Software, die ich hier liegen habe, funktioniert immer noch.
Wo es Brüche gibt, sind Toolkits wie Qt, das ist wahr. Um dieses Problem zu handhaben, gibt es zwei Möglichkeiten. Variante 1 ist statisches linken. Und ja, das kann man bis runter zur libc treiben. Da umgeht man so ziemlich alle Kompatibilitätsprobleme. Ok, die glibc lässt sich nicht 100% statisch linken. Aber wie schon gesagt, ist die vollständig abwärtskompatible gehalten. Alles andere ist statisch linkbar. Und die letzte Schnittstelle zur Außenwelt sind eh die Syscalls des Betriebssystems.
Wer es also mag, kann sein Programm statisch linken, unabhängig von GUI oder sonst etwas. Das wirft "lediglich" das Problem von riesigen Binaries auf, da sämtlicher Code dupliziert wird. Deshalb gibt es Variante zwei, welche die Hersteller proprietärer Software auch gehen, sowohl unter Linux als auch unter Windows. Sie liefern die benötigten libs einfach mit aus. Matrica macht das z.b. bei Moneyplex so, und liefert die libqt dort mit. Damit hat man das Problem wechselnder Toolkits schon nicht mehr. Und jetzt darfst du dreimal raten, wieso die X11-libs nicht mit geliefert werden, bei keinem Programm mit GUI. Richtig, weil es auf Grund der Abwärtskompatiblität nicht notwendig ist.

Ich denke viele Linux Probleme die wir haben, sind darauf zurückzuführen, das es bei Linux keine Kontrollinstanz gibt, die über die Kompatibilität von Funktionen/Schnittstellen wacht. Wieso muss z.B. Nvidia jedesmal wenn ein neuer Kernel kommt, den Grafiktreiber anpassen ?
Weil es aus diversen Gründen kein festes ABI gibt. (nebenbei, du plenkst)

Das ist doch ein Unding und nicht mehr zeitgemäß. Es wird ganz dringend eine HAL an Linux gefordert. Aber solche Forderungen verpuffen ganz schnell auf Mailinglisten
Weil nach dem x-ten Mal Begründung keiner Lust hat, die Argumente gegen ein festes ABI zu wiederholen.

und man widmet sich lieber der 10ten Erneuerung von fuse/dateisystemen/usw... Anstatt die wirklichen Probleme anzugehen.
Echt? Wo jetzt?

Was wäre schöner als wenn ein Hersteller einen Linux Treiber für ein Gerät schreiben könnte, der 10 Jahre lang, ohne neu zu kompilieren, einfach funktionieren würde ? Aber alles Utpoie, nicht gewollt, Kleinkinder gezanke über freie Treiber...
Damit verlangst du 10 Jahre ziemliche Stillstand in der Kernel-Entwicklung.

Sind wir doch mal ehrlich, AMD hat vor einem Jahr ihre Chipsatz Dokumentation zu ihren damals aktuellen 3D Chips herausgegeben. Wo sind die 10 freien 3D Treiber die alle besser sind als die closed Source ?
Ein halbes Jahr. Und wenn es nur sehr wenige Entwickler gibt, die das umsetzen, dauert es dementsprechend lange, bis ein nutzbarer Treiber dabei raus kommt. Ich weiß jetzt von 3 Entwicklern, die am r6xx-rewrite branch arbeiten, und das auch nicht Vollzeit. Und die Materie ist nicht trivial.

Wo sind die freien alsa - x-fi Treiber, creative hat die Docus vor 2 Jahren frei gegeben. (Okay sind nun endlich eperimentell im aktuellen Kernel und unterstützen so gut wie keine x-fi features).
Wie meinen? Anfang 2008 gab es einen erstem OSS Beta-Treiber, sowie Gerüchte über Doku seitens Creative. Im März gab es dann auch erste Dokus für die Entwickler. Auf der Basis gab es auch einen experimentellen ALSA-Treiber, der es aber nie zur stable-Reife brachte. Im November brachte Creative dann endlich einen eigenen quelloffene ALSA-Treiber heraus. Das ist auch der Treiber, der jetzt aufgenommen wurde.

Aber ich schweife etwas ab. Nur leider sehe ich bei Linux einfach kein weiterkommen. Es wird auch in weiteren 10 Jahren nicht das Desktopsystem der Massen werden. Es wird einfach Zeit für einen kompletten Neuanfang.
Da spricht jemand, der den Überblick (über die Komplexität) hat. *lol*
 
Interessant wird die Sache, ob nach so einem Update z.B. das System noch stabil ist. Oder ob z.B. Konfigurationsdateien die vor dem Update noch richtig waren, nach dem Update noch per Hand angepasst werden müssen. Nicht selten passiert es dass man ein Programm/Lib updated und danach an einer anderen Stelle etwas nicht mehr funktioniert.

sowas testet man bei kritischer Software auch vorher...machst du das nicht?
 
Das ist schlicht und ergreifend falsch. Es gibt genormte Schnittstellen. Dies ist natürlich zu allererst die libc. Und die ist so was von konservativ gehalten. Binärkompatibilität ist da oberstes Gebot. Auch die xlib ist abwärtskompatibel. Ich habe es jetzt nicht mit Qt1 probiert, aber sämtliche proprietäre Software, die ich hier liegen habe, funktioniert immer noch.
Dann sage mir doch bitte nach welcher ISO Norm oder welcher Zertifizierung die Schnittstellen genormt wurden ? Und welche externe Kontrollinstanz diese Überwacht ?

Wo es Brüche gibt, sind Toolkits wie Qt, das ist wahr. Um dieses Problem zu handhaben, gibt es zwei Möglichkeiten. Variante 1 ist statisches linken. Und ja, das kann man bis runter zur libc treiben. Da umgeht man so ziemlich alle Kompatibilitätsprobleme. Ok, die glibc lässt sich nicht 100% statisch linken. Aber wie schon gesagt, ist die vollständig abwärtskompatible gehalten. Alles andere ist statisch linkbar. Und die letzte Schnittstelle zur Außenwelt sind eh die Syscalls des Betriebssystems.
Und genau die ändern sich fast im Jahresrhythmus.
Versuch doch mal ein 3D Programm statisch zu linken... Geht einfach nicht zu 100%

Wer es also mag, kann sein Programm statisch linken, unabhängig von GUI oder sonst etwas. Das wirft "lediglich" das Problem von riesigen Binaries auf, da sämtlicher Code dupliziert wird. Deshalb gibt es Variante zwei, welche die Hersteller proprietärer Software auch gehen, sowohl unter Linux als auch unter Windows. Sie liefern die benötigten libs einfach mit aus. Matrica macht das z.b. bei Moneyplex so, und liefert die libqt dort mit. Damit hat man das Problem wechselnder Toolkits schon nicht mehr. Und jetzt darfst du dreimal raten, wieso die X11-libs nicht mit geliefert werden, bei keinem Programm mit GUI. Richtig, weil es auf Grund der Abwärtskompatiblität nicht notwendig ist.
In 10 Jahren wird die Software auch nicht mehr laufen.


Weil es aus diversen Gründen kein festes ABI gibt. (nebenbei, du plenkst)
nebenbei , du nervst mit Fanboy gelaber.

Weil nach dem x-ten Mal Begründung keiner Lust hat, die Argumente gegen ein festes ABI zu wiederholen.
Die Begründung ist ja auch eine Kindergartenbegründung. Deshalb wird die auch so selten wiederholt.

Damit verlangst du 10 Jahre ziemliche Stillstand in der Kernel-Entwicklung.
Mach dich erstmal schlau was eine HAL ist. Für dich erklär ich das aber auch hier gerne. Das ist ein "Hardware Abstraction Layer" der es ermöglicht durch eine definierte
Software Schnittstelle mit der Hardware zu kommunizieren. Wieso eine definierte Schnittstelle die sich ja um die internen Kernelschnittstellen legt, nun einen Stillstand bedeutet, kann ich nicht erkennen. Aber du als Kernel Entwickler hast da sicher genauere Informationen.

Ein halbes Jahr. Und wenn es nur sehr wenige Entwickler gibt, die das umsetzen, dauert es dementsprechend lange, bis ein nutzbarer Treiber dabei raus kommt. Ich weiß jetzt von 3 Entwicklern, die am r6xx-rewrite branch arbeiten, und das auch nicht Vollzeit. Und die Materie ist nicht trivial.
Lol, dann wird das nie was...

Wie meinen? Anfang 2008 gab es einen erstem OSS Beta-Treiber, sowie Gerüchte über Doku seitens Creative. Im März gab es dann auch erste Dokus für die Entwickler. Auf der Basis gab es auch einen experimentellen ALSA-Treiber, der es aber nie zur stable-Reife brachte. Im November brachte Creative dann endlich einen eigenen quelloffene ALSA-Treiber heraus. Das ist auch der Treiber, der jetzt aufgenommen wurde.
Ob nun 18 oder 24 Monate, was für ein Unterschied !
Entscheidend ist, selbst mit Doku dauert es bei einem so simplen Treiber wie der von einer Soundkarte, JAHRE bis die freien Hobby Bastler einen Treiber präsentieren.


Da spricht jemand, der den Überblick (über die Komplexität) hat. *lol*
[/QUOTE]
Da spricht jemand der überhaupt keinen Überblick hat. HA HA HA
.
EDIT :
.

sowas testet man bei kritischer Software auch vorher...machst du das nicht?

Bei kritischen Systemen macht man ja auch kein Update. Das wird im Software/Hardware stand eingefroren.
 
Dann sage mir doch bitte nach welcher ISO Norm oder welcher Zertifizierung die Schnittstellen genormt wurden ? Und welche externe Kontrollinstanz diese Überwacht ?
Nach welcher ISO Norm oder Zertifizierung sind die Schnittstellen von Windows genormt? So langsam wirds peinlich.

Und genau die ändern sich fast im Jahresrhythmus.
Versuch doch mal ein 3D Programm statisch zu linken... Geht einfach nicht zu 100%
Zeig mir den Syscall, der sich geändert hat. Das Userspace-Interface des Kernels ist faktisch in Stein gemeißelt. Was da einmal aufgenommen wurde, wird so gut wie nie geändert.
Wenn man derart anfängt zu kritisieren, sollte man schon wissen, worüber man überhaupt spricht.

In 10 Jahren wird die Software auch nicht mehr laufen.
Du solltest dich auf den Jahrmarkt setzen. Mit deiner Glaskugel fällst du da unter all den anderen Weissagern auch nicht auf.

nebenbei , du nervst mit Fanboy gelaber.

Die Begründung ist ja auch eine Kindergartenbegründung. Deshalb wird die auch so selten wiederholt.
Schon blöd, wenn einem die Argumente ausgehen und das Angebrachte auf Grund von Halbwissen nicht mal bis zum nächsten Satzzeichen hält. Hätte mich auch überrascht, wenn da mal mehr als nur haltloses Geblubber von der gekommen wäre.

PS: Für alle, die so gerne ein stabiles ABI des Kernels sehen würden, hier nochmal die Argumente dagegen:
The Linux Kernel Driver Interface
(all of your questions answered and then some)

Greg Kroah-Hartman <greg@kroah.com>

This is being written to try to explain why Linux does not have a binary
kernel interface, nor does it have a stable kernel interface. Please
realize that this article describes the _in kernel_ interfaces, not the
kernel to userspace interfaces. The kernel to userspace interface is
the one that application programs use, the syscall interface. That
interface is _very_ stable over time, and will not break. I have old
programs that were built on a pre 0.9something kernel that still work
just fine on the latest 2.6 kernel release. That interface is the one
that users and application programmers can count on being stable.


Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.


Intro
-----

It's only the odd person who wants to write a kernel driver that needs
to worry about the in-kernel interfaces changing. For the majority of
the world, they neither see this interface, nor do they care about it at
all.

First off, I'm not going to address _any_ legal issues about closed
source, hidden source, binary blobs, source wrappers, or any other term
that describes kernel drivers that do not have their source code
released under the GPL. Please consult a lawyer if you have any legal
questions, I'm a programmer and hence, I'm just going to be describing
the technical issues here (not to make light of the legal issues, they
are real, and you do need to be aware of them at all times.)

So, there are two main topics here, binary kernel interfaces and stable
kernel source interfaces. They both depend on each other, but we will
discuss the binary stuff first to get it out of the way.


Binary Kernel Interface
-----------------------
Assuming that we had a stable kernel source interface for the kernel, a
binary interface would naturally happen too, right? Wrong. Please
consider the following facts about the Linux kernel:
- Depending on the version of the C compiler you use, different kernel
data structures will contain different alignment of structures, and
possibly include different functions in different ways (putting
functions inline or not.) The individual function organization
isn't that important, but the different data structure padding is
very important.
- Depending on what kernel build options you select, a wide range of
different things can be assumed by the kernel:
- different structures can contain different fields
- Some functions may not be implemented at all, (i.e. some locks
compile away to nothing for non-SMP builds.)
- Memory within the kernel can be aligned in different ways,
depending on the build options.
- Linux runs on a wide range of different processor architectures.
There is no way that binary drivers from one architecture will run
on another architecture properly.

Now a number of these issues can be addressed by simply compiling your
module for the exact specific kernel configuration, using the same exact
C compiler that the kernel was built with. This is sufficient if you
want to provide a module for a specific release version of a specific
Linux distribution. But multiply that single build by the number of
different Linux distributions and the number of different supported
releases of the Linux distribution and you quickly have a nightmare of
different build options on different releases. Also realize that each
Linux distribution release contains a number of different kernels, all
tuned to different hardware types (different processor types and
different options), so for even a single release you will need to create
multiple versions of your module.

Trust me, you will go insane over time if you try to support this kind
of release, I learned this the hard way a long time ago...


Stable Kernel Source Interfaces
-------------------------------

This is a much more "volatile" topic if you talk to people who try to
keep a Linux kernel driver that is not in the main kernel tree up to
date over time.

Linux kernel development is continuous and at a rapid pace, never
stopping to slow down. As such, the kernel developers find bugs in
current interfaces, or figure out a better way to do things. If they do
that, they then fix the current interfaces to work better. When they do
so, function names may change, structures may grow or shrink, and
function parameters may be reworked. If this happens, all of the
instances of where this interface is used within the kernel are fixed up
at the same time, ensuring that everything continues to work properly.

As a specific examples of this, the in-kernel USB interfaces have
undergone at least three different reworks over the lifetime of this
subsystem. These reworks were done to address a number of different
issues:
- A change from a synchronous model of data streams to an asynchronous
one. This reduced the complexity of a number of drivers and
increased the throughput of all USB drivers such that we are now
running almost all USB devices at their maximum speed possible.
- A change was made in the way data packets were allocated from the
USB core by USB drivers so that all drivers now needed to provide
more information to the USB core to fix a number of documented
deadlocks.

This is in stark contrast to a number of closed source operating systems
which have had to maintain their older USB interfaces over time. This
provides the ability for new developers to accidentally use the old
interfaces and do things in improper ways, causing the stability of the
operating system to suffer.

In both of these instances, all developers agreed that these were
important changes that needed to be made, and they were made, with
relatively little pain. If Linux had to ensure that it preserve a
stable source interface, a new interface would have been created, and
the older, broken one would have had to be maintained over time, leading
to extra work for the USB developers. Since all Linux USB developers do
their work on their own time, asking programmers to do extra work for no
gain, for free, is not a possibility.

Security issues are also very important for Linux. When a
security issue is found, it is fixed in a very short amount of time. A
number of times this has caused internal kernel interfaces to be
reworked to prevent the security problem from occurring. When this
happens, all drivers that use the interfaces were also fixed at the
same time, ensuring that the security problem was fixed and could not
come back at some future time accidentally. If the internal interfaces
were not allowed to change, fixing this kind of security problem and
insuring that it could not happen again would not be possible.

Kernel interfaces are cleaned up over time. If there is no one using a
current interface, it is deleted. This ensures that the kernel remains
as small as possible, and that all potential interfaces are tested as
well as they can be (unused interfaces are pretty much impossible to
test for validity.)


What to do
----------

So, if you have a Linux kernel driver that is not in the main kernel
tree, what are you, a developer, supposed to do? Releasing a binary
driver for every different kernel version for every distribution is a
nightmare, and trying to keep up with an ever changing kernel interface
is also a rough job.

Simple, get your kernel driver into the main kernel tree (remember we
are talking about GPL released drivers here, if your code doesn't fall
under this category, good luck, you are on your own here, you leech
<insert link to leech comment from Andrew and Linus here>.) If your
driver is in the tree, and a kernel interface changes, it will be fixed
up by the person who did the kernel change in the first place. This
ensures that your driver is always buildable, and works over time, with
very little effort on your part.

The very good side effects of having your driver in the main kernel tree
are:
- The quality of the driver will rise as the maintenance costs (to the
original developer) will decrease.
- Other developers will add features to your driver.
- Other people will find and fix bugs in your driver.
- Other people will find tuning opportunities in your driver.
- Other people will update the driver for you when external interface
changes require it.
- The driver automatically gets shipped in all Linux distributions
without having to ask the distros to add it.

As Linux supports a larger number of different devices "out of the box"
than any other operating system, and it supports these devices on more
different processor architectures than any other operating system, this
proven type of development model must be doing something right :)



------

Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
Robert Love, and Nishanth Aravamudan for their review and comments on
early drafts of this paper.
Diese Dokumentation wird mit den Kernel-Sourcen ausgeliefert, steht so und in ähnlicher Form in x Mails auf diversen Mailinglisten und ist mit ein wenig Arbeit auch prima über google zu finden. Man muss also nicht unbedingt in den Kindergarten gehen, um die Argumente zu finden.
 
Zuletzt bearbeitet:
@nebulus
Ich mußte über deine Argumentation auf Basis Office schmunzeln.
Du hast recht, Office selbst ist sehr kompatibel, die Spezifikation der VBA-Schnittstelle ändert sich schon mit größeren Updates.
 
Nach welcher ISO Norm oder Zertifizierung sind die Schnittstellen von Windows genormt? So langsam wirds peinlich.


Zeig mir den Syscall, der sich geändert hat. Das Userspace-Interface des Kernels ist faktisch in Stein gemeißelt. Was da einmal aufgenommen wurde, wird so gut wie nie geändert.
Wenn man derart anfängt zu kritisieren, sollte man schon wissen, worüber man überhaupt spricht.


Du solltest dich auf den Jahrmarkt setzen. Mit deiner Glaskugel fällst du da unter all den anderen Weissagern auch nicht auf.


Schon blöd, wenn einem die Argumente ausgehen und das Angebrachte auf Grund von Halbwissen nicht mal bis zum nächsten Satzzeichen hält. Hätte mich auch überrascht, wenn da mal mehr als nur haltloses Geblubber von der gekommen wäre.

PS: Für alle, die so gerne ein stabiles ABI des Kernels sehen würden, hier nochmal die Argumente dagegen:

Diese Dokumentation wird mit den Kernel-Sourcen ausgeliefert, steht so und in ähnlicher Form in x Mails auf diversen Mailinglisten und ist mit ein wenig Arbeit auch prima über google zu finden. Man muss also nicht unbedingt in den Kindergarten gehen, um die Argumente zu finden.

Selten so ein Fanboy geblubber gehört. Du hast ja die Weisheit mit Löffeln gefressen...

Also,
unter Windows GIBT es eine stabile Treiber HAL ! Und hier steht auch nichts still !
Mann könnte soetwas unter Linux auch machen, will man aber nicht. Und zwar weil die ihr tolles Linux nicht mit closed source "verunreinigen" wollen. Und dann kommt die Aufforderung, die Firmen sollen lieber open source Treiber schreiben. Das es in der Realität ganz anders ausschaut sehen die Linux-Entscheider leider nicht. Und das ist das Grundlegende Linux Problem, es wird auf Grund von FREI und GPL und offen, und dynamisch vergessen, dass es nunmal zu 98% die FIRMEN nicht wollen !
P.s. wenn dir die Argumente ausgehen wirst Du wohl beleidigend, was ?

Übrigens kann ich zu 100% Nachweisen, das Linux nicht 10 Jahre lang in Stein gemeißelt ist. Installier mal Suse 6.0 und versuch mal z.B. den Konquerror von damals statisch zu linken und unter Suse 11.1 ans laufen zu bekommen. ES WIRD NICHT FUNKTIONIEREN ! Weil ---> AUFPASSEN du Trollplonk---> Weder die X11, glibc oder Kernel ABI in Stein gemeißelt ist. Und dafür brauch ich keine Glaskugel. Hier gibt es Fakten ! Fakten Fakten Fakten !!
 
Zurück
Oben Unten