Hallo, On Fri, Sep 29, 2000 at 3:14 +0200, Wolfgang Weisselberg wrote:
Bernhard Walle schrieb in 4,4K (111 Zeilen):
On Sun, Sep 24, 2000 at 8:45 +0200, Ralf Corsepius wrote:
Gäbe es nun einen einheitlichen Standard bezüglich Paketformat,
rpm, deb, tar-Ball, shar, zip ...
Ich meine keine Archivformate wie zip sondern _Paketformate_ wie rpm oder deb. Und da eben 1 statt 2, das die Vorteile von beiden vereint.
Bootkonzept
SysV (mit runleveln), BSD (hat keine runlevel, alles ein langes Script), Winfried Truemper's Modell (Programm mit Configfile), ...
Ich rede von Linux, nicht von BSD! Was interessiert mich BSD, Solaris und wie sie alle heißen. Irgendwo müssen ja die Unterschiede zwischen den Unices existieren.
und Dateisystem,
ADFS (Acorn), AmigaFS, Apples FS, BFS (BeOS), DOS/UMSDOS/VFAT/FAT32, EFS (Irix-CDs), CramFS (Compressed ROM FS), RamFS (Autogrow/shrink), ISO 9660/Joliet/RockRidge, MINIX FS, NTFS, HPFS (OS/2), /proc, /devfs, /dev/pts, QNX4FS, (QNX), RomFS, ext2, SYSV FS (Coherent, Xenix, SCO), UDF (DVD/CDROMs), UFS (BSDs, SunOS, NeXTstep)
Coda, NFS, SMB, NCP
Acorn, Alpha OSF, Amiga, Atari, Macingtosh, MSDOS, BSD, Solaris, UnixWare, SGI, Ultrix, Sun --- Partitionstypen
(2.4.0-test8)
ReiserFS, JFS, XFS, ext3, ... fangen wir gar nicht erst _damit_ an.
Natuerlich muss das OS den Zugriff auf alle diese FS soweit wie technisch moeglich transparent gestalten.
Gut, ich habe nicht das Dateisystem sondern den Ort, wo die Dateien abgelegt werden, gemeint. Gegen die verschiedenen _technischen_ Dateisysteme habe ich nichts, die behindern ja auch nicht den Austausch der Programme bzw. -installationen. Das war meinerseits missverständlich ausgedrückt.
könnte jeder dieselben Linux-Programme installieren, ohne selber kompilieren oder ein Paket für seine Distribution suchen zu müssen. Das wäre ein echter Fortschritt.
Und jeder duerfte nur noch KDE benutzen. Danke, das ist mir zu nahe an Windows.
Was hat das mit KDE zu tun?
Nenne mir bitte deinen Standard. Und begruende, warum du bestimmte FSses und geg. User dann ausschliesst.
.o. Ich schließe keine FS und auch keine WM-Benutzer aus. Ich habe nichts von einem einheitlichen WM geschrieben.
Der Standard soll fest sein, nicht das Programm. Es können doch zwei Unterschiedliche Programme für RPM/DEB existieren. Dazu wird es aber wahrscheinlich nicht kommen, weil es unsinnig ist.
Es gibt afterstep, amiwm, blackbox, bowman, cdesim, ctwm, Enlightenment, fvwm1, fvwm2.0, fvwm2.2, fvwm95, icewm, mlvwm, olvwm, qvwm, scwm, wm2 und WindowMaker fuer X auf der SuSE 7.0. (gwm ist z.B. nicht auf der SuSE drauf, und mindestens ein Dutzend weitere lassen sich bei freshmeat finden). Es gibt xterm, aterm, eterm, rxvt, ... Es gibt lilo, loadlin, chos, nuni, milo, silo, ... Es gibt Netscape, amaya, arena, Mosaic, Mozilla, ... lynx, www, w3m, links
Say again?
OK, wenn ich so länger darüber nachdenke, hast Du recht. Aber das ändert nichts daran, dass wir ein einheitliches Format bräuchten.
Wie soll eine Firma ein Programm, das unter der GPL steht, patentieren? Wie soll ein Standard ausfallen?
Wenn ich einen GPL-gif-Creator schreibe, habe ich dann Probleme mit Unisys, oder nicht?
AFAIK nicht, sofern das Programm kostenlos ist. Zahlt GIMP Lizenzgebühren an Unisys? GIF wurde schon viel länger patentiert, das ist nicht vergleichbar.
Wenn ich in den USA ein Programm schrieb, welches RSA[1] verwendete, haette ich dann ein Lizenz-Problem mit der Firma rsa data securities gehabt, oder nicht?
Keine Ahnung, ich weiß nicht, was RSA ist.
Wenn ich ein Progamm schreibe, welches etwas patentiertes verwendet -- gegebenenfalls auch ohne mein Wissen --- kann das Probleme machen?
Ja. Unwissenheit schützt nicht vor Strafe. [Beispiele]
--> Nein, die Firma patentiert nicht ein bestehendes GPL-Programm. Die Firmen patentieren einen Algorithmus. Dieser koennte natuerlich in einem GPL-Programm auftauchen. (So ist z.B. IDEA -- neben RSA die Verschluesselung von PGP2 -- lizensiert. Auch wenn ich ein 'freies' GLP-pgp schreibe, kann ich nicht ohne weiteres IDEA einbinden -- und in der Tat, SuSE liefert(e) pgp2 ohne IDEA,)
Dann könnte praktisch jeder einen »freien« Algorithmus patentieren? Wie weit kann man gehen? Es gibt doch Algorithmen, die in jedem Programm mehr oder weniger auftauchen (z. B. Sortieralgorithmen), also ganz einfache. Kann man sowas auch patentieren lassen oder wie? Mit dem habe ich mich eingentlich noch nicht beschäftigt.
Ja. Und manchmal macht das, was die Distributoren sagen, Sinn.
[Ausführungen] Wenn ich das also richtig verstanden habe, dann müsste z.B. beim Wechsel von Runlevel 2 nach 3 alles gestopt und neu gestartet werden, wenn es nach sysv geht. Macht nicht gerade Sinn.
Es muss ja nicht unbedingt ein ganz gleiches Bootkonzept sein, aber z. B. die Bootscripte könnte man wenigstens an einen einheitlichen Ort verlegen, die Runlevel standardisieren (wäre für einen, der öfter mit mehreren Distris arbeitet eine echte Erleichterung) und sowas in der Richtung.
Welche Runlevel meinen sie, mein Herr? Was sollen diese mysterioesen Runlevel sein? Schon die Existenz von Runleveln ist Bootkonzept-abhaengig!
Es wäre z. B. einfacher, wenn Runlevel 3 immer Netzwerk-Grafisch heißen würde, und wenn man sich nicht erst informieren müsste, welcher Runlevel nun gestartet werden muss, damit man einen grafischen Login vorgesetzt bekommt.
Rein technisch gesehen, will ich in Bezug auf alle 3 Punkte Konkurrenz sehen, um zum einen keine Abhängigkeiten und Monopole entstehen zu lassen (Wurde von Wolfgang sehr treffend ausgeführt) und, so platt es klingen mag, durch Konkurrenz das Geschäft belebt zu sehen.
Mit der gleichen Begründung könnte man Konkurrenz zwischen verschiedenen Linux-Kernel und X11-Systemen (es gibt unterschiedliche Implementierungen, aber nur einen Standard!) anstreben.
Soso. IMHO sind BSD-Style Bootkonzepte und SYSV-Style Bootkonzepte auch nur andere Implementierungen. Genauso wie BSD eine andere Implementierung eines UNIX ist. Genauso wie ein (bestimmtes) Filesystem (z.B. reiserfs, FAT16, ...) nur eine Implementierung eines Filesystems ist.
Du weißt genau, wie ich es meine. Du brauchst jetzt nicht auf irgendwelche Begriffe herumhacken.
Hätte es diese Konkurrenz in der Vergangenheit nicht gegeben, würden wir es heute noch in Bezug auf Paketmanagement alle mit *tar.gz und bestenfalls Slackware's pkgtool zu tun haben.
Woher willst Du das wissen? Meinst Du nicht, dass das auch weiterentwickelt worden wäre.
Was du meinst, ist Evolution statt Revolution^WNeuentwicklung.
Mit dem gleichen Argument wird sich Windows zu einem brauchbaren Unix entwickeln.
Aha. So lange habe ich aber auch wieder nicht Zeit ;) Auf der anderen Seite hast Du nicht ganz unrecht.
Es hätte sich auch mit Standards was getan. Haben sich Programmiersprachen, Protokolle etc. nicht verändert, die von Anfang an standardisiert waren?
K&R C ist IIRC immer noch gueltig. RFC 821 (SMTP) ist von August '82, und immer noch gueltig, und nur in geringsten Teilen genauer spezifiziert worden. (und der Vorgaenger, RFC 788, ist von November '81). Sendmail ist immer noch der am meisten verwendete Mailer.
Ja, es hat sich ein wenig getan. Aber du hast (vermute ich) The Cathedral And The Bazaar & Co nicht verstanden (und auch die Kernelmailingliste nicht verfolgt), sonst wuesstest du, dass in vielen Faellen etwas erst dann in's Rollen kommt, wenn jemand einen vielversprechenden Anfang vorweisen kann, oder Code, oder einen Patch...
Nein, ich verfolge keine Kernelmailinglisten. Wie gesagt, ganz Unrecht gebe ich Dir nicht. Für einen einheitlichen Windowmanager habe ich nichts gesagt, toll wäre aber ein einheitliches Paketformat und, dass sich alle an den FHS halten. Damit könnte man ein Programm A auf Distribution X und Y installieren, ohne großartige Anpassungen vornehmen zu müssen. Ich rede nicht von Systemprogrammen, die auf das Bootkonzept abgestimmt werden müssen. Gruß, Bernhard -- ***** LINUX, weils Betriebssystem eben ned wurscht is! ******** *************** http://www.linux.de ****************** Homepage: http://www.linuxinfopage.de *** Tux # 171705 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com