Nee, von getestet kann ich (noch) nicht sprechen...
Kanotix (Live-CD): ok, alles lief ootb. Aber irgendwie gegenüber aptosid... nee, eher nicht, rein gefühlsmäßig.
Paldo (Live-CD): Bleibt im grub hängen. Fairerweise muß ich dazusagen daß ich mir den ausdrücklich als unstable markierten daily build gezogen hatte. Wenn ich mal wieder Zeit habe werd ich es mal mit einer "stable" probieren.
Chakra (Live-CD): Machte einen interresanten Eindruck nachdem nach Verwenden eines alternativen Eintrags im Grub-Menü das vorher hängende udev doch noch seine Dienste tat. Leider hab ich meinen Wlan-Stick nicht zum Laufen übereden können, so daß ich es -Ceni-verwöhnt und von agaidas Hinweis auf möglicherweise bevorstehende Probleme mit dem Paketmanagment und einigem mehr abgeschreckt- auch erst mal zurückgestellt habe, mit dem Vorsatz mir erst mal arch anzuschauen.
Arch (Netinstall-CD): Erste Feststellung kurz nach Starten der CD: Nach mehr als zwei Jahren ausschließlich sidux/aptosid bin ich von der Bediener-Freundlichkeit verwöhnt und habe mehr an Grundlagenwissen verloren als ich eigentlich dachte daß ich je hatte. :evil:
Das bereits von der Chakra-CD bekannte Problem mit meinem AR9001-u -Wlan-Stick bremste meinen Enthusiasmus dann auch abrupt von 180 auf deutlich unter Schrittgeschwindigkeit.
Agaidas Rat "Tu dir zwei Gefallen -nimm ein Kabel und lies zuerst den Installations Guide" lies sich leider nur im zweiten Punkt befolgen. Mein Router steht -bei ordentlicher Verlegung- ca 15m von meiner Kiste entfernt und mein längstes Kabel hat gerade mal 10. Ok, Router an die Wohnzimmerlampe hängen und Kabel durch die Wohnung spannen hatte ich auch schonmal... nur nicht Sonntagsnachmittags in Anwesenheit meiner wirklich lieben Frau... die sowieso schon komisch guggt weil ich mal wieder stundenlang an der Kiste sitze... nee... trau ich mich nicht... :cry:
Aber: Ein ath0 taucht ja in der Auswahl der Netzwerkverbindung auf also kann es doch nicht so schwer sein... hab ich doch vor sidux auch x-mal gemacht -nur wie ging das nochmal?
Wo ist die wpa_supplicant.conf wieder? ok unter /etc -> passphrase und Netzwerkname rein -> wie ging das dann?
wpa_supplicant -d -B -Dwext ...
"driver doesn't support wpa"
huh?? Wie schauts mit der firmware? Keine vorhanden? Probier ich die von meiner aptosid Installation... cp ... modprobe ... ifup ath0
"unbekannter Befehl" ?? ok ifconfig ath0 up
iwconfig mode Managed essid .....
"Driver doesn't support SET" aber die ESSID erscheint jetzt bei "iwconfig ath0" wenn auch "not connectet" ??
Nochmal den wpa_supplicant... "driver doesn't support wpa"
Das wars also nicht...
hmm... keine /etc/network/interfaces?? Wo wird das denn hier zu finden sein...
Verbissene gefühlte Stunden später, immer noch "interfaces" oder was vergleichbares am Suchen, Zeit zum Schlafen, muß ja schließlich morgen arbeiten.
Frauchen auch und da ich Schicht arbeite... Router an die Lampe und Kabel spannen... :roll:
Vorläufiges Fazit: Die bei mir in den letzten Monaten entstandene Unzufriedenheit mit aptosid hat sich deutlich relativiert. Was Hardware-Unterstützung und Bedienerfreundlichkeit betrifft ist aptosid für mich nach wie vor TOP. Aber es macht auch Spaß mal wieder tiefer in das Ganze einzutauchen und sich mal wieder mit dem Rest der weiten, bunten Linuxwelt auseinander zu setzen.
Gruß
ayla
so, ich darf das ja jetzt:
aptosid ist technisch brilliant, sozial völlig unterbelichtet.
ich denke, das bringt es auf den punkt.
greetz
devil
Quote from: "devil"so, ich darf das ja jetzt:
aptosid ist technisch brilliant, sozial völlig unterbelichtet.
ich denke, das bringt es auf den punkt.
greetz
devil
Besser kann man es wohl nicht ausdrücken :lol:
@ayla: Hier weiter mit Netzwerk
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&p=7045#7045
ahh... Der Link zum wireless-setup wiki und dessen Part carl9170 dürfte es wohl sein. Da probier ich doch morgen gleich mal weiter, jetzt muß ich leider zur Arbeit.
Falls ich noch Probleme haben sollte melde ich mich dort nochmal.
Danke Dir
ayla
Hallo @ayla,
bei Deinen bisherigen Testobjekten musst Du aber fairerweise sagen, dass es doch eher Nischendistributionen sind, die diverse Spezialitäten der Konfiguration haben und die zwar alle ihre deutlichen Stärken haben mögen, aber um den Preis, dass man extrem viel Zeit aufwenden muss, um sich in sie herein zu arbeiten.
Und nun nimm mal hingegen ein aktuelles Mandriva, Kubuntu oder openSUSE. Die haben zwar alle ihre Eigenheiten, und da läuft auch nicht alles optimal. Aber dass man durch benutzerfreundliche Werkzeuge wie Yast oder DrakeConf davon abgehalten wird, dort bestimmte Sachen nach eigenen Vorstellungen händisch einzustellen, halte ich häufig für einen Mythos, um seine eigene Distribution, bei der man ja so viel mehr kann und lernt, aufzuwerten.
Und wenn es mal richtig knirscht im Gebälk bei Schwierigkeiten, die nicht distributionsbedingt sind, sondern an der aktuellen Situation von Anwendungssoftware und Treibern liegen, kochen alle aktuellen Distributionen mit Wasser und eine Frickelei kann dann richtig ätzend werden, sei es unter openSUSE, aptosid, Kubuntu oder Mandriva.
Viele Grüße,
Holger
Was ich so toll finde an Gentoo:
Hier kann man in einem vorgegebenen Rahmen ungefährdet rumfrickeln, und zwar beim Backen des Paketes durch die USE Flags:
Wenn ich akonadi/nepomuk einschränken will, mache ich:
USE=" -semantic-desktop "
Dann merke ich aber schnell, dass es so nicht mehr compilieren will: Das USE flag muss zumindest für einige libs wieder rein.
Wie man sieht:
Die ganze Frickelei passiert lange vor dem Installieren der Pakete, noch vor dem kompilieren! Wenn man also im eng begrenzten Rahmen der USE Flags bleibt, macht man sich sein System nicht kaputt durch Frickeln nach dem Installieren der Pakete. Die Kongruenz des Systems wird im Rahmen von USE Flags vorher abgecheckt.
Dieses USE Flag System ist allerdings manchmal bei Gentoo~ unstable noch unfertig, ein USE Flag wird durch eine neue Programm Version in unstable unmöglich, oder es ist noch nicht implementiert. Dann muss man einen Bug Report schreiben ...
Was die meisten Anfänger bei Gentoo verkehrt machen, und das ist ganz ähnlich wie bei Debian:
Sie meinen es sich mit Gentoo stable leichter zu machen, haben aber das Bedürfnis brandneue Versionen von Desktop Programmen auszuprobieren. Dann wird das System sehr schnell inkongruent und wirklich instabil. Es ist genauso, als ob man zu Debian stable xfce-4.8 aus experimental dazu holt.
Leichter ist es, gleich Gentoo~ unstable zu nehmen, aber einige Toolchain Pakete auf stabil zu setzen (udev,gcc,linux-headers,glibc), wie Funtoo~ unstable es vormacht.
Ich glaube, dass ein Anfänger es mit striktem Gentoo stable leichter hat, als mit Arch, weil das Gentoo Paketsystem ausgefuchster ist, als das mit Absicht auf slackware-1992 reduzierte Arch Paketsystem. Aber das ist mein Vorurteil über Arch ...
@holgerw: Natürlich hast Du irgendwo recht, nur der bisherige Zustand der meisten GUIs ist eher beschämend. Die wären zwar bedienfreundlich, benutzerfreundlich ist was anderes. Unter Benutzerfreundlich verstehe ich gute, durchdachte und vor allem durchschaubare Konzepte, die dann auch gnadenlos durchgezogen werden. Solange die GUIs für Linux teilweise nicht mal elementare Teilmengen der verfügbaren Möglichkeiten abbilden, sind sie für mich mehr oder weniger nutzlos.
Die Konzpte müssen nicht mal sonderlich leicht sein, es reicht eigentlich erschöpfend und konsistent dokumentiert, vor allem aber mit Beispielen in der Dokumentation. Nur wenige von uns können allein aus einer metasprachlichen Beschreibung eines Befehls mühelos den korrekten Einsatz ableiten. Was mich auch annervt ist die Überfrachtung von Befehlen, die ganz klar im Gegensatz zu uralten Grundsätzen steht.
Wenn man schon über den Tellerrand schaut, ich habe nie wieder ein so überschaubares und leicht zu lernendes Betriebssystem wie OS/400 gesehen. Da war fast alles erfüllt, was zum Traum eines Administrators gehört. Dummerweise ist eine AS/400 mit allen Diensten, die eventuell darauf laufen, nicht an einem Tag zu erlernen. Vor allem, wenn man eine bestehende Maschine übernimmt, auf der Software läuft, die einfach teilweise nur grauenhaft und fehlerhaft ist. Das Steuerungskonzept der Bedienung von OS/400 mit dem selben Befehlssatz für reine Textsteuerung und automatischem Fallback in ein Menüsystem war einfach nur Klasse. Kannst Du eins, kannst Du alles, Du musst nur noch den richtigen Befehl finden.
@agaida, Deine Beschreibung von OS/400 hört sich fast so an, wie das, was Yast mit seinem Modulen versucht: eine Möglichkeit mit einfachen Modulen GUI mäßig, wie auf Cli-gui mäßig konfigurieren zu können.
Da Yast openSource ist, könnten wir mit dem Tool sicherlich sowas wie ein "simple Debian sid" bauen. Aber es gibt noch andere Tools.
Ich hatte auch schon überlegt, ob man mit einer Art Linux-Registry die Linux Administration nicht vereinheitlichen könnte. Gconf kam mir da in den Sinn, ist zwar nur eine Registry für Gnome-Gui-Apps, aber das könnte man ausbauen. Dann habe ich mitbekommen, dass Gnome3 sich von gconf losgesagt hat und gsettings als neue Sau durchs Dorf treibt. Bei Linux ist die Entwicklung oft so schnell, dass schon dadurch nicht die Zeit für Vereinheitlichungen bleibt, leider ....
Hallo Alf,
QuoteSolange die GUIs für Linux teilweise nicht mal elementare Teilmengen der verfügbaren Möglichkeiten abbilden, sind sie für mich mehr oder weniger nutzlos.
Aber bitte bedenke, dass für einen Großteil der Linux Nutzer, die rasch eine Desktop Distribution aufsetzen möchten, das hinreichend ist, was ein GUI wie Yast anbietet. Ich behaupte sogar, dass selbst die Optionen in Yast kaum zur Hälfte von den Meisten ausgereizt wird. Und wenn Du dann als Experte mehr brauchst und machen möchtest, hindert Dich auch ein openSUSE nicht daran, Dich mit vi oder emacs in Konfig Dateien auszutoben, und SuSEConfig überschreibt schon lange keine geänderten Dateien mehr und lässt sich sogar deaktivieren :-)
QuoteDa Yast openSource ist, könnten wir mit dem Tool sicherlich sowas wie ein "simple Debian sid" bauen.
Kannst Du so etwas? Die Frage ist ernst gemeint, ich fände so etwas gar nicht schlecht.
Viele Grüße,
Holger
Das ist eigentlich nur eine Oberfläche, die durchgängig implementiert ist. Und zwar ohne auswüchse wie aptitude.
Du tippst einen Befehl ein, löst aus und es erscheint eine Maske, die Du menügesteuert ausfüllen kannst. Du tippst einen Befehl teilqualifiziert ein und füllst den Rest im Menü aus.
Du qualifizierst die Eingabe voll und löst aus und der macht, was Du willst. Besonders schön ist es, dass die Oberfläche mit Deinem Wissen wächst und auch bei voll qualifizierter Eingabe durch Funktionstasten ins jeweilige Menü, die Kontext-Hilfe und spezielle Funktionen gewechselt werden kann. Ok. 24 Funktionstasten in Kombination mit Umschaltern machen das Ganze dann nicht unbedingt sehr übersichtlich, aber Du fängst halt mit dem Kleinzeug an, was Du brauchst und irgenwann erweitert sich Dein Horizont auf das Maß, das Du benötigst oder bei Interesse und den notwendigen Rechten darüber hinaus.
Es ist schön qsecofr zu sein.
Ich hab zu langsam getippt, Du warst schneller, Holger. - hm, Sonderfall, yet another setup tool - ganz ehrlich, als ich das 2003 nach längerer Abstinenz wieder mal benutzt hatten, war ich überrascht, wie es sich weiterentwickelt hatte. Nach einer halbe Stunde wollte ich unter lautem Fluchen diesen Scheiß nur noch loswerden. Damals war an regelmäßiges Linux bei mir noch nicht zu denken. 2009 habe ich es zuletzt benutzt. In abgeschwächter Form das selbe Ergebnis. Diesmal hat aber Suse auf meinem Rechner nicht wegen yum oder yast oder rpm keinerlei Chancen gehabt, sondern ist sogar 2 Tage sehr befriedigend gelaufen.
Erst am dritten Tag kam der große Knall, da in der Distribution an sich zuviel verbogen ist oder war. Danach hab ich Cent genommen. Cent war eigentlich die Distribution, bei der ich mich von der Verwaltung und Einfachheit am wohlsten gefühlt habe. Leider war es Herbst 2009 so gnadenlos veraltet, dass die meisten Sachen, mit denen ich spielen wollte, mein Wissen über Backports und Einbindung eigener Sachen weit überstiegen hätten. Das war eigentlich komisch, keine Ahnung warum, aber ich fühlte mich sehr wohl damit. Diesen Zustand erreichte ich erst ansatzweise wieder mit Arch Mitte letzten Jahres.
Die große Liebe zu debian ist bis heute nicht entbrannt, aber nach den Monaten fühle ich mich auch bei debian langsam aber sicher recht wohl. Ein Blick auf die Webseiten von Cent oder Fedora bringen mich aber regelmäßig nach 10 min Lesen zurück zu sid. Lieber ein paar Holperer und der Rest Zufriedenheit als das. Suse müsste ich mal wieder ausprobieren, allein es fehlt die Zeit. Und ausserdem ist ein großer Blocker vor Suse an der Reihe: Funtoo.
Den Ansatz von Sabayon fand ich ja auch recht gut, allerdings scheiterte es immer daran, das entgültige Umschalten auf gentoo, sprich den Wechsel von Sulfur zu emerge auf die Reihe zu bekommen. Ich geb aber zu, dass ich in diesen Belangen noch recht blöd und blauäugig war, als ich den Selbstversuch startete. Heute fehlt die Zeit und irgendwo der Wille, von fast Punkt 0 wieder anzufangen.
Quote from: "holgerw"Hallo @ayla,
bei Deinen bisherigen Testobjekten musst Du aber fairerweise sagen, dass es doch eher Nischendistributionen sind, die diverse Spezialitäten der Konfiguration haben und die zwar alle ihre deutlichen Stärken haben mögen, aber um den Preis, dass man extrem viel Zeit aufwenden muss, um sich in sie herein zu arbeiten.
Und nun nimm mal hingegen ein aktuelles Mandriva, Kubuntu oder openSUSE......
Das ist natürlich so wie du sagst.
Meine Auswahlkriterien -nachdem ich mal wieder den Kopf aus dem aptosid-Ei stecke- waren zuerst mal: Live-CD's suchen und erst mal anschauen. Kubuntu schied aus, da hab' ich schon einmal mit 7.x und 8.x ein paar "Erfahrungen" gesammelt, muß ich nicht mehr haben, dazu kommt noch dieses sudo-Gedöhns.
SuSe hab ich mal nach hinten gestellt -weiß auch garnicht ob es von denen inzwischen eine Live-CD gibt. Ich hab mit SuSe 4.nochwas angefangen in Linux reinzuschnuppern und bis 10.x fast ausschließlich SuSe zum "Linux Ausprobieren" benutzt. Dann lernte ich Debian kennen und war von der Klarheit und Strukturiertheit des Aufbaus schnell überzeugt. Wo ich bei SuSe -wenns mal mit Yast nicht klappte- immer Ewigkeiten am Suchen war um das -was auch immer- dann händisch in Ordnung zu bringen, gings bei Debian einfacher und schneller. Das kann natürlich vollkommen subjektiver Eindruck sein, möglicherweise hab ich den Aufbau von SuSe einfach nicht kappiert.
Und fairerweise muß ich auch sagen das mit Yast das Meiste ja auch auf Anhieb klappte -wenigstens ab 10.2/3. Anschauen werd ich mir eine der neuen SuSe's in absehbarer Zeit auf jeden Fall nochmal.
Arch hat vor allem deshalb erst mal den Vorzug weil mir die Chakra-CD gefiel.
Gruß
ayla
Meine Versuche mit pclinuxos, mandriva, fluxflux hab ich wegen
der paketmanager wieder eingestellt, das heisst fluxflux als
slackware ableger ist super für meinen eeepc 901 (lief alles out of the Box). Aber slapt-get ist leider nicht ganz so wie apt-get, und das softwareangebot muss man auch erst durch slackware erweitern.
Manches was ich unter Debian standardmässig finde hab ich dort auch nicht gefunden.
Linux kennengelernt hab ich mit SuSe 5.0. Ab 10.0 hat mich das Paketmanagement dann durch extreme "Schnelligkeit" über Ubuntu Kubuntu Kanotix zu Sidux/aptosid Debian getrieben. Aber das ist jetzt mit zypper ganz erträglich geworden. Nur finde ich das Angebot an vdr Paketen echt traurig,
oder ich war zu doof sie zu finden. Ich schaue mir aber jedesmal die neue Version unter virtualbox an.
das maclike dock bei dreamlinux fand ich auch echt schick, nur das die deutsche lokalisierung dort nicht meinen Ansprüchen genügt hat.
Ebenfalls interessant fand ich mint mit debian Basis =
Neptun 1.9.
Da ich die Breite des Softwareangebots noch wichtiger finde wie die Aktualität, apt wirklich prima ist, wird debian stable auf dem Server testing/sid auf dem Desktop wohl mein Freund bleiben.
Na, das war ja doch noch einfach :o
Bin wirklich platt wie gut der Installationsguide und das wiki von Arch gemacht sind. Und fuer jemand der den Umgang mit apt gewoehnt ist sollte pacman auch keine Probleme bereiten.
Ich danke nochmal agaida fuer seine wertvolle Hilfe.
(Das mit dem deutschen Kezboardlazout sollte jetyt ja auch noch in kde hinyukriegen sein, wenns in init 3 schon funktioniert)
Exploring...
EDIT huh, wieso ist das Foto hier schwarz/weiss? Eigentlich ist der Kaktus gruen und rot.
Hallo @dieres,
QuoteNur finde ich das Angebot an vdr Paketen echt traurig,
Diese Seite kann ich sehr empfehlen:
http://software.opensuse.org/search
Viele Grüße,
Holger
Hallo,
nachdem ich jetzt etwas Zeit hatte mir arch mal näher anzusehen noch ein paar Sachen die mir so als Highlights aufgefallen sind:
Pacman erscheint mir bei Installationen schneller als apt -obwohl ich arch auf einer "normalen" HD laufen habe und aptosid auf einer SSD, wobei bei aptosid /tmp ins RAM verlegt ist. Zu bedienen ist er genauso einfach.
Mein Netzwerk wird direkt mit wpa_supplicant und dhcpcd während des bootens gestartet und ist deutlich schneller up als mit "Ceni". Außerdem bricht -anders als auf meiner aptosid-Installation- die Verbindung nicht gelegentlich ab. Das hielt ich bisher für ein Problem der Funkverbindung an sich -jetzt rätsel ich da.
Beim ausprobieren von AUR habe ich mich dann auch über die Stabilität von arch gefreut.
Grub durch Grub2 ersetzen: erstaunlich einfach, dank des wiki, das hier aber -das .de- weniger komplett ist. Ohne daß ich grub2 schon gekannt hätte, hätte ich da wohl Probleme gehabt. Das englische half aber weiter. OS-prober aus AUR dazu und grub-mkconfg, fertig, alle OS auch von hier bootbar.
yaoult ist einfach nur gut.
An die rc.conf als zentrale Konfigurationsstelle könnte ich mich auch gut gewöhnen.
Fazit bisher: Der Ausflug lohnt auf jeden Fall. Noch ein wenig probieren und die Eigenheiten kennenlernen. Dann werde ich wohl Platz auf meiner SSD freischaufeln und mal versuchen eine möglichst schlanke Installation als zweites Betriebsystem aufzubauen. Arch kann sich jedenfalls durchaus ohne abzufallen mit aptosid vergleichen lassen.
Gruß
ayla
Freut mich ja, dass es gefällt. An dieser Stelle für alle diejenigen, die auch pröbeln wollen (und natürlich auch an Dich, ayla): Es ist nicht unbedingt ratsam, yaourt zum installieren von Paketen aus dem AUR zu benutzen - schon gar nicht zu Aktualisierung des kompletten Systems. Das wäre zwar möglich, ist aber keine gute Idee.
Begründungen: Wesentliche Kontrollmechanismen fallen einfach aus. Installation aus dem AUR hört sich geil an, aber eine Installation aus einem Quellpaket möglichst noch ohne Kontrolle des Rezepts on the fly ist nicht die beste Idee. Hab ich auch nicht geglaubt, musste das aber leider recht zeitaufwendig lernen. Ein wichtiger Punkt ist auch der Sicherheitsaspekt. Da yaourt per fakeroot weitesgehende Rechte innerhalb des Scripts hat, ist potentiellen Angreifern Tür und Tor geöffnet. Nicht weiter tagisch, die Auswirkungen eines mistig geschriebenen Pakets auf das System können mit root-Rechten recht drastisch sein. Das muss kein Schadcode sein, ein Slash zu wenig oder zuviel in Verbindung mit -rf können richtig spassige Sachen bewirken.
So was kann passieren, eine Qualitätskontrolle der Pakete im Aur findet praktisch nicht statt. Dafür ist der User selbst verantwortlich. Schaut man nicht drauf und es geht schief, Pech. Beschwert man sich dann, gibt das garantiert ein weltweites Gelächter und man hat den Titel "Esel des Tages" geerbt und auch verdient. Also IBM. (immer besser manuell).
Bei größeren Paketen wie Linus-Kerneltree bietet sich Build on the fly auch nicht an, da das übertragene .git-Archiv in /tmp landet und da naturgemäß nicht sehr lange überleben wird. Also bitte - benutzt yaourt -G und makepkg. Geht schneller, ist sicherer und und falls man doch mal schrauben muss, hat man die Quellen wenigstens an einem nicht unbedingt flüchtigem Ort.
Hallo,
ich schaue regelmäßig in dieses Forum um mich weiter zu bilden. Vor allem die Ausführungen von agaida sind einfach wunderbar. Ich bin nur User (nicht mal der Zusatz "Power-" würde zutreffen) und habe mir beide Systeme ( Arch und Aptosid ) auf die Festplatte "gehauen". Bei der Installation hat Aptosid eindeutig die Nase vorn. Nur kurz die Partitionen eingerichtet und nach knapp 5 Minuten lief das System wie geschmiert. Dank Ceni war auch Wlan schnell eingerichtet. Ich muß zugeben, bei Arch lief nicht alles so glatt. Schon bei der Partitionierung ist mir der Installer zweimal abgestürzt. Danach hatte Pacman Probleme die Pakete zu finden.Da ich Kummer gewohnt bin (hatte vor Jahren mal FreeBSD auf mein Laptop installiert) habe ich natürlich nicht aufgegeben.Na gut, beim 5ten Mal hat dann auch alles hingehauen und das Arch läuft jetzt auch ohne Probleme.Jetzt darüber zu diskutieren ob apt oder Pacman schneller ist halte ich für Zeitverschwendung. Beim Upgrade fühle ich mich persönlich bei Pacman sicherer. Kein Vergleich mit BSD wo auf Abhängigkeiten überhaupt keine Rücksicht genommen wird.
Im Moment benutze ich produktiv mehr Arch, aber das ändert sich von Zeit zu Zeit.
Hallo logout,
willkommen im Forum.
einen Vergleich zwischen pacman und apt in Bezug auf die Geschwindigkeit kann ich vorerst noch gar nicht anstellen, das war nur der erste Eindruck den ich hatte.
Auch über die Stabilität Arch : aptosid kann ich noch nix konkretes sagen, dazu müsste ich Arch erstmal wenigstens ein paar Monate im täglichen Einsatz laufen haben.
Warum ich diese erwähnt hatte hat den Grund daß ich ein wenig mit AUR herumgespielt hatte, eigentlich um zu sehen wie pacman/yaourt reagiert wenns mal ernsthafte Probleme mit Abhängigkeiten oder Inkompatibilitäten gibt.
Hatte mir z.B. das komplette Mesa-git dazu aus AUR geholt und per yaourt installiert. Ein/zwei Tage später wurde bei einem pacman -syu -was wohl einem apt-get dist-upgrade entspricht- der Xserver aus den "normalen" Repos upgegraded und meine Installation hat noch nicht mal gezuckt.
Hat aber auch nicht so viel zu sagen weil ich mit den Versionen noch nicht durchblicke...
Wenn ich das System mal aus der Testphase raus habe werde ich da wohl -eingedenk agaidas Rat- sehr viel vorsichtiger vorgehen, aber im Moment solls eigentlich ein paar mal knallen damit ich sehe was ich vermeiden sollte und auch mal was zu reparieren hab :)
Der Installer von aptosid ist in jedem Fall einsame Spitze.
Allerdings machte auch der von arch bei mir keine Probleme, nachdem ich erst mal eine Netzwerkverbindung hatte, das lief dann alles ganz sauber durch.
Was die Sicherheit von apt:pacman betrifft wage ich auch noch keinen Vergleich. Vorerst -da dran gewöhnt und gute Erfahrungen gemacht- ist da apt bei mir vorne.
Gruß
ayla
Der Grund, warum man so wenig über Stabilitätsprobleme in Arch liest, dürfte eventuell auch an der relativen Schmerzfreiheit einiger (vieler) Archbenutzer liegen. Diese Schmerzfreiheit steigt im Laufe der Benutzung. Hätte ich auch nie gedacht. Was in Debian eine Katastrophe ist, wird dann nur noch als leichter Schluckauf wahrgenommen. Zerschieße dem Durchschnittsbenutzer sein X und er ist unglücklich und eventuell verzweifelt. Ich habe einmal in nicht ganz jugendlicher Unbekümmertheit geschrieben, dass ein nicht funktionierender XServer ja nichts über die Funktionsfähigkeit der Installation aussagt - das System läuft doch stabil, der Server halt nicht. Den zu ändern - auf eine recht beliebige Version - ist mit eventuellem Kompilieren zwar auch ein Aufwand von einigen Minuten, aber was solls. Kritisch wird es eigentlich nur, wenn die Entwicklungswerkzeuge stillschweigend versagen. Das habe ich mit python und perl aus testing erlebt und fand das überhaupt nicht schön. Solange man aber an das System rankommt, ist auch das kein Problem. Wirklich böse wäre nur ein Löschen von /etc, der Rest des Systems ist eigentlich bequem zu ersetzen. Dabei rede ich jetzt ausdrücklich nicht von Anwendungsdaten.
In meiner Sturm- und Drangzeit hatte ich mal das unbedingte Bedürfniss /usr wegzulöschen (typo). War nicht so schön, aber relativ problemlos ohne den Einsatz einer Datensicherung zu reparieren. Eine wirkliche Totalzerstörung habe ich bisher nur mit rm -rf / hinbekommen (ok, Rechte und Eigentümer neu setzen macht auch Spass - aber ganz ehrlich, wenn man schon Datensicherungen macht, möchte man die doch auch mal einsetzen). Das war aber. bevor ich eine Sicherung gemacht hatte. Neue Daten waren da noch nicht drauf. Das war das erste und einzige Mal, dass mir so was passiert ist: Vor der ersten Datensicherung die Totallöschung. Insofern ist das System ob seiner Einfachheit doch sehr stabil. Hilfreich bei Problemen sind auch immer wieder Hilfestellungen á la "Du hast es kaputtgemacht, also sieh zu, wie Du es reparierst bekommst!". Aber auch bei solchen Antworten bekommt man meist noch Tipps, wonach man schauen könnte.
Toll beschrieben, ayla, Deine Erfahrung zu Arch. Zwar läuft mein Arch von der selben Platte wie mein aptosid und ich betreibe lediglich den aptosid grub2, was den Rest angeht so spricht mir Dein Eindruck aus der Seele. Arch manifestiert sich für mich zunehmends als interessante und attraktive Alternative. Nachdem ich Arch bislang für gerade mal wenige Wochen sub-produktiv und wohl eher experimentell nutze, bin ich vor allem erstmal weiterhin darauf gespannt wie sich pacman fortwährend verhalten wird und wie stabil das System dabei bleiben wird.
Zu agaida's Kommentar hinsichtlich yaourt hab ich eine Frage:
Wenn ich etwas aus dem AUR installier, dann werden die Infos in das Paketmanagement, samt Abhängigkeiten, übernommen, oder? Falls dem so ist, und falls zudem, wovon ich momentan ausgehe, ein "pacman -Syu" lediglich die Arch Repos berücksichtigt und nicht AUR, was passiert dann wenn sich ein offizielles Paket derart ändert dass ein installiertes AUR Paket dadurch seine Abhängigkeiten verliert?
Ein wenig komplexer ist das schon. Vergiss yaourt und frag einfach nicht danach. Die Frage, die Du eigentlich stellst, betrifft nur pacman. Und das verhält sich dann wie ein normales Abhängigkeitsproblem. Im schlimmsten Fall - Pech gehabt und nachfrickeln.
Klingt vielleicht jetzt ein wenig überheblich oder abgehoben - ist aber so. yaourt oder clyde oder was auch immer machen eigentlich nur eins. Sie vereinfachen den Prozess der Erstellung der Pakete aus Quelltext und sind reine wrapper um pacman respektive nutzen die Libraries von pacman.
Warum ich geschrieben habe - Pech gehabt, nachfrickeln: Jedes Paketmanagement ist nur so gut wie das schwächste Glied. Und das sind im Zweifel die AUR-Pakete. Davon ausgehend, dass die Abhängigkeiten korrekt verwaltet werden - stelle Dir bitte den Fall vor, in dem runtime-dependencies nicht ordnungsgemäß im Paket vermerkt sind. In diesem Fall bist Du einfach nur Nase. Spasseshalber kannst Du diesen Fall einfach nachstellen. Such Dir ein Paket aus, was seltene Abhängigkeiten hat. Stelle sicher, dass diese Abhängigkeiten (Build und Runtime) installiert sind. Modifiziere das zu bauende Paket dadurch, dass Du ein oder zwei Runtimes (im PKGBUILD) einfach löschst. Baue und installiere. Dann lösche die benötigte Abhängigkeit. ;)
Dieses Konstrukt ist nicht mal weit hergeholt. In diesem Fall hast Du einen Bruch im System, der eventuell nicht sofort auffällt und deshalb nur sehr schwer zu reproduzieren sein dürfte. Darin sehe ich die wirkliche Gefahr bei Paketen aus dem AUR. Die Pakete aus den offizielle Repositories können diese Krankheit zwar auch haben, aber die Chance, dass so was passiert, ist wesentlich geringer, da die Massnahmen zur Qualitätssicherung bei Arch eigentlich recht gut greifen. Nur halt bei Paketen aus dem AUR nicht. Deshalb ist auch der Weg nach Community relativ lang und steinig.
Das sagt jetzt auf keinen Fall aus, dass die Pakete im AUR von schlechter Qualität wären. Jeder der Pakete da reinstellt, macht das so gut er kann. Auch im Aur gibt es Rückmeldungen. Nur die Gefahr, sich die eine oder andere Inkonsistenz ins System zu holen, ist größer als bei den offiziellen Paketen.
Das war jetzt der beschriebene worst case. Was viel häufiger der Fall sein dürfte: Durch nicht oder nicht ganz richtige Versionsbegrenzungen könnte durch das ein oder andere Paket die ein oder andere Schnittstelle nicht ganz passen, was auch ganz witzige Effekte hervorrufen kann. Und dann wirds echt haarig, das zu debuggen. Das hab ich durch und das hat auch keinen Spass gemacht. Das ist aber alles kein Problem von pacman oder yaourt - die können in den beschriebenen Fällen rein gar nichts zu den Problemen dazu. Das ist dann das gute alte Prinzip Shit in - Shit out. Passiert halt schon mal, ist aber ein Problem in den Quellen.
EDIT: Das ist auch in debian möglich - da wird es nur dadurch verhindert, dass alle Pakete ihren Weg gehen über experimental oder sid als Einstieg gehen. Wenn die dann als stable deklariert sind, dann kann man davon ausgehen, dass keine oder nur sehr wenige grobe Klopfer in den Paketen verblieben sind. Nimmst Du nur einen dieser Filter weg, dann steigt halt die Zahl der Fehler im Endprodukt. Viele grundlegende Fehler kommen auch in debian erst gar nicht an, da die zuerst in den richtig blutigen Quelltext-Distries aufschlagen dürften. Was dann in experimental aufschlägt, ist aber (oder kann) immer noch in einem Zustand sein, der den Status experimental mehr als rechtfertigt. Genau aus diesem Grund wird auch bei Arch vor den unstable-Repos und testing gewarnt. Die sind das wirklich. Die Fehler schlagen da ungefiltert durch und sollen das auch. Der upstream hat in solchen Szenarien alle Hände voll zu tun und freut sich wahrscheinlich über die Anzahl an pre alpha Testern. Die KDE-Entwicklung von 4.6 recht hautnah mitzuerleben hat auf jeden Fall Spass gemacht. Arbeiten hätte ich damit aber nicht wollen.
@agaida, wirklich toll unterhaltender Schreibstil, Kolumnen reif!
Quote from: "agaida"Der Grund, warum man so wenig über Stabilitätsprobleme in Arch liest, dürfte eventuell auch an der relativen Schmerzfreiheit einiger (vieler) Archbenutzer liegen.
...
Zerschieße dem Durchschnittsbenutzer sein X und er ist unglücklich und eventuell verzweifelt.
In Gentoo ein Eintrag in /etc/portage/package.mask
>=x11-base/xorg-server-1.10.1und der Benutzer root Befehl:
emerge -uD worldum das System wieder mit einem älteren xorg zum Laufen zu bekommen.
[Edit zu Agaidas Edit] In Gentoo sind eigentlich nur die Overlays, in denen die Entwicklerarbeit gemacht wird, wirklich unstabil. In Gentoo ~unstable gibt es meistens nur Probleme bei denen USE Flags nich machen, wie sie sollten:
kdepimlibs lässt sich ohne "semantic-desktop" leider immer noch nicht kompilieren.
Wenn ich etwas aus einem Overlay ausprobieren will, aktiviere ich
- die USE Flags "test tests"
- das portage FEATURE "test"
so dass, die Paket spezifischen Tests veranstaltet werden. Fast alle höher entwickelten Softwaresweets haben ihre unit tests, die das fertig kompilierte System auf Funktionen und erwartete Ergebnisse prüfen.
Thema X und was man da ohne den Neubau des Gesamtsystems machen kann. Ein make world würde ich aus Zeitgründen ablehnen. Das muss auch anders gehen. Zum Beispiel so: https://bbs.archlinux.de/viewtopic.php?pid=261583#p261583
Quote
EDIT: Das ist auch in debian möglich - da wird es nur dadurch verhindert, dass alle Pakete ihren Weg gehen über experimental oder sid als Einstieg gehen.
das wird in debian zuvorderst dadurch verhindert, das der weg zum DM oder DD in debian mit tränen gepflastert ist, und so sicherstellt, dass der proband zumindest grundlegend sein metier beherrscht.
greetz
devil
+1
Und das ist auch gut so, wenngleich das doch sehr selektiv ist ;) Anders wäre der Weg wohl auch nicht möglich. Das ist bei Arch aber nicht anders. Mal eben TU werden dauert auch Jahre.
Quote from: "agaida"Thema X und was man da ohne den Neubau des Gesamtsystems machen kann. Ein make world würde ich aus Zeitgründen ablehnen.
Bei emerge -uDN @world wird nur
emerge --update(Up/Downgrades) --deep(Inspekt) --newuse(USEveränderteFlags) World(ManuelAusgewälte)Ich hatte nicht gemeint: emerge -e @installed
Hatte ich überlesen ;) Darüber weiss ich frühestens in ein paar Monaten mehr Bescheid.