Discussion:
Geschichte von "ping" (in memoriam Mike Muuss)
(zu alt für eine Antwort)
Raimund Huemmer
2020-11-15 20:17:12 UTC
Permalink
Kürzlich (beim Installieren von Nextstep) wurde ich wieder einmal daran
erinnert, dass dort ping in /etc zu finden ist. Beim überlegen, was das
wohl für historische Gründe hat, kam ich schnell durch die aktuellen
Manpages von ping(8) auf 4.3BSD und Mike Muuss.

Da ich eben sah, dass Mike Muuss vor 20 Jahren (20.11.2000) leider
relativ jung verstarb, dachte ich, hier in der Gruppe daran zu erinnern.

https://ftp.arl.army.mil/~mike/
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.etc/ping/ping.c

Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Gruss
Raimund
--
Life's too short to read boring signatures
Goetz Hoffart
2020-11-15 23:46:02 UTC
Permalink
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern die
Hauptplatte mit /bin voll war, und man Binaries also auf die Zweitplatte
unter dem User-Verzeichnis /usr parkte ...

Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

Grüße
Götz
--
http://www.knubbelmac.de/
Michael Bäuerle
2020-11-16 09:43:17 UTC
Permalink
Post by Goetz Hoffart
[...]
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern die
Hauptplatte mit /bin voll war, und man Binaries also auf die Zweitplatte
unter dem User-Verzeichnis /usr parkte ...
Früher hatte man /usr auch gerne auf einem NFS-Server liegen und ganze
Rechner-Pools haben das von dort gemountet.
Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.
Eine Begründung der systemd-Leute findet sich hier:
<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>
Hanno Foest
2020-11-16 10:37:25 UTC
Permalink
Post by Michael Bäuerle
Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.
<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>
Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.

Hanno
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith
Michael van Elst
2020-11-16 11:59:05 UTC
Permalink
Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.
Salami-Taktik erhöht die Akzeptanz.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Kay Martinen
2020-11-16 17:55:13 UTC
Permalink
Post by Michael van Elst
Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.
Ja, das finde ich als Begründung auch eher frech.
Post by Michael van Elst
Salami-Taktik erhöht die Akzeptanz.
Hier erhöht es allenfalls die Salamität der Kalamität (von systemd).
Aber auch so kann ich deinen Satz nur als unwahr abtun. Jedenfalls ich
glaube nicht dran aber... YMMV. ;-)

Kay
--
Posted via leafnode
Michael Bäuerle
2020-11-16 11:23:24 UTC
Permalink
Post by Hanno Foest
Post by Michael Bäuerle
Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.
<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>
Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.
Ja, das ist schon ein wenig lustig (oder auch nicht).
Ich wollte trotzdem auf deren Begründungen verweisen.
Hauke Fath
2020-11-16 19:58:09 UTC
Permalink
Post by Goetz Hoffart
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
War "ganz früher" nicht /etc das home von root? Verlinkt Solaris immer
noch "everything but the kitchen sink" nach /etc?

Hauke
--
Now without signature.
Thomas Koenig
2020-11-16 20:35:09 UTC
Permalink
Post by Hauke Fath
Post by Goetz Hoffart
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
War "ganz früher" nicht /etc das home von root?
Ich dachte, root hatte / (daher der Name).
Kay Martinen
2020-11-16 22:37:46 UTC
Permalink
Post by Thomas Koenig
Post by Hauke Fath
Post by Goetz Hoffart
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
War "ganz früher" nicht /etc das home von root?
Ich dachte, root hatte / (daher der Name).
Ich denke das kommt eher von der Dateisystem-wurzel. Das ist nun mal /

Aber ich bin auch kein Kenner alter Unices und mag mich irren.

Kay
--
Posted via leafnode
Thomas Koenig
2020-11-17 07:44:19 UTC
Permalink
Post by Kay Martinen
Post by Thomas Koenig
Post by Hauke Fath
Post by Goetz Hoffart
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
War "ganz früher" nicht /etc das home von root?
Ich dachte, root hatte / (daher der Name).
Ich denke das kommt eher von der Dateisystem-wurzel. Das ist nun mal /
Ich meinte das wie in https://en.wikipedia.org/wiki/Superuser
erläutert:

# The name root may have originated because root is the only user
# account with permission to modify the root directory of a Unix
# system. This directory was originally considered to be root's
# home directory,[4] but the UNIX Filesystem Hierarchy Standard now
# recommends that root's home be at /root.[5]
Andreas Fenner
2020-11-28 10:11:20 UTC
Permalink
Post by Hauke Fath
War "ganz früher" nicht /etc das home von root? Verlinkt Solaris immer
noch "everything but the kitchen sink" nach /etc?
Hauke
Bis einschließlich Solaris-10 hatte der USer root "/" als $HOME. Seit
Solaris-11 ist es nun "/root" .

Andreas
Sebastian Barthel
2020-11-20 11:46:24 UTC
Permalink
Post by Goetz Hoffart
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
Das stimmt - in dem McKusick Buch zu BSD 4.3 steht das auch so drin,
allerdings nicht als eine Definition sondern eher als Beispiele für die
Beschreibung des Bootens. Da gibt es u.a. in /etc

/etc/rc
/etc/fsck
/etc/update
/etc/cron
/etc/accton
/etc/syslogd
/etc/getty und
/etc/init

interessanterweise taucht login dann als /bin/login auf


Normalerweise haben die das aber sicher auch mal irgendwo aufgeschrieben,
wahrscheinlich findet man das in so einem USENIX Konferenz Papier, wo mal
jemand einen Dateibaum vorschlägt - an den sich dann alle, mehr oder
weniger, halten.
Post by Goetz Hoffart
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin.
Manches ist aber auch schwierig, wenn man das wirklich richtig machen
will. Ein schönes Beispiel ist da /usr/local
Darin taucht dann quasi 'alles' nochmal auf und weil es ja sowieso nur
auf der Einzelmaschine da sein sollte, wäre es ja auch relativ konsequent
das als /local einzubinden. Auf der anderen Seite ist eben alles was drin
ist auch per se immer /usr Content.

Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann. Erklären kann man sich das aus heutiger Sicht nur
damit, daß grafische Filemanager einfach unüblich waren. Genausowas ist /
usr/share/icons und die Nummer mit dem /X11 ist auch nie wirklich
entschieden worden. Ich z.B. finde ja, daß man auch so Sachen wie
Windowmanager oder Datenbanken schön in Einzelordner packen könnte. Bei
Sun gibt es sowas mit dem Openwin Verzeichnis, wo mal halt alles was zum
Desktop gehört drin ist - dann aber eben auch konsequenterweise mit dem X
- den man dann stundenlang suchen kann, wenn man das nicht weiß.
Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.
Das ist aber auch keine wirklich schöne Lösung. Eher so eine Art backward-
Kompatibilitätslayer der besonders trivialen Art.


Gruß,
SBn
Nils M Holm
2020-11-20 13:53:41 UTC
Permalink
Post by Sebastian Barthel
Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann.
Wahrscheinlich, weil die RK05 dann ziemlich schnell voll waere!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Norbert Narten
2020-11-20 19:30:15 UTC
Permalink
Post by Sebastian Barthel
interessanterweise taucht login dann als /bin/login auf
Der Grund ist wirklich einfach: Es hat damit zu tun, das /usr in einem klassischem
UNIX-System ein eigens Filesystem ist. Wenn das System "mal" nicht Ordnungsgemäß
starten kann und die Dateisysteme nicht gemountet werden, steht das logon-Programm
noch zur Verfügung. Ebenso die Standard-Shell /bin/sh. Damit ist ein Logon
im "Maintenance-Mode" immer noch möglich.
Post by Sebastian Barthel
Post by Goetz Hoffart
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin.
Das ist hier der gleiche Grund. In /bin liegen die Programme, die im Notfall
unbedingt benötigt werden, um das System zu "retten"...
Post by Sebastian Barthel
Manches ist aber auch schwierig, wenn man das wirklich richtig machen
will. Ein schönes Beispiel ist da /usr/local
Darin taucht dann quasi 'alles' nochmal auf und weil es ja sowieso nur
auf der Einzelmaschine da sein sollte, wäre es ja auch relativ konsequent
das als /local einzubinden. Auf der anderen Seite ist eben alles was drin
ist auch per se immer /usr Content.
Der local-Ordner ist im Ursprung dafür gedacht, das dort Programme & Daten liegen,
die zu dem System gehören, wenn z.B. /usr über NFS gemountet wurde.
Post by Sebastian Barthel
Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann. Erklären kann man sich das aus heutiger Sicht nur
Wenn /usr ein NFS-Mount ist, liegen dort die Dateien, die für alle Systeme,
die diesen Mount nutzen, dann gleich sind (normalerweise RO gemountet)...
Post by Sebastian Barthel
damit, daß grafische Filemanager einfach unüblich waren. Genausowas ist /
usr/share/icons und die Nummer mit dem /X11 ist auch nie wirklich
entschieden worden. Ich z.B. finde ja, daß man auch so Sachen wie
Windowmanager oder Datenbanken schön in Einzelordner packen könnte. Bei
Sun gibt es sowas mit dem Openwin Verzeichnis, wo mal halt alles was zum
Desktop gehört drin ist - dann aber eben auch konsequenterweise mit dem X
- den man dann stundenlang suchen kann, wenn man das nicht weiß.
...somit machen /usr/X11 und /usr/share/X11 dann doch wieder Sinn, den
die Programme & Daten sind /usr-Mount und die Konfiguration ist in /etc.
Post by Sebastian Barthel
Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.
Ich finde es eher "sub optimal" (um das höflich zu umschreiben), alles in
ein "Riesiges" File-System rein zu kippen. Das sorgt eher dafür, das der
vom Kernel kontrollierte File-System-Cache "extrem" anwachsen kann, bzw
die Suche nach Dateien in einem großen Dateisystem länger dauert, wenn es
keinen "Cache-Hit" gibt - es muss dann der Inode-Tree vollständig durchsucht
werden. Das kann dauern. Nicht jeder nutzt SSDs - schon gar nicht in klassischen
Systemen.
Post by Sebastian Barthel
Das ist aber auch keine wirklich schöne Lösung. Eher so eine Art backward-
Kompatibilitätslayer der besonders trivialen Art.
So ist das eben, wenn bewährte Dinge - meiner Meinung nach - zu schnell über
Board geworfen werden, nur weil es geil ist, alles von einer Firma in Redmond
vorgemachte, zu übernehmen. Der systemd ist da auch so ein Beispiel: Nach 10
Sekunden ist der Logon-Schirm da, aber eine Anmeldung dauert, weil die System-
Dienste im Hintergrund noch am starten sind... ;-)... aber das gehört jetzt
nicht hierhin.
Post by Sebastian Barthel
Gruß,
SBn
Viele Grüße
Norbert
Stefan Möding
2020-11-21 11:22:48 UTC
Permalink
Post by Norbert Narten
Der local-Ordner ist im Ursprung dafür gedacht, das dort Programme &
Daten liegen, die zu dem System gehören, wenn z.B. /usr über NFS
gemountet wurde.
Ich habe das so kennengelernt, dass /usr vom Betriebssystem ist und in
/usr/local die eigenen Erweiterungen abgelegt wurden. Da gab es dann eben
/usr/local/bin/bash, weil die Bash nicht beim OS mitgeliefert wurde und
man die stattdessen selber kompiliert hat.
Post by Norbert Narten
Ich finde es eher "sub optimal" (um das höflich zu umschreiben), alles
in ein "Riesiges" File-System rein zu kippen. Das sorgt eher dafür, das
der vom Kernel kontrollierte File-System-Cache "extrem" anwachsen kann,
bzw die Suche nach Dateien in einem großen Dateisystem länger dauert,
wenn es keinen "Cache-Hit" gibt - es muss dann der Inode-Tree
vollständig durchsucht werden. Das kann dauern. Nicht jeder nutzt SSDs -
schon gar nicht in klassischen Systemen.
Da sehe ich keinen Zusammenhang zur Anzahl der Filesysteme. Wenn der PATH
x Verzeichnisse enthält, dann läuft die Suche doch immer gleich ab, egal
ob die x Verzeichnisse in einem, drei oder fünf Filesystemen liegen. Der
Cache hält das, was eingelesen wird. Ich kenne das noch so (Ultrix 4.2),
dass die Größe des Caches ein statischer Kernelparameter war. Eine
Änderung erforderte einen Reboot mit einem neu compilierten Kernel.

