Boycott Systemd

[-Nuke-]

Es wäre schön, wenn du bei der Wahrheit bliebst.

Ich hab die Init-Skripte kritisiert weil sie in teils komplett unleserlichem SH geschrieben sind. Im Gegensatz dazu werden Systemd-Init Files als zu eingeschränkt kritisiert. Ich wurde als Inkompetent eingestuft "und sollte keine Server betreuen"... natürlich mit zig weiteren Annahmen über mich. Man kann halt an rc.d nicht allzu viel mehr kritisieren, weil es sonst nicht mehr kann. Aber das wird ja als Kritikpunkt erst gar nicht anerkannt.

Sorry, aber ich bin schon bei der Wahrheit geblieben

 

[-Nuke-]

Der Apache läuft hier aber def. nicht. Problem ist das IMAP Modul von PHP. cat /usr/local/etc/php/ext-20-imap.ini.

Danke für den Hinweis, ich muss mal gucken ob sich das da reingemogelt hat. Apache+PHP5.6 läuft eigentlich ganz gut. Nur wenn ich eine Apache+PHP7 Jail aufsetzen will, geht gar nichts mehr, außer dass sich Coredumps sammeln. PKG schreibt einem ja auch gerne in der httpd.conf rum...

 

[Athaba]

Ich weiß garnicht mehr, wie wir auf PG gekommen sind. Hat jetzt nicht viel mit dem init-System zu tun. Ich mache seit mindesten 8.4 PG-Upgrades auf Produktionssystemen und habe glaube ich nur ein zwei mal Versonen übersprungen (9.0). Da mache ich über die Variante mit vollen Dumps. Ich weiß, dass das nicht für alle Anwendungsfälle möglich ist. Allerdings hat es ein paar Vorteile. War schon öfters mal der Fall, dass pg_upgrade auch ein paar andere Probleme hat oder bestimmte Dinge nicht abdeckt und man dann ohnehin Indices neu machen darf und ähnliche Themen. Da ist dumpall sauberer.

Das tue ich sowohl unter BSD, als auch unter Linux (mit und ohne systemd). pg_upgrade ist ein Graus. Da stimme ich zu. Ganz generell. Nachdem ich PostGIS verwende ist das nochmal ein wenig schwieriger. Ich gehe in den meisten Fällen de pg_dumpall-Weg, denn selbst wenn ich sowas wie Spezial-Pakete für pg_upgrade habe muss ich mich noch um postgis kümmern und das ist eine Sache für sich. Beim 9.6er wurde das Ganze etwas verbessert, mit Verzeichnisstrukturänderung. Das fand ich recht gut.

Nachdem ich auch schon auf PGCons war wundert mich die Behauptung, dass PG-Upgrades irgendwo gut sind ziemlich. Das hätte dort sicher jemand erwähnt, dass das Problem gelöst sein. Mein letzter Stand war, dass man sich jetzt daran machen will, pg_upgrade so umzubauen, dass es eben keine zwei Installationen mehr benötigt. Weiß jetzt den genaue Stand dabei aber nicht.

Unter FreeBSD hatte ich tatsächlich weniger Probleme, was aber nicht an einer großen Eigenheit liegt, sondern einfach daran, dass die Pakete da relativ nah an dem was man von PG bekommt liegen und beim Upgrade keine Automatismen sind, die einem dazwischenfunken. Ein anderer Faktor ist, dass die Dinge meist besser planbar sind, weil die PG-Releases (und wieder PostGIS) relativ unabhängig von Distributions-/OS-Releases sind und ich deshalb sagen kann "Anfang November werde ich das Postges/PostGIS-Upgrade fahren.

Aber wie gesagt, das hat jetzt meines Erachtens relativ wenig mit dem init-System zu tun. Korrigiert mich wenn ich falsch liege!

Wenn man die modernen Init-Systeme auf das Featureset von rc.d runterbricht ja. Verstreut man aber leichte Prisen von Sandboxing, Limits und Laufzeit-Infos, und automatisches Neustarten von Diensten, dann erübrigt sich schnell die Diskussion. Aber das war hier schon vor ein paar Seiten das Thema. Es endete in etwa in "ich brauche das nicht, darum bin ich dagegen".

Ja und nein. Erstens finde ich das grundsätzlich nicht schlecht. Allerdings gibt's da zwei kleine Relativierungspunkte. Erstens finde ich da trotzdem Kommandos fllexibler, beim Sandboxing. Und der zweite Punkt und auch die Begründung dazu ist, dass systemd damit potentiell einen längerfristigen Fehler macht, denn solche Dinge ändern sich. Nein ehrlich, derzeit ist ständig eine andere Art zu virtualisieren hipp. Das sieht gerade aus, als würde das zu viel deprecated Zeug mittelfristig führen. Das ist generell der Fall, wenn man alles in Configs gießt. Man erzeugt damit was, was dann irgendwann Turing Complete wird (jetzt mal übertrieben gesagt und weiß es bei anderen Dingen schon passiert ist) und/oder jede Menge Altlasten entwickelt. Wäre cool, wenn das nicht so ist.

Die Diskussion ist meines Erachtens nicht "ob man das braucht oder nicht". Da stimme ich dir voll und ganz zu. Die Frage und das meinte ich mit philosophisch: Sollen die Dinge "bei Convention" sein und das sind sie bei den meisten rc.d Skripten. Die sind sehr, sehr ähnlich aufgebaut oder will man sie hart haben. Und genau solche Dinge sind es ja auch was diverse Flamewars wenn's um Programmiersprachen geht starten. Welche Dinge sollen wie lang und wie explizit sein und ähnliches. Da kannst du in alle Extremen gehen und alle werden einen Hauch unterschiedliche Meinungen haben.

Wenn das alles so objektiv wäre hätten wir weniger Programmiersprachen, Betriebssystem, Linuxdistributionen, Editoren, SQL-Datenbanken, init-Syteme, ... Dann gäb's nur eine Hand voll. Die hätten ein paar klar daefinierte Vor- und Nachteile. Allerdings gibt es davon zig, bis hunderte, die tatsächlich produktiv genutzt werden. Leute und Unternehmen sind damit erfolgreich sind und sich gegenseitig in unterschiedlichster Hinsicht überlegen.

