hab kein ton mehr

[lunar]

Auch wenn's arg offtopic wird ( ): Hat jemand hier Erfahrungen mit Arch?

Nett, aber pacman ist ... naja, da ist sogar portage besser. Anstatt was eigenes zu nutzen, hätte man zumindest Teile des Paketmanagements von Debian übernehmen können.

Möcht nich so "lol was is'n daran schlimm" wirken... Aber was gefälltn dir daran nicht oO?...

Pacman baut keinen vollständigen Paketbaum über alle Repositories. Angenommen, spam enthält foo-1 und eggs enthält foo-2, dann installiert pacman immer foo-1, wenn man in der Konfiguration das Repo spam vor eggs angibt. Damit sind eigene Repositories verglichen mit den Möglichkeiten von portage ziemlich begrenzt.

Pacman selber verwend ich auch nich mehr, 'n anderes frontend benutz ich... Das kann auch automatisch Pakete aus' AUR kompilieren und installieren. Yaourt nennt's sich...

Ich kenne das. Wenn man mit AUR und den offiziellen Repos auskommt, reicht das auch.

Aber an Pacman ist eigentlich nichts auszusetzen, find ich. Das Paketformat find ich genial einfach

Naja, das Binär-Paketformat ist nur ein Archiv mit den kompilierten Dateien. Genial ist das nun nicht, sondern allenfalls naheliegend. Im Vergleich zu ebuilds sind auch PKGBUILDs nicht wirklich spektakulär, was man im Vergleich zu dh-make wohl durchaus sagen könnte.

es ist schnell genug, man kann damit suchen, automatisiert etwas installieren lassen, hatte noch nie dependency Probleme...

Nun, das gilt auch für dpkg/apt und die modernen RPM-Frontends. Insofern ist das nun wirklich nichts spektakuläres, vor allem rechtfertigt es die Eigenentwicklung nur in begrenztem Maße.

Ich sage ja nicht, dass man dh-make übernehmen muss, aber den Dependency-Resolver und das Repo-Format hätte man durchaus von Debian übernehmen können.

[BlackVivi]

Hab ich gesagt, dass es Pacmanspezifisch ist? Nein. Hab ich gesagt, dass das Paketformat genial ist? Auch nicht. Ich hab gesagt, dass es genial _einfach_ ist. Wesentlich leichter für mich, als jedes andere. Und ich kenne Portage.

Ja, RPM und Deb kann vieles dafür auch. Dafür hat es woanders defizite. Pacman umfasst gute Vorteile... und ist sehr einfach zu bedienen, für mich zumindest. Ich habs schneller verstanden als jedes andere Paketmanagement.

[lunar]

["BlackVivi"]Hab ich gesagt, dass das Paketformat genial ist? Auch nicht. Ich hab gesagt, dass es genial _einfach_ ist.[/quote]
Sorry, da hatte ich was überlesen ...

Ja, RPM und Deb kann vieles dafür auch. Dafür hat es woanders defizite.

Im Vergleich zu Pacman ist nur dh-make ein echter Nachteil. Der Resolver und das Paketformat sind pacman auf jeden Fall weitaus überlegen.

Pacman umfasst gute Vorteile...

Die wären?

Ich sehe nämlich nur Nachteile: Downgrades sind unmöglich, weil es innerhalb eines Repositories nur eine Version eines Paket geben kann. Dadurch muss man instabile Pakete (z.B. Betas, Release Candidates oder gar Live-Builds) in ein separates Repo auslagern, und stößt dann auf Probleme mit dem limitierten Resolver, der nicht über mehrere Repositories hinweg arbeitet (die Beta aus dem eigenen Repo wird nie durch das eigentliche Release ersetzt, selbst wenn das im offiziellen Repo aufschlägt). Es gibt innerhalb nur Pacman nur eine Version jedes Pakets (selbst wenn das Paket in mehreren Repos enthalten ist), gezielt instabile Pakete zum Testen zu installieren ist damit unmöglich.

Und wenn ein Paket mal – aus welchen Gründen auch immer – mal nicht funktioniert, Pech gehabt. Dann muss man das Paket komplett selbst bauen, selbst wenn es das eigentlich in den Repos gäbe.

Das ist schon mal ein KO-Kriterium für kritische Systeme, da man bei einem fehlgeschlagenen Update mehr oder weniger im Regen sitzt und keine Möglichkeit zur Fehlerkorrektur hat.

Es gibt allerdings keine direkte Unterstützung für Quellpakete so wie in Portage, wenn man eigene PKGBUILDs erstellt, muss man diese manuell bauen und ein eigenes lokales Repo dafür erstellen. Damit ist das wesentlich aufwendiger, als portage-Ebuilds zu erzeugen.

und ist sehr einfach zu bedienen, für mich zumindest.

Für den Nutzer ist aptitude auch nicht schwerer als pacman. Und sobald man mit eigenen PKGBUILDs (außerhalb von aur, für die es ja yaourt gibt) arbeitet, ist pacman weitaus aufwendiger als portage.

Im Übrigen gibt es bei Debian auch cdbs, das die Länge der dh-make Dateien erheblich reduziert. Debian-Pakete für den eigenen Zweck zu bauen, ist damit nicht wesentlich schwerer als Pacman-Pakete zu erzeugen.

Komplex wird es nur, wenn man die chroot-Umgebung für Pakete aufsetzen muss, die den Richtlinien entsprechen. Aber das muss man nur als Entwickler ...

Ich glaube aber, dass wir das nicht ausdiskutieren müssen. Meine Meinung hat sich durch Erfahrungen mit Debian, Pacman und portage gebildet, ich habe für jede dieser Paketverwaltungen Pakete gebaut, und halte Pacman daher für den schlechtesten dieser Kandidaten. Daher wirst du mich kaum von den Qualitäten von Pacman überzeugen können. Ich denke, gleiches gilt auch für dich, du scheinst von Pacman ja sehr überzeugt zu sein.

Die Grenzen von Pacman waren übrigens auch mit ein Grund dafür, dass ich Arch auf meinem System wieder durch Gentoo ersetzt habe.

[BlackVivi]

Downgrading find ich nun ... nich so schwer. In'r SVN ist das alte PKGBUILD immer vorhanden und aus'n PKGBUILD'nen Paket zu machen ist'ne Sache von 5 Minuten. Wenn du von irgendwas nicht die neuste Version haben möchtest, weil du stabil bleiben willst... IgnorePKG existiert.

Wenn man in den Stablereps bleibt, also nicht AUR verwendet (was man ja auf eigener Gefahr tut) dann ist es fast unmöglich, dass ein Paket nicht funktioniert. Und workaround gibts in diesem Fall im sehr aktiven Forum immer. (Das Forum ist auch einer der Gründe, warum ich Arch mag. Gibt kaum eine so gute Community für mich)

Du kannst dein Betriebssystem mithilfe der AUR komplett aus den Sourcen erstellen, dafür gibt es auch genügend Tuts im Wiki. Pure PKGBUILDS in Kombination mit der Buildkette dafür ist fast dasselbe wie'n SRC-Paket.

Ich höre auch nicht einfach auf zu diskutieren, nur weil du das sagst Ich diskutier gern. Und ich weiß, dass ich dich nich überzeugen kann. Und du mich bestimmt auch nicht so leicht... aber es ist schön um neue Sachen herauszubekommen. Sowas mach ich halt gern...

Bin bestimmt kein Pacmanfanboy, ich hab nur, wie du, ganz spezielle Erfahunrgen mit den Paketformaten gemacht. Besonders schlechte mit RPM, aber auch schon welche mit Deb.

(Übrigens find ich deinen Diskussionstil, für so eine recht offene und auch von eigene Meinungen gefüllte Diskussion relativ aggresiv. Die Behauptung am Ende wirkte so, als wäre ich unwissen und ein fanboy, obwohl ich dich zuerst nur gefragt habe, was dir nicht gefällt. Find ich irgendwie traurig...)

[Leonidas]

Nett, aber pacman ist ... naja, da ist sogar portage besser.

Also ich fand pacman besser als Portage.

[Py19917062]

ich versteh zwar euer fach-chinesisch nicht, aber würd mal trozdem fragen...kann das sein, dass microsoft bald auf der strecke liegen bleibt?

[numerix]

ich versteh zwar euer fach-chinesisch nicht, aber würd mal trozdem fragen...kann das sein, dass microsoft bald auf der strecke liegen bleibt?

Nein.

[lunar]

Downgrading find ich nun ... nich so schwer. In'r SVN ist das alte PKGBUILD immer vorhanden und aus'n PKGBUILD'nen Paket zu machen ist'ne Sache von 5 Minuten.

Ein manueller Downgrade widerspricht irgendwie dem Zweck einer Paketverwaltung. Die sollte mir solche Aufgaben doch eigentlich abnehmen. Wenn ich dagegen sowas selbst tun muss, wozu habe ich dann eine Paketverwaltung?

Anders gesagt: Eine Paketverwaltung, die von sich aus nur eine einzige Version in einem einzigen Repository verwalten kann, ist irgendwie ziemlich witzlos.

Wenn man in den Stablereps bleibt, also nicht AUR verwendet (was man ja auf eigener Gefahr tut) dann ist es fast unmöglich, dass ein Paket nicht funktioniert.

Ich stelle die Stabilität des Systems ja gar nicht in Frage. Aber ich nutze Arch ja nicht zwecks Stabilität (dann wäre ich bei Debian Stable), sondern um eine solide Basis mit vorkompilierter, einigermaßen aktueller Software bei Bedarf komfortabel mit eigenen Paketen erweitern zu können. Genau das aber ist aufgrund der Beschränkungen von pacman schwieriger als bei Gentoo (bei dem man kaum mehr tun muss, als einen ebuild in das richtige Verzeichnis zu packen). Selbst Debian bietet bessere Wege, selbstgebaute Pakete in das Paketmanagement einzubinden.

Das Problem bei Pacman ist, dass es nicht sinnvoll mit mehreren Repositories umgehen kann, und dieser Punkt lässt sich leider nicht wegdiskutieren. Hätte Arch eine bessere Paketverwaltung, wäre es das ideale System.

Vor allem verstehe ich auch nicht, warum Arch Linux unbedingt Pacman entwickeln musste. Es ist ja nicht so, dass es damals keine guten Programme dafür gab: rpm und dpkg waren zu dieser Zeit schon stabil und ausgereift, und apt gab es auch schon. Auf diesen hätte man doch aufbauen und sie mit einem einfacheren Buildsystem versehen können, aber eine völlige Neuentwicklung im Sinne von NIH halte ich für wenig sinnvoll, besonders wenn das Resultat heute noch nicht mit seinen Konkurrenten mithalten kann.

(Übrigens find ich deinen Diskussionstil, für so eine recht offene und auch von eigene Meinungen gefüllte Diskussion relativ aggresiv. Die Behauptung am Ende wirkte so, als wäre ich unwissen und ein fanboy,

Das war nicht so gemeint, das Missverständnis tut mir leid. Ich hatte eher die Ansicht, dass Pacman deinen Bedürfnissen vollauf entspricht und du daher gute Gründe hast es zu nutzen. Warum also sollten wir diskutieren: Jeder nutzt sinnvollerweise das, womit er am besten zurecht kommt ... daher dreht sich diese Diskussion irgendwann bestimmt auch mal im Kreis, denn was für mich gravierende Mängel sind, ist für dich sinnvolle Reduktion im Sinne der Einfachheit.

[Sr4l]

ich versteh zwar euer fach-chinesisch nicht, aber würd mal trozdem fragen...kann das sein, dass microsoft bald auf der strecke liegen bleibt?

Nein.

Ohhh schade , ist da nichts zu machen?

Aber wie gesagt wenn jmd zu Linux wechseln will ist Ubuntu die beste Wahl, ist so extrem auf die einfach Benutzbarkeit ausgelegt. Es versucht schon das Windows der Linuxe zu sein Was ja nichts schlechtes ist.

Wenn ich mich an "früher" erinnere wo man den XServer konfigurieren musste, das kann man keinem Windows Nutzer erklären, warum für so etwas in die Konsole muss.

Oder warum ich nach einem Dateisystemfehler in die Konsole komme und nicht automatisch die Fehler behoben werden.

[derdon]

Es versucht schon das Windows der Linuxe zu sein.

Nein, das versucht es ganz bestimmt nicht. Windows != Linux, das will es gar nicht sein und das ist auch gut so. Lies dir mal den Link durch, dann weißt du, was ich meine. Sehr gute Lektüre für Umsteiger aus der Windows-Welt.

[C4S3]

Ich finde ja Mandriva und Abkömmlinge noch ein wenig einfacher weil eine Art "Kontrollzentrum" mitgeliefert wird, was bei den *buntus ja fehlt.
Ubuntu gefällt mir aber trotzdem und deswegen habe ich es auch in Verwendung.
Mit freeBSD und Abkömmlingen hätte ich ja geliebäugelt, aber mit den *PBIs konnte ich nix anfangen und Portage (hieß das so?) war mir zuuuu langsam, bzw. für meine Zwecke ungeeignet. ><

[Leonidas]

Mit freeBSD und Abkömmlingen hätte ich ja geliebäugelt, aber mit den *PBIs konnte ich nix anfangen und Portage (hieß das so?) war mir zuuuu langsam, bzw. für meine Zwecke ungeeignet.

Du meinst die FreeBSD-Ports, oder? Portage ist der von FreeBSD inspirierte (und, das gebe ich zu, verbesserte) Paketmanager von Gentoo.

derdon: zu dem Artikel fällt mir hauptsächlich tl;dr ein. Ich habe ein paar Punkte überflogen, allerdings scheint mir das irgendwie unstrukturiert und Linux und Windows mit Autos und Motorrädern zu vergleichen macht den Punkt des Autors nicht klarer.

Und das mit dem CLI stimmt hinten und vorne nicht. GNOME-Software ist oftmals aus der Konsole kaum brauchbar (``gnomeapp --help`` zeigt zwar einiges an, aber ohne X11 ist Nautilus völlig unnütz), bei KDE wird es wohl nicht anders sein.

Die Bemerkung zu vi ist wiederrum völlig fehl am Platze. vi ist in der Hinsicht eine Ausnahme, ebenso wie Emacs, dass es eben sich nicht an übliche Konventionen hält.. naja, weil sie älter als die Konventionen sind. Aber für beide gibt es Pakete, die sie anpassen, namentlich Cream und CUA-Mode.

Der Artikel klingt eher so wie "warum Linux gut so ist wie es ist". Wenn das so wäre, dann sollten sich Linus, die KDE-Leute die so fleißig KDE 4.2 rausgegeben haben, die GNOME-Leute etc. zurücklehnen. Aber ich kann dir sagen, als Programmierer auf Linux, als Administrator von Linux-Kisten und auch als User: es hapert an einigem. Daher ist es gut, dass Leute fordern dass die Software einfacher zu nutzen wird und mehr Leute auf Linux migrieren.

Mehr Linux-Use bedeutet auch eine heterogenere Computerlandschaft. Wir sehen ja wie eine Windows-Monokultur ausschaut, daher bin ich froh wenn viele Leute zu Linux oder meinetwegen Mac OS X wechseln. Das bedeutet für Hardwarehersteller, dass sie versuchen müssen, den Nutzern brauchbare Angebote zu liefern. Hardware die auf einem System nicht läuft, wird von den jeweiligen Nutzern nicht gekauft (oder zumindest nicht zweimal, siehe: Fehlkauf) und wenn die Nutzer ein drittel des Marktes darstellen wird ein Hersteller stark überlegen was er da macht. Gleiches gilt für Software. Gerade Bildungssoftware gibt es eigentlich nur für Windows, da es in Schulen/Zuhause nur Windows-Kisten gibt, weil es Bildungssoftware nur für Windows gibt.

Natürlich verstehe ich dass man einige wichtige Prinzipien im Linux-Lager nicht hergeben will, wie eben dass die meiste Software frei ist, aber Leute abzuschrecken ist der falsche Weg. Die Idee ist, Leute aufzuklären und nicht ihnen zu sagen "wenn ihr blöd bleiben wollt, dann nutzt etwas anderes als Linux". Windows hat eine immense Zahl an Freeware-Autoren und wenn man diese überzeugt auf ein freies System zu wechseln und ihre Freeware in Zukunft als freie Software bereitzustellen (was kein Problem sein sollte, denn Freeware ist idR. aus keinen bestimmten Gründen propietär) dann ist das ein großer Vorteil für Linux und eigentlich auch alle anderen Platformen.

[Hyperion]

Danke für die vielen Detailbetrachtungen zu pacman und deb! Im Moment habe ich leider eh keine mal Arch auszuprobieren, aber ich werde das mir mal sicherlich angucken!

Um das Thema noch mal in eine andere Richtung zu lenken (wobei die "pythonischer" ist): Hat jemand sich mal Foresight Linux und vor allem deren Paketmanagement conary angeguckt? Ist ja anscheinend ein auf Python aufsetzendes Paketsystem und von daher per se sehr interessant zu diskutieren hier im Board. Wäre toll, wenn da auch jemand erfahrenes etwas zu zu sagen wüßte

[BlackVivi]

Um das Thema noch mal in eine andere Richtung zu lenken (wobei die "pythonischer" ist): Hat jemand sich mal Foresight Linux und vor allem deren Paketmanagement conary angeguckt? Ist ja anscheinend ein auf Python aufsetzendes Paketsystem und von daher per se sehr interessant zu diskutieren hier im Board. Wäre toll, wenn da auch jemand erfahrenes etwas zu zu sagen wüßte

Portage ist auch in Python geschrieben...

[cofi]

Portage ist auch in Python geschrieben...

Nicht ganz. Das hat auch ne gute Portion BASH intus

[lunar]

Um das Thema noch mal in eine andere Richtung zu lenken (wobei die "pythonischer" ist): Hat jemand sich mal Foresight Linux und vor allem deren Paketmanagement conary angeguckt? Ist ja anscheinend ein auf Python aufsetzendes Paketsystem und von daher per se sehr interessant zu diskutieren hier im Board. Wäre toll, wenn da auch jemand erfahrenes etwas zu zu sagen wüßte

Portage ist auch in Python geschrieben...

Ebenso wie yum, das imho beste RPM-Frontend.