Neben der Größe der Platten ist m.E. da eher noch die Dauer des
Filesystemchecks ein Thema. Es gab keine Journaling Filesysteme, d.h. bei
einem Crash (und nach x Reboots) war ein fsck nötig. Und Filesysteme auf
mehreren Disks konnten parallel durchlaufen werden. Drei Platten mit
jeweils 500MB waren da schneller fertig, als eine Platte mit 1500MB.
--
Stefan
K. Krause
2020-11-23 13:07:57 UTC
Permalink
...
Post by Norbert Narten
Der Grund ist wirklich einfach: Es hat damit zu tun, das /usr in einem klassischem
UNIX-System ein eigens Filesystem ist. Wenn das System "mal" nicht Ordnungsgemäß
starten kann und die Dateisysteme nicht gemountet werden, steht das logon-Programm
noch zur Verfügung. Ebenso die Standard-Shell /bin/sh. Damit ist ein Logon
im "Maintenance-Mode" immer noch möglich.
Viele Grüße
    Norbert
In dem Buch von 1983 "The UNIX System, von S. R. Bourne, das war der mit
der gleichnamigen Muschel) steht geschrieben, dass die Homes der
Benutzer in /usr untergebracht sind. Daneben gibt es dort auch noch die
Subdirectories wie include, spool und src.
Von daher scheint mir der Name usr eher als eine Verkürzung von user,
als ein Akronym für Unix System Resources wahrscheinlich. Der Herr
Bourne hat es mit dreibuchstabigen Abkürzungen.

Ping gibt es in dem Buch natürlich noch nicht, und der Herr Bourne
freut sich, dass er von seinem Rechner allegra mit uucp Zugriff auf
über 300 andere Rechner hat, auf die er Files entweder über Telefon-
leitungen oder über spezielle Hochgeschwindigkeitsleitungen kopieren
kann. :-)

Klemens
Stefan Möding
2020-11-20 12:27:18 UTC
Permalink
Ich sag nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern
die Hauptplatte mit /bin voll war, und man Binaries also auf die
Zweitplatte unter dem User-Verzeichnis /usr parkte ...
Nach /bin gehören die Sachen, die man im Single-User Betrieb und zum
Booten braucht, bevor /usr gemounted wurde (ggfs. über NFS).

Irgendwo habe ich mal gelesen, dass /usr das Kürzel für Unix System
Resources sei, also nicht unbedingt was mit Usern zu tun hat. Wer kann
heute noch sagen, ob da was dran ist...
--
Stefan
Nils M Holm
2020-11-20 13:56:10 UTC
Permalink
Irgendwo habe ich mal gelesen, dass /usr das K?rzel f?r Unix System
Resources sei, also nicht unbedingt was mit Usern zu tun hat. Wer kann
heute noch sagen, ob da was dran ist...
Da die User-Verzeichnisse frueher direkt unter /usr lagen, halte
ich das fuer ein bacronym.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Stefan Möding
2020-11-20 14:17:29 UTC
Permalink
Post by Nils M Holm
Da die User-Verzeichnisse frueher direkt unter /usr lagen, halte
ich das fuer ein bacronym.
Ja, vermutlich ist das auch so.

Im Unix Programmer’s Manual unter
https://www.bell-labs.com/usr/dmr/www/1stEdman.html (auch hier sieht man
/usr/dmr) finden noch ein paar Hinweise zu /etc:

,----[ mkfs ]
| This program is kept in /etc to avoid inadvertant use and consequent
| destruction of information
`----

,----[ boot ]
| boot logically a command, and is kept in /etc only to lessen the
| probability of its being invoked by accident or from curiosity
`----

/etc sollte wohl nicht im Pfad sein und damit potentiell gefährliche
Kommandos nicht aus versehen gestartet werden, sondern eben durch Eingabe
des kompletten Pfades.
--
Stefan
Nils M Holm
2020-11-20 16:08:36 UTC
Permalink
Post by Stefan Möding
,----[ mkfs ]
| This program is kept in /etc to avoid inadvertant use and consequent
| destruction of information
`----
Ergibt Sinn!
Post by Stefan Möding
,----[ boot ]
| boot logically a command, and is kept in /etc only to lessen the
| probability of its being invoked by accident or from curiosity
`----
*Das* hat bei mir nicht funktioniert! :)
Post by Stefan Möding
/etc sollte wohl nicht im Pfad sein und damit potentiell gef?hrliche
Kommandos nicht aus versehen gestartet werden, sondern eben durch Eingabe
des kompletten Pfades.
Genau so habe ich das immer gehandhabt.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Diedrich Ehlerding
2020-11-20 17:25:03 UTC
Permalink
Post by Nils M Holm
Post by Stefan Möding
| This program is kept in /etc to avoid inadvertant use and
| consequent destruction of information
`----
Ergibt Sinn!
Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da
schon ein Filesystem vorfinden.

Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Nils M Holm
2020-11-20 17:52:41 UTC
Permalink
Post by Diedrich Ehlerding
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".
Ich denke, da geht es eher um safety als security.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Kay Martinen
2020-11-20 18:14:08 UTC
Permalink
Post by Nils M Holm
Post by Diedrich Ehlerding
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".
Ich denke, da geht es eher um safety als security.
'Safety by Obscurity" klingt auch nicht besser, eher wie eine
Marketing-Luftblase. :-)

Pers. möchte ich bei meinen Linuxen auch keine binarys in /etc sehen
noch einen link darauf. /etc/init.d/ zählt dabei nicht weil die binarys
nur aus den scripts dort aufgerufen werden. Aber das gewöhnt man sich
m.E. als erstes an das man für Start/stops ein /etc/init.d/ schreibt.
Und dank Autocomplete in der bash kommt man auch schnell zum richtigen
script. Im gegensatz zu 'systemctl <aktion> <dienstname>.service
blablafasel... was ich total praxisfeindlich finde. Dann lieber 'service'


Kay
--
Posted via leafnode
Ignatios Souvatzis
2020-11-22 15:10:48 UTC
Permalink
Post by Diedrich Ehlerding
Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da
****
Post by Diedrich Ehlerding
schon ein Filesystem vorfinden.
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".
Hm, ja. Es ist kein echter Schutz. Es hilft aber in begrenztem Ausmass
vor Tippfehlern, wie dem inversen von dem, den du gerade begangen hast.
Gerade als root.

-is
--
A medium apple... weighs 182 grams, yields 95 kcal, and contains no
caffeine, thus making it unsuitable for sysadmins. - Brian Kantor
Gerrit Heitsch
2020-11-22 15:42:47 UTC
Permalink
Post by Ignatios Souvatzis
Post by Diedrich Ehlerding
Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da
****
Post by Diedrich Ehlerding
schon ein Filesystem vorfinden.
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".
Hm, ja. Es ist kein echter Schutz. Es hilft aber in begrenztem Ausmass
vor Tippfehlern, wie dem inversen von dem, den du gerade begangen hast.
Gerade als root.
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.

Gerrit
Andreas Fenner
2020-11-28 10:19:25 UTC
Permalink
Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

:-)

Andreas
Kay Martinen
2020-11-28 16:21:34 UTC
Permalink
Post by Andreas Fenner
Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn
dieses aktuell gemounted ist.
  Gerrit
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?
Ach das ist interessant. Welche Version von fsck auf welchem OS
verwendest du bitte?

Ich meine, es wäre doch toll wenn alle so ein Tool hätte das außer den
"bist du Sicher" und "Willst du das WIRKLICH tun" Nachfragen - hier
offenbar auch noch die Qualifikation des fsck-aufrufenden abfragt
(online-vitae analysierend) und bei weniger als 3 Jahren
Systemverwaltungspraxis den Zugriff einfach mit einem DAU-Error 404
verweigert. MIR würde dann zwar der Zugriff immer verweigert aber die
Regeln kann man ja sicher auch umgehen, nodephalls durch ziehen des
Netzwerkkabels. Man muß ja *nur* wissen was man tut. So wie Sledge Hammer.
Post by Andreas Fenner
:-)
Ja, genau. Stell dir mal vor das Skalpel fährt erst dann den
Klingenschutz zurück wenn der Doc seinen Heilberufsausweis vorzeigt. In
der Notaufnahme - bei einem Kritisch Schwerverletzten...

Wir müssen es echt irgendwie hinkriegen das in Summe nur noch so viele
Menschen (über)leben wie der Planet auch ernähren kann. Dafür werden uns
irgendwann alle mittel recht sein.

Ob sie dann auch GERECHT sind, das liegt dann wohl am Bankkonto...

fsck -t terraform -M /dev/earth

Result is: FUBAK

Kay
--
Posted via leafnode
Guido Grohmann
2020-11-29 15:52:14 UTC
Permalink
Post by Kay Martinen
fsck -t terraform -M /dev/earth
segmentation fault
core dumped

uuuund:

kernel panic

;)

Guido
Kay Martinen
2020-11-29 18:23:42 UTC
Permalink
Post by Guido Grohmann
Post by Kay Martinen
fsck -t terraform -M /dev/earth
segmentation fault
core dumped
kernel panic
;)
Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)

Das kriegen wir auch 2021 noch ganz alleine hin. Praktische
Zahlendreherei. ;)

Kay
--
Posted via leafnode
Guido Grohmann
2020-11-29 19:40:50 UTC
Permalink
Post by Kay Martinen
Post by Guido Grohmann
Post by Kay Martinen
fsck -t terraform -M /dev/earth
segmentation fault
core dumped
kernel panic
;)
Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)
Nö, der ist mir völlig unbekannt. :o

Guido
Kay Martinen
2020-11-29 21:59:53 UTC
Permalink
Post by Guido Grohmann
Post by Kay Martinen
Post by Guido Grohmann
Post by Kay Martinen
fsck -t terraform -M /dev/earth
segmentation fault
core dumped
kernel panic
;)
Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)
Nö, der ist mir völlig unbekannt. :o
[x] Dir ist der Alu-Hut über die Augen gerutscht.

Andere Beschreibung des Films: "Wir werden alle Sterben! Nein! Doch!
Ohh! Na, doch nicht alle..." Aber schön das zum Ende hin der US
Präsident stirbt - leider der Falsche wie üblich.

Kay
--
Posted via leafnode
Michael van Elst
2020-11-30 12:30:18 UTC
Permalink
Post by Kay Martinen
Andere Beschreibung des Films: "Wir werden alle Sterben! Nein! Doch!
Ohh! Na, doch nicht alle..." Aber schön das zum Ende hin der US
Präsident stirbt - leider der Falsche wie üblich.
Helden müssen sterben.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Arno Welzel
2020-11-30 08:13:02 UTC
Permalink
Post by Andreas Fenner
Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?
Nein, so wie fsck eben fragt:

--------------------

fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/sda2 is mounted.



WARNING!!! The filesystem is mounted. If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.


Do you really want to continue<n>?

--------------------
--
Arno Welzel
https://arnowelzel.de
Hanno Foest
2020-11-30 09:59:05 UTC
Permalink
Post by Andreas Fenner
Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?
Daß es das heute tut ist klar. Ob es das im letzten Jahrtausend (immer)
schon getan hat? Und was davon "sollte" sein? Der Admin sollte wissen,
was er tut :)

Die Nachfrage ist dennoch nett, klar.

Hanno
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith
Christian Corti
2020-11-30 11:48:26 UTC
Permalink
Post by Hanno Foest
Daß es das heute tut ist klar. Ob es das im letzten Jahrtausend (immer)
schon getan hat? Und was davon "sollte" sein? Der Admin sollte wissen,
was er tut :)
Eben. Unter SunOS passiert einfach folgendes:
# fsck /dev/sd12c
** /dev/sd12c
** Currently Mounted on /src
** Phase 1 - Check Blocks and Sizes
[...]

Das System weiß immerhin, daß das FS gemountet ist. Man sollte bei
eventuellen Fragen, ob etwas repariert werden soll, natürlich wissen,
worauf man sich da einläßt.

Christian
Dennis Grevenstein
2020-12-01 15:49:08 UTC
Permalink
Post by Andreas Fenner
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?
Ist halt wie beim Löten. Da fragt der Lötkölben auch nicht, ob man
wirklich was extrem Heisses an diese Stelle halten will. Und im
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."
Kay Martinen
2020-12-01 16:59:15 UTC
Permalink
Post by Dennis Grevenstein
Post by Andreas Fenner
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?
Ist halt wie beim Löten. Da fragt der Lötkölben auch nicht, ob man
wirklich was extrem Heisses an diese Stelle halten will. Und im
Anders herum hat die Sonne auch keiner gefragt ob sie so und nicht
anders "heiß" brennen will. Und wir; als Kinder der Sonne (und des
Universums an sich) wurden auch nicht gefragt. Typisch Götter. Machen
einfach! ;-)
Post by Dennis Grevenstein
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).
Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?

Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).

Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.


Kay
--
Posted via leafnode
Dennis Grevenstein
2020-12-02 01:01:57 UTC
Permalink
Post by Kay Martinen
Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?
Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).
Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.
So kann man es natürlich auch betrachten, aber ich würde auch
sagen, dass man es nicht ganz so philosophisch aufladen muss.
Dahinter steckt ja ein "best practice" Ansatz. Erst die Struktur
mit der stumpfen Seite vom Skalpell freilegen, bevor man was
mit der scharfen Seite durchschneidet. Das ist dann wieder
Handwerk. Piloten verwenden Checklisten. Piloten müssen auch
im Simulator üben, bevor man sie ans Steuer eines Urlausflieger
nach Mallorca setzt.
In der IT gibt es diese Art von Sicherheit nicht unbedingt.
Wer einmal unfallfrei Linux installiert hat, kann morgen schon
Administrator von irgendeiner box werden, wenn es halt kein
anderer machen will. Man will gar nicht drüber nachdenken,
wieviel Software irgendwelchen Zombie-code, von irgendwelchen
Praktikanten geschrieben, enthält, der einfach nicht sterben
will. Ich gebe offen zu, dass ich an der Front auch schuldig
bin. Ich habe keine Ahnung, wie man sowas kulturell besser
lösen könnte, aber vor dem Hintergrund finde ich Sicherheits-
fragen wie "Sind Sie sicher, dass Sie XY formatieren wollen?"
sinnvoll.

Immer noch schön:
https://www.gnu.org/fun/jokes/vaxorcist.html

"SYSMGR: Documentation S...? Oh, you mean the grey binders? They're over
there. (he points to the wall behind the VAXORCIST. The VAXORCIST turns
and we see a closed glass-front bookcase packed with grey binders. A small
red sign on the front of the bookcase reads: "IN CASE OF EMERGENCY, BREAK
GLASS")."

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."
Martin Wohlauer
2020-12-05 05:59:34 UTC
Permalink
Post by Kay Martinen
Post by Dennis Grevenstein
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).
Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?
Och, nach Ende des Gebrauchs bzw. bei völliger Unbenutzbarkeit ist das
doch gar nicht so weit weg von der Wahrheit. Manche landen quasi in der
Verbrennungsanlage, andere werden verbuddelt. Mancher will sich von
seinem inzwischen nicht mehr so ganz brauchbaren Menschen trotzdem nicht
trennen und stellt ihn zum Anschauen trotzdem noch in eine Art Vitrine,
wo wie mancher auch noch kaputte/unbenutzbare alte Computer behält. Aber
wirklich aufgehoben wurden anteilig gesehen nicht so irre viele, die
meisten fliegen raus™... Also die Parallelen sind schon definitiv da. ;-)
Post by Kay Martinen
Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).
Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.
Naja, eigentlich ist der (relativ gut zu begründende) Verdacht der
permanenten Absenz eines Bewusstseins der ausschlaggebende Grund, warum
man das so machen kann. Es gibt aber welche, die der Meinung sind, die
Seele würde mit beschädigt, wenn der Körper beschädigt würde, und daher
verlangen sie, dass man das unterlässt.

Grüßle,

Martin.

Diedrich Ehlerding
2020-11-20 13:24:29 UTC
Permalink
Post by Goetz Hoffart
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.
Ich habe hier noch ein altes Buch "Unix Version 7, System III und System
V" von 1985, das nennt auch diverse Binaries in /etc ( (/etc/getty,
/etc/fsck z.B.)
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Nils M Holm
2020-11-16 09:14:06 UTC
Permalink
Post by Raimund Huemmer
Und ggf. zur Struktur unter /etc? War das in
4.3BSD so ?blich?
Bei einigen 7th-Edition-Derivaten (und ich meine in
7th Edition selbst auch) lagen die administrativen
binaries in /etc. /sbin gab es noch nicht. Coherent, zum
Beispiel, wurde mit /etc/shutdown heruntergefahren (es sei
denn /etc lag in $PATH). fsck, fdisk, getty, mkfs, mount,
passwd, und vieles mehr lag in /etc. Bei BSD war das
anfangs genauso.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Ralph Spitzner
2020-11-21 12:04:09 UTC
Permalink
Raimund Huemmer wrote on 11/15/20 9:17 PM:
[...]
Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Gruss
Raimund
um mal zum Thema zurueckzukommen:
Ich denke das hat wirklich eher mit security by obscurity zu tun, als mit
irgendwelchen dateisystemhirarien, oder philosophien, den wer / folgt kommt so oder so auch durch
irgendwelche eingehaengte dateisysteme...

Allerdings gehoert ping halt root/root und hat das s bit gesetzt, waer also mit irgendwelchen tricks
evtl. dazu zu ueberreden ne #shell herzugeben...
security by obscurity weils halt unter /etc nicht im $PATH liegt....

nur meine 2 Pfennig...

Mfg
-rasp
PS: sorry, falls das schon wer schrub und ich's ueberlesen hab
Michael van Elst
2020-11-21 12:20:26 UTC
Permalink
Post by Ralph Spitzner
security by obscurity weils halt unter /etc nicht im $PATH liegt....
Safety, nicht security. Und versteckt ist es auch kaum.

So wie /sbin, in das man die /etc-Binaries hineinsortiert hat. Nur dass
heutzutage jeder /sbin in den Pfad aufnimmt, auch wenn er nicht als root
arbeitet.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Norbert Narten
2020-11-21 13:09:06 UTC
Permalink
Post by Michael van Elst
So wie /sbin, in das man die /etc-Binaries hineinsortiert hat. Nur dass
heutzutage jeder /sbin in den Pfad aufnimmt, auch wenn er nicht als root
arbeitet.
/sbin steht für "Static Binaries". Das sind Binaries, die ohne zusätzliche
Libraries auskommen. Hat im übrigen die gleiche Funktion wie /bin bei dem
System-Start / Wartung (z.B nach einem init s) oder im Notfall, um dann
noch ein Minimal-System zur Verfügung zu haben. Die Pfade sind deswegen
in PATH enthalten, weil es auch reguläre Programme sind, die jeder nutzen
kann / darf.

Norbert
Michael van Elst
2020-11-21 14:10:50 UTC
Permalink
/sbin steht für "Static Binaries".
4.4BSD hat /sbin und /usr/sbin eingeführt, hatte aber noch keine shared
libraries. Administrative Kommandos, die z.B. bei 4.3BSD noch in /etc
lagen, wurden nach /sbin bzw. /usr/sbin verschoben.

SunOS 4 (da hat SunOS shared libraries eingeführt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.

SysVR4 hatte seine shared libraries in /usr/lib (/lib gab es nicht).
Alle Binaries in /bin und /sbin waren dynamisch gelinkt (z.B. gegen
/usr/lib/libc.so.1) weswegen /usr kein eigenes Filesystem mehr sein
konnte.

Aktuell sind alle Binaries in /sbin dynamisch gelinkt (bei Linux
mit Ausnahme von ldconfig aus verständlichen Gründen).
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Michael Bäuerle
2020-11-22 10:07:57 UTC
Permalink
Post by Michael van Elst
Post by Norbert Narten
/sbin steht für "Static Binaries".
4.4BSD hat /sbin und /usr/sbin eingeführt, hatte aber noch keine shared
libraries. Administrative Kommandos, die z.B. bei 4.3BSD noch in /etc
lagen, wurden nach /sbin bzw. /usr/sbin verschoben.
Demnach steht das "s" in sbin dann für "Superuser".


[Umlaut im Zitat repariert]
Christian Corti
2020-11-23 08:34:35 UTC
Permalink
Post by Michael van Elst
/sbin steht für "Static Binaries".
So habe ich das auch gelernt.
Post by Michael van Elst
SunOS 4 (da hat SunOS shared libraries eingeführt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.
Das hier immer noch laufende SunOS 4.1.1 hat in /etc nur dynamische
Binaries. In /sbin sind alle Binaries statisch:
# ldd /sbin/*
/sbin/hostconfig: statically linked
/sbin/hostname: statically linked
/sbin/ifconfig: statically linked
/sbin/init: statically linked
/sbin/intr: statically linked
/sbin/mount: statically linked
/sbin/sh: statically linked

Christian
Kay Martinen
2020-11-23 13:43:13 UTC
Permalink
Post by Christian Corti
/sbin steht für "Static Binaries".
So habe ich das auch gelernt.
Dann ist das mein Problem (der späten Geburt) das ich sbin immer als
"secure" o.ä. Verstanden habe. Sprich: tools die nur root o.a. admin
user benutzen (dürfen). Aber ich muß auch zugeben das ich das nie im
Detail nachprüfte. Seit ca. 1990 als ich mit Linux anfing... und ein
Unix/Minix hab ich nie benutzt.

Oder kann es sein das Linux da <> Unix <> Minix ist?

Kay
--
Posted via leafnode
Dennis Grevenstein
2020-12-02 01:56:36 UTC
Permalink
SunOS 4 (da hat SunOS shared libraries eingef?hrt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.
Hat diese Abhaengigkeit von shared libraries an der Stelle nicht
mehr damit zu tun, dass keine Abhaengigkeiten in /usr vorkommen
duerfen, weil man das System noch retten koennen muss, wenn /usr
nicht gemountet ist? Die libc liegt docch unter /usr/lib wenn ich
mich richtig erinnere.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Kay Martinen
2020-12-02 07:11:20 UTC
Permalink
Post by Dennis Grevenstein
SunOS 4 (da hat SunOS shared libraries eingef?hrt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.
Hat diese Abhaengigkeit von shared libraries an der Stelle nicht
mehr damit zu tun, dass keine Abhaengigkeiten in /usr vorkommen
duerfen, weil man das System noch retten koennen muss, wenn /usr
nicht gemountet ist? Die libc liegt docch unter /usr/lib wenn ich
mich richtig erinnere.
Bei meinem aktuellen Linux hier finde ich 'libc' auf die Schnelle unter
/lib obwohl unter /usr/lib u.a. auch vieles liegt. Das scheint aber eher
Text oder zusätzliches zu sein.

Hat sich das evtl. nicht bewährt?

Kay
--
Posted via leafnode
Dennis Grevenstein
2020-12-02 11:17:06 UTC
Permalink
Post by Kay Martinen
Bei meinem aktuellen Linux hier finde ich 'libc' auf die Schnelle unter
/lib obwohl unter /usr/lib u.a. auch vieles liegt. Das scheint aber eher
Text oder zus?tzliches zu sein.
Hat sich das evtl. nicht bew?hrt?
ein aktuelles Linux ist halt nochmal was anderes als ein echtes Unix
mit Wurzeln in den 80ern :-)
Daher koennte man schon sagen, dass sich die alte Struktur nicht bewaehrt
hat.

Ich habe gerade mal Solaris 2.4 angeguckt. Da gibt es in /sbin
auch dynamisch gelinkte Dateien. /bin ist ein symlink nach /usr/bin.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Lesen Sie weiter auf narkive:
Suchergebnisse für 'Geschichte von "ping" (in memoriam Mike Muuss)' (Newsgroups und Mailinglisten)
32
Antworten
startup notification
gestartet 2002-10-23 19:34:29 UTC
xdg@lists.freedesktop.org
79
Antworten
[clug] The harsh realities of CLUG
gestartet 2010-05-18 11:31:57 UTC
linux@lists.samba.org
138
Antworten
Jörg Haider mit Bombe ermordet...
gestartet 2008-10-11 08:01:42 UTC
de.soc.politik.misc
17
Antworten
[Openvpn-users] Some clients work, some don't (redux)
gestartet 2005-10-24 11:23:10 UTC
openvpn-users@lists.sourceforge.net
14
Antworten
firewall for a client
gestartet 2004-12-06 02:51:28 UTC
debian-firewall@lists.debian.org
Suchergebnisse für 'Geschichte von "ping" (in memoriam Mike Muuss)' (Fragen und Antworten)
6
Antworten
Ängstlich während Telefonkonferenzen
gestartet 2017-09-04 16:18:17 UTC
zwischenmenschlich
4
Antworten
Was ist der Unterschied zwischen Hefe und Bakterien?
gestartet 2011-01-25 23:32:01 UTC
zuhause gebraut
Nicht verwandte, aber interessante Themen
15
Antworten
Wie gehe ich mit einem Kandidaten um, der Gott zwölf Mal in seiner Bewerbung erwähnt?
gestartet 2020-07-23 13:33:31 UTC
16
Antworten
Ist es üblich, digitale Notizen (Folien oder handschriftlich) für Schüler bereitzustellen?
gestartet 2014-08-19 15:07:00 UTC
6
Antworten
Sollte ich ein Empfehlungsschreiben von meiner Mutter bekommen, die eine berühmte Forscherin auf meinem Gebiet ist?
gestartet 2017-09-02 05:40:51 UTC
6
Antworten
Hat ein Dozent das Recht, Studenten daran zu hindern, ihre Notizen zu veröffentlichen?
gestartet 2017-01-31 15:39:34 UTC
15
Antworten
Ist es angebracht, einem Professor per E-Mail mitzuteilen, dass Sie den Unterricht genossen haben, nachdem Sie ihn gut gemacht haben?
gestartet 2018-04-20 06:29:44 UTC
Loading...