From cracauer@bik-gmbh.de Thu Dec 16 11:48:49 1999 Path: klemm.gtn.com!newsfeed.dpn.de!news-out1.d.gtn.com!news-in1.d.gtn.com!iradj.is-bremen.de!informatik.uni-bremen.de!cs.tu-berlin.de!news.uni-hamburg.de!news-ham1.dfn.de!news-han1.dfn.de!news.fh-hannover.de!f.de.uu.net!newsfeed.ision.net!ision!news.ppp.net!counter.bik-gmbh.de!not-for-mail From: cracauer@bik-gmbh.de (Martin Cracauer) Newsgroups: de.comp.os.unix.bsd Subject: Re: Fee/Net/Open FAQ (und BSD vs. Linux) Date: 16 Dec 1999 11:48:49 +0100 Organization: BIK Market Research - Hamburg/Germany Lines: 189 Message-ID: <83ag2h$b71$1@counter.bik-gmbh.de> References: <3856fc0d@nntp.server.uni-frankfurt.de> <838v1f$2qtp$1@bigeye.rhein-neckar.de> <38584d31@nntp.server.uni-frankfurt.de> <839msh$8jo$2@methusalix.rz.tu-clausthal.de> NNTP-Posting-Host: localhost Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: counter.bik-gmbh.de 945341332 11490 127.0.0.1 (16 Dec 1999 10:48:52 GMT) X-Complaints-To: usenet@bik-gmbh.de NNTP-Posting-Date: 16 Dec 1999 10:48:52 GMT X-Newsreader: NN version 6.5.3 (NOV) Xref: klemm.gtn.com de.comp.os.unix.bsd:1009 olli@FreeBSE.ORG writes: >eyanar@trollinger-fe.rz.uni-frankfurt.de wrote (16 Dec 1999 03:23:45 +0100): > > Christian Weisgerber (naddy@mips.rhein-neckar.de) wrote: > > > http://www.de.freebsd.org/ > > > http://www.de.netbsd.org/ > > > http://www.de.openbsd.org/ > > > > > Dafür braucht man ungefähr, oh, eine Minute mit Google. > > Google hin Google her (keine Ahnung was das ist) >Eine Suchmaschine. > > bin nach > > 5 min. nicht viel schlauer. >Dann hast Du vielleicht die URLen falsch abgetippt, oder Du >liest ausgesprochen langsam. Selbst ein sehr flüchtiger Blick >auf die Projekt-Homepages sagt einem sofort: > - FreeBSD ist für i386 optimiert, > - NetBSD läuft auf mehr Plattformen als Linux, > - OpenBSD hat den Schwerpunkt "Sicherheit". Das ist zwar die klassiche Unterscheidung, aber nicht nuetzlich zum aussuchen, weil: - FreeBSD ist nicht mehr nur i386 - NetBSD hat auch noch ganz andere Vorzuege - niemand entwickelt wissentlich ein unsicheres System und die anderen BSD uebernehmen die OpenBSD security-Fixes. Ich finde, man kann die drei Systeme eher nach der gaengigen Praxis der Entwicklungsarbeiten charaktirisieren: NetBSD legt sehr viel Wert auf sauberen Code und architektonische Eleganz. Klingt gut, aber in der Praxis nervt es schon, wenn es ewig dauert, bis eigentlich triviale und dringend notwenidge Sachen endlich im NetBSD landen (und dann erst mal haufenweise Treiber disabeled sind). Die saubere Architektur ist bei NetBSD auch eher notwendig als bei FreeBSD, weil sich die vielen Plattformen sonst nicht so viel Code sharen koennten. Und NetBSD hat eine ganze Anzahl Entwickler, die eben nur auf einem so sauberen System arbeiten wollen und/oder die nicht auf i386 arbeiten wollen und die deshalb bei FreeBSD nicht gluecklich werden wuerden. Das fuehrt zu einigen "chicen" Sachen wie dem Raidframe und einem guten Consolentreiber. Bei FreeBSD heist's "Rough agreement and working code". Im FreeBSD landet sehr viel Zeugs, was es nicht ins NetBSD geschafft haette. Solange es funktioniert, nicht unnoetig haesslich ist und nicht die Arbeit von jemandem anderen stoert, koennen die Committer schon weitgehend machen, was sie wollen. Auf diese Weise kommt man eher zu Sachen wie CAM, SMP, Softupdates, neuen Treibern, besserer Linux-Emulation, einem guten IDE-Treiber etc. als bei NetBSD. In der Praxis kann FreeBSD diese Art Arbeit auch besser durchziehen als NetBSD, weil die Anzahl Leute, die -current fahren und dadurch implizit testen, wesentlich groesser ist. OpenBSD sieht fuer mich eher negativ aus. Sicherheit ist sicherlich grossgeschrieben, aber da sich OpenBSD durch Unterschiede in der Kernelarchitektur von den anderen beiden BSDs abgekoppelt habt, bleiben viele guten Sachen liegen. So was wie CAM (und damit die ganzen Treiber fuer moderne SCSI-Controller) und ein schnelles VM-System liegen in weiter Ferne und koennen kaum von den anderen BSDs uebernommen werden. Viele sogenannte Security-Fixes sehr vorsorglich und fixen Dinge, die in der Praxis nicht als explotable angesehen werden koennen (der Grossteil der anderen wird dann schnell von FreeBSD und NetBSD geklaut). Ausserdem gibt es eine deutliche Tendenz zu Holzhammerloesungen, u.a. auch bei der Policy, wann Userland - Sachen ausgetauscht werden (sh, tar etc.). Keine Frage, dass OpenBSD wertvolle Arbeit leistet und fuer eine Maschine, die wenig Durchsatz machen muss aber hoechste Sicherheit braucht, ist es sicherlich erste Wahl, aber als Arbeitsmaschine waere es mir unsympatisch. Insgesamt finde ich FreeBSD am besten, aber das ist eben nicht nur das Ergebnis der Zielsetzung der Entwickler. Sondern weil die Zielsetzung, die FreeBSD im Moment hat, zufaellig gepaart ist mit einer grossen Anwenderschaft, die fuer diese Art der Entwicklung unbedingt gebraucht wird (sonst waere FreeBSD inzwischen so stabil wie Windows 3.0). Das ist Glueck, sonst nix. Die Einsatzfaehigkeit dieser Systeme haengt eben nicht nur von der Zielsetzung der Entwickler ab, auch nicht von der Anzahl und Faehigkeit der Entwickler, sondern eben auch von kaum beeinflussbaren aeusseren Faktoren bis zum zu - eben - Glueck. Insofern kann man ueber sollen und wollen der Teams schreiben, soviel man will, das nuetzt demjenigen, der sich ein System aussuchen will, erst mal nix. "If you don't know, you want FreeBSD" ist bisher der einzige Ratschlag, den ich als nuetzlich ansehen kann (auch wenn er selbstverstanedlich unfair zu NetBSD und OpenBSD ist). [...] In Sachen Linux moechte ich nur mal auflisten, durch welche Katastrophen wir bei den Linux-Binaries von CMU Common Lisp in den letzten Monaten gegangen sind: - Die Binaerkernel, die beim Redhat installiert werden, sind gegenueber den Standarddistributionen im groessen Umfang abgewandelt. Durch Aenderungen im VM-System war die memoryallokation von CMUCL auf default Redhats nicht lauffaehig, nach compilieren eines neuen Kernels schon (Source von der gleichen CD). Sehr witzig. - lib5 -> lib6 natuerlich. Dadurch, dass libc und kernel nicht vom gleichen Team gemacht wurden und die Distributionen das frei mixen, gab es sehr viel Chaos bei der Umstellung. - _setfpcw (glibc-2 -> glibc-2.1). Leider hat es niemand fuer noetig gehalten, bei der Aenderung des Symbolsets in glibc-2.1 die Versionsnummer der shared library hochzusetzen. Ergebnis: Nicht die Meldung, dass die richtige shared lib fehlt, sondern einfach undefined symbol und Ende. Was das an Anfragen auf den Mailinglisten von CMUCL gebracht hat, ist nicht witzig. Das Control Word der FPU zu setzen ist ueberigens eine einzelne Instruktion des Prozessors. Das in eine Funktion zu hauen, geschweige denn in eine in einer shared Library, macht das Setzen um ein paar Zehnerpotenzen langsamer. - Die Idee, overcommit Memory ausschalten zu koennen, ist begruessenswert. Nicht begruessenswert ist, dass es einfach zum Default gemacht wurde, ohne dass eine wichtbar entscheidende Releasegrenze ueberschritten wurde. Das ganze wird natuerlich hervorragend davon unterstuetzt, dass es beim Linux-kernel immer noch keine CVS logmessages oder aehnliches gibt. irgendwie kommen mir diese Aenderungsmails, die nur auflisten, wieviele Zeilen sich in welchem Directory geaendert haben, vor wie die typischen aussagekraeftigen Windows-Fehlermeldungen a'la' "hat nicht funktioniert". - Der Linux-CMUCL-Erzeuger ist von *.rpm auf *.deb umgestiegen. Die Leute kapieren einfach nicht, dass sie lieber das neueste nehmen sollten und nicht die alten RPMs, die leider ueberall rumfliegen, weil die Anzahl der nicht gemaintainten Mirrors bei Linux hoch ist. Zuviele Sites, wo selbst der Maintainer eines Paketes es nicht schafft, die obsoleten Pakete wegzuhauen, zuviele User, die nicht wissen, dass sie ein *.deb auch auf Ihrem Redhat benutzen koennen. Hab bestimmt noch was vergessen. Und dass sind nur die Probleme einer einzelnen Applikation, die noch nicht mal eine komplizierte Installation braucht. Wie schwer es komplizierte Installationen auf den unterschiedlichen Distributioenen haben, sollte bekannt sein. Und ich fange noch nicht mal an, ueber Sachen wie asynchrone Metadaten, Kernel memory allocation, einen IDE-Treiber der nicht unter SMP geht, dem unsaeglichen LILO, unshrinkable directories, keinem `umount -f` und einem Bootprozess, der nicht durch SIGINT oder SIGQUIT beeinflusst werden kann, zu reden. ARGHHH! In der Summe sind die CMUCL-Mailinglisten voll von Anfragen von Anwendern, denen ohne unsere oder deren eigene Schuld Ihr CMUCL kaputt gemacht wurde, waehrend die FreeBSD - Front komplett ruhig ist. Wir haben immer noch ein aout binary als Standard fuer FreeBSD-3 und -4, das funktioniert einfach weiter und FreeBSD hat sogar die Tools heil gelassen, so dass immer noch aout Objectfiles compiliert und geladen werden koennen. Dasselbe binary, dass wir standardmaessig vertreiben, laeuft von ca. 2.2.6 bis 4.0-current ueberall. Das ist *Support* in dem Sinne des Wortes, wie ich es verstehen wuerde (nicht in dem Dummuser - Telefonsupport Sinne). Die FreeBSD - Leute wollen den Usern Ihr System nicht kaputt machen. Natuerlich wollen die Linuxer das auch nicht. Aber die FreeBSDler haben auch die Moeglichkeit, dass durchzuziehen, weil sie alle entscheidenden Komponenten des Systems unter Ihrer Kontrolle haben und weil die Kommunikation stimmt (allen voran CVS logmessages). Grummel, Zeit zum Abregen. Wieso ist der Kaffee alle? Scheiss-Buero. Wie soll man in seiner Arbeitszeit posten, wenn der Kaffee alle ist? Nur um den aeltesten Witz nochmal unterzubringen: In Deutschland gibt es ein Gesetz, nach dem ein Produkt in brauchbarem Lieferumfang verkauft werden muss. Zum Beispiel muessen bei vielen Elektronikprodukten Batterien enthalten sein. Microsoft soll nun gezwungen werden, Windows 2000 einen Strick beizulegen. Ach ja, wenn jemand noch eine von diesen 3GB 5.25" Seagate Elite Platten hat, ich waere sehr interessiert daran. Noch was? Wird der inn dieses Posting ablehnen, weil zuviel gequotetes drin ist? Was ist eigentlich der Sinn des Lebens? Warum schiessen die Marsmenschen unsere Sonden ab? Warum ist die NASA nicht vorher in den ADAC eigetreten? Oder ist AC/DC zustaendig? Und ueberhaupt. segmentation fault, core dumped... -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer/ "Where do you want to do today?" Hard to tell running your calendar program on a junk operating system, eh?