Login
Newsletter
Werbung

Thema: Linux: Start in zwei Sekunden

24 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von DotzlerMotzilla am Mo, 16. September 2019 um 09:53 #

braucht dann KDE eine Ewigkeit, um einsatzbereit zu sein.
Spaß beiseite: 300 ms für den Kernel – Respekt!

[
| Versenden | Drucken ]
0
Von André Ramnitz am Mo, 16. September 2019 um 11:27 #

Kennt sich damit jemand aus? Muss da spezieller Hardwaresupport vorhanden sein, oder läuft das komplett softwareseitig ab?
Den Folien nach zu urteilen reicht ja anscheinend ein simpler bootparameter und ein userspace service, der von init gesteuert wird.

[
| Versenden | Drucken ]
0
Von Arran am Mo, 16. September 2019 um 11:40 #

Allerdings kann man mich erst dann aus dem Schlaf wecken wenn der Start bereits gemacht ist bevor ich aufgewacht bin.

Im Ernst, was nützen solche Spielereien? Linux hat grössere Challenges als solche Spielereien.

[
| Versenden | Drucken ]
  • 1
    Von eMme am Mo, 16. September 2019 um 11:48 #

    Für Wartungen an VMs ist entscheidend, wie lang ein Service ausfällt. Schnelle Bootzeiten sind da schon von Vorteil.

    [
    | Versenden | Drucken ]
    0
    Von asfdsadf am Mo, 16. September 2019 um 15:59 #

    Das ist sehr wichtig bei Embedded. Da muss z.B. ein Steuergerät sich sehr schnell am CAN Bus anmelden und Daten zurück liefern. Linux wird immer mehr für solche Dinge verwendet.

    [
    | Versenden | Drucken ]
    • 1
      Von der-don am Mo, 16. September 2019 um 16:28 #

      Nein, die Zeiten sind schon längst wieder vorbei. Linux ist so Fett geworden (auch schlank kompiliert), dass es immer übers Ziel hinausschiesst genau für diese Dinge. Auch ist der Stack einfach zu veraltet (Stichwort: Aktualisierbarkeit im laufenden Betrieb, kommt mir nicht mit den 2-3 Hampelmannartigen versuchen der Distributoren), da gibt es mittlerweile schlankere und modernere Alternativen.

      Ich weiss, das will wieder keiner hören, aber Linux ist auf keiner Basis sonderlich modern. In ein modernes (skalierbares) Serverumfeld wird es reingezwängt (Containerisierung bspw. ist alles nur gefummel an den Kernel angeflanscht), mobile verliert es an Bedeutung (Google sucht selbst modernere Alternativen) und Embedded ist es ein fetter Dino geworden. Bleiben noch Full-Stack-Server, die aber im professionellen Bereich auch eher mit BSD betrieben werden ....

      Die Zukunft liegt in einem UNIX, aber ganz sicher nicht mehr dem Bastelpinguin. Ich habe ihn 20 Jahre gehabt (Desktop wie Server) und weiss, das wird nichts mehr.

      [
      | Versenden | Drucken ]
      • 0
        Von eMme am Mo, 16. September 2019 um 19:17 #

        Ich lerne ja gern dazu. Was sind denn die besseren Alternative konkret? Ich würde mir das gerne ansehen.

        [
        | Versenden | Drucken ]
        • 0
          Von blablabla233 am Di, 17. September 2019 um 19:02 #

          Nicht um dem vorrendner recht geben zu wollen, aber iot ist wirklich mehr eine sparte von riot, freertos oder qnx/vxwork, linux ist meist nur eine uebergangsloesung.

          [
          | Versenden | Drucken ]
        1
        Von Verfluchtnochmal_5987108 am Mo, 16. September 2019 um 19:37 #

        Dämliches Geschwätz!

        [
        | Versenden | Drucken ]
        0
        Von klopskind am Di, 17. September 2019 um 09:35 #

        Mag alles stimmen. Bis dahin heißt es "abwarten und Tee trinken".

        zu:

        Die Zukunft liegt in einem UNIX, aber ganz sicher nicht mehr dem Bastelpinguin. Ich habe ihn 20 Jahre gehabt (Desktop wie Server) und weiss, das wird nichts mehr.
        a) Welches UNIX™-zertifizierte System setzen Sie folglich ein?

        b) Liegt die Betonung hier auf "einem UNIX" im Sinne von einem, "sie zu knechten, sie alle zu finden,
        Ins Dunkel zu treiben und ewig zu binden"?
        Falls ja: Welches aktuell gepflegte UNIX™-zertifizierte System ist speziell mit der Absicht entwickelt worden, sowohl für Server als auch den Desktop geeignet zu sein bzw. dafür vermarktet zu werden?
        IRIX wird nicht mehr gepflegt, HP-UX ist quasi nur für Server gedacht, die BSDs auch nur für Server, Mainframes oder Embedded, und macOS ist rein für "personal computing" (spätestens seit es nicht mehr Mac OS X heißt). Bleiben eigentlich nur Solaris und AIX, oder? Sind illumos (und Derivate wie OpenIndiana) UNIX™-zertifiziert?

        [
        | Versenden | Drucken ]
        0
        Von Oiler der Borg am Di, 17. September 2019 um 14:03 #

        Crappy MacOS kannst Du ja wohl kaum meinen!

        [
        | Versenden | Drucken ]
    0
    Von Verfluchtnochmal_5987108 am Mo, 16. September 2019 um 19:35 #

    Jedem der Server betreibt und Downtimes minimieren will nützt das und nein clustering und failover ist nicht für jeden workload die Antwort

    common sense?

    [
    | Versenden | Drucken ]
0
Von A. Nonymous am Di, 17. September 2019 um 07:57 #

Bei mir bootet Linux jetzt schon schneller als das BIOS zum initialisieren braucht.
Solange das BIOS 30 Sekunden braucht, kommt es sif ein paar Sekunden beim Kernel auch nicht an.

[
| Versenden | Drucken ]
0
Von unix111 am Di, 17. September 2019 um 10:44 #

Mein openSUSE Leap 15.0 starte ich momentan in etwa 1.3s laut systemd-analyze. Unter gleichem Nutzernamen wie hier habe ich im openSUSE-Forum öfters mal aufgelistet, was ich dafür getan habe: in der Hauptsache eine schnelle SSD mit einer großen, korrekt ausgerichteten ext4-Partition verwendet, Unnötiges aus dem Bootprozess entfernt, kdm ohne Themes verwenet, und so weiter.

(Details siehe Thread »537299-Extremely-slow-boot-for-new-tumbleweed-gnome-installation« im openSUSE-Forum).

Mein bestes Ergebnis war ein Warmstart (Reboot) in 1.211 Sekunden. Heute früh wars nicht so schnell, der Kaltstart dauerte 1.339s.

[
| Versenden | Drucken ]
  • 0
    Von blablabla233 am Di, 17. September 2019 um 19:11 #

    Wie richtest Du ein partition auf einer ssd richtig aus?

    [
    | Versenden | Drucken ]
    • 0
      Von unix111 am Mi, 18. September 2019 um 15:04 #

      Mit einem Partitionseditor wie GParted etc. solltest Du für den Startblock der Partition eine Blocknummer wählen, die durch 2048 teilbar ist.

      SSDs brauchen ja auch immer ein bisschen Platz für Wear-Leveling und andere interne Wartungsaktivitäten, da kann man ruhig etwas »Luft« zwischen den Partitionen lassen. Alternativ kann man auch eine Swap-Partition dazupacken, die selten oder nur zu einem kleinen Teil von Linux genutzt wird.

      Noch ein Trick: ich dachte anfangs, dass der »noop«-Scheduler ideal für SSDs ist — nein, »deadline« scheint noch ein paar Kniffe anzuwenden, damit SSDs schneller arbeiten können. Ein anderer Parameter wäre dann noch »swappiness«, aber ich denke, das hilft nur dann, wenn oft das RAM knapp wird.

      [
      | Versenden | Drucken ]
    0
    Von 1ras am Fr, 20. September 2019 um 20:35 #

    Haha, alleine die SSD-Verschlüsselung braucht hier schon 6 Sekunden, während dieser Zeit hast du schon 4x dein System gebootet ;-)

    [
    | Versenden | Drucken ]
    • 0
      Von unix111 am Sa, 21. September 2019 um 09:30 #

      Ja, Verschlüsselung mache ich nur bei ein paar wenigen Dateien. Für SSD-Verschlüsselung sind mir meine CPU-Zyklen zu kostbar. Das könnte sich aber ändern, sobald die Verschlüsselung in Hardware und »nahe« an oder in den SSDs stattfindet.

      Mein Boot von heute morgen laut »systemd-analyze blame«:

      ~ ▶ systemd-analyze
      Startup finished in 231ms (kernel) + 712ms (initrd) + 387ms (userspace) = 1.331s
      ~ ▶ systemd-analyze blame
      114ms udisks2.service
      102ms systemd-journal-flush.service
      97ms polkit.service
      85ms display-manager.service
      76ms systemd-udevd.service
      62ms upower.service
      43ms klog.service
      30ms systemd-udev-trigger.service
      27ms systemd-tmpfiles-setup.service
      22ms user@1000.service
      22ms systemd-remount-fs.service
      21ms sys-kernel-debug.mount
      18ms dev-mqueue.mount
      18ms dev-hugepages.mount
      16ms systemd-modules-load.service
      15ms systemd-logind.service
      15ms systemd-tmpfiles-setup-dev.service
      13ms systemd-networkd.service
      11ms systemd-fsck-root.service
      11ms systemd-update-utmp.service
      10ms systemd-sysctl.service
      8ms systemd-journald.service
      6ms dracut-shutdown.service
      5ms systemd-random-seed.service
      5ms kmod-static-nodes.service
      3ms rtkit-daemon.service
      3ms systemd-update-utmp-runlevel.service
      2ms systemd-user-sessions.service
      1ms systemd-vconsole-setup.service
      ~ ▶ _

      [
      | Versenden | Drucken ]
      • 0
        Von 1ras am Sa, 21. September 2019 um 21:06 #

        Hardwareverschlüsselung seitens der SSH ist nicht sicher. Besonders wenn man auch deshalb verschlüsselt, um bei einem Defekt die Garantie der SSD in Anspruch nehmen zu können, ist dies keine Option.

        Allerdings kann man die Hardwareunterstützung der CPU nutzen, Stichwort AES-NI. Damit und einer Multicore-CPU ist die Verschlüsselung im Normalbetrieb eigentlich nicht wahrnehmbar. Nur die Verzögerung beim Booten merkt man eben, da entsperren Zeit kosten muss um die Anzahl der Versuche zu limitieren. Außerdem wartet man alleine schon 2 Sekunden auf das USB-Backend, um einen Key von USB einlesen zu können. D.h. in der Zeit hast du schon durchgebootet. Irgend einen Tod muss man leider sterben.

        [
        | Versenden | Drucken ]
        • 0
          Von unix111 am So, 22. September 2019 um 12:30 #

          Gute Argumente. Seit Snowden und der Einmischung der US-Regierung in von ANSI und NIST vorgeschlagenen Standards ist auch möglich, dass Hersteller von Verschlüsselungstechnologie gezwungen werden, kryptografische Hintertüren einzubauen, aber ohne dies publik machen zu dürfen.

          Meine generelle Sorge bei der Verschlüsselung ganzer Partitionen oder Platten sind Defekte. Während bei Lesefehlern in unverschlüsselten Bereichen oft eine Rettung der meisten Blöcke möglich ist (sogar eine heuristische »Schätzung« der defekten Bits seitens der Platten-Firmware und dd), kann bei Block-Level-Verschlüsselung im Extremfall ein falsches Bit dazu führen, dass gar nix mehr lesbar ist, ähnlich wie bei proprietärer und zu »cleverer« RAID-Hardware, wo im Fehlerfall uninterpretierbarer Bit-Salat übrig bleibt.

          Da bleibe ich lieber noch eine Weile bei Dateiverschlüsselung der paar Files, die mir echt wichtig sind. Das meiste auf der Platte sind in meinem Fall Steam-Spiele und die Standardinstallation aus openSUSE-Paketen — kein Anlass hier zum Verschlüsseln, nur zum gelegentlichen Verifizieren der Checksummen. Zusammen mit bewährten Dateisystemen (ext4, XFS) und robusten Backup-Strategien sollte das doch für fast alle Fälle ausreichen.

          Ich war mal ein Jahr als Externer bei der Datev eG in Nürnberg, wo generell alle mobilen Geräte verschlüsselt sein müssen, habe ab und zu mitbekommen, was da alles schief geht und davon gelernt — aber wie Du schon so treffend schriebst: »Irgend einen Tod muss man leider sterben.«

          [
          | Versenden | Drucken ]
          • 0
            Von 1ras am So, 22. September 2019 um 16:37 #

            Da bin ich ganz bei dir, Verschlüsselung erhöht die Komplexität, was immer dann wenn es darauf ankommt, Abläufe teils massiv verkompliziert oder gar unmöglich macht. Wer schon einmal eine Festplatte hatte, welche langsam anfing unkorrigierbare Blöcke zu melden (bekommt man dank SMART-Monitoring rechtzeitig mit, kann ich nur empfehlen), der wird zu schätzen wissen, wenn er über Low-Level Tools feststellen kann, in welchen Dateien sich die defekten Blöcke befinden, um diese gezielt ersetzen zu können. Da kann jeder weitere Layer an Komplexität schnell einer zu viel sein.

            Andererseits dürften moderne SSDs ein ganz anderes Fehlerverhalten haben und ein gutes Backup ist ohnehin durch nichts zu ersetzen. Im Problemfall wird einem die höhere Komplexität aber sicherlich nicht von Vorteil sein.

            [
            | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung