systemd, der nächste Horror für BSD?

Status
Für weitere Antworten geschlossen.
Das Konzept hinter systemd und Konsorten ist vernünftig und steht einfach an. launchd (2005), SMF (2005), upstart (2006), systemd (2010).

Leider wurde systemd mit gewalt gepusht und wurde dargestellt als wären seine features ausgereift, obwohl sie nur Proof-Of-Concept waren.
Jetzt haben wir überall systemd, aber statt die Technical Dept abzutragen und es zu stabilisieren, Dokumentieren und portabel zu machen wird der feature-hype vorangetrieben und es entwickelt sich zu einer OS middleware mit tight coupling.

Jetzt sitzen die Parteien, denen etwas an Stabilität und sauberen Schnittstellen liegt, da und müssen mitziehen oder sie verlieren Support von der meisten OSS.

Was hätte passieren sollen ist, dass RedHat eine InitCon veranstalten hätte sollen, bei der alle Stakeholder sich auf ein deklaratives Kernformat geeinigt hätten. Das wäre dann von 2-3 systemen mit verschiedenen schwerpunkten implementiert worden und alles wäre relativ gut.

Ich glaube die FreeBSD Foundation könnte die Debian situation ausnutzen und klarstellen, dass eine kompatible zweit-implementierung geschaffen werden muss, damit nicht ein Linux Monopol geschaffen wird.
Das würde eine Phase einleiten, in der sich herauskristallisiert welche Teile der neuen init's den großen umbruch der letzten Jahre tragen, und welche einfach nur frickelei sind.

Klingt alles nach grauer Theorie. Man ist gespannt wie und ob sich die BSD-Systeme außerhalb des Servers weiterhin behaupten können.
 
Es gibt dieses Forum nun seit beinahe 12 Jahren. Und genauso lange gibt es das "*BSD stirbt!"-Thema in unterschiedlichen Ausführungen. Sei es, dass FreeBSD angeblich nicht gut genug skaliert. Oder das OpenBSD zu wenige Pakete hat. Oder das Linux ein tolles Feature hat, was man nicht nachbauen möchte. Oder... Es gibt wirklich genug Beispiele hier. Es gab regelrechte Heulthreads, die mehr als 200 Seiten hatten. Und es gibt uns und *BSD immer noch. Zumindest um FreeBSD steht im Jahr 2014 sogar bedeutend besser, als im Jahr 2004. Daher hört bitte mal mit dieser ewigen Schwarzmalerei auf. Und selbst wenn es berechtigte Sorgen gibt, kann man sich natürlich in einem eher unbedeutenden, deutschem Forum auskotzen. Nur ändern wird das nicht. Also besser die Zeit nutzen, um mal wieder den vi zu starten und den zum Lösen der Probleme und Sorgen notwendigen Code in die Kiste hauen.
 
Gibts eine Statistik wie groß der Schwund aktiver Nutzer ist? Ich meine andere (Linux-)Foren hätten Zulauf bekommen.
 
Seit 2004? Nein, ich habe nur Zahlen bis 2008 zurück. Bis dahin sind wir in Sachen aktiver Nutzer stabil, die Anzahl Klicks ist um ca. 50% angestiegen. Wobei ich bis Herbst 2013 nicht zwischen Bots und Menschen unterscheiden kann. Was auffällt ist eine stark nachlassende Popularität von NetBSD und OpenBSD über die Zeit, verbunden mit einem etwa gleichstarken Anstieg von Zugriffen auf den FreeBSD-Bereich. Das sieht man auch gut an der Anzahl neuer Beiträge in den beiden Bereichen.
 
Wer *BSD einsetzt, macht dies meiner Meinung bewusst und weiss genau für was er es braucht/brauchen kann. z.B.

Grosse Fileserver mit ZFS == FreeBSD
Sichere Firewall == OpenBSD
 
Wer *BSD einsetzt, macht dies meiner Meinung bewusst und weiss genau für was er es braucht/brauchen kann.

Oder er kommt hierher, weil ihn die Fragmentierung unter Linux ankotzt und lieber OpenBSD und FreeBSD auf seinem Notebook installiert, weil er sich somit nicht für jeden Anwendungszweck eine eigene Distribution installieren und deren Befehle verinnerlichen muss. Zudem kann dieser jemand sich auch noch mit dem Porters Handbook beschäftigen, um somit allen Betriebssystemen einen für beider Seiten gewinnbringenden Dienst zu erweisen. So jemanden wie mich z.B. :cool:
 
Hab mich
Seit 2004? Nein, ich habe nur Zahlen bis 2008 zurück. Bis dahin sind wir in Sachen aktiver Nutzer stabil, die Anzahl Klicks ist um ca. 50% angestiegen. Wobei ich bis Herbst 2013 nicht zwischen Bots und Menschen unterscheiden kann. Was auffällt ist eine stark nachlassende Popularität von NetBSD und OpenBSD über die Zeit, verbunden mit einem etwa gleichstarken Anstieg von Zugriffen auf den FreeBSD-Bereich. Das sieht man auch gut an der Anzahl neuer Beiträge in den beiden Bereichen.
Hab ich auch schon mitbekommen, als letzter seiner Art kann ich eine WG mit Athaba aufmachen.
 
eine stark nachlassende Popularität von NetBSD und OpenBSD

Die sehe ich auch! Alleine durch Betrachten der Threads... Ich lese ja meistens nur mit aber ehemals wurde erheblich mehr noch über NetBSD geplaudert, das passiert ja nun eigentlich gar nicht mehr.
 
Was ist den an NetBSD speziell? FreeBSD hat ZFS, dtrace und hat am meisten User. OpenBSD ist sehr gut als Firewall/Router geeignet. NetBSD läuft auf X verschiedenen Architekturen. Ja kann ich aber alles nicht benutzen, da man nur im Ausnahmefall etwas anderes hat, was nicht auch von Free/OpenBSD unterstützen wird.
 
Meine Güte ihr reduziert die einzelnen BSDs sehr stark. Mit NetBSD werden Geschwindikeitsrekorde gebrochen, ist extrem stabil, hat verdammt nochmal Lua im Kernel. Da sollte das Herz eines jeden Geeks höher schlagen. NetBSD hat (oder hatte?) glaube ich weniger Sicherheitslücken als OpenBSD, wenn man nicht nur auf die Defaultinstallation geht und während die OpenBSD-Leute einfach echt den Standard hoch setzen und sich ihr eigen NTPD, ihr eigens SSH und ihr eigens SMTPD schreiben sind sie nach den Sendmail-Debakeln einfach mal auf Alternativen umgestiegen. Des weiteren haben sie eine BSD-Implementierung von PGP, cooles Testsuite-Konzept, etc.

Die drei BSDs und sogar DragonFly sind echte Allroundsysteme. An allen arbeiten Experten in vielen Gebieten, egal ob Security, Performnace, Networking, whatever. Ich habe ein Lego Mindstorms (das alte, originale) Buch da war ausschließlich von NetBSD die Rede (neben Windows, Linux und Mac). Das ist nicht nur multiplatform, aber portabler Code ist eine Stärke, ein Qualitätsmerkmal und cool zu haben. Auf der ISS haben sie's auch laufen, weil sie mit starker Stabilität und langen Supportzyklen werben. Die DARPA hat es offensichtlich auch viel verwendet und sogar Package Managing Zeug gemacht. Achja, Package Managing. Nochwas, was daran portabel ist. Das wird von Joyent auf SmartOS (Solaris für Cloud-Infrastruktur - ziemlich nett, das Systeme auf nem USB-Stick und die Platte für virtualisierte System) für ihre Cloudinfrastruktur Verwender. Einfach weil pkgsrc leicht zu portieren ist. Aber nicht nur auf Solaris, selbst auf Minix, wo sonst nichts läuft funktioniert es extrem gut.

Wir verwenden nun für unsere Server-Infrastruktur FreeBSD, einfach weil es den breitesten Support hat und das genau das liefert was wir brauchen. Heißt nicht, dass das so bleibt.

Ich habe lang genug OpenBSD als Hauptsystem auf dem Desktop betrieben um zu wissen, dass es nicht nur auf Routern und Firewalls rennt. Ohnehin irgendwie seltsam zu sagen. FreeBSD hat ipwf (neben pf natürlich), OpenBSD hat pf und NetBSD npg.

DragonFly hat mittlerweile so ziemlich jede Kritik widerlegen können, ist schnell, hat jede Menge Hardware- und Softwaresupport, meiner Meinung nach das am einfachsten aufzusetzende System, mit dntpd ein eigenes System, mit der Truecrypt/OFTE-Implemetierung Support für einen Standard, dass nun nicht mehr nur auf Windows und Linux funktioniert, dann noch dm-crypt support, coole neue Features als erstes gehabt (memory) resident, variant symlinks, vkernel, multip jail, ipv6 jail, die waren die Ersten die damals bei dem USB-Stick-Drama nicht geraunzt, sondern einfach mal gefixed haben. Sie setzen einfach logische Dinge, wie das Makefile in /usr. Ist nicht speziell, aber einfach mal pragmatisch. Und da sind Killerfeatures, wie HAMMER noch garnicht genannt.

Leute, seien wir uns doch mal ehrlich. Wenn alle nur ihr klitzekleines Ding hätten und die Leute nicht gut im Fixen und so werden und vor allem es nicht so eine Community gäbe, die Qualität und dieses Pragmatische mischen und neue Entwickler anziehen würde (jedes der BSD hat ständig neue Commiter). Und wenn die nicht durch alles durchtauchen können, auch wenn es mal was gibt was scheiße ist. Das sind große, komplexe Softwaresysteme, viele kleine und große Projekte, die zusammenspielen. Klar gibt es das auch ab und an mal Probleme und vielleicht muss man sich für was schämen und Befürchtungen haben, aber jedenfalls kann man sich in ein Kammerl sperren, sie auf seinen Hintern setzen und das Problem beheben und mir garantierten Support von Leuten rechnen, die nicht nur quasseln (so wie ich ;)).

Mal ernst, wenn man sich ansieht, was überall in der Softwarewelt so abgeht, dann freut man sich so richtig, dass man immer zu BSD zurückkommen kann. Da hat man einfach eine beständige Qualität. So einfach. Linux entwickelt sich rasend, aber was hilft es wenn ich was brauch worauf ich mich verlassen kann.

Und andererseits sind das nur Systeme. Oft redet man von so schlimmer Migration, aber mal ehrlich, so arg ist das dann meist nicht und wenn schon hat man meist ein Indiz für schlechte Software und sehnt sich nach seinem BSD.

Das Einzige was mich immer erschüttert und wo ich mich so gewaltig täusche, wenn ich lang mit BSD rumgetan habe ist wie schnell anders wo was als fertig und stabil gilt. Und ich glaube das ist das was den BSDs noch ähnlicher ist, als das ganze Zeug mit Basissystem und 3rd party und ports, etc.

Sorry, war Off Topic, aber auch wenn systemd in gewisser Hinsicht arg ist für BSD hat Yamagi ja eigentlich vollkommen recht mit dem was er sagt.
 
Meine Güte ihr reduziert die einzelnen BSDs sehr stark. Mit NetBSD werden Geschwindikeitsrekorde gebrochen, ist extrem stabil, hat verdammt nochmal Lua im Kernel. Da sollte das Herz eines jeden Geeks höher schlagen. NetBSD hat (oder hatte?) glaube ich weniger Sicherheitslücken als OpenBSD, wenn man nicht nur auf die Defaultinstallation geht und während die OpenBSD-Leute einfach echt den Standard hoch setzen und sich ihr eigen NTPD, ihr eigens SSH und ihr eigens SMTPD schreiben sind sie nach den Sendmail-Debakeln einfach mal auf Alternativen umgestiegen. Des weiteren haben sie eine BSD-Implementierung von PGP, cooles Testsuite-Konzept, etc.

Die drei BSDs und sogar DragonFly sind echte Allroundsysteme. An allen arbeiten Experten in vielen Gebieten, egal ob Security, Performnace, Networking, whatever. Ich habe ein Lego Mindstorms (das alte, originale) Buch da war ausschließlich von NetBSD die Rede (neben Windows, Linux und Mac). Das ist nicht nur multiplatform, aber portabler Code ist eine Stärke, ein Qualitätsmerkmal und cool zu haben. Auf der ISS haben sie's auch laufen, weil sie mit starker Stabilität und langen Supportzyklen werben. Die DARPA hat es offensichtlich auch viel verwendet und sogar Package Managing Zeug gemacht. Achja, Package Managing. Nochwas, was daran portabel ist. Das wird von Joyent auf SmartOS (Solaris für Cloud-Infrastruktur - ziemlich nett, das Systeme auf nem USB-Stick und die Platte für virtualisierte System) für ihre Cloudinfrastruktur Verwender. Einfach weil pkgsrc leicht zu portieren ist. Aber nicht nur auf Solaris, selbst auf Minix, wo sonst nichts läuft funktioniert es extrem gut.

Wir verwenden nun für unsere Server-Infrastruktur FreeBSD, einfach weil es den breitesten Support hat und das genau das liefert was wir brauchen. Heißt nicht, dass das so bleibt.

Ich habe lang genug OpenBSD als Hauptsystem auf dem Desktop betrieben um zu wissen, dass es nicht nur auf Routern und Firewalls rennt. Ohnehin irgendwie seltsam zu sagen. FreeBSD hat ipwf (neben pf natürlich), OpenBSD hat pf und NetBSD npg.

DragonFly hat mittlerweile so ziemlich jede Kritik widerlegen können, ist schnell, hat jede Menge Hardware- und Softwaresupport, meiner Meinung nach das am einfachsten aufzusetzende System, mit dntpd ein eigenes System, mit der Truecrypt/OFTE-Implemetierung Support für einen Standard, dass nun nicht mehr nur auf Windows und Linux funktioniert, dann noch dm-crypt support, coole neue Features als erstes gehabt (memory) resident, variant symlinks, vkernel, multip jail, ipv6 jail, die waren die Ersten die damals bei dem USB-Stick-Drama nicht geraunzt, sondern einfach mal gefixed haben. Sie setzen einfach logische Dinge, wie das Makefile in /usr. Ist nicht speziell, aber einfach mal pragmatisch. Und da sind Killerfeatures, wie HAMMER noch garnicht genannt.

Leute, seien wir uns doch mal ehrlich. Wenn alle nur ihr klitzekleines Ding hätten und die Leute nicht gut im Fixen und so werden und vor allem es nicht so eine Community gäbe, die Qualität und dieses Pragmatische mischen und neue Entwickler anziehen würde (jedes der BSD hat ständig neue Commiter). Und wenn die nicht durch alles durchtauchen können, auch wenn es mal was gibt was scheiße ist. Das sind große, komplexe Softwaresysteme, viele kleine und große Projekte, die zusammenspielen. Klar gibt es das auch ab und an mal Probleme und vielleicht muss man sich für was schämen und Befürchtungen haben, aber jedenfalls kann man sich in ein Kammerl sperren, sie auf seinen Hintern setzen und das Problem beheben und mir garantierten Support von Leuten rechnen, die nicht nur quasseln (so wie ich ;)).

Mal ernst, wenn man sich ansieht, was überall in der Softwarewelt so abgeht, dann freut man sich so richtig, dass man immer zu BSD zurückkommen kann. Da hat man einfach eine beständige Qualität. So einfach. Linux entwickelt sich rasend, aber was hilft es wenn ich was brauch worauf ich mich verlassen kann.

Und andererseits sind das nur Systeme. Oft redet man von so schlimmer Migration, aber mal ehrlich, so arg ist das dann meist nicht und wenn schon hat man meist ein Indiz für schlechte Software und sehnt sich nach seinem BSD.

Das Einzige was mich immer erschüttert und wo ich mich so gewaltig täusche, wenn ich lang mit BSD rumgetan habe ist wie schnell anders wo was als fertig und stabil gilt. Und ich glaube das ist das was den BSDs noch ähnlicher ist, als das ganze Zeug mit Basissystem und 3rd party und ports, etc.

Sorry, war Off Topic, aber auch wenn systemd in gewisser Hinsicht arg ist für BSD hat Yamagi ja eigentlich vollkommen recht mit dem was er sagt.

Warum laufen die BSD-Systeme unter ferner liefen wenn sie so konkurrenzlos sind? Wer macht da was falsch?

Bitte erklärt es einem Nutzer wie mir, der seit zwei Jahren FreeBSD als Desktopsytem verwendet und immer mal
dumme Fragen stellt.
 
Warum laufen die BSD-Systeme unter ferner liefen wenn sie so konkurrenzlos sind? Wer macht da was falsch?

Bitte erklärt es einem Nutzer wie mir, der seit zwei Jahren FreeBSD als Desktopsytem verwendet und immer mal
dumme Fragen stellt.

Ein großer Grund ist der hier (ich sehe die BSDs sehr weit rechts und mit wahrscheinlich kleineren Schwankungen, die aber wohl normal sind je nach Newsmeldung (Treiber, große Unternehmen, die BSD nutzen, Sicherheitslücken, Releases, ...)).


Ein weiterer Grund ist, dass es kein übermäßiges Interesse gibt den Einsatz von bestimmten BSDs groß publik zu machen. Canonical hat großes Interesse Ubuntu zu bewerben, Novell (und andere) haben großes Interesse SUSE zu bewerben und Redhat bewirbt RHEL und Fedora. Linux ist jünger, der Hype größer.

Dass MacOS, Playstation 4, Cisco Router, Juniper Router, DuckDuckGo, viele Unternhemen von Amazon (under der Firma/Cloud, die die Payment Transactions für Amazon macht), Google, etc. das auf einem anständigen Teil ihrer Server im Einsatz haben ist nichts was man groß erwähnt. Auch iOS ist groß und basiert auf BSD. Das ist einfach so.

Es ist wie bei Programmiersprachen. Auch wenn alle Go und Node hypen, schau mal wie viel wirklich darin geschrieben ist und wie es mit Jobinseraten ausschaut. Als C/++, Perl, PHP, C#, Scala, Erlang (ja, wirklich!) Programmierer hast du eine viel breitere Auswahl und wenn du Java, was vollkommen uncool ist hast du sowieso den Jackbot gemacht. Selbiges gilt für Datenbanken. Alle setzen auf Oracle oder Postgres, aber MySQL ist trotzdem das bekannteste. Schau dich um, ist wirklich so.

Und dann schau dir mal ISP/Hoster oder lang stehende, stabile Server auf Netcraft an. Der Anteil an BSD ist nicht so groß.

Und der Desktop? Naja, die Tatsache, dass Dinge, wie Java (binär), Steam und Skype unter Linux gut laugen trägt einiges bei. Neben der Politik natürlich.

Aber das ist eben immer so eine Sache. Im nicht-kommerziellen privaten Umfeld wird häufig Stuss verwendet. Schau dir die Elektronik an, die pünktlich zur Garantie ausfällt oder was die Leute für "Müll" essen.

Und ja, Linux hat auch ganz klar seine Vorzüge. Mehr Hype und User sorgen da für einen Status, der es für viele attraktiver macht. Keines der BSDs versucht so, wie Canonical das OS an die breite Masse zu bringen. Wenn man seinen Blick auf die Linuxwelt richtet hast du auch interessante Konstelationen. Ubuntu ist groß am Desktop und groß bei sehr kleinen Unternehmen/Startups. Das vor allem weil die Leute das OS vom Desktop kennen. Hast du aber jemanden, der mehr ein Techie(also nicht jemand, der einfach irgendwann programmieren gelernt hat) oder Sysadmin ist steigt die Wahrscheinlichkeit, dass es ein RedHat bzw. sowas wie CentOS wird, oder eben BSD.

Ich glaube nicht, dass BSD da groß was falsch macht. Ich glaube sogar, dass das Gegenteil der Fall ist und sie nicht, wie viele andere Projekte zu sehr in dieses "BSD is dying" verfallen. Wenn man sich Perl oder so ansieht klingt das viel Schlimmer, als die Realität. Da kommt man nicht mehr auf die Idee zu glauben, dass da immer noch Zustrom an neuen Usern ist, dass die Sprache sehr aktiv entwickelt wird, breit auch in Startups verwendet wird, etc. Das ist einfach nur abschreckend. Ihr größtes Problem ist diese einigermaßen depressive Selbstreflexion, in Blogs, Newslettern und Konferenz. Wenn das bei einem Projekt zum großen Thema wird, dann würde ich vielleicht nichts damit aufbauen wollen. Aber das "BSD is dying" ist ja meistens etwas zum Schmunzeln.

Was ich witzig finde ist ja, dass als LXC die Runde machte viele auf BSD und Solaris aufmerksam geworden sind, weil überall stand "wie FreeBSD jails und solaris zones". So hat quasi ein neues Feature wo man meinen würde, dass der große BSD-Vorteil weg ist dazu geführt, dass einige ihren Weg zu BSD gefunden haben.

Und ja, alle starten mit Ubuntu, aber wenn du dann deine Serverinfrastruktur aufbaust und du ständig mit outdated Software deiner Konkurrenz hinterherläufst und die jedes Systemupgrade Wochen kostet, dann schaust du auch mal über den Tellerrand und gibst dem Ganzen einen Versuch. Du kannst nicht viel verlieren, wenn du am Ende ohnehin immer alles neu aufsetzen musst.

Ich hoffe das klingt jetzt nicht zu anti-Linux. Wenn die Probleme dort behoben wären und das auch so bleibt und man nicht zig Admins für eine Hand voll Server bräuchte würde ich es in Betracht ziehen, einfach weil eine große Userbase gewisse Vorteile mit sich bringt. Derzeit halte ich es aber für ziemlichen Unsinn und eine Verschwendung von Zeit und Geld. Das ist aber auch sehr, sehr anwendungsspezifisch.

@grogolz: Beantwortet das die Frage oder ging das dran vorbei? War mir nicht ganz sicher, wie sie gemeint war.

Edit: Uff, habe mich gerade selbst ertappt. Wenn du da weiterdiskutieren willst würde ich die Diskussion dazu in einen eigenen Thread verschieben. Oder wir diskutieren per PM. :)
 
Ein großer Grund ist der hier (ich sehe die BSDs sehr weit rechts und mit wahrscheinlich kleineren Schwankungen, die aber wohl normal sind je nach Newsmeldung (Treiber, große Unternehmen, die BSD nutzen, Sicherheitslücken, Releases, ...)).


Ein weiterer Grund ist, dass es kein übermäßiges Interesse gibt den Einsatz von bestimmten BSDs groß publik zu machen. Canonical hat großes Interesse Ubuntu zu bewerben, Novell (und andere) haben großes Interesse SUSE zu bewerben und Redhat bewirbt RHEL und Fedora. Linux ist jünger, der Hype größer.

Dass MacOS, Playstation 4, Cisco Router, Juniper Router, DuckDuckGo, viele Unternhemen von Amazon (under der Firma/Cloud, die die Payment Transactions für Amazon macht), Google, etc. das auf einem anständigen Teil ihrer Server im Einsatz haben ist nichts was man groß erwähnt. Auch iOS ist groß und basiert auf BSD. Das ist einfach so.

Es ist wie bei Programmiersprachen. Auch wenn alle Go und Node hypen, schau mal wie viel wirklich darin geschrieben ist und wie es mit Jobinseraten ausschaut. Als C/++, Perl, PHP, C#, Scala, Erlang (ja, wirklich!) Programmierer hast du eine viel breitere Auswahl und wenn du Java, was vollkommen uncool ist hast du sowieso den Jackbot gemacht. Selbiges gilt für Datenbanken. Alle setzen auf Oracle oder Postgres, aber MySQL ist trotzdem das bekannteste. Schau dich um, ist wirklich so.

Und dann schau dir mal ISP/Hoster oder lang stehende, stabile Server auf Netcraft an. Der Anteil an BSD ist nicht so groß.

Und der Desktop? Naja, die Tatsache, dass Dinge, wie Java (binär), Steam und Skype unter Linux gut laugen trägt einiges bei. Neben der Politik natürlich.

Aber das ist eben immer so eine Sache. Im nicht-kommerziellen privaten Umfeld wird häufig Stuss verwendet. Schau dir die Elektronik an, die pünktlich zur Garantie ausfällt oder was die Leute für "Müll" essen.

Und ja, Linux hat auch ganz klar seine Vorzüge. Mehr Hype und User sorgen da für einen Status, der es für viele attraktiver macht. Keines der BSDs versucht so, wie Canonical das OS an die breite Masse zu bringen. Wenn man seinen Blick auf die Linuxwelt richtet hast du auch interessante Konstelationen. Ubuntu ist groß am Desktop und groß bei sehr kleinen Unternehmen/Startups. Das vor allem weil die Leute das OS vom Desktop kennen. Hast du aber jemanden, der mehr ein Techie(also nicht jemand, der einfach irgendwann programmieren gelernt hat) oder Sysadmin ist steigt die Wahrscheinlichkeit, dass es ein RedHat bzw. sowas wie CentOS wird, oder eben BSD.

Ich glaube nicht, dass BSD da groß was falsch macht. Ich glaube sogar, dass das Gegenteil der Fall ist und sie nicht, wie viele andere Projekte zu sehr in dieses "BSD is dying" verfallen. Wenn man sich Perl oder so ansieht klingt das viel Schlimmer, als die Realität. Da kommt man nicht mehr auf die Idee zu glauben, dass da immer noch Zustrom an neuen Usern ist, dass die Sprache sehr aktiv entwickelt wird, breit auch in Startups verwendet wird, etc. Das ist einfach nur abschreckend. Ihr größtes Problem ist diese einigermaßen depressive Selbstreflexion, in Blogs, Newslettern und Konferenz. Wenn das bei einem Projekt zum großen Thema wird, dann würde ich vielleicht nichts damit aufbauen wollen. Aber das "BSD is dying" ist ja meistens etwas zum Schmunzeln.

Was ich witzig finde ist ja, dass als LXC die Runde machte viele auf BSD und Solaris aufmerksam geworden sind, weil überall stand "wie FreeBSD jails und solaris zones". So hat quasi ein neues Feature wo man meinen würde, dass der große BSD-Vorteil weg ist dazu geführt, dass einige ihren Weg zu BSD gefunden haben.

Und ja, alle starten mit Ubuntu, aber wenn du dann deine Serverinfrastruktur aufbaust und du ständig mit outdated Software deiner Konkurrenz hinterherläufst und die jedes Systemupgrade Wochen kostet, dann schaust du auch mal über den Tellerrand und gibst dem Ganzen einen Versuch. Du kannst nicht viel verlieren, wenn du am Ende ohnehin immer alles neu aufsetzen musst.

Ich hoffe das klingt jetzt nicht zu anti-Linux. Wenn die Probleme dort behoben wären und das auch so bleibt und man nicht zig Admins für eine Hand voll Server bräuchte würde ich es in Betracht ziehen, einfach weil eine große Userbase gewisse Vorteile mit sich bringt. Derzeit halte ich es aber für ziemlichen Unsinn und eine Verschwendung von Zeit und Geld. Das ist aber auch sehr, sehr anwendungsspezifisch.

@grogolz: Beantwortet das die Frage oder ging das dran vorbei? War mir nicht ganz sicher, wie sie gemeint war.

Edit: Uff, habe mich gerade selbst ertappt. Wenn du da weiterdiskutieren willst würde ich die Diskussion dazu in einen eigenen Thread verschieben. Oder wir diskutieren per PM. :)

Meine Frage zur Verbreitung der BSD-Systeme war durchaus ernst gemeint. Eine Antwort darauf wie "die anderen sind zu doof" sicher nicht.

Wie ich an anderer Stelle schon geschrieben haben nutze ich als Backup-System seit Monaten FreeNAS und möchte es hiermit empfehlen. Es ist ja nicht nur für einen elitären Nutzerkreis gedacht und wer will schon freiwillig auf ZFS verzichten. Habe heute problemlos ein Update auf 9.2.1-RELEASE ausgeführt.

Für mich ist nur die Situation von FreeBSD als Desktop-System nicht durchschaubar und auch problematisch. Die Versuche mit PC-BSD sind gescheitert und ich habe auch nicht viel Zeit es immer wieder zu probieren. Zur Zeit nutze ich Manjaro Linux auf einem Laptop Lenovo SL510 und empfinde dieses Linux als sehr geeignet für meine Zwecke.

Ein anderer Thread? Okay, warum nicht?
 
Ja, mach bitte ein eigenen Thread auf und überleg dir eine Diskussionsrichtung die nicht gleich Trolle anzieht und Flames provoziert.
Hier hat jeder eine andere Sicht von Nutzung,Desktop und Verbreitung.
 
Zurück zum Thema systemd.

Bei mir in der Firma haben die Unix-Admins die Beta von RHEL 7 (das mit systemd kommt) mal unter die Lupe genommen und seit dem Jahreswechsel in den unterschiedlichen Entwicklungsumgebungen verprobt. Nach all den theoretischen Diskussionen hier im Forum habe ich sie bei einem Kaffee mal auf ihre Erfahrungswerte mit systemd angesprochen.

Gewöhnungsbedürftig fanden die Kollegen nur in den ersten 2-3 Tagen die neuen Befehle und die Syntax der Service-Konfiguration.

Ansonsten waren sie hellauf begeistert von systemd und haben davon geschwärmt, wie sehr es ihnen die Arbeit erleichtert. Am meisten Zuspruch fand systemctl status ("alle relevanten Informationen auf einer Seite"), das bessere Logging sowie die einfachere Anpassbarkeit der Servicekonfiguration und -abhängigkeiten durch den deklarativen Ansatz.

Auf die auch hier im Thread schon erwähnten Nachteile angesprochen, war als Feedback von "wen kümmert's" über "unschön, aber systemd ist für mich als Admin einfach deutlich besser" bis hin zu "die anderen Betriebssysteme müssen eben nachziehen" alles vertreten.
 
Ich kann schon verstehen, dass Linuxer sich über Sachen freuen, die andere Systeme schon längst haben. Da sollte man auch hin, aber wenigstens einmal auf die anderen schauen, wie ihre Ideen sind und wie gut sie praktisch umgesetzt wurden.

Ich bin mir noch nicht sicher was ich von "systemctl status" halten soll, denn ein Protokoll bietet jeder Dienst entweder eigenständig oder, falls das Protokoll an sich weniger interessant ist, wird alles rein in syslog reingekotzt. Ich habe das Problem damit nicht, deswegen sehe ich nicht, dass man das unbedingt lösen muss. Ich habe allerdings einen anderen Anwendungsfall... ich muss oft die Meldungen im Kontext (meistens zeitlichen Kontext) von anderen Diensten darstellen. maillog beinhaltet zum Beispiel alles rund um E-Mail und zwar für alle relevanten E-Mail-Dienste. Das brauche ich so und nicht nur dovecot-, procmail- oder postfix-Log alleine (wohlgemerkt ist procmail auch kein Dienst, was bekommt man dann von systemd darüber?).

Zum zweiten Punkt... deklarativ... das ist sicherlich toll. Aber wir haben doch deklarativen Ansatz duch /etc/rc.conf. Deswegen mögen wir eben die BSDs und auch die Linuxe, die hier an dieser Stelle abgeschaut haben.

Das einzige was (meiner Verständnis nach) systemd ausmacht ist, dass es mit Prozessgruppen arbeitet und damit Dienste und Prozesse korrekt zuordnen kann. Jedoch habe ich hier auch meine Schwierigkeit damit, dass Problem zu identifizieren, welches die systemd-Leute damit gelöst haben wollen. Mir ist nämlich in erster Linie ein portables Design wichtiger als ein "sauberes" Design, welches nicht portabel ist (für mich ist Portabilität oft ein Hinweis auf Sauberkeit des Designs... aber darüber kann man sich sicherlich auch streiten).
 
Ich bin mir noch nicht sicher was ich von "systemctl status" halten soll, denn ein Protokoll bietet jeder Dienst entweder eigenständig oder, falls das Protokoll an sich weniger interessant ist, wird alles rein in syslog reingekotzt.

Wenn über 1000 unterschiedliche Dienste in Betrieb sind, kann sich ein Admin schwerlich merken, wie jeder einzelne Dienst seinen Logging-Output schreibt. Es gibt auch Software, die mit einem Dutzend unterschiedlicher Prozessnamen etwas nach syslog schreibt.
Mit "systemctl status" sieht der Admin auf einen Blick, was es mit dem Dienst gerade auf sich hat, ohne sich minutenlang die Informationen aus unterschiedlichsten Quellen zusammensuchen zu müssen.

Ich habe das Problem damit nicht, deswegen sehe ich nicht, dass man das unbedingt lösen muss.

Es gibt viele Probleme, die man selbst nicht hat, aber trotzdem nach einer Lösung verlangen. :)

ich muss oft die Meldungen im Kontext (meistens zeitlichen Kontext) von anderen Diensten darstellen. maillog beinhaltet zum Beispiel alles rund um E-Mail und zwar für alle relevanten E-Mail-Dienste.

Das das Äquivalent von "mail.info /var/log/maillog" in /etc/syslog.conf wäre unter systemd "journalctl -p info SYSLOG_FACILITY=2" (wobei systemd hier noch den Namen und nicht nur die Nummer der Log-Facility akzeptieren sollte).

Das brauche ich so und nicht nur dovecot-, procmail- oder postfix-Log alleine (wohlgemerkt ist procmail auch kein Dienst, was bekommt man dann von systemd darüber?).

Das Logging-Modul von systemd nimmt auch den Output der syslog()-Calls von procmail entgegen, so wie es es syslogd unter BSD macht. Der procmail-Output würde also auch beim obigen journalctl-Befehl erscheinen.

Zum zweiten Punkt... deklarativ... das ist sicherlich toll. Aber wir haben doch deklarativen Ansatz duch /etc/rc.conf.

Die Admins meinten etwas anderes - wie bildet man in /etc/rc.conf ab, dass ein Dienst neu gestartet werden soll, falls er 30 Sekunden nach Anlauf noch nicht verfügbar ist?

Das einzige was (meiner Verständnis nach) systemd ausmacht ist, dass es mit Prozessgruppen arbeitet und damit Dienste und Prozesse korrekt zuordnen kann. Jedoch habe ich hier auch meine Schwierigkeit damit, dass Problem zu identifizieren, welches die systemd-Leute damit gelöst haben wollen.

In diesem Anwendungsfall: Limitierung und Priorisierung von Resourcen (z.B. I/O) von Diensten. Wie kann ich unter BSD verhindern, dass mir ein Dienst (oder auch eine Jail) mit massiver I/O-Last den Rest der I/O-Zugriffe ausbremst?
 
Die Admins meinten etwas anderes - wie bildet man in /etc/rc.conf ab, dass ein Dienst neu gestartet werden soll, falls er 30 Sekunden nach Anlauf noch nicht verfügbar ist?

Gar nicht, wenn er nicht startet, suche ich die Ursache und behebe diese und habe danach das Problem nicht mehr.

In diesem Anwendungsfall: Limitierung und Priorisierung von Resourcen (z.B. I/O) von Diensten. Wie kann ich unter BSD verhindern, dass mir ein Dienst (oder auch eine Jail) mit massiver I/O-Last den Rest der I/O-Zugriffe ausbremst?

Du schmeißt mit genügend Hardware nach dem Problem oder erschießt den "Softwareingenieur". ;)