Ich stimme dir ja zu, dass viel zu viel über systemd geflamed wird und ich gestehe auch gerne ein, dass ich da manchmal mitmache bei so Stammtischdiskussionen, aber mal ehrlich, der "What the Fuck" Level ist groß. Da haben die systemd-Leute auch teilweise eingesehen und eingelenkt. Solche Dinge würde ich dann auch nicht mehr argumentieren, außer dass es halt kein gutes Bild macht, insgesamt.

Was du auch angesprochen hast ist, dass man Dinge auswechseln kann - wie gut das geht ist lass ich mal offen und will ich auch wirklich nicht diskutieren. Das ist gut, aber das ist meines Erachtens auch ein Problem bei solchen Diskussionen. Systemd ist ja auch wenn es au mehrere Pakete, Module, ... aufgeteilt ist alles unter einer Fahlen und an jedem Eck gibt's natürlich Kritikpunkte. Da kommt was zusammen. Das wirst du aber auch anderswo haben. Da ist dann mitunter auch die Frage berechtigt, warum man gleich 20 andere Dinge untergeschoben (klingt jetzt negativer als gemeint) bekommen muss. Gerade im Linuxbereich regt das die Leute ja mitunter etwas auf. systemd ist ja mehr ein Toolbelt, als ein Initsystem, aber so halb unter einem Namen.

Und dass es schlechte rc.d-Skripte und gute Skripte gibt, genauso wie Unitfiles will ich ebenfalls nicht bestreiten. Ändert eben trotzdem nichts dran, dass systemd+tools genug Macken hat und nicht perfekt ist. Ich find's eben allein schon deshalb und auf Grund von eh schon erwähnten einfach nicht schlüssig wenn man behauptet, dass systemd objektiv besser als etwaige Alternativen ist. Für gewisse Anwendungsfälle ganz sicher, aber du hast trotzdem deine Vor- und Nachteile und dafür hat systemd anderswo Defizite.

Allein schon ob init und supervisor das selbe System sein soll hat auch schon vor systemd zu Glaubenskriegen geführt.

So wie hier. Wenn rc.d in FreeBSD kritisiert wird, wird man ja auch gleich als inkompetent bezeichnet.

Hast du da ein Beispiel?

rc.d hat mir beim Versuch Apache 2.4+PHP7 zum Laufen zu kriegen auch dauernd gesagt, dass Apache "started" sei... nö.

Habe ich unter Arch Linux auch mit einem Service. Das ist ganz komisch. Gar kein Output und wenn ich entweder nochmal start mache oder restart klappt's. Ich glaube es ist eine Initialisierungssache, aber es ist recht seltsam.

Einen anderen Punkt, den ich hatte (verwende die Software aber nicht mehr) war, dass ich im Zusammenhang mit sd-notify ein Problem hatte. Das war eine Software, die als erstes sd-notify gemacht hat. Mit fork, ziemlich am am Anfang in main. Der Code wurde definitiv aufgerufen, trotzdem hat systemctl ziemlich zufällig dort gehangen. Keine Rückmeldung. Meine meisten negativen Erfahrungen sind Dinge, wo ich keinen Output dazu habe was gerade passiert ist. Das wundert mich deshalb, weil ja systemd eben auch Supervisor sein soll und da ist sowas doch recht kritisch. Ja, rc.d ist kein Supervisor, aber dafür hat rc.d auch noch keines der beiden Probleme.

Wie gesagt, das Spiel kann man ewig betreiben und auch nicht nur zwischen systemd und rc.d.

Bei einer weiteren Sache stimme ich dir auch noch zu: Sachen zu kritisieren mit denen man nicht arbeitet, die man nicht gelernt hat macht die Sache recht fruchtlos. Das ist ein wenig das, was vor allem anfangs von der Community bei systemd so stark kritisiert wurde und auch bei Pulseaudio, dass einfach so wahnsinnig schlecht mit Kritik umgegangen wird.

Von dem was du so schreibst, scheinst du die genau gegenteiligen Erfahrungen gemacht zu haben, aber das sind Dinge, die ich an den BSDs, PostgreSQL und anderen Projekten so stark schätze. Man ist meist sachlich und Lösungsorientiert. Man ist vielleicht nicht übermäßig freundlich (häufig doch), aber recht faktenorientiert. Soll heißen, dass wenn man einen Stuss macht oder Behauptungen aufstellt, für die es keine Beweise oder Hinweise gibt man das direkt gesagt bekommt, aber man Kritik nicht unsachlich abwehrt.

Für rc.d habe ich jetzt noch nicht viel Kritik gesehen. Das hat mich nie wirklich interessiert (ist einfach nicht meine Priorität bzw. eben hinreichend gut - aber auch nicht perfekt), aber dein Beispiel oben was pg_upgrade betrifft. Das wurde nie als "das war schon immer so" oder gute Situation bezeichnet. Da war man sich immer einig, dassdas besser sein könnte und sollte. Vielleicht gab's Diskussionen über Priorität davon, manche meinten, dass das nicht so arg wichtig für sei, aber das war's.

Ein anderes Thema ist dann auch noch, dass man verschiedene Vorstellungen von Modularität haben kann. Unter systemd hat man quasi die Funktionalität von daemon(8) drin unter FreeBSD baut man das ins RC-Script. Ist aufwendiger und explizit. Persönlich finde ich daemon(8) für eine sinnvollere Methode, aber wenn andere, auch auf Grund ihrer wahrscheinlich anderen Erfahrungen systemd's Art bevorzugen dann glaube ich ihnen das auch und halte sie nicht für dumm oder so. Ist aber trotzdem einfach nur ein anderer Weg das zu tun, mit anderen Vor- und Nachteilen und wenn dann so Argumente kommen, wie "Das ist aber die Zukunft, weil daemon ist älter [wurde zeitlich früher programmiert]", dann beginne ich mir schon Sorgen über die Art der Argumentation zu machen. Da wüsste ich selbst bessere/echte Kritikpunkte.

Und TrueOS ist gerade auf OpenRC umgestiegen - mit dem von Kris Moore verkündeten Ziel, bei Erfolg auch FreeBSD dafür zu gewinnen.

Wow, wusste ich noch gar nicht. Sehr cool!

EDIT: Uff, sorry für die langen Posts. Tu mir echt schwer sie zu kürzen.

EDIT2:

ch hab die Init-Skripte kritisiert weil sie in teils komplett unleserlichem SH geschrieben sind. Im Gegensatz dazu werden Systemd-Init Files als zu eingeschränkt kritisiert.

Ich hoffe du fasst Kritik an systemd nicht als persönlich auf?

Ich wurde als Inkompetent eingestuft "und sollte keine Server betreuen"... natürlich mit zig weiteren Annahmen über mich.

Wo? Ich habe jetzt nach "keine Server betreuen" gesucht, aber nur deine Aussage hier gefunden. Bin mir nicht ganz sicher was du mit den Annahmen über dich meinst.

 

[Yamagi]

Unter FreeBSD hatte ich tatsächlich weniger Probleme, was aber nicht an einer großen Eigenheit liegt, sondern einfach daran, dass die Pakete da relativ nah an dem was man von PG bekommt liegen und beim Upgrade keine Automatismen sind, die einem dazwischenfunken. Ein anderer Faktor ist, dass die Dinge meist besser planbar sind, weil die PG-Releases (und wieder PostGIS) relativ unabhängig von Distributions-/OS-Releases sind und ich deshalb sagen kann "Anfang November werde ich das Postges/PostGIS-Upgrade fahren.

Darum sind die 3 wichtigsten Regeln beim Arbeiten mit großen Postgresql-Clustern:

1. Compile das Ding selbst, installiere es nach /postgresql/server/$version und setze einen Symlink nach /postgresql/server/active.
   
2. Compile das Ding selbst, installiere es nach /postgresql/server/$version und setze einen Symlink nach /postgresql/server/active.
3. Compile das Ding selbst, installiere es nach /postgresql/server/$version und setze einen Symlink nach /postgresql/server/active.

Das ist C89-Code, es baut überall. Durch das Selbstbauen eliminiert man erstmal alle gut gemeinten, aber oft undurchdachten Distributionseigenheiten. Man muss auch nicht darauf vertrauen, dass nicht irgendwelche irren Maintainer meinten unqualifiziert am Code rumpatchen zu müssen. Man kann neue Versionen sofort einsetzen und muss nicht darauf warten, bis sich der Distributor mal dazu bequemt die Pakete zu aktualisieren. Falls das überhaupt jemals passiert. Und vor allem kann man so viele Versionen parallel installiert haben, wie man will und zwischen ihnen wechseln, wie man lustig ist.

 

[-Nuke-]

[...]

Die PostgreSQL Sache hat nichts mit dem Init-Daemon zu tun. Das ist mehr eine Macke in den Ports. Wie gesagt, wenn du ein pg_dumpall von z.B. 9.5 mit den 9.5 Clients machst und das dann in der nächsten Version von PostgreSQL einspielst, dann läuft das gegen der Empfehlung der Entwickler. Ich kenne da auch nicht jede Möglichkeit die da schief gehen kann, wenn man das so macht.

Offizielle Pakete von PostgreSQL für die verschiedenen Linux-Distributionen sind allesamt parallel installierbar und gehen meist nach /usr/pgsql/<version>. Ich fragte mich, warum das unter FreeBSD nicht auch so gemacht wird und habe damals auf der Mailingliste gefunden "Wir sind uns dem Problem bewusst, aber wir wollen das nicht ändern, weil wir das schon immer so gemacht haben"...

Und zu systemd vs rc.d: Ich will jetzt auch nicht "ich habe da ein Problem" Ping-Pong spielen. Jeder macht andere Erfahrungen. Meine eigentliche Frage war, wie hier ein neues Init-System in FreeBSD aufgenommen werden würde. Diese orientieren sich ja gerne an OpenRC, systemd und Co. und bieten ähnliche Features.

Klar ist systemd hochgradig Linux orientiert und benutzt allerhand Features wie seccomp Sandboxing, cgroups und Co. Aber z.B. ein Flag wie "ProtectSystem=" im Service-File sagt, wie der Dienst vom System abgeschottet werden soll. Das ist halt nicht großartig relevant wie das geschieht. Es sagt nicht aus ob SELinux, AppArmor oder Seccomp. Das Flag kann also mit steigenden Anforderungen oder seiner Umgebung "mitwachsen". Dass ExecStart auch Skripte aufnimmt und man dementsprechend komplexere Startroutinen nicht unbedingt ins Service-File rein packen muss, wird warum auch immer, bei Seite geschoben.

Ich weiß jetzt nicht wie Capsium in FreeBSD genau umgesetzt werden soll oder bereits ist, das steht noch auf meiner ToDo Liste.

Wie gesagt, eigentlich wäre ich auch eher an einer Diskussion, rund um die Dinge die man in FreeBSD verbessern könnte, interessiert. Und nicht nur "das funktioniert, das muss man nicht ändern". Und wie gesagt, meine Vorlage ist halt systemd, weil es eben ein weit verbreitetes anderes Init-System ist und es eben auch in den Thread passt. Und wie ich auch schon gesagt habe, es geht mir nicht darum systemd zu feiern. Es geht mir auch nicht darum was an systemd jetzt schlecht ist. Es geht eher um die Dinge die Systemd gut macht, die nicht in FreeBSD funktionieren. Und da ist es mir zumindest relativ egal was in systemd nun nicht geht. Der Kontext ist also ein ganz anderer.

Ich hoffe du fasst Kritik an systemd nicht als persönlich auf?

Natürlich nicht. Mir sind Details von systemd auch vollkommen Wumpe. Mir ist es auch gar nicht wichtig ob Systemd, OpenRC, runit oder sonst was. Mir geht es allgemein um die hier vorherrschende Feature-Phobie. Da wird halt eine Aussage von vielen rausgepickt und darauf rumgehackt. Und wenn ich dann sehe wie man im systemd-Bereich mit Kritik umgeht und dann hier sehe wie hier mit Kritik umgegangen wird, dann sehe ich dort ziemliche parallelen. Nur entgegengesetzte Seiten.

Wo? Ich habe jetzt nach "keine Server betreuen" gesucht, aber nur deine Aussage hier gefunden. Annahmen über dich?

Aussagen wie: "Wenn du Shell nicht kannst, solltest du keinen Server betreiben dürfen. Das ist eine Gefahr für dich und alle Besucher." oder "anscheinend nicht in der Lage, dir das anzueignen". Irgendwo waren noch mehr. Nur weil ich die krude Syntax von SH und die SH-Codequalität in FreeBSD kritisiert habe. O-Ton der Rückantwort: "Das muss man können sonst bist du eine Gefahr und Dumm"...

 

[TCM]

Das Einzige, was ich lese, ist "Details interessieren mich nicht". Das klingt nach genau der neumodischen Art Admins, die nichts mehr durchschauen, nur aufs Knöpfchen drücken und wenn mal was nicht geht, wird's neu aufgesetzt. Wenn dich das alles nicht interessiert, warum fühlst du dich dann ständig dazu berufen, bei sowas mitzudiskutieren? Nimm doch das, was dir am besten gefällt und womit du ohne zu große Anstrengung zurechtkommst.

Meine eigentliche Frage war, wie hier ein neues Init-System in FreeBSD aufgenommen werden würde.

Warum, wenn du nicht am System interessiert bist? Du willst anscheinend nur ohne große Anstrengung einen bestimmten Dienst am Laufen haben. Dann nimm doch Linux oder was auch immer und gut ist. Warum muss man dann in die Community einsteigen und Änderungen fordern, für deren nähere Details man sich sowieso nicht interessiert und den Leuten dann noch "Fortschritt"sverweigerung vorwerfen, wenn sie zig Beispiele bringen, die genau belegen, dass dieser "Fortschritt" halbgarer Unfug ist?

Aber z.B. ein Flag wie "ProtectSystem=" im Service-File sagt, wie der Dienst vom System abgeschottet werden soll. Das ist halt nicht großartig relevant wie das geschieht.

Wenn du sowas nicht relevant findest, ist das doch OK. Nur warum dann ständig mitreden wollen?

 

[Athaba]

Wie gesagt, wenn du ein pg_dumpall von z.B. 9.5 mit den 9.5 Clients machst und das dann in der nächsten Version von PostgreSQL einspielst, dann läuft das gegen der Empfehlung der Entwickler. Ich kenne da auch nicht jede Möglichkeit die da schief gehen kann, wenn man das so macht.

Sorry, aber das stimmt so nicht. Das ist die allererste Empfehlung im Handbuch. pg_upgrade kann auf viele Arten schief gehen. Kann es sein, dass du das verwechselst?

Wenn du pg_upgrade nutzt, dann hast du Dinge die schief gehen können, aus unterschiedlichen Gründen, eben weil es ein Binärformat ist. Bugs, Unterschiede bei den kompilierten Versionen, gerade third party libs (mein Favorit bleibt PostGIS) können allesamt Problme machen. pg_upgrade hat einen Vorteil, nämlich Ressourcen zu sparen, was vor allem bei großen Datensets wichtig ist. Leider benötigt es (noch - man überlegt wie man das verbessern könnte) die alte und neue Version. Wenn man PG ohne Extensions verwendet geht das meist gut. Wenn man Extensions hat und die vielleicht auch upgraden will oder muss braucht man da ebenfalls beide Versionen. Die sind schon seltener als Packages vorhanden. Ganz schlimm und das habe ich auch schon öfters erlebt ist wenn die alte Version, dann bestimmte andere Version von Extensions hat. Und am aller schlimmsten, wenn pg_upgrade was übersieht. Gab's auch mal, aber drum warte ich gerne ein wenig ab mit dem Upgrade auf ein neues Major.

pg_upgrade habe ich auch schon mal gemacht. Da habe ich einfach das alte Paket genommen und dann entsprechend woanders hin gepackt. Auch wenn ich persönlich weiterhin mit dumpall arbeiten würde stimme ich dir zu, dass eine parallele Installation nicht schlecht wäre, nur kenne ich Distributionen wo das relativ halbherzig gemacht wurde und dann ist es nervig, wenn man erst herumfickeln muss. Man müsste sich halt überlegen wie man das besser macht, oder man löst es bei Postgres. Wie gesagt, die planen schon ein Weilchen die Situation zu verbessern.

Aber ja, status quo könnte besser sein. Ich glaube nicht, dass dir da grundsätzlich jemand widerspricht. Dass man nichts kaputtmachen will halte ich für sinnvoll. Hört sich jetzt aber mal nicht so an als würde man nichts ändern wollen würde. Auch, dass man die Verzeichnisse und den Postges-User umbenannt hat zeigt schon Willen auch zu einschneidenderen Änderungen.

Natürlich nicht. Mir sind Details von systemd auch vollkommen Wumpe. Mir ist es auch gar nicht wichtig ob Systemd, OpenRC, runit oder sonst was. Mir geht es allgemein um die hier vorherrschende Feature-Phobie. Da wird halt eine Aussage von vielen rausgepickt und darauf rumgehackt. Und wenn ich dann sehe wie man im systemd-Bereich mit Kritik umgeht und dann hier sehe wie hier mit Kritik umgegangen wird, dann sehe ich dort ziemliche parallelen. Nur entgegengesetzte Seiten.

Ich rede jetzt mal nicht von Usern. Die sind häufig extremer als die wirklich aktiven Entwickler und das sind auch die "den Verantwortlichen", also den Entwicklern. Siehst du das Problem da auch?

Ich stimme dir schon zu, dass grundsätzlich Angst vor Neuem schlecht ist. Skepsis ist angebracht. Da sieht man auch in der Linuxwelt Fehler und eben Systeme, auf die alle Distributionen umsteigen und dann wird im zweijahrestakt gewechselt (hald zum Beispiel).

Allerdings sehe ich die Angst nicht groß. Virtualisierung/Container gab's unter FreeBSD früher, capsicum ist daraus entstanden, dass man was in Richtung seccomp haben wollte. Das wird gleich zu "eat your own dogfood gemacht" (stärker als bei Linux. Das ist seit Ewigkeiten im Kernel). Wenn man sich so Sachen wie TrustedBSD und HardenedBSD ansieht, dann ist das in etwa so, wie Linux und deren diverse Patchsets.

Eigentlich wurde jede gute Idee aus der Linuxwelt, oft mit gelernten Fehlern aufgenommen und Linux hat FreeBSD-Teile aufgenommen (Netzwerkstack, Container). FreeBSD hat auch ein paar Sachen die schon so alt sind, dass sie niemand mehr anspricht, die Dinge abdecken, die gerade erst in die Linuxwelt kommen. Security Levels, die du fürs Hauptsystem und für Jails getrennt verwalten kannst.

Und ich denke auch, das Kritik aufgenommen wird. Man sehe sich an, wie immer alle zu third party packages gegriffen haben für jails. Das jail utility ist extrem gut und überhaupt nicht verwirrend. Die Config ist prima. Es ist simpel und flexibel und wenn man darauf dann noch aufbauen möchte ist das ebenfalls leicht möglich.

Vielleicht sind wir komplett auf unterschiedliche Leute gestoßen, aber mir ist es scheinbar komplett anders ergangen. Das Einzige, was ich weiß, dass manche beunruhigt ist dass Dinge kürzer/effizienter bzw. mehr auf den Punkt kommuniziert wird. Das merkt man auch beim Problemlösungsverhalten und ist mir auch mit anderen Leuten aus anderen Communities aufgefallen. Wenn jemand mit seinen Vermutungen oder dem Verständnis in die offensichtlich falsche Richtung läuft wird schneller darauf hingewiesen. Außerdem wird generell präziser kommuniziert. Es gibt da mehr Besorgnis darüber, dass etwas falsch verstanden wird und die Person oder man selbst deshalb Zeit verschwendet. Letzteres ist eine Sache, die ich sehr schätze, die aber glaube ich dazu führt, dass man sich manchmal abgeblockt fühlt. Dass die Zeit anderer Personen aber hoch eingeschätzt wird halte ich für gut.

Denkst du es könnte das sein? Wie gesagt, mir ging's noch nicht so, dass ich das Gefühl hatte FreeBSD würde was abblocken, sondern eher, dass es mehr Mitarbeiter/Zeit braucht.

 

[-Nuke-]

Sorry, aber das stimmt so nicht. Das ist die allererste Empfehlung im Handbuch. pg_upgrade kann auf viele Arten schief gehen. Kann es sein, dass du das verwechselst?

Nein, ich meine das hier:

"It is recommended that you use the pg_dump and pg_dumpall programs from the newer version of PostgreSQL"

Und genau das ist in FreeBSD eben schwierig über pkg zu erreichen. Und eben auch so 2 Versionen parallel usw.

Denkst du es könnte das sein? Wie gesagt, mir ging's noch nicht so, dass ich das Gefühl hatte FreeBSD würde was abblocken, sondern eher, dass es mehr Mitarbeiter/Zeit braucht.

Naja, ich kenne die Historie dahinter nicht, aber z.B. HardenedBSD ist entstanden, weil Features wie ASLR in FreeBSD (zumindest in der Form) nicht angenommen wurden.

 

[-Nuke-]

Das Einzige, was ich lese, ist "Details interessieren mich nicht".

Mich interessieren eben in einer Diskussion rund um moderne Init-Systeme eben gezielte Schwächen von systemd nicht, sondern um die globale Verbesserung im Init-System. Unabhängig von systemd. Das hab ich auch geschrieben. Aber wie ich dir letztes mal schon geschrieben habe, wäre es nett, wenn du nicht immer bei "systemd" aufhören würdest zu lesen.

Das klingt nach genau der neumodischen Art Admins, die nichts mehr durchschauen, nur aufs Knöpfchen drücken und wenn mal was nicht geht, wird's neu aufgesetzt. Wenn dich das alles nicht interessiert, warum fühlst du dich dann ständig dazu berufen, bei sowas mitzudiskutieren?

Genauso könnte ich jetzt behaupten, du bist ein fauler Alt-Admin der mit moderner Technik nicht mehr klar kommt und deswegen abweisend reagierst. Aber persönliche Angriffe helfen nicht. Das sorgt nur dafür, dass ich den Diskussionspartner weniger ernst nehme.

Nimm doch das, was dir am besten gefällt und womit du ohne zu große Anstrengung zurechtkommst.
Warum, wenn du nicht am System interessiert bist? Du willst anscheinend nur ohne große Anstrengung einen bestimmten Dienst am Laufen haben. Dann nimm doch Linux oder was auch immer und gut ist.

Die Behauptung ich wäre nicht am System interessiert kommt von dir. Ich habe mich mit systemd befasst. Ich weiß wie es funktioniert... Ich weiß halt nicht was an einem Wunsch nach Verbesserung schlecht ist?

Warum muss man dann in die Community einsteigen und Änderungen fordern, für deren nähere Details man sich sowieso nicht interessiert und den Leuten dann noch "Fortschritt"sverweigerung vorwerfen, wenn sie zig Beispiele bringen, die genau belegen, dass dieser "Fortschritt" halbgarer Unfug ist?

Ich weiß jetzt nicht, ob die Daten korrekt sind, aber... ich bin schon 1 Jahr länger hier als du? Willst du mich jetzt rausekeln, weil ich nicht deiner Meinung bin und nicht alles feiere was in den BSDs enthalten ist? Wäre mir neu, wenn man, um hier schreiben zu dürfen, erst sämtliche Kritik an den BSDs am Login-Fenster abgeben muss.

Wenn du sowas nicht relevant findest, ist das doch OK. Nur warum dann ständig mitreden wollen?

OK, noch mal genauer: Der Flag "ProtectSystem=" legt keine Technologie dahinter fest. Es wurde vorhin gesagt, dass systemd in seine Service-Files Techniken einbaut, die ggf. irgendwann wieder deprecated oder überholt sind. Genau das ist so ein Flag aber z.B. nicht.

 

[-Nuke-]

Denkst du es könnte das sein? Wie gesagt, mir ging's noch nicht so, dass ich das Gefühl hatte FreeBSD würde was abblocken, sondern eher, dass es mehr Mitarbeiter/Zeit braucht.

Bearbeitungslimit abgelaufen, darum noch Ergänzung:

Wie gesagt, hauptsächlich habe ich 2 (im Detail 3) große Kritikpunkte an FreeBSD.
1. Das Init-System (offensichtlich), weil es mehr oder weniger nur ein "Fire-And-Forget" System ist

(2./3.) die Ports und deren Beschreibung sind komplex, haben ggf. schlechte Standard-Optionen (z.B. Option A ist nicht gesetzt, weil es Probleme in FreeBSD 8 macht, zu Zeiten von FreeBSD 10). Die Komplexität zeigt sich dadurch, dass man gerne Probleme hat, wenn man mal eine Option ändert. Leider wurde sich auch entschieden, dass man von Grund auf ein neues Paketsystem von Grund auf zu schreiben. Man versucht halt irgendwie alle glücklich zu machen und naja... der Prozess läuft noch. So wirklich schön ist die Benutzung von PKG auch heute nicht. Und wenn einem die Standard-Optionen nicht ausreichen und z.B. poudriere nimmst, dann viel Spaß, wenn du eine Python3 Anwendungspaket erzeugen willst, über PKG.

Gerade bei (2/3) habe ich im Alltag die meisten Probleme. Also PKG hat schon so einiges verbessert. Ich erinnere mich noch an alte portmaster (und früher) Zeiten... boah, war das teilweise anstengend. Die Diskussion um PKG ging sehr sehr lange und hatte auch diverse Kritiker. Vermutlich ist auch genau aus dem Grund PKG jetzt so eine Zwischenlösung aus Ports und PKG. Ich sehe das als "Man hat eine Lösung mit den Nachteilen von Ports und den fehlenden Features, weil es komplett neu entwickelt wurde".

Da würde ich mir manchmal schon eine schöne Clean-Room Implementierung (oder eben die Nutzung eines erprobten Linux-Paketmanagers) wünschen, wo man eben ein paar Leute auf der Strecke lässt, aber das System als Ganzes voranbringt.

Und ist ja nicht so als wenn FreeBSD hier gerade auf jedem zweiten Server zum Einsatz kommt. Im Gegenteil, es fehlt an allen Ecken und Enden.

 

[TCM]

Ich weiß wie es funktioniert

Du weißt, wie du deinen einzelnen use-case damit abbildest. Wie es "funktioniert", weißt du nicht, oder bist du in den Code eingestiegen? Wie sehen doch hier ständig, wie schlechtes Design in systemd hochblubbert. Die funktionale Ebene ist bei systemd doch vollständig verborgen, oder willst du mir erzählen, dass du bei systemd im C-Code rumkramst? Du nutzt doch nur, was dir als Oberfläche vorgesetzt wird, und das ist ein Config-Format, kein Code. Wir reden aber davon, wie es darunter aussieht. Nur weil du das nicht wie bei rc direkt siehst, heißt das nicht, dass es die heilsbringende Offenbarung ist.

Da würde ich mir manchmal schon eine schöne Clean-Room Implementierung (oder eben die Nutzung eines erprobten Linux-Paketmanagers) wünschen, wo man eben ein paar Leute auf der Strecke lässt, aber das System als Ganzes voranbringt.

Es scheint, du leidest an der typischen Linuxer-Krankheit: Irgendwas gefällt mir nicht oder ich verstehe es nicht, also muss man es komplett entsorgen und neuschreiben. http://www.joelonsoftware.com/articles/fog0000000069.html hat Näheres dazu. https://xkcd.com/927/ dito.

Was das pkg-System auf einmal mit alledem zu tun hat, wäre dann die nächste Frage.

Dein Interesse daran, wie konkrete OSes ihre Init-Systeme handhaben, läuft irgendwie orthogonal zu deiner tatsächlichen Nutzung. Was konkret machst du mit FreeBSD, was nicht auch mit Linux ginge, wo du dein systemd vollständig zur Verfügung hast? Das wird einfach nicht klar. Irgendwelche Details interessieren dich nicht, aber du bist sicher, dass du genau FreeBSD und nichts anderes brauchst. Warum?

Und warum ist sowas z.B. gut oder sinnvoll? https://bugs.freedesktop.org/show_bug.cgi?id=64116 Warum kann man so grundlegende "Details" wie 1) binäre Logs 2) die korrupt werden können 3) irreparabel sind, einfach ignorieren? Das kann man doch nur, wenn man noch nie auf ein Log mal wirklich angewiesen war, sprich: wenn man eigtl. keine ernstzunehmende Admin-Tätigkeit ausführt. Warum sollte man sich sowas freiwillig ins Haus holen? Was ist der gigantische Nutzen, der sowas rechtfertigt? Und warum bedingt eine Neuerung, dass man gleich sämtliche "Altlasten", darunter auch sinnvolle, komplett über den Haufen wirft und alles in einen gigantischen Moloch zusammenbackt? Warum muss systemd ntpd, dhcpd, ... spielen? Das sind alles Anmaßungen, die zurecht Skepsis erzeugen. Sowas einfach abzuspeisen mit "aber es ist für mich einfacher zu benutzen", bringt's irgendwie nicht. Nutz doch einfach, was für dich einfacher ist, warum sollen alle anderen da mitmachen?

 

[-Nuke-]

Es scheint, du leidest an der typischen Linuxer-Krankheit: Irgendwas gefällt mir nicht oder ich verstehe es nicht, also muss man es komplett entsorgen und neuschreiben. http://www.joelonsoftware.com/articles/fog0000000069.html hat Näheres dazu. https://xkcd.com/927/ dito.

Du meinst, so wie man pkg komplett neu geschrieben hat, statt erprobte Sachen zu nehmen die täglich Millionenfach Anwendung findet?

Dein Interesse daran, wie konkrete OSes ihre Init-Systeme handhaben, läuft irgendwie orthogonal zu deiner tatsächlichen Nutzung. Was konkret machst du mit FreeBSD, was nicht auch mit Linux ginge, wo du dein systemd vollständig zur Verfügung hast? Das wird einfach nicht klar. Irgendwelche Details interessieren dich nicht, aber du bist sicher, dass du genau FreeBSD und nichts anderes brauchst. Warum?

Es sind Sachen die mich an FreeBSD stören. Es geht hier nicht um Linux vs FreeBSD, sondern einfach nur um Alltag in FreeBSD. Und so die feinen Details wie die umfassende Dienstüberwachung sind einfach sehr angenehm.

Und ja, mir gefällt eben die Frist-Class Interation von ZFS und Jails gefallen mir auch sehr (auch wenn man gerne die Idee vom Tooling von Docker übernehmen könnte). Auch dass FreeBSD als Basissystem mehr als ein Kernel ist, ist eine nette Sache. Und nein, ich wechsel nicht nur wegen des Init-System das OS auf einem Großteil meiner Server. Aber ich erlaube mir einfach die Kritik an anderen Systemkomponenten.

Und warum ist sowas z.B. gut oder sinnvoll? https://bugs.freedesktop.org/show_bug.cgi?id=64116 Warum kann man so grundlegende "Details" wie 1) binäre Logs 2) die korrupt werden können 3) irreparabel sind, einfach ignorieren? Das kann man doch nur, wenn man noch nie auf ein Log mal wirklich angewiesen war, sprich: wenn man eigtl. keine ernstzunehmende Admin-Tätigkeit ausführt. Warum sollte man sich sowas freiwillig ins Haus holen? Was ist der gigantische Nutzen, der sowas rechtfertigt? Und warum bedingt eine Neuerung, dass man gleich sämtliche "Altlasten", darunter auch sinnvolle, komplett über den Haufen wirft und alles in einen gigantischen Moloch zusammenbackt?

Ja, journald ist scheiße... und? Einfach weiter syslog nehmen... wo ist das Problem?

Warum muss systemd ntpd, dhcpd, ... spielen? Das sind alles Anmaßungen, die zurecht Skepsis erzeugen. Sowas einfach abzuspeisen mit "aber es ist für mich einfacher zu benutzen", bringt's irgendwie nicht. Nutz doch einfach, was für dich einfacher ist, warum sollen alle anderen da mitmachen?

Macht systemd nicht. Und nur weil ein Programm "systemd-<irgendwas>" heißt, ist das kein Teil von systemd als PID1. Ja es _nutzt_ systemd als Ökosystem, aber seit Erscheinen von systemd hab ich noch _keines_ dieser Sachen benutzt. Warum sollte ich also systemd dafür kritisieren, dass sie optional weitere Sachen anbieten? Ich kann das Teilprojekt kritisieren, ja. Aber das hat doch mit systemd als Init-System nichts zu tun.

 

[Athaba]

Naja, ich kenne die Historie dahinter nicht, aber z.B. HardenedBSD ist entstanden, weil Features wie ASLR in FreeBSD (zumindest in der Form) nicht angenommen wurden.

Ist offiziell glaube ich noch im Review. -> Wieder mehr Mitarbeiter.

Ich vergleiche da nur gern mit anderen Projekten und dieses "im Review" ist ein Status ähnlich wie unter Linux. Da gibt es mindestens zwei Patchsets, die beide ein keiner Mainstream Distribution sind und nur in Hardened Varianten zu finden sind (Hardened Gentoo zum Beispiel).

Und das sind solche "mal Langsam" Themen, die ich eigentlich als gutes Zeichen sehe, sowohl, bei Linux als auch bei BSD. Keine Featureritis, wo man dann zwei Jahr später den Salat hat, weil unmaintained ist, offene Sicherheitslücken hat, Zeit kostet es weiterzuentwickleln und auch es wieder raus zu hauen. Da stehen meist auch generelle Designentscheidungen dahinter und das sind das wo viele Projekte kämpfen, wenn man sagt man mag Feature X und es wird dann "irgendwie" gemacht. Das sind Dinge, wo du einen Tauschhandel begehst. Du kannst sagen "dann haben wir das wenigstens mal", aber das kann eben auf Kosten zukünftiger Entwicklung gehen.

Und dann eben die Priorisierung. Die einen wollen endlich, dass ihre HW läuft, die anderen wollen Verbesserungen an Jails und wieder andere wollen, dass ASLR endlich gereviewed bekommen.

Was man von den Leute so mitbekommt klingt als wäre das große Thema bei Core mitzumachen einfach Zeit. Dann kann man das ordentlich beschleunigen. Aber auch sonst kann man mitarbeiten:

https://reviews.freebsd.org/D5603

Edit/Randbemerkung:

auch wenn man gerne die Idee vom Tooling von Docker übernehmen könnte

Okay, ich gebe mal zu, dass ich von Docker nach anfänglicher Begeisterung (siehe dazu auch einen Thread von mir) ziemlich entgeistert bin und einige Teile in der praktischen Umsetzung für eher kontraproduktiv in der produktiven Nutzung halte.

Aber wenn dir der Workflow grundsätzlich gefällt, je nachdem was dir daran gefällt:

• https://wiki.freebsd.org/Docker
  
• https://github.com/3ofcoins/jetpack (falls dir/euch rkt was sagt)
  
• https://github.com/cbsd/cbsd (verdient meines Erachtens mehr Publicity)
• jail(8)

Sorry, drifte da ein wenig ab. Vielleicht sollten wir einen neuen Thread zu FreeBSD Tooling und derartige Themen starten? Was man besser machen könnte und nicht unmittelbar systemd ist?

 

[Sickboy]

Systemd is about choice. -.-

 

[mark05]

moin

FreeBSD wird doch nicht ............. nein ich will mir das nicht vorstellen .............


und Docker muss auch nicht sein .

Holger

 

[foxit]

und Docker muss auch nicht sein .

Docker selber nicht aber das Konzept/Technologie dahinter bitte schon! Wie das implementiert wird, über Projekte wie containerd [1] oder Jetpack [2], ist mir eigentlich egal.

[1] https://github.com/3ofcoins/jetpack
[2] http://www.pro-linux.de/news/1/24291/docker-lagert-containerd-in-eigenes-projekt-aus.html

 

[mark05]

hi

doch docker als solches , solange die sicherheits probleme nicht gelöst sind.

es ist ein grauen fertige "docks" zu bekommen um dessen inhalt sich dann niemand mehr kümmert , ein schelm wer jetzt an z.b. php
denkt und an sichere pogrammierung und bug freiheit .

sorry das ding ist ein graus ..... aus security sich .

holger

 

[holgerw]

Systemd is about choice. -.-

Nun ja, die Macher wählen sich die potenziellen "Opfer" - so verstehe ich das

Wobei dazu bekanntlich ja mehrere gehören.

 

[goblin]

Systemd is about choice. -.-

Ich sehe das als selbstironischen Humor. Er will uns damit mitteilen, dass wir systemd, Amiga oder FreeBSD nutzen können.
Finde ich prinzipiell sogar fast gut, wenn ein paar kompetente devs zu FreeBSD kommen würden wäre das super.

 

[foxit]

Dieses Foto ist uralt (2014)!

 

[Athaba]

Docker selber nicht aber das Konzept/Technologie dahinter bitte schon! Wie das implementiert wird, über Projekte wie containerd [1] oder Jetpack [2], ist mir eigentlich egal.

[1] https://github.com/3ofcoins/jetpack
[2] http://www.pro-linux.de/news/1/24291/docker-lagert-containerd-in-eigenes-projekt-aus.html

Weil du die gerade erwähnst möchte ich auch folgendes Projekt erwähnen. Heroku-style PaaS mit FreeBSD jails:
https://github.com/adhokku/adhokku

Vielleicht sollten wir da einen Wiki-Abschnitt bauen zu diesen Themen? Ist jemand der gut darin wäre dabei? Falls ja sollten wir dazu aber einen neuen Thread aufmachen. Würde schreiben, aber bin mit dem Rest von Wikis nicht so gut.

Witzig, dass das Thema hier aufkommt. Hatte mal vor Ewigkeiten hier im Forum nach "sowas wie Docker" gefragt. Da geht's mit ein bisschen wie mit systemd. Die Idee ist grundsätzlich nicht schlecht, aber die Umsetzung halte ich auch hier in Teilen echt mies. Dazu zählt das Dockerfile-Format, was wohl nicht so gedacht war, wie es jetzt verwendet wird, was eine quasi eigene Sprache hat was es schwer macht darauf aufzubauen.

Ich kann das teilweise verstehen. Docker hat sich aus einem PaaS, namens dotCloud entwickelt, das ich auch testhalber verwendet habe (Support und Uptime waren grauenhaft) und Docker war zuerst mal was um es deren Infrastruktur in etwa gleich zu tun. Allerdings hat es sich nach dem Release in alle Richtungen entwickelt und vor nicht allzu langer Zeit (ein oder zwei Jahren!) hieß es noch, man solle es keinesfalls produktiv einsetzen, wann auch immer es Kritik hagelte. Da wurde es dann mehr als "lokal schnell eine Testumgebung haben" vermarktet.

Was ich von der Anwendung her so sehe ist wirklich der Hauptgrund, dass Leute Docker nutzen es eine Art Standard bereitstellt wie man etwas lädt und startet. In etwa so wie './configure && make && make install' etwas ist was jeder schnell kann. Ich weiß, das ist teilweise nur ein Nebeneffekt, aber trotzdem, wenn ich mit Leuten rede, die das produktiv nutzen und sie Frage was ihre Hintergedanken war ist die Antwort entweder, dass es das tolle neue sei, oder läuft im Endeffekt genau darauf hinaus. Deshalb bin ich unter FreeBSD auch glücklich über jail.conf(5). Ich glaube da sollte man weiterarbeiten. UCL spielt da auch rein.

Kleine Sache am Rande noch: Viele Standardimages von Docker verwenden Alpine Linux als Basis. Das ist eine ziemlich coole Linuxdistribution für alle die systemd nicht so mögen und was eher BSD-artiges haben wollen (OpenRC, cooles Package Management, LibreSSL, musl libc, ZFS root, starker Fokus auf Security und hat mittlerweile auch Desktopsupport).

Bei beiden Systemd und Docker denke ich, dass sie von der Idee her ganz gut sind, Design und Implementierung allerdings teils gravierende Probleme haben, wobei ich das bei Docker noch ein wenig mehr verstehen kann, weil ich das eher als Test ansehe (sie auch rkt/jetpack als Alternative, die gerade populär wird). Und bei beiden sind viele Leute leider so eingestellt, dass sie meinen man muss es verwenden, unabhängig vom Anwendungsfall und ohne wirklich zu wissen warum, einfach nur weil Hype da ist. Dem ist einfach bei keiner Software so und auch wenn es das immer gibt sind die beiden Communities einfach grauenhaft was das betrifft, wenn man dann ständig über Unwissenheit und auf Falschaussagen stolpert und dann Leute meinen sie müssten ihre Dockerimages nicht updaten oder dass das irgendwelche Magie macht und man sich generell nicht darum kümmern muss und man keinen Admin mehr braucht.

Das es relativ schnell jetpack, Docker-support, so Projekte wie iocage, iocell, iohyve, etc. gibt zeigt meines Erachtens, dass es um Tooling geht. Das ist wieder das was wir weiter oben mit systemd und OpenRC hatten. Einfach von der Nutzung, simpel und programmierbar können sich da teilweise in die Quere kommen, wenn das Design nicht passt. Wenn man eine ganze Sprache, wie Shell-Skripts hat ist man sehr flexibel, aber es kann mit unter zu arger Komplexität führen, andererseits hat man ansonsten leicht das Problem, dass man Unmengen an Deklaration braucht, die noch verwirrender als ein Shellskript sein kann. Docker hat einen kleinen Mix mit CMD und RUN die quasi Shell-Skripts sind und diese auch häufig aufrufen. Ich glaube da hätte man auch JSON, YAML, etc., damit man's mit Standardlibs parsen hätte können, oder was minimalistischeres mit extra Shell-Skript(s). So schlimm ist es aber auch nicht. Wäre nur cool, wenn RUN und CMD ein wenig strikter wären, aber ist jetzt nicht so tragisch. Ist ja sonst recht simpel.

Jetzt habe ich Docker viel aufgegriffen, aber ich bin wohl nicht de Einzige, der da Parallelen in der Entwicklung sieht. Aber ich sehe da vieles positiver, auch weil es grundsätzlich simpler ist und sich schon einige Alternativen auftun, selbst wenn es in vielerlei Hinsicht noch grobe Probleme hat. Das wird nicht ganz so stark und dogmatisch bestritten, wie in weiten Teilen der Systemd-Community, aber das ist auch nur meine persönliche Erfahrung. Wenn man sagt X ist schrecklich und es ist wirklich so, dann wird da auch mal zugestimmt und das nicht gleich als persönlicher Angriff gewertet. Sowas kann einen riesigen Unterschied machen. Wer will schon ein Produkt verwenden, wo die Entwickler keine Kritik (produktiv) aufgreifen?

 

[holgerw]

Kleine Sache am Rande noch: Viele Standardimages von Docker verwenden Alpine Linux als Basis. Das ist eine ziemlich coole Linuxdistribution für alle die systemd nicht so mögen und was eher BSD-artiges haben wollen (OpenRC, cooles Package Management, LibreSSL, musl libc, ZFS root, starker Fokus auf Security und hat mittlerweile auch Desktopsupport).

Hallo @Athaba,

danke für den Hinweis auf Alpine Linux. Da sehe ich Parallelen zu Void Linux, kein systemd, musl lib, bsd ähnliche Werkzeuge.

Viele Grüße,
Holger

 

[CrimsonKing]

Von wegen optional: Textdateien sind nun "deprecated".

 

[Azazyel]

Von wegen optional: Textdateien sind nun "deprecated".

Quelle? In deinem Anhang steht was anderes.

 

[darktrym]

https://access.redhat.com/documenta....3_Release_Notes/new_features_networking.html