SuSE löst das clever:

Das ist zB bei einer NVidia-Treiberinstallation ganz praktisch:Man switched in runlevel 3 - damit X unten ist - und installiert.

runlevel2 ist ganz praktisch, wenn du Systemarbeiten machen willst, bei denen sich kein User via Netz connecten soll
(Egal ob via Shell, Oracle, Postgres, ...) Also mehrere runlevel sind schon
was feines...  

• Du lügst
  
• Du hast eine andere Version
  
• Aus einem mir nicht bekanntem anderen Grund verhalten sich die Pakete anders.
  

-s Specify user's login shell. The default for  normal
              user  accounts is taken from /etc/default/useradd/,
              the default for system accounts is /bin/false.

und genau wenn die "fragesession" beginnt, ziehst das netzwerkkabel. it's not
rocket science

yeah, but it's bloody stupid to have to do it...

Aber Kabel ab- und wieder anstecken ist zeitlich ungefähr der gleiche Aufwand
wie ein paar Ports in der Firewall aufzumachen. Somit imho wieder
Geschmackssache.

Jedoch gibt es mehr Leute auf der Welt, denen ich das Abstecken eines Kabels
zutraue, als es Menschen gibt, denen ich den versierten Umgang mit Firewalls
zutraue.

aber nochmal: wer setzt seine maschine mit einer public ip auf? ausserhalb eines gesicherten netzwerkes? die wird in sicherer umgebung aufgesetzt und dann umgesiedelt, somit spart man sich den ganzen stress.

nicht als kritik auffassen, aber wenn man schon so penibel drauf schaut, daß security policies einhält, dann sollte man auch die als best practice geltende methode mit der obig erwähnten umsiedlung nach der installation einhalten. somit spart man sich nämlich die paranoia firewall out of the box, das sollte nämlich eine andere box oder ein router übernehmen, wenn wir das ganze schon auf die professionelle angehen wollen

und btw: die suse firewall kommt vorkonfiguriert daher, aber sie ist nicht intelligent genug, ohne manuelles nachhelfen ports freizuschalten, die von einem installierten paket benötigt werden. habe zuletzt einen mailserver auf suse für einen freund gebastelt, da stolperte ich nach langer fehlersuche über das verhalten. aber obs jetzt auf die eine oder andere art und weise suboptimal ist, macht wenig unterschied imho. es ist weder das eine noch das andere besser oder schlechter, es ist einfach nur anders.

Sprich wenn man von anfang an konsequent nix als shell angibt, kann man über das setzen der default shell systemweit alle user mit einer zeile migrieren (umstellung von bash auf zsh oder sowas).
somit ansichtssache. it's not a bug, it's a feature

perl -anF: -e '$F[-1]=~s#/bin/bash#/bin/neu#;print join(":",@F);'< /etc/passwd > /etc/passwd.neu

sed "s/\/bin\/bash/\/bin\/neu/;" < /etc/passwd > /etc/passwd.neu

useradd ist ürbigens afair nicht bei suse dabei (damit die leute auch brav
yast verwenden, weil die syntax von useradd nicht jedermanns sache ist)

XYZ ist besser, sonst würden nicht die meisten YY jetzt auf AA setzen!

Aber der Installationsvorgang selbst sowie die "Basissachen" wie grep,
mkinitrd et al sollten klappen (was unter SuSE9.2prof trotz aller
onlineupdates net ist)..

Aber wenn du der gentoo-pro bist

FEATURES="loadpolicy"

Ich will nix weiter...
Als eine fehlerfreie Distri.

Bei mir kommt das Ethernetkabel sowieso erst dann rein wenn alles fertig ist.

>reiserfs  ->   warum bitte nimmst ein reiserfs warum kein ext2 oder ext3

datenwiederherstellung ist ext2 bzw ext3 freundlicher.

nd mich schreckt reiserfs schon ab weil es (angeblich) vom herrn reiser von
der firma SuSE ist.

Also grundsätzlich werden Bad blocks
ja mal remapped...Und die Platte meldet dem System die Änderung.Es passiert
also praktisch nie, daß eine [gute] Platte ohne Vorwarnung stirbt -
insbesondere seit S.M.A.R.T.

Kurzum:Gegen Hardwarefehler absichern ist sicher sinnvoll - nur ist
die Auswahl des Dateisystems (dein Algo: eines mit fixer
inoden/Datenzuordnung) IMHO der falsche Ansatz... Journalling ist aber trotz
allem unverzichtbar geworden, einerseits weil das System manchmal ja echt so
stehen kann, daß nur ein Hardreset hilft - andererseits weil ja wirklich mal
der FI fallen kann.Verzicht auf Journalling erinnert dann schon an Bumsen ohne
Schutz... Möglich, daß es manchen mehr Spaß macht - aber soooo mutig bin ich
denn dann auch nicht  

