Linux Flame

Danke für den Link ... muss ich später gleich mal testen. :)

lG

Brabax
 
Achja @bit mal rein interessehalber,
Was hat dich eigentlich dazu gebracht, deine Meinung zu XFCE so radikal zu ändern?
Ich hatte mich nämlich gerade erinnert, da mal diesen Blogeintrag von dir gelesen zu haben:
http://bitmuncher.blog.de/2008/07/14/von-kde-zu-xfce-4449006/ hat gesagt.:
Kurz gesagt: XFCE hat mich überzeugt und hat in den letzten Tagen bewiesen, dass er alle Funktionalitäten bietet um ihn für mich als Alternative zu KDE attraktiv zu machen. Er ist als Alternative zu KDE vor allem durch die ähnliche Bedienung weitaus besser geeignet als Gnome. Vorerst wird er wohl auch erstmal mein Standard-Desktop bleiben.

Dann hatte ich noch gesehen:
http://bitmuncher.blog.de/2009/07/01/lxde-neuer-desktop-6428787/ hat gesagt.:
und nachdem ich diese Desktop-Umgebung nun eine Weile ausprobiert habe, steht fest, dass ich wohl vorerst dabei bleiben werde. Auch wenn er noch nicht als ausgereift bezeichnet werden kann, bietet er schon jetzt fast alles, was ich so brauche.

Und jetzt kommst du mit "Windows95-ähnlicher Funktionalität"?
 
Bitmuncher kann ich voll und ganz zustimmen.
Ich habe immer versucht bei Problem mich mit dem System zu beschäftigen und eine Lösung zu finden, trotzdem hatte ich fast alle von Bitmuncher genannten Probleme.
 
Ist euch aufgefallen, dass man bei den wenigsten großen Distris noch eine Desktopfreie Installation machen kann? Man installiert ca. 5 Millionen Gigabyte Programme und Defaultsoftware, die man dann mühsam wieder Stück für Stück entfernt und bei jedem Paket betet, dass das System gleich noch funktioniert.

Also bei *buntu geb ich dir recht (wobei es da auch noch eine Alternativ-Version gibt, wo du mehr Kontrolle über die zu installierenden Pakete hast...)

Aber bei Debian kann man sehr wohl problemlos eine Minimal-Installation machen.
Während der Installation wird an einer Stelle mal tasksel ausgeführt, womit der Anfänger einfach den Haken bei "Desktop-Umgebung" drin lässt und der erfahrene Linux-Nutzer, der seine eigenen Vorstellungen von einem schönen System hat, kann den Haken raus nehmen und per apt-get die Desktop-Umgebung seiner Wahl installieren (ich bin z.B. mit xfce4 voll zufrieden)

Und wenn Gentoo's Installation immer noch nach den gleichen Idealen funktioniert wie vor 3 Jahren, dann hat man da auch die volle Kontrolle über sein System... und mit emerge hatte ich auch noch nie Probleme von wegen "kaputt-updaten" - klar, man musste manchmal zwischen den gcc-Versionen hin und her switchen, das war nervig... aber ansonsten ging's problemlos... bin nur dann wieder zu Debian zurück, da es mir auf meinem alten Lappi zu lange gedauert hat, jedes Paket erst zu kompilieren...



Aber mal 'ne Frage an Bitmuncher:
ich hab mich zugegeben noch nie sooo genau mit Kernel-Architektur auseinander gesetzt - aber wie würdest du den Hurd-Kernel einmal im Gegensatz zu Linux und einmal im Gegensatz zu *BSD oder OpenSolaris einschätzen? Hast du da auch schon Erfahrungen mit gemacht?

Bin nämlich gerade am Überlegen, ob ich mal Debian GNU/Hurd probieren soll...
 
@beavisbee: Ich hab mir den Hurd-Kernel im Detail noch nicht angeschaut, aber ich halte eine Mikrokernel-Architektur allgemein für leichter wartbar und wenn sauber programmiert auch für sicherer als klassische monolithische Kernel. Es gibt einfach weniger mögliche Fehlerquellen, die z.B. das Rechtemanagement betreffen, da es dafür saubere Schnittstellen zum Kernel gibt, die genutzt werden müssen. Unter Linux hingegen kann man quasi jede Kernel-Funktion direkt aufrufen ohne sich an restriktete Schnittstellen halten zu müssen. Das macht die Entwicklung zwar einfacher, aber nunmal auch fehleranfälliger.

