Re: Debian-Betriebssysteme
Moin,
Am Mit, 2002-07-17 um 13.17 schrieb Michael Welle:
> Dirk Haage <dirk.haage@web.de> writes:
> > 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:
> >> > 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.
> >
> > ?
> Der Grund, warum Konzepte der ST nicht oder nur wenig beachtet werden,
> duerfte bei kommerziellen Projekten oft der Zwang sein, schnell am
> Markt zu sein, billig zu sein, ST kostet Leute und Geld. Zeitdruck
> fuehrt dazu, das beim Entwurf oder der Implementierung schonmal
> geschlabbert wird und hacks eingefuehrt werden etc. Vermutlich liegt
> da das Problem von Kompilaten aus Redmont etc.
Achso, du meinst die Fehler der BWLer. Nur ist das ne
Milchmädchenrechnung. Denn auf Dauer kosten die Hacks mehr Geld, als sie
vorher durch die Zeitersparnis gespart haben. Aber das ist ein völlig
anderes Thema.
Auf der anderen Seite sollten man dann aber eigentlich erwarten, das bei
den vielen Informatiker und anderen fähigen Leuten in der OSC, freie
Software viel häufiger nach vernünftigen Entwicklungskonzepten
entwickelt werde würde.
> >> 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?
> Prinzipiell kann ich ein Sync-Problem mit Semaphoren oder mit
> Monitoren loesen. Monitore sind ein hoeherwertiges, komplexeres
> Konzept als Semaphore. Trotzdem sollten Loesungen mit Monitoren
> uberschaubarer und wartbarer sein (bei qualitativ gleicher
> Umsetzung) => ein einfaches Konzept bedeutet nicht immer Uebersicht
> und bessere Wartbarkeit.
OK, Punkt für dich, oder besser: ein halber. ;)
ich würde Semaphore, Kanal, Monitor usw. als an sich eigenständige,
einfache Konzepte bezeichnen (auch wenn sie untereinander betrachtet
verschiedene Komplexität enthalten). Etwas anderes wäre (wenn auch nicht
real vorhanden) ein Kanal-Semaphoren-Monitor, also ein Komplex, der alle
Funktionalitäten auf einmal zur Verfügung stellt. Ist im Übrigen wieder
Unix-Philosophie: ein Programm macht eine Sache und die Programme können
miteinander kombiniert werden. Warum sowas also im User-Bereich machen
und auf Kernel-Ebene das Konzept über den Haufen werfen?
> [...]
> > 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.
> Ja, so gesehen hast Du schon recht ;). Nur bei Mikrokern vs mono. Kern
> ist es imho etwas anders. Dort ist der Kern in Prozesse zerlegt
> (zB. fs, mm, skeduling etc). Wenn davon einer die Graetsche macht, hat
> man meist es Pech. Fuer ssh, ftp etc. aendert sich bei beiden Konzepten
> eher nix.
Nö, eben genau nicht. Solange die untersten Prozesse bestehen bleiben,
ist alles ok, da kann alles andere gerne draufgehen, wird einfach neu
gestartet. Desweiteren lassen sich Fehler in den Mini-Kernel-Prozessen
meist viel einfacher finden. Und stell die die Möglichkeiten vor: Hey,
ich find das Scheduling doof, ich möchte hier was mit Realtime-fähigkeit
oder nen einfachen FCFS, ich tausch mal eben den Scheduling Prozess aus.
> >> > 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 ;)
> Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben
> ;).
/dirk
--
dirk haage | dh@a-n-t-s.de
advanced network technologies
phone +49 (0)30 85 07 06 12
mobile +49 (0)172 9 26 32 18
--
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: