* "GUI? Brauchen wir nicht! Kommandozeile ist eh' viel schneller, nicht wahr?" * "Featutes? Brauchen wir nicht. Wir sind dazu da, den Nutzern die "Freiheit" zu geben!"
Den Vertretern "freier" Software bleibt auch nicht anderes übrig, würde doch sonst jedem auffallen, wo das große Loch in ihrem Gefasel ist, nicht wahr?
Mal zum angeblich nicht existierenden Problem: Was ist denn mit dem durchschnittlichen Freiberufler, der seine UST-Voranmeldungen monatlich abliefern muß? Zum Glück gibt's da ja auch was für Linux namens Taxbird. Nur leider: Für 2008 braucht man die neuste Version, denn die alte hat das Jahr 2007 wohl fest einprogrammiert.
Was muß man also machen, wenn man die letzte Ubuntu LTS Version verwendet? Genau. Seine Zeit mit Kompilieren verschwenden.
Das ist doch wohl ein lächerliches Argument! Ein System wird doch nicht dadurch gut oder schlecht weil ein Compiler enthalten ist oder nicht. Ich kann mir genauso gut auch ein Linux bauen, wo kein Compiler dabei ist. Ob er benötigt wird oder nicht hängt schlicht vom Einsatzzweck ab. Auch wäre es für MS ein leichtes, ihrem Windows einen Compiler mitzugeben.
Und ohne Dich angreifen zu wollen: Ein System wird dadurch gut, daß es den jeweiligen Einsatzzweck am Besten erfüllt. Womit ich wieder die Brücke zurück zum Eingang des Threads schlage. Für den Einsatzzweck "Desktop-OS" gehört für mich u.a. eine vernünftige Installer Lösung (siehe oben). Da bin ich im Linuxlager bisher leider nicht so recht fündig geworden, was sehr schade ist, denn Linuxdistributionen wie Kubuntu stellen ein an sich in vielen Belangen hervorragendes "Desktop-OS" dar. Erstaunlich nur, daß die von mir eingangs angerissenen Probleme zwar von der verältnismäßig kleinen PC-BSD Truppe (Danke noch mal für den Link) angegangen werden, nicht aber von einer riesigen Linux Community.
P.S.: Wie ich gerade gelesen habe kommt schon mit der nächsten Version ZFS als Dateisystem dazu. Auch ein Grund sich das PC-BSD mal genauer anzusehen.
Gruß linuxpling
P.S.: Bitte keinen Flamewar mehr!!! Führt eh zu nichts.
Ok, speziell für Dich: das letzte Zeichen meines Post sollte ein werden...
> ...Probleme zwar von der verältnismäßig kleinen PC-BSD Truppe (Danke noch mal für den Link) angegangen werden, nicht aber von einer riesigen Linux Community.
Kann vielleicht daran liegen, dass bei einem System, welches nur eine CPU-Architektur unterstüzt die Verteilung von Binaries sich etwas einfacher gestaltet, also bei einem System, welches zwölf solche bedient...
na dann ;-) Aber wo liegt der Vorteil der bisherigen Systeme bei zwölf oder mehr Architekturen? Das Paket muß am Ende doch für jede Architektur kompiliert und bereitgestellt werden. Es wird sogar noch schlimmer. Es muß sogar noch für jede Distribution bereitgestellt werden. Noch schlimmer es muß auch noch für jede Version bereitgestellt werden. Und das Schlimmste: das multipliziert sich alles. Daraus würde ein schlicht nicht zu leistender Arbeitsaufwand resultieren, den kaum einer auf sich nehmen wird. Die Folge ist, daß erst einmal viele Architekturen "unter den Tisch fallen". Das alleine reicht aber noch nicht. Um den Aufwand weiter zu reduzieren werden nur wenige Distributionen unterstützt, der Rest bleibt bei den Maintainern der jeweiligen Distribution hängen. Bei den kleinen Distributionen sind das meist Leute, die sich in ihrer Freizeit mit der Distribution beschäftigen. Von diesen sind dann die Nutzer der Distribution abhängig oder sie müssen selbst (teilweise sehr tief ins Sstem eingreifen) und selbst Compilieren. Dabei wird der Nutzer leider feststellen, daß viele Abhängigkeiten bestehen. Also muß er das Netz nach den passenden Libaries durchwühlen. Hat er diese endlich gefunden stellt er beim Compilieren dieser fest, daß die Bibliothek selbst wieder ungelößte Abhängigkeiten besitzt. Entnervt geht der Nutzer erneut auf die Suche. Er kompiliert die Abhängigkeit der Abhängigkeit völlig genervt paßt er kurz nicht auf...schade eine alte Version der Bibliothek wurde gerade überschrieben, jetzt geht das halbe System nicht mehr...
Wenn doch nur die Nutzer der kleinen exotischen Distributionen betroffen wären! Leider trifft es alle. Hat ein Nutzer eine alte Version seiner Distribution drauf oder eine für das benötigte Programm zu neue geht es mit guter wahrscheinlichkeit wieder an Compilieren.
In so fern verstehe ich Dein Argument nicht so ganz. Gäbe es für Linux ein System wie PBI für PC-BSD müßte der Programmierer nur (sofern er denn alle Linux-Hardware-Architekturen unterstützen will) 12 oder weniger Pakete für alle! Distributionen und Distributionsversionen bereitstellen.
Und die Distributionsleute hätten obendrein den Rücken frei für Ihr eigentliches "Kern"-System. Sicherlich ein weiterer Vorteil. Zudem können die PBI Pakete sich selbstständig updaten, so daß der Nutzer sich nicht einmal darum kümmern muß. Sicherlich ein weiterer Vorteil.
PBI hat auch seine Grenzen. Du wirst sehr wahrscheinlich zukünftige PBIs, die sich auf die FreeBSD 7-Serie beziehen, nicht auf PCBSD-Versionen installieren können, die auf FreeBSD 6 beruhen. Diese Kompatibilität hat ihre Grenzen.
Bei Linux ist das übrigens ähnlich. So kannst Du theoretisch Pakete einer neueren Distribution auf einer älteren installieren, wenn sich gcc und glibc nicht oder nur rein "kosmetisch' unterscheiden (das gilt aber nicht in jedem Fall). Bsp.: Suse 7.3-Pakete liefen hervorragend unter Suse 7.1 (gcc-2.95-3 und glibc-2.2.x) Allerdings ist das von den Distributoren nicht gewollt, wohl aus ökonomischen Gründen. Sehr oft steht dem Nutzer auch ganz einfach der Paketmanager im Weg, der das "nicht weiß". Insofern hast Du recht.
Zu FreeBSD: FreeBSD hat ja ein kleines Kernsystem, darum herum befindet sich das Userland. Ich glaube es ist so, daß die FreeBSD-Paketierer tatsächlich darauf achten, daß innerhalb eines BSD-Zweiges die Kompatibilität mit den Kernsystemen gewahrt bleibt. Das hieße also, daß Du mit dem Kernsystem eines FreeBSD 6.0 das Userland eines FreeBSD 6.3 bzw. eines gepflegten und stets aktualisierten FreeBSD6-Zweiges nutzen könntest. Ich habe allerdings erst mit FreeBSD angefangen, ich muß das also erst noch austesten.
> Gäbe es für Linux ein System wie PBI für PC-BSD müßte der Programmierer nur (sofern er denn alle Linux-Hardware-Architekturen unterstützen will) 12 oder weniger Pakete für alle! Distributionen und Distributionsversionen bereitstellen.
Und nun hast Du den Grund erkannt, warum die meiste Software als Source-tgz augeliefert wird. Mindesten eine der 12 schlägt mit 10.000 EUR zu Buche... Ja, es gibt verfügbare Buildsysteme, doch warum soll sich der Entwickler auch noch um das Deployment kümmern, wenn ein ./configure && make es auf der Clientseite auch tut? Ich würde es nicht machen wollen...
Typische Reaktion: Problem wird heruntergeredet:
* "GUI? Brauchen wir nicht! Kommandozeile ist eh' viel schneller, nicht wahr?"
* "Featutes? Brauchen wir nicht. Wir sind dazu da, den Nutzern die "Freiheit" zu geben!"
Den Vertretern "freier" Software bleibt auch nicht anderes übrig, würde doch sonst jedem auffallen, wo das große Loch in ihrem Gefasel ist, nicht wahr?
Mal zum angeblich nicht existierenden Problem: Was ist denn mit dem durchschnittlichen Freiberufler, der seine UST-Voranmeldungen monatlich abliefern muß? Zum Glück gibt's da ja auch was für Linux namens Taxbird. Nur leider: Für 2008 braucht man die neuste Version, denn die alte hat das Jahr 2007 wohl fest einprogrammiert.
Was muß man also machen, wenn man die letzte Ubuntu LTS Version verwendet? Genau. Seine Zeit mit Kompilieren verschwenden.
Stell Dir vor, er hätte Windows auf dem System! Da ist ja nicht mal ein Compiler enthalten.
Und ohne Dich angreifen zu wollen: Ein System wird dadurch gut, daß es den jeweiligen Einsatzzweck am Besten erfüllt. Womit ich wieder die Brücke zurück zum Eingang des Threads schlage. Für den Einsatzzweck "Desktop-OS" gehört für mich u.a. eine vernünftige Installer Lösung (siehe oben).
Da bin ich im Linuxlager bisher leider nicht so recht fündig geworden, was sehr schade ist, denn Linuxdistributionen wie Kubuntu stellen ein an sich in vielen Belangen hervorragendes "Desktop-OS" dar.
Erstaunlich nur, daß die von mir eingangs angerissenen Probleme zwar von der verältnismäßig kleinen PC-BSD Truppe (Danke noch mal für den Link) angegangen werden, nicht aber von einer riesigen Linux Community.
P.S.: Wie ich gerade gelesen habe kommt schon mit der nächsten Version ZFS als Dateisystem dazu. Auch ein Grund sich das PC-BSD mal genauer anzusehen.
Gruß
linuxpling
P.S.: Bitte keinen Flamewar mehr!!! Führt eh zu nichts.
> ...Probleme zwar von der verältnismäßig kleinen PC-BSD Truppe (Danke noch mal für den Link) angegangen werden, nicht aber von einer riesigen Linux Community.
Kann vielleicht daran liegen, dass bei einem System, welches nur eine CPU-Architektur unterstüzt die Verteilung von Binaries sich etwas einfacher gestaltet, also bei einem System, welches zwölf solche bedient...
Aber wo liegt der Vorteil der bisherigen Systeme bei zwölf oder mehr Architekturen? Das Paket muß am Ende doch für jede Architektur kompiliert und bereitgestellt werden. Es wird sogar noch schlimmer. Es muß sogar noch für jede Distribution bereitgestellt werden. Noch schlimmer es muß auch noch für jede Version bereitgestellt werden. Und das Schlimmste: das multipliziert sich alles. Daraus würde ein schlicht nicht zu leistender Arbeitsaufwand resultieren, den kaum einer auf sich nehmen wird. Die Folge ist, daß erst einmal viele Architekturen "unter den Tisch fallen". Das alleine reicht aber noch nicht. Um den Aufwand weiter zu reduzieren werden nur wenige Distributionen unterstützt, der Rest bleibt bei den Maintainern der jeweiligen Distribution hängen. Bei den kleinen Distributionen sind das meist Leute, die sich in ihrer Freizeit mit der Distribution beschäftigen. Von diesen sind dann die Nutzer der Distribution abhängig oder sie müssen selbst (teilweise sehr tief ins Sstem eingreifen) und selbst Compilieren. Dabei wird der Nutzer leider feststellen, daß viele Abhängigkeiten bestehen. Also muß er das Netz nach den passenden Libaries durchwühlen. Hat er diese endlich gefunden stellt er beim Compilieren dieser fest, daß die Bibliothek selbst wieder ungelößte Abhängigkeiten besitzt. Entnervt geht der Nutzer erneut auf die Suche. Er kompiliert die Abhängigkeit der Abhängigkeit völlig genervt paßt er kurz nicht auf...schade eine alte Version der Bibliothek wurde gerade überschrieben, jetzt geht das halbe System nicht mehr...
Wenn doch nur die Nutzer der kleinen exotischen Distributionen betroffen wären! Leider trifft es alle. Hat ein Nutzer eine alte Version seiner Distribution drauf oder eine für das benötigte Programm zu neue geht es mit guter wahrscheinlichkeit wieder an Compilieren.
In so fern verstehe ich Dein Argument nicht so ganz. Gäbe es für Linux ein System wie PBI für PC-BSD müßte der Programmierer nur (sofern er denn alle Linux-Hardware-Architekturen unterstützen will) 12 oder weniger Pakete für alle! Distributionen und Distributionsversionen bereitstellen.
Und die Distributionsleute hätten obendrein den Rücken frei für Ihr eigentliches "Kern"-System.
Sicherlich ein weiterer Vorteil.
Zudem können die PBI Pakete sich selbstständig updaten, so daß der Nutzer sich nicht einmal darum kümmern muß.
Sicherlich ein weiterer Vorteil.
Schöne Grüße
linuxpling
Du wirst sehr wahrscheinlich zukünftige PBIs, die sich auf die FreeBSD 7-Serie beziehen, nicht auf PCBSD-Versionen installieren können, die auf FreeBSD 6 beruhen.
Diese Kompatibilität hat ihre Grenzen.
Bei Linux ist das übrigens ähnlich. So kannst Du theoretisch Pakete einer neueren Distribution auf einer älteren installieren, wenn sich gcc und glibc nicht oder nur rein "kosmetisch' unterscheiden (das gilt aber nicht in jedem Fall).
Bsp.: Suse 7.3-Pakete liefen hervorragend unter Suse 7.1 (gcc-2.95-3 und glibc-2.2.x)
Allerdings ist das von den Distributoren nicht gewollt, wohl aus ökonomischen Gründen.
Sehr oft steht dem Nutzer auch ganz einfach der Paketmanager im Weg, der das "nicht weiß".
Insofern hast Du recht.
Zu FreeBSD:
FreeBSD hat ja ein kleines Kernsystem, darum herum befindet sich das Userland. Ich glaube es ist so, daß die FreeBSD-Paketierer tatsächlich darauf achten, daß innerhalb eines BSD-Zweiges die Kompatibilität mit den Kernsystemen gewahrt bleibt. Das hieße also, daß Du mit dem Kernsystem eines FreeBSD 6.0 das Userland eines FreeBSD 6.3 bzw. eines gepflegten und stets aktualisierten FreeBSD6-Zweiges nutzen könntest.
Ich habe allerdings erst mit FreeBSD angefangen, ich muß das also erst noch austesten.
Und nun hast Du den Grund erkannt, warum die meiste Software als Source-tgz augeliefert wird. Mindesten eine der 12 schlägt mit 10.000 EUR zu Buche... Ja, es gibt verfügbare Buildsysteme, doch warum soll sich der Entwickler auch noch um das Deployment kümmern, wenn ein ./configure && make es auf der Clientseite auch tut? Ich würde es nicht machen wollen...