Von Baumgartner Martin am Di, 30. Mai 2006 um 10:32 #
dafür bekommst du ja auch die ersten beiden dazu. Ausserdem darfst du nicht vergessen dass in Zeiten des Highspeedinternets es leider schwer geworden ist für Distributionen sich am leben zu erhalten. Man beachte nur die finanziellen Schwierigkeiten von OpenBSD.
Die Programme werden inklusive ihrer Bibliotheken in eigene Verzeichnisse kopiert? Da muss das Paketsystem dann aber entsprechend schlau sein zu erkennen ob die lib vielleicht doch noch von anderen Anwendungen mitbenutzt wird und demzufolge doch eher in einen Systemordner sollte... Ansonsten ist das Konzept nicht verkehrt. Wenn die Ports ausserdem noch benutzt werden können, ist man aber dann doch wieder dabei dieses System aufzubrechen und nach alter FreeBSD-Manier es zu installieren...
Vom Text her macht es zumindest den Eindruck als wäre es eine recht runde Sache. Noch etwas einfacher als FreeBSD und etwas vorkonfiguriert, hört sich also nicht schlecht an.
Von Marcus der Werner am Di, 30. Mai 2006 um 11:23 #
Hi Beasti. Die FREE BSD Ports kannst du ganz normal mit verwenden und von dort programme installieren. Alle Teile der Programme die als PBI installiert werden landen in einem Verzeichniss. Hat den Vorteil daß bei der Deinstallation alles komplett verschwindet. Nachteil ist, daß einige Libs doppelt installiert werden.
Ansonsten finde ich PCBSD richtig klasse. Müsst mal auf die PBI Seite gehen, was es da schon alles an Software gibt.
> Die Programme werden inklusive ihrer Bibliotheken in eigene > Verzeichnisse kopiert? Da muss das Paketsystem dann aber > entsprechend schlau sein zu erkennen ob die lib vielleicht > doch noch von anderen Anwendungen mitbenutzt wird und > demzufolge doch eher in einen Systemordner sollte...
Fehlanzeige: So schlau ist der Paketmanager dann leider doch nicht, und entsprechend unschlau ist auch das Ergebnis: Im Zweifelsfall werden Bibliotheken halt einfach mehrfach installiert, selbst wenn sie von mehreren Bibliotheken gemeinsam benutzt werden könnten.
Insgesamt also eine sehr gelungene Kopie gewisser "M$"-Produkte, bei denen eine gewisse gdiplus.dll auch mehrfach installiert wird und bei Problemen gleich mehrfach gepatcht werden darf. Wer weiß, vielleicht machen die PC-BSDler "M$" in so einem Fall auch wieder nach und liefern ein nettes Tool mit, das die ganzen mehrfach installierten Bibliotheken wieder aufsammelt.
Sorry, so läuft das nicht: Entweder UNIX oder einfach. Beides gleichzeitig wird nicht gehen. Auch nicht mit angeblich die Installation vereinfachenden Doppelbibliotheken.
> Sorry, so läuft das nicht: Entweder UNIX oder einfach. Beides gleichzeitig wird nicht gehen. Auch nicht mit angeblich die Installation vereinfachenden Doppelbibliotheken.
Nix da! Ist doch ein klasse Konzept das ich bei Linux schon öfter sehr vermisst habe. Normalerweise nimmt man die Ports, bei Linux halt den Paketmanager.
Aber wenn man ein Programm unbedingt in einer speziellen Version haben möchte dann ist das doch eine tolle Sache. Man kann also z.B. ewig mit einem uralt Programm arbeiten, das restliche System aber aktuell halten. Ganz ohne Neukompilieren oder anderweitige Klimmzüge. Das ist doch sehr elegant! Ich habe hier noch einen alten Compiler laufen, für den ich extra einen eigenen Rechner mit Suse 8.0 am laufen halten muss. Und ich will den Compiler in den nächsten fünf Jahren auch nicht mehr anfassen müssen!!!
Das ganze erinnert mich ein wenig an Klick, obwohl da sicherlich Unterschiede bestehen.
Ich wünsche dem Projekt viel Erfolg und vielleicht die Muße das ganze nach Linux zu portieren.
Das Riesenproblem bei diesem Konzept ist nur, das wenn in irgendeiner Bibliothek (sagen wir mal libssl.o) ein Problem auftaucht und diese Bibliothek dank dieses tollen Installationskonzeptes 30x in verschiedenen Paketverzeichnissen installiert ist, diese 30 Pakete alle aktualisiert werden müssen. Es reicht nicht einfach nur die Lib zu aktualiesieren, sondern man muss alle Pakete aktualisieren. Das ist erstens ziemlich unökonomisch (nicht jeder hat DSL) und zweitens ziemlich fehleranfällig.
Deine Argumentation ist nicht ganz fehlerfrei: Um den Aufwand beider Konzepte vergleichen zu können, muß man natürlich Situationen betrachten, die den gleichen Nutzen liefern.
Anders augedrückt: Vergleiche Dein Beispiel mit den Aufwand, 30 verschiedene Anwendungsprogramme manuell in der neusten Version zu installieren, inklusive aller benötigten Bibliotheken, die nicht vom Betriebssystem in der richtigen Version bereitsgestellt wird.
Und dann rechne das Ganze hoch auf einige Hundertausend Nutzer.
Willst Du immer noch behaupten, das Konzept sei unökonomisch?
Es ist natürlich Unsinn alle Software auf einem Rechner mit diesem System zu installieren! Dafür nutzt man das Paketmanagement der Distribution oder hier die Ports. AAAAAAber: Um ein bestimmtes Programm in einer bestimmten Version zu installieren ist es Goldrichtig.
Beispiele: 1) Ein Webdesigner muss die Wirkung seines Getippes auf unterschiedlichen Versionen eines Browsers testen.
2) Ich habe eine Version des AVR-GCC die ich behalten möchte! Für die neueren Versionen des GCC müßte ich den Code einer umfangreichen Mikrocontrollerregelung verändern, was ich aber nicht will. Der alte Code ist getestet und freigegeben. Wer weiß ob eine neuere Version des GCC nicht doch Code erzeugt der sich in irgendeiner seltenen Situation nicht so wie geplant verhält. Da das Projekt schon älter ist und auch noch einige Jahre laufen wird, muss momentan ein Uraltsystem am leben gehalten werden. An diesem System muss auch keine Bibliothek erneuert werden. Er läuft ja problemlos. Was neues wird nicht darauf installiert, basta (er hat nur die eine Aufgabe)! Der Rechner hat aus Sicherheitsgründen keinen Anschluss ans Netzwerk. Mit dem Neuen Installationstool könnte man sich diesen Aufwand schenken und überall die benötigte GCC-Version installieren!
Von Marcus der Werner am Di, 30. Mai 2006 um 13:08 #
Hi Mark
Muss dir ungeingenommen zustimmen. Das Konzept ist klasse. Ich habe zum Beispiel auf meiner PCBSD Testmaschine unterschiedliche Versionen eines Programmes (z.B. Firefox) und sie laufen problemlos nebeneinander. Bei der Deinstallazin wird dann das komplette Verzeichnis rückstandsfrei gelöscht, sodaߎnicht die Gefahr besteht, daß irgendwelche "rest libs" übrigbleiben.
Sorry, so läuft das nicht: Entweder UNIX oder einfach. Beides gleichzeitig wird nicht gehen.
So, so. Und mit welchem Argument stützt Du Deine Behauptung?
Sag' mal: Wenn ich mir jetzt aus die Quellen irgendeine Bibliothek manuell nach /usr/local/ installiere -- sie muß nicht mal doppelt vorhanden sein --, wer patcht sie dann, wenn nicht ich? Und wie wahrscheinlich ist es, daß eine Heim-Anwender die Sicherheitsmeldungen studiert um seine manuell eingespielten Bibliotheken zu patchen?
Du siehst: Bereits jetzt geht es am System der Distri vorbei!
Das Gegenteil ist eher der Fall: Ohne einfache Installation von End-User-Software per Installer wird nie etwas aus Linux auf dem Desktop. Die Frage ist vielmehr, ob man die Distris versuchen, das Unvermeidbare zu beherrschen. Oder, ob das ein Chaos wird, wie zu den Anfängen von Microsoft. Gegenwärtig sieht es ja eher nach letzterem aus.
Der Witz ist nicht schlecht, hab Solaris 10 mehr als ein halbes jahr auf der Maschine gehabt (um die neuen Funktionen auszutesten)....aber irgendwie es kommt mir lahm vor und absolut unoptimiert auf x86 von stabil kann irgendwie auch keine rede sein (auf x86??) war echt nicht glücklich damit also zurück zu Debian, dass man irgendwie auch als unix bezeichnen kann.
Habe aber vergessen das ich das Projekt Nexenta genial finde (Solariskernel+Debian-packetsystem). Ich hoffe das dieses System langelange weiterlebt und den Kernel auf x86+x86_64 schnell verbessern wird, also diese Distri kann ich weiterempfehlen.
Ja da könntest du recht haben da Sun ja server mit Amd64 herstellt und es ja eigentlich auch die Zukunft ist, trotzdem fand ich es schade das es so langsam lief auf meinem uralt P4 aber ja denke auch das du recht hast da sie die meiste optimierungsarbeit auf x86/64 und Sparc leisten...wahrscheinlich.
Bestehen für einen Nur-Anwender nennenswerte Unterschiede zwischen einem Linux-KDE und einem BSD-KDE? Oder anders gefragt: Wenn ich in meiner kleinen Firma ein paar Rechner auf BSD und einige unter Linux jeweils mit KDE laufen habe, kann ein DAU mit beiden arbeiten? Natürlich gleiche Software vorausgesetzt (z.B. OpenOffice). Oder braucht er eine neue Einweisung?
Nimm das gleiche Icon-Theme und die gleiche X-Auflösung - installiere die gleichen Programme und passe die Menüstruktur der User aneinander an - fertig.
BTW: PC-BSC ist für mich das absolut DAU-taugliche OS, schnell aufgesetzt, vernünftige Performance (in der Default-Version).
Bei Ooorg solltest du keine Probleme bekommen - du must bei den *.pbi von PC-BSD halt nur die Wörterbücher für die Rechtschreibung und Thesaurus händisch nachinstallieren, was sich bei Suse z.B. erübrigt.
Also ich würde mir das schon noch genauer überlegen ...
Ich habe PC-BSD vor kurzem mit dem VMplayer getestet. Durch KDE und Oberflächenanpassungen kann man das Aussehen zwar ähnlich gestalten wie bei Linuxen mit KDE. Ich hatte aber den Eindruck, dass es "unter der Haube" schon einige Unterschiede gibt, z.B. Paketverwaltung/Softwareinstallationen (und -quellen), Steuerung von Serverdiensten und Anpassungen bei Hardware-Einrichtungen.
Letztlich habe ich keinen Vorteil z.B. gegenüber Debian/(K)Ubuntu oder Suse gesehen und spare mir daher die Mühe, mich wieder in ein neues System einzuarbeiten und verschiedene __nix-Systeme zu pflegen. Und wenn, dann würde mich zur Zeit vorallem Solaris reizen.
Man sieht keinen Unterschied und merkt auch keinen. Alleine Mangels HAL poppen Icons auf dem Desktop nicht automatisch auf wenn man ein USB-Gerät einstöpselt. Das kann man allerdings mit etwas gescripte hinbiegen da FreeBSD/PC-BSD ja das devfs nutzt. KDE ist unter Linux und FreeBSD identisch, bis auf den angesprochen Punkt der Unterstützung von HAL.
Wie viele andere FreeBSD-basierte Betriebssysteme gibt es denn? Soviel ich weiss momentan nur 2 (zumindest bekanntere): Desktop-BSD und PC-BSD. Wenn man MacOS X mit dem Userland-FreeBSD mitrechnet wären es halt 3. Das sind im Vergleich mit den hunderten Distributionen von Linux ja nun wirklich keine Massen
DragonFlyBSD ist ein FreeBSD derivat. Auch wenn es sich nun schon auseinanderentwickelt hat. Außerdem gab es noch ein *FlyBSD, war aber imho komzeriell.
Na ja, hängt vom Gastrechner ab. Ich habe Desktop- BSD (da wird es wohl keine bahnbrechenden Unterschiede zu PC- BSD geben) auf einem nicht mehr so ganz aktuellen AMD-Sempron 2600 mit 512 MB, davon 192 MB für Qemu, ausprobiert - es ist schon grottenlangsam.
Aber (K)Ubuntu ist noch schlimmer - erträglich wird es auf meinem Rechner erst, wenn ich ein schlankes Linux nehme - SuSE 5.3 z.B. oder Slackware bzw. ein Slackware- Derivat. In einer Qemu- VM merkt man doch recht deutlich, welche Distries sparsam mit den Ressourcen umgehen....
Ich habe mir die obigen vielen Beiträge jetzt alle durchgelesen und bin schon sehr verwundert über manch Ergüsse hier.
Als die Vers. 1.0 herauskam, hab ich mir die eine ISO gezogen und das System aus Neugier einmal installiert. War sehr positiv überrascht. Das Ding macht Sinn - nicht überladen, recht flott und zügig in jeder Beziehung.
Die Dokumentation zu den BSD OSen im Netz ist ausserdem erstklassig. Habe ich bemerkt, als ich z.B. meine TV-Karte mit links zum Laufen brachte.
Der einzige "Schönheitsfehler" welcher mir bis jetzt aufgefallen ist, dass manch Non-OSS Weichware einfach nicht vorhanden ist. Über den Umweg eines Linuxpaketes z.B. das Flashplugin ins System zu bekommen (braucht man leider immer öfter...) ist schon kniffelig.
Aber ansonsten möchte ich den ewigen Meckerern hier schon einmal anraten einmal wirklich über den Tellerand zu schauen und erst nachher zu kommentieren.
Mag sein das PCBSD nur Dau-sicher ist, wenn man es nimmt wie es ist (dann trifft es zu), aber wofür hätten sich die lieben guten Leute sonst die viele Arbeit für die Doku gemacht?!?
Stimmt, Flashplayer etc. sind zum Teil ein Krampf. Liegt aber auch daran das die Ports nicht immer richtig synchronisiert sind. Z.B. ist bei den aktuellen Stand der Ports Flashplayer7 aktuell, der wiederum wird als Alpha bezeichnet und lässt z.B. den FreeBSD-Firefox abstürzen... Flashplayer6 der funktionierte, ist zwar noch in den Ports aber maskiert (soll nicht mehr benutzt werden). Was nun? Hilft dann nur den Linux-Firefox zu installieren, bei dem funktioniert alles wie man es erwartet... Openoffice? Auch so ein Ding... In den Ports ist 2.0.3rc3 aktuell, für diesen Port gibts aber nirgends ein fertiges Paket und Openoffice selber bauen ist nun nicht jedem sein Ding (zumal das an die 9GB Platz braucht und vieeel Zeit). Erstaunlicherweise laufen Realplayer und Acrobat Reader sofort, werden sogar automatisch mit dem Linuxwrapper installiert...
Nicht-OSS ist eigentlich kein Problem unter BSD. Problematisch ist eher das oft die Ports und Packages nicht richtig synchron sind. Dann steht man halt da, weil das eine nicht richtig zum anderen passt.
Nichts gegen BSD ... wirklich nicht!
Ich meine, wie kann man KDE so häßlich machen ..... dieses Icon-Theme :D
WOW! Das nenne ich mal unverschämt!
Die ersten beiden CDs sind ja kostenlos runterladbar.
Aber die dritte CD, welche aus OSS besteht dann für 49 US Dollar zu verticken ist ja mal mehr als frech.
Wenn die Ports ausserdem noch benutzt werden können, ist man aber dann doch wieder dabei dieses System aufzubrechen und nach alter FreeBSD-Manier es zu installieren...
Vom Text her macht es zumindest den Eindruck als wäre es eine recht runde Sache. Noch etwas einfacher als FreeBSD und etwas vorkonfiguriert, hört sich also nicht schlecht an.
Alle Teile der Programme die als PBI installiert werden landen in einem Verzeichniss. Hat den Vorteil daß bei der Deinstallation alles komplett verschwindet. Nachteil ist, daß einige Libs doppelt installiert werden.
Ansonsten finde ich PCBSD richtig klasse. Müsst mal auf die PBI Seite gehen, was es da schon alles an Software gibt.
Keep PCBSDŽin
Marcus Werner
PCBSD PBI Testing Team
> Verzeichnisse kopiert? Da muss das Paketsystem dann aber
> entsprechend schlau sein zu erkennen ob die lib vielleicht
> doch noch von anderen Anwendungen mitbenutzt wird und
> demzufolge doch eher in einen Systemordner sollte...
Fehlanzeige: So schlau ist der Paketmanager dann leider doch nicht, und entsprechend unschlau ist auch das Ergebnis: Im Zweifelsfall werden Bibliotheken halt einfach mehrfach installiert, selbst wenn sie von mehreren Bibliotheken gemeinsam benutzt werden könnten.
Insgesamt also eine sehr gelungene Kopie gewisser "M$"-Produkte, bei denen eine gewisse gdiplus.dll auch mehrfach installiert wird und bei Problemen gleich mehrfach gepatcht werden darf. Wer weiß, vielleicht machen die PC-BSDler "M$" in so einem Fall auch wieder nach und liefern ein nettes Tool mit, das die ganzen mehrfach installierten Bibliotheken wieder aufsammelt.
Sorry, so läuft das nicht: Entweder UNIX oder einfach. Beides gleichzeitig wird nicht gehen. Auch nicht mit angeblich die Installation vereinfachenden Doppelbibliotheken.
Nix da!
Ist doch ein klasse Konzept das ich bei Linux schon öfter sehr vermisst habe.
Normalerweise nimmt man die Ports, bei Linux halt den Paketmanager.
Aber wenn man ein Programm unbedingt in einer speziellen Version haben möchte dann ist das doch eine tolle Sache.
Man kann also z.B. ewig mit einem uralt Programm arbeiten, das restliche System aber aktuell halten.
Ganz ohne Neukompilieren oder anderweitige Klimmzüge. Das ist doch sehr elegant!
Ich habe hier noch einen alten Compiler laufen, für den ich extra einen eigenen Rechner mit Suse 8.0 am laufen halten muss. Und ich will den Compiler in den nächsten fünf Jahren auch nicht mehr anfassen müssen!!!
Das ganze erinnert mich ein wenig an Klick, obwohl da sicherlich Unterschiede bestehen.
Ich wünsche dem Projekt viel Erfolg und vielleicht die Muße das ganze nach Linux zu portieren.
Gruß
Mark
Es reicht nicht einfach nur die Lib zu aktualiesieren, sondern man muss alle Pakete aktualisieren. Das ist erstens ziemlich unökonomisch (nicht jeder hat DSL) und zweitens ziemlich fehleranfällig.
Anders augedrückt: Vergleiche Dein Beispiel mit den Aufwand, 30 verschiedene Anwendungsprogramme manuell in der neusten Version zu installieren, inklusive aller benötigten Bibliotheken, die nicht vom Betriebssystem in der richtigen Version bereitsgestellt wird.
Und dann rechne das Ganze hoch auf einige Hundertausend Nutzer.
Willst Du immer noch behaupten, das Konzept sei unökonomisch?
Dafür nutzt man das Paketmanagement der Distribution oder hier die Ports.
AAAAAAber:
Um ein bestimmtes Programm in einer bestimmten Version zu installieren ist es Goldrichtig.
Beispiele:
1) Ein Webdesigner muss die Wirkung seines Getippes auf unterschiedlichen Versionen eines Browsers testen.
2) Ich habe eine Version des AVR-GCC die ich behalten möchte! Für die neueren Versionen des GCC müßte ich den Code einer umfangreichen Mikrocontrollerregelung verändern, was ich aber nicht will. Der alte Code ist getestet und freigegeben. Wer weiß ob eine neuere Version des GCC nicht doch Code erzeugt der sich in irgendeiner seltenen Situation nicht so wie geplant verhält. Da das Projekt schon älter ist und auch noch einige Jahre laufen wird, muss momentan ein Uraltsystem am leben gehalten werden. An diesem System muss auch keine Bibliothek erneuert werden. Er läuft ja problemlos. Was neues wird nicht darauf installiert, basta (er hat nur die eine Aufgabe)! Der Rechner hat aus Sicherheitsgründen keinen Anschluss ans Netzwerk.
Mit dem Neuen Installationstool könnte man sich diesen Aufwand schenken und überall die benötigte GCC-Version installieren!
Muss dir ungeingenommen zustimmen. Das Konzept ist klasse. Ich habe zum Beispiel auf meiner PCBSD Testmaschine unterschiedliche Versionen eines Programmes (z.B. Firefox) und sie laufen problemlos nebeneinander. Bei der Deinstallazin wird dann das komplette Verzeichnis rückstandsfrei gelöscht, sodaߎnicht die Gefahr besteht, daß irgendwelche "rest libs" übrigbleiben.
Gruss
Marcus
So, so. Und mit welchem Argument stützt Du Deine Behauptung?
Sag' mal: Wenn ich mir jetzt aus die Quellen irgendeine Bibliothek manuell nach /usr/local/ installiere -- sie muß nicht mal doppelt vorhanden sein --, wer patcht sie dann, wenn nicht ich? Und wie wahrscheinlich ist es, daß eine Heim-Anwender die Sicherheitsmeldungen studiert um seine manuell eingespielten Bibliotheken zu patchen?
Du siehst: Bereits jetzt geht es am System der Distri vorbei!
Das Gegenteil ist eher der Fall: Ohne einfache Installation von End-User-Software per Installer wird nie etwas aus Linux auf dem Desktop. Die Frage ist vielmehr, ob man die Distris versuchen, das Unvermeidbare zu beherrschen. Oder, ob das ein Chaos wird, wie zu den Anfängen von Microsoft. Gegenwärtig sieht es ja eher nach letzterem aus.
Bestehen für einen Nur-Anwender nennenswerte Unterschiede zwischen einem Linux-KDE und einem BSD-KDE?
Oder anders gefragt:
Wenn ich in meiner kleinen Firma ein paar Rechner auf BSD und einige unter Linux jeweils mit KDE laufen habe, kann ein DAU mit beiden arbeiten?
Natürlich gleiche Software vorausgesetzt (z.B. OpenOffice).
Oder braucht er eine neue Einweisung?
Gruß
Mark
BTW: PC-BSC ist für mich das absolut DAU-taugliche OS, schnell aufgesetzt, vernünftige Performance (in der Default-Version).
Bei Ooorg solltest du keine Probleme bekommen - du must bei den *.pbi von PC-BSD halt nur die Wörterbücher für die Rechtschreibung und Thesaurus händisch nachinstallieren, was sich bei Suse z.B. erübrigt.
Ich werde es bald mal ausprobieren wenn ich wieder einen Alten PC in die Finger bekomme :-)
Freue mich schon darauf!!
Schöne Grüße
Mark
Ich habe PC-BSD vor kurzem mit dem VMplayer getestet. Durch KDE und Oberflächenanpassungen kann man das Aussehen zwar ähnlich gestalten wie bei Linuxen mit KDE. Ich hatte aber den Eindruck, dass es "unter der Haube" schon einige Unterschiede gibt, z.B. Paketverwaltung/Softwareinstallationen (und -quellen), Steuerung von Serverdiensten und Anpassungen bei Hardware-Einrichtungen.
Letztlich habe ich keinen Vorteil z.B. gegenüber Debian/(K)Ubuntu oder Suse gesehen und spare mir daher die Mühe, mich wieder in ein neues System einzuarbeiten und verschiedene __nix-Systeme zu pflegen. Und wenn, dann würde mich zur Zeit vorallem Solaris reizen.
KDE ist unter Linux und FreeBSD identisch, bis auf den angesprochen Punkt der Unterstützung von HAL.
Und dann auch noch BSD, das Unix von Verlierern für Verlierer. So gesehen macht PC-BSD wieder Sinn.
Ja, mit so dämlichen Kommentaren.
Aber (K)Ubuntu ist noch schlimmer - erträglich wird es auf meinem Rechner erst, wenn ich ein schlankes Linux nehme - SuSE 5.3 z.B.
oder Slackware bzw. ein Slackware- Derivat. In einer Qemu- VM merkt man doch recht deutlich, welche Distries sparsam mit den Ressourcen umgehen....
Ralf
Als die Vers. 1.0 herauskam, hab ich mir die eine ISO gezogen und das System aus Neugier einmal installiert.
War sehr positiv überrascht. Das Ding macht Sinn - nicht überladen, recht flott und zügig in jeder Beziehung.
Die Dokumentation zu den BSD OSen im Netz ist ausserdem erstklassig.
Habe ich bemerkt, als ich z.B. meine TV-Karte mit links zum Laufen brachte.
Der einzige "Schönheitsfehler" welcher mir bis jetzt aufgefallen ist, dass manch Non-OSS Weichware einfach nicht vorhanden ist. Über den Umweg eines Linuxpaketes z.B. das Flashplugin ins System zu bekommen (braucht man leider immer öfter...) ist schon kniffelig.
Aber ansonsten möchte ich den ewigen Meckerern hier schon einmal anraten einmal wirklich über den Tellerand zu schauen und erst nachher zu kommentieren.
Mag sein das PCBSD nur Dau-sicher ist, wenn man es nimmt wie es ist (dann trifft es zu), aber wofür hätten sich die lieben guten Leute sonst die viele Arbeit für die Doku gemacht?!?
Also ein fröhliches RTFM!
an alle
;-)
Openoffice? Auch so ein Ding... In den Ports ist 2.0.3rc3 aktuell, für diesen Port gibts aber nirgends ein fertiges Paket und Openoffice selber bauen ist nun nicht jedem sein Ding (zumal das an die 9GB Platz braucht und vieeel Zeit).
Erstaunlicherweise laufen Realplayer und Acrobat Reader sofort, werden sogar automatisch mit dem Linuxwrapper installiert...
Nicht-OSS ist eigentlich kein Problem unter BSD. Problematisch ist eher das oft die Ports und Packages nicht richtig synchron sind. Dann steht man halt da, weil das eine nicht richtig zum anderen passt.