Auf dem Weg zu FreeBSD 10.0

Ich habe nur die upgrade notes von Beta zu Beta gesehen, und die waren ja bisher teils recht haarig. Aber möglicherweise wurden ja bereits die schlimmsten Upgrade Bugs gefunden.
 
Sag mal gibts eine Prioritätenqueue für Port-Updates? Oder liest jemand hier mit, der Commi-Rechte hat?

Ich kriege jeden Tag E-Mails dass meine Ports auf 10.0 nicht durchbauen (wegen Clang). Deswegen habe ich natürlich schon ein Update-PR geschrieben, das wird aber nicht committet :grumble: Die kriegen ja auch nicht jeden Tag die Mails!!
 
Mal noch ein paar Info's zu Bhyve welche ich auf "phoronix.com" gelesen habe:
Code: 
- Linux x86_64 and OpenBSD 5.4 guest support in Bhyve.

- There's a 16 virtual CPU maximum limitation right now but as much RAM as needed can be devoted to guests.

- The FreeBSD hypervisor features support for VirtIO net/block, AHCI SATA/ATAPI interfaces, and serial PUC/LPC device support.

- Future operating systems to be supported for guests include Illumos and Microsoft Windows.

- Other future work includes AMD SVM 10.1 support, VT-d IOMMU integration, transitioning to UEFI support, suspend/resume/live-migration support, and loadable device models and back-ends.

http://www.phoronix.com/scan.php?page=news_item&px=MTUwODY

Wow da wurde sehr viel Arbeit hineingesteckt! :)
 
h^2 schrieb:
Ich finde ja auch, dass man auf allen Ports, die auf 10.0 nicht bauen, vorher aber scon gingen, automatisch ein USE_GCC= any hätte setzen können, es damit probieren und das dann automatisch dem Port hinzufügen. Würde sicherlich 90% der momentan nicht-bauenden Pakete funktionabel machen...
Zum Vergrößern anklicken....
Es gibt mehr Probleme mit libiconv und der neuen libc++. Und die lassen sich in der Regel nicht mit einem USE_GCC=any fixen.
 
Yamagi schrieb:
pkg-test.freebsd.org ist übrigens überholt. Bis auf das sehr zeitnah kommende Packet Signing steht das offizielle Repo, es ist nur noch nicht angekündigt. Daher sollte man nun http://pkg.freebsd.org/${ABI}/latest setzen. Die URL wird sich übrigens mit pkg 1.2 noch mal ändern, da das Protokoll auf pkg+http:// geändert wird. Es soll Verwirrung verhindern.
Zum Vergrößern anklicken....

Nachdem ich heute auf einer 9.1/64-Installation mit alten Packages erstmal alle alten Packages mit 'pkg_delete -a' vernichtet habe, weil in einem anderen Post das gegenüber der Methode 'pkg2ng' empfohlen wird, musste ich jetzt mit Entsetzen feststellen, dass diese tolle Test-URL weder die Pakete gnome2 noch gnome2-lite hat. Wenigstens klappte 'pkg install xorg'. Einige Brocken wie nautilus und gdm konnte ich auch mittels pkg install vorinstallieren, doch jetzt muss ich mittles 'portmaster x11/gnome2-lite' den Rest installieren, um wieder einen funktionierenden Desktop zu bekommen. Und 'portmaster --packages-if-newer' funktioniert mit den neuen Packages auch noch nicht. Na super, wie können zwei so wichtige metaports wie gnome2 und gnome2-lite da einfach fehlen? Da hätte ich doch lieber mal ein 'pkg2ng' gemacht...
 
@cabriofahrer: Gibt's mate denn schon als Paket? Das ist ja vor ein paar Tagen in den Ports aufgeschlagen. Spätestens am Mittwoch sollte es dann mitgebaut werden.
 
Warum sollte ich jetzt FreeBSD 10 ausprobieren? Das System ist doch kein Selbstzweck für mich.
Ohne Anwendungen, egal ob aus Ports oder als Pakete, ist es sinnlos.
Ich will damit arbeiten. Die Zeit der Bastelei, sie hatte ihre guten Seiten, ist nun vorbei.
 
Code: 
# grep "grogolz, du musst FreeBSD 10 ausprobieren" $THREAD
exit 1

Auf unter pkg.freebsd.org gibt's übrigens ca. 21.000 fertige Pakete (von ca. 24.000 Ports).
 
Ich werde FreeBSD 10 ausprobieren. Das ist klar. Nur nicht mehr in diesem Jahr. Ich habe dann die Absicht nur noch mit Paketen zu arbeiten.
Bisher habe ich alles aus den Ports gebaut. Große Probleme gab es dabei nicht dank portmaster und pkg_libchk. Auch nicht nach dem
Umstieg auf pkg.
 
Wer hat denn FreeBSD 10 produktiv im Einsatz und ist weg von 9.x und 8.x? Wo sind die Hürden? Was ist zu beachten?
Pure Neugier meinerseits.
 
lme schrieb:
@cabriofahrer: Gibt's mate denn schon als Paket? Das ist ja vor ein paar Tagen in den Ports aufgeschlagen. Spätestens am Mittwoch sollte es dann mitgebaut werden.
Zum Vergrößern anklicken....

Nein, "mate" wird durch ein 'pkg install mate' noch nicht gefunden. Konnte aber wiegesagt mit portmaster letztendlich gnome2-lite installieren, funktioniert wunderbar. Welchen Vorteil hätte mate gegenüber gnome2?
 
Bitte beim Thema bleiben, bzw. wenn es weitere Details zu speziellen Desktops gibt diese getrennt diskutieren.
 
Offensichtlich setzt niemand zur Zeit FreeBSD 10 produktiv ein oder es gibt keine nennenswerten Probleme.
Letzteres wäre erfreulich und ich könnte PC-BSD auf dem Laptop wieder eine Chance geben wenn sie auf
FreeBSD 10 aufspringen sollten.
 
Es gibt schon ein paar Probleme. Zum Beispiel kannst du keine Jails älterer Versionen unter FreeBSD 10 bauen (jedenfalls nicht mit Tinderbox). Durch das neue make geht hier und da etwas kaputt. Der Rest betrifft vor allem die Ports, der neue C++ Stack wirkt sich hier stärker aus als der Compiler-Wechsel.

Fuse zum Beispiel funktioniert tatsächlich wieder. Smbnetfs, sshfs ... geht alles wieder.

Bei der Performance ist mir auch noch nichts unangenehmes aufgefallen.
 
Dank Yamagis Anleitung läuft seit Monaten fuse.ko aus FreeBSD 10 stabil in meinem System. :)
Eine feine Sache. Rsync und NTFS Altbestände vertragen sich wieder.

Werde mit dem Sprung auf FreeBSD 10 noch warten. In diesem Jahr wird es nix mehr. Meine Ports sind mir zu wichtig.
 
Ich weiß es nicht. Ich schrieb schon öfter, dass man meiner Meinung nach mit 10.0 gern noch bis in den späten Herbst hätte warten können. Einfach um den Abstand zwischen 9.0 und 10.0 etwas größer zu ziehen und einige interessante Dinge noch eingehen zu lassen. Auf der anderen Seite ist es aber nun so, dass man immer auf interessante Dingen warten kann und irgendwann ins kalte Wasser springen muss. So ist es auch mit den Ports. Man hätte noch 1000 Jahre können und munter Mails mit Bitten seine Ports zu fixen schicken können, es wäre trotzdem nichts passiert. Erst der Druck durch das nahende Release und das unablässige Gemoser diverser Nutzer sorgt dafür, dass Maintainer ihren Mist in Ordnung bringen und Dritte Patches schicken. Das sehen wir auch an anderen Fronten. Stage-Dir Support entwickelt sich gut, weil bapt@ durch seinen Massencommit die Leute aufgeschreckt und in die richtige Richtung gestoßen hat. Die Anzahl in Poudriere nicht bauender Ports ist in den letzten Wochen deutlich gesunken. Und so weiter. Das ist eben auch die Crux mit .0-Releases. Solange es nicht released ist, will kaum einer testen und notwendige Anpassungen vornehmen, man dreht sich im Kreis. Wenn es released wurde, wird kurz über Bugs geschrieen, dann geht aber die Commit-Orgie los und sofort wird das Gras viel grüner.

Das mal vorweg gesagt, bin ich bisher mit 10.0 sehr zufrieden. Waren 8.0 und 9.0 gegen Ende der Betaphase noch ziemlich wackelig und im finalen Ergebnis ziemlich verbuggt, kann ich mich über 10.0 nicht beschweren. Ich selbst hatte trotz mehrere Testmaschinen und langer Lasttests bisher keine Probleme und auch auf den Mailinglisten ist es erstaunlich ruhig. Sicher stehen da hauptsächlich zwei Gründe hinter. Die bessere Mergestrategie des neuen Release Engineering Teams, welche problematische Commits verhindert. Zum Beispiel wurde der obligatorische "Inte Commit" dieses mal abgewürgt, bevor alle Intel-NIC-Treiber in den Orkus gingen. Und dann die Entscheidung, den Codefreeze am Ende des Sommers, der traditionell ruhigsten Zeit zu beginnen und damit die "Regenphase" etlicher Last-Minute-Commits direkt vor dem Freeze abzuschwächen. 10.0 ist das erste .0-Release seit langer Zeit, dem ich nicht kritisch entgegen sehe.

In meinen Tests ist 10.0 übrigens deutlich schneller als 9.2. Auf kleinen Kisten 2 bis 4 Prozent, sicher hauptsächlich durch Clang. Auf dicken Eisen aber schon mal >10%. Hauptsächlich durch die Verbesserungen am VM-Subsystem und weiterer Mikrooptimierung kritischer Codepfade. IO ist teilweise im Bereich mehrerer 100% schneller und könnte sich in 10.1 durchaus nochmal verdoppeln. Der IO-Krüppel FreeBSD steht plötzlich teilweise sogar vor Linux. Was allerdings kaum mehr praktische Relevanz hat.
 
Ich habe auf meinem Thinkpad X200s mir auch eben 10.0 Beta 3 aus den Sourcen geholt, Kernel und Welt gebacken und es läuft alles wie gewohnt...

Alleine finde ich kein fertiges Paket für wine mehr ;) Aber das könnte ich mir auch selber basteln mit einer i386 Jail. Libreoffice und gimp vermisse ich beim pkg Repository leider auch. Ansonsten habe ich dann auch gleich den Umschwung von Ports zu pkgng gemacht und das was nicht da war via Ports gebaut, bisher nur gimp und ein, zwei andere kleine Sachen. Libreoffice brauch ich auch nicht unbedingt, Abiword und so tut's auch.
 
Ich hatte dbn@ mal mal gefragt wann er pkg fuer 10 baut. Ich schreib hier einfach mal seine Antwort rein.

The production of FreeBSD 10 packages stopped due to incompatibility of running a FreeBSD-10 jail on a FreeBSD-9 system (although not officially supported, this worked for quite a while, and still does for most system calls). Currently my systems are down and I need to rewrite the scripts I use to maintain them. Once this is done I will migrate to FreeBSD 10 and start publishing packages for that. As to the time frame, I cannot comment.
Zum Vergrößern anklicken....
 
Die Folien, auf die ich mich bezogen hatte, finde ich nun partout nicht. In denen war ein schönes Diagramm, was FreeBSD 9.x mit damals noch 10-CURRENT und Red Hat gegenüber stellte. Aber sogar noch deutlicher sind diese hier: http://people.freebsd.org/~mav/camlock.pdf Step 1 und Step 2 sind in FreeBSD 10.0, Step 3 leider nur in 11-CURRENT. Wahrscheinlich wird er Teil von 10.1 werden.

EDIT: Wer lange sucht, wird endlich fündig - http://www.bsdcan.org/2013/schedule/attachments/242_BenchmarkingFreeBSD.pdf
 
Eines der Probleme das FreeBSD auf dicken SMP Boxen gequält hat waren die mapped I/O Puffer. Die Puffer für I/O wurden im virtuellen Adressraum des Kernels hinterlegt das ist zwar bequem, aber hat den Nachteil den TLB aller MMUs synchronisieren zu müssen. Unter AMD64 bedeutet das IPI zuversenden an alle Kerne. Die Lösung ist einen lokalen Adressbereich pro Kern zu definieren und diesen als I/O Puffer zu verwenden. Dieser Puffer wird bevorzugt nur von dem lokalen Kern verwendet. Ist das nicht möglich so wird er umgemapped in den globalen Adressbereich. Damit dies möglichst selten bis nie passiert müssen die Treiber angepasst werden. Die Treiber für AHCI und einige gängige SAS HBAs wurden schon angepasst.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben