Re: Debian-Betriebssysteme
Am Mit, 2002-07-17 um 20.44 schrieb Steffen Schulz: > http://www.gnu.org/software/hurd/hurd-talk.html#TOCmic > (Plus die folgenden 3 Abschnitte) > > Wenn dir die Vorteile von dieser Arbeitsteilung immer noch nicht > bewusst sind, hilft es vielleicht sich an Windows95 zu erinnern. > Ein Programm stürtzt ab und der Rest schliesst sich ihm an. > Es ist doch dumm, darauf zu vertrauen, dass etwas fehlerfrei > funktioniert, wenn man stattdessen auch völlig unabhängig davon > sein kann. Mir fällt da der wuftpd-Bug ein, der unter Hurd nicht > exploitbar war. Fehler passieren. Durch die klare Aufgabenteilung > werden sie selbst und ihre Konsequenzen minimiert. Und Fehler lassen sich leichter lokalisieren, somit also schneller beheben. Wieder ein Argument für SysAdmins (und nicht-Entwickler) > > >> Kein Problem. > > > Genau, solange alles sachlich bleibt ;) > > Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben > Popkorn, aber trotzdem ärgerlich... Wenn du es nicht willst, ich nehm es gerne... /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Am Mit, 2002-07-17 um 20.31 schrieb Michael Welle: > > 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. Wenn du den Rest da gelassen hättest, dann nicht. Für so Dinge wie Root-FS, IDE (oder SCSI, je nachdem) und sowas ist das kritisch, bei Sound, Maus ... eben nicht. /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Herzlich Willkommen in dieser durchaus interessanten Runde... ;) Am Mit, 2002-07-17 um 19.02 schrieb Dieter Schuster: > Am Mit, den 17 Juli 2002, schrieb Michael Welle: > > Dirk Haage <[EMAIL PROTECTED]> 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?! Hier geht's um Softwareentwicklung, als heisst ST SoftwareTechnik (in einem Satz ausgedrückt: Wie sollte Softwareentwicklung in vernünftig gemacht 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. > > Dann müsste Linux aber in allem Bereichen sauber programmiert sein?! > 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?! Nö, denn da hält sich auch keiner an die Konzepte. Keine eindeutigen, sinnvollen Schnittstellen, keine Modularität, keine Funktionsbeweise (ich sag nur Hoare ;) ) usw. > > >> 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. Nö, ist genauso wie überall anders. Einzig die Zahl der Leute, die in irgendeiner Art programmieren können, dürfte etwas höher sein. > > 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? In jedem Buch über BS und Grundlagen der Informatik. Vielleicht ist das ja schon mal ein Anfang, auch im Bezug auf OS-Design: http://kbs.tu-berlin.de/teaching/ws2001/bs/bs_index.htm Kapitel 5 ist Prozesskomunikation, da sind IIRC auch Monitore erklärt > 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, oder > gar eine neue, fehlerfreie Version installieren, und das während dem > Laufen. Bei Dateisystem ist das natürlich viel unwahrscheinlicher aber > bei anderen Treibern (Sound, Graphik, CD-ROM, Tape, usw.) sollte man > das System doch recht gut retten können. Genau das meine ich. Der Treiber für deine Maus ist auch nix anderes als ein Dienstleister, so wie ein Webserver. > > >> > nichts für ungut > > >> Kein Problem. > > > Genau, solange alles sachlich bleibt ;) > > Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben > > ;). > > Gilt das auch für Kekse :-) /dirk -- dirk haage| [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Moin, Am Mit, 2002-07-17 um 13.17 schrieb Michael Welle: > Dirk Haage <[EMAIL PROTECTED]> writes: > > Am Die, 2002-07-16 um 23.32 schrieb Michael Welle: > >> Dirk Haage <[EMAIL PROTECTED]> 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| [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
On 020717 at 14:34, Michael Welle <[EMAIL PROTECTED]> wrote: [sorry wegen der pMail...] > Dirk Haage <[EMAIL PROTECTED]> writes: > > 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. > > > 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. http://www.gnu.org/software/hurd/hurd-talk.html#TOCmic (Plus die folgenden 3 Abschnitte) Wenn dir die Vorteile von dieser Arbeitsteilung immer noch nicht bewusst sind, hilft es vielleicht sich an Windows95 zu erinnern. Ein Programm stürtzt ab und der Rest schliesst sich ihm an. Es ist doch dumm, darauf zu vertrauen, dass etwas fehlerfrei funktioniert, wenn man stattdessen auch völlig unabhängig davon sein kann. Mir fällt da der wuftpd-Bug ein, der unter Hurd nicht exploitbar war. Fehler passieren. Durch die klare Aufgabenteilung werden sie selbst und ihre Konsequenzen minimiert. > >> Kein Problem. > > Genau, solange alles sachlich bleibt ;) > Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben Popkorn, aber trotzdem ärgerlich... mfg pepe PS: Der Spruch, das Hurd zu spät kommt, erinnerte mich irgendwie an "Linux is obsolete." :) -- What I don't understand is you, God. - Serial Experiments Lain -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Sers, Dieter Schuster <[EMAIL PROTECTED]> writes: > Tach auch! > > Am Mit, den 17 Juli 2002, schrieb Michael Welle: >> Dirk Haage <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Tach auch! Am Mit, den 17 Juli 2002, schrieb Michael Welle: > Dirk Haage <[EMAIL PROTECTED]> 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?! > 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?! 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 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. > 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? > > 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, oder gar eine neue, fehlerfreie Version installieren, und das während dem Laufen. Bei Dateisystem ist das natürlich viel unwahrscheinlicher aber bei anderen Treibern (Sound, Graphik, CD-ROM, Tape, usw.) sollte man das System doch recht gut retten können. > >> > nichts für ungut > >> Kein Problem. > > Genau, solange alles sachlich bleibt ;) > Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben > ;). Gilt das auch für Kekse :-) Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg13038/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Hallo, Dirk Haage <[EMAIL PROTECTED]> writes: > Hi Michael, > > Am Die, 2002-07-16 um 23.32 schrieb Michael Welle: >> Dirk Haage <[EMAIL PROTECTED]> writes: >> > Am Die, 2002-07-16 um 17.40 schrieb Michael Welle: >> >> Dirk Haage <[EMAIL PROTECTED]> 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 be
Re: Debian-Betriebssysteme
Hi Michael, Am Die, 2002-07-16 um 23.32 schrieb Michael Welle: > Dirk Haage <[EMAIL PROTECTED]> writes: > > Am Die, 2002-07-16 um 17.40 schrieb Michael Welle: > >> Dirk Haage <[EMAIL PROTECTED]> 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, als
Re: Debian-Betriebssysteme
Hallo, Dirk Haage <[EMAIL PROTECTED]> writes: > Moin, > Am Die, 2002-07-16 um 17.40 schrieb Michael Welle: >> Dirk Haage <[EMAIL PROTECTED]> writes: >> > Am Die, 2002-07-16 um 01.07 schrieb Michael Welle: > >> >> naja, es ging um ein Produktionssystem. Da interessiert mich das >> >> nicht. Darum zaehlt auch die moeglicherweise bessere Wartbarkeit nur >> >> halb. >> > >> > Da machst du es dir aber einfach. Wartbarkeit möchte ich auch bei einem >> > Produktionssystem haben. >> 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? > 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 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. > 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. Oder bei Synchronisierung (Semaphore, Monitore, etc) finden sich wohl auch Gegenbeispiele. > "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. > 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. VG hmw -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Moin, Am Die, 2002-07-16 um 17.40 schrieb Michael Welle: > Dirk Haage <[EMAIL PROTECTED]> writes: > > Am Die, 2002-07-16 um 01.07 schrieb Michael Welle: > >> naja, es ging um ein Produktionssystem. Da interessiert mich das > >> nicht. Darum zaehlt auch die moeglicherweise bessere Wartbarkeit nur > >> halb. > > > > Da machst du es dir aber einfach. Wartbarkeit möchte ich auch bei einem > > Produktionssystem haben. > 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 Linux: viel in nicht portierbarem Assembler (an unnötigen Stellen), willkürlich gezogene Kernelschnittstellen...) 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 "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 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 /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Sers, Dirk Haage <[EMAIL PROTECTED]> writes: > Am Die, 2002-07-16 um 01.07 schrieb Michael Welle: > >> > Naja, das ist doch ein bisschen unpraktisch, oder? Du arbeitest und >> > entwickelst vielleicht gerade einen Treiber für ein FS, dann stört >> > das. >> naja, es ging um ein Produktionssystem. Da interessiert mich das >> nicht. Darum zaehlt auch die moeglicherweise bessere Wartbarkeit nur >> halb. > > Da machst du es dir aber einfach. Wartbarkeit möchte ich auch bei einem > Produktionssystem haben. 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. > Und ein einfaches Konzept ist immer stabiler > und wartbarer als ein komplexes, oder? Noe. >> > 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. VG hmw -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Am Die, 2002-07-16 um 01.07 schrieb Michael Welle: > > Naja, das ist doch ein bisschen unpraktisch, oder? Du arbeitest und > > entwickelst vielleicht gerade einen Treiber für ein FS, dann stört > > das. > naja, es ging um ein Produktionssystem. Da interessiert mich das > nicht. Darum zaehlt auch die moeglicherweise bessere Wartbarkeit nur > halb. Da machst du es dir aber einfach. Wartbarkeit möchte ich auch bei einem Produktionssystem haben. Und ein einfaches Konzept ist immer stabiler und wartbarer als ein komplexes, oder? > > > 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? /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Sers, Dirk Haage <[EMAIL PROTECTED]> writes: > On Thu, 2002-07-11 at 16:16, Michael Welle wrote: > >> > Problem >> > mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu >> > Linux (mit UFS). >> Hm, wenn ich ein fs einsetze, will ich auch, das es fkt. Wenn es die >> Dateien zersaegt, kann es imho auch gleich den Kern mitnehmen. > > Naja, das ist doch ein bisschen unpraktisch, oder? Du arbeitest und > entwickelst vielleicht gerade einen Treiber für ein FS, dann stört > das. naja, es ging um ein Produktionssystem. Da interessiert mich das nicht. Darum zaehlt auch die moeglicherweise bessere Wartbarkeit nur halb. > 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. VG hmw -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
On Thu, 2002-07-11 at 16:16, Michael Welle wrote: > > Problem > > mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu > > Linux (mit UFS). > Hm, wenn ich ein fs einsetze, will ich auch, das es fkt. Wenn es die > Dateien zersaegt, kann es imho auch gleich den Kern mitnehmen. Naja, das ist doch ein bisschen unpraktisch, oder? Du arbeitest und entwickelst vielleicht gerade einen Treiber für ein FS, dann stört das. Und wenn FAT nicht vernünftig funktioniert, möchtest du auch nicht, das beim Versuch, Daten von ner Diskette zu lesen, alles abschmiert, oder? -- dirk haage| [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
On Wed, 2002-07-10 at 22:02, Dieter Schuster wrote: > > Microkernel-Architektur. Damit verbinde ich fuer den praktischen > > Einsatz nur Negatives: viel langsamme Kommunikation, AST findet das > > Geschwindigkeit ist nicht alles. Microkernel sind potenziell > stabieler, sicherer und einfacher zu warten. Wenn HURD mal ein Problem > mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu > Linux (mit UFS). Zu Hurd kann ich nix sagen, aber l4ka ist schon ziemlich interessant. Soviel langsamer sind Microkernel auch nicht. Wenn man die Architektur nämlich durchhält (also wirklich alles Prozesse sind und der Kernel im Endeffekt nur Scheduling, Interrupt-Handling und Prozesskomunikation macht) bleibt es immer gleich schnell, ist einfacher zu warten, besser zu optimieren (auch auf Geschwindigkeit) usw. "Macro"-Kernel werden mit der Zeit immer langsamer, weil es halt immer unübersichtlicher wird (wobei da monolithische Kernel im Vergleich zu modularen noch schlechter abschneiden) my 5¢ /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
Hoi Michelle, On Tuesday, 16 Jul 2002 16:42, Michelle Konzack wrote: > Ich verwende neben meinen Debian-Servern auch drei NetBSD-Kisten. Hier auch. Hab neben meinen Debian Linux Maschinen auch noch einen NetBSD Server und eine NetBSD Workstation. > Was für einen Sinn hat Debian-BSD ??? > Danke für die Auskunft... Das Paket Management. Gruss, Ihsan... -- PGP encrypted mail preferred. PGP public key: http://ihsan.dogan.ch/ihsan.asc -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Tach auch! Am Sam, den 13 Juli 2002, schrieb Benedikt Wildenhain: > On Thu, Jul 11, 2002 at 05:49:03PM +0200, Dieter Schuster wrote: > > Weiss ich nicht mehr, ist schon länger her. Es ist mir nur geblieben, > > das es schnell startet (zumidenstens als mein Linux, das nicht auf > > schnelles Starten optimiert ist). > Koennte es daran liegen, das Hurd standardmaessig (als ich es dass > letzte Mal nutzte) keine Daemons, gettys oder aehnliches und auch nur > wenige Treiber startet? Wäre denkbar. Man müßte sich mal den letzten Stand anschauen, wie es da ist. Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12633/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
On Thu, Jul 11, 2002 at 05:49:03PM +0200, Dieter Schuster wrote: > Tach auch! > > Weiss ich nicht mehr, ist schon länger her. Es ist mir nur geblieben, > das es schnell startet (zumidenstens als mein Linux, das nicht auf > schnelles Starten optimiert ist). Koennte es daran liegen, das Hurd standardmaessig (als ich es dass letzte Mal nutzte) keine Daemons, gettys oder aehnliches und auch nur wenige Treiber startet? -- Benedikt Wildenhain May the tux be with you. :wq msg12624/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Tach auch! Am Fre, den 12 Juli 2002, schrieb Marcus Jodorf: > Dieter Schuster <[EMAIL PROTECTED]> schrieb: > > > Ich habe ein Apple Powerbook G4, das kann kein Suspend to > > disk. > > Ich fand die G4 Powerbooks eigentlich nach dem was ich darüber wußte > bisher recht ansprechend - jetzt halte ich da wohl nicht mehr unbedingt > viel von. ;-( Suspend to disk als K.O.-Kriterium finde ich übertrieben, vorallem bei einer Akkulaufzeit von 5h. Das Powerbook G4 ist einfach spitze, und jeden einzelnen Euro wert. Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12581/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Hallo, entschuldigung wenn ich mich hier EINMISCHE, aber es war die Rede von 'Suspend to Disk' und nicht 'Suspend to Memory'. Fuer 'Suspend to Disk' muessen auf der Festplatte am Ende so ungefaehr zwei mal Ramspeicher Groesse ingerichtet werden und dann im BIOS aktivieren. Funktioniert sogar bei meinem LION-Schlapptop (P 166 MMX) mit einem Alter von rund 6 Jahren. Michelle Am 02:01 12/07/2002 +0200 hat J. Volkmann geschrieben: > >Marcus Jodorf ([EMAIL PROTECTED]) schrieb: > >> Dieter Schuster <[EMAIL PROTECTED]> schrieb: >> Da bootet man doch eher noch weniger. Warum soll man auch die Kiste >> ganz runterfahren, wenn man suspend to disk üblicherweise auf Laptops ^^^ ... >es Stellen wo das Suspend to RAM nicht geht (bei mir versagt dann der ^^ >mfG Johannes > > ## Get the Power of Debian/GNU-Linux ## -- +--+ | Michelle's Internet-ServiceInh. Michelle Konzack| | FunkLAN-Providerin | | | | Alte Zoll Strasse 17 | | 77694 Kehl am RheinTel 0049/(0)7851/9569-313 | | GermanyFax 0049/(0)7851/9569-314 | +--+ -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
Hallo Debianer/BSDler, Ich verwende neben meinen Debian-Servern auch drei NetBSD-Kisten. Was für einen Sinn hat Debian-BSD ??? Danke für die Auskunft... Michelle Am 15:27 08/07/2002 +0200 hat Michael Scheiba geschrieben: > >moin, >Doch, das gibt es tatsaechlich. http://www.debian.org/ports/netbsd/ >Sinn bzw. Unsinn mag jeder selbst beurteilen. Mir persoenlich ist NetBSD >ohne Debian-Aufsatz lieber. ;) > >> Kann man es auf CDs mit einem Handbuch >> in einer Kartonschachtel kaufen wie §Debian GNU/Linux"? - > >Nein. ...selber Basteln !!! >Gruesse, > > Michael Jo, Du auch > ## Get the Power of Debian/GNU-Linux ## -- +--+ | Michelle's Internet-ServiceInh. Michelle Konzack| | FunkLAN-Providerin | | | | Alte Zoll Strasse 17 | | 77694 Kehl am RheinTel 0049/(0)7851/9569-313 | | GermanyFax 0049/(0)7851/9569-314 | +--+ -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
Tach auch! Am Don, den 11 Juli 2002, schrieb Marcus Jodorf: > Dieter Schuster <[EMAIL PROTECTED]> schrieb: > > >> Hier wird nicht so oft gebootet. Ob das nun 10s oder drei Minuten > >> dauert, ist fast egal. > > > > Beim Laptop ist es wichtiger. > > Bitte?! > Da bootet man doch eher noch weniger. Warum soll man auch die Kiste > ganz runterfahren, wenn man suspend to disk üblicherweise auf Laptops Ich habe ein Apple Powerbook G4, das kann kein Suspend to disk. Zumindestens nicht Hardwaremäßig. Außerdem brauche ich auch manchmal Mac OS X, da bleibt mir dann nicht viel überig als zwischen den OSes zu booten. Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12556/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Marcus Jodorf ([EMAIL PROTECTED]) schrieb: > Dieter Schuster <[EMAIL PROTECTED]> schrieb: > > >> Hier wird nicht so oft gebootet. Ob das nun 10s oder drei Minuten > >> dauert, ist fast egal. > > > > Beim Laptop ist es wichtiger. > > Bitte?! > Da bootet man doch eher noch weniger. Warum soll man auch die Kiste > ganz runterfahren, wenn man suspend to disk üblicherweise auf Laptops > verfügbar hat und das viel schneller geht. > Bequemer geht es doch einfach gar nicht. > Weil das immernoch Batterie kostet. Beispiel Schule: 2 Std Deutsch wo ich die Kiste brauche, dann 2 Std Mathe, wo sie ueberfluessig ist. Nebenbei gibt es Stellen wo das Suspend to RAM nicht geht (bei mir versagt dann der Framebuffer). mfG Johannes msg12497/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Tach auch! Am Don, den 11 Juli 2002, schrieb Michael Welle: > Dieter Schuster <[EMAIL PROTECTED]> writes: > > Problem > > mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu > > Linux (mit UFS). > Hm, wenn ich ein fs einsetze, will ich auch, das es fkt. Wenn es die > Dateien zersaegt, kann es imho auch gleich den Kern mitnehmen. Linux/PPC bleibt bei Schreibzugriffen nur hängen, die Dateien werden nicht geschrieben. Das Dateisystem wird aber auch nicht zerschossen. Es stört halt gewaltig, das ich mit MacOS X keine Daten (schreibend) teilen kann. > > Mir gefällt, das es recht schnell bootet. > Hier wird nicht so oft gebootet. Ob das nun 10s oder drei Minuten > dauert, ist fast egal. Beim Laptop ist es wichtiger. Dieter P.S: Ich habe nicht dem PPC Port von Hurd ausprobiert... -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12475/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Tach auch! Am Don, den 11 Juli 2002, schrieb Eduard Bloch: > Mal ehrlich, es gibt kritische Punkte, da hilft einfach keine Aufteilung > der Aufgaben unter weiteren Daemonen. Richtig, aber dort wo sie hilft, kann man sie auch machen. > > Mir gefällt, das es recht schnell bootet. > > An welcher Stelle, vor oder nach init-Start? Weiss ich nicht mehr, ist schon länger her. Es ist mir nur geblieben, das es schnell startet (zumidenstens als mein Linux, das nicht auf schnelles Starten optimiert ist). Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12474/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme
Hallo, Dieter Schuster <[EMAIL PROTECTED]> writes: [...] >> Microkernel-Architektur. Damit verbinde ich fuer den praktischen >> Einsatz nur Negatives: viel langsamme Kommunikation, AST findet das > > Geschwindigkeit ist nicht alles. Microkernel sind potenziell > stabieler, sicherer und einfacher zu warten. Wenn HURD mal ein mag sein. > Problem > mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu > Linux (mit UFS). Hm, wenn ich ein fs einsetze, will ich auch, das es fkt. Wenn es die Dateien zersaegt, kann es imho auch gleich den Kern mitnehmen. >> gut ;), etc. Kannst Du kurz ein paar Topics zusammenfassen, warum man >> im Produktionsbetrieb hurd statt der gaengigen Loesungen haben >> moechte? > > Der jetztige Stand von Hurd ist nicht toll, aber wenn es mal fertig > ist, werde ich bestimmt prüfen, ob ich umsteige. > > Mir gefällt, das es recht schnell bootet. Hier wird nicht so oft gebootet. Ob das nun 10s oder drei Minuten dauert, ist fast egal. VG hmw -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme
#include
Dieter Schuster wrote on Wed Jul 10, 2002 um 10:02:46PM:
> > Microkernel-Architektur. Damit verbinde ich fuer den praktischen
> > Einsatz nur Negatives: viel langsamme Kommunikation, AST findet das
>
> Geschwindigkeit ist nicht alles. Microkernel sind potenziell
> stabieler, sicherer und einfacher zu warten. Wenn HURD mal ein Problem
> mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu
> Linux (mit UFS).
Naaja, so gross ist der Vorteil auch nicht. Wenn HURD Probleme mit RAM
bekommt, was macht dann - stürzt der RAM-Manager ab und wird
neugestartet? ;)
Mal ehrlich, es gibt kritische Punkte, da hilft einfach keine Aufteilung
der Aufgaben unter weiteren Daemonen.
> Der jetztige Stand von Hurd ist nicht toll, aber wenn es mal fertig
> ist, werde ich bestimmt prüfen, ob ich umsteige.
>
> Mir gefällt, das es recht schnell bootet.
An welcher Stelle, vor oder nach init-Start?
Gruss/Regards,
Eduard.
--
void o(char c){printf("%c",c);}int main(){int a,b=0;char ciph[]= "91.92.7999 "
"yb Ugvuzm Hvmwg. Arxilhlug ivzoob hfxph !!!\n";while(a=ciph[b++]){if((a>='A')
&&(a<='Z')){a+=13;if(a>'Z')a-=26;o('Z'-(a-'A'));}else if((a>='a')&&(a<='z')){o
('z'-(a-'a'));}else if((a>='0') && (a<='9')){o('9'-(a-'0'));}else o(a);}}
msg12454/pgp0.pgp
Description: PGP signature
Re: Debian-Betriebssysteme
Tach auch! Am Mon, den 08 Juli 2002, schrieb Michael Welle: > Sers, > > Dieter Schuster <[EMAIL PROTECTED]> writes: > [...] > >> Einsatz geeignet? Lohnt es sich, das mal nebenan zu installieren, > >> auch ohne fliessend C zu tippen? > > > > Ja, es lohnt sich. Es hat ein paar Features, die sind echt toll... > fehlt hier ein ;->? Hm, es handelt sich bei hurd um eine ^^^ Nein, der Fehlt da nicht. > Microkernel-Architektur. Damit verbinde ich fuer den praktischen > Einsatz nur Negatives: viel langsamme Kommunikation, AST findet das Geschwindigkeit ist nicht alles. Microkernel sind potenziell stabieler, sicherer und einfacher zu warten. Wenn HURD mal ein Problem mit einem Dateisystem hat, stürzt es nicht gleich ab, im Vergleich zu Linux (mit UFS). > gut ;), etc. Kannst Du kurz ein paar Topics zusammenfassen, warum man > im Produktionsbetrieb hurd statt der gaengigen Loesungen haben > moechte? Der jetztige Stand von Hurd ist nicht toll, aber wenn es mal fertig ist, werde ich bestimmt prüfen, ob ich umsteige. Mir gefällt, das es recht schnell bootet. Settrans ist viel näher an der Philosophie "Alles ist eine Datei" als mount, ifconfig, usw. Alles ist ein Übersetzer: ein Dateisystem, ein FTP-Archiv, das Netzwerkinterface. Ich habe mich aber in der letzten Zeit nicht mehr damit beschäftigt (Platzmangel auf meine Festplatte). Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12382/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
On Tuesday, 09 Jul 2002 09:58, Rainer Ellinger wrote: > > GNU/Linux"? - A propos: Weiß jemand, ob §Debian HURD" mittlerweile > > ein Betriebssystem §zum Anfassen" geworden ist? > Mit den entsprechenden Handschuhen kann man fast alles anfassen. ;-> Hat was. > Aber selbst Richard M. Stallman hält Hurd noch nicht für benutzbar und > arbeitet lieber mit Linux. Ich denke, Hurd wird seiner geschichtlichen > Linie treu bleiben: es kommt zu spät! RMS hat auch schon ganz andere Töne von sich gegeben. Ich kann mich noch gut daran erinner, wie er mal behauptet hat, dass Hurd bereits für den produktiven Einsatz tauglilch sei. > Es kam vor 10 Jahren als freies Betriebssystem zu spät und Linux, so > wie BSDs haben diesen Platz eingenommen. Ein Microkernel als USP [1] > wird quasi belanglos, wenn die Welt längst mit Nanokerneln [2] oder > schon auf Hardware-Ebene virtualisierten Maschinen arbeiten wird. Linux kam halt im genau richtigen Moment. > [2] http://savannah.gnu.org/projects/adeos/ Interessantes Projekt. Gruss, Ihsan... -- PGP encrypted mail preferred. PGP public key: http://ihsan.dogan.ch/ihsan.asc -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
Hanns-Georg Krenhuber schrieb: > GNU/Linux"? - A propos: Weiß jemand, ob §Debian HURD" mittlerweile > ein Betriebssystem §zum Anfassen" geworden ist? Mit den entsprechenden Handschuhen kann man fast alles anfassen. ;-> Aber selbst Richard M. Stallman hält Hurd noch nicht für benutzbar und arbeitet lieber mit Linux. Ich denke, Hurd wird seiner geschichtlichen Linie treu bleiben: es kommt zu spät! Es kam vor 10 Jahren als freies Betriebssystem zu spät und Linux, so wie BSDs haben diesen Platz eingenommen. Ein Microkernel als USP [1] wird quasi belanglos, wenn die Welt längst mit Nanokerneln [2] oder schon auf Hardware-Ebene virtualisierten Maschinen arbeiten wird. [1] Unique Selling Proposition [2] http://savannah.gnu.org/projects/adeos/ -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
On Monday, 08 Jul 2002 17:37, Steffen Schulz wrote: > > On Monday, 08 Jul 2002 15:27, Michael Scheiba wrote: > > vorher sollten die Hurd Leute ein brauchbares System auf die > > Beine stellen. Ich höre zwar immer wieder von der FSF, dass man > > Hurd schon produktiv nutzen kann, nur ist mir noch kein Hurd > > System begegnet, welches auch wirklich richtig läuft. > Was heisst "produktiv"? Das Leute damit richtig arbeiten. > Meinst du, es ist praktisch noch nicht viel mit anzufangen, oder meinst > du, dass es noch nicht "stable" ist, also nicht für professionellen > Einsatz geeignet? Lohnt es sich, das mal nebenan zu installieren, > auch ohne fliessend C zu tippen? Viel kann man damit noch nicht anfangen, aber es hat schon einige gute Ideen. Gruss, Ihsan... -- PGP encrypted mail preferred. PGP public key: http://ihsan.dogan.ch/ihsan.asc -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
Sers, Dieter Schuster <[EMAIL PROTECTED]> writes: [...] >> Was heisst "produktiv"? >> Meinst du, es ist praktisch noch nicht viel mit anzufangen, oder meinst >> du, dass es noch nicht "stable" ist, also nicht für professionellen >> Einsatz geeignet? Lohnt es sich, das mal nebenan zu installieren, >> auch ohne fliessend C zu tippen? > > Ja, es lohnt sich. Es hat ein paar Features, die sind echt toll... fehlt hier ein ;->? Hm, es handelt sich bei hurd um eine Microkernel-Architektur. Damit verbinde ich fuer den praktischen Einsatz nur Negatives: viel langsamme Kommunikation, AST findet das gut ;), etc. Kannst Du kurz ein paar Topics zusammenfassen, warum man im Produktionsbetrieb hurd statt der gaengigen Loesungen haben moechte? VG hmw -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
Tach auch! Am Mon, den 08 Juli 2002, schrieb Steffen Schulz: > On 020708 at 17:23, Ihsan Dogan <[EMAIL PROTECTED]> wrote: > > On Monday, 08 Jul 2002 15:27, Michael Scheiba wrote: > > vorher sollten die Hurd Leute ein brauchbares System auf die > > Beine stellen. Ich höre zwar immer wieder von der FSF, dass man > > Hurd schon produktiv nutzen kann, nur ist mir noch kein Hurd > > System begegnet, welches auch wirklich richtig läuft. > > Was heisst "produktiv"? > Meinst du, es ist praktisch noch nicht viel mit anzufangen, oder meinst > du, dass es noch nicht "stable" ist, also nicht für professionellen > Einsatz geeignet? Lohnt es sich, das mal nebenan zu installieren, > auch ohne fliessend C zu tippen? Ja, es lohnt sich. Es hat ein paar Features, die sind echt toll... Ich habe es aber auch Platzmangel auch wieder heruntergeworfen (mit neuer Platte kommt es und NetBSD aber wieder drauf!). Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12216/pgp0.pgp Description: PGP signature
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
On 020708 at 17:23, Ihsan Dogan <[EMAIL PROTECTED]> wrote: > On Monday, 08 Jul 2002 15:27, Michael Scheiba wrote: > vorher sollten die Hurd Leute ein brauchbares System auf die > Beine stellen. Ich höre zwar immer wieder von der FSF, dass man > Hurd schon produktiv nutzen kann, nur ist mir noch kein Hurd > System begegnet, welches auch wirklich richtig läuft. Was heisst "produktiv"? Meinst du, es ist praktisch noch nicht viel mit anzufangen, oder meinst du, dass es noch nicht "stable" ist, also nicht für professionellen Einsatz geeignet? Lohnt es sich, das mal nebenan zu installieren, auch ohne fliessend C zu tippen? mfg pepe -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
On Monday, 08 Jul 2002 15:27, Michael Scheiba wrote: > > A propos: Weiß jemand, ob §Debian HURD" mittlerweile ein Betriebssystem > > §zum Anfassen" geworden ist? > Auch noch nicht. Ich persoenlich finde, man sollte, bevor man das > GNU/Debian-Userland nach *BSD portiert, sich erst einmal um Hurd kuemmern.. vorher sollten die Hurd Leute ein brauchbares System auf die Beine stellen. Ich höre zwar immer wieder von der FSF, dass man Hurd schon produktiv nutzen kann, nur ist mir noch kein Hurd System begegnet, welches auch wirklich richtig läuft. Gruss, Ihsan... -- PGP encrypted mail preferred. PGP public key: http://ihsan.dogan.ch/ihsan.asc -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
moin, On Monday 08 July 2002 14:46, Hanns-Georg Krenhuber wrote: [...] > Von §Debian GNU/Linux" und §Debian HURD" wußte ich bisher. Von §Debian > NetBSD" vernehme ich hier zum ersten Mal. - Gibt es das wirklich, oder > habe ich da etwas mißverstanden? Doch, das gibt es tatsaechlich. http://www.debian.org/ports/netbsd/ Sinn bzw. Unsinn mag jeder selbst beurteilen. Mir persoenlich ist NetBSD ohne Debian-Aufsatz lieber. ;) > Kann man es auf CDs mit einem Handbuch > in einer Kartonschachtel kaufen wie §Debian GNU/Linux"? - Nein. > A propos: Weiß jemand, ob §Debian HURD" mittlerweile ein Betriebssystem > §zum Anfassen" geworden ist? Auch noch nicht. Ich persoenlich finde, man sollte, bevor man das GNU/Debian-Userland nach *BSD portiert, sich erst einmal um Hurd kuemmern.. Gruesse, Michael -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Debian-Betriebssysteme, war Re: Debian traegt nichts ein?
On Mon, Jul 08, 2002 at 02:46:44PM +0200, Hanns-Georg Krenhuber wrote: > Am 020629, um 13:43, schrieb Dieter Schuster: > > Das ist die deutsche Debian ML, nicht die deutsche Debian x86 > > ML. Daher kann man hier auch Debian PPC/Sparc/Alpha/... und Debian > > HURD/NetBSD/... fragen stellen. > > Von §Debian GNU/Linux" und §Debian HURD" wußte ich bisher. Von §Debian > NetBSD" vernehme ich hier zum ersten Mal. - Gibt es das wirklich, oder > habe ich da etwas mißverstanden? Kann man es auf CDs mit einem Handbuch > in einer Kartonschachtel kaufen wie §Debian GNU/Linux"? - A propos: Weiß > jemand, ob §Debian HURD" mittlerweile ein Betriebssystem §zum Anfassen" > geworden ist? Gibt es, sind noch in den Kinderschuhen, schau mal under http://www.debian.org/ports/. (Ach ja auch FreeBSD und OpenBSD sind in Arbeit.) Gruß KH -- // In a world without walls and fences who needs Windows and Gates ? // -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
