Anschaffung von Linux

Ich möchte mir gerne Linux anschaffen, welche Linux-Version ist eurer Ansicht nach die beste?
Von welchem Anbieter? Suse, Redhat...?
Ist Linux sicherer als Microsoft Windows?
Welche Hauptvorteile hat Linux?
Kann man mit Linux genau so komfortabel arbeiten wie mit Windows?

 

Bin halt einfach zu doof und unwissend für diese Thematik ... verzeih es mir. *g*

 

Ok, du kapierst die Beispiele nicht, soll auch nicht weiter interessieren.

 

# Außerdem habe ich nie behauptet, das es Unmengen von statisch gelinkten..., sondern nur, was ja auch richtig ist, dass das Problem eher in Linux auftritt.
Ich will auch nicht dauernd Fragen stellen wie "welches Problem"? Statisches Linken ist jedenfalls kein Problem.

Ist aber auch egal. Und mit Mesa/nVidia-GL: nVidia _ERSETZT_ Mesa (und was weiß ich sonst noch) ja gerade mit eigenen Libs. Die Namensgleichheit und das Überschreiben ist ausdrücklich _ERWÜNSCHT_, das ist sogar das Ziel der ganzen Aktion! Die haben wohl irgendetwas gegen Mesa und DRI. Das ist aber kein Problem von shared Libraries. Du kannst auch einfach eine Lib löschen oder 2MB Müll stattdessen an die Stelle verfrachten, danach läuft auch nichts mehr. Mit irgendwelchen Shared oder DLL-Höllen hat das nicht unbedingt etwas zu tun.

Alle anderen Beispiele sind nicht unbedingt besser gewählt. War bis hierhin sehr amüsant, aber nun hast du genug getrollt und ich habe keine Lust, alles nochmal zu erklären. Du hast das mit den Major-Nummern immer noch nicht kapiert, wie es aussieht. Mußt ab hier dann wohl leider alleine weitermachen.

EDIT:
Wenn du allerdings weißt, warum das Paket von Mozilla für Windows kleiner ist, würde ich das schon noch gerne wissen. Das ist mir nämlich auch häufig aufgefallen. Möglich, daß es daran liegt, daß er unter Linux GTK2-Themes übernimmt, aber soviel kann das nicht sein. Falls du darauf hinaus willst, daß es statisch gelinkt sei, so muß ich dich enttäuschen (ldd ist dein Freund, einfach selbst nachschauen).

 

"Ähm, das Thema hatten wir schon. Du erinnerst dich ... Majorversion ... Minorversion? Ich kann das aber gerne ergänzen erleutern:"

Du wirst es kaum glauben, aber es gibt Unterschiede. Allein mal das Open-Gl-Zeugs, das sich X installiert kann man praktisch vergessen. Aber es steht im Pfad. Major-Version gleich oder nicht: völlig egal. Folge z.B.: ./configure ermittelt die Existenz von OpenGl, aber wir haben nur eine verkrüppelte Version davon und kompilieren kann man vergessen. Der erfahrene Linux-Nutzer wird sich eine zweite Version installieren - gleicher Major-Nr, gleicher Datei-Name aber halt andere Funktionalität

Zur Rendundanz:
Ich war nie für Rendundanz, sondern wollte dir erklären am Bsp. von X bzw. Win, dass der rendundante X-Lib-Schrott andere Anwendungen beeinflussen kann (und irgendwann tappt man unter Linux in die Falle), das rendundante Win-Dll-Zeug aber nur die installierende Anwendung.


Außerdem habe ich nie behauptet, das es Unmengen von statisch gelinkten..., sondern nur, was ja auch richtig ist, dass das Problem eher in Linux auftritt.
In Linux erinnert man sich doch an den Klassiker Netscape 4.x.
Es könnte weiter z.B. sein, dass das Suse-Open-Office ihre font-rendering-lib statisch gelinkt hat. Denn die Fonts, oh Wunder, sehen anders aus als die, die mit der systemweiten Lib gerendert werden. Oder handelt es sich hier um ein schönes Bsp. für Lib-Chaos in Linux, das OO sich vielleicht selbst seine Rendering-Lib installiert, wie übrigens auch X. Beide womöglich im Suchpfad? Beide mit absolut identischer Major-Nr. Ich habe keine Lust, das rauszufinden. OO für Linux braucht man allerdings nicht, denn es gibt ja die Win-Version und da hat man solche Probleme einfach nicht.

Auch das Problem der fehlenden Distributionsmöglichkeit ihrer (binär-)Software hindert übrigens Firmen daran, eine Linux-Version zu entwickeln.
Oder sie linken sich den Motif-Schrott statisch dazu wie einst Netscape oder evtl. auch Acrobat beim Reader.
Oder sie erlauben sich den Spaß, für jede Distribution und jede Eventualität ein kleines Päckchen zu schnüren.

Du kannst dir ja mal überlegen, warum der Download von Mozilla für Linux mehr Megabytes anbietet als der für Windows.
Und für alle Mozilla-Freunde noch einen Tipp: die Windows-Version hat einige nette Extras.

 

# Passiert ja in Linux auch immer häufiger (opt/mozilla/lib/, /opt/gnome/lib) kennt man ja.

Kenne ich nicht. Und ich verabscheue, ja hasse /opt regelrecht. Ich halte /opt für absolut sinnlos. Wenn schon, dann /usr/opt, aber viel besser finde ich das auch nicht. Viele Distributoren kommen schon mit /usr/bin und /usr/local/bin nicht zurecht ... und jetzt auch noch /opt. Naja, nicht mein Problem.

Vielleicht hast du trotzdem ein Beispiel, auch wenn Libs wunderbar in verschiedenen Verzeichnissen in unterschiedlicher Version installiert sein können. (Das wäre das dritte, zu dem ich dich auffordere. Langsam mußt du mal was hinbekommen ...)

 

# Dass X vielleicht 10 redundante Libs oder mehr installiert, die teilweise andere Schnittstellen haben und warum das zum Chaos führt, wollte ich dir erklären. Aber ganz von vorn anfangen muss nicht sein.
Komisch, eben warst du noch für Redundanz (jedes Programm bringt eigene Libs mit und installiert sie in sein Verzeichnis). Bitte entscheiden sie sich jetzt ... tick, tack, tick, tack ... Und von vorne Anfang muß wirklich nicht sein. Liefer mir doch einfach endlich mal ein Beispiel.

# Das man binäre Software gerade unter Linux häufig mit statisch gelinkten Libs distributiert
Bla bla bla ...

(0)[bastiaf@vulpec:~]% find $path -type f -print0 2&>/dev/null | xargs -0 file | grep dynamic | wc -l
1151
(0)[bastiaf@vulpec:~]% find $path -type f -print0 2&>/dev/null | xargs -0 file | grep static | cut -f1 -d:
/sbin/nologin
/sbin/devd
/bin/sh
/usr/sbin/pccardc
/usr/sbin/pccardd
/usr/bin/ar
/usr/bin/as
/usr/bin/ld
/usr/bin/ranlib
/usr/bin/gdb
/usr/bin/cc
/usr/bin/gcc
/usr/bin/make

Ui, 13 statisch gelinkte Executables und 1151 dynamisch gelinkte. Ne du, ich glaube du hast wirklich recht, das meiste "wird mit statisch gelinkten Libs distributiert". Nagut, fairerweise muß man hier eingestehen, daß obiges nicht auf einem Linuxsystem ausgeführt ist, aber dort ist es genauso (bevor jemand aufschreit, soll er es doch erstmal testen! ). Es müssen nicht zwangsläufig 13 sein, der eine Distributor hat /bin und /sbin statisch gelinkt, der andere nicht. Die Zahlen sollten sich aber ebenfalls in dem Bereich befinden.

Aber ich möchte dir natürlich trotzdem die Chance auf ein Beispiel für die Unmengen statisch gelinkten Applikationen geben. Nur zu, halte dich nicht zurück.

Wenn du einen besseren Einblick in Linux hättest, wüsstest du es auch.
Logisch ...

# Keine Linux-Anwendung wird daran gehindert, ihre Libs in ein eigenes Verzeichnis zu installieren, allein um dem Chaos zu entgehen, dass man vielleicht in /usr/lib installierst, die Version aber nie aktiv wird, weil in /lib schon eine ältere Version residiert.
Ähm, das Thema hatten wir schon. Du erinnerst dich ... Majorversion ... Minorversion? Ich kann das aber gerne ergänzen erleutern:
ld.so läd/linkt immer die Library mit der entsprechenden Major-Nummer und es ist ersichtlich, daß libblub.so.5 und libblub.so.6 parallel existieren können. Du kriegst auch nicht recht, wenn du deine Behauptungen hartnäckig wiederholst (glaube ich zumindest.

Ach ja, und zu einer alten Version in /lib und einer neuen in /usr/lib ... das wäre schonmal merkwürdig, denn es handelt sich bis auf den Versionsunterschied um die selbe Lib, warum sollte die sich plötzlich woanders befinden? Entweder gehört sie nach /lib oder /usr/lib, beides ist eher unsinnig. Aber nagut, nehmen wir halt an, es wäre so. Wenn es die selbe Datei ist (libblah.so.5 bspw), ist es egal, welche er wählt. Ist es eine andere (/lib/libblah.so.5 und /usr/lib/libblah.so.6), dann nimmt er die, die er nehmen muß. Benötigt ein Binary 5, dann kriegt es 5. Braucht es 6, kriegt es 6. Was meinst du, ist jetzt hier genau das Problem?

 

Eben nicht nachvollziehbar für dich.
Deswegen macht es auch keinen Sinn. Das Bsp. mit X begreifst du nicht mehr. Dass X vielleicht 10 redundante Libs oder mehr installiert, die teilweise andere Schnittstellen haben und warum das zum Chaos führt, wollte ich dir erklären. Aber ganz von vorn anfangen muss nicht sein.

Das man binäre Software gerade unter Linux häufig mit statisch gelinkten Libs distributiert, was man eben in Windows weit seltener - eigentlich nie - muss, könnte man einsehen. Genau das Gegenteil von dem was du schreibst, ist die Realität.
Wenn du einen besseren Einblick in Linux hättest, wüsstest du es auch.

Deinem ganzen Geschreibe mit der Rendundanz entnehme ich, dass es zu schwierig für dich wird. Es ist grundfalsch, s.o. das Bsp. mit X. Oder besser: lass es bleiben.
Keine Linux-Anwendung wird daran gehindert, ihre Libs in ein eigenes Verzeichnis zu installieren, allein um dem Chaos zu entgehen, dass man vielleicht in /usr/lib installierst, die Version aber nie aktiv wird, weil in /lib schon eine ältere Version residiert. Passiert ja in Linux auch immer häufiger (opt/mozilla/lib/, /opt/gnome/lib) kennt man ja.

"Solange es mich amüsiert, ist die Welt aber ok."
Wie schon mal geschrieben.
Der Narr ist glücklich, denn er weiß nicht....

 

Axo, mein Hauptargument habe ich vergessen:
Das weiß eigentlich auch jeder, der Linux besser kennt.

 

# X installiert parallel zu den libs in /usr/lib bzw. /usr/local/ zahlreiche eigene Versionen in /usr/X11R6/lib...
Bla bla bla ...
Wohin sonst, wenn nicht /usr/X11R6, genau dort gehören sie hin. Alles, wie es sein sollte:
(0)[bastiaf@vulpec:~]% pkg_info -xL XFree86 | egrep '^(/lib|/usr/lib|/usr/local/lib)' | wc -l
0
(0)[bastiaf@vulpec:~]% pkg_info -xL XFree86 | egrep '^/usr/X11R6/lib' | wc -l
5663

# Man hat bei einem normalen Linux-System garantiert zwei Libs, die eigentlich die selbe Funktionalität bieten sollen
Warum sollten zwei Libs die gleiche Funktion anbieten? Kommt sicherlich vor, macht aber keinen Sinn und sollte vermieden werden. Redundanter Code, doppelt so große Anzahl potentieller Fehler, größerer Speicherverbrauch auf HDD und RAM, doppelte Programmierarbeit, doppelte Wartungsarbeit. Bzw. dreifach, oder vierfach, oder fünfach, ... Von Sollen kann da nicht die Rede sein.

# Gutes Bsp. für die Linux-Lib-Probleme.
Nein, nur sinnfreies Blabla. Komm doch einfach mit einem konkreten Beispiel, dann wird vielleicht sogar mal klar, von was du eigentlich schreibst.

# Anwendungspfade (unter Windows) sind systemweit nicht bekannt/gesetzt.
Du meinst Suchpfade für den Runtime-Linker? Dann schreib doch nicht so, daß man andauernd raten muß. Du glaubst aber jetzt nicht wirklich, daß ld.so systemweit sucht, oder?

# D.h. eine Anwendung installiert eine Dll nur für sich selbst oder fürs System, das ist die Konvention.
Das ist einfach nur höchstgradig schwachsinnig und glücklicherweise auch bei Microsoft nicht immer der Fall. Argumentation kommt weiter unten.

# Oder wo soll da ein Problem sein?
Das ich hier mit jemanden rede, der entweder absolut gar keine Ahnung hat oder mich verarschen will. Bin mir noch nicht sicher. Solange es mich amüsiert, ist die Welt aber ok.

Es ist nur so, dass es mehrere Standard-Orte gibt, deren libs sich u.U. in die Quere kommen.
Was meinst du mit "in die Quere kommen"? Es kann zwar theoretisch durchaus vorkommen, daß zwei Entwickler, die nichts voneinander wissen, zwei Libs mit selben Namen unabhängig voneinander veröffentlichen, die unterschiedliches tun. Dann hätte man ein Problem, aber bis jetzt konnte man immer eindeutige Namen finden. Wie haben ja genug Buchstaben im Alphabet.

# Zu binär-inkompatiblen Libs und Anwendungen: Riesenproblem unter Linux, v.a. auch für die Distribution von Software
Prima, dann hast du ja ein Beispiel parat.

# warum Windows klar weniger Probleme bzgl. der Shared Libs bietet als Linux, weil jemand so einen inkompetenten Unsinn von der sog. Dll-Hölle schreibt.
Danke ... *g*
Du bist echt lustig, willst mir hier redundante Implementationen (jedes Programm eigene DLLs) als Vorteil verkaufen? Hihi ...
Das führt wie gesagt den Sinn von Shared Libraries ad absurdum und wurde von mir oben schon längst als Nachteil aufgelistet. Aber von mir aus gerne noch mal, copy&paste kostet ja nichts:
Redundanter Code, doppelt so große Anzahl potentieller Fehler, größerer Speicherverbrauch auf HDD und RAM, doppelte Programmierarbeit, doppelte Wartungsarbeit. Bzw. dreifach, oder vierfach, oder fünfach, ... Dazu kommt, daß du auftretende Fehler nicht mehr einmal patchen, sondern x-mal fixen und x-mal patchen mußt. Das jedes Programm eigene Libraries mitbringt ist genauso unsinnig wie statisches Linken. Du bist mir echt witzig ...
Und ja, es gibt unter Windows auch keine Probleme, weil oft einfach statisch gelinkt wird. Warum? Ganz einfach, weil das Problem mit Shared Libs unter Windows eben eine Hölle ist.

Die Gründe sind genannt und leicht nachvollziehbar.
Tja, eine sich auf Blabla stützende Argumentationsbasis ist immer trivial und sogar für einen inkompetenten unsinnverbreitenden Menschen wie mich nachvollziehbar.

 

X installiert parallel zu den libs in /usr/lib bzw. /usr/local/ zahlreiche eigene Versionen in /usr/X11R6/lib...
Man hat bei einem normalen Linux-System garantiert zwei Libs, die eigentlich die selbe Funktionalität bieten sollen (was sie aber zur Verärgerung des Users sicher nicht exakt tun) im Suchpfad drin. Gutes Bsp. für die Linux-Lib-Probleme. Ein sicherer Stolperstein für jeden, der Linux ernsthaft benutzen will, d.h. auch mal eine Software selber kompiliert, was aus oben genannten Gründen notwendig ist.

Anwendungspfade (unter Windows) sind systemweit nicht bekannt/gesetzt. D.h. eine Anwendung installiert eine Dll nur für sich selbst oder fürs System, das ist die Konvention. Fürs System ist alles klar, da ein zentraler Ort und normal nur ein Update erfolgt und im anderen Fall auch, dann benutzt halt die Anwendung die Dll, die sie installiert hat, beeinflusst aber keine andere Anwendung. Ist ganz einfach zu verstehen. Oder wo soll da ein Problem sein?
In Linux können die libs auch überall liegen. Es ist nur so, dass es mehrere Standard-Orte gibt, deren libs sich u.U. in die Quere kommen. Und es wird so kommen, lässt sich gar nicht vermeiden. Jeder der mit Linux ernsthaft arbeitet, wird so einen Fall erleben.

Zu binär-inkompatiblen Libs und Anwendungen: Riesenproblem unter Linux, v.a. auch für die Distribution von Software. Trotzdem keine Lust, darauf genauer einzugehen. Es weiß eigentlich auch jeder, der Linux besser kennt.

"Aber du kannst ja immer noch ein paar hunderttausend Files per Hand verwalten, wenn du der Meinung bist, das ginge besser."
Es ging nur daum, zu zeigen, warum der Package-Manager die Sache nach kurzer Zeit nicht mehr im Griff hat und insgesamt v.a. darum, warum Windows klar weniger Probleme bzgl. der Shared Libs bietet als Linux, weil jemand so einen inkompetenten Unsinn von der sog. Dll-Hölle schreibt. Die Gründe sind genannt und leicht nachvollziehbar.

 

# aber im Grunde nicht zu pflegen und damit nett gemeint
Nunja, besser du als ich. Hauptsache ich habe keine Probleme. <:
Aber du kannst ja immer noch ein paar hunderttausend Files per Hand verwalten, wenn du der Meinung bist, das ginge besser. Viel Spaß. <:

# Nutzt trotzdem meisten nichts, da z.B. X allein sich
# für viele Dinge eine eigene Lib parallel installiert
Verstehe ich nicht. Parallel zu was? Und was hat das mit Prefix zu tun? Eigentlich gar nichts, oder?
Was auch immer du meinst, Libs werden immer relativ zu EPREFIX installiert, sofern nicht explizit libdir spezifiert wird.

# Das eine Lib u.U. nicht mehr (binär-)kompatibel zu
# anderen Komponenten ist, darauf kein Eingang jetzt.
Major-Versionen sind natürlich inkompatibel in den bereitsgestellten Funktionen, aber wen stört das? Richtig, eigentlich niemanden. Mit Binärkompatiblität hat das nichts zu tun ... du scheinst mir etwas verwirrt zu sein oder nicht wirklich zu wissen, wovon du redest. Naja ...

# Alles in allem, ist mit der zentralen Lokation
# (Sys32) leichter auskommen.
Wenn es denn so wäre, ist aber nicht so. Wo sie überall liegen können (und das ist einfach gesagt überall), wurde ja oben schon erwähnt.

# Anwendungspafde sind schließlich nicht systemweit
Verstehe ich nicht (auch nicht den Kontext).

# Im übrigen hat auch Windows einen Paketmanager.
Wie update ich dort alle Pakete? Wie liste ich mir auf, welche Files zu einem Paket gehören? Ach ja, darauf habe ich als Anwender keine Kontrolle. Naja, sehr sinnig ...

 

"Warum deinstallierst du nicht einfach die vom Paketmanager installierte Version, wenn du sie nicht mehr haben willst? "

Sag ich doch, der Paketmanager ist zwar auf den ersten Blick ganz schön, aber im Grunde nicht zu pflegen und damit nett gemeint, aber am Ende steht man doch im Regen.
Klar, man könnte dem Paketmanager und damit dem OS vortäuschen, das das Paket doch installiert ist (damit z.B. Yast2 mit allem klar kommt). Aber das ist doch alles ein Krampf.
Die ganzen Optionen wie prefix usw. kenn' ich. Nutzt trotzdem meisten nichts, da z.B. X allein sich für viele Dinge eine eigene Lib parallel installiert (und der Pfad dazu ist systemweit bekannt).
Das eine Lib u.U. nicht mehr (binär-)kompatibel zu anderen Komponenten ist, darauf kein Eingang jetzt.
Alles in allem, ist mit der zentralen Lokation (Sys32) leichter auskommen.
Anwendungspafde sind schließlich nicht systemweit. Im übrigen hat auch Windows einen Paketmanager. Es gibt nur keinen Anwender-Zugriff darauf.

 

@ dummerl

Bist du dir sicher, dass du da auch nichts verwechselst? debian hat gar keine hardwareerkennung...

 

Hallo,

betreffend der (problemlosen) Installation, habe ich die Erfahrung gemacht, daß die Debian-Ausführung besser mit den Rechnerkomponenten klarkommt, als Suse Linux (hier 7.0 prof.).

Bei Suse 7.0 waren noch etliche ins Detail gehende Infos einzugeben bezüglich der Komponenten, so daß ich die jeweiligen Handbücher der Komponenten herauskramen mußte.

gruß
dummerl

 

@pcw_ano:
# Was Mozilla will, versteht KDE nicht, was Gnome will, versteht Emacs nicht usw... Typ.
Bischen unschön, daß KDE und GNOME nicht die gleichen Einstellungen nutzen (Mozilla nutzt die GTK-Einstellungen, Emacs die des Terminal Emulators).
Könnte sich jedenfalls mal etwas ändern, aber es wird trotzdem immer Applikationen geben, die eigene Einstellungen haben, wie unter Windows auch (bspw. JBuilder, Editoren, Winamp-Playliste, ...).

Weiß nicht welche Linux-Version du benutzt
Zeigt dann wohl, daß du den Thread nicht richtig gelesen hast. Ich nutze kein Linux.

# Und besser kriegt man's nicht, wenn man nicht selber erzeugt.
Meinst du damit X kompilieren? Wie weiter oben gesagt, ist das unsinnig. Das gleiche gilt für den Font-Server. Bzw. welche Optionen beim Kompilieren meinst du konkret?

#Die selbst kompil. Lib installiert sich dann per Default nach /usr/local/lib und die übrige gebliebene Leiche in /usr/lib/ bleibt dann blablabla man kann sich's ja denken.
Warum deinstallierst du nicht einfach die vom Paketmanager installierte Version, wenn du sie nicht mehr haben willst? Du kannst dich doch nicht beschweren, daß Files übrig bleiben, wenn du die alte Version nicht löscht. Alternativ könntest du, wenn du es schon selbst kompilierst, mit --prefix oder zumindest --libdir den Pfad auch umsetzen, aber /usr/local ist schon korrekt. Und letztendlich kannst du für sowas auch komplett eigene Verzeichnisse benutzten, mir ist das zumindest immer lieber. Einfaches löschen des Verzeichnisses und Ruhe ist, damit kommt man dem Paketmanager nicht in die Quere. Der Dynamic Linker linkt neben den Standardverzeichnissen alle in /etc/ld.so.conf aufgeführten, das ist also auch kein Problem.

Harmlos ist die DLL-Hölle auch nicht wirklich, sondern ein riesiges Problem. Lies dir am besten erstmal den Link von mir durch, dann können wir darüber diskutieren.
Mit Shared Libs hast du aber eigentlich immer mehr oder weniger Probleme, bzw. unschöne Situationen, bei dem einen OS mehr, beim anderen weniger.


@hotzenplotz10:
Nunja, ich studiere zwar Informatik, aber das ist mehr Mathematik und Theorie als alles andere. Betriebssysteme kamen noch nie dran.

So gesehen hängt das damit nicht direkt zusammen, das Interesse für Informatik (und auch Betriebssysteme) allgemein besteht aber grundsätzlich.

 

@cirad
Weiß nicht welche Linux-Version du benutzt, aber ich habe in den letzten Wochen paar ausprobiert und alle Suse, Slackware, Knoppix, Mandrake haben per Default keine brauchbare Fontdarstellung. Bei deinen Screenshots sieht's hingegen gut aus.
Wobei man in Linux keine Fonteinstellunge systemweit sinnvoll vornehmen kann. Was Mozilla will, versteht KDE nicht, was Gnome will, versteht Emacs nicht usw... Typ. Beispiel dafür, woran es hapert.
Ich gehe bei schlecht gerenderten Fonts übrigens von Truetype-Schriften aus. Suse könnte ich mir mit der Default-Einstellung nicht antun. Und besser kriegt man's nicht, wenn man nicht selber erzeugt. Die selbst kompil. Lib installiert sich dann per Default nach /usr/local/lib und die übrige gebliebene Leiche in /usr/lib/ bleibt dann blablabla man kann sich's ja denken. Auf keinen Fall vglbar. mit der sog. vollkommen harmlosen Dll-Hölle.

Meistens, wenn man einem Linux-Jünger erklärt, was Scheiiße ist unter Linux, dann erklärt er, warum es (ausgerechnet) bei ihm eben nicht Scheiiße ist, und zeigt dann stolz Scheiiße vor.
Und wenn er noch so dran rumkonfiguriert.
Vielleicht bis du ja eine Ausnahme bei der alles läuft, was ich nicht glaube, aber man muss von der Masse der Distributionen ausgehen.

Zum Rest könnte ich noch was schreiben. Muss aber nicht sein, aus erwähntem Grund.

 

@cirad

Hat ein bisschen gedauert, aber hier meine Antwort.

Zu den Englischkenntnissen - da hast du recht, geht aber.
Unter Suse ist die deutsche Dokumentation recht gut.

Wenn ich mir deine postings so durchlese denke ich mal dass du Software/Informatic/PC studiert hast oder es beruflich ausübst.
Wenn dem so ist dann betrachten wir das ganze natürlich aus komplett anderen Blickwinkeln. Ich kratze bei den Betriebssystemen ja lediglich an der Oberfläche während du dich explizit damit beschäftigst.
Dann stimmt es natürlich auch -wie du schreibst - dass die Leute keine Lust haben sich Wissen anzueignen, oder, eben nicht die Zeit dafür haben.
Egal, ich werde mich auch wieder mit Linux beschäftigen auch wenns nur eine Mainstream-Distro ist.

Schönen Sonntag noch

Wolfgang

 

Keine Angst, den Trollversuch habe ich bemerkt, aber genauso Lust, darauf einzugehen.

Unklar sehen? Scheint mir eher ein Fall für den Augenarzt zu sein. Und große Dokumente mit MS-, Star oder Open-Office klingen stark nach einem Oxymoron.

Der Vergleich der Geschwindigkeit mit dem IE ist eine äußerst interessante Sache, wurde der Unix-IE doch schon seit langem eingestellt. Egal, den gab es sowieso nur für HP-UX und Solaris, für beide existiert kein API-Mapping unter Linux. Jetzt mußt du dir nur noch Gedanken darüber machen, warum er von MS eingestellt wurde und dann sehen wir weiter.

 

also ich finde das Vorhandensein von Linux klasse, hält es doch die Preise meines Lieblings-OS (Windows) am Boden. Auch lüge ich manchmal öffentlich das Linux ganz brauchbar wäre, um den Marktstrategen von MS den Preis zu 'versalzen'. Habe immer zwei Wechselplatte auf der selben HW im Einsatz.

Fazit: wer nur mal etwas surfen will und akzeptiert, das er nicht alle Seiten im Internet klar sehen kann, für dem ist Linux o.k;

Wer es allerdings gewohnt ist mit seinen Office mehr als nur einseitige Dokus zu schreiben, oder noch viel schlimmer mit Excel mehr als nur 2 Zahlen zu addieren, der bekommt mit den von mir bisher getesteten Office-Alternativen unter Linux graue Haare.

Also erst mal festlegen was man mit seinen Computer anstellen will - dann das OS auswählen.

Da ich bewusst einen P2 mit XP bzw. Linux teste, weis ich erst mal wie viel schneller XP gegenüber z.B. Suse ist - sofern es sich um Office-Programme und Internet Explorer handelt. Über andere Programme kann ich im direkten Vergleich allerdings keinen Angaben machen.

Solange es kein MS-Office und IE für Linux gibt, ist für mich Linux als OS völlig unbrauchbar.