systemd

[malzeit]

Moin,

ich weiß, dass das Thema "systemd" schon Millionen Male durchgekaut wurde, habe mich da jetzt auch ein wenig in die beiden Fraktionen reingelesen.
Dabei ist mir aufgefallen, dass es (unter vielen) ein interessantes Argument gibt:
"systemd beschleunigt wegen Parallelisierung den Systemstart"

Dieses wird als Argument der Gegner genommen, da dieses ja absolut nicht nötig sei bei Servern.
Jetzt mein Gegenargument:
sollte ein Server nach einem gewolltem Neustart / ungewolltem Absturz nicht wieder so schnell wie möglich hochfahren??

Mir ist schon klar dass Stabilität immer zu bevorzugen ist gegenüber Geschindigkeit, aber ich denke/glaube/meine (als Laie mit einem Homeserver (owncloud, samba & squid) und zwei Debian-Firmenservern (squid & samba)) dass systemd bisher ganz gut funktioniert bei mir (wie gesagt, 3 einfache Server).

Gruß

[Meillo]

dass das Thema "systemd" schon Millionen Male durchgekaut wurde

Ja.

sollte ein Server nach einem gewolltem Neustart / ungewolltem Absturz nicht wieder so schnell wie möglich hochfahren??

Ja.

Mir ist schon klar dass Stabilität immer zu bevorzugen ist gegenüber Geschindigkeit

Ja.

ich denke/glaube/meine [...] dass systemd bisher ganz gut funktioniert bei mir

Freut mich.

... ich frage mich nur, was dieser Thread Neues beitragen soll, wo dieses Thema inzwischen einerseits schon total ausgelutscht ist und es andererseits immer wieder neu polarisiert, ohne dass man dadurch weiter kaeme.

[catdog2]

... ich frage mich nur, was dieser Thread Neues beitragen soll, wo dieses Thema inzwischen einerseits schon total ausgelutscht ist und es andererseits immer wieder neu polarisiert, ohne dass man dadurch weiter kaeme.

Nichts

[debianoli]

Hat hier einer systemd gesagt? steinigt sie... ihn ihn ihn

https://www.youtube.com/watch?v=MIaORknS1Dk

[Lord_Carlos]

Schneller start ist ja nur ein Beifallprodukt.
Wenn du wissen willst was wirklich sYsTeMd ausmacht kannst du dich mal hier rein hoeren: http://cre.fm/cre209-das-linux-system

[Mäuseturm]

Ja, auch ein Server sollte unbedingt schnellstmöglich komplett wieder zur Verfügung stehen. Unbedingt.

Ein Argument pro systemd kann ich daraus aber nicht ableiten. Mein Server läuft mit Jessie und vollständig entsorgtem systemd, also ganz klassisch mit sysv-init. Verbaut sind ein Stromspar-i7 (Haswell Refresh), eine SSD für das System und diverse Festplatten. Nachdem das BIOS nach einer gefühlten Ewigkeit endlich durchlaufen wurde - wo ja auch ein systemd-System erstmal durch muss - dauert es keine 5 Sekunden, bis alles komplett ganz und vollständig wieder zur Verfügung steht: apache, mysql, dhcp, ntp, samba, nfs, exim, dovecot, squid3.

Nach insgesamt nicht mal 10 Sekunden hat die Kiste dann auch die Systemzeit erstmals aus dem Netz aktualisiert, fetchmail schon nach neuen Mails geschaut, smartd alle Festplatten durchgecheckt, der DHCP meinem Android-Smartphone seine Lease bestätigt und ddclient die aktuelle öffentliche IP an den DDNS-Server berichtet.

Also: mir persönlich ist es wirklich egal, ob mein Server 5 Sekunden zum Start benötigt oder vielleicht 3 oder 4. So viel Zeit habe ich selbst im größten Stress gerade noch

Auch wenn ich die Idee hinter systemd und das Konzept und die vielen guten Ideen sehr gut versteht und super finde, habe ich mit systemd immer wieder Probleme, egal wo es auf irgendeiner Maschine auftaucht. Bis es endlich ausgereift ist und vielleicht vernünftig dokumentiert ist, halte ich mich zumindest bei Servern beharrlich an sysv-init fest.

[Radfahrer]

Wenn du wissen willst was wirklich sYsTeMd ausmacht kannst du dich mal hier rein hoeren: http://cre.fm/cre209-das-linux-system

Bist du irre?
Wenn die Leute sich das anhören, begreifen sie womöglich noch, worum es geht. Das macht doch die ganzen Stammtischargumente kaputt.

Und jetzt.......

Popkorn für alle!!!

[Mäuseturm]

Bist du irre?
Wenn die Leute sich das anhören, begreifen sie womöglich noch, worum es geht. Das macht doch die ganzen Stammtischargumente kaputt.

Das stimmt. Dieses Interview ist echt Mist... ich habe immer gedacht, dieser Poettering wäre so ein arroganter US-Schnösel von RedHat, der dumm in seinem Kämmerlein irgendeinen undurchdachten Murks zusammen hackt. Und dann ist das ein netter Hamburger in Berlin, der sich echt richtig einen Kopf macht und echt gescheite Ideen hat.

Ich hasse es, wenn man mir meine Weltanschauung zerstört. Ein Feindbild weniger. Jetzt muss ich wieder eine Bild-Zeitung kaufen gehen *aaaaaahhhhh*

[malzeit]

*Erleuchtung*

- DOS ... mehr braucht's nich'
- das haben wir noch nie so gemacht, das haben wir schon immer so gemacht, da könnte ja jeder kommen

Ich wollte nur bestätigt haben, dass es ein Grabenk(r)ampf ist ... schade dass es keine 2 Projekte nebeneinander geben darf

...
Wenn du wissen willst was wirklich sYsTeMd ausmacht kannst du dich mal hier rein hoeren: http://cre.fm/cre209-das-linux-system

Werde ich mir mal reinziehen heute Nachmittag; wenn der Chef nicht mehr da ist

Gruß + Danke für halbwegs sachdienliche HInweise

[Lord_Carlos]

...
Wenn du wissen willst was wirklich sYsTeMd ausmacht kannst du dich mal hier rein hoeren: http://cre.fm/cre209-das-linux-system

Werde ich mir mal reinziehen heute Nachmittag; wenn der Chef nicht mehr da ist

Gruß + Danke für halbwegs sachdienliche HInweise

Hat sogar sein eigenen Thread hier im Forum. viewtopic.php?f=1&t=158182
Ist eine wirklich gute Folge.

[Radfahrer]

Jepp, ist es!

+1

[Meillo]

... schade dass es keine 2 Projekte nebeneinander geben darf

Das ist ein wichtiger Aspekt fuer mich in dieser Diskussion: Wie kommt man die unterschiedlichen Beduerfnisse und Wuensche unter einen Hut, ohne dass man Aeste absaegt oder dass verfeindete Lager entstehen? In dieser Hinsicht ist vieles unnoetig schlecht gelaufen in dieser Diskussion, bislang. Es wird besser, habe ich den Eindruck. Die Emotionen flauen ab und machen Raum fuer Sachlichkeit, Verstaendnis und so letztlich fuer Moeglichkeiten der Koexistenz.

[malzeit]

Wie kommt man die unterschiedlichen Beduerfnisse und Wuensche unter einen Hut, ohne dass man Aeste absaegt oder dass verfeindete Lager entstehen?

Wieso muss denn "alles unter einen Hut". Für meinen Teil denke ich immer, dass man Dinge ruhig mal anders angehen kann, Stoppuhr nehmen, Effizienzmesser ausklappen und vergleichen; mal die Betriebsblindheit ablegen; einfach mal sagen "jo, der beidseitig linkshändische 10Daumennutzer macht's tatasächlich besser, wir sollten was ändern".

In dieser Hinsicht ist vieles unnoetig schlecht gelaufen in dieser Diskussion, bislang. Es wird besser, habe ich den Eindruck. Die Emotionen flauen ab und machen Raum fuer Sachlichkeit, Verstaendnis und so letztlich fuer Moeglichkeiten der Koexistenz.

Dieses habe ich, als einfacher Benutzer, schon des öfteren mitbekommen wenn es um 2 Lösungen für ein Problem geht; scheint irgendwie ein typisches open-source Problem zu sein.

Habe mir grade mal (etwas alt) http://www.heise.de/open/artikel/Das-In ... kelseite=1 durchgelesen und hoffe, dass ich heute noch das Interview hören kann.

...
Bis es endlich ausgereift ist und vielleicht vernünftig dokumentiert ist, halte ich mich zumindest bei Servern beharrlich an sysv-init fest.

Dazu mal eine Frage, reine Neugierde (vielleicht offtopic): "...waiting for LSB Module to be activated... (max 1m 30s)
Ist das ein SysVinit- oder ein SystemD-Problem? Bin ja gerne bereit zu sagen dass SystemD noch was verbessern kann
(Taucht bei mir jedesmal auf, wenn ich eine static-ip in /etc/interfaces hinterleg wenn ich hochfahre; und als "waiting for deactivating" bei meinem Laptop bei jedem zweiten shutdown)

Gruß

[Mäuseturm]

Dazu mal eine Frage, reine Neugierde (vielleicht offtopic): "...waiting for LSB Module to be activated... (max 1m 30s)
Ist das ein SysVinit- oder ein SystemD-Problem? Bin ja gerne bereit zu sagen dass SystemD noch was verbessern kann
(Taucht bei mir jedesmal auf, wenn ich eine static-ip in /etc/interfaces hinterleg wenn ich hochfahre; und als "waiting for deactivating" bei meinem Laptop bei jedem zweiten shutdown)

Etwas mit LSB Module hatte ich bisher noch nie, aber diesen Mist mit dem 1m 30s warten kenne ich nur zu gut. Kommt eindeutig von systemd und das habe ich nicht nur bei Debian, sondern auch bei Arch, wo schon viel länger und konsequenter auf systemd gesetzt wird.

Diese Warterei kommt gerne und oft, wenn beim Hochfahren eine Platte oder ein Netzwerkmount fehlt, gerne auch immer, wenn ein NFS- oder Samba-Mount vorhanden ist und man dann beispielsweise das per WLAN angebundene Notebook runter fahren will - was ich mir nur so erklären kann, dass der Networkmanager beim Beenden der Mausschubseroberfläche schon das WLAN weggekickt hat und systemd dann schlicht zu blöd ist, die noch existierenden mounts einfach ebenfalls weg zu werfen. Oder so ähnlich.

Wie gesagt: diese 1m 30s Warterei kenne ich nur zu gut und zwar von jeder einzelnen Maschine, die ich in den letzten Monaten eingerichtet hatte und auf der systemd lief. Aus völlig verschiedenen Gründen, wann immer irgendwas beim Hoch- oder Runterfahren nicht ganz erwartungsgemäß lief. Und gerne auch mehrfaches 1m30s-Warten hintereinander.

Das ist einer der Gründe, warum ich systemd so überhaupt nicht leiden kann...

[malzeit]

Das ist einer der Gründe, warum ich systemd so überhaupt nicht leiden kann...

In dem Punkt stimme ich dir dann zu

...jetzt fällt mir nur noch ein Spruch meines alten Chefs wieder ein: "nicht nur möppeln sondern das Problem lösen"

..wobei ich glaube ich grade wegen dir meine Fehlerlösung gefunden habe, Reply 20:
http://forum.siduction.org/index.php?topic=4503.15
Das werde ich nachher mal probieren.

Gruß

[ingo2]

Also, ich hatte nach dem Upgrade auf Jessie das gleiche Problem (90s timeout von systemd). Schuldiger: "das Netzwerk".
Bei mir hat es geholfen, avahi komplett zu deinstallieren. Der Daemon findet offenbar immer mal wieder irgendwelche Resourcen im Heimnetz. Ich brauche das Ding nicht, weiß selbst, auf welche Freigaben/Exports ich zugreifen will.

Gruß Ingo

[scientific]

Wie gesagt: diese 1m 30s Warterei kenne ich nur zu gut und zwar von jeder einzelnen Maschine, die ich in den letzten Monaten eingerichtet hatte und auf der systemd lief. Aus völlig verschiedenen Gründen, wann immer irgendwas beim Hoch- oder Runterfahren nicht ganz erwartungsgemäß lief. Und gerne auch mehrfaches 1m30s-Warten hintereinander.

Das ist einer der Gründe, warum ich systemd so überhaupt nicht leiden kann...

Ich hab einen Laptop mit einer Hybrid-Platte. Den Grund, warum der Zugriff manchmal sagenhaft schnell ist, und dann wieder so wie von einer HDD, hab ich noch nicht rausgefunden. Irgend ein Prozess schiebt offenbar immer wieder andere Daten in die SSD-Abteilung der Hybrid-Platte... Aber grundsätzlich ist das nicht das Thema hier.

Der Bootprozess dauert hier so um die 15-35 Sekunden. Ich konnte die Bootzeit drastisch reduzieren, indem ich einige klassiche SysV-Init-Skripte durch systemd-Units ersetzt habe. Bei ein paar Diensten hab ich die Socket-Activation aktiviert usw. Debian ist halt als stabile Distribution für Admins mit eigenem Hirn. Das ist nicht so endandwenderfreundlich hingetrimmt, wie ein Ubuntu oder Mint. Deshalb verwende ich Debian auch, weil ich hier noch Aufgaben habe, wo ich mir selber den Kopf darüber zerbrechen kann. Und dann kann ich die Freude genießen, wenn es funktioniert. Obwohl es out of the box auch funktionieren würde.... nur halt nicht so, wie ich es gerne hätte.

Das ganze Geseiere über systemd versteh ich bis heute nicht. Ich hab mich jetzt mal eingearbeitet (und noch lange nicht alle Funktionen durchschaut...) und bin hellauf begeistert, wie "nett" man mit systemd Aufgaben lösen kann. Was z.B. den Ersatz für cron anbelangt... Ja, man braucht zwei Units. eine Timer-Unit und einer Service-Unit. Und wenns ganz blöd her geht (weil z.B. die Dienste so geschrieben sind, dass man nicht einfach ein Konfigurationsfile in die Systemd-Unit einlesen kann) dann ist auch noch ein Wrapper notwendig... Klar ist da ein Einzeiler in der Crontab "schneller" geschrieben. Aber zum Debuggen ist der systemd-timer-Prozess wesentlich eleganter.

Und mir ist auch klar, dass systemd noch stark in Entwicklung ist. Und wenn ich den systemd aus Jessie mit dem aus Testing vergleiche, dann hat sich da in der Zwischenzeit schon wieder einiges getan (Z.B. kann ich beim aktuellen eine Timer-Unit xyz@.timer nennen und systemd instanziert diese dann. Das geht bei systemd aus Jessie noch nicht.)

Was das Audiofile mit Pöttering anbelangt... Ich hatte noch nicht die Zeit, es bis zum Ende anzuhören. Aber ich kann nur eines sage: Genauso hab ich mir diesen Typen vorgestellt. Das trifft sich mit genau dem, was ich über systemd gelesen habe, während andere (auch hierzuforums) sich in Maulzerreißen zergangen sind, dass systemd doch die Welt in zwei Stücke reißen würde, weil Pöttering ein arroganter A* wäre... Weit gefehlt.

Just my 2 cent

lg scientific

[ViNic]

Schneller start ist ja nur ein Beifallprodukt.
Wenn du wissen willst was wirklich sYsTeMd ausmacht kannst du dich mal hier rein hoeren: http://cre.fm/cre209-das-linux-system

Vielen Dank für den Link

[Lord_Carlos]

Ich glaube viele debian Benutzter haben durch das upgrade auf eine neue debian version probleme mit systemd bekommen. Wenn sowas nicht sauber funktioniert wundert es mich nicht das man abgeschraekt wird.

[scientific]

Die Upgrades waren doch immer schon mehr oder weniger problembehaftet. Das liegt in der Natur der Sache, wenn man ein laufendes Systemd angreift und verändert.

Ich glaube viele debian Benutzter haben durch das upgrade auf eine neue debian version probleme mit systemd bekommen. Wenn sowas nicht sauber funktioniert wundert es mich nicht das man abgeschraekt wird.

Ich hab in meiner mittlerweile 10 jährigen Linux-Karriere (8 davon mit Debian) auch schon einige Troubles gehabt. Wenn man ein neues Werkzeugset hat, dann weiß man erstmal nicht, wie man damit umgehen muss. Ich erinnere mich an die Zeit, als so nach und nach die Notwendigkeit einer xorg.conf verschwunden ist.. Vorher gab es wirklich VIELE Probleme mit den Monitoren und der Anzeige (auch ich bin in solche Probleme gerannt), als noch zwingend eine xorg.conf erforderlich war.
So hatte ich noch ganz zu beginn - ich hatte von Linux Nüsse Ahnung - noch Anleitungen gefunden, wie ich mir ModeSet-Zeilen (glaub so hießen die) selber für meinen Monitor basteln müsste... Und nichts funktionierte so, wie gewollt... Dann kam irgendwann udev daher und irgendwie verschwand dann die Notwendigkeit von ModeSet-Zeilen und überhaupt für die xorg.conf... Und was da von manchen geschimpft und gemeckert wurde, dass sie die Kontrolle über das System verlieren würden... Aber der ganze Krempel hat sich - zurecht - durchgesetzt, weil die Bedienung eines Rechners mit Linux wesentlich vereinfacht wurde.

Jetzt las man schon so viel Geschwurbel, wie schrecklich systemd wäre, weil Pöttering so ein Arsch sei... bevor noch systemd in Debian Einzug hielt. Und dann kam systemd. Die User kannten es nicht, die bewährten Problemlösungsstrategien funktionierten auf einmal nicht mehr, und sie fühlten sich bestätigt, dass systemd wirklich ein Mist sei, weil das Klumpert geht nicht und Pöttering ist schuld.

Ich möchte eigentlich nicht wissen, wieviele Probleme bei System-Upgrades es vorher gab, die gar nie in Foren aufgetaucht sind, weil die Leute ungefähr wussten, was zu tun ist.
Und ich bin mir ganz sicher, dass beim nächsten Upgrade von Jessie auf Stretch wieder genausoviele Probleme auftauchen werden, aber in den Foren schlägt weniger auf, weil in der Zwischenzeit die Leute mit systemd umgehen können... Angenommen, es hätte eine Präjudikatur zu systemd gegeben, welche da lautete: "das ist ja uuuuursuper", dann wären die selben Probleme ganz anders kommentiert worden...

Für mich ist es eindeutig rein ein Wahrnehmungsproblem, dass systemd Mist wäre... Wenn man nur auf das hört, was "man so hört", dann liegt man halt echt oft daneben... Die Realität hat in den wenigsten Fällen wirklich etwas damit zu tun, was wahrgenommen wird.

lg scientific

[rendegast]

Und nichts funktionierte so, wie gewollt... Dann kam irgendwann udev daher und irgendwie verschwand dann die Notwendigkeit von ModeSet-Zeilen und überhaupt für die xorg.conf... Und was da von manchen geschimpft und gemeckert wurde, dass sie die Kontrolle über das System verlieren würden... Aber der ganze Krempel hat sich - zurecht - durchgesetzt, weil die Bedienung eines Rechners mit Linux wesentlich vereinfacht wurde.

Das Problem verschwand wohl eher, weil die Monitore endlich anfingen
ihre Modes mitzuteilen (EDID / DDC), und das auch immer mehr korrekt.

Hier habe ich einen Samsung 997DF, der seine 1400x1050 nicht ausgibt.
(Wobei das Ding bei mehr als 1280 nicht zu gebrauchen ist)

[scientific]

Und nichts funktionierte so, wie gewollt... Dann kam irgendwann udev daher und irgendwie verschwand dann die Notwendigkeit von ModeSet-Zeilen und überhaupt für die xorg.conf... Und was da von manchen geschimpft und gemeckert wurde, dass sie die Kontrolle über das System verlieren würden... Aber der ganze Krempel hat sich - zurecht - durchgesetzt, weil die Bedienung eines Rechners mit Linux wesentlich vereinfacht wurde.

Das Problem verschwand wohl eher, weil die Monitore endlich anfingen
ihre Modes mitzuteilen (EDID), und das auch immer mehr korrekt.

Hier habe ich einen Samsung 997DF, der seine 1400x1050 nicht ausgibt.
(Wobei das Ding bei mehr als 1280 nicht zu gebrauchen ist)

Der ganze X-Server wurde umgebaut, dass die Infrastruktur besser und automatisch erkannt werden konnte... Schloss man einen Beamer an, musste vor RandR und udev den X-Server neu starten... Auch war die Erkennung von Maus und Tastatur bei laufendem X zu meinen Beginnzeiten mit Linux nicht immer ganz zuverlässig...

[Meillo]

Wie kommt man die unterschiedlichen Beduerfnisse und Wuensche unter einen Hut, ohne dass man Aeste absaegt oder dass verfeindete Lager entstehen?

Wieso muss denn "alles unter einen Hut". Für meinen Teil denke ich immer, dass man Dinge ruhig mal anders angehen kann, Stoppuhr nehmen, Effizienzmesser ausklappen und vergleichen; mal die Betriebsblindheit ablegen; einfach mal sagen "jo, der beidseitig linkshändische 10Daumennutzer macht's tatasächlich besser, wir sollten was ändern".

Wenn die Stoppuhr das von allen anerkannte wichtigste Kriterium waere, dann koennte man den von dir skizzierten Weg gehen. Mir aber ist die Stoppuhr aeusserst egal. Ich interessiere mich in erster Linie fuer die Komplexitaet (d.h. die Einfachheit) des Gesamtsystems. Wie schoen, dass ich z.B. auch nach dem Aufkommen von GRUB2 (der vermutlich der maechtigste und deshalb in der Meinung vieler wohl der beste Bootloader ist) LILO weiter nutzen konnte -- GNU/Linux, das Baukastensystem: Jeder kann es sich anders zusammenbauen. Wie schoen, waere es, wenn die Auswahl des Init-Systems, wie ich sie jahrelang zwischen sysv-rc und file-rc hatte und auch genutzt habe, jetzt um eine weitere Option ergaenzt werden wuerde ... Nur ist Systemd halt kein einzelner Baustein sondern eine konzeptionelle Restrukturierung. Dem will ich nicht im Wege stehen, denn sowas oeffnet Wege in die Zukunft (wenngleich man sich nie einig werden wird, welcher Weg der beste ist). Ich selber will damit nur nichts zu tun haben, denn ich interessiere mich fuer's alte Unix (und habe mich schon an der Perfektionierung von Debians Paketmanagement gestoert). Auf meinem Hauptrechner ist folglich schon laenger kein Debian mehr. Nun werde ich mir eben noch staerker (technisch) Gleichgesinnte suchen. Dass ich mich in Debian im Bezug auf die technische Sicht zunehmend weniger zuhause fuehle, ist mir schon vor Jahren klar geworden, darum laesst mich die Systemd-Diskussion weitgehend kalt. Ich fand nur schade, wie unnoetig konfrontativ sie gelaufen ist. Schoen zu sehen, welch positive Wirkung der CRE-Podcast hier hat.

(Unveraendert stark ist meine Verbundenheit mit Debian als Community-Projekt.)

[malzeit]

... mir hat es geholfen, avahi komplett zu deinstallieren. Der Daemon findet offenbar immer mal wieder irgendwelche Resourcen im Heimnetz. Ich brauche das Ding nicht, weiß selbst, auf welche Freigaben/Exports ich zugreifen will.

MERCI BEAUCOUP... das hat das mit dem "will ewig nicht runterfahren" gelöst. Drück ich jetzt auf meinen Aus-Knopf, fährt mein Rechner in 3sec runter

Ich glaube viele debian Benutzter haben durch das upgrade auf eine neue debian version probleme mit systemd bekommen. Wenn sowas nicht sauber funktioniert wundert es mich nicht das man abgeschraekt wird.

Ich hatte dieses Problem auch. Auf einem Wheezy war mein selbstkompiliertes Zoneminder drauf. Nach dem Upgrade auf Jessie funktionierte es nicht mehr, weder über /etc/init.d/zoneminder start noch über service zoneminder start.
Hatte mich da so sehr verrannt, dass ich nach (gefühlten)Monaten der Fehlersuche einfach n frisches Debian aufgespielt habe und nach 30min war wieder alles gut.

Aber auf wen schiebe ich jetzt den Fehler?
- Network Layer 8
- Upgrade-Scripte-Schreiberling von Debian (scho klar, selber kompiliert und installiert, kein Paket aus dem Repository)
- systemd
- zoneminder Programmierer?

Mir hat der Umschwung von Wheezy zu Jessie mit systemd auf meinem alten Server (Futro S400 mit 32GiB CF Card) den Bootvorgang erheblich beschleunigt, von ca. 50 Sekunden auf ca. 35 Sekunden, da wusste ich noch gar nix von systemd und erfreute mich dass Jessie so schnell ist.

Was ich sagen möchte:
es geht immer besser, einfacher, schneller und nur weil etwas gut funktioniert, muss man nicht die Evolution aufgeben, sollte aber beachten dass es hierbei zu Fehlern kommen kann

Wenn die Stoppuhr das von allen anerkannte wichtigste Kriterium waere, dann koennte man den von dir skizzierten Weg gehen. Mir aber ist die Stoppuhr aeusserst egal....

Ohne Böswilligkeit, mit 'nem Augenzwinkern, ist ja hier smalltalk: Zeit = Geld = Arbeitskraft; Arbeitskraft ist eine endliche Ressource die meist mit dem Tode endet
Wenn ich mir jeden Tag bei 4 Bootvorgängen jeweils 2 Sekunden .... kann ich mir noch 30min beim Tod erschleichen, zum Kiosk fahren, Tabak kaufen und doch wieder mit dem Rauchen anfangen, was ich ohne Beschleunigung des Bootvorganges dank einiger Menschen, die doch noch Verbesserungspotential sahen, nicht hätte machen werden können

Und jetzt: angenehmen Feierabend und soll jeder sich an seinem Lieblingsbootversorger erfreuen

[Meillo]

Zeit = Geld = Arbeitskraft; Arbeitskraft ist eine endliche Ressource die meist mit dem Tode endet
Wenn ich mir jeden Tag bei 4 Bootvorgängen jeweils 2 Sekunden .... kann ich mir noch 30min beim Tod erschleichen, [...]

Ebenfalls mit einem Augenzwinkern: Schonmal Momo gelesen?