Der Kuketz hat uns berichtet welche Systeme er hat. Ich bin sehr ürberrascht das er ein alter Klaprechner aus 2018 benutzt, 8er generation i5/ i7 oder AMD?
Was genau macht diese Teil so besonders das er es noch immer benutzt???
Sollte man sich so ein gebrauchtes Model besorgen statt ein teurer neues? Leider gibt er nicht die details die bei meisten Linux Foren erzwingt werden: inxi -Fxxxrza (‚Sie müssen die Ausgabe des QSI-Dienstprogramms posten!!!‘ Ist ja auch sein eigenes Forum/ Blog. Oder ist das sowieso ein slechtes Idee um Quick System Info offentlich zu publizieren? inxi -Fxxxrza)
Wurde auch gerne wissen warum er Debian und nicht ein fork wie MX linux oder antiX installiert hat. Beiden haben ja init statt systemD
Wieso alter Klapprechner? Ich habe selbst kein Lenovo T480, aber in meiner Family gibt es so eines. Ein echtes Arbeitstier, 4x4 sozusagen. Sehr solide Hardware, also Gehäuse, Scharniere, Tastatur, Touchpad, etc. Finde mal solch gute Hardware im Jahr 2025 (bald 2026). Und von der Rechenleistung her reicht es ihm auch, er lässt ja darauf auch VMs laufen. Viel RAM und SSDs sind hier die Stichwörter. Im übrigen verkauft Nitrokey diese T480 als Nitropad inklusive Measured Boot und deaktivierter Intel Management Engine. Und: Nachhaltig. Warum ein Notebook von 2018 ausrangieren? Bräuchte ich ein neues Notebook, dann käme dies in die engste Auswahl.
Du beantwortest die Frage bereits selbst: Statt eines modernen Initsystems wie Systemd, welches Prozesse sauber von einnander isolieren und in Sandboxen sperren kann, haben sie Shellscripte wie Anno 1983.
Dass diese Debian-Forks auch aufwendig Updates manuell an ihr SysV-Init anpassen müssen, verzögert u.U. kritische Security-Updates. (Nicht, dass ich die Verzögerungen geprüft hätte - ist nur ein pauschaler Erfahrungswert).
Ich finde das schon einen validen Punkt. Warum ein System aussortieren, welches für die täglichen Anforderungen reicht? Ich habe selbst 10 Jahre alte DELL Latitude laufen, mit denen man noch super Surfen und Briefe schreiben kann..
Waren beim 2018er T480 der RAM noch austauschbar? Oder auch da schon fest verlötet?
Ich finde Nachhaltigkeit ist hier ein extrem valider Punkt. Warum soll ich mir für teuer Geld jedes Jahr ein neues Notebook hinstellen, was immer Unreparierbarer und Unaufrüstbarer wird, wenn die Performance des T480 immer noch meinen Anforderungen genügt?
Für mich ist das recht simpel: Das T480 macht alles, was ich brauche – wozu also mehr CPU-Leistung? Ich arbeite damit produktiv, keine Spiele, kein 4K-Rendering, dafür reichen 8. Gen und viel RAM/SSD völlig aus. Debian ist für mich »langweilig stabil« und gut gepflegt, genau das will ich im Alltag.
@TylerDurden7 + mlamhm203 + media-floppy Nachhaltigkeit ist nicht das Thema! Ich benutze ein teil aus 2011, total überflüssige Informationen in dieses Thema.
Ich bin neugierig, ob es Gründe in der Hardware gibt, die die Wahl erklären, Zb das vielleicht kein MPT Chip existiert oder so ähnliches? @HansVonWurst
Interessant nie daran gedacht. Obwohl die meinen selber ihr initV ist an sich schon ein bessrer Sicherheit als SystemD?!
Das einzige was man sich überlegen könnte ist, dass die 8. Generation mittlerweile keine Updates mehr von Intel bekommt.
Nicht tragisch, wenn im eigenen Thread Model Angriffe auf die CPU nicht relevant sind. Allerdings bin ich auf Grund der Features im Mobilsegment mittlerweile der Meinung, dass man im Laptop Segment noch einiges aufzuholen hat.
Es ist zwar schade, wenn man alte Hardware nicht mehr nutzen kann, aber bei Mobiltelefonen stellt sich die Frage gar nicht. Bei den Laptop wird es imho zu schnell ignoriert.
Bei den T480 muss man ein wenig die Augen aufhalten. Es gibt sie in der 8. Generation als 4-Kerner, aber leider auch in der 7. Generation als 2-Kerner.
Ein Thinkpad ist ein Thinkpad, ich habe noch einen T430, wenn auch selten noch im Gebrauch. Man kann sie (die T-Modelle) in aller Regel vernünftige öffnen, warten und aufrüsten. Nichts mit „man nehme ein Plektron und versuche das Zusammengeklemmte zu öffnen“.
Die IME ist auch für Linux relevant, da sie unabhängig vom installierten OS seine Funktionen ausführt (Wikipedia - IME). Ob die IME wirklich ein Risiko für den Anwender darstellt oder nicht ist nicht zweifelsfrei geklärt.
Des weiteren wäre ich dir sehr verbunden, wenn du die dB reduzieren könntest. Die vielen Ausrufezeichen und teilweise Wörter in Grossbuchstaben, als auch Sätze wie
stressen die Kommunikation unnötigerweise. Vielen Dank.
Kann ich nicht bewerten, da ich mir deren Initskripe nicht angeschaut habe. Systemd nutzt aber so etwas wie cgroups (also Isolierung von Prozessen) standardmäßig, was in klassischen Shellscripten aufwendig implementiert werden müsste oder viel Copy&Paste-Code benötigt.
Daneben erlaubt mit Systemd einen Dienst erst beim Ansprechen einer Sockets / Netzwerkports zu starten, und Dienste auch für Benutzer zu verwalten. Das ist mehr Komfort denn Sicherheit, aber der Mangel an Komfort ohne Systemd führt eher dazu, dass ein Dienst permanent und als root läuft.
Das sind imho die “Marketingversprechen” von Systemd. Hast Du einmal ernsthaft versucht ein halbwegs normal komplexes Client/Server Programm (in meinem Fall java basiert) mit Systemd Bordmitteln als User laufen zu lassen?
Ich hatte das Vergnügen eine Solaris Applikation nach RH Systemd zu migrieren.
Mit SysV konnte ich den Code sauber nach 1 h Portierung laufen lassen.
Systemd hat den Code wegen bescheiden gelöstem Abhängigkeitsmanagement und noch bescheidenerer Debugging Möglichkeiten (ist in den letzten 2 Jahren graduell besser geworden -aber noch lange nicht gut) auf 4 Init-Scripte aufgeblasen .
Die Neu-Implementierung dauerte 2 Wochen.
In beiden Fällen liefen die Prozesse abgeschottet in einem eigenen minder privilegierten User.
Unter Linux habe ich sie noch weiter mit RBACS eingehegt. (Ich habe nicht so viel Vertrauen in den java Code.)
Apropos Misstrauen - die SysV Scripte sind sicher nicht jedermanns Sache - imho aber wesentlich intuitiver als die “schlanken” > 1300000 Zeilen Systemd Code, die bei Updates gerne mal die Skripte brechen…. Wenn ich mir jetzt noch die Bootzeiten anschaue - dann ist Systemd für mich eine Lösung für Probleme, die ich nie hatte.
Hallo kuketzblog, kannst du bitte dein inxi -Fxxxrza publizieren, es sollte total harmlos sein und man ist nicht identifizierbar damit wird immer gesagt.
Ja. Unsicher geschriebene Java-Programme auf Uralt-JBossen mit noch älteren EOL-Java-Versionen mit Systemd und SELinux abzuschotten, war lange Zeit Teil meines Jobs (den ich nicht vermisse). Ich kann mich auch an die Zeiten vor Systemd erinnern - Das war ein Graus.
Am Ende reduziert es bei 99% aller Initskripte den Boilerplate-Code und reduziert das Skript auf die wesentliche Infos: Was, wann als wen ausführen. Kompliziertere Probleme brauchen komplexere Lösungen, aber selten so komplex, dass man POSIX-kompatible Shellscripte schreiben muss.
Systemd hat eine gute Doku, und Lennart Poetterings Blog lohnt sich auch als Tutorial.
Mit Sysvinit ist es sehr leicht, Code mit vollem Zugriff, Root-Rechten, unlimitierten Ulimits usw. laufen zu lassen. Wenn du das willst: Ja, das ist mit Systemd komplizierter.
Aus Sicherheitsperspektive sollte es aber leichter sein, Code mit Einschränkungen und mit voneinander isolierten Diensten laufen zu lassen. Wenn es das Argument für Sysvinit ist, dass es einfacher ist, schlechten Code laufen zu lassen, dann greife ich erst recht zu Systemd.
Systemd hat eher um die 700.000 LoC. Es ist eine große Softwaresuite, die alle möglichen Funktionen anbietet. Sie geht weit über Init hinaus und ist vor allem modular, d.h. man kann nur die Teile installieren, die man wirklich braucht. systemd-Updates brechen Skripte auch nicht einfach mal so, zumindest habe ich es in vielen Jahren Linux-Nutzung auf Servern und Desktopsystemen nie erlebt. Es verwenden nur noch ein paar Nischen-Distros kein systemd, weil es einfach besser ist als die Alternativen.
Um die von mir benötigte Funktionalität zu realisieren - halte ich die 700.000 LoC für kein Zeichen durchdachten, stringenten Designs - um es einmal extrem höflich zu formulieren…
Die Modularität von Systemd erinnert mich immer an die Modularität von SAP. (Man kann immer Dinge weglassen, dann geht halt irgend etwas auch anderswo nicht. Versionen mixen geht schon gar nicht…)
Ich habe Legacy Apps portiert und die haben einen Sack von Abhängigkeiten als technische Schuld im Gepäck.
Mit SysV init hatte ich das in <10 Zeilen reproduzierbar und sicher abgefrühstückt, weil die Shell eben um einiges mächtiger ist, als die Umgebung, die Systemd aufspannt.
Die RH Paketupdates haben mir regelmäßig, die, in der schönen Poettering Doku beschrieben - Environment Variablen geschrotet. Zudem musst ich aufgrund von funktionalen Beschränkungen 4 interdependente Systemd Boilerplate Code Services aufbauen um ein SysV Skript zu ersetzen.
Aufgrund von anderen Beschränkungen der Syntax von Systemd im Vergleich zu SysV init wurden die eigentlichen Startupscripte für die Anwendung(en) erheblich umfangreicher - und mussten ab initio angefertigt werden.
Die Tests von 4-5 Jahren waren ein Graus. Mittlerweile ist Systemd besser - aber imho immer noch weit davon entfernt so stabil wie SMF oder SysV init zu sein.
Ich verwende privat DEVUAN aus imho guten Gründen!
Am Ende führen alle init System Ihren Kern mit root Rechten aus.
Ob du nun mit SysV komfortabel oder mit Systemd mühsamer zu Fuß daraus brauchbaren init Code machst ist imho Geschmackssache.
Imho ist es in SysV init leichter gut wart- und testbaren Code zu schreiben, der Rechte weg - nimmt als im stark eingeschränkten Systemd was viel Boiler Plate Code erzwingt (your milage may vary).
Für Menschen mit Shell Phobie ist SysV init möglicherweise das falsche System.
Das gilt auch für Systemd … (Ich nehme mich da nicht aus. )
Ich knn das alles nur bestätigen, habe eine T480s sogar noch als Arbeitsrechner, solte letztens noch eine neues bekommen aber ch mag es sehr…hat als letztes s Modell noch wechselbare Speicherriegel. Die Displays sind teilweise von der Helligekeit etwas schwach, es gibt da aber unterschiedliche falls das für dich wichtig ist.
)