Re: Debian-Betriebssysteme
Sers,
Dieter Schuster <didischuster@gmx.de> writes:
> Tach auch!
>
> Am Mit, den 17 Juli 2002, schrieb Michael Welle:
>> Dirk Haage <dirk.haage@web.de> writes:
>> > Am Die, 2002-07-16 um 23.32 schrieb Michael Welle:
>> >> 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,
> ^^ nehme an Du meinst
> SicherheitsTechnik?!
Softwaretechnik.
>> 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.
>
> Dann müsste Linux aber in allem Bereichen sauber programmiert sein?!
Noe, der Umkehrschluss gilt nicht automatisch.
> Oder sollte man jetzt feststellen, dass z.B. NetBSD sauber
> programmiert ist, und Linux nicht, da die Industrie Linux einsetzt und
> gewisse Entwicklungen unter Druck gesetzt hat?!
Hier kann ich Dir nicht mehr so recht folgen.
>> >> Hier verschwimmen wohl die Grenzen zwischen dem Anwender eines
>> >> Produktes und dem Entwickler. Ich denke immer noch, das mich als
>
> Bei freier Software ist das gängig, das Anwender auch Entwickler sind,
> daher sollten auch beide Betrachtet werden.
Nein. Nicht im Kontext zu diesem thread. Es ging um mono. Kern vs
Mikrokern und ob sich daraus bessere Wartbarkeit etc. ableiten
laesst etc. Ohne genau Zahlen zu kennen, bezweifle ich auch, das die
meisten Anwender freier Software auf Entwickler sind.
>> 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.
>
> Weißt Du wo ich dazu mehr Information finden kann?
Zu Semaphoren? Betriebssystem-Buecher, zB. bei AST. Aber der kann sich
eher fuer Mikrokerne begeistern. Oder zu ST und Wartbarkeit? Da weiss
ich gerade nix konkretes. Gibt aber Buecher ohne Ende.
>> > 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.
>
> Wenn aber der ext2-Treiber im Kernelspace läuft und sich aufhängt ist
> kannst Du das System vergessen. Läuft er hingegen im Userspace als
> Prozess läuft dein System weiter und mit etwas Glück (z.b. / ist ein
> anderes Dateisystem), kannst Du den Server (Treiber) neustarten,
Das klingt aber nach einem schwer konstruierten Fall.
VG
hmw
--
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: