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

[McStarfighter]

PCBSDs PBI-Pakete sind im Sinne des Users ja eigentlich sogar der richtige Ansatz, da man es nur herunterladen und doppelklicken muß. Alle möglichen Abhängigkeiten sind im Paket bereits eingebacken und so bekommt man unterm Strich den gleichen "Komfort" wie bei Windows Setup-Paketen.
Auch wenn mir schlankere PBIs lieber wären und dynamisch statt statisch verlinkt werden würde.

[SolarCatcher]

Zitat von McStarfighter

PCBSDs PBI-Pakete sind im Sinne des Users ja eigentlich sogar der richtige Ansatz, da man es nur herunterladen und doppelklicken muß.

Das kann ich unterstützen: Man muss den Ansatz nicht mögen - ich verstehe, warum ihn viele ablehnen - aber immerhin ist es wirklich mal etwas anderes. Denn die technischen Unterschiede zwischen den verschiedenen *NIX Package-Management-Systemen erschließen sich doch nur dem versierten User - für den Laien machen sie alle exakt dasselbe. Hier geht PC-BSD wirklich einen eigenen und wie ich finde interessanten Weg.

[Elwood]

Die PBIs sollen auch schlanker werden ab 9 BETA1:

* Improved PBI system, allows sharing of files / libraries between applications for reduced disk / runtime space.

Hatte vor kurzem auch von einem Port?! gelesen, mit dem die Erstellung von PBIs deutlich vereinfacht werden sollen (wäre wirklich hilfreich)?? Quelle ist mir entfallen...

Die Blogmeldung zur Beta1 http://blog.pcbsd.org/2011/08/releas...bsd-9-0-beta1/ und Beta 1.5 http://blog.pcbsd.org/2011/08/pc-bsd...e-for-testing/ lassen einiges hoffen

Wird langsam OT

[laemodost]

Ich bin auch sehr gespannt auf das neue PBI-System.
Der initiale Download bleibt leider immer noch sehr groß, aber auf der Platte nehmen die installierten PBIs dann nicht so viel Platz weg, wenn zwei oder mehrere PBIs die gleichen Libraries benutzen, weil durch Hardlinks immer nur eine Version davon auf der Platte vorhanden ist.
Auch sollen Updates wesentlich kleiner ausfallen, weil mit bsdiff nur noch die Unterschiede zwischen altem und neuem Paket heruntergeladen werden. Das klingt alles sehr gut und freut mich als Besitzer einer heutzutage eher schmalen 6 MBit-Leitung.

[Crest]

Wenn sie wirklich Hardlinks verwenden steht hinter den Dateien auch der selbe inode. Damit sollte der Linker, wenn er die shared libs per mmap r/o in die Prozesse mapped auch keine mehrfachen Kopien mehr anlegen.

[Nukama]

PBI:9 verwendet den selben inode für identische Dateien.

# find /usr/pbi/ -inum 10810
/usr/pbi/libreoffice-amd64/lib/libxvidcore.so.4
/usr/pbi/vlc-amd64/lib/libxvidcore.so.4
/usr/pbi/.hashdir-user/lib/libxvidcore.so.4:::caffebdbf3ea279c3569549080d39887a31a3df6e87d9aa64d599e6ddae74545

[solarix]

Zitat von mark05

g
und zeigt mir nur ein loesung unter linux die im HA bereich so gut laeuft wie carp
samt verzahnung in das OS .

Wenn Du HA auf CARP reduzierst, dann frag ich Dich erst mal wo setzt du HA ein und welchem Umfang? Oder ist Deine Sicht auf HA etwas reduziert?

Den alten Heartbeat Kram gibts schon lange nicht mehr. Mittlerweile nennt sich das Kind
Corosync/Pacemaker. Nach wie vor haben es die Linuxbuben es nicht fertig bekommen eine Clustersoftware zu bauen die im Kernel läuft.

Corosync/Pacemaker Ist zwar vom Handling her auch Gammel, aber eine komplette Clusterlösung mit Agenten
für sämtliche Enterprise Software wie DB/2, SAP und genau daran mangelt es den BSD Systemen.
Glaub mir es wäre mir lieber wenn es anders wär. Dem ist aber nicht so.

Außerdem gibts noch den kostenpflichtigen Veritas Cluster für Linux. Also Lösungen gibt es mehr als genug.

Das es bessere als diese gibt, ist allerdings auch wahr, nur die hat es nicht im BSD Lager.

wenn ich mir das grauen iptables alleine anschaue ......... das muss man ja schon kryptograph sein wenn man von pf kommt.

Da geb ich Dir absolut Recht, das ist eine Krankheit ohne Ende, nix was man freiwillig haben will.

und wo passieren wirklich innovative dinge im kernel ?

Das interessiert am Ende des Tages keine Sau, weil Endkunden und vor allem Enterprise Kunden dafür zahlen das der Kram läuft und das möglichst schmerzfrei.

sind es nicht mittlerweile nur noch anpassung an neuste hardware , besser umgang mit smp
, verbesserungen virtualisierung und btrfs ?

Genau das ist es doch aber was der Kunde haben will und zu btrfs... das ist ein reines "Not invented here!" Produkt, das wieder unter den üblichen Gammel wie dem widerlichen LVM angeflanscht wird.
Dann lieber Geld ausgeben für VxFS

und alle 2 monate , oder , einen ellenlanger bericht was es den neus im kernel gibt wie auf C
lese ich schon lange nicht mehr ... das ist so als ob VW den Golf zum sibenhundertfuenfzehtenmal geface liftet hat und es doch kein besseres auto geworden ist.

holger

Muss ja auch keiner lesen, abgesehen davon, kommen da wo die Linuxbüchsen eingesetzt werden ja sowieso die netten Consultants von Rothut IBM und sonstigen mildtätigen Vereinen ins Haus, die dem Kunden in schicken Powerpoint Folien vorstellen was tolles geht.

Dem Kunden ist es meistens egal, was unter seiner Applikation läuft Hauptsach sie läuft, was anderes interessiert doch gar nicht.

Die einzigen die auf eine Entscheidung vielleicht noch Einfluss nehmen können sind festangestellten Systemklempner vor Ort. Aber meistens ist es eine politische Entscheidung und da kommt Linux meistens gut weg, das andere besser sind steht ausser Frage. Die Linuxindustrie hat aber eben eine sehr gute Lobby.

Wenn ich unsere Infrastruktur so ankucke und von Solaris Maschinen auf Linux Maschinen migrieren muss, komm ich mir teilweise vor, als würde ich in die Steinzeit zurück wandern.

Grade beim Thema HA, und Storedge kriegt man da mehr als nur graue Haare.

[Elwood]

http://www.pro-linux.de/news/1/18233...n-systemd.html

udev wird Bestandteil von Systemd

Die Geräteverwaltung des Linux-Kernels, udev, wird künftig gemeinsam mit Systemd entwickelt. Udev wird aber auch weiterhin ohne Systemd einsetzbar sein.
...

[Abakus]

Ich denke die werden udev bald einstellen mit dem kommentar, das kann eh systemd und wer will schon 2 Codebasen pflegen. Interessant finde ich auch dieses zitat

Der von Poettering befürchtete Flamewar blieb aus.

Wieso blieb der aus?

Grüße,
Abakus

[MuffiXXL]

Zitat von Abakus

Wieso blieb der aus?

Grüße,
Abakus

Der ist nichtmal für Argumente zugänglich. Da hilft also auch kein Flamen.
Letztlich ist es eh nicht zu ändern. Ich bin nur gespannt was in Zukunft passieren wird, ob ihm alle selig hinterherrennen werden, oder ob jemand eine Alternative zu ver-poetterten Projekten schaffen wird, denn auch unter den Linux Entwicklern wird das der eine oder andere sicher kritisch sehen was der da vorhat.

[Abakus]

Was ich mich frage ist, warum braucht das init Hotplugging für Geräte? Warum muss das init sowas können?

Als Grund für die Integration gibt Sievers die Funktionsweise der Geräteerkennung und des Init-Systems an. So sei es essentiell wichtig, dass ein modernes Init-System über eine Hotplug-Fähigkeit verfüge, so Sievers. Aus diesem Grund sei es für ihn und die anderen Entwickler auch verständlich, dass ein System wie udev sich nicht als eine »isolierte Logik« verstehen darf, sondern ein integraler Bestandteil des Init-Systems sein muss. Zudem reduziere die Integration den administrativen Aufwand und verhindere die Duplizierung von Quellcode, so Sievers weiter in seiner E-Mail.

Also ich lese da keinen wirklichen Grund raus. Kann mir das vielleicht einer erklären? Weil ich persönlich halte das für keine Gute Idee muss ich gestehen. Ich denke eine Trennung ist besser und entspricht auch mehr dem "Unix Way".

Grüße,
Abakus

[darktrym]

Für die Freunde der Aluhüte: Beide Typen sind bei Red Hat angestellt.

Jetzt fehlen nur noch Spiele für Systemd, ist ja fast alles bereits integriert.

[Yamagi]

Ich glaube, ich schrieb es schon einmal in diesem Thread oder in einem anderen: Was vielen nicht bewusst ist, ist die Macht, die Red Hat inzwischen in der Linuxwelt hat. Red Hat ist, um es mal überspitzt zu sagen, das Microsoft der Linuxwelt geworden. In praktisch jedem größeren Projekt stellen sie einen größeren Teil der Entwickler, oft gleich auch die aktivsten. Das von ihnen initiierte Gnome ist nur die Spitze des Eisbergs, es geht über Xorg und Wayland, diverse Infrastrukturpakete wie eben systemd bis zum Kernel hinab. Und so verwandelt sich Linux langsam aber stetig in eine Art "Red Hat OS", denn sie stellen die Coder, machen die Arbeit und geben damit verständlicherweise auch den Ton an. Und ich prohpezeie, was derzeit den Nicht-Linux-Nutzern des Opensource-Ökosystems passiert, wird eher früher als später auch einen Kahlschlag in Linux Distributionslandschaft verursachen. Entweder, die Unterschiede zwischen den Distributionen werden durch immer weniger Möglichkeiten Komponenten anders als andere zu kombinieren glattgeschliffen, oder einige steigen gleich ganz aus.
Nun denken wir einmal weiter. Red Hat ist eine kleine Klitsche, in der Rangliste der Softwaregiganten aggieren sie irgendwo im unteren Mittelfeld. Oracle denkt sich, dass sie ihr Linuxgeschäft ausbauen sollten und geben ein feindliches Übernahmeangebot ab. Nun werden die Fanboys sagen, dass Red Hat sich niemals an Oracle verkaufen wird, aber beim Geld hört die Freundschaft auf. Sie sind erfolgreich und stampfen die ganze Mitarbeit an diversen Projekten ein. Was dann? Schon heute wäre das ein Schlag, der das Opensource-Ökosystem nachhaltig aus der Bahn werfen könnte, denn damit wären viele bezahlte Entwickler erst einmal weg. Wie soll das erst werden, wenn sich das Zentrum immer mehr zu Red hat verschiebt? Ich denke, dass sich die Opensource-Welt derzeit zu sehr an ein einziges Unternehmen bindet, als es gesund sein kann. Und wenn wir eines gelernt haben ist es, dass sowas meist irgendwann schiefgeht und hinterher das Geheul groß ist.
So gesehen sollten wir froh sein, an der Seite zu stehen und zuschauen zu können. Denn wie MuffiXXL sagt, ändern kann man daran eh nichts.

[darktrym]

Sind dann die Nerds auf Red Hats Seite wenn sich der Wald lichtet?
Debian, Arch und Konsorten dürfte zu viel Kommerz und ein Einheitslinuxsystem gegen den Strich gegen.

[Abakus]

Eigentlich ist doch ein einheitliches Basissystem nichts schlechtes. Es vereinfacht die Anpassung, die Dokumentation ist leichter aktuelle zu halten. Distributoren haben einen einfacher Basis, und Stabile zweige lassen sich leichter pflegen, gerade Security Updates kommt das zugute. Im Prinzip das was wir bei FreeBSD aktuell haben.

Klar wenn das alles an einer Firma hängt wäre das schlecht, besser wäre eine Community gesteuertes Basissystem finde ich, das an keiner Firma hängt.

Grüße,
Abakus