@Chris_XY: Ansprüche und Erfahrungen ändern sich. Wenn man mal einen modernen Desktop genutzt hat und mehr auf Usability als auf Minimalistik achtet, wird man sehr schnell feststellen, dass DMs und WMs wie LXDE oder XFCE lediglich die Basis-Funktionalitäten umsetzen, die man eben auch unter Windows95 schon kannte. Wenn man sich dran gewöhnt hat, ist das auch vollkommen ausreichend und sofern ich an einem Linux-Desktop arbeiten muss, bevorzuge ich immernoch LXDE, da er Shortcut-mäßig und Look&Feel-mäßig sehr nah an KDE3 rankommt. Wenn ich aber die Wahl habe, nutze ich lieber ein MacOSX mit netten Grafik-Effekten, immer gleich aussehenden Fenstern, immer gleichen WM-Shortcuts und erweiterten Funktionalitäten wie in den Desktop integrierten Dateimanager, Indexing-System usw. Mit solchen Funktionalitäten kann sich unter Linux höchstens KDE oder Gnome messen und bei denen ist sowas zumeist sehr ressourcenfressend umgesetzt.

Ein einfaches Beispiel: Nutze ich unter MacOS oder Windows auf einem Laptop einen 3D-Bildschirmschoner, bleiben die Lüfter weiter im Idle-Betrieb. nutze ich hingegen unter Linux einen OpenGL-Bildschirmschoner, springen schon nach kurzer Zeit die Lüfter an, weil die Grafikkarte und die CPU hochgetaktet werden müssen, damit die Darstellung flüssig ist. Ich nutze aber nunmal bevorzugt Laptops um Strom zu sparen, da kann ich es nicht gebrauchen, dass die auf Hochleistung laufen, nur weil der Bildschirmschoner anspringt. Ich hab aber auch keine Lust auf 3D-Bildschirmschoner zu verzichten, nur weil die OSS-Community es nicht auf die Reihe bekommt mal ihre GL-Schnittstellen anständig zu implementieren. Ergebnis: Ich verzichte lieber auf OSS-Software als auf Komfort.

Ein weiteres Beispiel für die Unzulänglichkeit von OSS. Ich nutze ja nun relativ gern Twitter. Schonmal Twitter-Clients von Linux und Mac verglichen? Ich schon und ich musste feststellen, dass es unter Linux keinen Client gibt, der auch nur annähernd die Funktionalitäten umgesetzt hat, die ich mittlerweile mit Tweetie auf dem Mac habe. Das hat mich auch nicht weiter gestört, weil ich es nicht anders kannte. Mittlerweile kenne ich es aber anders und bin nicht mehr bereit darauf zu verzichten. Würde ich aber alle Funktionalitäten, die ich mittlerweile durch ein kommerzielles OS gewohnt bin, unter Linux nachbilden wollen, würde ich meine sämtliche Freizeit mit Programmieren verbringen müssen.

Kurzum: Ich habe einfach keine Lust mehr ständig auf Funktionalitäten zu verzichten und seien es so einfache Dinge wie 3D-Bildschirmschoner, Indexing sämtlicher Daten auf meinem Rechner oder einen anständigen Twitter-Client. Nachdem ich einmal bereit war mich auf kommerzielle Software einzulassen, musste ich einfach feststellen, dass diese qualitativ hochwertiger ist, als alles, was ich jemals im OSS-Bereich kennengelernt habe. Bis auf wenige Ausnahmen (z.B. OpenOffice oder Firefox) ist OpenSource-Software zumeist funktional als auch in der Benutzerfreundlichkeit minderwertiger als vergleichbar kommerzielle Tools. Die OpenSource-Software, die qualitativ wirklich hochwertig ist, entstammt aber zumeist ehemals kommerziellen Produkten (OpenOffice von StarOffice, Firefox von Netscape, OpenSolaris von Sun Solaris usw.) und wird auch zumeist noch unter der Schirmherschafft der Firmen weiterentwickelt.

Damit OSS sich in Zukunft noch mit kommerziellen Programmen messen kann, wird das "Ich entwickle Software für mich" zu "Ich entwickle Software für mich und die Community" werden müssen, wie man es z.B. derzeit bei OpenSolaris erlebt. Solange dieses Umdenken nicht erfolgt, wird OSS immer ein Nischenprodukt bleiben, das gegen andere Systeme und Software nur verlieren kann. Die Eingefahrenheit der Kernel-Entwickler ist dabei nur eines von vielen Beispielen.
 
"Damals" hat das installieren von Linux (und den BSDs) richtig viel Spass gemacht. Das war jedesmal ein echtes Abenteuer! Diese Sicht ist wenig professionell und eher heim-tüftler mässig. Aber letztendlich ist Linux genau das gewesen. Die Jahre vergehen und Linux wird verbreitet. Firmen fangen an, Linux zur Kenntnis zu nehmen. Nicht als hochwertiges System- sondern als einen pool kostenloser Entwicklerkraft. Man muss nur etwas hineingeben, seine Seele verkaufen(GPL) und bekommt vielleicht etwas halbwegs entwickeltes heraus. Wenn das nicht zieht entwickelt man selbst ein bischen oder bezahlt ein paar OSS Prostituierte(NDA) mal eben Treiber zu entwickeln. Der ist dann zwar OpenSource, aber keine Sau hat Doku zu dem Geraet, was das ganze fuer andere nahezu unbrauchbar macht.

Mittlerweile hat ein Teil der Computerindustrie auf Linux umgesattelt und der Gemeinde die Zuegel aus der Hand genommen.

Der massgebliche Erfolgsfaktor von Linux im "normaluser-Desktop" Bereicht deckt sich mit dem aller anderen Betriebssysteme: Multimedia und Spiele. Hier gibt es allerdings schon zwei etablierte Konkurrenten, die in jedem dieser Bereich wesentlich besser und erfahrener sind: Windows und MacOS. Linux hat wahrscheinlich erst dann im Desktopbereich etwas zu melden wenn die Leute sagen "Das ist genauso wie Windows". Da frage ich mich allerdings, warum nehmen die nicht gleich Windows?
 
Hinzu kommt diese unsinnige Versessenheit auf die monolithische Kernelstruktur, die schon in den 90er Jahren als veraltet galt. Aber die Herren Kernel-Entwickler sind ja so 1337, dass sie lieber in megabyteweise Code rumwühlen anstatt einen Mikrokernel aufzubauen, der sich wesentlich leichter verwalten liesse und weniger Angriffspunkte für Sicherheitslücken- und schwächen hätte. Da würde niemand einfach die Rechteverwaltung mit einem Modul umgehen können, wie man es beim wunderbar_emporium-Exploit erleben durfte.
Frage: Wäre es überhaupt möglich Linux so komplett umzuschreiben? Würde das das Projekt nicht Quasi auf den Stand zu Zeiten von 0.01 zurückwerfen?
 
Ich denke auch, dass ein umgeschriebener Kern zwar zeitgemäßer, aber dennoch weniger aktuell wäre.
Denn die Zeit, die es braucht um den Kern umzuschreiben, würde in einem parallel dazu weiterentwickelten monolithischen Kern ja Aktualisierungen erlauben, die dann in der umgeschriebenen Version eben nicht vorhanden wären.
Damit würden sich die Kerne rein technisch unterscheiden, dazu kommt, dass es dann mit Updates die beide Kerne benötigen länger dauern könnte - sofern das Kernelupdate dann noch so einfach gemacht ist. Denn woher weiß der Linux-DAU, ob er den monolithischen oder den neuen Kern hat?
 
Frage: Wäre es überhaupt möglich Linux so komplett umzuschreiben? Würde das das Projekt nicht Quasi auf den Stand zu Zeiten von 0.01 zurückwerfen?

Am Linux-Kernel entwickeln tausende Entwickler mit. Im Release des 2.6.24er Kernels gab es knapp 10.000! Änderungen zur Vorversion. Zwischen des Releases von 2.6.0 und 2.6.29 sind 5,8 Millionen Zeilen Code hinzugekommen. Der Code hat sich somit mehr als verdoppelt und wie wir wissen, ist eine Menge Kram hinzugekommen, den kaum jemand braucht. Ein Rewrite der Basis hätte nur einen Bruchteil dieses Aufwands ausgemacht, da man bestehende Algorithmen zum Großteil übernehmen könnte. Der Grund, warum es nicht getan wird, ist vielmehr, dass (zu Recht) befürchtet wird, dass viele Treiber nicht in den neuen Kernel einfliessen würden, da die Entwickler dieser Treiber nicht mehr aktiv sind. Das absurde daran ist, dass genau dadurch die hohe Sicherheitsproblematik im Kernel-Code liegt. Es gibt tausende von Codezeilen, die sich seit Jahren niemand mehr angeschaut hat, die aber ggf. in Verbindung mit anderen Bestandteilen des Kernels zu Sicherheitsproblemen führen können. wunderbar_emporium war ein gutes Beispiel dafür. Anstatt sich also zu fragen "Wollen wir weiterhin einen Kernel entwickeln, von dem wir wissen, dass er Sicherheitslücken enthalten kann, die da vielleicht schon seit Jahren drin sind und die einfach noch niemand in der Masse von Code gefunden hat?" stellt man sich lieber die Frage "Wollen wir auf alte ISA-Treiber u.ä. verzichten?" und beantwortet diese dummerweise auch noch mit "Nein".
Allerdings traue ich es bei der derzeitigen Organisation und "Einigkeit" der Kernel-Entwickler dem Linux-Projekt auch nicht mehr zu, solche Schritte organisatorisch zu bewältigen. Man erinnere sich nur mal dran wie lange einige Treiber-Entwickler gebraucht haben, bis sie ihre Treiber vom 2.4er auf dem 2.6er Kernel angepasst hatten, so daß man ewig obsolete Modul-Interfaces mitschleppen musste. Bei einer Restrukturierung des Kernel wäre es vermutlich kaum möglich solche Interfaces weiterhin anzubieten und eine entsprechend kurze Reaktionszeit der Treiber-Entwickler wäre gefragt. Klar, diese entwickeln nur in der Freizeit, aber als Entwickler an einem so großen und wichtigen Projekt sollte man einigermaßen angemessene Reaktionszeiten ermöglichen, falls z.B. mal Sicherheitslücken zu schliessen sind u.ä.. Mir ist klar, dass ein Rewrite eines Treibers keine einfache Sache ist, aber es gibt kaum Systeme, wo man da drumrum kommt. Linux versucht es aber krampfhaft.

Es ist aber primär eine Sache der Organisation. Erwartet ja niemand, dass es heute sofort fertig sein muss, aber es mal für die Zukunft einzuplanen und langsam damit loszulegen, wäre nicht verkehrt. Aktuell könnte man ihn auch bekommen, allerdings müssten die Entwickler dazu bereit sein zeitweise 2 Versionen ihrer Module anzubieten, für den alten/aktuellen Kernel und für den dann neuen Entwicklungskernel. Sicherlich ist der Aufwand hoch, aber ohne diesen sehe ich auf lange Sicht keine Zukunft für Linux. Habt ihr euch mal angeschaut wie riesig der Kernel mittlerweile geworden ist? Die Hardware wird im Laufe der nächsten Jahre nicht weniger und es wird immer wieder neue Hardware-Schnittstellen geben, deren Unterstützung dann wieder in diese monolithische Struktur gefrickelt werden muss. Der Kernel unterliegt damit einem permanenten Wachstum im RAM-Verbrauch, der sich drastisch vermindern liesse, wenn alle Subsysteme über fest definierte Schnittstellen mit dem Kernel kommunizieren würden und dieser sich auf seine eigentlichen Aufgaben konzentrieren würde... Schnittstelle zur Hardware sein und nicht eine Sammlung von Subsystemen um Schnittstellen zu Treibern zu bilden.

@jemo.: Der Noob sieht es daran, dass er dann z.B. Linux-NG nutzt. Ist ja eine Abkürzung, die sich mittlerweile in vielen Bereichen eingebürgert hat, wo man die Notwendigkeit von Rewrites eingesehen hat.
 
Habt ihr euch mal angeschaut wie riesig der Kernel mittlerweile geworden ist?

Also ich hab hier noch 1-2 Debian-Systeme laufen, wo ich 'ne extra BOOT-Partition angelegt hatte, welche ich damals (Debian Woody) auf ganze 30MB "großzügig" festgelegt hatte...

Mittlerweile kann man auf dieser boot-Partition kein Kernel-Update laufen lassen, da 2-3 Kernel parallel schnell mal zum Platz-Problem werden...

Ich muss natürlich dazu sagen, dass ich mir bei Woody mit 2.4er-Kernel auch noch die Mühe gemacht hatte, selbst Kernel zu backen... mittlerweile hat die Faulheit gesiegt und ich nutze doch oftmals überdimensionierte Standard-Kernel...
 
Frage: Wäre es überhaupt möglich Linux so komplett umzuschreiben? Würde das das Projekt nicht Quasi auf den Stand zu Zeiten von 0.01 zurückwerfen?

Praktisch, nein. Interessanter ist die verspaetete Erkenntnis wie unsinnig es war einer solchen Architektur zu folgen.

Obwohl man wusste wie problematisch sie eigentlich ist, hat man sie umgesetzt. Aus dem eifachen Grund weil es das schon gab und man es nachbauen konnte (Linux hat bis heute kaum irgendwas innovatives geschafft).

Windows NT bot damals schon eine Rechtegranularitaet die *Nixe bis heute nicht haben. Das wusste man. Trotzdem baute man den alten Mist nochmal neu.

Sicherheitstechnisch kannte man alle unzulaenglichkeiten der intel Architektur, von C und die verwendeten Compiler. Trotzdem hat man die gleichen Fehler nochmal neu programmiert die in BSD, und S5 Unixen ausgemerzt waren.

Und das zu einer Zeit wo es durchaus andere "weiter" gedachte und innovative Kernelkonzepte gab.
 
Ein Flame Thread ... fein ...

Ich finde das diese ganze Open Source Welle einfach grundlegend überschätzt oder falsch interpretiert wird. Nur weil der Quellcode einer Software offen ist und sie nichts kostet heißt das doch nicht das dies der bessere Weg ist ? Ich finde sogar es ist der schlechtere!

Ja, OSS ist gelegentlich toll. Aber wenn man hinschaut, dann nur da wo tatsächlich doch Gelder hinterstecken, wo die Entwickler eben doch angestellt sind und dahinterstehende Konzerne aus verschiedensten Interessen diese Schiene fahren. Ausnahmen bestätigen die Regel. Natürlich hat die Philosophie das Software offen sein sollte, alle sie nutzen könnten und jeder seinen Teil einbringen kann, etwas Gutes. Die Idee klingt halt schön, aber sie ist fürchterlich ineffizient und das fährt sie einfach total gegen die Wand.

Ich möchte mal einen Vergleich aufzeigen:

Kommerzielle Software hat:
-ein strukturiertes Entwicklerteam welches in direktem Kontakt steht
-orientierte Ziele, auch was Entwicklungsdauer angeht
-Ressourcen für Beta-Tests
-Kunden welche bei schlechter Ware zurecht reklamieren könnten
-Leistungsdruck/bzw. Anspruch durch Konkurenzentwickler

vielleicht fällt auf das das alles klare Vorteile sind und dem lediglich ein Nachteil gegenüber steht

-es kostet was

Doch der Preis wird (zumindest in den meisten Fällen) entsprechend durch den Markt reguliert. Nur selten gibt es bei kommerzieller Software ein Must-Have das seinem Preis nicht gerecht wird. Und Ausnahmen bestätigen auch hierbei die Regel.

So, und nun wiegt mal diesen einen Nachteil gegenüber den Nachteilen der OSS auf. Denn OSS hat in der Regel keinen einzigen der genannten Vorteile der kommerziellen Software.
 
Flame-Thread, schön und gut, aber bitte keine Unwahrheiten erzählen:

Nachteile von kommerzieller, closed-source Software:
- Eventuelle Backdoors
- Verwendung unsicherer Algorithmen (wie es zum Beispiel bei den "sicheren" externen Festplatten mit Code-Eingabe üblich ist)
- Keine Möglichkeit kleine Änderungen selber hinzuzufügen
- Möglicherweise wird das Produkt eingestellt
- Eventuell werden eigene, neue "Standards" eingeführt, OSS hält sich in der Regel eher an tatsächliche Standards

Ich bin jetzt aber auch schon wieder still. :)

mfg benediktibk
 
Kommerzielle Software hat:
-ein strukturiertes Entwicklerteam welches in direktem Kontakt steht
-orientierte Ziele, auch was Entwicklungsdauer angeht
-Ressourcen für Beta-Tests
-Kunden welche bei schlechter Ware zurecht reklamieren könnten
-Leistungsdruck/bzw. Anspruch durch Konkurenzentwickler

Bis auf Punkt Nr. 4 kann man das imho eigentlich pauschal so nicht stehen lassen.
Einige OS-Projekte haben ein - wenn auch anders - strukturiertes Entwicklerteam, sehr wohl Ziele & Deadlines (die natürlich genau so wie bei CSS gelegentlich überschritten werden), freiwillige Beta-Tester und natürlich auch einen gewissen Leistungsdruck, gegenüber alternativer Software, egal ob closed oder open source.
Gut, in "direktem" Kontakt stehen die Entwickler vielleicht seltener wie im CS-Bereich, das muss sich aber nicht zwangsweise nachteilig auswirken. Beta-Tester gibt's - je nach Popularität der Software - mal vergleichweise mehr oder weniger wie im CS-Bereich. Dass OSS Konkurenz auch aus dem CS-Bereich hat, merkt man ja auch an diesem Flamewar hier in Bezug auf Linux <=> *nix <=> OSX. Ob sich dieser unterschiedlich auf Entwickler von OSS bzw. CSS auswirkt, weiß ich nicht, halte ich aber für durchaus nachvollziehbar. :wink:
 
Also was den Aspekt mit möglichen Backdoors und möglicher Einstellung des Supports angeht, das ist in der Tat wahr. Wobei das Aspekte sind die man vom Entwicklerunternehmen abhängig abwägen müsste.

Die anderen Dinge halte ich für so auch nicht ganz richtig.
Das vlt. unsichere Algorithmen verwendet werden spielt speziell im Unternehmensbereich eine Rolle, und gerade hier denke ich kann man bei den Software Einkäufen drauf achten das diese die gewünschten Voraussetzungen erfüllen.

Und im Privatbereich gibts auch genug Auswahl. Der Markt reguliert solche Dinge halt für gewöhnlich. In Bereichen wo es auf Sicherheit ankommt setzt sich auch die Software durch welche in diesem Aspekt besonders punkten kann.

Das man Dinge an CS Software nicht "Ändern" kann ist wahr, aber in der Praxis oft unbedeutend. Privatpersonen werden nur in den allerseltensten Fälle Software direkt für sich umschreiben, dafür gibts meist irgendwelche Alternativen. Und Unternehmen welche es sich leisten könnten ein Team zu unterhalten das (OS-) Software für sie erweitert kann den viel effizienteren Weg gehen und beim Entwickler der Software an die Tür zu klopfen.

Und Standards finde ich werde gerade durch Konzerngruppen am effektivsten durchgesetzt. Das mag nicht immer gut und richtig sein, zugegeben. Aber ein Beispiel sind z.B. die Blu-Rays sowie der HDMI Port. Beides durch eine Gruppe von Konzernen durchgesetzt und jetzt als sicherer Standard für aktuelle sowie zukünftige Projekte etabliert. Ohne Intel hätten wir auch noch nichts USB-mäßiges und bei Software find ich das es ähnlich läuft: Dateiformate etablieren sich auch fast ausschließlich durch kommerzielle Vertreter. *.odt ? ja ... das Standardformat von OpenOffice ... wird's effektiv genutzt ? nein, hier triumphieren nach wie vor *.doc und *.pdf dateien.


Versteht mich nicht falsch ...
OSS hat klare Vorteile. Vieles von dem was ich aufgeführt habe ist auch aufs mehrfache überspitzt, stark selektiert oder beschränkt zutreffend. Aber meiner Ansicht nach ist es nunmal so und OSS ist ein guter Weg, aber effektiv gesehen für niemanden der bessere. Es macht auch viel mehr Sinn kommerzielle Software von einem Entwicklerunternehmen vernünftig zu entwickeln und zu supporten und durch Werbeblöcke kostenfrei zu gestalten als ein OSS Projekt zu gründen und darauf zu hoffen das ein solches Projekt fruchtet.
 
Stopp, Linux-Flame, nicht OSS-Flame :D

Für mich der entscheidende Punkt. Ich bin Schüler und habe wirklich nicht viel Geld. Auf eine Win 7 Lizenz müsste ich mehrere Monate sparen.
Aber wenn man hinschaut, dann nur da wo tatsächlich doch Gelder hinterstecken, wo die Entwickler eben doch angestellt sind und dahinterstehende Konzerne aus verschiedensten Interessen diese Schiene fahren. Ausnahmen bestätigen die Regel. Natürlich hat die Philosophie das Software offen sein sollte, alle sie nutzen könnten und jeder seinen Teil einbringen kann, etwas Gutes. Die Idee klingt halt schön, aber sie ist fürchterlich ineffizient und das fährt sie einfach total gegen die Wand.
Also: Es ist mir relativ egal, solange ich kostenlos und legal an gute Software komme. Und wenn ich eine Möglichkeit sehe, Software zu unterstützen (Übersetzungen, Bugreports, Patches) und die Zeit dazu habe, dann tue ich das. Wobei das eben bei Open Source leichter ist.
Dateiformate etablieren sich auch fast ausschließlich durch kommerzielle Vertreter. *.odt ? ja ... das Standardformat von OpenOffice ... wird's effektiv genutzt ? nein, hier triumphieren nach wie vor *.doc und *.pdf dateien.
PDF ist vielleicht nicht frei im Sinne von Freiheit, aber durchaus Open im Sinne von lesbar. Oder warum gibt es sonst die Spezifikationen zum Download auf adobe.com?
 
Und Standards finde ich werde gerade durch Konzerngruppen am effektivsten durchgesetzt. Das mag nicht immer gut und richtig sein, zugegeben. Aber ein Beispiel sind z.B. die Blu-Rays sowie der HDMI Port. Beides durch eine Gruppe von Konzernen durchgesetzt und jetzt als sicherer Standard für aktuelle sowie zukünftige Projekte etabliert. Ohne Intel hätten wir auch noch nichts USB-mäßiges und bei Software find ich das es ähnlich läuft: Dateiformate etablieren sich auch fast ausschließlich durch kommerzielle Vertreter. *.odt ? ja ... das Standardformat von OpenOffice ... wird's effektiv genutzt ? nein, hier triumphieren nach wie vor *.doc und *.pdf dateien.

Da gibts dann mal ein wunderbares Gegenbeispiel: TeX wurde von Don Knuth entwickelt, weil keine vernuenftige kommerzielle Alternative da war und hat sich in den letzten 20 Jahren zu einem Standard was akademische Texte angeht entwickelt.

Persoenlich finde ich Open Source als Entwicklungsmodell einfach deswegen schon besser als Closed Source, da man direkt mit den Entwicklern in Kontakt treten kann. Wenn man zum Beispiel Microsoft und Windows als Gegenbeispiel nimmt: Wer da einen Bugreport einsendet, kann in der Regel lange warten bis der ueberhaupt bearbeitet wird und die Entwickler sind hinter "Mauern" von Anonymitaet versteckt. Bei Projekten wie Awesome (zugegeben, da bin ich eventuell vorgeeicht) dagegen kann man 1:1 mit den Entwicklern des Codes, der einem Probleme bereitet sprechen. Man kann sich nach Motiven, das so oder so zu schreiben erkundigen und man kann direkt da Vorschlaege anbringen, wo es sinnvoll ist: bei Upstream, ohne das zig Instanzen dazwischen liegen. Ausserdem hat Open Source Software IMHO den Vorteil, dass sie in der Regel von den Leuten, die sie schreiben, selbst verwendet wird. Die Entwickler haben tiefere Interessen daran, ihre Software besser zu machen (um selbst weniger Probleme damit zu haben), im Gegensatz zu Angestellten Entwicklern von geschlossener Software, die in der Regel mehr interessiert, dass am Ende des Monats der Gehaltsscheck kommt. Wenn ich da an Entwickler, die in irgendwelchen Firmen an Software arbeiten, die sie nach dem Release vergessen und persoenlich nie nutzen wuerden, denke, wundert mich nicht, dass viele Sachen mit CSS einfach umstaendlicher sind als wenn man das selbe Projekt als OSS aufgezogen haette.
 
@farhaven: Mal einen Bug-Report an ein vergleichbar großes Projekt wie Windows geschickt, z.B. mal an KDE oder das Gnome-Projekt oder gar auf die Kernel-Mailingliste von Linux? Die Bearbeitung dieser Bugreports dauert zumeist länger als die bei MS. Oft wird man sogar darum "gebeten", einen entsprechenden Patch einzureichen und nicht mit Bugreports zu nerven, wenn man eh keine Ahnung hat.

Wenn man natürlich Mini-Projekte wie Awesome-WM mit MS Windows vergleicht, wird Awesome-WM in Sachen Support sicher besser abschneiden, weil es ein 1-Mann-Projekt ist, wo keine Notwendigkeit für Zuständigkeiten besteht. Vergleicht man hingegen mal den Support beim Linux-Kernel z.B. mit dem von MacOSX (um mal bei unixoiden Systemen zu bleiben), wird man schnell feststellen, dass ClosedSource da weitaus besser abschneidet. Wieviele ACPI-Bugs gibt's z.B. im Linux-Kernel und wieviele im Kernel von MacOSX? Wie lange braucht Apple um Fehler, die in Verbindung mit neuer Hardware auftreten, zu fixen und wie lange braucht Linux dafür? Besserer Support? Direkter Entwicklerkontakt? Sicherlich nicht bei Projekten, an denen mehr als 100 Leute programmieren und das ist auch gut so, da erfahrungsgemäß eine zentrale Kommunikations/Customer-Schnittstelle eher den Überblick behält als wenn jeder Entwickler ständig von Usern genervt wird. Da aber OSS-Entwickler eben nur in ihrer Freizeit coden, investieren sie schon wesentlich weniger Zeit in die Software, als es im kommerziellen Umfeld möglich ist, wo Entwickler 8-12h am Tag dran arbeiten. Allein dadurch kann OSS nicht mit dem Support und der Entwicklungsgeschwindigkeit kommerzieller Programme mithalten, es sei denn man erschlägt dieses Defizit durch Manpower und da zeigt die Erfahrung, dass zuviele Köche den Brei eher verderben.

Ausserdem erlebe ich auch im kommerziellen Umfeld immer wieder Entwickler, die sich genauso in ihr Produkt reinknien wie irgendwelche OSS-Entwickler. Klar wollen die Leute auch davon leben und da liegt die nächste Schwachstelle von OpenSource. Man kann davon nicht leben, weil man die Software nicht verkaufen kann, sondern nur den Support und den braucht dank offenen Quellen kaum jemand. Es kommen also nur Firmen als Finanzier in Frage, die die Software an ihre Bedürfnisse anpassen lassen, womit dann wieder die Kommerzialisierung von OSS beginnt.

Dass es nicht unbedingt von Vorteil ist, dass die OSS-Entwickler Software primär für sich selbst schreiben, habe ich bereits als Nachteil aufgeführt. Genau dadurch wird oft am Verbraucher vorbei entwickelt und oft genug hab ich schon erlebt, dass ich Patches eingereicht habe um Funktionalitäten zu ergänzen, die mit der Begründung abgelehnt wurden "Ich schreib die Software für mich. Wenn du eine gepatchte Version haben willst, dann musst du dir halt einen Fork machen. Ich will den Patch nicht." Ja super, tolle OSS-Entwickler. :rolleyes: Auf Egoismus baute der OSS-Gedanke jedenfalls ursprünglich eigentlich nicht auf. Mittlerweile tut er es aber bei den meisten Entwicklern und genau diese Denkweise "Ich schreibe die Software für mich" ist Schuld daran.
 
Zurück
Oben