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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.«
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.
braucht dann KDE eine Ewigkeit, um einsatzbereit zu sein.
Spaß beiseite: 300 ms für den Kernel – Respekt!
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.
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.
Für Wartungen an VMs ist entscheidend, wie lang ein Service ausfällt. Schnelle Bootzeiten sind da schon von Vorteil.
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.
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.
Ich lerne ja gern dazu. Was sind denn die besseren Alternative konkret? Ich würde mir das gerne ansehen.
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.
Dämliches Geschwätz!
Mag alles stimmen. Bis dahin heißt es "abwarten und Tee trinken".
zu:
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?
Crappy MacOS kannst Du ja wohl kaum meinen!
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?
Nein, einfach NEIN!!!!!!!!!!
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.
Ohne entsprechende Hardware und Modifikationen nicht möglich.
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.
Wie richtest Du ein partition auf einer ssd richtig aus?
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.
Haha, alleine die SSD-Verschlüsselung braucht hier schon 6 Sekunden, während dieser Zeit hast du schon 4x dein System gebootet
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
~ ▶ _
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.
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.«
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.