Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] systemd in debian/experimental  (Read 7366 times)

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.844
[DE] systemd in debian/experimental
« on: 2010/11/19, 16:07:22 »
systemd hat einzug nach experimental gehalten, weil es  eine option für Squeeze+1 (Wheezy) ist. es gibt dazu ein debian-wiki
disclaimer: dies sollte wirklich nur auf 'wegwerfinstallationen' getestet werden.

greetz
devil

Offline reddark

  • User
  • Posts: 1.053
    • http://www.klangruinen.de/
systemd in debian/experimental
« Reply #1 on: 2010/11/19, 18:13:47 »

Offline ab

  • User
  • Posts: 117
systemd in debian/experimental
« Reply #2 on: 2010/12/15, 16:21:20 »
In der aktuellen LinuxUser (01.2011 ab Seite 90) findet sich sehr ausführlicher Beitrag anhand eines konzeptionellen Vergleiches von Systemd und Upstart.

Gruß ab

Offline Lanzi

  • User
  • Posts: 1.781
systemd in debian/experimental
« Reply #3 on: 2010/12/15, 23:58:03 »
was ist denn das Fazit des Artikels?


Offline ralul

  • User
  • Posts: 1.814
systemd in debian/experimental
« Reply #5 on: 2010/12/16, 13:11:27 »
@devil, danke für den Link!

Den Author finde ich aber in seinen Formulierungen etwas "biased", sein Fazit:

Quote
Upstart besitzt ein einfaches und klares Konzept,
Das systemd Konzept ist klar und einfach. Upstart nur auf den ersten Blick.

Quote
(upstart) bleibt dabei jedoch vollständig abwärtskompatibel.
Systemd ist für nicht-zentrale, zusätzliche Dienste abwärtskompatibel zu Sys-V.

Quote
Seine Fähigkeiten durfte es (upstart) bislang jedoch erst ansatzweise in Ubuntu unter Beweis stellen.
"durfte" ?  "konnte" !
Upstart ist eben viel zu komplex.

Quote
Konkurrent Systemd lockt Entwickler mit einem radikaleren Konzept, das noch schnellere Startzeiten verspricht,
Die zentralen Vorteile von systemd sind nicht Schnelligkeit, sondern:
- Sicherheit
- einfache Erweiterbarkeit (Boost für Systementwickler!)
- tuneable (zB statt Phoronix 200 Zeilen Patch)
- update long running server systems
 
Quote
(systemd) dafür aber unter der Haube komplexer ausfällt und spezielle Kernel-Funktionen verlangt.
Systemd braucht eben die neuen standard Kernel Funktionen, die systemds neue Möglichkeiten bringen!


Die openSUSE Wiki Seite bringt einen aktuellen Überblick über die Probleme mit Systemd und gute Links zu anderen systemd Seiten:
http://en.opensuse.org/openSUSE:Systemd_status

Verheinheitlichendes Potential von Systemd:
Quote
# Crypto handling. upstream systemd only supports a subset of SUSE's/Debian possible crypto options.
...
# chkconfig knows about xinetd and init scripts but not systemd services
...
# switch SUSE-specific config files to new cross-distro configs: /etc/os-release, /etc/locale,
Meine Kristall Kugel für einen Blick in die Zukunft sagt mir:

- Crypto, bis jetzt in jeder Distribution unterschiedlich, wird endlich eine "best state of the art" Methode finden.
- init und xinetd wird vereinheitlicht werden.
- LSB wird umfassender werden...

Viele Distributionen haben ihre Berechtigung vor allen Dingen wegen der bisher noch nicht gefundenen optimalen Methode des Systemstarts für Linux. Dies wird entfallen. Die Tendenz zu Core-Distributionen, auf die Systementwickler mit "Derived Distros" aufsetzen, wird sich verstärken!
experiencing siduction runs better than my gentoo makes me know I know nothing

DonKult

  • Guest
systemd in debian/experimental
« Reply #6 on: 2010/12/16, 15:10:44 »
Aber deine Meinung ist jetzt nicht "biased"?

Die Cryptovorhersage ist z.B. mehr als gewagt. Da steht das systemd nur einen Teil dessen untersützt was momentan Verwendung findet, d.h. irgend jemand wird im Regen stehengelassen, nicht das sich jetzt alle einen großen Schirm teilen… Kleine Schirm gibts also immer noch, vielleicht nicht mehr so viele, aber die Ultimative Lösung wenn denn überhaupt eine geben sollte ist nicht gefunden.

Ich bezweifle übrigens, dass "Viele Distributionen ihre Berechtigung vor allen Dingen wegen der bisher noch nicht gefundenen optimalen Methode des Systemstarts für Linux haben". Vielleicht bin ich einfach nur nicht hipp genug, aber der Systemstart ist so ziemlich das letzte was mich an Linux bzw. einer Distribution interessiert (Das allerletzte ist übrigens wie einfach die Installation ist - das mach ich einmal und gut ist, daher verstehe ich nicht, dass Reviews sich meist nur auf die Installation beziehen…).

Wen interessiert es den ob mein Rechner jetzt 10 oder 20 Sekunden zum booten braucht? Das ist doch kein Task bei dem Zeit verbrannt wird, da das ohne meine Mithilfe geschieht. Und selten genug tue ich das auch noch - vermehren wird sich die Anzahl der reboots jedenfalls nicht mehr, ich sag nur "Always On"…

Nene, Distributionen unterscheiden sich in Zukunft immernoch vor allem dadurch wieviel Zeit ich mit einen regelmäßigen Aufgaben "verschwende" - und das vollkommen unabhängig davon ob da jetzt sysv, insserv, systemd, upstart oder $whatever unter der Haube werkelt… Da gehts um Integration und Bedienbarkeit…

Offline ralul

  • User
  • Posts: 1.814
systemd in debian/experimental
« Reply #7 on: 2010/12/16, 22:46:02 »
Ich bin überhaupt nicht biased. Außer ich bin so stark biased, dass ich es nicht merke. Voreingenommenheit ist kaum per Introspektion zu beurteilen. Ich meinte nur ein Muster Pro upstart und Contra systemd beim Artikel erkennen zu können bei der angewandten Wortwahl.

Mit Systemstart ist im Zusammenhang meiner Argumentation nicht das Booten sondern das allgemeinere "Systemmanagment" gemeint.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
systemd in debian/experimental
« Reply #8 on: 2010/12/20, 20:51:59 »
Für Pro Audio User (RealTimePreemption) stellt sich systemd /cgroups gerade als neue Hürde da.
http://jackaudio.org/linux_group_sched
Bisher habe ich cgroups immer in der Kernelconfig abgeschaltet, um diese Probleme zu vermeiden, aber systemd braucht das ja wohl.
Es gibt zwar schon Lösungsansätze, aber einige probleme bleiben noch offen.
Da ich keine "Offiziellen" aptosid kernel nutze, wollt ich ma fragen, ist den Group scheduling (cgroups) standardmäßig im aptosid Kernel aktiviert ?

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.844
systemd in debian/experimental
« Reply #9 on: 2010/12/20, 21:22:14 »
bisher nicht, wäre ja recht nutzlos.

greetz
devil

Offline ralul

  • User
  • Posts: 1.814
systemd in debian/experimental
« Reply #10 on: 2010/12/20, 21:55:24 »
@brummer, benutzt du nicht einen selbst gebackenen RT Kernel, wo du es anstellen kannst?

Außerdem, Systemd wird in Debian wohl nicht Pflicht werden, sondern Option...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
systemd in debian/experimental
« Reply #11 on: 2010/12/21, 06:22:25 »
Quote from: "ralul"
@brummer, benutzt du nicht einen selbst gebackenen RT Kernel, wo du es anstellen kannst?


Ja, klar, sach ich ja, ich schalte es aus in der kernel config.

Nur, ich bin auch Entwickler, und stehe nun vor dem Problem, das meine Apps mit systemd /cgroups "noch nicht" funktionieren werden. Ich werde wohl größere Umbau Maßnahmen vornehmen müssen. Die bisherigen Mechanismen (pthread_attr_setschedpolicy) um realtime threads zu erstellen funktionieren eben mit cgroups nicht mehr. Noch schwieriger wird das einbinden von library’s die rt-threads erzeugen. Ich will nicht weinen, nur berichten, . .
Und setzt buntu nicht voll auf sytemd in der 11er reihe?

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.844
systemd in debian/experimental
« Reply #12 on: 2010/12/21, 06:33:51 »
nein, ubuntu setzt eher auf uptime. du meinst evtl. fedora.

greetz
devil

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
systemd in debian/experimental
« Reply #13 on: 2010/12/21, 07:34:45 »
ah, ja , mein Fehler  :oops: