Systemd assimiliert sudo

[Paul Muster]

Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und
-Mechanismen in Systemd:

https://www.heise.de/news/Systemd-Alternative-zu-sudo-soll-Linux-sicherer-machen-9705458.html

| *Systemd-Alternative zu sudo soll Linux sicherer machen*
|
| run0 lässt reguläre Benutzer Programme mit root-Rechten ausführen. Es
| ähnelt sudo, nutzt aber andere Mechanismen zur Privilegienerhöhung und
| soll sicherer sein.
|
| 12:42 Uhr 02.05.2024 iX Magazin Von Dr. Oliver Diedrich
|
| Systemd-Entwickler Lennart Poettering hat mit der neuen Version 256
| von Systemd für Linux das Tool run0 inkludiert. Mit run0 können
| reguläre Nutzer ein Kommando mit root-Rechten ausführen. Poettering
| empfiehlt es als sichereren Ersatz für sudo. [...]


Na, herzlichen Glückwunsch. Ja, es kann schlechter werden also das
Original-sudo. Wir werden sehen.


mfG Paul

[Marco Moock]

Post by Paul Muster
Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und
https://www.heise.de/news/Systemd-Alternative-zu-sudo-soll-Linux-sicherer-machen-9705458.html
| *Systemd-Alternative zu sudo soll Linux sicherer machen*
|
| run0 lässt reguläre Benutzer Programme mit root-Rechten ausführen.
Es | ähnelt sudo, nutzt aber andere Mechanismen zur
Privilegienerhöhung und | soll sicherer sein.
|
| 12:42 Uhr 02.05.2024 iX Magazin Von Dr. Oliver Diedrich
|
| Systemd-Entwickler Lennart Poettering hat mit der neuen Version 256
| von Systemd für Linux das Tool run0 inkludiert. Mit run0 können
| reguläre Nutzer ein Kommando mit root-Rechten ausführen. Poettering
| empfiehlt es als sichereren Ersatz für sudo. [...]
Na, herzlichen Glückwunsch.

|Das ganze SUID-Konzept sei nicht mehr zeitgemäß und gehöre "auf den
|Haufen schlechter Unix-Ideen".

Warum macht der eigentlich nicht ein Poettering OS?
Ganz ohne UNIX-Ideen?

Post by Paul Muster
Ja, es kann schlechter werden also das Original-sudo.

Bisher ist mir das nicht negativ aufgefallen. Zwar ist die
Konfigurationsdatei etwas komisch, aber an die muss man nur selten ran.
Bisher musste ich das nur 1x unter FreeBSD.

Stattdessen darf man sich dann mit systemd-units, PolKit und Co.
befassen.

[Ralph Aichinger]

Post by Marco Moock
Stattdessen darf man sich dann mit systemd-units, PolKit und Co.

Mit systemd-units muß man sich 2024 sowieso beschäftigen, wenn man
irgendwas mit Unix machen will. Und sei es nur weil man eine
Linux-Konfiguration woanders hin übertragen will.

Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd. Ich möchte
nicht mehr zurück auf den Stand von 1990 oder so.

/ralph

[Marco Moock]

Post by Ralph Aichinger

Post by Marco Moock
Stattdessen darf man sich dann mit systemd-units, PolKit und Co.

Mit systemd-units muß man sich 2024 sowieso beschäftigen, wenn man
irgendwas mit Unix machen will.

Bisher halt nicht, um root-Privilegien zu erhalten. Das könnte hier
lustig werden, wenn mal was verkorkst ist. :-)
PS: Welches UNIX hat denn systemd?

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd.

Bei mir ja umgekehrt. Erst systemd, dann SysVinit und unter FreeBSD
habe ich auch mal den init gesehen.
Irgendwie gruselig, aber nachvollziehbar, dass die kein systemd wollen.

[Ralph Aichinger]

Post by Marco Moock
Bisher halt nicht, um root-Privilegien zu erhalten. Das könnte hier
lustig werden, wenn mal was verkorkst ist. :-)
PS: Welches UNIX hat denn systemd?

Wenn man ein nicht-Linux verwendet, dann muss man sysemd-Units zumindest
verstehen um sie in Init-Skripte zu übersetzen. Vieles an Software wird
heute mit systemd-Units und nur systemd-Units ausgeliefert.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Marco Moock
Bisher halt nicht, um root-Privilegien zu erhalten. Das könnte hier
lustig werden, wenn mal was verkorkst ist. :-)
PS: Welches UNIX hat denn systemd?

Wenn man ein nicht-Linux verwendet, dann muss man sysemd-Units zumindest
verstehen um sie in Init-Skripte zu übersetzen. Vieles an Software wird
heute mit systemd-Units und nur systemd-Units ausgeliefert.

Der Code, der eine systemd-Unit liest und in einem execve() endet ist
vorhanden und Open Source. Man könnte, wenn man wollte, unter Nutzung
dieses Codes ein Programm schreiben, das ein initskript-kompatibles
Kommandozeileninterface hat, ein Vrzeichnis mit systemd-Units liest
und unter Weglassen von auf der Zielplattform nicht verfügbaren
Features am Ende das Programm aufruft.

Man müsste dann für stop, reload, restart halt wieder mit pidfiles und
kruden Heuristiken arbeiten wenn man keine namespaces hat.

Hat halt noch niemand gemacht. Praktisch für nicht-systemd-Linuxe und
andere unixoide Systeme wäre es.

Grüße
Marc

[Marc Haber]

Post by Marco Moock

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd.

Bei mir ja umgekehrt. Erst systemd, dann SysVinit und unter FreeBSD
habe ich auch mal den init gesehen.
Irgendwie gruselig, aber nachvollziehbar, dass die kein systemd wollen.

Andersrum wird ein Schuh draus. systemd benutzt konsequent
Linux-Features, die gibt es auf anderen Betriebssystemen halt nicht:
Namespaces, Capabilities, Bind-Mounts etc bla.

Lennart hat klar gesagt, dass systemd ein Linux-Programm ist und dass
er keine OS-Weichen-ifdef-Orgien in seinem Code haben will.

Und irgendwie ist systemd ja tatsächlich gut genug dass es noch
niemand geforkt hat.

Grüße
Marc

[Kay Martinen]

Post by Marc Haber

Post by Marco Moock

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd.

Bei mir ja umgekehrt. Erst systemd, dann SysVinit und unter FreeBSD
habe ich auch mal den init gesehen.
Irgendwie gruselig, aber nachvollziehbar, dass die kein systemd wollen.

Andersrum wird ein Schuh draus. systemd benutzt konsequent
Namespaces, Capabilities, Bind-Mounts etc bla.
Lennart hat klar gesagt, dass systemd ein Linux-Programm ist und dass
er keine OS-Weichen-ifdef-Orgien in seinem Code haben will.
Und irgendwie ist systemd ja tatsächlich gut genug dass es noch
niemand geforkt hat.

Impliziert das nicht im Umkehrschluß den Anspruch das andere Unices die
systemd hätten haben wollen dann gefälligst auch die anderen; von
systemd linux-eigen genutzten; Funktionen nachrüsten müssten.

Bei so einer Ansage würde ich mir das dann auch zwei mal mehr überlegen,
wenn ich etwas non-linux, BSD o.a. benutzen/supporten wollte.

Damit will ich nicht mal systemd schlecht machen. Aber es wäre doch
gewiß ein größerer Aufriß deine o.g. Features auf einem anderen
(Non-Linux) OS um zu setzen - nur damit man dort dann systemd nutzen könne.

= Entweder alles Forken/migrieren oder gar nichts.

Das werden dann wohl nur größere Firmen in Angriff nehmen - wenn sie es
dringend bräuchten. Aber für was genau ist dann die Frage.

Abgesehen davon wären die anderen OS dann um eines ihrer ureigenen
Alleinstellungsmerkmale verringert. Das dort nur ihr eigenes Init läuft. ;)

Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Impliziert das nicht im Umkehrschluß den Anspruch das andere Unices die
systemd hätten haben wollen dann gefälligst auch die anderen; von
systemd linux-eigen genutzten; Funktionen nachrüsten müssten.

Vermutlich. Oder systemd forken und die Funktionalität irgendwie
implementieren.

Post by Kay Martinen
Bei so einer Ansage würde ich mir das dann auch zwei mal mehr überlegen,
wenn ich etwas non-linux, BSD o.a. benutzen/supporten wollte.

Ein Non-Linux-Unix verwendet man heute eh meist eher für spezielle Nischen,
z.B. irgendwelche Embedded-Dinger oder Firewalls.

Für Mietserver, Cloud-Images, irgendwelche allgemeinen
Webserveraufgaben, irgendwelche Backends verwendet man eh zu einem sehr
hohen Anteil Linux, wenig Windows, da spielt Open/Free/NetBSD/MacOS/Solaris (gibt es
Solaris noch?) kaum eine Rolle mehr. Letztendlich ist die Frage heute
nicht mehr SysV oder BSD, bwz. Linux oder BSD bzw. kommerzielles Unix vs
freies, sondern "Debian-basiert" vs. "Redhat-basiert". Mit letzterer
Unterscheidung hast du schon einen Großteil des Servermarkts abgedeckt.

Post by Kay Martinen
Damit will ich nicht mal systemd schlecht machen. Aber es wäre doch
gewiß ein größerer Aufriß deine o.g. Features auf einem anderen
(Non-Linux) OS um zu setzen - nur damit man dort dann systemd nutzen könne.

Umgekehrt: Man wird für allegemeine nicht-Nischenanwendungen sowieso
kein anderes Unix mehr am Server verwenden. Clientseitig gibt es
natürlich MacOS, aber das verwendet niemand am Server ohne Not (z.B.
als Builder für iPhone-Anwendungen).

Post by Kay Martinen
Das werden dann wohl nur größere Firmen in Angriff nehmen - wenn sie es
dringend bräuchten. Aber für was genau ist dann die Frage.

Niemand wird das in Angriff nehmen. Linux hat sich am Server
durchgesetzt, wenn man sich von letztendlich auch auslaufenden
Windows-Abteilungsservern/Active-Directory-Servern (wie lang gibt es die
noch?) absieht.

Eher portiert Microsoft Active Directory auf Linux als dass die volle
Linux-Funktionalität auf MacOS X oder OpenBSD portiert wird, IMHO.

BSDs haben ihre eigene Nische, z.B. als embedded-Teil, wegen der Lizenz.
Oder weil sie nicht Linux sind.

/ralph

[Marco Moock]

Post by Ralph Aichinger
Ein Non-Linux-Unix verwendet man heute eh meist eher für spezielle
Nischen, z.B. irgendwelche Embedded-Dinger oder Firewalls.

*BSD wird aber im Serverbereich auch gerne verwendet, vermutlich viel
häufiger als Solaris oder IBM AIX.

Post by Ralph Aichinger
Umgekehrt: Man wird für allegemeine nicht-Nischenanwendungen sowieso
kein anderes Unix mehr am Server verwenden.

Bei kommerziellem Unix kann ich das verstehen, aber was spricht denn
gegen die freien BSD-Varianten, außer, dass die halt anders sind?

Post by Ralph Aichinger
Niemand wird das in Angriff nehmen.

Wenn bei *BSD Bedarf ist, würde ich das nicht ausschließen. Aber das
alte init reicht da wohl aus - zumindest hätte man das andernfalls
sicher mitbekommen.

Post by Ralph Aichinger
Linux hat sich am Server durchgesetzt, wenn man sich von letztendlich
auch auslaufenden Windows-Abteilungsservern/Active-Directory-Servern
(wie lang gibt es die noch?) absieht.

Noch sehr lange, denn MS ist nach wie vor Maaaaarktstandard.

Post by Ralph Aichinger
Eher portiert Microsoft Active Directory auf Linux als dass die volle
Linux-Funktionalität auf MacOS X oder OpenBSD portiert wird, IMHO.

OpenLDAP existiert, 389 directory server auch. Kann das denn was nicht,
was man im LDAP-Umfeld braucht?

[Ralph Aichinger]

Post by Marco Moock
*BSD wird aber im Serverbereich auch gerne verwendet, vermutlich viel
häufiger als Solaris oder IBM AIX.

IMHO ist das Geschichte. Ich hab die letzten 10 Jahre nix mehr in die
Richtung mitgekriegt, auch bei hunderten Systemen von Kunden der Firmen
bei denen ich gearbeitet habe nicht. Ausnahme: Lösungen wie TrueNAS oder
pfSense, aber das geht schon in Richtung self-contained/embedded.
Mag sein, dass ich einen verschobenen Blick auf die IT habe, weil ich
halt von einem gewissen Ausgangspunkt gestartet bin.

Post by Marco Moock
Bei kommerziellem Unix kann ich das verstehen, aber was spricht denn
gegen die freien BSD-Varianten, außer, dass die halt anders sind?

Dass sie anders sind. Du kannst bei komplexeren Softwaresystemen oft
zig Anleitungen finden, wie man das Zeug unter Ubuntu installiert, und eine
wie es auf OpenBSD *vielleicht* funktionieren könnte, oder so.

Post by Marco Moock

Post by Ralph Aichinger
Linux hat sich am Server durchgesetzt, wenn man sich von letztendlich
auch auslaufenden Windows-Abteilungsservern/Active-Directory-Servern
(wie lang gibt es die noch?) absieht.

Noch sehr lange, denn MS ist nach wie vor Maaaaarktstandard.

Ja, nur die Frage ist: Zwingt Microsoft Leute die Blech daheim stehen
haben in die Cloud?

Post by Marco Moock
OpenLDAP existiert, 389 directory server auch. Kann das denn was nicht,
was man im LDAP-Umfeld braucht?

Maaaaarktstandard ;)

/ralph

[Kay Martinen]

Post by Marco Moock

Post by Ralph Aichinger
Ein Non-Linux-Unix verwendet man heute eh meist eher für spezielle
Nischen, z.B. irgendwelche Embedded-Dinger oder Firewalls.

*BSD wird aber im Serverbereich auch gerne verwendet, vermutlich viel
häufiger als Solaris oder IBM AIX.

Ich sehe BSD-Basierte Systeme eigentlich viel eher im Netzwerk-Bereich,
sprich Routing, Paketfilter u.a. Infrastruktur-sachen. Siehe Pfsense,
OPNsense u.a. Und NetBSD hat z.b. ja den "Ruf" das es quasi auf allem
liefe was eine CPU hätte, selbst auf einem Toaster, Thermomix oder...
WLAN-Glühobst. ;-)

Die richtigen "Server" sind dann eben Linux für Vieles, bei reinem
Storage vielleicht noch TrueNAS (=BSD) oder wenn es der Kunde eklig
haben will auch mal eine WinDoze. :)

Post by Marco Moock
OpenLDAP existiert, 389 directory server auch. Kann das denn was nicht,
was man im LDAP-Umfeld braucht?

Vielleicht spricht er nicht Microsoftisch genug. ;) Man braucht halt die
ganzen Schema-dateien die ein AD braucht - und das Drumherum.

Aber vielleicht probierst du mal Univention Corporate Server
(community-edition Kostenlos) aus. IMHO soll der auch ein AD für
MS-Clients bieten.
Könnte allerdings sein das man mit dem nötigen Feature für Totale
Integration dann den Kostenlosen Bereich verläßt.

BTW zum Thema passend: Der UCS "verhindert" den Zugang auf eine
Root-Konsole, sowohl am Gerät als auch via SSH. Ist meine Erfahrung.

Man kommt zwar auf den Server aber nur als Admin mit passsend gesetzten
Rechten und auch da darf man lange nicht alles. IMO geht 'sudo' zu root
dort auch nicht weil er einem nicht erlaubt ein kennwort zu finden oder
setzen dafür. Ist vielleicht ganz weise für eine Lösung die alles über
eine WebUI ONU-tauglich abwickeln will.

Bye/
/Kay

[Tim Ritberg]

Post by Kay Martinen
Vielleicht spricht er nicht Microsoftisch genug. ;) Man braucht halt die
ganzen Schema-dateien die ein AD braucht - und das Drumherum.

UCS existiert.

Tim

[Kay Martinen]

Post by Tim Ritberg

Post by Kay Martinen
Vielleicht spricht er nicht Microsoftisch genug. ;) Man braucht halt
die ganzen Schema-dateien die ein AD braucht - und das Drumherum.

UCS existiert.

Hast du meinen nachfolgenden Absatz (in dem es um UCS ging) nicht nur
nicht mit geqoutet sondern schlicht nicht gelesen? :)

Bye/
/Kay

[Alexander Schreiber]

Post by Kay Martinen

Post by Marco Moock

Post by Ralph Aichinger
Ein Non-Linux-Unix verwendet man heute eh meist eher für spezielle
Nischen, z.B. irgendwelche Embedded-Dinger oder Firewalls.

*BSD wird aber im Serverbereich auch gerne verwendet, vermutlich viel
häufiger als Solaris oder IBM AIX.

Ich sehe BSD-Basierte Systeme eigentlich viel eher im Netzwerk-Bereich,
sprich Routing, Paketfilter u.a. Infrastruktur-sachen. Siehe Pfsense,
OPNsense u.a. Und NetBSD hat z.b. ja den "Ruf" das es quasi auf allem
liefe was eine CPU hätte, selbst auf einem Toaster, Thermomix oder...
WLAN-Glühobst. ;-)

Netflix hat FreeBSD im Einsatz. U.a. um _intelligent_ NUMA zu nutzen und
damit richtig Durchsatz aus den CDN Maschinen zu holen, gibt es Papers und
Vortäge dazu.

Post by Kay Martinen
Die richtigen "Server" sind dann eben Linux für Vieles, bei reinem
Storage vielleicht noch TrueNAS (=BSD) oder wenn es der Kunde eklig
haben will auch mal eine WinDoze. :)

Post by Marco Moock
OpenLDAP existiert, 389 directory server auch. Kann das denn was nicht,
was man im LDAP-Umfeld braucht?

Vielleicht spricht er nicht Microsoftisch genug. ;) Man braucht halt die
ganzen Schema-dateien die ein AD braucht - und das Drumherum.
Aber vielleicht probierst du mal Univention Corporate Server
(community-edition Kostenlos) aus. IMHO soll der auch ein AD für
MS-Clients bieten.

Hmm, damit kann man sich vielleicht immerhin MS AD Serverinfrastruktur
als Scheunentor für unerwünschte Gäste sparen? Aber die MS Clients
hat man halt immer noch am Hals.

Post by Kay Martinen
Könnte allerdings sein das man mit dem nötigen Feature für Totale
Integration dann den Kostenlosen Bereich verläßt.
BTW zum Thema passend: Der UCS "verhindert" den Zugang auf eine
Root-Konsole, sowohl am Gerät als auch via SSH. Ist meine Erfahrung.
Man kommt zwar auf den Server aber nur als Admin mit passsend gesetzten
Rechten und auch da darf man lange nicht alles. IMO geht 'sudo' zu root
dort auch nicht weil er einem nicht erlaubt ein kennwort zu finden oder
setzen dafür. Ist vielleicht ganz weise für eine Lösung die alles über
eine WebUI ONU-tauglich abwickeln will.

Naja, root die Zähne zu ziehen ist keine so neue Idee, die Mittel dazu
gibt es bei Linux schon lange (u.a. SELinux), wird AFAIK aber nur selten
eingesetzt, weil es prinzipbedingt keine "shake&bake" Fertiglösung ist
sondern man sich ernsthaft mal mit der gewünschten Privilegienstruktur
auseinandersetzen muss.

Man liest sich,
Alex.

[Alexander Schreiber]

Post by Marc Haber

Post by Marco Moock

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd.

Bei mir ja umgekehrt. Erst systemd, dann SysVinit und unter FreeBSD
habe ich auch mal den init gesehen.
Irgendwie gruselig, aber nachvollziehbar, dass die kein systemd wollen.

Andersrum wird ein Schuh draus. systemd benutzt konsequent
Namespaces, Capabilities, Bind-Mounts etc bla.
Lennart hat klar gesagt, dass systemd ein Linux-Programm ist und dass
er keine OS-Weichen-ifdef-Orgien in seinem Code haben will.
Und irgendwie ist systemd ja tatsächlich gut genug dass es noch
niemand geforkt hat.

Kleine Korrektur: s/gut/komplex/

SCNR,
Alex.

[Dietz Proepper]

Post by Alexander Schreiber

Post by Marc Haber

Post by Marco Moock

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd.

Bei mir ja umgekehrt. Erst systemd, dann SysVinit und unter FreeBSD
habe ich auch mal den init gesehen.
Irgendwie gruselig, aber nachvollziehbar, dass die kein systemd wollen.

Andersrum wird ein Schuh draus. systemd benutzt konsequent
Namespaces, Capabilities, Bind-Mounts etc bla.
Lennart hat klar gesagt, dass systemd ein Linux-Programm ist und
dass er keine OS-Weichen-ifdef-Orgien in seinem Code haben will.
Und irgendwie ist systemd ja tatsächlich gut genug dass es noch
niemand geforkt hat.

Kleine Korrektur: s/gut/komplex/

Du hast durchaus recht.

Und Herrn Poettering ist jederzeit zuzutrauen, dass er einen Fork mit
funktionalen Änderungen sabotiert. Macht er mit Admins ja seit es
systemd gibt. Ich will ihm gemäß Hanlon natürlich keinen Vorsatz
unterstellen.

Post by Alexander Schreiber
SCNR,

Es ist eher traurig.

[Thomas Zajic]

Post by Ralph Aichinger
Mit systemd-units muß man sich 2024 sowieso beschäftigen, wenn man
irgendwas mit Unix machen will. Und sei es nur weil man eine
Linux-Konfiguration woanders hin übertragen will.

Kann ich so eigentlich nicht bestätigen, es sei denn du zählst Linux
nicht zu "irgendwas mit Unix".

Post by Ralph Aichinger
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd. Ich möchte
nicht mehr zurück auf den Stand von 1990 oder so.

[***@disclosure:~]$ date +%Y
2024
[***@disclosure:~]$ lsb_release -ds
"Slackware 15.0 x86_64"
[***@disclosure:~]$ ls -1ad /etc/rc.d/rc* | wc -l
68
[***@disclosure:~]$ pgrep -af systemd
[***@disclosure:~]$

Ja, das ist privat. Ja, beruflich sieht das ein bisschen anders aus.
RHEL, CentOS, Rocky, Oracle, SLES ... alles systemd-verseucht. Pfui.

Aber daheim habe ich noch meine Insel der Seligen. Da gibt es nicht
mehr von systemd als den elogind. Und der geht grad noch so. :-)

LG
Thomas

[Martin Vaeth]

Da gibt es nicht mehr von systemd als den elogind.

Wozu? seatd existiert und wird von wlroots unterstützt,
auf den alle benutzbaren wayland compositors aufbauen.
Das Einzige, das von systemd nützlich ist, ist tmpfiles
sowie ev. noch udev - je nach System.

[Thomas Zajic]

Post by Martin Vaeth

Da gibt es nicht mehr von systemd als den elogind.

Wozu? seatd existiert und wird von wlroots unterstützt,
auf den alle benutzbaren wayland compositors aufbauen.
Das Einzige, das von systemd nützlich ist, ist tmpfiles
sowie ev. noch udev - je nach System.

Hab ich mir nicht ausgesucht, ist halt bei Slackware dabei, laut Changelog
als Ersatz für ConsoleKit2. seatd sagt mir nix, ich kann mir aber aufgrund
des Namens ungefähr ausmalen was der tut. :-) Wayland ist mir aber eh
relativ egal, bei mir läuft noch Xorg. Und als Ersatz für das von systemd
assimilierte udev gibts unter Slackware eudev.

Mal sehen wie lange es meine Insel der Seligen noch gibt. Selbst PAM gibt
es auf Slackware erst seit 15.0 (wurde Anfang 2022 released), von daher
habe ich also im Hinblick auf systemd noch jede Menge Hoffnung. :-D

LG
Thomas

[Martin Vaeth]

Post by Thomas Zajic

Post by Martin Vaeth

Da gibt es nicht mehr von systemd als den elogind.

Wozu? seatd existiert und wird von wlroots unterstützt,
auf den alle benutzbaren wayland compositors aufbauen.
Das Einzige, das von systemd nützlich ist, ist tmpfiles
sowie ev. noch udev - je nach System.

Hab ich mir nicht ausgesucht, ist halt bei Slackware dabei

Nach Deinen Beschreibungen käme Slackware aus Sicherheitsgründen
für mich als Distribution nicht in Frage. Ich würde Dir empfehlen,
zu Gentoo zu wechseln: Das kannst Du Dir so sicher machen, wie Du
willst. Das macht allerdings Arbeit, denn Du musst Dir Deine
gewünschte Distribution i.W. selbst zusammenstellen.

Post by Thomas Zajic
Wayland ist mir aber eh relativ egal, bei mir läuft noch Xorg.

Käme für mich auch aus Sicherheitsgründen nicht in Frage.
Das habe ich nur noch für den Notfall, weil einige wenige Sachen
(in meinem Fall bisher nur extreme-tuxracer) dort nicht laufen.
Ich starte X seit ein paar Jahren nur noch hin und wieder zum
Testen (ebenso wie systemd, das für mich ein Ersatz-Notboot-System
ist, falls openrc mal nicht hochkommt). Ernsthaft auf einem von
beiden zu arbeiten, wäre mir zu unsicher.

Post by Thomas Zajic
Und als Ersatz für das von systemd assimilierte udev gibts
unter Slackware eudev.

Wow! Ein Tool von Gentoo-Entwicklern, das von seinen Entwicklern
seit Jahren nicht mehr gewartet wird und deswegen aus dem
Gentoo-Baum entfernt wurde!
Die Benutzung solcher ungewarteter Tools ist potentiell ein
noch größeres Sicherheitsloch als systemd.
An udev finde ich nichts verkehrt (es kann unter Gentoo auch
ohne systemd installiert werden, läuft auch mit openrc, und
ist zumindest nicht konzeptionell ein Sicherheitsloch).
Aber wenn Du es aus religiösen Gründen ablehnst, kann Du
unter Gentoo auch das gewartete mdev aus busybox benutzen,
oder natürlich ein statisches /dev anlegen. Beides kann bei
Anstöpseln entsprechender Hardware mit manuellem Frickeln
verbunden sein.
Aber vermutlich wird auch das eudev ebuild von irgendeinem
nicht-Gentoo-Entwickler weiter in irgendeinem Repository
angeboten.

Post by Thomas Zajic
Mal sehen wie lange es meine Insel der Seligen noch gibt.

Unter Gentoo ist noch kein Ende in Sicht.

Post by Thomas Zajic
Selbst PAM gibt es auf Slackware erst seit 15.0

Ich hatte PAM mal kurzzeitig drauf, weil kein wayland-compositor
in der wayland Anfangszeit ohne das startete (aber nur 1-2
Programme hatte ich so kompiliert, dass sie es tatsächlich
benutzt haben). Das ist aber schon lange nicht mehr so, und ich
habe es vor ein paar Jahren wieder heruntergeschmissen.

[Erik Heinz]

Post by Martin Vaeth

Post by Thomas Zajic
Und als Ersatz für das von systemd assimilierte udev gibts
unter Slackware eudev.

Wow! Ein Tool von Gentoo-Entwicklern, das von seinen Entwicklern
seit Jahren nicht mehr gewartet wird und deswegen aus dem
Gentoo-Baum entfernt wurde!

eudev wird sehr wohl weiterentwickelt. Release 3.2.14 ist vom 5.10.2023.

Die Verwendung exotischer oder veralteter Systemkomponenten hat im übrigen
den Vorteil, dass diese meist keine lohnenden Angriffsziele darstellen.
Also statistisch gesehen ein Sicherheitsfeature ;-).


Viele Grüße,
Erik

[Martin Vaeth]

Post by Erik Heinz

Post by Martin Vaeth

Post by Thomas Zajic
Und als Ersatz für das von systemd assimilierte udev gibts
unter Slackware eudev.

Wow! Ein Tool von Gentoo-Entwicklern, das von seinen Entwicklern
seit Jahren nicht mehr gewartet wird und deswegen aus dem
Gentoo-Baum entfernt wurde!

eudev wird sehr wohl weiterentwickelt. Release 3.2.14 ist vom 5.10.2023.

Aha. Dann vermutlich von jemand anderem: Der Link von der
Gentoo-Wikipedia ist tot.

Post by Erik Heinz
Die Verwendung exotischer oder veralteter Systemkomponenten hat im übrigen
den Vorteil, dass diese meist keine lohnenden Angriffsziele darstellen.
Also statistisch gesehen ein Sicherheitsfeature ;-).

Hoffnung ist kein Sicherheitsprinzip.

[Alexander Schreiber]

Post by Ralph Aichinger

Post by Marco Moock
Stattdessen darf man sich dann mit systemd-units, PolKit und Co.

Mit systemd-units muß man sich 2024 sowieso beschäftigen, wenn man
irgendwas mit Unix machen will.

Man sollte "The Ten Commandments for C Programmer", Gebot 10 (im
Original: "Thou shalt foreswear, renounce, and abjure the vile heresy
which claimeth that ``All the world's a VAX'', and have no commerce
with the benighted heathens who cling to this barbarous belief,
that the days of thy program may be long even though the days of
thy current machine be short.") vermutlich aktualisieren auf sowas wie
"Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world is amd64 and all Unix is Linux```". ;-)

Es gibt auch noch Unix ausserhalb der Pinguin-Farm ;-)

Post by Ralph Aichinger
Und sei es nur weil man eine
Linux-Konfiguration woanders hin übertragen will.
Mein erstes Init-System das ich als Admin mitbekommen hab war noch
BSD-Init (unter Slackware), dann SysV-Init, dann systemd. Ich möchte
nicht mehr zurück auf den Stand von 1990 oder so.

Naja, sysvinit hat auch keinen Mangel an Warzen und systemd hat
durchaus sinnvolle Ideen umgesetzt. Nur diese langsame Vereinahmung
durch systemd Komponenten (mittlerweile habe ich wieder eine fixit
Liste nach der Systeminstallation, u.a. systemd-resolved stilllegen)
nervt zunehmend.

Man liest sich,
Alex.

[Peter J. Holzer]

Post by Alexander Schreiber

Post by Ralph Aichinger

Post by Marco Moock
Stattdessen darf man sich dann mit systemd-units, PolKit und Co.

Mit systemd-units muß man sich 2024 sowieso beschäftigen, wenn man
irgendwas mit Unix machen will.

Man sollte "The Ten Commandments for C Programmer", Gebot 10 (im
Original: "Thou shalt foreswear, renounce, and abjure the vile heresy
which claimeth that ``All the world's a VAX'', and have no commerce
with the benighted heathens who cling to this barbarous belief,
that the days of thy program may be long even though the days of
thy current machine be short.") vermutlich aktualisieren auf sowas wie
"Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world is amd64 and all Unix is Linux```". ;-)

In der Annotated Edition hat Henry selbst dazugeschrieben:

| This particular heresy bids fair to be replaced by ``All the world's a
| Sun'' or ``All the world's a 386'' (this latter being a particularly
| revolting invention of Satan), but the words apply to all such without
| limitation. Beware, in particular, of the subtle and terrible ``All
| the world's a 32-bit machine'', which is almost true today but shall
| cease to be so before thy resume grows too much longer.

hp

[Marco Moock]

Post by Alexander Schreiber
Naja, sysvinit hat auch keinen Mangel an Warzen und systemd hat
durchaus sinnvolle Ideen umgesetzt. Nur diese langsame Vereinahmung
durch systemd Komponenten (mittlerweile habe ich wieder eine fixit
Liste nach der Systeminstallation, u.a. systemd-resolved stilllegen)
nervt zunehmend.

Was mir daran vor allem stinkt ist der Umstand, dass diese Sachen dann
Teil von systemd sind und auf anderen Systemen nicht eingesetzt werden
können. dnsmasq, nscd, ntpd & Co. gehen halt auch auf Slackware oder
BSD.

[Michael Bäuerle]

Post by Marco Moock

Post by Alexander Schreiber
Naja, sysvinit hat auch keinen Mangel an Warzen und systemd hat
durchaus sinnvolle Ideen umgesetzt. Nur diese langsame Vereinahmung
durch systemd Komponenten (mittlerweile habe ich wieder eine fixit
Liste nach der Systeminstallation, u.a. systemd-resolved stilllegen)
nervt zunehmend.

Was mir daran vor allem stinkt ist der Umstand, dass diese Sachen dann
Teil von systemd sind und auf anderen Systemen nicht eingesetzt werden
können. [...]

Wenn man unterstellt, dass vendor lock-in hinzugefügt werden soll,
dann ist das genau so gewünscht. Du sollst nichts anderes verwenden,
insbesondere kein anderes OS.

[Ralph Aichinger]

Post by Michael Bäuerle
Wenn man unterstellt, dass vendor lock-in hinzugefügt werden soll,
dann ist das genau so gewünscht. Du sollst nichts anderes verwenden,
insbesondere kein anderes OS.

Das ist die eine Sichtweise.

Die andere Sichtweise: Linux entwickelt sich halt weiter, bekommt neue
Features, während andere Unices letztendlich irgendwo oft auf einem Stand
stehengeblieben sind, auf dem Linux ca. 2000 war, und sich nur mehr
langsam durch übernehmen von Linux-Features mit Verspätung von Jahren
oder Jahrzehnten weiterentwickeln[1].

Wenn man da immer nach dem kleinsten gemeinsamen Nenner geht, dann
müssen wir ewig bei 640k und 8.3-Dateinamen bleiben, oder so.

/ralph

[1] Ausnahme natürlich MacOS

[Martin Vaeth]

Post by Ralph Aichinger

Post by Michael Bäuerle
Wenn man unterstellt, dass vendor lock-in hinzugefügt werden soll,
dann ist das genau so gewünscht. Du sollst nichts anderes verwenden,
insbesondere kein anderes OS.

Das ist die eine Sichtweise.
Die andere Sichtweise: Linux entwickelt sich halt weiter, bekommt neue
Features, während andere Unices letztendlich irgendwo oft auf einem Stand
stehengeblieben sind, auf dem Linux ca. 2000 war

Andersrum wird ein Schuh draus: Solaris beispielsweise hatte schon lange
ein gut durchdachtes Capabilities-System, während Linux nur eine
Teilmenge - die Posix-Capabilities - tröpfchenweise und mit vielen
Problemen (sowohl was Sicherheit als auch was Performance betrifft)
übernahm, da offensichtlich vorher das Gesamtkonzept niemals richtig
überdacht worden war.

Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war. In dem Fall liegt
das Problem nicht bei Linux (TIPC ist dort schon lange verfügbar),
sondern ganz klar am NIH-Syndrom von systemd, die natürlich auch die
Probleme von dbus sahen, aber statt TIPC zu nutzen (oder ggf. um ein
paar von ihnen benötigte Features zu erweitern) unbedingt zusätzlich
einen minderwertigen TIPC-Clone in den Kernel drücken wollten, was
glücklicherweise gescheitert ist.

Disclaimer: Ich kenne weder die Details des Solaris-Capabilities Systems
noch von TIPC oder der entsprechenden Linux-Lösungen, habe dies aber von
vertrauenswürdigen Leuten gelernt, die mit jeweils ersterem viel Erfahrung
hatten und ob der Linux-Varianten die Hände über dem Kopf zusammengeschlagen
haben.

Post by Ralph Aichinger
Wenn man da immer nach dem kleinsten gemeinsamen Nenner geht

Deswegen kommen immer wieder neue Releases des Posix-Standards heraus.
Ich vermute mal, wenn Posix nicht zumindest die wichtigsten Capabilities
standardisiert hätte, gäbe es bei Linux vermutlich immer noch gar keine,
oder noch schlechtere als jetzt.

[Ralph Aichinger]

Post by Martin Vaeth
Andersrum wird ein Schuh draus: Solaris beispielsweise hatte schon lange
ein gut durchdachtes Capabilities-System, während Linux nur eine
Teilmenge - die Posix-Capabilities - tröpfchenweise und mit vielen
Problemen (sowohl was Sicherheit als auch was Performance betrifft)
übernahm, da offensichtlich vorher das Gesamtkonzept niemals richtig
überdacht worden war.

Es gab auch vor Linux eine Möglichkeit die Maschinen zu virtualisieren/
aufzuteilen, und auch sonst vieles. Aber das ist heute eine historische
Randnotiz, Solaris ist tot.

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

Post by Martin Vaeth
In dem Fall liegt
das Problem nicht bei Linux (TIPC ist dort schon lange verfügbar),
sondern ganz klar am NIH-Syndrom von systemd, die natürlich auch die
Probleme von dbus sahen, aber statt TIPC zu nutzen (oder ggf. um ein
paar von ihnen benötigte Features zu erweitern) unbedingt zusätzlich
einen minderwertigen TIPC-Clone in den Kernel drücken wollten, was
glücklicherweise gescheitert ist.

dbus kommt ja glaub ich eher aus der Gnome/KDE-Ecke, weniger aus der
systemd-Ecke, aber ich kann mich täuschen. dbus hat ja einige Vorläufer
gehabt, bis hin zu irgendwelchen hochkomplexen CORBA-Architekturen, die
man dann bei Gnome 2.0 oder so wieder langsam rausprogrammiert hat. dbus
dürfte schon Sinn haben, da haben sich auch KDE und Gnome auf was
geeinigt, und das ist schon die 2. oder 3. Iteration der gleichen Idee,
soweit ich weiß, wo man halt jedes mal die Fehler ausgemerzt hat, die in
der Praxis aufgetreten sind.

Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Post by Martin Vaeth
Deswegen kommen immer wieder neue Releases des Posix-Standards heraus.
Ich vermute mal, wenn Posix nicht zumindest die wichtigsten Capabilities
standardisiert hätte, gäbe es bei Linux vermutlich immer noch gar keine,
oder noch schlechtere als jetzt.

Kommen noch Posix-Standards raus? Ich hab nicht das Gefühl, dass das
noch viel Relevanz hat. Das meiste in Posix standardisierte dürfte
implementiert sein, vieles scheint schlicht handwerklich schlecht
gemacht (Zeitzonen/Schaltsekunden) und wird ignoriert, hat nicht heute
viel mehr Gewicht wenn sich RedHat und Ubuntu auf was einigen, oder
meinetwegen freedesktop.org, oder Poettering was in systemd einbaut?
Wenn Apple, RedHat und Cannonical sich auf was einigen, dann
wär mir das definitiv lieber als alles an Posix. Leider ist das gefühlt
gerade mit Apple oft ein Problem.

/ralph

[Michael Bäuerle]

Post by Ralph Aichinger

Post by Martin Vaeth
[...]
Deswegen kommen immer wieder neue Releases des Posix-Standards heraus.
Ich vermute mal, wenn Posix nicht zumindest die wichtigsten Capabilities
standardisiert hätte, gäbe es bei Linux vermutlich immer noch gar keine,
oder noch schlechtere als jetzt.

Kommen noch Posix-Standards raus?

Die nächste Version steht kurz davor fertig zu werden.

Post by Ralph Aichinger
Ich hab nicht das Gefühl, dass das noch viel Relevanz hat.

Leider.

Post by Ralph Aichinger
Das meiste in Posix standardisierte dürfte
implementiert sein, vieles scheint schlicht handwerklich schlecht
gemacht (Zeitzonen/Schaltsekunden) und wird ignoriert, hat nicht heute
viel mehr Gewicht wenn sich RedHat und Ubuntu auf was einigen, oder
meinetwegen freedesktop.org, oder Poettering was in systemd einbaut?
Wenn Apple, RedHat und Cannonical sich auf was einigen, dann
wär mir das definitiv lieber als alles an Posix. Leider ist das gefühlt
gerade mit Apple oft ein Problem.

Und auch dort aus dem gleichen Grund: vendor lock-in.

Solange die Kunden das akzeptieren, und keine kompatible Lösung
fordern, wird das so bleiben.

[Ralph Aichinger]

Post by Michael Bäuerle

Post by Ralph Aichinger
Kommen noch Posix-Standards raus?

Die nächste Version steht kurz davor fertig zu werden.

Und Höhepunkte?

Post by Michael Bäuerle
Und auch dort aus dem gleichen Grund: vendor lock-in.
Solange die Kunden das akzeptieren, und keine kompatible Lösung
fordern, wird das so bleiben.

Bei Apple gibt es sicher vendor lock-in aber, ich vermute, dass der
Unix-Unterbau so stiefmütterlich behandelt wird ist einfach nur darin
begründet, dass sie halt damit durchkommen.

Aber das Linux-Ökosystem rauft sich doch soweit zusammen, dass
gemeinsame Errungeschaften irgendwann mal überall verfügbar werden. Ich
kann mich zumindest an nix erinnern, das man nur unter Ubuntu machen
könnte oder nur unter RedHat bzw. den jeweiligen Derivaten/Upstreams wie
Debian.

/ralph

[Michael Bäuerle]

Post by Ralph Aichinger

Post by Michael Bäuerle

Post by Ralph Aichinger
Kommen noch Posix-Standards raus?

Die nächste Version steht kurz davor fertig zu werden.

Und Höhepunkte?

Es geht dabei nicht um neue Features. Dinge, welche seit Jahren oder
Jahrzehnten verwendet werden, sollen ein genormtes Verhalten bekommen,
so dass sie auf allen OS gleich (und nicht nur ähnlich) funktionieren.

Das vereinfacht es Software auf ein anderes OS zu portieren bzw. gleich
so zu entwickeln, dass sie nicht OS-spezifisch ist.
Man muss das natürlich zuerst überhaupt wollen, siehe vendor lock-in.

Im nächsten Release soll z.B. gettext genormt werden.

[Ralph Aichinger]

Post by Michael Bäuerle
Es geht dabei nicht um neue Features. Dinge, welche seit Jahren oder
Jahrzehnten verwendet werden, sollen ein genormtes Verhalten bekommen,
so dass sie auf allen OS gleich (und nicht nur ähnlich) funktionieren.

Ja eh, was sind die Höhepunkte dieser Standardisierung?

Auf Wikipedia liest es sich so, als wäre in Posix seit 2007 oder 2008
nur mehr kleine Fehlerbehebungen eingeflossen.

Wird z.B. was bezüglich Containern standardisiert?

Post by Michael Bäuerle
Das vereinfacht es Software auf ein anderes OS zu portieren bzw. gleich
so zu entwickeln, dass sie nicht OS-spezifisch ist.
Man muss das natürlich zuerst überhaupt wollen, siehe vendor lock-in.

Welches OS könnte das sein?

Post by Michael Bäuerle
Im nächsten Release soll z.B. gettext genormt werden.

Wow, gettext zu normen ist sicher sinnvoll, meine ersten Erinnerungen an
AIX, Solaris und Konsorte sind, dass man zuerst immer geflucht hat, und
dann irgendeine bash die gegen readline gelinkt war installiert hat.
Gettext vermutlich ähnlich.

Aber seriously, das hätte man doch schon vor 20 Jahren machen können?
Der erste Release von gettext war 1990 laut Wikipedia? Bleeding edge
stuff.

Solange da nichts zu aktuellen Themen wie Containern, BPF, Flatpak/snap,
etc. standardisiert wird, wird das niemand mehr groß kratzen.

Würde POSIX z.B. deb vs. rpm, Flatpak vs. snap standardisieren, *das*
hätte Sinn. Ja, können sie natürlich nicht, aber *das* hätte Sinn.

/ralph

[Alexander Schreiber]

Post by Ralph Aichinger

Post by Martin Vaeth
Andersrum wird ein Schuh draus: Solaris beispielsweise hatte schon lange
ein gut durchdachtes Capabilities-System, während Linux nur eine
Teilmenge - die Posix-Capabilities - tröpfchenweise und mit vielen
Problemen (sowohl was Sicherheit als auch was Performance betrifft)
übernahm, da offensichtlich vorher das Gesamtkonzept niemals richtig
überdacht worden war.

Es gab auch vor Linux eine Möglichkeit die Maschinen zu virtualisieren/
aufzuteilen, und auch sonst vieles. Aber das ist heute eine historische
Randnotiz, Solaris ist tot.

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

Also hier sind die ersten Treffer für (google "TIPC"):
- https://www.kernel.org/doc/html/next/networking/tipc.html
- https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication
kommt aus der Cluster Ecke.

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Nicht jeder braucht den ganzen Desktop-Kram unbedingt. Meinereiner
ist nach wie vor mit WindowMaker + einem ganzen Sack voller xterms
(und Chrome-windows) zufrieden. Aber ich bin auch nicht die Zielgruppe
für GNOME, KDE& Co.

Man liest sich,
Alex.

[Stefan Reuther]

Post by Alexander Schreiber

Post by Ralph Aichinger

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

- https://www.kernel.org/doc/html/next/networking/tipc.html
- https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication
kommt aus der Cluster Ecke.

Also, wenn ich das richtig lese, eine Linux-only-Lösung.

Was *das* wieder für ein Geschrei bzgl. vendor lock-in gegeben hätte.
D-Bus gibt's auch anderswo.

Post by Alexander Schreiber
Nicht jeder braucht den ganzen Desktop-Kram unbedingt. Meinereiner
ist nach wie vor mit WindowMaker + einem ganzen Sack voller xterms
(und Chrome-windows) zufrieden. Aber ich bin auch nicht die Zielgruppe
für GNOME, KDE& Co.

Die Desktops sind inzwischen gut genug, dass mir fast egal ist, welchen
ich benutze. Daheim (glaube ich) KDE, auf Arbeit (glaube ich) LXDE. So
Sachen wie "beim Einstecken eines USB-Sticks ein Popup" sind halt schon
hübsch.


Stefan

[Martin Vaeth]

Post by Stefan Reuther

Post by Alexander Schreiber

Post by Ralph Aichinger
TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

- https://www.kernel.org/doc/html/next/networking/tipc.html
- https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication
kommt aus der Cluster Ecke.

Also, wenn ich das richtig lese, eine Linux-only-Lösung.

Keineswegs. Erstens ist es eben vor allem ein Protokoll.
Und dafür, dass es noch nicht allzu verbreitet ist, ist die
Anzahl der Implementierungen nicht allzu übel.
Neben Linux mindestens noch VxWorks und Solaris:
https://docs.oracle.com/cd/E19282-01/E20948-01/chap10_TIPC.html
Ich vermute mal, man könnte es (mit Geschwindigkeitsabstrichen)
sogar betriebssystemunabhängig implementieren, aber
Geschwindigkeitsverlust ist bei einem Cluster-Protokoll halt
ein wichiges Thema.

[Alexander Schreiber]

Post by Stefan Reuther

Post by Alexander Schreiber

Post by Ralph Aichinger

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

- https://www.kernel.org/doc/html/next/networking/tipc.html
- https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication
kommt aus der Cluster Ecke.

Also, wenn ich das richtig lese, eine Linux-only-Lösung.

Oracle ist da anderer Meinung:
https://docs.oracle.com/cd/E19282-01/E20948-01/chap10_TIPC.html

Post by Stefan Reuther

Post by Alexander Schreiber
Nicht jeder braucht den ganzen Desktop-Kram unbedingt. Meinereiner
ist nach wie vor mit WindowMaker + einem ganzen Sack voller xterms
(und Chrome-windows) zufrieden. Aber ich bin auch nicht die Zielgruppe
für GNOME, KDE& Co.

Die Desktops sind inzwischen gut genug, dass mir fast egal ist, welchen
ich benutze. Daheim (glaube ich) KDE, auf Arbeit (glaube ich) LXDE. So
Sachen wie "beim Einstecken eines USB-Sticks ein Popup" sind halt schon
hübsch.

USB Massstorage ist @$WORK bewusst abgeklemmt ;-)

Und privat will ich solche Automatismen auch nicht haben.

Man liest sich,
Alex.

[Stefan Reuther]

Post by Martin Vaeth

Post by Stefan Reuther

Post by Alexander Schreiber
- https://www.kernel.org/doc/html/next/networking/tipc.html
- https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication
kommt aus der Cluster Ecke.

Also, wenn ich das richtig lese, eine Linux-only-Lösung.

https://docs.oracle.com/cd/E19282-01/E20948-01/chap10_TIPC.html

Dann hat die Wiki-Seite Verbesserungspotenzial:

# Transparent Inter Process Communication (TIPC) is an inter-process
# communication (IPC) service in Linux designed for cluster-wide
# operation

Post by Martin Vaeth

Post by Stefan Reuther

Post by Alexander Schreiber
Nicht jeder braucht den ganzen Desktop-Kram unbedingt. Meinereiner
ist nach wie vor mit WindowMaker + einem ganzen Sack voller xterms
(und Chrome-windows) zufrieden. Aber ich bin auch nicht die Zielgruppe
für GNOME, KDE& Co.

Die Desktops sind inzwischen gut genug, dass mir fast egal ist, welchen
ich benutze. Daheim (glaube ich) KDE, auf Arbeit (glaube ich) LXDE. So
Sachen wie "beim Einstecken eines USB-Sticks ein Popup" sind halt schon
hübsch.

Geht in meinem Job nicht :)

Post by Martin Vaeth
Und privat will ich solche Automatismen auch nicht haben.

Der Witz am Popup ist ja, dass ich eine Wahl treffen kann, bevor was
passiert.

"/dev/sr0 /cdrom iso9660 user,noauto 0 0" oder das Äquivalent für
Floppies hat ja früher noch ganz brauchbar funktioniert, um als Nutzer
mit Wechselmedien arbeiten zu können.

Aber "/dev/sdb1 /stick vfat user,noauto 0 0" skaliert halt einfach
nicht. Was, wenn der Stick als Superfloppy (ohne Partitionstabelle)
kommt? Oder zwei Partitionen? Was, wenn der Stick NTFS hat? Was, wenn
ich *zwei* Sticks habe?

Und Automounter hatte Solaris vor 30 Jahren schon, ist also kein
neumodischer Linux-Schnickschnack.


Stefan

[Sieghard Schicktanz]

Hallo Stefan,

Post by Stefan Reuther
Die Desktops sind inzwischen gut genug, dass mir fast egal ist, welchen

Mir auch, ich benutze garkeinen.

Post by Stefan Reuther
Sachen wie "beim Einstecken eines USB-Sticks ein Popup" sind halt schon
hübsch.

Und bei jedem Desktop anders, und "gelgentlich" nicht von der Konsole aus
sichtbar (hatte ich zumindest mal). Und was besonderes ist das auch nicht,
mit ein paar Skripterln und dem guten alten "autofs" läuftt das bei mir
hier ganz ähnlich, aber dafür genau _so_ (un)aufdringlich, wie mir das noch
erträglich ist. Undd das läuft auch _ganz ohne_ Desktopp und hat sogar noch
die Möglichkeit, daß der USB-Stick (o.a.) automatisch auch wieder
"ausgeworfen" (abgemeldet) wird, wenn er länger nicht benutzt wurde.
Dazu braucht's keinen Desktopp.

[Stephan Seitz]

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Und kommen dir immer in die Quere beim Arbeiten. Ich kenne daher
keinen, der diesen Müll freiwillig benutzt. XFCE oder andere einfache
Umgebungen. Ich kenne auch noch fvwm-Benutzer. Die können ihre
jahrzehnte alte Konfigurationsdatei problemlos umherkopieren und sind
dann fertig.

Stephan

[Ralph Aichinger]

Post by Stephan Seitz
Und kommen dir immer in die Quere beim Arbeiten. Ich kenne daher
keinen, der diesen Müll freiwillig benutzt.

Ich benutze Gnome sehr gerne, wobei ich vermute, dass ich mit etwas
Umgewöhnungszeit auch mit KDE gut zurechtkommen würde.

/ralph

[Andreas M. Kirchwitz]

Post by Stephan Seitz

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Und kommen dir immer in die Quere beim Arbeiten. Ich kenne daher
keinen, der diesen Müll freiwillig benutzt. XFCE oder andere einfache
Umgebungen. Ich kenne auch noch fvwm-Benutzer. Die können ihre
jahrzehnte alte Konfigurationsdatei problemlos umherkopieren und sind
dann fertig.

Inzwischen FVWM3, wird sogar noch erfreulich aktiv entwickelt,
doch der für mich wichtigste Punkt ist, dass ich mir die
Handhabung so einstellen kann, wie es für meinen Arbeitsfluss
am besten ist. Geht mit vielen anderen Window-Managern ja auch,
das ist schließlich die Idee dahinter, jeder nach seinem ganz
persönlichen Geschmack.

Bei GNOME wundere ich mich immer wieder, welche extreme Manpower
da seit Jahren reinfließt, jedoch das gesamte Handling ist so
unfassbar starr, friss oder stirb, Konfigurierbarkeit so gut
wie nicht vorhanden. Bei GNOME bejubeln sie immer wieder neue
Features, die ich schon im letzten Jahrtausend genutzt habe
mit FVWM*/X11. GNOME verbraucht dann auch noch extreme Mengen
von CPU und RAM. Was treiben die da eigentlich?

KDE benutze ich nur wenig. Das bietet immerhin von sich aus
eine gewisse Flexibilität und Individualität, aber das ist
auch so ein Riesenschiff, bei dem ich nicht verstehe, wofür
eigentlich.

Na ja, so ist eben der Lauf der Dinge. Der alte Unix-Geist
ist längst dahin. Und seit Ansible und Kubernetes weiß eh
keiner der nachwachsenden ITler mehr, wie Unix überhaupt
funktioniert. Programmieren kann seit Jahren auch keiner
mehr richtig.

Doch das Lustige ist, das habe ich mir damals ähnlich anhören
müssen, dass ich ein Pfuscher bin, weil ich in C programmiere
statt Assembler und weil ich GUI benutze statt Text-Konsole. :-)

Der natürliche Lauf des Lebens ... Andreas

[Alexander Schreiber]

Post by Andreas M. Kirchwitz
Na ja, so ist eben der Lauf der Dinge. Der alte Unix-Geist
ist längst dahin. Und seit Ansible und Kubernetes weiß eh
keiner der nachwachsenden ITler mehr, wie Unix überhaupt
funktioniert. Programmieren kann seit Jahren auch keiner
mehr richtig.

Was ich derzeit von Kandidaten in den "Unix/Linux internals"
Interviews höre ist einfach nur noch grauslig. Keine Ahnung,
davon aber jede Menge.

Man liest sich,
Alex.

[Marc Olschok]

Post by Stephan Seitz

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Und kommen dir immer in die Quere beim Arbeiten. Ich kenne daher
keinen, der diesen Müll freiwillig benutzt. XFCE oder andere einfache
Umgebungen. Ich kenne auch noch fvwm-Benutzer. Die können ihre
jahrzehnte alte Konfigurationsdatei problemlos umherkopieren und sind
dann fertig.

Beruhigend, dass ich nicht der einzige bin. Tatsächlich habe ich schon öfter
von Kollegen gehört "Egal, was man Dir für einen Rechner gibt, nach kurzer
Zeit sehen die alle gleich aus".

v.G.

[Marc Haber]

Post by Marc Olschok

Post by Stephan Seitz

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Und kommen dir immer in die Quere beim Arbeiten. Ich kenne daher
keinen, der diesen Müll freiwillig benutzt. XFCE oder andere einfache
Umgebungen. Ich kenne auch noch fvwm-Benutzer. Die können ihre
jahrzehnte alte Konfigurationsdatei problemlos umherkopieren und sind
dann fertig.

Beruhigend, dass ich nicht der einzige bin. Tatsächlich habe ich schon öfter
von Kollegen gehört "Egal, was man Dir für einen Rechner gibt, nach kurzer
Zeit sehen die alle gleich aus".

Meinten die Kollegen nicht vielleicht den Zustand der Abgeranztheit?

Bei mir ist ein Notebook auch maximal einen Monat lang "neu".

Grüße
Marc

[Ralph Aichinger]

Post by Marc Haber
Meinten die Kollegen nicht vielleicht den Zustand der Abgeranztheit?
Bei mir ist ein Notebook auch maximal einen Monat lang "neu".

Das muß so sein. Ich bewundere Leute, die auf Geräten wirklich arbeiten
und sie in einem annähernden Neuzustand halten. Wobei sicher auch putzen
manchmal einen Unterschied macht, ich hab mein Surface zu Microsoft
geschickt, und hab anhand der Seriennummer kontrollieren müssen, ob ich
ein neues oder "meines" zurückbekommen habe, vermutlich hat man den
Bildschirm irgendwie perfekt sauber gemacht und auch das Alcantara
irgendwie abgewischt. So sauber hab ich das Ding jedenfalls nicht
eingeschickt.

/ralph

[Martin Vaeth]

Post by Ralph Aichinger

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

https://www.kernel.org/doc/html/next/networking/tipc.html

Post by Ralph Aichinger
dbus kommt ja glaub ich eher aus der Gnome/KDE-Ecke

Gnome. Ja, Gnome hat sich aufgrund des XML-Hypes seinerzeit entschlossen
von dem anscheinend ganz guten Binärprotoll COBRA auf das schlecht zu
parsende XML-Protokoll dbus umzusteigen, um dann nach vollzogenem Umstieg
festzustellen, dass dieser Krampf für die unter COBRA noch mögliche Audio-
und Videoübertragung ungeeignet ist, da durch das notwendige
Konvertieren der Daten zu langsam.
Statt den Design-Fehler einzuräumen oder rückgängig zu machen, wurde
versucht, den Kernel aufzubohren, um die konzeptionelle Langsamkeit zu
"reparieren".

Post by Ralph Aichinger
weniger aus der systemd-Ecke

Das sind i.W. die selben Leute. systemd hat von Anfang an auf dbus
gesetzt. Insbesondere kann man bei einem von systemd gebooteten
System mit dbus eben den Prozess der PID 1 kontrollieren, was der
Hauptgrund ist, weshalb die Komplexität von systemd eben so eine
Sicherheitskatastrophe ist: Irgendein geeigneter Exploit in *einer*
der vielen Libraries reicht aus, und der Angreifer bekommt gleich
die Kontrolle über PID 1.

Wenig überraschend ist dieses Komplexitäts-Sicherheitsproblem von
systemd, vor dem viele warnten und dafür (auch hier) als Hater
diffamiert wurden, natürlich genau das, auf das sich die bösen
Buben stürzen: Der xz Angriff hätte ohne die Ausnutzung dieser
systemd-Schwäche nicht funktioniert.

Insofern ist das systemd-sudo (oder wie immer das heißt) statt sudo
schon konsequent, weil es nur das ohnehin durch systemd geschaffene
klaffende Sicherheitsloch benutzt und nicht noch zusätzlich den
SUID-Angriffsvektor öffnet.

Bei einem System, das nicht mit systemd gebootet wurde, ist
der SUID-Angriffsvektor als einzige Möglichkeit der Privilegerhöhung
natürlich als viel überblickbarere Alternative vorzuziehen. Aber
diese Tatsache können die Systemd-Macher natürlich nicht gelten
lassen - es würde ja die Schwäche von systemd offenbar - und müssen
sie deswegen als "nicht mehr zeitgemäß" diffamieren.
Ja, "zeitgemäß" ist leider in der Tat das viel größere
Sicherheitsrisiko systemd.

Post by Ralph Aichinger
Letztendlich sind aktuelles KDE und Gnome unvergleichlich featurereicher
als alles andere, was es außerhalb von MacOS oder Android auf Unix
jemals als Desktop gegeben hat, also dürften sie was richtig machen.

Weder Gnome noch KDE haben das Problem mit der Übertragung von
Video und Audio lösen können. Das hat erst pipewire Jahre später
getan, indem es ein eigenes Protokoll geschaffen hat. Das klingt
also eher doch nicht so, als wenn Gnome oder KDE mit dem dbus
Protokoll etwas richtig gemacht hätten.

Die Anzahl der Features ist auch weniger ein Indiz für eine
Qualität sondern eher für eine Komplexität. Überigens fällt
Gnome (im Gegensatz zu KDE) eher durch Featureabbau auf als
durch Hinzufügen neuer. Aber das ist ein anderes Thema.

Post by Ralph Aichinger
Kommen noch Posix-Standards raus?

Darauf wurde ja bereits geantwortet.

Post by Ralph Aichinger
Ich hab nicht das Gefühl, dass das noch viel Relevanz hat.
[...] hat nicht heute viel mehr Gewicht wenn sich RedHat und Ubuntu
auf was einigen, oder meinetwegen freedesktop.org, oder Poettering
was in systemd einbaut?

Leider. Wie so oft sind Marktmacht und Qualität mal wieder
Gegensätze.

Post by Ralph Aichinger
Das meiste in Posix standardisierte dürfte implementiert sein

Posix standardisiert normalerweise das, was bereits auf vielen
Systemen implementiert *ist*.
Nur in ganz wenigen Fällen, in denen die Implementierungen gar zu
schrecklich zurückfallen, übernimmt Posix eine Vorreiterrolle,
und das ist in jedem dieser Fälle stark umstritten.

In Linux ist vieles von Posix nicht implementiert: Der Mangel
an Posix-zertifizierten Linux-Systemen liegt nicht nur an den
Zertifizierungskosten. Schon die (leider) verbreitetste
Linux-Shell bash hat nicht die von Posix geforderdeten Features.

Post by Ralph Aichinger
vieles scheint schlicht handwerklich schlecht gemacht
(Zeitzonen/Schaltsekunden)

Das kann ich gerade in diesem Beispiel nicht bestätigen.
Das damit verbundene Problem *ist* einfach (politisch) zu
komplex.

[Kay Martinen]

Post by Ralph Aichinger

Post by Martin Vaeth
Andersrum wird ein Schuh draus: Solaris beispielsweise hatte schon lange
ein gut durchdachtes Capabilities-System, während Linux nur eine
Teilmenge - die Posix-Capabilities - tröpfchenweise und mit vielen
Problemen (sowohl was Sicherheit als auch was Performance betrifft)
übernahm, da offensichtlich vorher das Gesamtkonzept niemals richtig
überdacht worden war.

Es gab auch vor Linux eine Möglichkeit die Maschinen zu virtualisieren/
aufzuteilen, und auch sonst vieles.

Denkst du da in Richtung Chroot + Extras, meinst du Container wie Docker
o.a. oder echte Virtualisierung ganzer Maschinen? Ich hab auf einem
Nicht-VT Tauglichen System mal kurz Paravirtualisierung (Nannte sich IMO
bare-Metal VM o.ä.) probiert. War ganz schön lahm. Und bei Großrechnern
nennt man's IMO Partitionierung oder LPAR. DAS gab's sicher schon vor
den Versuchen auf dem PC.

Post by Ralph Aichinger

Post by Martin Vaeth
Ähnlich sieht es wohl mit Protokollen wie TIPC aus, das es schon lange
vor dbus gab und wohl bei weitem überlegen war.

TIPC sagt mir gar nix, und das Akronym läßt sich auch nicht leicht
googeln.

Frag Wikipedia! Bei der DE-Version springt als erstes Transparente
Interprozess Kommunikation heraus. Immerhin mit einer Kurzerklärung.

Aber die hilft mir leider auch nicht zu verstehen wozu man IPC über
host-grenzen hinweg brauchen sollte. Vielleicht habe ich nur keinen
Anwendungsfall dazu wie Verteiltes Rechnen oder x gleiche Prozesse auf Y
Maschinen die alle an Aufgabe Z arbeiten...

Braucht man TIPC in einem normalen Privaten LAN für irgendwas zwischen
Hosts? dbus ist doch m.W. auch nur Hostonly oder? So weit ich das
verstehe mach dbus doch IPC auf dem Host.

Post by Ralph Aichinger
Kommen noch Posix-Standards raus? Ich hab nicht das Gefühl, dass das
noch viel Relevanz hat. Das meiste in Posix standardisierte dürfte
implementiert sein, vieles scheint schlicht handwerklich schlecht
gemacht (Zeitzonen/Schaltsekunden) und wird ignoriert, hat nicht heute
viel mehr Gewicht wenn sich RedHat und Ubuntu auf was einigen, oder
meinetwegen freedesktop.org, oder Poettering was in systemd einbaut?
Wenn Apple, RedHat und Cannonical sich auf was einigen, dann
wär mir das definitiv lieber als alles an Posix. Leider ist das gefühlt
gerade mit Apple oft ein Problem.

Bei Apple liegt es wohl an ihrem Ökosystem das sie ungern öffnen aber
früher war gefühlt eher Microsoft das Problem. Das sie eben etwas
machten das einfach Standards ignoriert. Wenn das Ziel war ein
geschlossenes Windows-Ökosystem zu schaffen dann sind sie damit nicht so
erfolgreich gewesen wie Apple.

Und Red Hat oder Canonical sind prinzipiell Linux-bezogen. So mixt eben
jeder seine Karten wie's ihm beliebt.

Bye/
/Kay

[Kay Martinen]

Post by Ralph Aichinger

Post by Michael Bäuerle
Wenn man unterstellt, dass vendor lock-in hinzugefügt werden soll,
dann ist das genau so gewünscht. Du sollst nichts anderes verwenden,
insbesondere kein anderes OS.

Das ist die eine Sichtweise.

Und naheliegen. Wurde nicht hierZuThread schon angemerkt das die Klare
Ansage besteht systemd wird es NUR für Linux geben. Damit sind alle
Nicht-Linux OS dann ausgesperrt. Vendor=Linux ist zwar immer noch eine
Große Teilmenge von All-OS aber eben nur eine TEILmenge.

Post by Ralph Aichinger
Die andere Sichtweise: Linux entwickelt sich halt weiter, bekommt neue
Features, während andere Unices letztendlich irgendwo oft auf einem Stand
stehengeblieben sind, auf dem Linux ca. 2000 war, und sich nur mehr
langsam durch übernehmen von Linux-Features mit Verspätung von Jahren
oder Jahrzehnten weiterentwickeln[1].

Okay. Annahme: Wenn man all die Features und neuen Entwicklungen (bei
Linux o.a.) in ein Beliebte Unix implementierte - wäre es DANN noch ein
Standard-Unix? IMHO legen die Unix-Leute gesteigerten Wert daraus das
ein Unix ein Unix ist und dazu gehören wohl bestimmte Faktoren. Und
AFAIR auch ein Standard oder solcher Prozeß.

Post by Ralph Aichinger
Wenn man da immer nach dem kleinsten gemeinsamen Nenner geht, dann
müssen wir ewig bei 640k und 8.3-Dateinamen bleiben, oder so.

IMHO war schon bei der Gates'schen Ansage mehr RAM möglich und wurde
auch genutzt, die CPU (8086) konnte da schon 1MB. Und 8.3 naja,
Limitierung des Dateisystems - welches man austauschen könnte.

Out-of-Bounds: Der C-64 konnte zwar nur per Bankswitching mehr RAM > 64k
aber auf der Floppy konnte er AFAIR 16 Zeichen lange Dateinamen. Plus
Typ-Angabe (PRG, SEQ, REL) Das wurde allerdings vom FloppyDOS gemanaged
und PCs hatten ja nur Dumme Laufwerke die nicht mal Track 0 selbst
fanden wenn sie keine Step-Impulse bekamen.

Du hättest auch die Limits eines 32-Bit Prozessors wählen können. :)
Aber da wär's dann nicht mehr so einfach denn da laufen deutlich
"fortschrittlichere" sachen drauf als 640k und 8.3. Hat halt die
Segment-register geerbt und nennt sie nun Selektoren die auch noch luft
nach oben hatten. Ich sach nur "Granularity-Bit".

Post by Ralph Aichinger
[1] Ausnahme natürlich MacOS

Launchd und ein Goldener Käfig drumherum? Toller Fortschritt. ;-/

Bye/
/Kay

[Marc Haber]

Post by Kay Martinen
Und naheliegen. Wurde nicht hierZuThread schon angemerkt das die Klare
Ansage besteht systemd wird es NUR für Linux geben. Damit sind alle
Nicht-Linux OS dann ausgesperrt. Vendor=Linux ist zwar immer noch eine
Große Teilmenge von All-OS aber eben nur eine TEILmenge.

systemd ergibt nur Sinn mit den Features eines Linux-Kernels
untendrunter. Diesen Standpunkt kann ich gut verstehen.

Post by Kay Martinen
Okay. Annahme: Wenn man all die Features und neuen Entwicklungen (bei
Linux o.a.) in ein Beliebte Unix implementierte - wäre es DANN noch ein
Standard-Unix? IMHO legen die Unix-Leute gesteigerten Wert daraus das
ein Unix ein Unix ist und dazu gehören wohl bestimmte Faktoren. Und
AFAIR auch ein Standard oder solcher Prozeß.

Was ist ein Standard-Unix? Ein System mit 0,2 % Marktanteil. Der
Löwenanteil ist Linux.

Post by Kay Martinen
IMHO war schon bei der Gates'schen Ansage mehr RAM möglich und wurde
auch genutzt, die CPU (8086) konnte da schon 1MB. Und 8.3 naja,
Limitierung des Dateisystems - welches man austauschen könnte.

Und dann zehn Jahre sptäer auch ausgetauscht hat.

Grüße
Marc

[Kay Martinen]

Post by Marc Haber

Post by Kay Martinen
Und naheliegen. Wurde nicht hierZuThread schon angemerkt das die Klare
Ansage besteht systemd wird es NUR für Linux geben. Damit sind alle
Nicht-Linux OS dann ausgesperrt. Vendor=Linux ist zwar immer noch eine
Große Teilmenge von All-OS aber eben nur eine TEILmenge.

systemd ergibt nur Sinn mit den Features eines Linux-Kernels
untendrunter. Diesen Standpunkt kann ich gut verstehen.

Schon richtig. Aber wenn das die Konditionen sind gibt es für andere OS
doch nur eine Option und die ist eben die folgende...

Post by Marc Haber

Post by Kay Martinen
Okay. Annahme: Wenn man all die Features und neuen Entwicklungen (bei
Linux o.a.) in ein Beliebte Unix implementierte - wäre es DANN noch ein
Standard-Unix? IMHO legen die Unix-Leute gesteigerten Wert daraus das
ein Unix ein Unix ist und dazu gehören wohl bestimmte Faktoren. Und
AFAIR auch ein Standard oder solcher Prozeß.

Was ist ein Standard-Unix? Ein System mit 0,2 % Marktanteil. Der
Löwenanteil ist Linux.

Keine Ahnung was ein Standard-Unix zum Standard macht aber ich hab mit
Unix doch nicht angefangen, nur dies als Beispiel mit einbezogen.

Warum benutzt jemand Slackware, oder andere OS die wenig Verbreitung
haben? Irgend einen Grund wird's schon geben.

Schließlich ist der erste Grund auf einen Berg zu steigen ja auch (nur):

WEIL ER DA IST. ;-)

Und nein, ich bin kein Bergsteiger.

Post by Marc Haber

Post by Kay Martinen
IMHO war schon bei der Gates'schen Ansage mehr RAM möglich und wurde
auch genutzt, die CPU (8086) konnte da schon 1MB. Und 8.3 naja,
Limitierung des Dateisystems - welches man austauschen könnte.

Und dann zehn Jahre sptäer auch ausgetauscht hat.

Und CPU und RAM sind auch schneller und Größer geworden ja. Ist das
jetzt ein Grund pro oder Kontra neues init-system, tool, OS, whatever?

Ich denke wenn man wollte könnte man auch mit 640k und 8.3 ein
Multitasking-Multiuser OS schaffen - mit irgend einem init.

Hmm, ich denke auch das ist bereits passiert!

Bye/
/Kay

[Marc Haber]

Post by Kay Martinen

Post by Marc Haber

Post by Kay Martinen
IMHO war schon bei der Gates'schen Ansage mehr RAM möglich und wurde
auch genutzt, die CPU (8086) konnte da schon 1MB. Und 8.3 naja,
Limitierung des Dateisystems - welches man austauschen könnte.

Und dann zehn Jahre sptäer auch ausgetauscht hat.

Und CPU und RAM sind auch schneller und Größer geworden ja. Ist das
jetzt ein Grund pro oder Kontra neues init-system, tool, OS, whatever?
Ich denke wenn man wollte könnte man auch mit 640k und 8.3 ein
Multitasking-Multiuser OS schaffen - mit irgend einem init.
Hmm, ich denke auch das ist bereits passiert!

Die Welt entwickelt sich halt weiter. Und wie gesagt, ich bin sehr
froh dass ich keine Initscripte mehr schreiben und testen muss, und
ich bin mir sicher, dass ich die Sicherheitsfeatures, die ich
inzwischen in jeder systemd-Unit gewohnheitsmäßig verwende und IMMER
noch schneller bin als würde ich auch nur das simpelste initscript
schreiben, bis heute nicht benutzen würde, wenn ich immer noch
initscripts schreiben müsste.

Ich habe im letzten Jahr aide in Debian auf systemd-Mechanismen und
capabilities umgestellt, es läuft seitdem nicht mehr als root, und
weit mehr als 50 % der Arbeit war das Schreiben des "Scaffolding" (wie
sagt man das auf deutsch) für diejenigen, die sich gegen systemd timer
sperren.

Grüße
Marc

[Marc Haber]

Post by Michael Bäuerle

Post by Marco Moock

Post by Alexander Schreiber
Naja, sysvinit hat auch keinen Mangel an Warzen und systemd hat
durchaus sinnvolle Ideen umgesetzt. Nur diese langsame Vereinahmung
durch systemd Komponenten (mittlerweile habe ich wieder eine fixit
Liste nach der Systeminstallation, u.a. systemd-resolved stilllegen)
nervt zunehmend.

Was mir daran vor allem stinkt ist der Umstand, dass diese Sachen dann
Teil von systemd sind und auf anderen Systemen nicht eingesetzt werden
können. [...]

Wenn man unterstellt, dass vendor lock-in hinzugefügt werden soll,
dann ist das genau so gewünscht. Du sollst nichts anderes verwenden,
insbesondere kein anderes OS.

Du darfst gerne weiterhin sudo, runas oder super verwenden. Dieser
Thread ist wieder mal zu reinem unpassenden systemd-bashing entgleist.

[Stephan Seitz]

Post by Marc Haber
Du darfst gerne weiterhin sudo, runas oder super verwenden. Dieser
Thread ist wieder mal zu reinem unpassenden systemd-bashing entgleist.

Das ist genau das, was dieser Müll verdient.

Stephan

[Marc Haber]

Post by Stephan Seitz

Post by Marc Haber
Du darfst gerne weiterhin sudo, runas oder super verwenden. Dieser
Thread ist wieder mal zu reinem unpassenden systemd-bashing entgleist.

Das ist genau das, was dieser Müll verdient.

systemd ist die DB der Open Source Szene: Alle hacken drauf rum und
nutzen jede unpassende Gelegenheit, dabei gibt es so viele
Möglichkieten, fundiert darüber zu lästern.

[Paul Muster]

Post by Marc Haber
systemd ist die DB der Open Source Szene

Mit "DB" meint Marc die Deutsche Bahn. Nur, falls das irgendwem nicht
klar sein sollte.


mfG Paul

[Marco Moock]

Post by Paul Muster

Post by Marc Haber
systemd ist die DB der Open Source Szene

Mit "DB" meint Marc die Deutsche Bahn. Nur, falls das irgendwem nicht
klar sein sollte.

Ich dachte erst an Datenbank. Danke für die Erläuterung. :-)

[Peter Blancke]

Post by Marco Moock

Post by Paul Muster

Post by Marc Haber
systemd ist die DB der Open Source Szene

Mit "DB" meint Marc die Deutsche Bahn. Nur, falls das irgendwem nicht
klar sein sollte.

Ich dachte erst an Datenbank. Danke für die Erläuterung. :-)

Ich dachte an Detlev Bosau, wer den noch kennen sollte.

[Rolf Buenning]

Post by Peter Blancke

Post by Marco Moock

Post by Paul Muster

Post by Marc Haber
systemd ist die DB der Open Source Szene

Mit "DB" meint Marc die Deutsche Bahn. Nur, falls das irgendwem nicht
klar sein sollte.

Ich dachte erst an Datenbank. Danke für die Erläuterung. :-)

Ich dachte an Detlev Bosau, wer den noch kennen sollte.

Ich.

Rolf

[Marc Haber]

Post by Alexander Schreiber
Es gibt auch noch Unix ausserhalb der Pinguin-Farm ;-)

Keins mit meßbarer Verteilung außehalb seiner winzigen Nische.

Grüße
Marc

[Stefan Reuther]

Post by Marco Moock

Post by Paul Muster
Na, herzlichen Glückwunsch.

|Das ganze SUID-Konzept sei nicht mehr zeitgemäß und gehöre "auf den
|Haufen schlechter Unix-Ideen".
Warum macht der eigentlich nicht ein Poettering OS?
Ganz ohne UNIX-Ideen?

suid *ist* in Umgebungen heutiger Komplexität eine schlechte Idee. Das
ist prima, wenn man statisch gelinkte a.out Binaries hat, die möglichst
wenig tun. Aber in heutigen Umgebungen muss man halt jede Komponente
darauf abprüfen, dass sie sich in der suid-Umgebung korrekt benimmt,
beginnend mit dem dynamischen Loader und weiter über alle Libraries
(dynamisch geladene PAMs oder Kryptoalgorithmen?) und alle
möglicherweise gestarteten Prozesse. Sobald einer davon auf irgendeine
Eigenschaft der Nutzerumgebung reagiert, bevor man die gesäubert hat,
hat man ein Sicherheitsproblem.

Es ist schon immer eine gute Idee, neue Prozesse aus einem "known good"
Status zu forken statt aus einem bereits wild verunreinigten
Nutzerprozess. Einige Applikationen implementieren ähnliches, bei
Chromium wäre das z.B. der Zygote-Prozess. Und auf System-Ebene ist das
eben: Prozesse vom Servicemanager forken, nicht von der Shell.


Stefan

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Post by Paul Muster
| *Systemd-Alternative zu sudo soll Linux sicherer machen*
|
| run0 lässt reguläre Benutzer Programme mit root-Rechten ausführen.
Es | ähnelt sudo, nutzt aber andere Mechanismen zur
Privilegienerhöhung und | soll sicherer sein.

^^^^^^^^^^^^^^^^^^^ ?

Post by Marco Moock
|Das ganze SUID-Konzept sei nicht mehr zeitgemäß und gehöre "auf den
|Haufen schlechter Unix-Ideen".

Naja, schließlich beruht "sudo" ja auch nicht auf "Privilegienerhöhung",
sondern macht das Gegenteil: startet als "root" und gibt dann das Privileg
ab.

Post by Marco Moock
Warum macht der eigentlich nicht ein Poettering OS?
Ganz ohne UNIX-Ideen?

Wahrscheinlich har er dann gar keine Ideen mehr, dann kann er ja nix
_anders_ machen.

[Kay Martinen]

Post by Sieghard Schicktanz
Hallo Marco,

Post by Marco Moock

| *Systemd-Alternative zu sudo soll Linux sicherer machen* | |
run0 lässt reguläre Benutzer Programme mit root-Rechten
ausführen. Es | ähnelt sudo, nutzt aber andere Mechanismen zur
Privilegienerhöhung und | soll sicherer sein.

^^^^^^^^^^^^^^^^^^^ ?

Post by Marco Moock
|Das ganze SUID-Konzept sei nicht mehr zeitgemäß und gehöre "auf
den |Haufen schlechter Unix-Ideen".

Naja, schließlich beruht "sudo" ja auch nicht auf
"Privilegienerhöhung", sondern macht das Gegenteil: startet als
"root" und gibt dann das Privileg ab.

Ach, das Problem ist also das einer mittendrin sagen könnte "Ach sudo,
halt mal hier an, ich will als root aussteigen"? ;)

Auf wessen Haufen ist so eine Schlechte Idee bei Unix den gediehen?

Post by Sieghard Schicktanz

Post by Marco Moock
Warum macht der eigentlich nicht ein Poettering OS? Ganz ohne
UNIX-Ideen?

Wahrscheinlich har er dann gar keine Ideen mehr, dann kann er ja nix
_anders_ machen.

Müßte es dann nicht konsequenterweise *OtherOS* Heißen? ;)

IMO arbeitet er jetzt für MS. Dann wird Windows wohl bald auch einen
SYSTEMD.EXE bekommen... und TIMESYNCD.EXE, RESOLVED.EXE u.s.w.

Soll mir lieber sein, Win11, 12, 13 ist hier schon jetzt obsolet!

Bye/
/Kay

[Marc Haber]

Post by Paul Muster
Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und

Es ist eine weitere Alternative. Über super, runas und das dritte was
mir gerade nicht einfallen mag wird das auch nicht hinausgehen.

Grüße
Marc

[Paul Muster]

Post by Marc Haber

Post by Paul Muster
Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und

Es ist eine weitere Alternative.

Jaja, klar. Bis wichtige Pakete run0 als harte dependency bekommen. Ist
ja nicht so, als wäre das nicht schon zuvor mit Systemd als init-System
so passiert.


mfG Paul

[Marc Haber]

Post by Paul Muster

Post by Marc Haber

Post by Paul Muster
Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und

Es ist eine weitere Alternative.

Jaja, klar. Bis wichtige Pakete run0 als harte dependency bekommen.

Ja, und? Du wirst weiterhin sudo benutzen können wenn Du unbedingt von
meiner Arbeit profitieren möchtest ;-)

Post by Paul Muster
Ist
ja nicht so, als wäre das nicht schon zuvor mit Systemd als init-System
so passiert.

Das Initsystem muss man für das ganze System festlegen. Den Privilege
Escalator nicht.

[Tim Ritberg]

Post by Marc Haber
Ja, und? Du wirst weiterhin sudo benutzen können wenn Du unbedingt von
meiner Arbeit profitieren möchtest ;-)

Netter Versuch:
https://www.sudo.ws/about/contributors/

Tim

[Ralph Aichinger]

Post by Tim Ritberg
https://www.sudo.ws/about/contributors/

uploaders: Marc Haber [DMD] ??? Hilko Bengen [DMD] ??? Hanno Wagner [DMD] ??? Bastian Blank [DMD]

https://tracker.debian.org/pkg/sudo

/ralph

[Andreas M. Kirchwitz]

Post by Paul Muster
Uuuund weiter geht's mit der Übernahme etablierter Unix-Tools und
https://www.heise.de/news/Systemd-Alternative-zu-sudo-soll-Linux-sicherer-machen-9705458.html

Eigentlich traurig, dass man inzwischen eher in Panik gerät,
statt verzückt zu sein, wenn es Neuigkeiten von systemd gibt.

Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch
war jede Komponente gut überschaubar und verständlich.
Die Interaktion zwischen den Komponenten konnte vielleicht
manchmal holprig sein, aber das war eben der Job des Admins. :-)

Heutzutage ist systemd wie so ein Windows-System, das macht
alles für einen, man kann nicht so gut reinschauen, und wenn's
nicht tut, was man soll, installiert man eher alles neu, als
die Vorgänge zu verstehen, weil das System ja auch gar nicht
dafür ausgelegt ist, dass man ihm auf die Finger schaut.

Die jungen Leute finden's geil. Meine Welt ist es nicht mehr.
Ich muss es nur noch irgendwie bis zur Rente schaffen...

Mal schauen, vielleicht schaffe ich es ja auch noch, bis zu
meinem Ableben kein Wayland nutzen zu müssen. :-)

Post by Paul Muster
Na, herzlichen Glückwunsch. Ja, es kann schlechter werden also das
Original-sudo. Wir werden sehen.

Besser, schlechter... ach, wer wollte das immer beurteilen...
Linux entwickelt sich einfach zu einem anderen IT-Verständnis.

Weiß ja heutzutage auch niemand mehr, wie ein Webserver oder
Mailserver funktioniert. Da gibt's fertige Container, und wenn
was nicht geht, schmeißt man es weg und installiert andere
Container. Irgendeiner funktioniert schon.

"sudo" ist Shell. Shell verwenden nur noch alte weiße Männer.
Ob das später dann "run0" heißt, es ist bald niemand mehr da,
den es noch interessieren könnte.

Grüße, Andreas

[Hergen Lehmann]

Post by Andreas M. Kirchwitz
Eigentlich traurig, dass man inzwischen eher in Panik gerät,
statt verzückt zu sein, wenn es Neuigkeiten von systemd gibt.
Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch
war jede Komponente gut überschaubar und verständlich.

Mit Betonung auf "war".

In der heutigen Zeit mit ihren vielfältigen Bedrohungen genügt es
einfach nicht mehr, das irgendwer vor Jahrzehnten mal ein nützliches
Tool geschrieben hat, das einfach immer wieder kopiert wird. Jedes Tool
braucht ein Team von aktiven Maintainern, und deren Arbeit wiederum muss
irgendwer überwachen. Je mehr von diesen langweiligen alten nicht mehr
wirklich gepflegten Tools du im System hast, desto leichter passiert das
nächste XZ.

Vor diesem Hintergrund ist es nicht ganz falsch, die vielen kleinen
Teilfunktionalitäten einzusammeln und in einem "Über-Tool" zu vereinen.
Wenn dieses kontrovers ist, umso besser, denn dann schauen mehr Leute
kritisch hin.

[Marco Moock]

Post by Hergen Lehmann

Post by Andreas M. Kirchwitz
Eigentlich traurig, dass man inzwischen eher in Panik gerät,
statt verzückt zu sein, wenn es Neuigkeiten von systemd gibt.
Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch
war jede Komponente gut überschaubar und verständlich.

Mit Betonung auf "war".
In der heutigen Zeit mit ihren vielfältigen Bedrohungen genügt es
einfach nicht mehr, das irgendwer vor Jahrzehnten mal ein nützliches
Tool geschrieben hat, das einfach immer wieder kopiert wird. Jedes
Tool braucht ein Team von aktiven Maintainern, und deren Arbeit
wiederum muss irgendwer überwachen. Je mehr von diesen langweiligen
alten nicht mehr wirklich gepflegten Tools du im System hast, desto
leichter passiert das nächste XZ.

Mehr Komplexität (durch die erst xz ein Problem wurde) ist nicht immer
eine Verbesserung der Sicherheit. Manchmal ist "Ein Tool, eine
Funktion, eine definierte Schnittstelle" die bessere Wahl.

Post by Hergen Lehmann
Vor diesem Hintergrund ist es nicht ganz falsch, die vielen kleinen
Teilfunktionalitäten einzusammeln und in einem "Über-Tool" zu
vereinen. Wenn dieses kontrovers ist, umso besser, denn dann schauen
mehr Leute kritisch hin.

Das ist aber bei einfachen Projekten einfacher, weil da ggf. mehr Leute
bei der Hintertür mitspielen müssen.
Ein Monster prüfste nicht mal nebenbei auf Schwachstellen.

[Stefan+ (Stefan Froehlich)]

Post by Hergen Lehmann

Post by Andreas M. Kirchwitz
Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch war
jede Komponente gut überschaubar und verständlich.

Mit Betonung auf "war".
In der heutigen Zeit mit ihren vielfältigen Bedrohungen genügt es
einfach nicht mehr, das irgendwer vor Jahrzehnten mal ein
nützliches Tool geschrieben hat, das einfach immer wieder kopiert
wird. Jedes Tool braucht ein Team von aktiven Maintainern, und
deren Arbeit wiederum muss irgendwer überwachen. Je mehr von
diesen langweiligen alten nicht mehr wirklich gepflegten Tools du
im System hast, desto leichter passiert das nächste XZ.

Das könnte, so generisch und eloquent, wie es formuliert ist, aus
einer Marketing-Broschüre stammen. Jemand anderer schreibt dann:

"In der heutigen Zeit mit ihren vielfältigen Bedrohungen genügt es
einfach nicht mehr, eine zentrale Komponente zu verwenden, die von
einer überschaubaren Gruppe an Maintainern gepflegt wird, deren
Arbeit jemand überwachen muss. Je größer dieses komplexe und dadurch
intransparente Tool wird, desto leichter passiert das nächste XZ".

Und nun?

Post by Hergen Lehmann
Vor diesem Hintergrund ist es nicht ganz falsch, die vielen
kleinen Teilfunktionalitäten einzusammeln und in einem "Über-Tool"
zu vereinen.

Das ist - ohne sehr viel ausführlicher Begründung - genauso eine
Nullaussage wie das Gegenteil.

Kleine Tools lassen sich - verglichen mit dem Monolithen sich
leichter prüfen und auch durch Alternativen ersetzen, dafür tut sich
das im Einzelfall wiederum keiner an, siehe eben xz. Ähnliches im
Monolithen ist fraglos viel schwieriger, aber *wenn* es doch einmal
jemand schafft, dann war's das.

Servus,
Stefan

[Kay Martinen]

Post by Hergen Lehmann

Post by Andreas M. Kirchwitz
Eigentlich traurig, dass man inzwischen eher in Panik gerät,
statt verzückt zu sein, wenn es Neuigkeiten von systemd gibt.

*Ack*

Post by Hergen Lehmann

Post by Andreas M. Kirchwitz
Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch
war jede Komponente gut überschaubar und verständlich.

Mit Betonung auf "war".

Definitiv, NEIN. Denn SO sollte es wieder SEIN oder WERDEN!

Post by Hergen Lehmann
In der heutigen Zeit mit ihren vielfältigen Bedrohungen genügt es
einfach nicht mehr, das irgendwer vor Jahrzehnten mal ein nützliches
Tool geschrieben hat, das einfach immer wieder kopiert wird. Jedes Tool

Software wird immer kopiert, das solltest du wissen. Du meinst hier
warscheinlich veränderungen am Code oder gar Forks die du einfach nicht
verhindern kannst - außer die Gründe zu eliminieren die andere zu dem
Fork veranlassen. Ein Grund könnte z.b. sein das man sich selbst für
PERFEKT hielte und alle anderen nur für Idioten. Heute sehr beliebt aber
immer noch falsch.

Deine "Vielfältigen Bedrohungen" sind allesamt Menschengemacht und
werden auch nicht durch ein Super-Über-tool verschwinden. Im Gegenteil.

Diese Annahme ist etwa so sinnvoll wie Demokratiefeinden mit
Überwachung+Diktatur beikommen zu wollen. Das ist im RL ja gerne die
Antwort auf alles: MEHR Überwachung+Weniger Rechte für Alle(außer dem
Überwachungsapparat). Willst du zurück in den Spitzelstaat?

Post by Hergen Lehmann
braucht ein Team von aktiven Maintainern, und deren Arbeit wiederum muss
irgendwer überwachen. Je mehr von diesen langweiligen alten nicht mehr
wirklich gepflegten Tools du im System hast, desto leichter passiert das
nächste XZ.

Das mag wohl wahr sein. Aber beim One-Tool=One Job konzept beschränkt
sich ein Fehler üblicherweise auf genau DIES tool. Oder eben auf die
Schnittstelle zum nächsten. Macht das XZ-Problem genüsslichen
Falschgebrauch von einer pipe?

Das Problem sehe ich hier eher bei den Programmierern die heute lieber
das Rad neu erfinden als gewachsenen Code zu verstehen und zu warten.
Dazu kommt das niemand im Großen Maßstab dafür zahlen will das
Programmierer dies tun. Firmen zahlen nur für das was ihnen Mehrwert
bietet und das ist im Zweifel eher eine neu Variante die noch mehr Daten
abgreift - statt eines funktionierenden Tools das dies datensparsam
NICHT täte!

Also komm nicht mit zu wenig Maintainern. Auch DAS Problem ist
Menschengemacht/Firmenpolitik. Sag mir nicht das du dies gut/besser
fändest!?

Post by Hergen Lehmann
Vor diesem Hintergrund ist es nicht ganz falsch, die vielen kleinen
Teilfunktionalitäten einzusammeln und in einem "Über-Tool" zu vereinen.
Wenn dieses kontrovers ist, umso besser, denn dann schauen mehr Leute
kritisch hin.

Das auf systemd angewandt hat offensichtlich nicht einen einzigen Bug
dort drin vor dem Release verhindern können. Ein "Schweizer
Armee-Messer" ist sicher auch ein Über-tool. Aber auch dort kann das
Messer oder die Schere Stumpf werden, der Schraubendreher oder andere
Teile abbrechen u.s.w. Ich meine der Hersteller bietet da auch
Reparaturen an aber ich weiß nicht ob die Billiger sind als einfach ein
neues zu kaufen.

Ein Init-System sollte auch genau EINEN Job machen: Dienste
starten/stoppen und überwachen. Mehr nicht! Es sollte eben wegen des
Sinnvollen One-Tool-One Job Ansatzes ermöglichen einen resolved durch
einen anderen zu ersetzen, einen timesyncd durch chrony, ntpd o.a.
u.s.w. Und nicht einfach Insgeheim die google-DNS fragen weil sein Autor
der (Falschen) Ansicht wäre er wolle "Ein funktionsfähiges System
erhalten" - Gewaltsam! Ich sperre Google DNS, mit denen will ich nichts
zu tun haben und in meinem LAN brauche ich die schon gar nicht. Was
erlaubt der sich für Frechheiten!!! :-(=(

Denn das einzige Problem das m.E. dann noch übrig bleibt sind jene in
der Interaktion dieses "Tool-haufens" und da ist es IMHO immer leichter
ein start-problem im init-system zu suchen, ein dienst-problem im jew.
Dienst und bestenfalls noch in der Schnittstelle dazwischen. Also z.b.
irgendwelcher API's oder Aufruf-konventionen - an die sich evtl.
schlichtweg einer von beiden nicht gehalten haben mag. Korrigiere das an
einer oder gar beiden Seiten und das Problem ist aus der Welt.

Aber einem Monster-übertool absichtlich hart hinein programmierte
features heraus zu operieren ist hier wieder mal nur den Autoren dieses
Tools möglich. Und wenn die; was ja wohl schon oft der Fall war; es
einfach ignorieren (weil sie ja so viel besser seien) dann haben alle
das Problem geerbt die dieses Tool einsetzen/müssen.

Diese Friss-oder-geht-sterben Mentalität ist einfach nur Überheblich,
Hundsgemein und du mußt die nicht auch noch verteidigen.

<End Rant>

Bye/
/Kay

[Marco Moock]

Post by Andreas M. Kirchwitz
Für mich waren Unix-Systeme früher ein Baukasten vieler kleiner
Komponenten, die jede für sich ihren Job gemacht hat. Dadurch
war jede Komponente gut überschaubar und verständlich.
Die Interaktion zwischen den Komponenten konnte vielleicht
manchmal holprig sein, aber das war eben der Job des Admins. :-)

Das zu standardisieren ist halt sinnvoll.

Post by Andreas M. Kirchwitz
Heutzutage ist systemd wie so ein Windows-System, das macht
alles für einen, man kann nicht so gut reinschauen, und wenn's
nicht tut, was man soll, installiert man eher alles neu, als
die Vorgänge zu verstehen, weil das System ja auch gar nicht
dafür ausgelegt ist, dass man ihm auf die Finger schaut.

Den Eindruck habe ich bei systemd nicht. Es gibt da zwar fragwürdige
Designentscheidungen, aber nachvollziehbar sind die Vorgänge eigentlich
schon.

Post by Andreas M. Kirchwitz
Mal schauen, vielleicht schaffe ich es ja auch noch, bis zu
meinem Ableben kein Wayland nutzen zu müssen. :-)

Das wird bei mir noch viel schwieriger.

Post by Andreas M. Kirchwitz
Weiß ja heutzutage auch niemand mehr, wie ein Webserver oder
Mailserver funktioniert. Da gibt's fertige Container, und wenn
was nicht geht, schmeißt man es weg und installiert andere
Container. Irgendeiner funktioniert schon.

Habe ich schonmal erwähnt, dass ich Docker hasse?
Falls nein: Jetzt ist es getan.

Das erzeugt einfach nur ein großes Chaos, viel mehr Komplexität und die
Sicherheit wird teilweise verschlechtert, weil keiner mehr nen
Überblick hat, was auf welcher Version läuft.

Post by Andreas M. Kirchwitz
"sudo" ist Shell. Shell verwenden nur noch alte weiße Männer.

Das kann ich erfreulicherweise verneinen, denn die Shell hat einen
Vorteil: Man kann damit automatisieren.

[Arno Welzel]

[...]

Post by Marco Moock

Post by Andreas M. Kirchwitz
Weiß ja heutzutage auch niemand mehr, wie ein Webserver oder
Mailserver funktioniert. Da gibt's fertige Container, und wenn
was nicht geht, schmeißt man es weg und installiert andere
Container. Irgendeiner funktioniert schon.

Habe ich schonmal erwähnt, dass ich Docker hasse?
Falls nein: Jetzt ist es getan.

Docker wird oft missverstanden.

Nein, Docker ist *nicht* dafür da, Software sicherer zu machen! Software
muss auch mit Docker weiterhin auf Sicherheit geprüft werden.

Aber ohne Tools wie Docker und Kubernetes ist es mitunter um
Größenordnungen aufwendiger, komplexere Umbgebungen sinnvoll zu beherrschen.

Post by Marco Moock
Das erzeugt einfach nur ein großes Chaos, viel mehr Komplexität und die
Sicherheit wird teilweise verschlechtert, weil keiner mehr nen
Überblick hat, was auf welcher Version läuft.

Wer Docker so einsetzt, macht was falsch. Der installiert dann aber
irgendeine Linux-Distribution, die gerade als "angesagt" gilt und packt
jedes Paket drauf, was gerade passt.

Post by Marco Moock

Post by Andreas M. Kirchwitz
"sudo" ist Shell. Shell verwenden nur noch alte weiße Männer.

Das kann ich erfreulicherweise verneinen, denn die Shell hat einen
Vorteil: Man kann damit automatisieren.

Das kann man mit vielen Tools. Aber sowas wie Terraform oder Ansible
macht Shell alleine halt auch nicht.

[Marc Haber]

Post by Arno Welzel

Post by Marco Moock
Das erzeugt einfach nur ein großes Chaos, viel mehr Komplexität und die
Sicherheit wird teilweise verschlechtert, weil keiner mehr nen
Überblick hat, was auf welcher Version läuft.

Wer Docker so einsetzt, macht was falsch. Der installiert dann aber
irgendeine Linux-Distribution, die gerade als "angesagt" gilt und packt
jedes Paket drauf, was gerade passt.

Docker hat unterschiedliche Einsatzzwecke. Ich beispielsweise nutze
Docker, um Dinge "mal eben schnell" auszuprobieren. Da muss man nicht
erst aufwendig Doku lesen und hat den ersten Prototypen in fünf
Minuten am Start. Wenn man sich dann überlegt, das Ding
weiterbetreiben zu wollen, sollte man es auf andere Beine stellen.

Docker im professionellen Umfeld ist im Wesentlichen ein
Flexibilitäts- und Skalierungstool, hier ist es angezeigt, nichts aus
dem öffentlichen Repository zu ziehen und alle Images selbst zu bauen.
Dann weiß man, was man im Einsatz hat und kann ordentliches
Securitymanagement betreiben.

Leider arbeiten bei weitem nicht alle professoinellen Docker-Anwender
so.

Grüße
Marc

[Arno Welzel]

Andreas M. Kirchwitz, 2024-05-02 17:22:

[...]

Post by Andreas M. Kirchwitz
"sudo" ist Shell. Shell verwenden nur noch alte weiße Männer.
Ob das später dann "run0" heißt, es ist bald niemand mehr da,
den es noch interessieren könnte.

In meinem aktuellen Umfeld wäre ein halbes Team nicht arbeitsfähig, wenn
ich nicht als "alter weißer Mann" den Leuten erklären würde, wie die
Shell fuktioniert ;-)

[Hermann Riemann]

Na, herzlichen Glückwunsch. Ja, es kann schlechter werden also das > Original-sudo. Wir werden sehen.

Ich finde gewisses Hinzulernen von seltenen Verwendungen riskant.

Wenn ich root Rechte brauche
etwa zum editieren in /etc
den verwende ich su.
Wenn das (grr) nicht geht, sudo su.

Wenn das erledigt ( und eventuell getestet ist )
gehe ich da mit exit wieder raus.

Das ist für mich einfach und ausreichend sicher.
# statt > in der shell halte ich für ausreichend.

Bei sudo denke ich an eine malware shell
die eventuell dann damit root Rechte
ohne Passwort erhält, nachdem ich mal sudo verwendet habe.

[Rolf Buenning]

Post by Hermann Riemann

Na, herzlichen Glückwunsch. Ja, es kann schlechter werden also das > Original-sudo. Wir werden sehen.

Ich finde gewisses Hinzulernen von seltenen Verwendungen riskant.
Wenn ich root Rechte brauche
etwa zum editieren in /etc
den verwende ich su.
Wenn das (grr) nicht geht, sudo su.

Hallo,
ich benutze bei Bedarf immer sudo.
Nach dem Lesen hier habe ich su versucht, aber das klappt nicht.
Es wird nach Passwort gefragt, aber die Eingabe funktioniert nicht,
es werden keine Tastendrücke und 'su Legitimierungsfehler'
angezeigt.
Wo muss ich drehen?

System:Linux Mint 20.3 Una

Rolf

[Marco Moock]

Post by Rolf Buenning
ich benutze bei Bedarf immer sudo.
Nach dem Lesen hier habe ich su versucht, aber das klappt nicht.
Es wird nach Passwort gefragt, aber die Eingabe funktioniert nicht,
es werden keine Tastendrücke und 'su Legitimierungsfehler'
angezeigt.
Wo muss ich drehen?

su fragt das Passwort des users ab. Gibt man keinen an, ist das root.
Ergo musst du das PW für root eingeben oder ggf. erst eines festlegen.

[Rolf Buenning]

Post by Marco Moock

Post by Rolf Buenning
ich benutze bei Bedarf immer sudo.
Nach dem Lesen hier habe ich su versucht, aber das klappt nicht.
Es wird nach Passwort gefragt, aber die Eingabe funktioniert nicht,
es werden keine Tastendrücke und 'su Legitimierungsfehler'
angezeigt.
Wo muss ich drehen?

su fragt das Passwort des users ab. Gibt man keinen an, ist das root.
Ergo musst du das PW für root eingeben oder ggf. erst eines festlegen.

Danke, hat geklappt.
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Rolf

[Marco Moock]

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

[Rolf Buenning]

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.
®olf

[Marc Haber]

Post by Rolf Buenning

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

Welche Distribution verwendest Du?

Grüße
Marc

[Stephan Seitz]

Post by Marc Haber

Post by Rolf Buenning
Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

Linuxmint gibt bei Sudo Sternchen aus.

Stephan

[Marc Haber]

Post by Stephan Seitz

Post by Marc Haber

Post by Rolf Buenning
Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

Linuxmint gibt bei Sudo Sternchen aus.

Okeeh, wieder was gelernt. Das ist die sudoers-Option pwfeedback, die
- gott sei dank - beim Rest der Welt im default Aus ist.

Grüße
Marc

[Kay Martinen]

Post by Marc Haber

Post by Stephan Seitz

Post by Marc Haber

Post by Rolf Buenning
Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

Linuxmint gibt bei Sudo Sternchen aus.

Okeeh, wieder was gelernt. Das ist die sudoers-Option pwfeedback, die
- gott sei dank - beim Rest der Welt im default Aus ist.

Ist mir bei meinem LM auch noch nie aufgefallen aber so oft benutze ich
sudo dort auch nicht. Die machen das offenbar damit es ONU-Kompatibler
wird. Oder es betrifft nur die Grafischen Prompts in der UI da kann das
schon sein. Es wird wohl auch da ein 'sudo' "dahinter" stecken.

Bye/
/Kay

[Rolf Buenning]

Post by Marc Haber

Post by Rolf Buenning

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.
Welche Distribution verwendest Du?

cat /etc/issue: Linux Mint 20.3 Una

Ich habe auch nichts gefunden, um sowas zu konfigurieren, es tut aber.

Rolf

[Rolf Buenning]

Post by Rolf Buenning

Post by Marc Haber

Post by Rolf Buenning

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.
Welche Distribution verwendest Du?

cat /etc/issue: Linux Mint 20.3 Una

OK, Danke an alle, habe wieder was dazu gelernt.

Rolf

[Marc Haber]

Post by Rolf Buenning
Ich habe auch nichts gefunden, um sowas zu konfigurieren, es tut aber.

/etc/sudoers nach pwfeedback durchschauen.

Grüße
Marc

[Gert Link]

Post by Marc Haber

Post by Rolf Buenning
Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

man sudoers. dort pwfeedback

[Rolf Buenning]

Post by Gert Link

Post by Marc Haber

Post by Rolf Buenning
Ja, aber auch keine *ne, wie es bei sudo ist.

Sudo gibt beim Eintippen eines Passworts auch nichts aus und mir ist
in erster näherung auch nicht bekannt dass man sudo entsprechend
konfigurieren könnte.

man sudoers. dort pwfeedback

in /etc/sudoers.d das file 0pwfeedback editieren.
Wenn man den Eintrag 'Defaults pwfeedback' auskommentiert,
werden keine **chen angezeigt.

Rolf

[Marco Moock]

Post by Rolf Buenning

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.

Das passiert zumindest unter Debian nicht.
Jedenfalls nicht bei mir und ich habe da nichts absichtlich eingestellt.

[Kay Martinen]

Post by Rolf Buenning

Post by Marco Moock

Post by Rolf Buenning
Verwirrend ist, daß bei der Passworteingabe nichts auf dem
Bildschirm ausgegeben wird.

Das ist bei UNIX/Linux normal.

Ja, aber auch keine *ne, wie es bei sudo ist.

Hier nicht.

So was ist modernes Teufelszeug von (Pseudo)Grafischen Oberflächen deren
OttoNormal-Benutzer sich sonst auf der Tastatur verirren.

Da "braucht" es dann halt für jedes eingetippte Zeichen einen * als
Rückmeldung das der Dumme Computer den Tastendruck auch verstanden
hätte. Auch wenn es dann manchmal ein TASTENDRUCK wurde. Aber einen * in
GROSSBUCHSTABEN hat m.W. noch keiner erfunden. ;-)

Aber wenn man ein paar tage länger an einem Linux saß und auch die
Tastatur gewohnt ist tippt man das doch sowieso mindestens halb-blind
richtig ein. Wozu also noch *

Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Aber wenn man ein paar tage länger an einem Linux saß und auch die
Tastatur gewohnt ist tippt man das doch sowieso mindestens halb-blind
richtig ein. Wozu also noch *

Besonders wichtig und nützlich sind die * bei einer Bildschirmtastatur.
Oder sonst wie störrischen, wie dem Type Cover eines Surface-Tablets.

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Kay Martinen
Aber wenn man ein paar tage länger an einem Linux saß und auch die
Tastatur gewohnt ist tippt man das doch sowieso mindestens halb-blind
richtig ein. Wozu also noch *

Besonders wichtig und nützlich sind die * bei einer Bildschirmtastatur.
Oder sonst wie störrischen, wie dem Type Cover eines Surface-Tablets.

Benutze ich nicht. Kann mal allerdings unter "nicht gewohnte Tastatur"
subsummieren denke ich.

Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Benutze ich nicht. Kann mal allerdings unter "nicht gewohnte Tastatur"
subsummieren denke ich.

Mit dem Unterschied, dass man sich an so einen Müll nie gewöhnt ;)

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Kay Martinen
Benutze ich nicht. Kann mal allerdings unter "nicht gewohnte Tastatur"
subsummieren denke ich.

Mit dem Unterschied, dass man sich an so einen Müll nie gewöhnt ;)

Darum benutze ich es ja auch nicht. :) Da ist mir eine IBM M-Type
lieber, da "hört" und "spürt" man jeden Anschlag. Auch den auf ein Leben
weil sie so stabil ist.

Bye/
/Kay

[Marc Haber]

Post by Hermann Riemann
Wenn ich root Rechte brauche
etwa zum editieren in /etc
den verwende ich su.
Wenn das (grr) nicht geht, sudo su.
Wenn das erledigt ( und eventuell getestet ist )
gehe ich da mit exit wieder raus.
Das ist für mich einfach und ausreichend sicher.
# statt > in der shell halte ich für ausreichend.
Bei sudo denke ich an eine malware shell
die eventuell dann damit root Rechte
ohne Passwort erhält, nachdem ich mal sudo verwendet habe.

Du redest wirr und widersprichst Dir selbst.