Für jeden Distribution eigenes Installpaket oder Treiber, warum?

[Biarchiv]

Hallo,

Ich bin noch neu bei Linux.
Nur mir ist etwas extrem Blödess bei Linux aufgefallen was eingentlich
bei Windoof echt super ist.
Der Installer!

Jeden Distributior hat ein eigenes Installer.
Das heißt wenn man ein SUSE hat und ein Programm das leider nur was für
einen anderen Distribution hat hat man wohl als Anfänger bech gehabt.
Oder nicht?

Dann wiederrum habe ich bei MSI Treiber entdeckt:
SUSE Treiber
RedHat Treiber
...

Auch ******e. Es solte ein Linux sein und nicht 100 Linux.
Oder sehe ich da was falsch?

[drunkenPenguin]

Original geschrieben von Biarchiv
Hallo,
[...]
Jeden Distributior hat ein eigenes Installer.
Das heißt wenn man ein SUSE hat und ein Programm das leider nur was für
einen anderen Distribution hat hat man wohl als Anfänger bech gehabt.
Oder nicht?
[...]
Es solte ein Linux sein und nicht 100 Linux.
Oder sehe ich da was falsch?

Es gibt mehrere Paketformate, das ist richtig, ja.
Nein, Du hast kein Pech gehabt, weil es immer noch Quellen gibt und Du Dir selber ein Paket bauen kannst. Als Anfänger hat man Pech gehabt, ja.

Naja, es _ist_ _ein_ Linux, also siehst Du was falsch.
Es gibt zu viele Distributionen, meinst Du? Sehe ich nicht so.

Du solltest von diesem Microsoft-Brain**** "Alles ist eins und wir sind bei Euch" wegkommen.
Ich weiß nicht, wieso manche auf diesen Einheitsbrei scharf sind. Gibt das einem Sicherheit? Oder fühlt man sich dann verstanden? Oder was?

Gruß,
Daniel

edit: Man arbeitet schon darauf hin, einiges zu vereinheitlichen. Aber irgendwo soll ja auch ein wenig Chaos herrschen, oder nicht

[Fußhupe]

In gewisser Weise muss ich Biarchiv Recht geben. Wenn ich mal von meiner SuSE 8.2 umsteigen will, muss ich mir wieder alle Pakete zusammensuchen, da die von SuSE 8.2 dann ja nicht mehr passen. Mit selber compilieren hatte ich leider noch kein Glück.

Gruß
Fußhupe

[JDieskau]

Original geschrieben von Fußhupe
In gewisser Weise muss ich Biarchiv Recht geben. Wenn ich mal von meiner SuSE 8.2 umsteigen will, muss ich mir wieder alle Pakete zusammensuchen, da die von SuSE 8.2 dann ja nicht mehr passen. Mit selber compilieren hatte ich leider noch kein Glück.

Gruß
Fußhupe

Neee, Kompilieren ist immer noch das beste! RPM's, Deb & Co. sind schnell zu installieren, aber nicht die Lösung!
Kompilieren dauert vielleicht etwas länger aber es funktioniert dann wenigsten, kein lästigen 100 pakete instalieren, keine Speicherzugriffsfehler, und nicht Stundenlang suchen wenn man das passende Paket nicht findet, etc.
Kompilieren bringt da echt ne Menge vorteile. Aber apt, yum & co sind schon ein guter Ansatz...

[peschmae]

Original geschrieben von JDieskau
Neee, Kompilieren ist immer noch das beste! RPM's, Deb & Co. sind schnell zu installieren, aber nicht die Lösung!

Naja. Wie managst du denn deine kompilate?

Kompilieren dauert vielleicht etwas länger aber es funktioniert dann wenigsten, kein lästigen 100 pakete instalieren, keine Speicherzugriffsfehler, und nicht Stundenlang suchen wenn man das passende Paket nicht findet, etc.
Kompilieren bringt da echt ne Menge vorteile. Aber apt, yum & co sind schon ein guter Ansatz...

Hä? Das Suchen geht ja erst dann richtig los, wenn du alles selber kompilierst und ne benötigte lib fehlt
Die 100 Pakete sind ja wohl meist auch Libs oder so die eh auch draufmüssten - beim selber kompilieren darfst du das alles manuell machen
Speicherzugrifsfehler hat ja wohl nix mit selber/nicht selber kompilieren zu tun
Stundenlang nach einem Paket gesucht hab ich auch noch nie.

Naja. Ich sehe nicht einmal einen Vorteil. Abgesehen davon dass es reine Zeitverschwendung ist, etwas nochmal zu kompilieren, was schon 100 andere kompiliert haben.

MfG Peschmä

[SeeksTheMoon]

Also:
Es gibt nur ein Linux. Linux ist der Betriebssystem-Kern von kernel.org.
Weil man mit dem Kern alleine aber nichts machen kann, gibts die ganzen Programme drumherum, die sich nach dem Unix-Vorbild System V richten (bei den BSDs ist das nicht System V sondern BSD-Unix und die haben auch einen anderen Kernel).
Wer ein minimales, Unix-konformes Linux haben will, der sollte es sich from Scratch zusammenbauen (LFS). Dort ist kein Schnickschnack wie grafische Installer dabei.
Schließlich ist Unix zu einer Zeit entstanden, wo man nicht wild ruminstalliert hat, sondern wo man als User an einem zuverlässigen System arbeiten musste.
Der Administrator hat das System einmal eingerichtet (bekommen) und war dann nur noch für die Systemüberwachung und Wartung zuständig.

Jetzt gibt es Leute, die speziellere Lösungen brauchen, z.B. skalierbarer Servereinsatz oder den Anwender mit Desktop und Multimedia.
Die Distributionen haben diese Schwerpunkte untereinander aufgeteilt oder bemühen sich sogar, allumfassend zu sein.

Diese Unterschiede spiegeln sich in verschiedenen Programmen oder Programmversionen wieder, ebenso wie in einem speziell vorkonfigurierten Kernel.
Wenn es jetzt Installer für 5 verschiedene Distributionen gibt, dann bedeutet das, dass distributionsspezifische Besonderheiten eingehalten werden oder dass dieses Paket so auf der speziellen Distri getestet wurde und lauffähig ist.
Trotzdem kannst Du ein RedHat-rpm auf Suse installieren und es wird laufen.
Der universelle Weg den es gibt, der besteht aus dem Selberkompileren der Tarbälle, womit wir wieder bei LFS wären.

Auf jeden Fall unterscheiden sich die Distries und das ist sehr gut so, damit jeder seine für ihn ideale Lösung fertig aus dem Kaufregal greifen kann und nicht alles selber stricken und anpassen muss.
Von Windows gab es auch lange Zeit Win9x und NT, heute gibt es Standard, Professional und Enterprise-Versionen von Windows.
Man muss nur wissen was man braucht und kann dann zugreifen.
Dem 08/15 User erschließen sich diese Unterschiede gar nicht, deshalb ist die Wahl der Distrie für solche Leute völlig schnuppe.

Es ist also kein Chaos, es ist sinnvolle Vielfalt, die sich da bietet.

Dieser Installationsunsinn ist eh nur eine der Macken von Windows: Neue Version von Spiel X drauf und alte Version runter, neue Version vom Grafikkartentreiber drauf, Windowspatches drauf, hier mal gespielt und da mal geschraubt.
Unter Windows gibt es auch nicht DEN Installer. Nur weil Installshield anscheinend gute Preise macht, bedeutet das nicht, dass es nur einen Installer gibt:
- Programme haben einen eigenen und wenn der in einer anderen Sprache geschrieben ist als in C++ mit MFC dann sieht er anders aus.
- Programme benutzen Installshield
- Programme werden einfach nur entpackt
- Programme benutzen den Winamp-Installer (den sehe ich immer öfter) oder einen anderen Installer.
- Programme installieren sich übers Netz (MS-Update, Java-Webstart)

DAS ist Chaos für mich! Unter Linux gibts die tarbälle und rpms; fertig. Ich darf mir sogar aussuchen ob ich mir eine GUI zum installieren nehme oder ob ich das auf der Konsole mache und wenn ich die rpm-GUI meiner Distrie nehme, dann ist es sogar einheitlich (es ist immer die gleiche).
Ich werde noch nichtmal mit lästigen Fragen bombardiert; ein Kommando und das Prog ist drauf, ein Kommando und das Prog kann weg sein (und zwar ohne Registry-Leichen)

[PoRcUpInE]

Original geschrieben von SeeksTheMoon
und zwar ohne Registry-Leichen

naja nach nem halben jahr sind das wohl schon eher friedhöfe.

und sei doch froh dass es die auswahl gibt, du kannst damit machen was du willst (vor allem mit den quellen)! und du hast den vorteil dein system anzupassen wie du willst und das bringt dir vor allem was bei den ganzen hintergrundprozessen. (ich will gar nicht wissen was bei windows im hintergrund alles den speicher zumüllt.

[JDieskau]

Original geschrieben von peschmae
Naja. Wie managst du denn deine kompilate?



Hä? Das Suchen geht ja erst dann richtig los, wenn du alles selber kompilierst und ne benötigte lib fehlt
Die 100 Pakete sind ja wohl meist auch Libs oder so die eh auch draufmüssten - beim selber kompilieren darfst du das alles manuell machen
Speicherzugrifsfehler hat ja wohl nix mit selber/nicht selber kompilieren zu tun
Stundenlang nach einem Paket gesucht hab ich auch noch nie.

Naja. Ich sehe nicht einmal einen Vorteil. Abgesehen davon dass es reine Zeitverschwendung ist, etwas nochmal zu kompilieren, was schon 100 andere kompiliert haben.

MfG Peschmä

Das sehe ich nun vollkommen anders!

Wenn ich früher unter SuSe 8.2 versucht habe RPM's für SuSe 8.1 oder älter zu installieren ging dies manchmal, aber sehr oft kahm ein Speichzugriffsfehler, welcher beim selber kompilieren nicht vorhanden war.

Selber kompilieren hat den Vorteil das es sich an dein System perfekt anpasst, Hardware und Software mässig. Nicht umsonst gibt es Packete für i386, i486, i586 und i686, etc, und nicht umsonst gibt es bei Kernel-RPM's welche für Intel, AMD etc!
Binarys installieren muss nun also nicht immer gut sein, ein RPM das auf einen i386'er erstellt wurde, läuft dann auf deinem Rechner (z.Bsp. i686) nicht so super, kaum ein Unterschied zu erkennen, aber er ist da.
Debian größtenteils selber kompiliert läuft auch schneller als ein Suse System! Und das kann du nun auch wieder nicht bestreiten.
Allen im allen ist RPM, und deb schon ein guter Anfang, aber nicht das gelbe vom Ei.

Und ja, ich hab schon nach einem RPM mehrere Stunden gesucht, weil ich es nicht kompilieren konnte, später hab ich das Packet gefunden, lief aber nicht

Edit: Und wenn du nur RPM's nutzt, und nicht die Sourcen, kannst du eigentlich auch wieder zu Windows wechseln, nicht Umsatz benutzen wir hier gerade ein OpenSource BS!

[Stanislaus]

Selam zusammen!

Original geschrieben von peschmae
Naja. Ich sehe nicht einmal einen Vorteil. Abgesehen davon dass es reine Zeitverschwendung ist, etwas nochmal zu kompilieren, was schon 100 andere kompiliert haben.

Da muss ich wiedersprechen.
Das Problem geht doch in dem Moment los, in dem man in die Verlegenheit kommt ein und die selbe lib in unterschiedlichen Versionen installiert haben zu müssen. Beim compilieren kannst Du evtl. statisch linken oder ein lib Päkchen nach sonstwohin installieren und später dann beim configure des entsprechenden Programms eben diesen Pfad angeben.
Mit rpms nicht machbar.
Ebenso würde ich mir niemals ein php (+mysql +firebird +gd +wasweissich) aus ettlichen Einzelpaketen zusammenbauen, wenn es doch per ./configure (respektive Gentoo USE Flags) viel komfortabler geht. Das nur als Beispiel; Betrifft natürlich jede Anwendung, die mit speziellen Optionen gebaut werden soll/muss.

Original geschrieben von JDieskau
Und wenn du nur RPM's nutzt, und nicht die Sourcen, kannst du eigentlich auch wieder zu Windows wechseln, nicht Umsatz benutzen wir hier gerade ein OpenSource BS!

Das ist ja wohl Blödsinn. Nur weil ein Programm im Source vorliegt muss ich es doch auch nicht zwangsläufig selber kompilieren. Ich würde z.B. niemals auf die Idee kommen unter Gentoo etwas anderes als openoffice-bin zu nutzen. Es läuft einwandfrei und vom Selberkompilieren verspreche ich mir an dieser Stelle keinen Vorteil.

Bis neulich ...

[peschmae]

Original geschrieben von SeeksTheMoon

- Programme benutzen Installshield
- Programme werden einfach nur entpackt
- Programme benutzen den Winamp-Installer (den sehe ich immer öfter) oder einen anderen Installer.

Yepp. Das ist ein Chaos. Interessant ist übrigens dass du (und viele andere) zwar den Nullsoft-Installer als solchen identifizieren weil er anders aussieht (dank SuperPimp-Technologie ).
InnoSetup (www.jrsoftware.org) hingegen ist mindestens so verbreitet und genau so gratis. Nur siehts aus wie n Installshield-MSI-Ding - einfach so unauffällig

MfG Peschmä

[peschmae]

@JDieskau: Für Fehler von deinem SuSE/dessen Paketverwaltung/Dir kannst du wohl schlecht sämtliche RPMs (und gleich noch alle anderen vorkompilierten Pakete) dieser Erde verantwortlich machen.
Derartige Probleme sind mir noch nie begegnet - dafür weiss ich nie wenn ich ein Paket aus den Sourcen installier (ausser dem Kernel) wo ichs denn jetzt am besten hinbastle, dass ich das am Ende wieder wegkriege. Dann bastle ich mir halt ein Paket.
Auf den Unterschied einer Kompilierung für i386 gegenüber i686 kann ich verzichten. Der ist eh minim (zwischen -5 und 20% je nach dem ob man den Pro- oder den Anti-Gentoo Studien glaubt )
Einen Vergleich Debian selbstkompilert vs SuSE nicht selbst kompiliert halte ich für doof. Wennschon ein ansonsten genau gleiches Debian für i686 kompiliert vs ein genau gleiches Debian mit den Paketen. Dass Debian (und andere schlanke Distros) schneller sind als SuSE hat wohl noch andere Gründe.

Zu deinem PS: Ist ja echt daneben.
1. Benutze ich freie Software
2. Zwingt freie Software keinen sich sein Zeugs selber zu kompileren - es gibt jedoch die Möglichkeit das zu tun
3. Ist ein meilenweiter Unterschied zwischen einem aus Binärpaketen installierten Debian und einem Windows. Wenn du den nicht siehst kann ich dir auch nicht helfen. (Kleiner Tipp auf den Weg: Debian ist freie Software)
4. ich benutze keine RPMs
5. So

@Stanislaus: So Pakete mit spezialflags bauen hab ich noch nie Bedarf gehabt. Mit sourcen-paketen dürfte das aber kein Problem sein.
Bibliothekenversionsprobleme sind mir eigentlich auch nicht so geläufig. Bei den Major-Versionen gibts dann eh ein neues Paket (vgl. libqt; libqt3; libgtk; libgtk-2.0; etc) - die kann ich auch parallel installieren.
Ausserdem ging es mir mehr darum zu zeigen, dass es normalerweise keinen Sinn macht einfach mal die Sourcen zu nehmen und irgendwohin zu installieren. Dass es Ausnahmen gibt ist mir durchaus bewusst (hab mal nen GCJ-Cross-Compiler für Java mit Mingw32-Target gebaut. Das dauerte jeweils so einen Tag).

Es bleibt aber die grosse Frage, wie man aus Sourcen installierte Programme vernünftig verwalten kann.
Ausserdem fehlen da die Upgrades - da muss man jeweils immer selber auf die Socken.

MfG Peschmä

[Stanislaus]

Original geschrieben von peschmae
@Stanislaus: So Pakete mit spezialflags bauen hab ich noch nie Bedarf gehabt. Mit sourcen-paketen dürfte das aber kein Problem sein.
Bibliothekenversionsprobleme sind mir eigentlich auch nicht so geläufig. Bei den Major-Versionen gibts dann eh ein neues Paket (vgl. libqt; libqt3; libgtk; libgtk-2.0; etc) - die kann ich auch parallel installieren.
Ausserdem ging es mir mehr darum zu zeigen, dass es normalerweise keinen Sinn macht einfach mal die Sourcen zu nehmen und irgendwohin zu installieren. Dass es Ausnahmen gibt ist mir durchaus bewusst (hab mal nen GCJ-Cross-Compiler für Java mit Mingw32-Target gebaut. Das dauerte jeweils so einen Tag).

Gut, daß man nicht laufend in die Verlegenheit kommt ist schon richtig. Gerade der Otto-Normal Anwender wird das Problem wohl eher selten haben.
Ich wollte ja auch nur mal einige Punkte aufzeigen weswegen selber kompilieren doch Sinn machen kann. Das man natürlich nicht direkt drauf loskompiliert, weil Programm XY als rpm gerade rumzickt sehe ich absolut genauso.
Und die source rpms hab ich ganz vergessen. Ist natürlich auch eine Möglichkeit eigene Optionen einzubauen und trotzdem ein rpm zu haben. Wobei dann u.U. die Abhängigkeiten nicht stimmen.

Original geschrieben von peschmae
Es bleibt aber die grosse Frage, wie man aus Sourcen installierte Programme vernünftig verwalten kann.
Ausserdem fehlen da die Upgrades - da muss man jeweils immer selber auf die Socken.

Eine saubere Verwaltung gibt es afaik nicht und besonders grausam wird es dann, wenn Selbstkompiliertes und rpms gemischt vorliegen. Außer man setzt direkt auf eine Source basierte Distri.

Bis neulich ...

[DarkSorcerer]

Ich finde die Arten-Vielflat auch sehr gut. Stell dir vor, du hättest nur ein Paketmanagement, oder noch schlimmer, stell dir vor es gäbe nur eine einzige Distribution? Nicht auszuhalten...

[-hanky-]

Original geschrieben von peschmae
Naja. Wie managst du denn deine kompilate?



Hä? Das Suchen geht ja erst dann richtig los, wenn du alles selber kompilierst und ne benötigte lib fehlt
Die 100 Pakete sind ja wohl meist auch Libs oder so die eh auch draufmüssten - beim selber kompilieren darfst du das alles manuell machen
Speicherzugrifsfehler hat ja wohl nix mit selber/nicht selber kompilieren zu tun
Stundenlang nach einem Paket gesucht hab ich auch noch nie.

Naja. Ich sehe nicht einmal einen Vorteil. Abgesehen davon dass es reine Zeitverschwendung ist, etwas nochmal zu kompilieren, was schon 100 andere kompiliert haben.

MfG Peschmä

Hi,

deine Frage mit den Kompilaten kann ich dir beantworten

Schau doch mal nach "checkinstall", das ist ein sehr gutes, kleines Tool genau zu diesem Zweck.

"./configure && make && checkinstall", danach noch die Art des Pakets ( Slackwarepaket, rpm oder Debian-Paket stehen zur Auswahl ) angeben, fertig.

Nutze ich schon lange und bin sehr zufrieden.

Ich kompiliere mir sehr oft Programme selbst, vorteilhaft z.B. bei neuen Personen und vor Allem da ich dann meine Pakete nicht auf i386 optimiert habe

Kommt natürlich auf den Rechner an, aber mittlerweile habe ich mich schon so daran gewöhnt dass es fast so schnell geht wie ein Slackware-Paket zu installieren.

@ Biarchiv :

Auch ******e. Es solte ein Linux sein und nicht 100 Linux.
Oder sehe ich da was falsch?

Ja, das siehst du falsch. Gerade die Tatsache, dass ich freie Wahl habe, ist ein riesen Vorteil unter Linux. Ich persönlich mag kein rpm und bevorzuge das bei Slackware mitgelieferte Paketsystem, andere schwören auf Debianpakete. Anders als beim Einheitsbrei unter Windows habe ich die freie Wahl.

Wobei z.B. apt-get eine wirklich sehr gute Lösung ist, die man auch problemlos portieren kann ( ich nutze hier slapt-get mit slack-Paketen ). Ich denke dass apt-get bzw. dessen Methode immer mehr Befürworter finden wird, und das zu Recht.

-hanky-

[Biarchiv]

Hallo,

ich sage ja nicht das viele Linux-Entwickler.
Nur solte hat ein jedes Linuxprogramm auf den Linux gehen.
Sonst es es ja bald wie bei Windows. NT/9X. Das währe schade.
Aber anscheinend entwickeln die eh in eine Richtig.

Sicher ist die Vielfalt die bessere.