Re: Debian-Betriebssysteme
Hallo,
Dirk Haage <dirk.haage@web.de> writes:
> 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.
Naja, davon habe ich schonmal gehoert ;).
>> > 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.
>> 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)
Ack.
> nicht der Fall ist. Ein falscher Treiber zerschisst das ganze Systeme,
> die Reihenfolge beim Installieren ist wichtig usw.
U.a. darum ist es fuer meine Anforderungen auch unbrauchbar.
> 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?
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.
[...]
> 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.
>> > 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
;).
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: