Von captain archer am Di, 17. Februar 2009 um 14:00 #
Gleich mal die Gelegenheit genutzt, alle Festplatten auf ext4 neu formatiert, neu installiert, lief einfach und komplikationslos, wie erwartet. Arch Linux und kdemod-testing (KDE4.2 gegen QT4.5 kompiliert) = mein Compi ging noch nie so ab
War es aber nicht so, dass ext4 seine Fähigkeiten erst voll zur Geltung bringen kann, wenn man frisch mit ext4 formatiert? Auf jeden Fall finde ich das schon recht mutig, jetzt schon auf ext4 zu setzen, und das obwohl ich debian/sid Nutzer bin.
Stable als System, aber nicht stabil für den produktiven Einsatz. D.h. man wird bei neuen Versionen keine "Inkompatibilitäten" erleben, alles andere ist aber drin da nicht breitenwirksam getestet.
Der viel zitierte "produktive Einsatz" bezieht sich auf Leute, die kein Backup haben (gibts die noch?) oder auf ihre Daten nicht bis zur Wiederherstellung verzichten können (betrifft hauptsächlich berufliche Bereiche).
Wenn beides nicht zutrifft, empfehle ich sogar den Einsatz, da sonst auch in Jahren noch abgeraten werden muss (mangels Testern).
Von meister propper am Di, 17. Februar 2009 um 20:09 #
Es ist nicht so, dass ein umgewandeltes ext3 in ext4 nicht die Vorzüge von ext4 bietet. Nur die, bis zu diesem Zeitpunkt, bereits auf der Platte existenten Dateien bleiben im ext3 Format. Ein umkopieren dieser und schon sind sie auch in ext4 hinterlegt. Die Antwort ist also eher JAIN
ich habe mein Lenny auf ext4 migiert, natürlich mit eigenem Kernel und grub2 (aus unstable). Und ich habe sogar geschafft, das / zu migrieren, indem ich es "ro" in der fstab erklärt habe, und dann die Anleitung umgesetzt habe. Ansonsten ist das System dann "testing" oder gar "stable".
Ich hab da wenig Bedenken, da ich auf dem Notebook eh nur ein Linux haben will. Sonst würde mich ärgern, dass /home nach Neuinstallation erstmal ne Weile noch nicht so einfach zu mounten ist. Ansonsten glaube ich den Leuten, die es "stabil" genannt haben.
Kbluetooth hängt IMHO schon lange in der Portierung auf KDE4 fest. Bluetooth selbst läuft - einfach die Config-Files füllen. Für's Pairing kann man auch auf's entsprechende Gnome-GUI zurückgreifen ;)
..nicht mal Bluetooth.. Bluetooth war bei seiner Konstruktion tief ins Innere von Windows verwoben worden - mithilfe der Hardware-Hersteller. Dementsprechend lange dauerte eine vernünftige freie Lösung - mM eine Meisterleistung wie's inzwischen benutzbar ist.
das scheint mir einfach unwahr. Wieviel Windows steckt in Deinem Headset, Handy denn drin? Soweit ich es erinnere hat Bluetooth von Anfang an im Kernel gut funktioniert und die GUI hat eben keiner richtig hingekriegt dafür.
Bluetooth hat unter Linux schon immer problemfreier als unter Windows funktioniert. Ich hab bluetooth oft als Argument für Linux benutzt, wer unter Windows mal den "falschen" Stack installiert hat, bzw. Anwendungen hatten die einen anderen als den installierten brauchen, wird wissen was ich meine. Unter Linux ist es reinstecken und gut, obwohl aktuell wohl ein Problem bei den GUIs ist, das betrifft nicht nur KDE und kbluetooth..
> Mein aktuelles Kubuntu nervt mich grad weil nicht mal Bluetooth vernünftig geht. Tja, typischer Fall von Sackgasse :-)
Haste KDE 3 ist kdebluetooth nicht mehr mit dem aktuellen bluez kompatibel und funktioniert nicht mehr. Macht du ein Downgrade auf bluez-3.36, sollte es funktionieren, könnte aber auch ein Kernel-Downgrade nachziehen.
Haste KDE 4 ist kdebluetooth erst halbportiert. Du kannst zwar die Geräte "paaren" aber z.B. Datentransport geht nur in Richtung externes Gerät. Leider ist kio-bluetooth noch nicht portiert, deswegen kann man noch nicht "obex browsen". Als Alternative nutze ich dafür zzt. obextool.
Portierung ist unterwegs: > - Comment #39 from Tom Patzig 2009-02-15 22:34:23 --- > (In reply to comment #38) > > Thanks for porting Tom :-) > > Is there any time frame when obex-browsing (kio-bluetooth) will be ported? > > gpothier is working on that. Just stay patient ...
Bluetooth-Modem-Funktion kann man natürlich wie gewohnt schon jetzt mit kppp4 nutzen. Übrigens die aktuelle Alpha von Kubuntu-Jaunty in in einigen Punkten schon runder als Intrepid, z.B. mit einem funktionierendem KDE4-Networkmanager.
Genau so wie du es erklärt hast ist es bei mir. Wobei ich schon mit einer der letzten KDE 3 Versionen 3.5.x ein Problem hatte, was bei 3.4 noch nicht drin war. Fakt ist halt das ich mir Debian/Lenny (Experimental/KDE4) installiert hatte und alles hat gepasst - vom Pairing über den Datentransfer in beide Richtungen - das macht schon nachdenklich.
Von Thorsten Schnebeck am Mi, 18. Februar 2009 um 19:20 #
Ja, es gab zu KDE 4.0-4.1 Zeiten ein kdebluetooth4, dass mit dem alten bluez 3.x kompatibel war. Allerdings wurde der inkompatibel, als Solid (Hardwareabstaktionsebene) bluez 3 nicht mehr unterstütze und wie oben schon geschrieben bluez3 aus den Distributionen flog. Zwar ist KDE4 momentan sicherlich im "Burst-Mode", was die Entwicklungsgeschwindigkeit betrifft, dennoch gibt es noch ein paar Ecken, wo es noch Rückstand oder Missstand gibt, PIM-Sync ist so eine zweite große Lücke.
Hab meinen PC vor ein paar Tagen neu aufgesetzt und die neue Arch "Version" gleich auf ext4 installiert. Läuft hervorragend und sehr sehr flott. Die Konfiguration ist extrem einfach, da der Großteil (zumindest bei mir) in einer Datei (/etc/rc.conf) konfiguriert wird. Einfacher gehts eigentlich schon gar nicht mehr. Kernel Version 2.6.28 und GNOME 2.24.3 (mit aktiviertem metacity compositing) und bisher gab's noch keinerlei Probleme.
So gut Etch (und bald auch Lenny) auf meinem Server läuft, so gut läuft Arch auf meinem Desktop. Die Pakete sind topaktuell und stabil läuft das ganze bei mir auch. Wer's also noch nicht getestet hat: Ich kann Arch nur empfehlen!
Wie ist denn die Paketversorgung im Vergleich zu debian/sid (sidux). In letzterem sind ja sehr viele Programme verfügbar. Klar braucht man nicht alles, aber wenn man was braucht, ist es schön, es einfach mit apt-get installieren zu können. Und wie sieht die Stabilität des Systems bei Upgrades im Vergleich zu sidux aus, wenn Arch so sehr on the edge ist?
Was ich gerade so auf der arch-Webseite gelesen habe, hört sich ja ganz gut an. Wenn ich irgendwann mal mit sidux unzufrieden bin, erinnere ich mich hoffentlich an Arch.
Was die Pakete angeht so ist vieles verfügbar. Sollte mal etwas nicht verfügbar sein, so kann man es im AUR finden und ganz leicht selbst ein Paket erstellen.
War bei mir zumindest bisher nur ein zweimal nötig. Ansonsten war alles verfügbar. Mittlerweile sind es in den offiziellen Repositories ja auch schon um die 8000 Pakete (oder sogar mehr).
Nutze ArchLinux auf jeden Fall auch schon seit Anfang 2007, davor Gentoo und auch mal Debian auf dem Desktop. Aber mit ArchLinux bin ich bisher sehr zufrieden.
Ich finde Gentoo und Arch sollten sich mal ein bissel austauschen, ich benutze bisher gentoo, und portage ist einfach nur klasse. aber immer alle pakete selber zu kompilieren ist manchmal auch etwas stoerend und dauert lange. es sollte meiner meinung nach eine mischung aus binaer und src geben sodas man auch einfach mal das vorkompilierte paket installieren kann. das scheint bei arch besser geloest zu sein, vielleicht werd ich demnaechst mal arch ausprobieren.
Wie der Vorposter schon erwähnt hat, erfüllt ArchLinux genau deine Ansprüche. Ansich ist es eine Binärdistribution. Allerdings kannst du mit ABS (Arch Build System) selber Pakete mit einem sogenannten PKGBUILD erstellen. Ist quasi ein Shellskript und vergleichbar mit einem ebuild unter Gentoo nur einfacher zu erstellen. Die PKGBUILD's aller Pakete in den offiziellen Repositories lassen auch mit abs (per rsync) holen.
Damit kann man die Software mit den eigenen Compileroptionen (ebenfalls in einer make.conf) nochmals durchjagen und installieren.
Aber gerade im Vergleich zu Gentoo hat man doch erstens weniger Auswahl in der Konfiguration, so wie auch weniger und weniger aktuelle Pakete? Oder täuschen mich meine Stichproben?
Wo siehst du den Vorteil von Arch gegenüber Gentoo?
Wie ist denn die Paketversorgung im Vergleich zu debian/sid
Ich denke, das Paketrepository ist nicht so groß wie bei Debian. Allerdings habe ich bisher auch noch nichts vermisst. Über AUR gibt's dann noch Pakete, die nicht offiziell vom ArchLinux-Team sind und auch nicht als fertige Pakete vorliegen. Deren Installation ist aber trotzdem sehr einfach.
Und wie sieht die Stabilität des Systems bei Upgrades im Vergleich zu sidux aus, wenn Arch so sehr on the edge ist?
Es gibt keine Releases in dem Sinn. Die Releases beziehen sich nur auf die Installations-CD. Die einzelnen Pakete werden dann aktualisiert, wenn es eine neue Version gibt und der entsprechende Maintainer ein neues Paket baut. Das hat den Vorteil, dass man immer aktuelle Pakete hat und es keine "Releasesprünge" gibt. Allerdings sollte man Updates nicht einfach per Cronjob einspielen, sondern ein Auge darauf haben. Sonst kann es schnell passieren, dass man von KDE3 auf 4 updatet, ohne dass man das will.
Ich finde Arch super. Aber man sollte wissen auf was man sich einlässt. Man muss kein Linux-Profi sein, sollte aber vor der Shell nicht zurückschrecken. Wenn man keine ausgefallenen Wünsche hat, muss man bei Arch nicht viel konfigurieren. Aber man kann.
na ja, so ausgereift ist arch noch nicht. das mit dem rolling release tut in der praxis manchmal gar nicht mehr. z.zt kann ich arch nur in einer chroot umgebung updaten. seit dem 2.6.28 kernel geht mein wlan nicht mehr...ganze 2 monate geht das schon so. nach 5 jahren arch vergeht mir langsam die lust....
Von volltroll.de am Di, 17. Februar 2009 um 15:53 #
"seit dem 2.6.28 kernel geht mein wlan nicht mehr...ganze 2 monate geht das schon so." Einfach alten Kernel nutzen oder neue Wlankarte (wenns am Treiber liegt). Ich nutze auch noch den 22er wegen dem Fritzwlanusb. Mal schauen, vielleicht kommt ja mal ne neue Karte rein.
Oh falls du es noch nicht benutzt probier mal yaourt aus, das ist sehr angenehm um Arch aktuell zu halten. Denn neben den reinen Paketen die ihre Upgrades erhalten musst du dich vorallem um die Konfigurationen kümmern (*.pacnew/*.pacsave) wenn man das über einen langen Zeitraum nicht macht kommen solche Effekte wie von dir beschrieben zum vorschein.
Aber wie gesagt probier mal dein System mit yaourt zu fixen. Damit kannst du sehr leicht alte und neue Konfigurationen vergleichen/verwalten.
Wenn das Fallback funzt liegts wohl an autodetect in /etc/mkinitcpio.conf das hat mir den 2.6.28 und 2.6.28.1 zersäbelt bzw die Module für dmraid funzt aber mittlerweile wieder weil ich dmraid or autodetect reingeknallt habe.
Von root_tux_linux am Di, 17. Februar 2009 um 14:48 #
Gentoo = Source Distrubtion, Userflags, Cflags, Overlays Arch = Binär Distrubtion, ABS (Arch Building System - Man kann auch wie bei Gentoo kompilieren WENN MAN WILL!), AUR (Arch User Repro ähnlich wie Sunrise Overlay)
Ich bin vor 3 Wochen von Gentoo (nach 6 Jahren) auf Arch gewechselt. Weil: 1. Top aktuelle Pakete 2. Top aktuelle installations Medien 3. Weniger Aufwand
Ich glaube zwischen Gentoo und Arch wird es kaum Unterschiede geben in der Aktualität. Und wenn jemand schon Gentoo benutzen möchte wird er sich auch bei einer nicht-aktuellen InstallationsCD zu helfen wissen (zb Netzwerkinstallation). Die Aussage zum Aufwand kann ich bestätigen, allerdings empfinde ich den Unterschied nur bei einem frischen System bedeutsam, wenn erstmal die Grundkonfiguration steht ist es bei beiden ziemlich leicht die Konfiguration aktuell zu halten. Man wird ja durchaus von einigen Distributions-Tools unterstützt. Bin übrigens (wieder) Gentoo-User, sowohl Desktop als auch auf meinem Server.
Von root_tux_linux am Di, 17. Februar 2009 um 16:56 #
Früher konnte man drauf gehen das wenn neue Pakete rauskamen sie sofort bei Gentoo drin waren heute ist es bei manchen nimmer und da ist Arch aktueller.
Jeder Gentoo User kann dir das Theater mit KDE 4 erzählen da vergingen Monate bis überhaupt was im Tree war.
* app-emulation/virtualbox-bin Latest version available: 2.0.6 Latest version installed: [ Not Installed ] Size of files: 76,708 kB Homepage: http://www.virtualbox.org/ Description: Family of powerful x86 virtualization products for enterprise as well as home use License: PUEL
Aktuell wäre aber 2.1.4.
Von solchen Paketen findet man massig z.B. Zattoo.
Bevor kurz bevor ich von Gentoo zu Arch bin war z.B. Virtualbox (noch heute), murmur, mumble, Zattoo (noch heute), KDE4, aircrack-ng, eric4 und noch einige veraltet.
Gentoo ist wirklich ne super Distrubtion und man lernt extrem viel aber mit der aktualität von Arch kann es zumindest nicht in allen Bereichen mithalten.
> Dafür habe ich den Eindruck, dass Gentoo deutlich mehr Pakete zur Verfügung stellt. Mit oder ohne AUR? Mit AUR ist ja praktisch jedes unter Linux lauffähige Programm erhältlich und schwer zu schreiben sind die PKGBUILDS auch nicht...
>Mit oder ohne AUR? Ich hatte den Paket-Sucher auf der Seite benutzt. War wohl ohne AUR. Mit AUR ist die Anzahl an (neuen) Paketen wirklich erschlagend. Das sieht echt gut aus. Sind die denn auch lauffähig/stabil, wenn die von irgendjemanden aus der Community zusammengefrickelt werden, oder kommt es hin und wieder vor, dass im AUR auch Schrott landet?
> Sind die denn auch lauffähig/stabil, wenn die von irgendjemanden aus der Community > zusammengefrickelt werden, oder kommt es hin und wieder vor, dass im AUR auch > Schrott landet? Zusammenfrickeln tut da niemand was, da wird eins-zu-eins der Quelltext von den Seiten des jeweiligen SW-Projekts heruntergeladen und dann wird mir makepkg eine Binary kompiliert. Das Binary kann dann mit pacman installiert werden. Kann natürlich immer mal sein, dass das was hängt, bei yzis bin ich immer gescheitert, da der eine ältere lua-Version haben wollte. Das hätte man/ich schon irgendwie regeln können, aber damals war es mir den Aufwand nicht wert. Man kann im PKGBUILD auch bestimmte Versionen installieren, usw... Rest siehe: arch-de arch-de-wiki arch-en arch-en-wiki
Das gute bei den PKGBUILDS aus dem AUR ist, dass sie total einfach lesbar sind, du siehst also was genau da passiert. Das ist bei den ebuilds gerade seit Einführung der eclasses leider nicht mehr der Fall.
> Slots bzw verschiedene Pakete sind ned umbedingt nötig, hat sonst auch sogut wie keine Distrubtion.
Diese Aussage würd ich gern invertieren. Ich kenn keine Distrie die es NICHT hat, nur halt nicht direkt Slots, sondern Pakete in unterschiedlichen Versionen mit unterschiedlichen Namen. Bekanntestes Beispiel dürfte qt3 und qt4 sein.
Und genau deswegen hab ich nie wirklich verstanden warum Slots so ein riesiger Vorteil sein soll.
> Wie gesagt Gentoo ist ne grossartige Distrubtion aber Arch auch.
Jep, und ich finds gut dass es viele gibt die beides benutzen (ich eingeschlossen), und es sehr wenig Flamewars gibt, was von beiden "besser" ist.
> Und genau deswegen hab ich nie wirklich verstanden warum Slots so ein riesiger Vorteil sein soll. Slots einen «riesigen» Vorteil zu nennen, wäre in der Tat übertrieben. Allerdings ist es IMO benutzerfreundlicher, wenn das gleiche Paket nicht in verschiedenen Versionen unterschiedliche Namen hat. Jedenfalls merkte ich, als ich noch Debian benutzte, erst, dass «aptitude install apache» noch den alten Apache 1 installiert hatte, als eine Konfiguration aus einem Howto einfach nicht funktionieren wollte...
BTW: Du hast natürlich recht, dass man bei Arch auch z.B. Qt3 und Qt4 installiert haben kann. Bei KDE 3 und KDE 4 hingegen geht es nicht, das war für mich einer der Gründe, wieder auf Gentoo zu wechseln. Zwar bin ich mit KDE 4.2 auf Gentoo nicht unglücklich, aber weil zum Teil immer noch Funktionen gibt, die KDE 3 hatte und KDE 4 nicht, ist es praktisch, das entsprechende KDE 3-Programm noch installiert zu haben.
arch ist wie oft erwähnt rolling release. Zudem find ich, ist hier noch garnicht das dickste argument für arch genannt worden.
Arch legt großen wert auf sauberen code, und ein sauberes system. Es wird wenig bis garnicht "gefrickelt", ausser bei größeren Updates wie vom alten X.org auf den neuen, wos durch die alten xorg.confs speziell wegen des hotpluggings probleme gab. Dann patcht Arch selbst sehr wenig und hält sich generell dicht an die Entwickler der Bereitgestellten software, KDE 4.0 hat man zb einfach nicht intergriert, wie die vielen großen wie SuSe, Ubuntu oder Fedora es gemacht haben, aus dem profanen Grund das KDE 4.0 nicht für den Produktiveinsatz war. Auch amarok2 gibts derzeit nicht in Arch, weil amarok2 noch nicht geeignet ist amarok zu ersetzen, da es mehr probleme macht als sonstwas.
Das Problem hatte ich auch. Lag bei mir an dem backup-Programm "areca", welches eine Anhängigkeit zu OpenJDK beinhaltet. Da ich "areca" ohnehin nur testen wollte, hab ich es deinstalliert und OpenJDK auch gleich mit. Jetzt läuft JRE wieder.
nein, ich hatte OPENJDK entfernt und JRE wieder installiert. Damit lief das update dann bei mir wieder. OPENJDK hatte ich mit einem update mitgezogen, ohne es explizit installiert haben zu wollen (?!). Als ich es entfernen wollt kam der Hinweise auf die Abhängigkeit zum Backup-Progi. OPENJDK runter, JDK wieder rein, update dann ohne Probleme. So wars jedenfalls bei mir hier.
Ich kann nicht mehr updaten. OpenJdk und Jdk stehen im Konflik
OpenJDK ist mittlerweile die präferierte Java-Umgebung in Arch [1]. Pakete, die Java benötigen haben als Abhängigkeit nun auch "java-environment". Dies wird sowohl von openjdk als auch von jdk bereitgestellt. D.h., theoretisch müsstest du beide Java-Umgebungen verwenden können (aber eben nur eine davon). Praktisch gesehen weiß ich es nicht, da ich es nicht ausprobiert habe.
Evtl. hast du noch ein altes Paket, dass jdk als Abhängigkeit hat und nicht java-environment. Falls es dafür keine Aktualisierung gibt, solltest du das als Bug melden. Es sei denn, das Programm funktioniert wirklich nur mit jdk und nicht mit openjdk.
"Oben genanntes passiert durchaus auch bei "stable" Distris like Debian." Was? Wie? Wo? Habe ich was verpasst? Sowas wird dir bei Debian Stable nie (!) passieren können, da es dort höchstens Sicherheitsupdates gibt und diese in den meisten Fällen nicht viel am Programmfluß ändern. Peace.
Ist halt eine Dauerbaustelle, man weiß nie, was einen nach einem kleinen Update erwartet - defekte Pakete, kaputte Abhängigkeiten.
Defekte Pakete ud kaputte Abhängigkeiten hatte ich nun fast nie. Aber trotzdem sollte man die Liste der Pakete, die aktualisiert werden, nochmal durchsehen, damit keine Überraschungen kommen.
Da ich zu wenig von Linux verstehe, war mir das zu abenteuerlich.
Arch ist nicht gerade eine fire-and-forget-Distribution. Man sollte schon bereit sein, auf der Shell zu arbeiten, was ich aber nicht als Nachteil sehen würde. Eingriffe in Vollautomatikdistributionen sind meist umständlicher. Aber es gibt ja zum Glück für fast jeden Geschmack eine Linuxdistribution.
> Da ich zu wenig von Linux verstehe, war mir das zu abenteuerlich. Ich will dir nicht zu nahe treten, aber dann gehörst du auch nicht zur Arch-Zielgruppe. Um Arch nutzen zu können, sollte man sich schon ein wenig mit dem System beschäftigen wollen und können. Unter den Linux-Distributionen hat man halt die Wahl und kann sich seinen persönlichen Favoriten rauspicken. Im übrigen habe ich höchstens zweimal wirklich Hand anlegen müssen, bei der Einführung von mkinitcpio und bei dem neuen x.org der ohne xorg.conf daher kommt. Letzteres muss ja jede Distribution lösen, und mkinitcpio-ähnliche Tools müsste es ja auch bei den anderen Distris geben, oder nutzen die alle noch initrd? Meine Erfahrung ist aber auch, dass es meistens nvidia- und ati-Treiber (also nicht die freien) sind, die Stress machen. Ich nutze kein 3D und mir reicht daher vesa...
Ich verstehe die Architekturbezeichnung i686 nicht richtig. Sind das nur die Intel-Prozessoren ab Pentium Pro? Oder gehören die AMD Athlon Prozessoren auch zur i686-Architektur? Und wie sieht es mit dem Transmeta-Crusoe-Prozessor aus?
Ich verstehe die Architekturbezeichnung i686 nicht richtig. Sind das nur die Intel-Prozessoren ab Pentium Pro? Oder gehören die AMD Athlon Prozessoren auch zur i686-Architektur?
Aus der gcc-man-Page (-mtune und -march): "i686: Same as "generic", but when used as "march" option, PentiumPro instruction set will be used, so the code will run on all i686 family chips."
Die Arch-Doku [1] sagt auch was dazu.
Und wie sieht es mit dem Transmeta-Crusoe-Prozessor aus?
Keine Ahnung ob der Crusoe das PentiumPro instruction set unterstützt. Frag am besten im Arch-Forum nach.
Von Graf Krolock am Do, 26. Februar 2009 um 14:27 #
Der AMD Athlon ist auch ein i686-Prozessor. Ein Prozessor ist dann vom Typ i686, wenn der Prozessor den i686-Befehlssatz unterstützt. Oft wird irrtümlicherweise angenommen, dass der CMOV-Befehl erforderlich ist, damit ein Prozessor i686-kompatibel ist. Das ist aber falsch. Der VIA C3 ist nämlich ebenfalls ein i686-Prozessor, unterstützt aber kein CMOV (zumindest frühere Varianten des C3).
Jaja,immer schön Butter bei die Filesysteme werfen.
Ja
> recht mutig, jetzt schon auf ext4 zu setzen
Naja, immerhin ist es stable
Wenn beides nicht zutrifft, empfehle ich sogar den Einsatz, da sonst auch in Jahren noch abgeraten werden muss (mangels Testern).
es soll ja auch noch ein Online-Defragmentierer kommen, der diesen Schritt übernimmt. Mal sehen, ob der pünktlich zur 2.6.29 Release auch stabil ist.
Gruss,
Kay
ich habe mein Lenny auf ext4 migiert, natürlich mit eigenem Kernel und grub2 (aus unstable). Und ich habe sogar geschafft, das / zu migrieren, indem ich es "ro" in der fstab erklärt habe, und dann die Anleitung umgesetzt habe. Ansonsten ist das System dann "testing" oder gar "stable".
Ich hab da wenig Bedenken, da ich auf dem Notebook eh nur ein Linux haben will. Sonst würde mich ärgern, dass /home nach Neuinstallation erstmal ne Weile noch nicht so einfach zu mounten ist. Ansonsten glaube ich den Leuten, die es "stabil" genannt haben.
Gruss,
Kay
..nicht mal Bluetooth..
Bluetooth war bei seiner Konstruktion tief ins Innere von Windows verwoben worden - mithilfe der Hardware-Hersteller.
Dementsprechend lange dauerte eine vernünftige freie Lösung - mM eine Meisterleistung wie's inzwischen benutzbar ist.
das scheint mir einfach unwahr. Wieviel Windows steckt in Deinem Headset, Handy denn drin? Soweit ich es erinnere hat Bluetooth von Anfang an im Kernel gut funktioniert und die GUI hat eben keiner richtig hingekriegt dafür.
Typisches Freie Software Gesauge eben.
Gruss,
Kay
Wirf doch einfach deine Suchmaschine an..
Unter Linux ist es reinstecken und gut, obwohl aktuell wohl ein Problem bei den GUIs ist, das betrifft nicht nur KDE und kbluetooth..
problemfrei - problemfreier - am problemfreiesten
schwanger - schwangerer - am schwangersten
Tja, typischer Fall von Sackgasse :-)
Haste KDE 3 ist kdebluetooth nicht mehr mit dem aktuellen bluez kompatibel und funktioniert nicht mehr. Macht du ein Downgrade auf bluez-3.36, sollte es funktionieren, könnte aber auch ein Kernel-Downgrade nachziehen.
Haste KDE 4 ist kdebluetooth erst halbportiert. Du kannst zwar die Geräte "paaren" aber z.B. Datentransport geht nur in Richtung externes Gerät. Leider ist kio-bluetooth noch nicht portiert, deswegen kann man noch nicht "obex browsen". Als Alternative nutze ich dafür zzt. obextool.
Portierung ist unterwegs:
> - Comment #39 from Tom Patzig 2009-02-15 22:34:23 ---
> (In reply to comment #38)
> > Thanks for porting Tom :-)
> > Is there any time frame when obex-browsing (kio-bluetooth) will be ported?
>
> gpothier is working on that. Just stay patient ...
Bluetooth-Modem-Funktion kann man natürlich wie gewohnt schon jetzt mit kppp4 nutzen.
Übrigens die aktuelle Alpha von Kubuntu-Jaunty in in einigen Punkten schon runder als Intrepid, z.B. mit einem funktionierendem KDE4-Networkmanager.
Bye
Thorsten
Fakt ist halt das ich mir Debian/Lenny (Experimental/KDE4) installiert hatte und alles hat gepasst - vom Pairing über den Datentransfer in beide Richtungen - das macht schon nachdenklich.
Gruß
Thorsten
Die Konfiguration ist extrem einfach, da der Großteil (zumindest bei mir) in einer Datei (/etc/rc.conf) konfiguriert wird. Einfacher gehts eigentlich schon gar nicht mehr.
Kernel Version 2.6.28 und GNOME 2.24.3 (mit aktiviertem metacity compositing) und bisher gab's noch keinerlei Probleme.
So gut Etch (und bald auch Lenny) auf meinem Server läuft, so gut läuft Arch auf meinem Desktop. Die Pakete sind topaktuell und stabil läuft das ganze bei mir auch. Wer's also noch nicht getestet hat: Ich kann Arch nur empfehlen!
Was ich gerade so auf der arch-Webseite gelesen habe, hört sich ja ganz gut an. Wenn ich irgendwann mal mit sidux unzufrieden bin, erinnere ich mich hoffentlich an Arch.
War bei mir zumindest bisher nur ein zweimal nötig. Ansonsten war alles verfügbar. Mittlerweile sind es in den offiziellen Repositories ja auch schon um die 8000 Pakete (oder sogar mehr).
Nutze ArchLinux auf jeden Fall auch schon seit Anfang 2007, davor Gentoo und auch mal Debian auf dem Desktop. Aber mit ArchLinux bin ich bisher sehr zufrieden.
Damit kann man die Software mit den eigenen Compileroptionen (ebenfalls in einer make.conf) nochmals durchjagen und installieren.
Oder täuschen mich meine Stichproben?
Wo siehst du den Vorteil von Arch gegenüber Gentoo?
Ich denke, das Paketrepository ist nicht so groß wie bei Debian. Allerdings habe ich bisher auch noch nichts vermisst. Über AUR gibt's dann noch Pakete, die nicht offiziell vom ArchLinux-Team sind und auch nicht als fertige Pakete vorliegen. Deren Installation ist aber trotzdem sehr einfach.
Und wie sieht die Stabilität des Systems bei Upgrades im Vergleich zu sidux aus, wenn Arch so sehr on the edge ist?
Es gibt keine Releases in dem Sinn. Die Releases beziehen sich nur auf die Installations-CD. Die einzelnen Pakete werden dann aktualisiert, wenn es eine neue Version gibt und der entsprechende Maintainer ein neues Paket baut. Das hat den Vorteil, dass man immer aktuelle Pakete hat und es keine "Releasesprünge" gibt. Allerdings sollte man Updates nicht einfach per Cronjob einspielen, sondern ein Auge darauf haben. Sonst kann es schnell passieren, dass man von KDE3 auf 4 updatet, ohne dass man das will.
Ich finde Arch super. Aber man sollte wissen auf was man sich einlässt. Man muss kein Linux-Profi sein, sollte aber vor der Shell nicht zurückschrecken. Wenn man keine ausgefallenen Wünsche hat, muss man bei Arch nicht viel konfigurieren. Aber man kann.
pacman -Syu
genügt um dein System auf den aktuellen Stand zu bringen?
Einfach alten Kernel nutzen oder neue Wlankarte (wenns am Treiber liegt). Ich nutze auch noch den 22er wegen dem Fritzwlanusb. Mal schauen, vielleicht kommt ja mal ne neue Karte rein.
Denn neben den reinen Paketen die ihre Upgrades erhalten musst du dich vorallem um die Konfigurationen kümmern (*.pacnew/*.pacsave) wenn man das über einen langen Zeitraum nicht macht kommen solche Effekte wie von dir beschrieben zum vorschein.
Aber wie gesagt probier mal dein System mit yaourt zu fixen. Damit kannst du sehr leicht alte und neue Konfigurationen vergleichen/verwalten.
http://archlinux.fr/yaourt-en
1. mkinitcpio -g /boot/kernel26.img -k 2.6.28-ARCH
2. Fallback nutzen.
Wenn das Fallback funzt liegts wohl an autodetect in /etc/mkinitcpio.conf das hat mir den 2.6.28 und 2.6.28.1 zersäbelt bzw die Module für dmraid funzt aber mittlerweile wieder weil ich dmraid or autodetect reingeknallt habe.
Eher: Wenn 1. nicht geht, versuche 2.
ext3fsd zersäbelt die Partition so das man immer fsck ausführen muss und IFS erkennt ne ext4 partition ned mal
Ich liebe Gentoo, da es dynamisch wächst und nicht festen Releasezyklen unterworfen wird.
Arch = Binär Distrubtion, ABS (Arch Building System - Man kann auch wie bei Gentoo kompilieren WENN MAN WILL!), AUR (Arch User Repro ähnlich wie Sunrise Overlay)
Ich bin vor 3 Wochen von Gentoo (nach 6 Jahren) auf Arch gewechselt.
Weil:
1. Top aktuelle Pakete
2. Top aktuelle installations Medien
3. Weniger Aufwand
Die Aussage zum Aufwand kann ich bestätigen, allerdings empfinde ich den Unterschied nur bei einem frischen System bedeutsam, wenn erstmal die Grundkonfiguration steht ist es bei beiden ziemlich leicht die Konfiguration aktuell zu halten. Man wird ja durchaus von einigen Distributions-Tools unterstützt. Bin übrigens (wieder) Gentoo-User, sowohl Desktop als auch auf meinem Server.
Jeder Gentoo User kann dir das Theater mit KDE 4 erzählen da vergingen Monate bis überhaupt was im Tree war.
Kleines Beispiel:
rch64 / # emerge -s virtualbox
Searching...
[ Results for search key : virtualbox ]
[ Applications found : 7 ]
* app-emulation/virtualbox-bin
Latest version available: 2.0.6
Latest version installed: [ Not Installed ]
Size of files: 76,708 kB
Homepage: http://www.virtualbox.org/
Description: Family of powerful x86 virtualization products for enterprise as well as home use
License: PUEL
Aktuell wäre aber 2.1.4.
Von solchen Paketen findet man massig z.B. Zattoo.
Bevor kurz bevor ich von Gentoo zu Arch bin war z.B. Virtualbox (noch heute), murmur, mumble, Zattoo (noch heute), KDE4, aircrack-ng, eric4 und noch einige veraltet.
Gentoo ist wirklich ne super Distrubtion und man lernt extrem viel aber mit der aktualität von Arch kann es zumindest nicht in allen Bereichen mithalten.
Bietet Arch auch verschiedene Versionen eines Paketes?
Mit dem AUR kannst du schon ziemlich viel selber zaubern...
Mit oder ohne AUR? Mit AUR ist ja praktisch jedes unter Linux lauffähige Programm
erhältlich und schwer zu schreiben sind die PKGBUILDS auch nicht...
Ich hatte den Paket-Sucher auf der Seite benutzt. War wohl ohne AUR.
Mit AUR ist die Anzahl an (neuen) Paketen wirklich erschlagend. Das sieht echt gut aus. Sind die denn auch lauffähig/stabil, wenn die von irgendjemanden aus der Community zusammengefrickelt werden, oder kommt es hin und wieder vor, dass im AUR auch Schrott landet?
Kann man entweder von Hand machen oder mit yaourt.
Von Hand:
aur.archlinux.org
Pakets suchen
PKGBUILD ziehen
makepkg
pacman -U pkgname
Mit yaourt:
yaourt -S pkgname
Wenn was ned funzt oder die Version veraltet ist reicht ein schlichtes editieren der PKGBUILD.
Btw. yaourt ist ein Aufsatz für Pacman.
> zusammengefrickelt werden, oder kommt es hin und wieder vor, dass im AUR auch
> Schrott landet?
Zusammenfrickeln tut da niemand was, da wird eins-zu-eins der Quelltext von den Seiten
des jeweiligen SW-Projekts heruntergeladen und dann wird mir makepkg eine Binary
kompiliert. Das Binary kann dann mit pacman installiert werden.
Kann natürlich immer mal sein, dass das was hängt, bei yzis bin ich immer gescheitert,
da der eine ältere lua-Version haben wollte. Das hätte man/ich schon irgendwie regeln
können, aber damals war es mir den Aufwand nicht wert.
Man kann im PKGBUILD auch bestimmte Versionen installieren, usw... Rest siehe:
arch-de
arch-de-wiki
arch-en
arch-en-wiki
Davon abgesehen bringt dieses geslote auch ab und zu Ärger.
Paket bliblablub blockiert Paket bliblablub.
Hat halt alles vor und nachteile.
Wie gesagt Gentoo ist ne grossartige Distrubtion aber Arch auch.
Diese Aussage würd ich gern invertieren.
Ich kenn keine Distrie die es NICHT hat, nur halt nicht direkt Slots, sondern Pakete in unterschiedlichen Versionen mit unterschiedlichen Namen. Bekanntestes Beispiel dürfte qt3 und qt4 sein.
Und genau deswegen hab ich nie wirklich verstanden warum Slots so ein riesiger Vorteil sein soll.
> Wie gesagt Gentoo ist ne grossartige Distrubtion aber Arch auch.
Jep, und ich finds gut dass es viele gibt die beides benutzen (ich eingeschlossen), und es sehr wenig Flamewars gibt, was von beiden "besser" ist.
Slots einen «riesigen» Vorteil zu nennen, wäre in der Tat übertrieben. Allerdings ist es IMO benutzerfreundlicher, wenn das gleiche Paket nicht in verschiedenen Versionen unterschiedliche Namen hat. Jedenfalls merkte ich, als ich noch Debian benutzte, erst, dass «aptitude install apache» noch den alten Apache 1 installiert hatte, als eine Konfiguration aus einem Howto einfach nicht funktionieren wollte...
Arch legt großen wert auf sauberen code, und ein sauberes system. Es wird wenig bis garnicht "gefrickelt", ausser bei größeren Updates wie vom alten X.org auf den neuen, wos durch die alten xorg.confs speziell wegen des hotpluggings probleme gab. Dann patcht Arch selbst sehr wenig und hält sich generell dicht an die Entwickler der Bereitgestellten software, KDE 4.0 hat man zb einfach nicht intergriert, wie die vielen großen wie SuSe, Ubuntu oder Fedora es gemacht haben, aus dem profanen Grund das KDE 4.0 nicht für den Produktiveinsatz war. Auch amarok2 gibts derzeit nicht in Arch, weil amarok2 noch nicht geeignet ist amarok zu ersetzen, da es mehr probleme macht als sonstwas.
Den ganzen Arch Way, findet man hier:
http://wiki.archlinux.org/index.php/The_Arch_Way
Ich kann nicht mehr updaten. OpenJdk und Jdk stehen im Konflikt
B.
B.
OpenJDK ist mittlerweile die präferierte Java-Umgebung in Arch [1]. Pakete, die Java benötigen haben als Abhängigkeit nun auch "java-environment". Dies wird sowohl von openjdk als auch von jdk bereitgestellt. D.h., theoretisch müsstest du beide Java-Umgebungen verwenden können (aber eben nur eine davon). Praktisch gesehen weiß ich es nicht, da ich es nicht ausprobiert habe.
Evtl. hast du noch ein altes Paket, dass jdk als Abhängigkeit hat und nicht java-environment. Falls es dafür keine Aktualisierung gibt, solltest du das als Bug melden. Es sei denn, das Programm funktioniert wirklich nur mit jdk und nicht mit openjdk.
[1] http://www.archlinux.org/news/418/
pacman -Syu --ignore soprano
Ist halt eine Dauerbaustelle, man weiß nie, was einen nach einem kleinen Update erwartet - defekte Pakete, kaputte Abhängigkeiten.
Da ich zu wenig von Linux verstehe, war mir das zu abenteuerlich.
Brain 1.0 gehört halt immer dazu
Was? Wie? Wo?
Habe ich was verpasst? Sowas wird dir bei Debian Stable nie (!) passieren können, da es dort höchstens Sicherheitsupdates gibt und diese in den meisten Fällen nicht viel am Programmfluß ändern. Peace.
Ein dist-upgrade ist kein kleines Update.
Defekte Pakete ud kaputte Abhängigkeiten hatte ich nun fast nie. Aber trotzdem sollte man die Liste der Pakete, die aktualisiert werden, nochmal durchsehen, damit keine Überraschungen kommen.
Da ich zu wenig von Linux verstehe, war mir das zu abenteuerlich.
Arch ist nicht gerade eine fire-and-forget-Distribution. Man sollte schon bereit sein, auf der Shell zu arbeiten, was ich aber nicht als Nachteil sehen würde. Eingriffe in Vollautomatikdistributionen sind meist umständlicher. Aber es gibt ja zum Glück für fast jeden Geschmack eine Linuxdistribution.
Ich will dir nicht zu nahe treten, aber dann gehörst du auch nicht zur Arch-Zielgruppe. Um
Arch nutzen zu können, sollte man sich schon ein wenig mit dem System beschäftigen wollen
und können. Unter den Linux-Distributionen hat man halt die Wahl und kann sich seinen
persönlichen Favoriten rauspicken.
Im übrigen habe ich höchstens zweimal wirklich Hand anlegen müssen, bei der Einführung von
mkinitcpio und bei dem neuen x.org der ohne xorg.conf daher kommt. Letzteres muss ja jede
Distribution lösen, und mkinitcpio-ähnliche Tools müsste es ja auch bei den anderen Distris
geben, oder nutzen die alle noch initrd?
Meine Erfahrung ist aber auch, dass es meistens nvidia- und ati-Treiber (also nicht die freien)
sind, die Stress machen. Ich nutze kein 3D und mir reicht daher vesa...
Oder gehören die AMD Athlon Prozessoren auch zur i686-Architektur? Und wie sieht es mit dem Transmeta-Crusoe-Prozessor aus?
Oder gehören die AMD Athlon Prozessoren auch zur i686-Architektur?
Aus der gcc-man-Page (-mtune und -march):
"i686: Same as "generic", but when used as "march" option, PentiumPro instruction set will be used, so the code will run on all i686 family chips."
Die Arch-Doku [1] sagt auch was dazu.
Und wie sieht es mit dem Transmeta-Crusoe-Prozessor aus?
Keine Ahnung ob der Crusoe das PentiumPro instruction set unterstützt. Frag am besten im Arch-Forum nach.
[1] http://preview.tinyurl.com/2onnap