Das einzige, was ein Journalling FS gewährleistet, sind korrekte Metadaten.

So sehr ich auch deinem Posting zustimme - das ist grob unrichtig... und vielleicht kam daher auch dein (nur IMHO falscher Trugschluß), daß sie
überbewertet sind.

Ext3 kann - je nach verwendetem journalling-mode - auch die
Datenintegrität gewährleisten,

genauso AFAIK xfs

So oder so - es geht immer um den "Worst
case" beim Absichern - der darf niemals gleichbedeutend mit Untergang
sein.Worst case bei ext2 ist eine wirklich mies beschädigte Metadatenstruktur
- PLUS Datenverlust. Worst Case bei journalling Dateisystemen sind
/ausschließlich/ beschädigte Datenfiles - und zwar nur die, die sich grad
/dirty/ im Buffer cache tummelten.

Worst Case bei journalling Dateisystemen,
die sich auch um die Nutzdaten kümmern ist etwas langsamere Performance (und
nicht einmal das zwingend, es gibt ja auch FS, die mit voller Performance
fahren und nur für Dateisystem-Operationen mehr Platz brauchen).

So oder so -
ext2 ist /seeehr/ toll, weil schnell und cpu-sparsam - und ich verwende es
echt gerne und oft für ro-Dateisysteme (bei mir zB /usr, /bin, /usr/sbin,
...)Bei allem anderen - no chance.Denn angenommen, mein /nutzdaten ist bei
ext2 gemountet und das System crashed - warum auch immer.Dann bedeutet der
Reboot /lange/ Dateisystemchecks...Und auch dann kann ich mir nicht so einfach
sicher sein, ob alles ok ist..

Wäre nicht das erste mal, daß e2fsck "alles ok"
meldet - und nach einem Fileanlegen hängt der Kernel, weil es eben doch nicht
ganz ok war und ein pointer ins nix zeigte. (Ok, das ist mir in 15 Jahren Unix
genau 2x passiert  ).

So oder so muß ich bei "normalen" journalling-FS nachher
die Nutzdaten prüfen - soweit möglich zB anhand von md5-summen,

... - nur muß
ich bei ext2 zusätzlich länger warten beim Start und hab einen Fehlerpunkt
mehr.Dieser "Fehlerpunkt" endete bei meinen Abstürzen (die ja doch mehr als 2
waren) i.d.R. mit verlorenen Dateiketten... Du bist unter unix zwar net ganz
so aufghaut wie unter DOS mit den "File0001.chk"-Rsultaten

- trotz allem
erkenn' ich den Vorteil vom Verzicht auf journalling nicht.Wenn du eh' mit
ext2 zufrieden bist - und auf ext3 /nur/ wegen dem Performance-penalty
verzichtest - dann leg' doch das journal einfach auf eine andere Platte...

Denn wenn die App sooo heikel ist, daß die paar µsecs im Zugriff wirklich eine
Überlegung von Dir wert sind - wie schlimm muß das dann erst mit den vielen
Mins bei einem recovern aussehen ?  

-rwxr-xr-x  1 root root 628684 Sep  6  2004 /bin/bash

Hab jetzt den ganzen Tread mal überflogen. - Und da kamen tatsächlich einige interessante Argumente deinerseits. Allerdings finde ich, Du solltest deine Bedenken eher mit den Debian-Entwicklern mitteilen, als das ganze hier lang und breit zu diskutieren. Oder zumindest in einem Debian-spezifschen Forum diskutieren.

"Es ist also weder ein System für Anfänger noch für Experten." So wie ich das beurteilen kann bist Du ja auch weder das eine noch das andere - sollte also genau dein Ding sein

... aber wenn noch eine Paketselektion dabei wäre, und mehr Möglichkeiten was die Dateisysteme&Partitionen angeht könnte das schon was werden.

Das mit dem benötigten Platz für die Partitionen ist so eine Sache, das hängt halt vorwiegend vom Einsatzzweck des Systems ab, ich konnte da noch keinen grünen Zweig finden.

Danke für die Info - damit fällt's für mich schon aus...

SuSE zeigt dir bei der Paketauswahl, wie voll deine Dateisysteme werden - und
warnt dich. Damit kannst du rechtzeitig korrigierend eingreifen (Die Anzeige
sieht ca. so aus wie kdf). Das ist super - und sollte von den anderen
übernommen werden.