unter Syllable und fügt sich nicht nahtlos in dieses OS ein. Es fängt schon an mit der Unix typischen Verzeichnisstruktur, die angelegt wird, wenn man derartige POSIX konforme Programme installieren will.
Dadurch gehen natürlich auch die Chancen verloren, denn es wird nie sauber von der Unix Software getrennt sein, so wie man bei Linux verschiedene Window Manager hat, die alle unterschiedlich aussehen, so hat man bei Syllable einen Mischmasch an wenigen nativen Syllable Anwendungen zusammen gemixt mit Unix Programme, die natürlich ihren Unix typischen Verzeichnispfad erfordern und daher wie ein Fremdkörper wirken.
Um dieses Problem zu ändern, müßte man die ganze Software für Syllable native neu schreiben, da das aber niemand mag und das portieren schneller geht wird das so wie es jetzt ist wohl für die restliche Zeit bleiben. Da macht es dann auch keinen Sinn mehr das Homeverzeichnis umzubenennen wenn eh nur ein Bruchteil der Software echte native Syllable konforme Software ist.
Außerdem besteht kein Bedarf mehr an nativer Syllable Software, da die GNU Software ja gut läuft.
Dabei hätte Syllable mal ein sauber getrenntes Desktop OS werden sollen, ohne den Ballast den ein Unix System seit Uhrzeiten mit sich schleppt (nein ich meine nicht X) mitzuschleppen. Aber jetzt wo das portieren von Unix SOftware so einfach geht, wird niemand mehr native Anwendunge schreiben wollen und damit ist es dann auch schon mit Syllable vorbei, denn ein Syllable OS, das halber Unix ist will keiner.
Haiku hat übrigens ähnliche Probleme. Auch da werden die Versuche Haiku möglichst POSIX konform zu machen, dazu führen, daß Unix Software zu Haiku portiert wird und dort dann wie ein Fremdkörper wirkt, denn die Verzeichnispfade die die Unix Software gewähnt sind, will man ja auch nicht umschreiben.
nur um Pfade zu ändern, muss man doch nicht Software komplett neu schreiben. Nebenbei: POSIX sagt doch _Nichts_ über Pfade aus, oder? Du meinst wahrscheinlich LFS oder Unix. Man kann ohne /etc und /usr oder /var völlig POSIX konform sein.
Wenn es "Euch" so wichtig ist, dass Konfigurationsdateien, Bibliotheken, etc. nicht alle jeweils an einem Ort liegen, sondern nach Programm getrennt, dann aber wieder alles pro Programm gemeinsam liegt, dann müsst ihr doch nur die Patches erstellen, mit denen man "configure" und Freunde für die jeweiligen Programme das möglich macht.
Ich weiss, nicht sehr beliebtes Konzept, jemand einen Bedarf ausreden zu wollen, aber was wäre der Vorteil von /Programs/SSH, wenn ich doch einfach folgendes tun kann:
Wenn ich selbst installiere, kann ich entweder --prefix=/usr/local/ oder --prefix=/opt/ssh compilieren, oder eben --prefix=/Programs/SSH also wozu der Aufwand? Was ist das Problem, das gelöst werden soll?
Und ein System ohne SSH, VNC, etc. ist sehr unpraktisch. Ohne SQL-Datenbank kannst Du vieles gleich mal vergessen.
Bei aller Sympathie, auch Linux hat durch dosbox (damals) oder wine (später) die eine oder andere Chance verpasst, aber eben auch bekommen. Wenn das Ziel trägt, wird es schon alles geben. Aber wer keine existierenden Programme ausführen kann, kriegt massiv Probleme damit User zu migrieren.
Es ist ja nicht nur der Verzeichnisort der Angepaßt werden müßte, sondern davon ist auch ein völlig neues Look & Feel betroffen.
Würde man z.b. OS/2 mit seinem Objekt Orientierten Desktop nachprogrammieren wollen, dann wäre das schlichte portieren von Anwendungen von Unix nach OS/2 genauso schlimm, denn die Anwendungen sollen ja Kenntnis vom Objekt Orientierten Desktop haben was bei einer Portierung aber in der Regel nicht passiert, da der Quellcode ja auch auf den anderen Plattformen laufen soll.
Hier sind also schon Designentscheidungen durch die anderen Plattformen vorweggenommen und somit ist völlig neue Art von Desktop OS nicht mehr möglich. Auch Syllable wird diesen Anspruch nicht erfüllen, Haiku aus den gleichen Gründen vermutlich auch nicht. Beide OS werden also mehr oder weniger wie jedes Unix OS auch, gleich sein.
Um mal ein Beispiel erweiterter Features zu nennen. Haiku bietet Transports & Attribute für Dateien die die Dateien beschreiben aber nicht zur Datei gehören. Damit könnte man sehr viele neue Möglichkeiten haben, aber damit das ganze Konsitent bleibt müßten alle Anwendungen damit umgehen können, was bei einfachen Ports nie passieren wird. Bei Linux sind die Attribute von Dateien auch nur aufgesetzt, eine echte Integration hat nie stattgefunden. Wenn du z.b. in Linux mit dem Konsolenbefehl rm eine Bilddatei löschst, dann wird zwar die Bilddatei gelöscht, nicht aber die Thumbnail Datei die sich im ./thumb Ordner befindet. rm müßte also davon Kenntnis haben oder man müßte die Dateien anders strukturiert speichern, wie z.B. in Haiku.
Aber wenn ich in Haiku Bildateien Attribute zuweisen kann, dann sollte die Anwendung darüber natürlich auch bescheid wissen, was bei einem GIMP Port aber nicht der Fall ist.
Das sind die Probleme von diesen ganzen Portierungen. Und da du SSH, VNC und SQL ansprichst. Man sollte sich schon Fragen was man eigentlich will. Jetzt eine ganz schnelle Lösung, nur damit die anderen Programme auf diesem OS laufen (ein meiner Meinung nach unsauberer Weg) oder die Programme erst gar nicht portieren und stattdessen native integrierte Programme die das gleiche können von Anfang an neu schreiben. Letzteres würde zwar deutlich länger dauern, aber nur so erreicht man das eigentliche Ziel ein völlig neues OS zu haben.
In diesem Zusammenhang Haiku anzuführen, finde ich sehr unglücklich. Der reine GUI-Nutzer merkt von der Posix-Kompatibiltät nichts, insofern er das Terminal nicht anfasst. Bei BeOS war das genauso. Der BeOS-Nutzer mußte von irgendwelchen Verzeichnisstrukturen nichts wissen, die Nutzung der posix-kompatiblen Shell war ebenfalls nicht nötig. In dieser Hinsicht war BeOS wie Windows. Das gilt auch für Haiku. Der einzige Unterschied: Haiku ist frei, "free as in freedom". Schau doch einmal, welche Software konkret für BeOS und Haiku angeboten wird: bebits.com und haikuware.com. Deine "Fremdsoftware-Befürchtungen" haben keine Grundlage. Nenne mir doch bitte ein paar "Fremdkörper".
> Der reine GUI-Nutzer merkt von der Posix-Kompatibiltät nichts, insofern er das Terminal nicht anfasst.
Ein Konsistentes OS müßte auch die Konsole berücksichtigen. Genau das ist ja das Problem.
Bei Linux ist alles nur ein Desktop Aufsatz, eine echte Integration hat nie stattgefunden.
> Nenne mir doch bitte ein paar "Fremdkörper".
Die Bash, eine Shell die keine in das OS gut integrierte Shell ist und von Transports und den Attributen des Haiku Dateisystems keine Ahnung hat.
Und das der Haiku User keine Shell brauchen würde ist ein ungültiges Argument, denn ein Dateimanager ersetzt keine Shell und umgekehrt. Beides geht Hand in Hand und beide sind in ihren jeweils verschiedenen Aufgabengebieten besser geeignet als das andere. Aus genau diesem Grund muß auch eine Shell im OS gut und wohlgeformt integriert sein.
Und dann kannst du mir mal sagen warum es nichts ähnlich Leistungsfähiges wie Gimp unter Haiku als Open Source gibt. Ich kann dir das sagen, weil Gimp selbst schon unter Haiku läuft und daher kein Bedarf mehr für eine wohl konform integrierte Anwendung mehr besteht. Bzw. der Bedarf wäre vielleicht da, aber niemand macht sich den Aufwanf weil ja gerade Gimp schon läuft. Und Gimp selbst ist absolut nicht gut in Haiku integriert.
Ich denke, Du bist im falschen Film. Haiku wird BeOS-kompatibel sein und damit läuft die Software, die sich BeOS-Nutzer (Netserver und Bone) früher gekauft haben, z.B. Pixel, Wonderbrush, Refraction oder auch Becasso. (siehe auch http://www.bebits.com/browse/128)
Ich glaube kaum, dass ein Haiku- oder BeOS-Nutzer, der stets eine schnelle Arbeitsgeschwindigkeit gewohnt ist, überhaupt eine Installation von Gimp in Erwägung zieht. Man muß sich schließlich noch zusätzlich GTK und das unter BeOS/Haiku recht instabile X11-Gedöns installieren. Dieser Tortur setzt sich praktisch niemand aus. http://www.haikuware.com/view-details/multimedia/graphics/image-editors/gimp Da kann man auch gleich Linux starten.
Es geht wirklich nur um Posix-Kompatibilität, nicht mehr. Haiku ist kein Linux oder Unix.
Und ich denke du bist realitätsfremd, vermutlich denkst du daher auch an Filme.
> Haiku wird BeOS-kompatibel sein und damit läuft die Software, die sich BeOS-Nutzer > (Netserver und Bone) früher gekauft haben, z.B. Pixel, Wonderbrush, Refraction oder auch Becasso.
Was willst du mit über 10 Jahre veralteter Software die nicht mehr für BeOS weiterentwickelt wird? Man muß das ganze schon realistisch betrachten und Open Source ist diese Software ganz gewiss nicht.
> Ich glaube kaum, dass ein Haiku- oder BeOS-Nutzer, der stets eine schnelle Arbeitsgeschwindigkeit gewohnt ist, überhaupt eine Installation von Gimp in Erwägung zieht.
Wenn du keine Alternativen hast nimmst du das was da ist. Und deine von dir genannten Programme sind ja weder OpenSource, noch aktuell und für Privatverbraucht die darauf achten, auch nicht kostenlos.
> Da kann man auch gleich Linux starten.
Natürlich, aber genau das gibt mir ja Recht. Es gibt schlichtweg kaum native Anwendungen für Haiku oder Syllable und ich habe auch noch niemanden gesehen, deinen Gimp Ersatz nativ für Haiku programmiert und das ganze unter eine Open Source Lizenz stellt.
Ich habe Dir die Software-Links oben genannt. Ich kenne auch niemanden, der unter BeOS, Zeta oder Haiku Gimp oder irgendeine Software benutzt, die X11 zum Starten braucht.
Diese X11-Ports sind ohnehin recht alt (das betreffende Xbeosnative wurde zum letzten Mal am 01.10.2003 aktualisiert: http://bebits.com/app/3606) und in diesem Sinne als gescheitert zu betrachten. Der andere X11-Port ist sogar noch über zwei Jahre älter (http://bebits.com/app/337).
Posix-Kompatibilität heißt eben auch, dass man Software entwickeln kann, die eben nicht posix-kompatibel sein muß und trotzdem läuft. Letzteres ist im Hinblick auf GUI-Anwendungen in der BeOS-/Haiku-Welt der Normalfall. Gimp braucht niemand unter BeOS/Haiku, es gibt genügend andere Software (s.o.).
Deshalb sagte ich, dass Du Dich im falschen Film befindest: Im Hinblick auf GUI-Anwendungen stürzt Du Dich auf ein Problem, dass es unter BeOS und Haiku gar nicht gibt.
Es fängt schon an mit der Unix typischen Verzeichnisstruktur, die angelegt wird, wenn man derartige POSIX konforme Programme
installieren will.
Dadurch gehen natürlich auch die Chancen verloren, denn es wird nie sauber von der Unix Software getrennt sein, so wie man bei Linux verschiedene Window Manager hat, die alle unterschiedlich aussehen, so hat man bei Syllable einen Mischmasch an wenigen nativen Syllable Anwendungen zusammen gemixt mit Unix Programme, die natürlich ihren Unix typischen Verzeichnispfad erfordern und daher wie ein Fremdkörper wirken.
Um dieses Problem zu ändern, müßte man die ganze Software für Syllable native neu schreiben, da das aber niemand mag und das portieren schneller geht wird das so wie es jetzt ist wohl für die restliche Zeit bleiben.
Da macht es dann auch keinen Sinn mehr das Homeverzeichnis umzubenennen wenn eh nur ein Bruchteil der Software echte native Syllable konforme Software ist.
Außerdem besteht kein Bedarf mehr an nativer Syllable Software, da die GNU Software ja gut läuft.
Dabei hätte Syllable mal ein sauber getrenntes Desktop OS werden sollen, ohne den Ballast den ein Unix System seit Uhrzeiten mit sich schleppt (nein ich meine nicht X) mitzuschleppen.
Aber jetzt wo das portieren von Unix SOftware so einfach geht, wird niemand mehr native Anwendunge schreiben wollen und damit ist es dann auch schon mit Syllable vorbei,
denn ein Syllable OS, das halber Unix ist will keiner.
Haiku hat übrigens ähnliche Probleme.
Auch da werden die Versuche Haiku möglichst POSIX konform zu machen, dazu führen, daß Unix Software zu Haiku portiert wird und dort dann wie ein Fremdkörper wirkt, denn
die Verzeichnispfade die die Unix Software gewähnt sind, will man ja auch nicht umschreiben.
nur um Pfade zu ändern, muss man doch nicht Software komplett neu schreiben. Nebenbei: POSIX sagt doch _Nichts_ über Pfade aus, oder? Du meinst wahrscheinlich LFS oder Unix. Man kann ohne /etc und /usr oder /var völlig POSIX konform sein.
Wenn es "Euch" so wichtig ist, dass Konfigurationsdateien, Bibliotheken, etc. nicht alle jeweils an einem Ort liegen, sondern nach Programm getrennt, dann aber wieder alles pro Programm gemeinsam liegt, dann müsst ihr doch nur die Patches erstellen, mit denen man "configure" und Freunde für die jeweiligen Programme das möglich macht.
Ich weiss, nicht sehr beliebtes Konzept, jemand einen Bedarf ausreden zu wollen, aber was wäre der Vorteil von /Programs/SSH, wenn ich doch einfach folgendes tun kann:
[~]> dpkg -L openssh-server
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/openssh-client
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/openssh-server
/usr/share/man
/usr/share/man/man5
/usr/share/man/man5/sshd_config.5.gz
/usr/share/man/man8
/usr/share/man/man8/sshd.8.gz
/usr/share/man/man8/sftp-server.8.gz
/usr/lib
/usr/lib/openssh
/usr/lib/openssh/sftp-server
/usr/sbin
/usr/sbin/sshd
/etc
/etc/init.d
/etc/init.d/ssh
/etc/default
/etc/default/ssh
/etc/pam.d
/etc/pam.d/sshd
/etc/network
/etc/network/if-up.d
/etc/network/if-up.d/openssh-server
/var
/var/run
/var/run/sshd
/usr/share/doc/openssh-server
/usr/share/man/man5/authorized_keys.5.gz
/usr/lib/sftp-server
Wenn ich selbst installiere, kann ich entweder --prefix=/usr/local/ oder --prefix=/opt/ssh compilieren, oder eben --prefix=/Programs/SSH also wozu der Aufwand? Was ist das Problem, das gelöst werden soll?
Und ein System ohne SSH, VNC, etc. ist sehr unpraktisch. Ohne SQL-Datenbank kannst Du vieles gleich mal vergessen.
Bei aller Sympathie, auch Linux hat durch dosbox (damals) oder wine (später) die eine oder andere Chance verpasst, aber eben auch bekommen. Wenn das Ziel trägt, wird es schon alles geben. Aber wer keine existierenden Programme ausführen kann, kriegt massiv Probleme damit User zu migrieren.
Gruss,
Kay
davon ist auch ein völlig neues Look & Feel betroffen.
Würde man z.b. OS/2 mit seinem Objekt Orientierten Desktop nachprogrammieren wollen,
dann wäre das schlichte portieren von Anwendungen von Unix nach OS/2 genauso schlimm,
denn die Anwendungen sollen ja Kenntnis vom Objekt Orientierten Desktop haben was bei einer Portierung aber in der Regel nicht passiert, da der Quellcode ja auch auf den anderen Plattformen laufen soll.
Hier sind also schon Designentscheidungen durch die anderen Plattformen vorweggenommen
und somit ist völlig neue Art von Desktop OS nicht mehr möglich.
Auch Syllable wird diesen Anspruch nicht erfüllen, Haiku aus den gleichen Gründen vermutlich auch nicht.
Beide OS werden also mehr oder weniger wie jedes Unix OS auch, gleich sein.
Um mal ein Beispiel erweiterter Features zu nennen.
Haiku bietet Transports & Attribute für Dateien die die Dateien beschreiben aber
nicht zur Datei gehören.
Damit könnte man sehr viele neue Möglichkeiten haben, aber damit das ganze Konsitent bleibt müßten alle Anwendungen damit umgehen können, was bei einfachen Ports nie passieren wird.
Bei Linux sind die Attribute von Dateien auch nur aufgesetzt, eine echte Integration hat nie stattgefunden.
Wenn du z.b. in Linux mit dem Konsolenbefehl rm eine Bilddatei löschst, dann wird zwar die Bilddatei gelöscht, nicht aber die Thumbnail Datei die sich im ./thumb Ordner befindet.
rm müßte also davon Kenntnis haben oder man müßte die Dateien anders strukturiert speichern, wie z.B. in Haiku.
Aber wenn ich in Haiku Bildateien Attribute zuweisen kann, dann sollte die Anwendung darüber natürlich auch bescheid wissen, was bei einem GIMP Port aber nicht der Fall ist.
Das sind die Probleme von diesen ganzen Portierungen.
Und da du SSH, VNC und SQL ansprichst.
Man sollte sich schon Fragen was man eigentlich will.
Jetzt eine ganz schnelle Lösung, nur damit die anderen Programme auf diesem OS laufen
(ein meiner Meinung nach unsauberer Weg) oder die Programme erst gar nicht portieren und stattdessen native integrierte Programme die das gleiche können von Anfang an neu schreiben.
Letzteres würde zwar deutlich länger dauern, aber nur so erreicht man das eigentliche Ziel ein völlig neues OS zu haben.
Der reine GUI-Nutzer merkt von der Posix-Kompatibiltät nichts, insofern er das Terminal nicht anfasst.
Bei BeOS war das genauso.
Der BeOS-Nutzer mußte von irgendwelchen Verzeichnisstrukturen nichts wissen, die Nutzung der posix-kompatiblen Shell war ebenfalls nicht nötig. In dieser Hinsicht war BeOS wie Windows.
Das gilt auch für Haiku. Der einzige Unterschied: Haiku ist frei, "free as in freedom".
Schau doch einmal, welche Software konkret für BeOS und Haiku angeboten wird: bebits.com und haikuware.com.
Deine "Fremdsoftware-Befürchtungen" haben keine Grundlage.
Nenne mir doch bitte ein paar "Fremdkörper".
Ein Konsistentes OS müßte auch die Konsole berücksichtigen.
Genau das ist ja das Problem.
Bei Linux ist alles nur ein Desktop Aufsatz, eine echte Integration hat nie stattgefunden.
> Nenne mir doch bitte ein paar "Fremdkörper".
Die Bash, eine Shell die keine in das OS gut integrierte Shell ist und von Transports und den Attributen des Haiku Dateisystems keine Ahnung hat.
Und das der Haiku User keine Shell brauchen würde ist ein ungültiges Argument,
denn ein Dateimanager ersetzt keine Shell und umgekehrt.
Beides geht Hand in Hand und beide sind in ihren jeweils verschiedenen Aufgabengebieten besser geeignet als das andere.
Aus genau diesem Grund muß auch eine Shell im OS gut und wohlgeformt integriert sein.
Und dann kannst du mir mal sagen warum es nichts ähnlich Leistungsfähiges wie Gimp unter Haiku als Open Source gibt.
Ich kann dir das sagen, weil Gimp selbst schon unter Haiku läuft und daher kein Bedarf mehr für eine wohl konform integrierte Anwendung mehr besteht.
Bzw. der Bedarf wäre vielleicht da, aber niemand macht sich den Aufwanf weil ja gerade Gimp schon läuft.
Und Gimp selbst ist absolut nicht gut in Haiku integriert.
Haiku wird BeOS-kompatibel sein und damit läuft die Software, die sich BeOS-Nutzer (Netserver und Bone) früher gekauft haben, z.B. Pixel, Wonderbrush, Refraction oder auch Becasso.
(siehe auch http://www.bebits.com/browse/128)
Ich glaube kaum, dass ein Haiku- oder BeOS-Nutzer, der stets eine schnelle Arbeitsgeschwindigkeit gewohnt ist, überhaupt eine Installation von Gimp in Erwägung zieht.
Man muß sich schließlich noch zusätzlich GTK und das unter BeOS/Haiku recht instabile X11-Gedöns installieren.
Dieser Tortur setzt sich praktisch niemand aus.
http://www.haikuware.com/view-details/multimedia/graphics/image-editors/gimp
Da kann man auch gleich Linux starten.
Es geht wirklich nur um Posix-Kompatibilität, nicht mehr. Haiku ist kein Linux oder Unix.
Und ich denke du bist realitätsfremd, vermutlich denkst du daher auch an Filme.
> Haiku wird BeOS-kompatibel sein und damit läuft die Software, die sich BeOS-Nutzer
> (Netserver und Bone) früher gekauft haben, z.B. Pixel, Wonderbrush, Refraction oder auch Becasso.
Was willst du mit über 10 Jahre veralteter Software die nicht mehr für BeOS weiterentwickelt wird?
Man muß das ganze schon realistisch betrachten und Open Source ist diese Software ganz gewiss nicht.
> Ich glaube kaum, dass ein Haiku- oder BeOS-Nutzer, der stets eine schnelle Arbeitsgeschwindigkeit gewohnt ist, überhaupt eine Installation von Gimp in Erwägung zieht.
Wenn du keine Alternativen hast nimmst du das was da ist.
Und deine von dir genannten Programme sind ja weder OpenSource, noch aktuell und für Privatverbraucht die darauf achten, auch nicht kostenlos.
> Da kann man auch gleich Linux starten.
Natürlich, aber genau das gibt mir ja Recht.
Es gibt schlichtweg kaum native Anwendungen für Haiku oder Syllable
und ich habe auch noch niemanden gesehen, deinen Gimp Ersatz nativ für Haiku programmiert
und das ganze unter eine Open Source Lizenz stellt.
Ich kenne auch niemanden, der unter BeOS, Zeta oder Haiku Gimp oder irgendeine Software benutzt, die X11 zum Starten braucht.
Diese X11-Ports sind ohnehin recht alt (das betreffende Xbeosnative wurde zum letzten Mal am 01.10.2003 aktualisiert: http://bebits.com/app/3606) und in diesem Sinne als gescheitert zu betrachten. Der andere X11-Port ist sogar noch über zwei Jahre älter (http://bebits.com/app/337).
Posix-Kompatibilität heißt eben auch, dass man Software entwickeln kann, die eben nicht posix-kompatibel sein muß und trotzdem läuft.
Letzteres ist im Hinblick auf GUI-Anwendungen in der BeOS-/Haiku-Welt der Normalfall.
Gimp braucht niemand unter BeOS/Haiku, es gibt genügend andere Software (s.o.).
Deshalb sagte ich, dass Du Dich im falschen Film befindest:
Im Hinblick auf GUI-Anwendungen stürzt Du Dich auf ein Problem, dass es unter BeOS und Haiku gar nicht gibt.