Boycott Systemd
- Ersteller Athaba
- Erstellt am
- Status
goblin
Motivierter Amateur
Naja, falls du den Thread nicht ganz gelesen hast, ich bin beispielsweise ein Linuxer, der von Systemd vertrieben wurde.
Gut, ich hatte BSD vorher schon ausprobiert, aber wirklich vertrieben hat mich Systemd. Und als Linuxer hatte ich vor allem folgende Probleme damit:
- Auf allen Rechnern (mit unterschiedlichen Distributionen) hat mir Systemd nur Scherereien in Form von Bootproblemen gebracht
- Feature-Creep
- Mangelnde Code-Qualität
- Einschränkung der Wahlfreiheit für Systemkomponenten
Ich bin mir sicher, dass es vielen so geht. Die einen steigen um, weil sie sich schon vorher für andere Systeme interessiert haben (so wie ich),
andere forken eben die Distribution, oder versuchen harte systemd-Abhängigkeiten aus ihrer Distribution herauszuhalten (Gentoo ist da ein prominentes Beispiel).
foxit
Well-Known Member
Das ist ein Argument, welches man immer wieder hört aber kann wirklich jemand, der unabhängig ist(!) dies bestätigen? Ansonsten sehe ich das wie du.
goblin
Motivierter Amateur
Wer ist schon unabhängig?
Ich habe es gelesen und es hat mir nicht gefallen
Aber vielleicht hast du Recht, ich hätte besser schreiben sollen:„Meiner Ansicht nach ist der Code nicht gut genug, dass ich ihn einsetzen wollen würde.“
Oder den Punkt ganz weglassen, folgt ja indirekt aus dem ersten Punkt
hunderteins
Member
Unabhängig weis ich nicht, aber zumindest experientierfreudig scheint der Debianer hier zu sein:
http://news.dieweltistgarnichtso.net/posts/systemd-assumptions-bullying-consent.html
Das ist nur meine persönliche Meinung, aber nicht die Code Qualität von linux sondern die von (ziemlich viel) gpl Zeug ist beschissen - was allerdings weitgehend deckungsgleich ist mit linux. linux im Sinne von kernel ist wirr und äh ... sehr offen für allerlei Ideen, aber nicht schlecht programmiert. Es gibt so einige Leute im linux kernel team, die sehr respektable Progammierer sind.
Allerdings scheint mir die Ebene Code-Qualität eh recht ungeeignet und irrelevant in dieser Diskussion (obwohl der eine oder andere systemd Entwickler diesbezüglich ja für Zornesausbrüche bei Linux gesorgt hat). "gpl" kommt der Sache schon näher, sprich, bei linux ist jede Menge "Politik" und Ideologie im Spiel; da geht's um die hach, so bedeutsamen Rechte irgendwelcher 14-jähriger ukrainischer cuul hackzors gegenüber Firmen, die dämlich genug sind, solches Zeug zu verwenden, um Kathedrale vs. Bazaar, um gender-Schwachsinn und sonst noch allerlei wirres Zeug. Und noch ein Faktor spielt leider eine betrüblich große Rolle: vermeintlich cooles Engagement (oder ein Simulation oder Selbsttäuschung diesbezüglich) hinter dem sehr häufig schlicht gedankenloses Mitläufertum steckt im Sinne von "bequeme Konsumhaltung und das noch für lau und als cool oder gar engagiert verkleidet".
Denn genau so konnte meiner persönlichen Meinung nach systemd durchgedrückt werden: Weil > 90% der cuulen hackzors a) null Plan haben, b) inhaltlich und tatsächlich null Interesse haben und es daher im wesentichen c) unter "läuft doch" buchen und abnicken. Zuletzt kommt dann noch eine linux-übliche Hurra-Begeisterungsschicht drüber und linux-bla-gazetten spammen noch reichlich Artikel à la "warum systemd toll ist", "linux ist dank systemd mal wieder der Erste und ganz vorne" oder "10 tolle Tips zu systemd". Das gibt's gelegentlich auch in der "Ich habe x-hundert server mit linux am Laufen" Variante.
Ein Beitrag aus einem anderen FreeBSD Forum zeigt recht gut (zumindest zum Teil) was ich meine. Dort laufen nun linux user auf, wollen "das andere Unix" (FreeBSD) nutzen und fragen, wie der FreeBSD Befehl für "AppArmor" auf FreeBSD heisst.
goblin
Motivierter Amateur
Eine Menge „interessante“ Links da drin, den Artikel heb ich mir mal als Referenz auf, falls wieder wer behauptet, der Poettering sei doch garnicht so…
Auf jeden Fall vielen Dank für den Link.
Edit:
Offensichtlich nicht unabhängig
Hast du belastbare Zahlen für Unterschiede zwischen den Lizenzen?
Die GPL ist nun einmal die verbreiteste Lizenz und deswegen auch die Lizenz mit den meisten guten, den meisten schlechten und den meisten mittelmäßigen Projekten.
Etwas mehr technische Diskussion wäre mir sehr willkommen, die ad-hominem-Attacken finden sogar die uselessd-Macher ermüdend. Als wollte man über die Vor- und Nachteile von OpenBSD diskutieren und in jedem zweiten Satz wird Theo de Raadt erwähnt. Und man will es nicht glauben, die Meriten eines aktuellen iPhone hängen tatsächlich nicht von den Eigenheiten von Steve Jobs ab.
Eine SonarQube-Analyse der einzelnen systemd-Module wäre mal interessant.
Deren Meinung interessiert aber auch keinen, weil sie weder einen technischen noch einen finanziellen Beitrag leisten. Auf die zahlreichen Betreiber eines privaten Metin2-Servers gibt im FreeBSD-Umfeld doch auch keiner was.
Man sollte sich vor elitärem Standesdünkel hüten. Bei mir im Unternehmen ist bei der Standardisierung der Betriebssystem-Landschaft (ich hab im Juni 2014 mal berichtet) FreeBSD jetzt in der Vorrunde rausgeflogen.
Ein paar Admins, die pro Nase tatsächlich hunderte Server betreuen, haben als Mindestanforderung eine elementare "Process Supervision" gefordert, die leider FreeBSD ohne 3rd-Party-Software nicht erfüllen konnte.
Mangels verlinktem Beitrag lässt das sehr viel Spielraum offen. Wenn ein FreeBSD-User in einem Linux-Forum fragt, wie er (als willkürliches Beispiel) sein individuelles Jails-Setup unter Linux abbilden könnte, wäre das eine berechtigte Frage. Die Dokumentation von Lösungen aus der Praxis ist bei den BSDs teilweise etwas spärlich.
C
CrimsonKing
Guest
Wobei Linux ja mit Docker inzwischen sogar Jails schlecht nachmacht.
Azazyel
Das ist deine Sicht und die nehme ich gelassen zur Kenntnis. Aber ich habe eben auch meine Sicht. Da Technik ja nicht einfach natürlich irgendwo im Ozean stattfindet sondern von Menschen gemacht wird, Menschen mit Gründen, Wünschen, Absichten, Bedürfnissen, usw. halte ich die immer wieder, häufig sogar als Maßstab für Seriosität, vorgebrachte Verengung des Blicks auf Technicalia für kurzsichtig und sogar unzulässig.
Wie wesentlich und kraftvoll die nicht technischen Momente sind, zeigt sich ja auch daran, welche Emotionen ausgelöst wurden und dass diverse Überlegungen zu forks angestellt wurden.
Ich bitte in diesem Zusammenhang auch zu bemerken, dass ich persönlich und für mich linux zwar nicht sonderlich ernst nehme, aber weder versuche, jemanden davon abzubringen, noch böswillig dagegen lästere. In der Tat verwende ich es in einigen Einsatzbereichen selbst und empfehle nicht selten auch anderen linux für einige Einsatzbereiche. Auch habe ich schon so manches bei linux gelobt und erwähnt, dass wir alle linux in der einen oder anderen Weise zu danken haben.
Der Umstand, dass "Anti" Projekte ins Leben gerufen und forks zumindest erwogen wurden, aber auch die offensichtliche und durchaus beträchtliche Verärgerung vieler user bis hin zum Rücktritt von debian Machern lässt mich stark daran zweifeln, dass systemd demokratisch auserkoren oder wegen seiner (vermeintlichen oder tatsächlichen) Vorteile in nahezu allen Distributionen Einzug hält.
Mir scheint, man sollte realistisch davon ausgehen, dass auch bei uns (open source Projekten, OS Unixoide) dieselben Mechanismen anzutreffen sind wie auch sonst nahezu überall. Sprich, es gibt auch bei uns so einiges, was nicht-öffentlich abläuft, es gibt auch bei uns diverse Interessengruppen, insbesondere auch seitens großer Unternehmen und Institutionen, und es funktionieren auch bei uns Methoden zur Beeinflussung der breiten (weniger unmittelbar involvierten) Massen, die ihrerseits auch in unserem Bereich so ticken wie sie auch sonst ticken.
Und es ist durchaus auch technisch oder Technik-nah einiges zu bemerken, was zumindest bemerkt werden und in die Betrachtung einfließen sollte.
So wurde systemd z.B. regelrecht gepusht und es wurden teilweise auch schlicht Fakten geschaffen, die den Entscheidungsspielraum erheblich verändert haben. Das sieht für mich nicht nach einem gesunden Prozess und Verlauf aus. Nur mal zum Vergleich: Wayland hat ein tatsächlich existierendes und tatsächlich zunehmend drängendes Problem aufgegriffen, eine Lösung erarbeitet und vorgestellt und die Reaktion potentieller user begrüßt und konstruktiv aufgegriffen. In der Folge haben verschiedene Projekte das aufgegriffen; manche haben Wayland sehr begrüßt und gelobt, manche haben es sogar ein bisschen gepusht - aber das war's auch. So kenne ich das und so sieht für mich ein gesunder Prozess aus und entsprechend gab es keinen Aufruhr und keine Core Leute, die nach vielen Jahren enttäuscht, angepisst, überrumpelt oder müde hingeschmissen haben. Bei systemd war/ist das ziemlich anders.
Ohne die systemd Macher persönlich angreifen zu wollen heisst das für mich insgesamt u.a. dass linux für mich nicht mehr in Betracht kommt, wenn es um Sicherheit (wie in: nicht von der nsa bespitzelt werden) geht. Die core der systemd Macher sind zwar europäisch aber der Wind (was Druck angeht) kommt ganz klar aus den usa.
Wie es der Zufall so will, arbeite ich im Bereich Sicherheit und sehe immer wieder ein bestimmtes Problem, nämlich dass tripwire & Co nicht mehr vertrauenswürdig sind, wenn der kernel oder init nicht vertrauenswürdig sind. Das heisst letztlich nichts anderes als dass das gesamte System, firewall, tripwire und sonstnochwas hin oder her, nicht mehr als vertrauenswürdig gelten kann.
Hässliche Tricks im kernel würden schnell auffallen und Linus hat ja klar gesagt, dass nsa Spielchen mit ihm nicht zu machen sind. Wenn ich der zuständige Mann bei der nsa wäre, wäre mein nächstes Idealziel pid 1. Und dabei würde ich dem user allerhand nettes Trallala an die Hand geben (z.B. Tools, mit denen man sogar hübsche Grafiken machen kann), aber darauf achten, dass er möglichst wenig wirkliche Kontrolle hat, z.B. in Form Menschen-lesbarer logs.
Falls mich nun jemand für paranoid halten sollte, gerne, kein Problem, gehört zu meinem Beruf. Allerdings gehört dazu auch (anders als die meisten linux user) zu wissen, wie Angriffsszenarien aussehen. So ist z.B. so ziemlich jeder Schutzmechanismus gegen private key Klau wirkungslos, wenn die Annahme meiner security daemons, das system sei bei ihrem early start noch "sauber" falsch ist.
Wie gesagt, Technik findet in einem Kontext statt und der ist oft menschlicher als es einem scheint (oder lieb sein kann). Sollte ich mich irren, so wäre es mir eine Freude. mein job allerdings ist es, für den Fall vorzusorgen, dass ich mich nicht irre.
Das ist deine Sicht und die nehme ich gelassen zur Kenntnis. Aber ich habe eben auch meine Sicht. Da Technik ja nicht einfach natürlich irgendwo im Ozean stattfindet sondern von Menschen gemacht wird, Menschen mit Gründen, Wünschen, Absichten, Bedürfnissen, usw. halte ich die immer wieder, häufig sogar als Maßstab für Seriosität, vorgebrachte Verengung des Blicks auf Technicalia für kurzsichtig und sogar unzulässig.
Wie wesentlich und kraftvoll die nicht technischen Momente sind, zeigt sich ja auch daran, welche Emotionen ausgelöst wurden und dass diverse Überlegungen zu forks angestellt wurden.
Ich bitte in diesem Zusammenhang auch zu bemerken, dass ich persönlich und für mich linux zwar nicht sonderlich ernst nehme, aber weder versuche, jemanden davon abzubringen, noch böswillig dagegen lästere. In der Tat verwende ich es in einigen Einsatzbereichen selbst und empfehle nicht selten auch anderen linux für einige Einsatzbereiche. Auch habe ich schon so manches bei linux gelobt und erwähnt, dass wir alle linux in der einen oder anderen Weise zu danken haben.
Der Umstand, dass "Anti" Projekte ins Leben gerufen und forks zumindest erwogen wurden, aber auch die offensichtliche und durchaus beträchtliche Verärgerung vieler user bis hin zum Rücktritt von debian Machern lässt mich stark daran zweifeln, dass systemd demokratisch auserkoren oder wegen seiner (vermeintlichen oder tatsächlichen) Vorteile in nahezu allen Distributionen Einzug hält.
Mir scheint, man sollte realistisch davon ausgehen, dass auch bei uns (open source Projekten, OS Unixoide) dieselben Mechanismen anzutreffen sind wie auch sonst nahezu überall. Sprich, es gibt auch bei uns so einiges, was nicht-öffentlich abläuft, es gibt auch bei uns diverse Interessengruppen, insbesondere auch seitens großer Unternehmen und Institutionen, und es funktionieren auch bei uns Methoden zur Beeinflussung der breiten (weniger unmittelbar involvierten) Massen, die ihrerseits auch in unserem Bereich so ticken wie sie auch sonst ticken.
Und es ist durchaus auch technisch oder Technik-nah einiges zu bemerken, was zumindest bemerkt werden und in die Betrachtung einfließen sollte.
So wurde systemd z.B. regelrecht gepusht und es wurden teilweise auch schlicht Fakten geschaffen, die den Entscheidungsspielraum erheblich verändert haben. Das sieht für mich nicht nach einem gesunden Prozess und Verlauf aus. Nur mal zum Vergleich: Wayland hat ein tatsächlich existierendes und tatsächlich zunehmend drängendes Problem aufgegriffen, eine Lösung erarbeitet und vorgestellt und die Reaktion potentieller user begrüßt und konstruktiv aufgegriffen. In der Folge haben verschiedene Projekte das aufgegriffen; manche haben Wayland sehr begrüßt und gelobt, manche haben es sogar ein bisschen gepusht - aber das war's auch. So kenne ich das und so sieht für mich ein gesunder Prozess aus und entsprechend gab es keinen Aufruhr und keine Core Leute, die nach vielen Jahren enttäuscht, angepisst, überrumpelt oder müde hingeschmissen haben. Bei systemd war/ist das ziemlich anders.
Ohne die systemd Macher persönlich angreifen zu wollen heisst das für mich insgesamt u.a. dass linux für mich nicht mehr in Betracht kommt, wenn es um Sicherheit (wie in: nicht von der nsa bespitzelt werden) geht. Die core der systemd Macher sind zwar europäisch aber der Wind (was Druck angeht) kommt ganz klar aus den usa.
Wie es der Zufall so will, arbeite ich im Bereich Sicherheit und sehe immer wieder ein bestimmtes Problem, nämlich dass tripwire & Co nicht mehr vertrauenswürdig sind, wenn der kernel oder init nicht vertrauenswürdig sind. Das heisst letztlich nichts anderes als dass das gesamte System, firewall, tripwire und sonstnochwas hin oder her, nicht mehr als vertrauenswürdig gelten kann.
Hässliche Tricks im kernel würden schnell auffallen und Linus hat ja klar gesagt, dass nsa Spielchen mit ihm nicht zu machen sind. Wenn ich der zuständige Mann bei der nsa wäre, wäre mein nächstes Idealziel pid 1. Und dabei würde ich dem user allerhand nettes Trallala an die Hand geben (z.B. Tools, mit denen man sogar hübsche Grafiken machen kann), aber darauf achten, dass er möglichst wenig wirkliche Kontrolle hat, z.B. in Form Menschen-lesbarer logs.
Falls mich nun jemand für paranoid halten sollte, gerne, kein Problem, gehört zu meinem Beruf. Allerdings gehört dazu auch (anders als die meisten linux user) zu wissen, wie Angriffsszenarien aussehen. So ist z.B. so ziemlich jeder Schutzmechanismus gegen private key Klau wirkungslos, wenn die Annahme meiner security daemons, das system sei bei ihrem early start noch "sauber" falsch ist.
Wie gesagt, Technik findet in einem Kontext statt und der ist oft menschlicher als es einem scheint (oder lieb sein kann). Sollte ich mich irren, so wäre es mir eine Freude. mein job allerdings ist es, für den Fall vorzusorgen, dass ich mich nicht irre.
nakal
Anfänger
Qualität von Software an Lizenzen erkennen zu können ist einfach Schwachsinn.
Ich würde auch davon Abstand nehmen, zu behaupten, dass der Linux-Kernel mangelnde Qualität hat. Das stimmt so nicht. Die Leute, die daran arbeiten, können durchaus sehr gut programmieren und wissen bescheid, wie man es machen sollte. Der einzige Punkt ist, dass experimentelle Konzepte und Treiber sehr früh im Kernel landen (was im Prinzip nicht schlecht ist; besser etwas schlechtes haben als gar nichts). Ich neige auch dazu, zu sagen, dass der Linux-Kernel einfach besser ist als was BSDs haben, weil Linux technologisch die Nase vorn hat und das ist immer ein Zeichen für ein besseres Entwicklungskonzept.
Wenn ich mir auch vieles bei FreeBSD angeschaut habe, dann gibt es von Hardware-Unterstützung oft nur das Allernötigste (siehe Bluetooth, HID etc) und dann fehlt es an vielen Feinheiten, die man sehr schnell braucht, wenn man seriös Software entwickeln möchte. Da rennt man voller Begeisterung und knallt mir dem Kopf gegen eine Wand und wird dann vernünftig und gibt die Entwicklung auf, weil es sinnlos ist bis die FreeBSD-Entwickler sich erbarmen. Ich glaube, dass meine Frage nach einer vernünftigen APIs für Joysticks/Joypads irgendwann in 4.x-Zeiten entstanden ist. Da gibt es bis heute nichts brauchbares. Nur so als Beispiel.
Ich würde auch davon Abstand nehmen, zu behaupten, dass der Linux-Kernel mangelnde Qualität hat. Das stimmt so nicht. Die Leute, die daran arbeiten, können durchaus sehr gut programmieren und wissen bescheid, wie man es machen sollte. Der einzige Punkt ist, dass experimentelle Konzepte und Treiber sehr früh im Kernel landen (was im Prinzip nicht schlecht ist; besser etwas schlechtes haben als gar nichts). Ich neige auch dazu, zu sagen, dass der Linux-Kernel einfach besser ist als was BSDs haben, weil Linux technologisch die Nase vorn hat und das ist immer ein Zeichen für ein besseres Entwicklungskonzept.
Wenn ich mir auch vieles bei FreeBSD angeschaut habe, dann gibt es von Hardware-Unterstützung oft nur das Allernötigste (siehe Bluetooth, HID etc) und dann fehlt es an vielen Feinheiten, die man sehr schnell braucht, wenn man seriös Software entwickeln möchte. Da rennt man voller Begeisterung und knallt mir dem Kopf gegen eine Wand und wird dann vernünftig und gibt die Entwicklung auf, weil es sinnlos ist bis die FreeBSD-Entwickler sich erbarmen. Ich glaube, dass meine Frage nach einer vernünftigen APIs für Joysticks/Joypads irgendwann in 4.x-Zeiten entstanden ist. Da gibt es bis heute nichts brauchbares. Nur so als Beispiel.
C
CrimsonKing
Guest
GPL-Software ist überdurchschnittlich oft von schlechter Codequalität. Verteufle die Statistik.
darktrym
Fahnenträger
Ich hab schon einiges an Software gesehen. Die Motivation warum man da seine Software unter GPL stellen will waren dabei oft ideologisch oder technisch motiviert.
Technisch, weil das Original GPL war oder man sich die Arbeit einfacher machen wollte und Teile übernommen hatte. Ideologisch damit nur man selbst später damit Kasse machen kann weil man die Rechte inne hat. Im Vergleich zu Software die von Scratch entsteht sehe ich kaum Unterschiede. BSDL sind bei Referenzprojekte oder Bibliotheken häufiger anzutreffen, dessen Qualität stimmen muss um genutzt zu werden. Aber bei bestehende Projekte gerade GPL neigen zur Implementierung von Hacks um das Feature Set aufzublähen, was man bei BSD in der Tat recht selten sieht. Die gammeln lieber vor sich hin.
Technisch, weil das Original GPL war oder man sich die Arbeit einfacher machen wollte und Teile übernommen hatte. Ideologisch damit nur man selbst später damit Kasse machen kann weil man die Rechte inne hat. Im Vergleich zu Software die von Scratch entsteht sehe ich kaum Unterschiede. BSDL sind bei Referenzprojekte oder Bibliotheken häufiger anzutreffen, dessen Qualität stimmen muss um genutzt zu werden. Aber bei bestehende Projekte gerade GPL neigen zur Implementierung von Hacks um das Feature Set aufzublähen, was man bei BSD in der Tat recht selten sieht. Die gammeln lieber vor sich hin.
nakal
Anfänger
Eine Lizenz beschränkt in keinster Weise die Qualität einer Software. Überlegt doch was Ihr da behauptet. Das ist doch überhaupt nicht schlüssig. Und solche Statistiken haben für mich keinen Wert, es sei denn man schränkt sie auf die Top-100 Projekte oder so ähnlich.
Das ist doch genau die gleiche nutzlose Aussage wie bei Programmiersprachen und Software-Qualität. Wenn das wirklich so einfach wäre, würden wir alle in sowas wie Agda programmieren.
Das ist doch genau die gleiche nutzlose Aussage wie bei Programmiersprachen und Software-Qualität. Wenn das wirklich so einfach wäre, würden wir alle in sowas wie Agda programmieren.
darktrym
Fahnenträger
Wir reden doch hier von der Code Qualität, nicht von dem erzeugten Code oder dem Feature Set/Technik. GPL Projekte neigen dazu die Lizenz als Waffe zu sehen um andere Bereiche aufzuhebeln, sozusagen einen Fuß dazwischen zubringen. Welche Gründe machen denn den Vergleich abwegig?
Es gibt viele RMS Projekte die durch schnellen Feature Bau bestehene Lösungen verdrängt haben. Das ist perse nichts schlechtes, selber Schuld wenn man sich ausruht. Emacs ist ein anderes Beispiel. Aber die Architekturdefekte die sowas mitbringen kann, stehen doch außer Frage.
Es gibt viele RMS Projekte die durch schnellen Feature Bau bestehene Lösungen verdrängt haben. Das ist perse nichts schlechtes, selber Schuld wenn man sich ausruht. Emacs ist ein anderes Beispiel. Aber die Architekturdefekte die sowas mitbringen kann, stehen doch außer Frage.
Das sagte auch niemand.
Mir fällt häufiger auf, dann man bei linux/gpl Proponenten und Fans durchaus häufiger auf dieses Muster trifft, "misszuverstehen" und sich to-tal em-pört über etwas aufzuregen und gegen etwas zu "argumentieren" was gar nicht gesagt wurde.
Was ich sagte war eine allgemein gehaltene Beobachtung mit statistischem Charakter.
Sehe ich das richtig, dass dein Beitrag satirisch gemeint ist? Mir scheint ja, denn nicht nur sagte ich nicht, der linux kernel sei schlecht programmiert, sondern ich erwähnte die linux kernel Programmierer sogar ausdrücklich positiv.
Ja, du meintest deinen Beitrag satirisch. Offensichtlich.
Ich kenne mich mit game "development" nicht aus, aber ich vermute mal, dass sich an joysticks einfach nicht so viel geändert hat.
Was seriöse software Entwicklung angeht ... Also, ich entwickle regelmäßig für FreeBSD, OpenBSD, Solaris und auch linux, wenn's nicht zu aufwendig/ätzend ist (was oft der Fall ist). Ich gebe zu, das graphischste, was ich je gemacht habe (ausser (zugegeben widerwllig) GUIs zusammenklicken) war eine TUI library (C und ASM) und kenne mich nicht so aus mit Spielen und Bunti-Zeug. Aber falls server (mit 1000en connections), base libraries, Sicherheitssysteme, HALs und DSLs. auch zu "seriöser Software Entwicklung" gehören sollte, dann möchte ich widersprechen. Das aufwendigste und ätzendste target unter den genannten ist für mich klar linux.
Im übrigen ist deine Argumentation ungefähr so sinnvoll wie die, dass LKWs unpraktisch sind, um Blümchen für seine Frau zu holen. linux spricht die große Masse und Bastelfreunde an - und will das auch - wohingegen FreeBSD eine weitgehend andere Zielgruppe (mit anderen Prioritäten) hat. Ebenso gut könnte ich nölen, dass netBSD (das genau das als raison d'etre hat) ein paar Plattformen unterstützt, die linux nicht unterstützt; so what? Das ist auch gar nicht das Ziel von linux.
Aus eben diesem Grund empfehle ich bei unterschiedlichen Bedarfssituationen auch unterschiedliche Systeme, mitunter durchaus auch linux oder windows.
nakal
Anfänger
Also oben wir zig mal GPL im Zusammenhang mit Software-Qualität erwähnt. Ich bin da anderer Meinung. Ich habe zwar keine Programme unter der GPL laufen, aber ich habe da keine BSD-Scheuklappen auf.
Nein gar nicht. Die bessere Software kann Neuerungen mit weniger Aufwand integrieren. Und das ist hier vor allem der Linux-Kernel. Ich muss hier nicht wirklich die ganzen Missstände aufzählen, die beim *BSD-Kernel gegeben sind und zum absoluten Stillstand in vielen Bereichen geführt haben.
Und noch einmal: Es ist besser irgendwas zu haben (Linux) als gar nichts (FreeBSD; gilt eigentlich für *BSD).
Misstände bei FreeBSD? Sehe ich nicht. Für mich und viele, viele andere user ist Stereo-Bunti-Trallala plusquamscheissegal.
Es gibt X (was in der Tat ein hässlicher Moloch ist - aber mit FreeBSD hat das rein gar nichts zu tun), es gibt Alltags-Gui-Bunti-Klicki (gtk, qt, fltk plus darauf aufbauende Klicki-Gui Oberflächen), es gibt einen soliden, guten kernel, es gibt so ziemlich alle benötigten Treiber, gute libraries und gazillionen ports. Und es gibt sogar (wenn auch apple-infizierte *g) core Leute, die über eine sinnvolle und angemessene Version dessen nachdenken, was systemd zu sein vorgibt (z.B. Hubbard, wenn auch ziemlich abenteuerlustig anmutend).
Ich bleibe dabei: Der Tag eines Snowden 2 wird kommen und die systemd Fans werden Tränen und Rotz heulen. R. (Namen soll man nier ja nicht nennen ...), die wesentlichste Kraft hinter systemd (nur dürftig mit freedesktop getarnt), ist eine ami Firma und ergo der nsa ausgeliefert. Obendrein sind die brutal kommerziell und haben ihr free linux (fedora) hauptsächlich, um diese user als Laborratten zugunsten ihres Kommerz-OS zu nutzen. Wer denen trauen will, mag das tun, aber für mich ist R., Pöttering, Sievers so ziemlich das Gegenteil dessen, was ich mit Vertrauen assoziiere.
FLAME WAR!!!!! Du Ungläubiger!!! Der einzige wahre Gott ist das fliegende Spaghettimonster in der Honeywell 9-bit Version!
FreeBSD ist ein wunderbar stabiles, robustes System. Solange man auf den ausgetretenen Pfaden bleibt. Aber wehe, wehe und wehe man macht einmal böse Dinge, die etwas von Mainstream abweichen. Da fällt man ganz schnell in Abgründe. Und das sage ich als FreeBSD-Fanboy erster Güte. Beispiele:rmoe schrieb:
- Mein naiver Versuch HAST unter FreeBSD 9.2 (da war es schon mehrere Release-Zyklen hinweg im System!) auf einem unter extremer IO-Last laufendem System zu deployen. Es kostete viele Mails, noch mehr Nerven und verdammt viele Patches alle sporadisch auftretenden Deadlocks in diversen Bereichen des Kernels rauszufischen.
- Bis vor kurzem musste man NFS-Shares nur mit einer rsize oder wsize mounten, die kein Vielfaches der Pagesize war und die Panic kam innerhalb von Minuten.
- Noch immer nicht vollständig behoben (da nur mit viel Aufwand möglich) ist die oft sofort auftretende Panic, wenn man die MTU eines Links ändert, während man parallel Daten auf einen NFS-Share kopiert.
- In FreeBSD 10.1 ist ein netter Livelock zwischen tty_drain() und revoke() enthalten. Macht vor allem großen Spaß, wenn init(8) deadlockt. Die Wahrscheinlichkeit eines Auftretens ist sehr gering, außer man schaltet die Keybell auf "visual". Dann ist ein Deadlock beim Ausführen von shutdown(8) fast sicher. Befand sich bereits ~7 Monate im Code, bevor ich es bemerkte.
- Ich war auch der böse Junge, der euch die Snapshots bei SU+J nahm. Da ich fast 12 Monate nach dem initialen Commit derjenige war, der die sporadisch auftretenden Panics beim Anlegen von UFS-Sanpshots mal näher anschaute.
- Der nette in age(4), der mich einen Zpool(!) kostete.
Da hast du schon recht, Yamagi
FreeBSD hat so einige dunkle Ecken, aber FreeBSD macht keinen Lärm und ist bescheiden. Diese Bescheidenheit ist auch absolut angemessen, einfach weil FreeBSD nur einen fast schon vernachlässigbaren Bruchteil der Resourcen von linux (oder ehemals Solaris, oder ...) hat(te).
Mein persönlicher Eindruck ist der, dass FreeBSD da von Anfang an zu Problemen verurteilt war, weil man ja ursprünglich "nur" eine open source Version von BSD machen wollte - und dabei das ursprüngliche design mit übernahm. Allerdings war BSD selbst damals schon keine jugendliche Schönheit mehr und so einige grundlegende Veränderungen bzw. die Notwendigkeit dazu zeichneten sich bereits am Horizont ab.
So einiges dessen, was du beschreibst, hat damit zu tun, dass ein und dasselbe (z.B. multitasking) damals und heute beileibe nicht dasselbe waren und meinten. Und so baute man halt immer wieder an an das System, das eigentlich gar nicht dazu taugte. Plus noch einiges von anderen Systemen, was haben zu müssen man meinte.
Interessanterweise, das nur als Randbemerkung, soff so ziemlich alles, was nicht aus den usa kam, ziemlich kläglich ab, obwohl da teilweise brilliante Sachen dabei waren (man denke nur mal an die ETHZ oder das frz. INRIA).
Man geht mich ja manchmal für meine Art oder meine Art, die Dinge zu sehen an. Nur: Das hat seine Gründe. Wenn ich z.B. unvorteilhaft über shells spreche, dann hat das nicht nur einen Grund sondern letztlich auch ziemlich unmittelbar mit dem Kern heutiger Probleme zu tun. Man muss dabei einfach mal verstehen, dass "die Geschichte" (und die Gewohnheit!) aus so manchem quick and dirty hack eine Art heilige Instanz gemacht haben. Wenn man weiss, vor welchem Hintergrund shells ursprünglich entwickelt wurden (und in welchem Kontext), dann versteht man, was ich meine. Solange shells hacks zur Bequemlichkeit (und in den Händen äusserst erfahrener Leute) waren und so auch verstanden wurden, war das kein Problem. Dazu wurde es allerdings schnell, als man (hurra, wir berühren am Rande mal wieder das Thema *g), lose formuliert, das halbe Betriebssystem daran aufhängte (z.B. init System oder, die Krönung der Perversion, diverse gnu tools).
Zum Teil litt und leidet Unix auch - ich sage das ohne bösen Willen - auch schlicht daran, dass es aus den usa kommt und so notwendig bereits frühzeitig zum Opfer einer sales minded Gesellschaft - und Academia! - wurde. Da steckt so manches ziemlich tief drin, was, offen gesagt, nie wirklich durchdacht und zu Ende gedacht wurde.
Nur - und das ist ein großes "nur": Das wird nicht besser, indem man dem problembehafteten Grundansatz (heute vor allem in Form von featuritis) treudoof weiter folgt. Aber genau das ist grundlegender Bestandteil des linux-Glaubens.
Analysiert man mal (was wichtiger Bestandteil meines Jobs ist), woran Zuverlässigkeit und Sicherheit immer wieder scheitern bzw, andersherum, konstruktiv betrachtet, wie man Zuverlässigkeit erhöhen kann, so kommt man immer wieder an die selben Punkte. Lustigerweise ist ein grundlegender Eckpfeiler ein (artig aufgesagtes aber selten geistig durchdrungenes) Credo von Unix! Das nämlich, einen job zu machen, den aber gut. Und wer verstößt ziemlich von Anfang dagegen? Unix shells.
Für einen Laien mag der Unterschied marginal scheinen, aber tatsächlich liegen (u.a. konzeptionelle) Welten zwischen batch Automatisierung und einem Sprach-interpreter. Würde man es ernst meinen und durchziehen, müssten sogar (durchaus für den user wichtige) gadgets wie history eigentlich externe add-ons sein.
Aber immerhin bemüht man sich bei FreeBSD um vernünftig konzeptioniertes design, während linux eher eine bunte Bastelbude ist (was wohlgemerkt OK, vielleicht sogar wichtig und gut ist, aber eben kein Paradigma, das immanent zu Qualität und Zuverlässigkeit führt).
Das kann man locker sehen und religiös drüber diskutieren - oder man kann begreifen, dass es Gründe für praktisch wöchentlich geklaute Millionen Passwörter, geklaute (und sowieso schwachsinnig konzeptionierte) private keys/Zertifikate und dergleichen mehr gibt.
Da sollte man schon mal fragen und überlegen, was diese gehackten Büchsen mit hoher statistischer Signifikanz gemeinsam haben. -> linux, apache, mysql, php - und auf allen Ebenen, angefangen von den Entwicklern bis hin zu den admins ... äh ... nur teiloptimal professionelle und kenntnisreiche Leute * räusper
Und da schwuppen wir jetzt noch systemd rein. Und dann wird alles besser. Ich erlaube mir zu zweifeln.
FreeBSD hat so einige dunkle Ecken, aber FreeBSD macht keinen Lärm und ist bescheiden. Diese Bescheidenheit ist auch absolut angemessen, einfach weil FreeBSD nur einen fast schon vernachlässigbaren Bruchteil der Resourcen von linux (oder ehemals Solaris, oder ...) hat(te).
Mein persönlicher Eindruck ist der, dass FreeBSD da von Anfang an zu Problemen verurteilt war, weil man ja ursprünglich "nur" eine open source Version von BSD machen wollte - und dabei das ursprüngliche design mit übernahm. Allerdings war BSD selbst damals schon keine jugendliche Schönheit mehr und so einige grundlegende Veränderungen bzw. die Notwendigkeit dazu zeichneten sich bereits am Horizont ab.
So einiges dessen, was du beschreibst, hat damit zu tun, dass ein und dasselbe (z.B. multitasking) damals und heute beileibe nicht dasselbe waren und meinten. Und so baute man halt immer wieder an an das System, das eigentlich gar nicht dazu taugte. Plus noch einiges von anderen Systemen, was haben zu müssen man meinte.
Interessanterweise, das nur als Randbemerkung, soff so ziemlich alles, was nicht aus den usa kam, ziemlich kläglich ab, obwohl da teilweise brilliante Sachen dabei waren (man denke nur mal an die ETHZ oder das frz. INRIA).
Man geht mich ja manchmal für meine Art oder meine Art, die Dinge zu sehen an. Nur: Das hat seine Gründe. Wenn ich z.B. unvorteilhaft über shells spreche, dann hat das nicht nur einen Grund sondern letztlich auch ziemlich unmittelbar mit dem Kern heutiger Probleme zu tun. Man muss dabei einfach mal verstehen, dass "die Geschichte" (und die Gewohnheit!) aus so manchem quick and dirty hack eine Art heilige Instanz gemacht haben. Wenn man weiss, vor welchem Hintergrund shells ursprünglich entwickelt wurden (und in welchem Kontext), dann versteht man, was ich meine. Solange shells hacks zur Bequemlichkeit (und in den Händen äusserst erfahrener Leute) waren und so auch verstanden wurden, war das kein Problem. Dazu wurde es allerdings schnell, als man (hurra, wir berühren am Rande mal wieder das Thema *g), lose formuliert, das halbe Betriebssystem daran aufhängte (z.B. init System oder, die Krönung der Perversion, diverse gnu tools).
Zum Teil litt und leidet Unix auch - ich sage das ohne bösen Willen - auch schlicht daran, dass es aus den usa kommt und so notwendig bereits frühzeitig zum Opfer einer sales minded Gesellschaft - und Academia! - wurde. Da steckt so manches ziemlich tief drin, was, offen gesagt, nie wirklich durchdacht und zu Ende gedacht wurde.
Nur - und das ist ein großes "nur": Das wird nicht besser, indem man dem problembehafteten Grundansatz (heute vor allem in Form von featuritis) treudoof weiter folgt. Aber genau das ist grundlegender Bestandteil des linux-Glaubens.
Analysiert man mal (was wichtiger Bestandteil meines Jobs ist), woran Zuverlässigkeit und Sicherheit immer wieder scheitern bzw, andersherum, konstruktiv betrachtet, wie man Zuverlässigkeit erhöhen kann, so kommt man immer wieder an die selben Punkte. Lustigerweise ist ein grundlegender Eckpfeiler ein (artig aufgesagtes aber selten geistig durchdrungenes) Credo von Unix! Das nämlich, einen job zu machen, den aber gut. Und wer verstößt ziemlich von Anfang dagegen? Unix shells.
Für einen Laien mag der Unterschied marginal scheinen, aber tatsächlich liegen (u.a. konzeptionelle) Welten zwischen batch Automatisierung und einem Sprach-interpreter. Würde man es ernst meinen und durchziehen, müssten sogar (durchaus für den user wichtige) gadgets wie history eigentlich externe add-ons sein.
Aber immerhin bemüht man sich bei FreeBSD um vernünftig konzeptioniertes design, während linux eher eine bunte Bastelbude ist (was wohlgemerkt OK, vielleicht sogar wichtig und gut ist, aber eben kein Paradigma, das immanent zu Qualität und Zuverlässigkeit führt).
Das kann man locker sehen und religiös drüber diskutieren - oder man kann begreifen, dass es Gründe für praktisch wöchentlich geklaute Millionen Passwörter, geklaute (und sowieso schwachsinnig konzeptionierte) private keys/Zertifikate und dergleichen mehr gibt.
Da sollte man schon mal fragen und überlegen, was diese gehackten Büchsen mit hoher statistischer Signifikanz gemeinsam haben. -> linux, apache, mysql, php - und auf allen Ebenen, angefangen von den Entwicklern bis hin zu den admins ... äh ... nur teiloptimal professionelle und kenntnisreiche Leute * räusper
Und da schwuppen wir jetzt noch systemd rein. Und dann wird alles besser. Ich erlaube mir zu zweifeln.
goblin
Motivierter Amateur
Da stimme ich dir zu, das ist eine Pauschalisierung, die schlicht und einfach zu falschen Ergebnissen führt.
Und das ist in meinen Augen genau so eine falsche Pauschalisierung. Die technisch bessere Lösung setzt sich nicht automatisch durch, wer das wirklich glaubt, dem werfe ich ein Problem mit seiner Wahrnehmung vor. Lösungen setzen sich aus verschiedenen Gründen durch, es wäre schön wenn es die technischen wären, aber es sind mindestens genauso oft politische oder wirtschaftliche Gründe. Oder eben die Mischung aus allem.
Das ist eben nicht nur eine Frage der besseren Technik, sondern der Menge an Entwicklerun und Unterstützern. Linux ist nicht schöner, Linux ist beliebter, und das heißt es gibt dort mehr Entwickler, mehr Tester, mehr Unterstützer. Also werden mehr Treiber schneller integriert. Das wäre auch dann noch so, wenn die Schnittstellen schlecht wären.
IMO hat beispielsweise Plan 9 eine der schönsten und einfachsten Strukturen, die man bei Betriebssystemen so finden kann. Aber die Entwickler kann man vermutlich an einer Hand abzählen, entsprechend hinkt es selbst *BSD nahezu Jahrzehnte hinterher, was Treiber etc. angeht.
- Status