[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian-Betriebssysteme



Hi Michael,

Am Die, 2002-07-16 um 23.32 schrieb Michael Welle:
> Dirk Haage <dirk.haage@web.de> writes:
> > Am Die, 2002-07-16 um 17.40 schrieb Michael Welle:
> >> Dirk Haage <dirk.haage@web.de> writes: 

> >> Wenn sich Wartbarkeit auf die Quellen bezieht, ist es das Problem des
> >> Entwicklers. Wenn der im Chaos leben kann, dann bitte. Das ist zwar
> >> kein ingenieurmaessiges Vorgehen und weckt nicht unbedingt Vertrauen
> >> in das Produkt, aber wenn es sich an die Spec haelt, ist es gut.
> >
> > Das ist das eine, wie man sieht haben so ziemlich alle Betriebsysteme
> > mit Makrokernel solche Probleme (Windows in allen Bereichen, aber auch
> welche Probleme?

Naja, Abstürze, Bluescreens, Speicherfehler, großes, mit der Zeit
langsam gewordenes System usw.

> > Linux: viel in nicht portierbarem Assembler (an unnötigen Stellen),
> > willkürlich gezogene Kernelschnittstellen...)
> Sicherlich sind grosse Projekte besser in den Griff zu bekommen, wenn
> man ingenieurmaessig vorgeht und Erkenntnisse aus der Softwaretechnik
> beachtet. Das ist unabhaengig von Mikrokern oder nicht. Das haengt

Stimmt im allgemeinen. Da es aber hier um Betriebssystemkerne ging...

> wohl eher von kaufmaennischen Zwaengen ab. 

? 

> Hier verschwimmen wohl die Grenzen zwischen dem Anwender eines
> Produktes und dem Entwickler. Ich denke immer noch, das mich als
> Anwender nicht interessiert, wie es in einer Software aussieht, wenn
> sie nach den Spec fkt.

Jain. ;) Natürlich will "der Anwender" nur, das alles so funktioniert,
wie die Spec es sagt. Alles unter der Oberfläche interessiert eher
selten (ist ja auch beim Videorecorder, Handy, whatever so)
Zudem soll es aber auch deterministisch und nachvollziehbar so laufen,
was zumindest bei Windows (zumindest da sollten wir uns einig sein)
nicht der Fall ist. Ein falscher Treiber zerschisst das ganze Systeme,
die Reihenfolge beim Installieren ist wichtig usw.
Linux hat aber ähnliche Probleme, ein Beispiel aus eigener Erfahrung:
IDE-CDROM geht ohne Probleme, IDE-SCSI beim gleichen Gerät friert das
System ein, Kernel-Patch-xyz eingebaut, schon geht's wieder. Warum?

> > Aber auch für den Administrator wird es so auf Dauer immer
> > unübersichtlicher.
> >
> >> > Und ein einfaches Konzept ist immer stabiler
> >> > und wartbarer als ein komplexes, oder?
> >> Noe.
> >
> > Dann liefer mal ein Beispiel. Immerhin hat sich Unix doch
> Ein schlecht umgesetztes einfaches Konzept muss nicht wartbarer als
> ein gut umgesetztes komplexes Konzept sein. 

OK, dann drück ich es anders aus: 
Es ist einfacher, bei einem einfachen Konzept den Überblick zu behalten
und es zu pflegen als bei einem komplexen.

> Oder bei Synchronisierung
> (Semaphore, Monitore, etc) finden sich wohl auch Gegenbeispiele.

Wieso? Das ist ein Konzept, von der Struktur und der Idee einfach. Oder
was möchtest du damit ausdrücken?

> > "small/simple
> > is beautiful" auf die Fahne geschrieben, und das nicht ohne Grund. Das
> > Beispiel mit den Sprachenvergleich kennt wohl auch jeder
> > (japanisch<->englisch). Suse wird nicht ohne Grund von ihrer
> > rc.config-Geschichte weg sein usw.
> > Mir fällt jedenfalls kein Beispiel ein, wo ein komplexes System
> > übersichtlicher und damit stabiler und wartbarer ist als ein einfaches.


> >> >> > Und wenn FAT nicht vernünftig funktioniert, möchtest du auch nicht, das
> >> >> > beim Versuch, Daten von ner Diskette zu lesen, alles abschmiert,
> >> >> > oder?
> >> >> Wenn das fs solche Fehler nicht abfaengt und dem Benutzer vernuenftig
> >> >> klar macht, ist das fs schlicht und einfach defekt und unbrauchbar. 
> >> >
> >> > Das mag ja sein, aber warum soll es deswegen das ganze System mit
> >> > reinreissen?
> >> Soll nicht, aber kann.
> >
> > Das ist aber eindeutig Windows-Denken. Es gibt genau 2 Gründe für
> Ich meine nicht kann im Sinne von 'das war jetzt sooo schlimm, da kann
> das Teil schonmal die Graetsche machen' sonder eher in Form von 'das
> kann mir egal sein, wenn es aus dem Grunde die Graetsche macht'. Ich
> sehe das immer noch so. Wenn auf einem Produktionssystem ein Fehler
> auftritt, der nicht erkannt oder gehandelt wird, ist das nicht zu
> gebrauchen. 

Hmm, das sehe ich anders. Kehren wir zum obigen Beispiel zurück: Die
ersten Tests waren ziemlich frustierend, da nix ging und Fehlersuche war
fehlanzeige, da das System ja tot war, keine Kernelausgaben, keine Logs,
nix.
Was ich sagen will: Der Fehler soll ja deswegen nicht einfach
unbehandelt, unerkannt bleiben, sondern er soll den Betrieb nicht
stören. Sieh das ganze aus einer anderen Perspektive: Alles im Betrieb
sind Dienste. Wenn jetzt auf deinem Rechner der Dienst "ftp" versagt,
laufen die Dienste "ssh", "http" u.s.w trotzdem noch. Denn eigentlich
ist ftp auch nur ein Remote-FS-Dienst wie NFS, also ein Betriebsmittel,
genauso wie beliebige FS, SCSI-Treiber usw.

> > ein
> > komplett abstürzendes System: 
> > - kaputte Hardware in den lebenswichtigen Systemen (Prozessor, Speicher)
> > - ein Fehler im (micro)-Kernel, also beim Interrupt-Handling, der
> > Prozesskommunikation oder dem Scheduling
> >
> > nichts für ungut
> Kein Problem.
Genau, solange alles sachlich bleibt ;)

/dirk


--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-request@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl)



Reply to: