![]() |
![]() |
|
|
|||||||
| Linux, UNIX, Open Source Rat & Tat bei Problemen und Fragen rund um GNU/Linux, BSD und sonstige UNIXe |
![]() |
|
|
Themen-Optionen | Ansicht |
|
|
#21 | |
|
Inventar
![]() Registriert seit: 23.09.2000
Beiträge: 2.321
|
Zitat:
ad 1.) Da hast du aber viele Möglichkeiten das mit apt-pinning, hold setzen und anderen netten Sachen das zu verhindern. Aptitude kann das z.B. ad 2.) Dein Beispiel ist klar und war damals kein Problem. Es war nur nach kurzer Zeit nicht möglich neuere Versionen als rpm zu installieren, musste sie backporten, was ich als Anfänger nicht wirklich konnte. Und am meisten Ärger machten die Ximian-Pakete mit ihrerer veränderten Namensstruktur. Und du gehst bei deinem Beispiel davon aus daß alle drei benötigten Pakete da sind. Wenn man eins mit einer fehlenen Abhängigkeit installiert bekommt (bzw. bekam ich die bei SuSE 7.0) man eine Fehlermeldung daß XYZ.lib.so fehlt. Ohne rpmfind.net zu kennen war ich da ziemlich aufgehaut! ad 3.) Das ist die Frage, meine Erfahrungen sind konträr zu deinen scheints. Ich habe mit Mandrake da "viel Spass" gehabt..... ad 4.) Das ist eben die Policy, weil wo möchtest du da aufhören? Wenn der Fix für Fehler Y eine neue Abhängigkeit erzeugt ist das System eben nicht mehr "stabil und unverändert bis auf Securityupdates".......wie gesagt, man hat die volle Auswahl, ich mag den Ansatz von Debian, daß man hunderte Workstations einfach und stressfrei betreuen kann. An der Dauer der Releasezyklen wird gearbeitet, ich denke einige Lehren wurden auch aus Woody gezogen. Wer mehr davon mitkriegen will kann gerne die entsprechenden Mailinglisten konsultieren. Ciao, Steve der bei tollem Wetter schon wieder in der Firma sitzt und das sicher noch einige Zeit tut, obwohl er schon bis 3 Uhr in der Früh hier war........
____________________________________
-- www.cargal.org GnuPG-key-ID: 0x051422A0 \"Be the change you want to see in the world\"-Mahatma Gandhi Jabber-ID:lotussteve@cargal.org |
|
|
|
|
|
|
#22 |
|
Master
![]() Registriert seit: 01.11.2001
Beiträge: 531
|
Hi Leute,
der einzige Weg "seine" Distribution zu finden ist sie alle mal auszuprobieren und sich dann in die gewählte Distri einzuarbeiten. Ich glaube das technische Aspekte bei unserer Beurteilung der verschiedenen Distris nicht wirklich ausschlaggebend sind. Wir entscheiden uns meist nicht wirklich nach streng rationalen, technischen Gesichtspunkten für eine Distri sondern eher aus dem Bauch heraus nach dem Image, Herkunftsland und der Ideologie die dahinter steckt. Mir zB. wird RH immer unsympathischer aber nicht weil die Distri schlecht wäre sondern weil ich lieber eine europäische Distri verwenden will... Machen wir mal ein Gedankenspiel: Was wäre wenn Debian eine kommerzielle Distri ohne Möglichkeit zum freien Download der ISOs wäre und SuSE ein Freiwilligenprojekt? Würden wir diese Distris dann genauso beurteilen und ihnen treu bleiben? Gruß santi
____________________________________
Signaturen sind wie Frauen. Man findet selten eine Vernünftige. |
|
|
|
|
|
#23 | |
|
Veteran
![]() Registriert seit: 18.07.2001
Beiträge: 384
|
Zitat:
![]() Würden wir Windows gegenüber Linux bevorzugen, wenn es Open Source wäre und es ISOs zum runterladen gäbe, Linux dagegen ein propietäres System wäre? |
|
|
|
|
|
|
#24 | ||
|
verXENt
![]() |
Zitat:
![]() Zitat:
Webmin ist ein gutes Beispiel. Webmin ist derzeit in Woody als Version 0.94 (Beta) enthalten. Das aktuellere 1.080 würde aber auch unter Woody laufen da es sich bei Webmin nur um eine Ansammlung von Perl Scripts handelt. Stattdessen wurden relativ unmotiviert diverse Fixes von Webmin 1.0xx nach 0.94 backported. Der Maintainer hat stellenweise mehrere Woche für die Backports benötigt. Ich nehme an das der Unterschied zwischen den beiden Version in der Zwischenzeit schon fast zu groß ist. Meiner Meinung nach ist manchmal ein Auffrischen mancher Pakete sinnvoller als Backports diverser Korrekturen. Vorallem wenn es signifikante Verbesserungen mit sich bringt. Es muss ja nicht gleich GNOME 2 sein ![]() |
||
|
|
|
|
|
#25 | ||
|
Inventar
![]() Registriert seit: 22.09.1999
Ort: Wien-West
Beiträge: 3.645
|
Zitat:
Wenn Du jetzt von "CrossOver Office 2.0" oder einem anderen Programm redest - ist das jetzt auf allen Linux-Distributionen installierbar? Oder muss man warten, bis selbiges für meine Distribution adaptiert ist (Beispiel jetzt "CrossOver Office 2.0" oder "Mozilla"): ? Und im Fall Debian kostets nix und im Falle RH dann doch ein bissl was, wenns nicht im Lieferumfang der 1. Schachtel dabei ist...? ----------------------------- Ich überlege gerade, bei der Frage "Linux für Desktop" könnt' ich noch ein wenig zuwarten - beim Debian-Server ist ja noch Feintuning angesagt, dann muss ich noch einen PC neubauen und konfigurieren, dann sollte man das schöne Wetter ausnutzen und sich nicht mit Computern 'rumschlagen - und im September sieht die Sache vielleicht wieder anders aus - dann hat Debian vielleicht wieder ein paar Dinge von unstable auf stable gesetzt bzw. nachgezogen. Auf der anderen Seite sind die 54 Euronen für RH9 auch nicht gerade weltbewegend.... MfG Quintus P.S.: Zitat:
|
||
|
|
|
|
|
#26 | |||
|
verXENt
![]() |
Zitat:
Mehr Informationen gibt es hier: http://www.codeweavers.com/products/office/ Eine 30 Tage Demo als Download hier: http://www.codeweavers.com/products/download_trial.php Zitat:
![]() Falls du ein Debian Desktop OS mit eingebauten CrossOver Office suchst gibt es auch http://www.xandros.com Allerdings ist Xandros schon wieder veraltet da es nur CrossOver Office 1.3 enthält. Irgendwann soll aber Xandros Desktop 2.0 erscheinen Zitat:
![]() Man könnte auch mal http://www.sol-linux.com/ ausprobieren ![]() |
|||
|
|
|
|
|
#27 |
|
Jr. Member
![]() Registriert seit: 19.06.2002
Alter: 58
Beiträge: 59
|
Hallo zusammen!
Ich hab ja nie verstanden, was es für einen Unterschied macht ob ich jetzt Linux vom Maier oder vom Müller beziehe. Schon viel eher ob ich mich für *BSD oder Linux entscheide. Der Inhalt ist doch ohnehin überall der selbe. Und spätestens nach einem Jahr hat man zumeist einen Stand, der von der Erstinstallation weit entfernt ist. Ich hab mir damals SuSE 7.2 gekauft weil ich es nett fand, für den Notfall deutschsprachigen Support zu haben. Des war auch schon der einzige Entscheidungsfaktor. Alles was mir abging oder nicht gefallen hat, hab ich mir dann von den jeweiligen Hompeages nachinstalliert. Zum ewigen Thema der verwendeten Paketmanager: Linux ist nach wie vor ein Compile-System. Wenn ich mir ein tarball runterziehe und "configure; make; make install" mach, muß ich ja auch selber darauf achten was da nun passiert. Also was nützt mir der beste Paketmanager, wenn ich nun mal keine passenden Pakete zur Verfügung habe? Und dann ist es in der Praxis meistens so, daß die Leute bei Problemen mit Paketabhängigkeiten gleich mal die "nodeps" Options anwenden - nach dem Motto - wäre ja gelacht wenn des nicht geht ;-) LG Pav
____________________________________
Of all the things I\'ve ever lost, I miss my mind the most. |
|
|
|
|
|
#28 | |
|
Inventar
![]() Registriert seit: 23.09.2000
Beiträge: 2.321
|
Zitat:
Hehehe, du möchtest dir vielleicht mal "checkinstall" anschauen, das baut dir nach einem ./configure und make mit make checkinstall ein .deb oder .rpm. Habs zwar erst einmal gebraucht, da funzt es aber sehr gut ![]() Ciao, Steve
____________________________________
-- www.cargal.org GnuPG-key-ID: 0x051422A0 \"Be the change you want to see in the world\"-Mahatma Gandhi Jabber-ID:lotussteve@cargal.org |
|
|
|
|
|
|
#29 | |
|
verXENt
![]() |
Zitat:
![]() RPM Build erzeugt (wie der Name es schon sagt) ein RPM aus dem Source. Nebenbei kann man auch einen Menüeintrag definieren und einiges mehr. Wie funktioniert RPM Build? Ein kleines Beispiel anhand von Tux Racer. Tux Racer enthält in RH9 keinen Sound da einer der Patches eine (Patentierte) MPEG Library verwendet. Tatsächlich verwendet es diese Library nur für den Mixer ![]() Also ändern wie das Paket und rekompilieren Tux Racer ohne diesen Code. Zu diesen Zweck brauchen wir das Tux Racer Source RPM: tuxracer-0.61-19.src.rpm (zu finden auf einer der Source CDs) Dieses wird mittels rpm -ivh tuxracer-0.61-19.src.rpm installiert. Jetzt wechselt man in folgendes Verzeichnis: cd /usr/src/redhat/SOURCES und öffnet die Datei tuxracer-0.61-config.patch in einen Editor. Jetzt müssen alle Zeile beginnend ab @@ -3417,7 +3417,7 @@ bis Ende gelöscht werden. Diese Zeilen enthalten die Aufrufe zur MPEG Bibliothek. Als nächstes wird in das SPECS Verzeichnis gewechselt: cd ../SPECS Jetzt wird die Datei tuxracer.spec in einen Editor geöffnet und die Zeile "Release: 19" in "Release: 20" geändert. Die spec Datei ist die Schlüsseldatei. Dort ist enthalten welche Pakete kompiliert werden sollen, Paketbeschreibung, Changelog, Revision, Abhängigkeiten usw. Als letztes wird das ganze mittels rpmbuild -bb tuxracer.spec ausgeführt. In /usr/src/redhat/RPMS/i386/ findet man dann das Endergebnis => tuxracer-0.61-20.i386.rpm Wer dieses Beispiel ausprobiert, hat jetzt viel über RPM gelernt. Zu weiteren Lernzwecken verweise ich auf die 3 Source CD. Diese erlauben interessante Einblicke hinter die Kulissen. Ich selber habe schon OpenRacer auf Redhat 9 portiert . Das ist die Tux Racer Version in der Tux ein Surfbrett verwendet ![]() |
|
|
|
|
|
|
#30 | ||
|
Inventar
![]() Registriert seit: 22.09.1999
Ort: Wien-West
Beiträge: 3.645
|
Zitat:
Zitat:
Thx Quintus |
||
|
|
|
![]() |
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
|
|