Ich verstehe übrigens durchaus, was Du mit deinem Post sagen wolltest und kann dem aus einer sehr bestimmten perspektive auch zustimmen.
 
Wenn über 1000 unterschiedliche Dienste in Betrieb sind, kann sich ein Admin schwerlich merken, wie jeder einzelne Dienst seinen Logging-Output schreibt. Es gibt auch Software, die mit einem Dutzend unterschiedlicher Prozessnamen etwas nach syslog schreibt.
Mit "systemctl status" sieht der Admin auf einen Blick, was es mit dem Dienst gerade auf sich hat, ohne sich minutenlang die Informationen aus unterschiedlichsten Quellen zusammensuchen zu müssen.

Dann sollte der Admin seinen Job wechseln, wenn er Dienste betreibt, bei denen er nicht weiss, was sie tun, wohin sie loggen oder irgendwie mal evaluiert hat, ob sie überhaupt gebraucht werden?

Es gibt viele Probleme, die man selbst nicht hat, aber trotzdem nach einer Lösung verlangen. :)



Das das Äquivalent von "mail.info /var/log/maillog" in /etc/syslog.conf wäre unter systemd "journalctl -p info SYSLOG_FACILITY=2" (wobei systemd hier noch den Namen und nicht nur die Nummer der Log-Facility akzeptieren sollte).



Das Logging-Modul von systemd nimmt auch den Output der syslog()-Calls von procmail entgegen, so wie es es syslogd unter BSD macht. Der procmail-Output würde also auch beim obigen journalctl-Befehl erscheinen.



Die Admins meinten etwas anderes - wie bildet man in /etc/rc.conf ab, dass ein Dienst neu gestartet werden soll, falls er 30 Sekunden nach Anlauf noch nicht verfügbar ist?

Für den Neustart oder restart von Diensten gibt es bereits Monit oder supervisord. Das gibt's auch für nicht Linuxe. Aber es liegt wohl auch eher an meiner allgemeinen Ablehnung gegenüber Redhat, die auch im Single User Modus alle Dateisystem rw mounten wollen und einen Neustart anbieten, falls das mal nicht klappt; anstatt eine Shell zur Problemlösung.


In diesem Anwendungsfall: Limitierung und Priorisierung von Resourcen (z.B. I/O) von Diensten. Wie kann ich unter BSD verhindern, dass mir ein Dienst (oder auch eine Jail) mit massiver I/O-Last den Rest der I/O-Zugriffe ausbremst?
Skalieren, sei es durch Hardware oder Software.
 
Wenn über 1000 unterschiedliche Dienste in Betrieb sind, kann sich ein Admin schwerlich merken, wie jeder einzelne Dienst seinen Logging-Output schreibt. Es gibt auch Software, die mit einem Dutzend unterschiedlicher Prozessnamen etwas nach syslog schreibt.
Mit "systemctl status" sieht der Admin auf einen Blick, was es mit dem Dienst gerade auf sich hat, ohne sich minutenlang die Informationen aus unterschiedlichsten Quellen zusammensuchen zu müssen.

Bei 1000 Diensten würde ich mir auch nicht die einzelnen Dienstenamen merken können. syslog ist sicherlich verbesserungsbedürftig, aber ich würde das in andere Richtung machen.

Es gibt viele Probleme, die man selbst nicht hat, aber trotzdem nach einer Lösung verlangen. :)

Wenn's nicht kaputt ist, repariere es nicht.

Die Admins meinten etwas anderes - wie bildet man in /etc/rc.conf ab, dass ein Dienst neu gestartet werden soll, falls er 30 Sekunden nach Anlauf noch nicht verfügbar ist?

Möchte man das? Ein Dienst hat einen Grund, wenn er nicht startet. Wir sind hier nicht bei MS-Windows!


In diesem Anwendungsfall: Limitierung und Priorisierung von Resourcen (z.B. I/O) von Diensten. Wie kann ich unter BSD verhindern, dass mir ein Dienst (oder auch eine Jail) mit massiver I/O-Last den Rest der I/O-Zugriffe ausbremst?

Ja, da stimme ich zu. Ich würde das aber auch weiter treiben wollen, und zwar so, dass es auch in Jails funktioniert (aber nicht nur ausschließlich in Jails!). Ich glaube, dass die cgroups (im Hinblick auf Ressourcenverwaltung!) schon eine gute Idee sind. So etwas ähliches könnte man gebrauchen.
 
Möchte man das? Ein Dienst hat einen Grund, wenn er nicht startet. Wir sind hier nicht bei MS-Windows!

Damit möchte das Linux-Lager aber konkurrieren. Fand ich früher allerdings auch selber gut. Aber inzwischen habe ich die technischen Implikationen dieses Wettbewerbs verstanden und daher bin ich jetzt dagegen.
Man kann mit Windows nur konkurrieren, wenn man wie Windows wird. Das heißt auf lange Sicht auch, dass schlussendlich kaum jemand mehr die Funktionsweise des Systems versteht.
Ein zertifizierter Linux-Admin wird dann ähnlich wie ein MSCA heute nicht mehr wissen, was sein System da tut, sondern nur noch wie er Problem A mit Werkzeug B löst. Was für Probleme ein solcher Ansatz hat kann sich hoffentlich jeder selbst denken.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben