Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NixOS 14.12 ist erst die dritte Veröffentlichung dieser Distribution. Das Herzstück – der Paketmanager Nix – wird aber bereits seit 2003 entwickelt, wo er im Rahmen einer universitären Studie an der Universität zu Delft entstand. NixOS macht sich dessen teils unorthodoxe Arbeitsweise zunutze.
Die Verlinkungen der bin und lib Verzeichnisse gibt es aber auch schon in anderen Distributionen seit einer Weile, beispielsweise arch verwendet das. Das build System ist natürlich interessant, ich frage mich allerdings, wie verschiedene Pakete gleichzeitig eingebunden werden, die symlinks nach /usr/bin würden dann ja einen Konflikt produzieren.
@offtopic Diese atomaren updates finde ich sehr spannend. Per Hand müsste sich das doch auf Systemen mit btrfs einfach realisieren lassen: alias update='brtfs subvolume snapshot root root-update-$(date) && <update>'
Mich interessiert das Feature, dass einem Rezepte geboten werden, mit deren dann eine Applikation/Paket gebaut wird.
Weiß jemand, wie viel das Selbstkompilieren bringt? Bemerkt man den Unterschied auf einem alten Pentium4 eher als auf einem i7? "Lohnt" sich das Kompilieren letztendlich?
Mich interessiert das Feature, dass einem Rezepte geboten werden, mit deren dann eine Applikation/Paket gebaut wird.
Weiß jemand, wie viel das Selbstkompilieren bringt? Bemerkt man den Unterschied auf einem alten Pentium4 eher als auf einem i7? "Lohnt" sich das Kompilieren letztendlich?
Automatische Optimierungen durch den Compiler bringen selten etwas wenn der Quell-Code nicht dafür ausgelegt ist. Performance lässt sich selten bis gar nicht steigern.
Der einzige unterschied beim compilen ist die Zeit. Ein P4 brauch halt länger als ein neuer i7. Das Ergebnis ist aber bei beiden gleich, vorausgesetzt die Argumente sind gleich.
Das gleiche/aehnliche Prinzip bringt auch Arch mit seinem AUR bzw. den Quellen mit, es bietet dabei binaere Dateien an aber auch das selbst bauen aus den sources wenn das gewuenscht ist (fuer core/extra/common hab ich das jetzt noch nie explizit probiert, soweit ich weiss sollte das aber auch gehen).
AUR ist hierbei ein von Usern gepflegtes Repository bei dem ein User ein "Rezept" geschrieben hat um besagtes Paket ans laufen zu bekommen. Ich hatte dort auch mal einen mcabber (client basiertes jabber program) gepatched weil es mit den gepflegten binaries mit manchen servern nicht wollte.
Der Geschwindigkeitsvorteil ist dabei wohl eher zu vernachlaessigen, viel spannender ist zumindest bei Arch das man schnell an patches ran kommt und sollte man selbst einen patch haben diesen leicht teilen kann. Der Nachteil wie so immer bei User gepflegten Dingen, immer schoen nachschauen woher das PKGBUILD seine Daten zieht und was es damit anstellt, wir wollen ja nicht das jmd. anders als die NSA mithoert
@Cool Master
Ich glaube er meint einen Unterschied beim Ausfuehren des fuer den P4 bzw. i7 optimierten Programs nach dem compilen. Imho ist das eher zu vernachlaessigen, vllt. merkt man bei anspruchsvollen Programmen etwas aber bin mir nicht sicher ob der Mehraufwand sich lohnt.
Vllt. bei Gentoo wo das gesamte System selbstkompiliert wird und entsprechend nur die Flags gesetzt sind um alle Programme auf dein System zu muentzen, war mir aber immer doch etwas zu viel stress. So bin ich bei Arch haengengeblieben, das beste aus beiden Welten sozusagen!
Ja genau, für mich interessant ist es zu wissen, ob meine Programme nach dem Selbstkompilieren schneller laufen oder kein Unterschied zu merken ist.
Sowohl Cool Master, floTTes als auch du haben ausreichend Information gegeben. Schade eigentlich, aber trotzdem ist die Distribution interessant, wenn einem die Möglichkeit gegeben wird, eine Applikation mehrmals installiert zu können. Gibt doch genügend Situationen, in denen man verschiedene Versionen eines Programms benötigt.
ne klar noch ne Distri
schlecht eingedeutscht etc. schade um den Zeitaufwand
wird Zeit dass Linus mal selber ne Distri macht und alles aus einem Guss daherkommt
Ja es macht kein großen Unterschied. Am ende kommt es auf die CPU an und wie viel Leistung diese pro MHz bzw. GHz hat. Kurz es kommt einfach auf die Architektur der CPU an.
Der Sinn des kompilierens auf der Zielplattform sollte ja eben die durch die individuellen Compiler-Flags hervorgerufenen Optimierungen am Binary sein, die eben genau auf die vorhandene Hardware gemünzt sind. Dadurch sollte das System theoretisch effizienter laufen.
ne klar noch ne Distri
schlecht eingedeutscht etc. schade um den Zeitaufwand
wird Zeit dass Linus mal selber ne Distri macht und alles aus einem Guss daherkommt
Das wird uns deutschen sicher helfen, die is dann auf finnisch und beinhaltet nur den Kernel oder wie hast du dir das vorgestellt?
Und je mehr Auswahlt umso besser, is ja nicht so das dich jmd zwingt ne distri zu verwenden und patches/fixes kommen GNU/Linux im allgemeinen zu gute egal aus welcher distri sie jetzt kommen ...
Na ja in der Theorie tut es das sicherlich auch und man kann es in Becnhmarks messen aber ich denke doch am ende von Tag spielt es keine Rolle. Das ist wie bei SSDs auch ob das nun ne SATA oder PCIe SSD ist spürt man nicht wirklich.
Na ja in der Theorie tut es das sicherlich auch und man kann es in Becnhmarks messen aber ich denke doch am ende von Tag spielt es keine Rolle. Das ist wie bei SSDs auch ob das nun ne SATA oder PCIe SSD ist spürt man nicht wirklich.
@ax156: nee sicher nicht. Linux bleibt im niedrigen einstelligen Bereich wenn man vom enduser ausgeht. Server natürlich schon. Eher wird mac OS X eine Alternative werden und diverse mobil Systeme. Linux fehlt einfach "die eine" distri die jeden überzeugt. Es bleibt ein Spielzeug für Nerds.
