Macht Archlinux etwa kein Backup des alten Kernels, der sich dann als Notanker im grub anwählen lässt? Das würde mich aber wundern. So viel Platz sollte im /boot doch eigentlich immer sein
> Macht Archlinux etwa kein Backup des alten Kernels, Welche Distribution macht das? > der sich dann als Notanker im grub anwählen lässt? Es werden immer zwei installiert, der default und ein fallback. > Das würde mich aber wundern. So viel Platz sollte im /boot doch > eigentlich immer sein:-) Sollte schon, aber mit dem fallback-image hat man schon einen Rettungsanker. Zur Not kann man sich ja einen eigenen anlegen.
> Macht Archlinux etwa kein Backup des alten Kernels, Welche Distribution macht das?
Alle mir bekannten in dem Sinne, daß der "alte" Kernel nicht gelöscht wird. Dann wird der Eintrag in Grub oder Lilo nicht gelöscht, sondern weiter vorgehalten.
Wenn Arch das nicht per default so macht, es ist ein Klacks, das selber zu machen. Das spart dann das Rauskramen der Boot-CD mit chroot und ähnlichen Späßen.
> Alle mir bekannten in dem Sinne, daß der "alte" Kernel nicht gelöscht > wird. Dann wird der Eintrag in Grub oder Lilo nicht gelöscht, sondern > weiter vorgehalten. *kopfkratz* Meine SuSE- und Ubuntu-Zeit ist auch sehr lang her...
> Wenn Arch das nicht per default so macht, es ist ein Klacks, das selber > zu machen. Äh, das letzte Wort in meinem Posting ist ein Link um das ganze mit Arch-Werkzeugen zu machen.
> Es werden immer zwei installiert, der default und ein fallback.
Genau falsch, informieren bevor du rumpustest. Es immer genau ein Kernel installiert, nicht mehr und nicht weniger. Der Fallback Eintrag bezieht sich auf die Fallback Initrd, die im Gegensatz zur normalen immer alle Module hat und daher auf jedem PC bootet. Mehr ist das nicht.
Willkommen bei meiner derzeitigen Lieblings-Distro!
Bin auch vor circa 3 Monaten erst zu Arch Linux gewechselt und bin voll zufrieden. Kernel Updates sind keine Probleme... Bei mir hat sich sogar ein Problem durch das automatische Update-Script gelöst, das ich vorher nicht beseitigen konnte:-)
Nur dran denken /boot/ rw zu mounten, wenn man es per default als ro mountet. Da hilft aber auch ein bisschen Brain 1.0 und die Meldungen des Update-Scripts mit offenen Augen anzuschauen;-)
Von Anonymous Coward am Do, 11. Juni 2009 um 13:53 #
Rolling Release Distros sind mir etwas zu aufwendig. Allerdings kann es auch sein, dass ich sie nicht so mag weil ich hier nur UMTS/HSDPA mit 10GiB Trafficbeschränkung habe.
> Ich nutze seit 1 Monat Archlinux. Bissl OT aber...gibts bei euch inzwischen signierte Pakete? Das war anno dazumal als ich mir das angesehen habe ein NoGo was ich schade fand.
Ich habe schon viele Kernel-Upgrades unter Arch Linux mitgemacht und das schlimmste was bisher geschah war, dass ich die Kernelmodule für meine WLAN-Karte neu kompilieren müsste... (btw: es heißt Arch Linux, nicht Archlinux)
So viele ArchLinuxer.........na da bin ich aber platt. Na ja, zur Not kann man ja auch mit der CD booten und dann das Super Forum und das Wiki befragen.
Ich benutze seit ca. 1 Jahr Arch und kann mir nicht vorstellen, eine andere Distro zu nutzen... Hab auch schon genug Kernel updates überlebt... Das einzige Problem war mal beim update auf .29, da wurde bei meiner CPU nur ein Prozessorkern erkannt... Im Forum wurde mir geholfen - ich musste einfach nur APIC einschalten (was vorher komischerweise kernel panics verursachte... jetzt ist es auf einmal benötigt) Schlimmer war das eine große Xorg update... und das auch nur bis es einen Wikieintrag dazu gab
Ich dachte Gentoo ist am sterben und nur Unbelehrbare kompilieren noch täglich vor sich hin und verbraten sinnlos Strömlinge und belasten die Umwelt für nix (ok, 1% performance mehr im synthetischen benchmark kann den Dödel enorm vergrössern).
Nicht jeder will ein KlickBunti!! Gentoo macht Spass und man lernt viel... Und wenn du bereit bist jedes Programm unter Linux, mit allen möglichen Optionen die du nicht brauchst, zu verwenden ist das dein Problem.
Diesen Vorteil bezahlst Du mit den anfallenden Kompilierorgien (ich habe selber ungefähr 2 Jahre lang gentoo benutzt). Ob es einem das wert ist, muß man für sich entscheiden. Mir (!) war es auf die Dauer zu nervig (wobei die Stromkosten auch eine Rolle gespielt haben).
Nett ist es natürlich, wenn man Eigenschaften eines Programmes braucht, die per Standard nicht aktiv sind. Ich erinnere mich düster z.B. an POP3-Unterstützung in mutt, die ich brauchte (mittlerweile nehme ich dafür einen externen POP3-client ...) und mir dann selber "reingebacken" habe. Rein aus performance-Gründen würde ich eher nicht selbst kompilieren wollen. Das dürfte auf einigermaßen modernen Kisten keine größere Rollen spielen. Und auf älteren Kisten macht das Kompilieren nicht viel Spaß. Ich habe mal einen gentoo-Kernel auf und für eine{n|m} PII 450 gebacken (natürlich einen angepaßten - das Ding sollte ein Router werden. War damals natürlich schon uralt). Da war ich mit über einer Stunde dabei, iirc.
Lernen kann man bei gentoo in der Tat sehr viel, aber das geht bei Distributionen wie debian auch (wo ich jetzt gelandet bin).
Und auf älteren Kisten macht das Kompilieren nicht viel Spaß. Ich habe mal einen gentoo-Kernel auf und für eine{n|m} PII 450 gebacken (natürlich einen angepaßten - das Ding sollte ein Router werden. War damals natürlich schon uralt). Da war ich mit über einer Stunde dabei, iirc.
LOL, nur eine Stunde? . Ich habe mal ein Gentoo 1.4 auf einem Laptop mit Pentium 120 MHz kompiliert und weil ich es wissen wollte mit X, KDE und OpenOffice. Das hat selbst mit Tricks wie distcc mehr als einen Monat gedauert. Aber im Geschwindigkeitsvergleich mit Debian, Mandrake und Suse (absteigende Performance) war es das schnellste und im Gegensatz zu Suse gut benutzbar.
... debian ... (wo ich jetzt gelandet bin)
Ja da bin ich auch gelandet, nachdem ich vor dem Problem stand, meinen Hauptrechner (1 GHz) mit ca. 15 GB Software auf ne aktuelle libc zu hieven, was bedeutet hätte, dass ich ca. eine Woche nicht richtig hätte arbeiten können, war da ganz schnell ein Debian drauf.
Ahja, du weißt also was genau passiert, wenn du das USE-Flag +flitzekacke setzt? Wenn du "genau" wissen willst, was du kompilierst, dann bleibt dir, wie bei jeder Distri, nur der Fußweg. Und da eigentlich jede Distribution einen bequemen Weg hat mit den Quellen umzuspringen bietet Gentoo dahingehend keinen Mehrwert. Was mich damals von Gentoo weggebracht hat, war die Qualität der ebuilds, nicht unbedingt die Qualität der damit generierten Binaries, aber das war teilweise schon abenteuerlich, kann inzwischen natürlich ganz anders sein, hab seitdem keinerlei Berührung mehr damit.
Wenn man wissen will, was beim Useflag +sprühwurst genau passiert, reicht ein Blick ins ebuild. Wobei ich da auch sagen muss, dass diese durch die ganzen eclasses und e-irgendwas relativ unlesbar geworden sind. Aber es ist trotzdem was anderes, als bei einer Binärdistrie ein Paket aus den Sourcen zu bauen, da das die Paketverwaltung nur rudimentär unterstützt: Wenn du z.B. Paket X mit Unterstützung für Y kompilierst, musst du selbst dafür Sorge tragen, dass Y-libs installiert sind, bzw. die deps im Paket entsprechend anpassen. Wenn du Paket A ohne Unterstützung für foo kompilierst, und B von A abhängt, musst du u.U. B auch neu kompilieren, bekommst das aber erst mit wenn B nicht mehr geht, sagen tuts dir keiner. Usw. hier könnten noch mehrere Beispiele folgen.. Desweiteren musst du sämtliche Pakete auf hold setzen, sprich Binär-Updates derselben verbieten, was auch bedeutet du musst dich selbst um Sicherheitsupdates kümmern, andere von deinen Paketen abhängige Pakete werden evtl. auch nicht mehr geupdated, da sie die Abhängigkeiten in der neueren Version verlangen, usw. Wer also sagt, dass Gentoo ggü. SRPM oder deb-src keinen Mehrwert hat, noch dazu gerade mit dem Beispiel der Useflags, hat keine Ahnung von Gentoo oder vom Paketmanagement im Allgemeinen, insofern bezweifel ich, dass du etwas über die Qualität der ebuilds sagen kannst.
Ich bin kein Gentoo-Freak, ich setze es nur noch auf wenigen Rechnern ein (bin auf Servern größtenteils auf Debian, und bei meinem Desktop auf arch, Bekannte/Verwandte Ubuntu), also ich will es hier nicht Gentoo über Gebühr schönreden, aber es ist immernoch ungeschlagen das flexibelste und anpassbarste Paketmanagement. Es gibt auch viele Momente wo ich Gentoo vermisse..
Es geht primär um Konfigurierbarkeit bei Gentoo und das Vermeiden von kaputten Paketen wie auch bei Arch häufiger anzutreffen. Wird zwar keinen der Jubelperser tangieren, da nicht existent in deren Mikrokosmos, aber so ist nun einmal die Realität. Zudem hat Gentoo eine ganz andere Qualität inne, weswegen viele der Patches in diversen Distros, u.a. auch Arch, Anwendung finden.
Keine Signierten Pakete ---> Unsicher?! Bugreports stapeln sich seit MONATEN und werden nicht abgearbeitet (Erste Seite bei bugs.archlinux.org) Programme sind BUGGY seit MONATEN im core (z.B. Blender, Mplayer) Alpha Versionen in core (z.B. K3B) Buggy Programme werden trotz Bugreport in core verschoben (z.B. Mplayer mit MKV). kdemod für x86_64 kommt garnicht hinterher (z.B. bei 4.2.2 auf 4.2.3 hiess es, es gäbe nur eine Dev für x86_64!)
Ich überleg mir momentan wirklich ob ich nicht wieder zu Gentoo zurück gehe oder gar auf eine Distrubtion ausweiche die eine Firma dahinter hat.
Das mit den unsignierten Paketen stört mich auch ein wenig.
Die Bugreportproblematik kann ich _nicht_ bestätigen. Auf meine wurde immer innerhalb einer Woche reagiert und 2 Wochen später wars gefixed.. Blender benutze ich nicht, aber inwiefern ist mplayer buggy? Bei mir spielt er noch alles ab Ich finds nur schade, dass keine VDPAU Unterstützung integriert werden wird.
Das mit K3B war ein "Unfall", das sollte nie so im [extra] landen. Es ist ja auch fast unbrauchbar atm.
Momentan gibts mehr Devs, die x86_64 selbst nutzen, als i686 Nutzer. Daher sind idR die x86_64 Pakete momentan schneller da als die i686..
Ich mein natürlich Exta im Falle von Blender, K3B und Mplayer.
Bei Mplayer: http://bugs.archlinux.org/task/14491. Bugreport wurde im 28. April eröffnet, trotzdem wurde am 18/19 Mai Mplayer mit dem Bug in extra verschoben.
Bei Blender: http://bugs.archlinux.org/task/12862. Was bei Blender ganz bitter ist, ist die Tatsache das der "Bug" seit Januar bekannt ist, keiner ihn fix trotz Lösung und nicht mal update rausbringt.
Das Verhalten ist mir schon bei mehreren Paketen aufgefallen, also das trotz Wochen alter Bugreports ein Paket mit Bug in core, extra oder community landet.
KDEmod (bald Chakra) ist ein "eigenständiges" Projekt und ist nicht Arch Linux' KDE-Variante
2. Pakete wie Mplayer oder K3b werden *nie* in core "erscheinen", da in core nur die nötigstens Pakete für einen Betrieb drin sind. Nichtmal X.Org ist in core (es ist in extra).
Kdemod ist und bleibt kdemod, nur die darauf basierende LiveCD heisst Chakra. Ich bin dabei übrigens einer der x86_64 Packager. Es gab eben Probleme mit einem Buildserver.. In absehbarer Zeit wird das alles kein Problem mehr sein.
Kein Linux-Dateisystem ist atomar konsistent. Stattdessen versucht man die Konsitenz erst wieder herzustellen, wenn die Katastrophe schon längst passiert ist. Das kann schon per Defintion nicht funktionieren und tut es in der Praxis auch nicht. Was mit bei Linux schon alles an Dateisystemen um die Ohren geflogen ist, ist nicht mehr feierlich. Andere Betriebssysteme - und nein, nicht Windows - die atomar konsitent arbeiten, habe diese Probleme nicht. Also, erst einmal über den Tellerrand schauen, bevor man wieder mal "Troll!" schreit.
Reiser4 ist es. (wobei das nicht im vanilla-Kernel ist und wohl auch nie sein wird) Scheint aber auch kaum Bedarf zu geben, kein Unternehmen im Linuxumfeld hat sich bisher dafür interessiert.
es gibt keinen Grund, die Software eines Schwerverbrechers nicht einzusetzen, solange diese unabhängig von der Tat entstanden ist, und das ist alleine wegen der zeitlichen Reihenfolge der Fall.
Andererseits gibt es keinen technischen Grund Reiser 4 einzusetzen.
Wenn man mit Dateisystemen experimentiert ist das die eigene Schuld. Isch abe selbst als Suse Reiser als Standard gesetzt hat um in den meisten Fällen nicht wirklich relevante Geschwindigkeitsvorteile auszunützen einfach EXT3 genommen und noch keinerlei Datenverlust durch Inkonsistenz gehabt obwohl die lieben Kinder und meine Frau trotzdem man es ihnen immer wieder sagt öfters Mal den Rechner ohne Herunterfahren abschalten. Ansonsten werde ich auch hier weil andere mit einem neuen Dateisystem experimentieren wollen sicher noch lange keine neuen Einstellungen akzeptieren. Das Problem sitzt meistens vor dem Bildschirm.
tu dir nen gefallen und kauf deinem weib und den bälgern nen eigenen rechner für den sie selbst verantwortlich sind. kann sein das man als familienvater ein dickeres fell hat, aber mir persönlich würde der hals platzen wenn auch noch innerfamiliär die sorglosigkeit/dummheit anderer mir arbeit machte.
Der Mist ist doch die zuverlässigkeit. Wem stört es, dass das ext3 bleibt wie es ist? Die Performancesteigerung die Umstellung kann man später auch noch machen, wenn man es benötigt. Jetzt muss man beim kernelupdate erst noch von hand eingreifen, um genau die alte Funktionalität beibehalten zu können.
Wenn man ext4 noch optimieren will/muss bitte, aber bei ext3 sind derartige änderungen nur für den alles andere als willkommen. Dafür sehen dann ein paar Benchmarks in den Verkaufsprospekten der kommerziellen Distris besser aus.
Würde mich endlich mal selber gerne ans Konfigurieren und Kompilieren eines Kernels extra für meine Hardware wagen, aber ich habe da noch so einige Fragen. Kennt jemand eine gute Anleitung (Schritt für Schritt) um einen Kernel unter Debian zu bauen? Ich finde zwar relativ viele Anleitungen, aber die unterscheiden sich zum Teil recht stark.
Und gibt es eine Seite wo man nachlesen kann für was die ganzen Optionen und Treiber bei den Einstellungen des Kernels stehen? Oder muss man sich das alles per Suchmaschine raus suchen? Bei den ganzen Einstellungen verliert man recht leicht den Überblick, besonders wenn man nicht weiß wofür alles steht.
Von anyoneirgendwer am Mi, 10. Juni 2009 um 20:05 #
Geh einfach alles durch, wenn du dann bei den Treibern bist, hast du das mühsamste hinter dir (finde ich). Drück in make menuconfig ? und du wirst Hilfestellungen dazu bekommen, oft auch empfehlungen. Wenn du dann noch nicht sicher bist was du tun sollst oder nicht verstehst was es macht, benutz eine Suchmaschine oder nimm die Empfehlung.
Ich glaube kaum dass irgendjemand wirklich jede Option im Detail im Linux Kernel versteht.
Ich glaube kaum dass irgendjemand wirklich jede Option im Detail im Linux Kernel versteht.
Mit Deiner Vorgehensweise bist Du aber definitiv auf dem direkten Weg dahin!
Vielleicht sollte man doch eher ein "make oldconfig" nutzen - oder macht es Spaß, drei Stunden lang alle möglichen Config-Optionen einzeln abzuwägen? Im Normalfall nimmt man einen laufenden Kernel und ändert beim Rebuild (einer evt. neueren Version) ein, zwei, drei Optionen ab.
Das ganze ist schlicht und einfach nur ein (jedenfalls unter Debian) tar xjf linux-NEU...tar.bz2 cd linux-NEU... cp /boot/config-MOMENTAN .config make oldconfig make-kpkg clean make-kpkg [--initrd....] kernel_image dpkg -i ../linux-image.....
Runterladen Entpacken in /usr/src make menuconfig Treiber die zwingend benötigt werden als Built-in (*), alle anderen wenn du magst als Modul (m) Was die Treiber etc bedeuten ---> Siehe HELP oder kenne deine Hardware. make && make modules_install
Ist doch alles eine Frage des Geschmacks. Der eine mag Windows, weil er sich um nichts kümmern muss, der andere mag es nicht, weil man sich um nichts kümmern kann und Fehler einfach hinnehmen muss. Ich denke, dass die Entscheidung Windows 7 oder Linux bei den meisten immer noch eine Frage dessen ist was sie haben möchten, was sie gewohnt sind oder was ihrer Ansicht von einer Freien Welt am besten passt. Mir würde auf Windows inzwischen (egal wie weit entwickelt es sein mag) der fvwm und all die gnu-tools fehlen. Als ich noch ausschließlich mit Windows gearbeitet habe, war mir W2k sehr lieb und stabil... von Armutszeugnis also keine Rede.
Von BSDistMeinSystem am Do, 11. Juni 2009 um 08:33 #
Andersherum ist es aber auch nicht viel besser. Was nützt mir ein Linux, wenn es voller Unzulänglichkeiten und Bugs ist. Der Normalanwender kann/will nicht jeder Woche sein System updaten und damit uU neue Fehler hinzugewinnen.
Ein großer Vorteil von Windows ist seine Homogenität in der Oberfläche und Programmen. Da wird Linux nicht mithalten können. Oder wie willst du einem Anwender erklären, das es dutzende Widget Toolkits gibt, alle samt mit anderem Aussehen und Verhalten.
Frage am Rande: Zum aktu. Ubuntu und der Nvidia Treiber. Ich besitze ein Onboard Grafikkarte(7???) und bekomme ständig schwarze Bereiche(immer in der Nähe von Widgets) innerhalb meiner Ausgabe. Dies passiert häufig, der Treiber ist closed source. Normal? Abhilfe?
> Ein großer Vorteil von Windows ist seine Homogenität in der Oberfläche und Programmen. Da wird Linux nicht mithalten können. Oder wie willst du einem Anwender erklären, das es dutzende Widget Toolkits gibt, alle samt mit anderem Aussehen und Verhalten.
Warum soll ich das nem Anwender erklären (ausser er wills wissen)? Ein reiner Anwender der keine Ambitionen hat das System zu verstehen/zu verändern/sonstwas bekommt z.B. ein Ubuntu und fertig. Dank gleicher Qt und GTK-Themes merkt er ja nichtmal dass es verschiedene Toolkits gibt.
> Frage am Rande: Zum aktu. Ubuntu und der Nvidia Treiber. Ich besitze ein Onboard Grafikkarte(7???) und bekomme ständig schwarze Bereiche(immer in der Nähe von Widgets) innerhalb meiner Ausgabe. Dies passiert häufig, der Treiber ist closed source. Normal? Abhilfe?
In der Nähe von Widgets werden möglicherweise Schatten/transparente Bereiche von den 3D-Funktionen der Graka gezeichnet, und das ist evtl. bei deinem Treiber buggy. Temporäre Abhilfe könnte das Abschalten der Compiz-Funktionen sein. Sorry hab gerade kein Ubuntu zur Hand, sonst würd ich dir sagen wie das genau heißt..
Der war auch gut. Ich zähle mal ein paar Windowsprogramme auf. Du darfst Sie Dir ansehen und danach können wir über Homogenität reden
CATIA V5, SAP, Microsoft Office 2007, MS Project, MS Internetexplorer 7, MS Mediaplayer ... möchtest Du noch mehr? Nicht mal M$ schafft innerhalb seiner Produkte Homogenität. Da ist man innerhalb der KDE Familie bei weitem in einer homogeneren Umgebung unterwegs.
Ausgerechnet Windows und sich um nichts kümmern *Loooooooooooooooooooooooooooooooool*. Wenn ich alleine an die Geschichte mit Mr. Virus, seinen Trojanischen Pferden und die Würmer denke. Dann die dauernden Probleme dass Treiber nicht so funktionieren wie sie sollen oder dass sich Programme nicht wirklich sauber deinstallieren lassen oder ...
Wird schon schiefgehen!
Welche Distribution macht das?
> der sich dann als Notanker im grub anwählen lässt?
Es werden immer zwei installiert, der default und ein fallback.
> Das würde mich aber wundern. So viel Platz sollte im /boot doch
> eigentlich immer sein:-)
Sollte schon, aber mit dem fallback-image hat man schon einen
Rettungsanker. Zur Not kann man sich ja einen eigenen anlegen.
Welche Distribution macht das?
Alle mir bekannten in dem Sinne, daß der "alte" Kernel nicht gelöscht wird. Dann wird der Eintrag in Grub oder Lilo nicht gelöscht, sondern weiter vorgehalten.
Wenn Arch das nicht per default so macht, es ist ein Klacks, das selber zu machen. Das spart dann das Rauskramen der Boot-CD mit chroot und ähnlichen Späßen.
> wird. Dann wird der Eintrag in Grub oder Lilo nicht gelöscht, sondern
> weiter vorgehalten.
*kopfkratz* Meine SuSE- und Ubuntu-Zeit ist auch sehr lang her...
> Wenn Arch das nicht per default so macht, es ist ein Klacks, das selber
> zu machen.
Äh, das letzte Wort in meinem Posting ist ein Link um das ganze mit
Arch-Werkzeugen zu machen.
Arch-Werkzeugen zu machen
Wer klickt heutzutage schon auf Links ... *g*
Genau falsch, informieren bevor du rumpustest.
Es immer genau ein Kernel installiert, nicht mehr und nicht weniger. Der Fallback Eintrag bezieht sich auf die Fallback Initrd, die im Gegensatz zur normalen immer alle Module hat und daher auf jedem PC bootet. Mehr ist das nicht.
Bin auch vor circa 3 Monaten erst zu Arch Linux gewechselt und bin voll zufrieden. Kernel Updates sind keine Probleme... Bei mir hat sich sogar ein Problem durch das automatische Update-Script gelöst, das ich vorher nicht beseitigen konnte:-)
Nur dran denken /boot/ rw zu mounten, wenn man es per default als ro mountet. Da hilft aber auch ein bisschen Brain 1.0 und die Meldungen des Update-Scripts mit offenen Augen anzuschauen;-)
Bissl OT aber...gibts bei euch inzwischen signierte Pakete? Das war anno dazumal als ich mir das angesehen habe ein NoGo was ich schade fand.
(btw: es heißt Arch Linux, nicht Archlinux)
Schlimmer war das eine große Xorg update... und das auch nur bis es einen Wikieintrag dazu gab
Gentoo > Arch
Eigentlich läßt sich jede mir bekannte Distribution auch nur mit Kommandozeile betreiben, wenn man's denn möchte. Bzw. ohne graphische Werkzeuge.
Nett ist es natürlich, wenn man Eigenschaften eines Programmes braucht, die per Standard nicht aktiv sind. Ich erinnere mich düster z.B. an POP3-Unterstützung in mutt, die ich brauchte (mittlerweile nehme ich dafür einen externen POP3-client ...) und mir dann selber "reingebacken" habe.
Rein aus performance-Gründen würde ich eher nicht selbst kompilieren wollen. Das dürfte auf einigermaßen modernen Kisten keine größere Rollen spielen. Und auf älteren Kisten macht das Kompilieren nicht viel Spaß. Ich habe mal einen gentoo-Kernel auf und für eine{n|m} PII 450 gebacken (natürlich einen angepaßten - das Ding sollte ein Router werden. War damals natürlich schon uralt). Da war ich mit über einer Stunde dabei, iirc.
Lernen kann man bei gentoo in der Tat sehr viel, aber das geht bei Distributionen wie debian auch (wo ich jetzt gelandet bin).
LOL, nur eine Stunde?
. Ich habe mal ein Gentoo 1.4 auf einem Laptop mit Pentium 120 MHz kompiliert und weil ich es wissen wollte mit X, KDE und OpenOffice. Das hat selbst mit Tricks wie distcc mehr als einen Monat gedauert. Aber im Geschwindigkeitsvergleich mit Debian, Mandrake und Suse (absteigende Performance) war es das schnellste und im Gegensatz zu Suse gut benutzbar.
... debian ... (wo ich jetzt gelandet bin)
Ja da bin ich auch gelandet, nachdem ich vor dem Problem stand, meinen Hauptrechner (1 GHz) mit ca. 15 GB Software auf ne aktuelle libc zu hieven, was bedeutet hätte, dass ich ca. eine Woche nicht richtig hätte arbeiten können, war da ganz schnell ein Debian drauf.
Aber es ist trotzdem was anderes, als bei einer Binärdistrie ein Paket aus den Sourcen zu bauen, da das die Paketverwaltung nur rudimentär unterstützt:
Wenn du z.B. Paket X mit Unterstützung für Y kompilierst, musst du selbst dafür Sorge tragen, dass Y-libs installiert sind, bzw. die deps im Paket entsprechend anpassen.
Wenn du Paket A ohne Unterstützung für foo kompilierst, und B von A abhängt, musst du u.U. B auch neu kompilieren, bekommst das aber erst mit wenn B nicht mehr geht, sagen tuts dir keiner.
Usw. hier könnten noch mehrere Beispiele folgen..
Desweiteren musst du sämtliche Pakete auf hold setzen, sprich Binär-Updates derselben verbieten, was auch bedeutet du musst dich selbst um Sicherheitsupdates kümmern, andere von deinen Paketen abhängige Pakete werden evtl. auch nicht mehr geupdated, da sie die Abhängigkeiten in der neueren Version verlangen, usw.
Wer also sagt, dass Gentoo ggü. SRPM oder deb-src keinen Mehrwert hat, noch dazu gerade mit dem Beispiel der Useflags, hat keine Ahnung von Gentoo oder vom Paketmanagement im Allgemeinen, insofern bezweifel ich, dass du etwas über die Qualität der ebuilds sagen kannst.
Ich bin kein Gentoo-Freak, ich setze es nur noch auf wenigen Rechnern ein (bin auf Servern größtenteils auf Debian, und bei meinem Desktop auf arch, Bekannte/Verwandte Ubuntu), also ich will es hier nicht Gentoo über Gebühr schönreden, aber es ist immernoch ungeschlagen das flexibelste und anpassbarste Paketmanagement. Es gibt auch viele Momente wo ich Gentoo vermisse..
Keine Signierten Pakete ---> Unsicher?!
Bugreports stapeln sich seit MONATEN und werden nicht abgearbeitet (Erste Seite bei bugs.archlinux.org)
Programme sind BUGGY seit MONATEN im core (z.B. Blender, Mplayer)
Alpha Versionen in core (z.B. K3B)
Buggy Programme werden trotz Bugreport in core verschoben (z.B. Mplayer mit MKV).
kdemod für x86_64 kommt garnicht hinterher (z.B. bei 4.2.2 auf 4.2.3 hiess es, es gäbe nur eine Dev für x86_64!)
Ich überleg mir momentan wirklich ob ich nicht wieder zu Gentoo zurück gehe oder gar auf eine Distrubtion ausweiche die eine Firma dahinter hat.
Die Bugreportproblematik kann ich _nicht_ bestätigen. Auf meine wurde immer innerhalb einer Woche reagiert und 2 Wochen später wars gefixed..
Ich finds nur schade, dass keine VDPAU Unterstützung integriert werden wird.
Blender benutze ich nicht, aber inwiefern ist mplayer buggy? Bei mir spielt er noch alles ab
Das mit K3B war ein "Unfall", das sollte nie so im [extra] landen. Es ist ja auch fast unbrauchbar atm.
Momentan gibts mehr Devs, die x86_64 selbst nutzen, als i686 Nutzer. Daher sind idR die x86_64 Pakete momentan schneller da als die i686..
Bei Mplayer: http://bugs.archlinux.org/task/14491.
Bugreport wurde im 28. April eröffnet, trotzdem wurde am 18/19 Mai Mplayer mit dem Bug in extra verschoben.
Bei Blender: http://bugs.archlinux.org/task/12862.
Was bei Blender ganz bitter ist, ist die Tatsache das der "Bug" seit Januar bekannt ist, keiner ihn fix trotz Lösung und nicht mal update rausbringt.
Das Verhalten ist mir schon bei mehreren Paketen aufgefallen, also das trotz Wochen alter Bugreports ein Paket mit Bug in core, extra oder community landet.
http://bugs.archlinux.org/task/12953
Mich nervte viel mehr, dass kein OSD-Menu Support drin war.
2. Pakete wie Mplayer oder K3b werden *nie* in core "erscheinen", da in core nur die nötigstens Pakete für einen Betrieb drin sind. Nichtmal X.Org ist in core (es ist in extra).
Kdemod ist und bleibt kdemod, nur die darauf basierende LiveCD heisst Chakra. Ich bin dabei übrigens einer der x86_64 Packager. Es gab eben Probleme mit einem Buildserver.. In absehbarer Zeit wird das alles kein Problem mehr sein.
solange meine Systeme genug Leistungsreserve haben, setze ich data=journal ein.
Wer weiß *genau* welche Gründe zu der Entscheidung geführt haben?
writeback = mehr speed.
Guck dir doch mal XFS, JFS, ZFS etc. bezüglich "delayed allocation" an.
Da kanns genau so zu Datenverlust kommen und wer kein wrtie_back will kann doch einfach mit der mount-option das alte Verhalten herstellen.
es gibt keinen Grund, die Software eines Schwerverbrechers nicht einzusetzen, solange diese unabhängig von der Tat entstanden ist, und das ist alleine wegen der zeitlichen Reihenfolge der Fall.
Andererseits gibt es keinen technischen Grund Reiser 4 einzusetzen.
Gruss,
Kay
(Nein, Deine persönlichen Erfahrungen sind da nicht sonderlich ausschlaggebend - was weiß ich, wie Du Deine Kisten quälst ...)
kann sein das man als familienvater ein dickeres fell hat, aber mir persönlich würde der hals platzen wenn auch noch innerfamiliär die sorglosigkeit/dummheit anderer mir arbeit machte.
Wem stört es, dass das ext3 bleibt wie es ist? Die Performancesteigerung die Umstellung kann man später auch noch machen, wenn man es benötigt. Jetzt muss man beim kernelupdate erst noch von hand eingreifen, um genau die alte Funktionalität beibehalten zu können.
Wenn man ext4 noch optimieren will/muss bitte, aber bei ext3 sind derartige änderungen nur für den alles andere als willkommen. Dafür sehen dann ein paar Benchmarks in den Verkaufsprospekten der kommerziellen Distris besser aus.
Kennt jemand eine gute Anleitung (Schritt für Schritt) um einen Kernel unter Debian zu bauen? Ich finde zwar relativ viele Anleitungen, aber die unterscheiden sich zum Teil recht stark.
Und gibt es eine Seite wo man nachlesen kann für was die ganzen Optionen und Treiber bei den Einstellungen des Kernels stehen? Oder muss man sich das alles per Suchmaschine raus suchen? Bei den ganzen Einstellungen verliert man recht leicht den Überblick, besonders wenn man nicht weiß wofür alles steht.
Drück in make menuconfig ? und du wirst Hilfestellungen dazu bekommen, oft auch empfehlungen. Wenn du dann noch nicht sicher bist was du tun sollst oder nicht verstehst was es macht, benutz eine Suchmaschine oder nimm die Empfehlung.
Ich glaube kaum dass irgendjemand wirklich jede Option im Detail im Linux Kernel versteht.
Mit Deiner Vorgehensweise bist Du aber definitiv auf dem direkten Weg dahin!
Vielleicht sollte man doch eher ein "make oldconfig" nutzen - oder macht es Spaß, drei Stunden lang alle möglichen Config-Optionen einzeln abzuwägen?
Im Normalfall nimmt man einen laufenden Kernel und ändert beim Rebuild (einer evt. neueren Version) ein, zwei, drei Optionen ab.
Das ganze ist schlicht und einfach nur ein (jedenfalls unter Debian)
tar xjf linux-NEU...tar.bz2
cd linux-NEU...
cp /boot/config-MOMENTAN .config
make oldconfig
make-kpkg clean
make-kpkg [--initrd....] kernel_image
dpkg -i ../linux-image.....
Entpacken in /usr/src
make menuconfig
Treiber die zwingend benötigt werden als Built-in (*), alle anderen wenn du magst als Modul (m)
Was die Treiber etc bedeuten ---> Siehe HELP oder kenne deine Hardware.
make && make modules_install
Kernel Kopieren nach /boot und grub anpassen.
http://www.debian.org/releases/stable/ia64/ch08s06.html.de
Ich denke, dass die Entscheidung Windows 7 oder Linux bei den meisten immer noch eine Frage dessen ist was sie haben möchten, was sie gewohnt sind oder was ihrer Ansicht von einer Freien Welt am besten passt. Mir würde auf Windows inzwischen (egal wie weit entwickelt es sein mag) der fvwm und all die gnu-tools fehlen. Als ich noch ausschließlich mit Windows gearbeitet habe, war mir W2k sehr lieb und stabil... von Armutszeugnis also keine Rede.
Ein großer Vorteil von Windows ist seine Homogenität in der Oberfläche und Programmen. Da wird Linux nicht mithalten können. Oder wie willst du einem Anwender erklären, das es dutzende Widget Toolkits gibt, alle samt mit anderem Aussehen und Verhalten.
Frage am Rande: Zum aktu. Ubuntu und der Nvidia Treiber. Ich besitze ein Onboard Grafikkarte(7???) und bekomme ständig schwarze Bereiche(immer in der Nähe von Widgets) innerhalb meiner Ausgabe. Dies passiert häufig, der Treiber ist closed source. Normal? Abhilfe?
Warum soll ich das nem Anwender erklären (ausser er wills wissen)? Ein reiner Anwender der keine Ambitionen hat das System zu verstehen/zu verändern/sonstwas bekommt z.B. ein Ubuntu und fertig. Dank gleicher Qt und GTK-Themes merkt er ja nichtmal dass es verschiedene Toolkits gibt.
> Frage am Rande: Zum aktu. Ubuntu und der Nvidia Treiber. Ich besitze ein Onboard Grafikkarte(7???) und bekomme ständig schwarze Bereiche(immer in der Nähe von Widgets) innerhalb meiner Ausgabe. Dies passiert häufig, der Treiber ist closed source. Normal? Abhilfe?
In der Nähe von Widgets werden möglicherweise Schatten/transparente Bereiche von den 3D-Funktionen der Graka gezeichnet, und das ist evtl. bei deinem Treiber buggy. Temporäre Abhilfe könnte das Abschalten der Compiz-Funktionen sein. Sorry hab gerade kein Ubuntu zur Hand, sonst würd ich dir sagen wie das genau heißt..
CATIA V5, SAP, Microsoft Office 2007, MS Project, MS Internetexplorer 7, MS Mediaplayer ... möchtest Du noch mehr? Nicht mal M$ schafft innerhalb seiner Produkte Homogenität. Da ist man innerhalb der KDE Familie bei weitem in einer homogeneren Umgebung unterwegs.