Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 19 reacties
Bron: The FreeBSD Project, submitter: Hel Gast

De leden van het Freebsd Release Engineering Team hebben in de 6.x-tak van Freebsd een nieuwe versie uitgebracht met 6.3 als het rugnummer. Het besturingssysteem heeft een lange geschiedenis achter de rug van Freebsd 1.0 uit december 1993 dat in de loop der jaren uitgegroeid is tot wat het nu is. Voor meer gedetailleerde informatie over het hoe en wat van Freebsd verwijzen we jullie door naar het Nederlandse handboek. De aankondiging ziet er als volgt uit:

Version 6.3:

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.3-RELEASE. This release continues the development of the 6-STABLE branch providing performance and stability improvements, many bug fixes and new features. Some of the highlights:
  • KDE updated to 3.5.8, GNOME updated to 2.20.1, Xorg updated to 7.3
  • BIND updated to 9.3.4
  • sendmail updated to 8.14.2
  • lagg(4) driver ported from OpenBSD/NetBSD
  • unionfs file system re-implemented
  • freebsd-update(8) now supports an upgrade command
For a complete list of new features and known problems, please see the online release notes and errata list, available at:For more information about FreeBSD release engineering activities, please see here. The FreeBSD Security Team intends to support 6.3-RELEASE until January 31st, 2010.

Dedication:

FreeBSD 6.3-RELEASE is dedicated to the memory of Dr. Jun-ichiro Hagino, known throughout the Internet community as itojun, for his visionary work on the IPv6 protocol and his many other contributions to the Internet and BSD communities.
Moderatie-faq Wijzig weergave

Reacties (19)

freebsd-update(8) now supports an upgrade command
Dit is waar ik al even op zat te wachten... Binaire updates van het base system konden al binnen een security branch van dezelfde minor versie, maar nu dus ook tussen minor of major versies updaten. Tuurlijk, de klassieke make kernel/buildworld/installworld routines werken prima, maar bij het bijhouden van een x aantal machines werkt het vervelend omdat je 'officieel' je world moet installeren in single user mode, en er naar mijn mening toch nog teveel handelingen voor nodig zijn.

Een simpelere administratie van het systeem weegt voor mij wel op tegen het kunnen zetten van compiler flags (waar je alleen echt wat van merkt bij specifieke applicaties als mutlimedia processing of rendering etc, en die compileer je gewoon nog steeds uit de ports tree met je rigoreuze compiler flags)...

Het enige 'vervelende' is wellicht dat je bij binaire upgrades eigenlijk de standaard GENERIC of SMP kernel moet gebruiken, dat kost je meestal een paar megabytes aan RAM omdat er een hoop in zit wat je niet gebruikt (als ik een eigen kernel compileer met alleen de dingen voor mijn systeem, gaat deze van ongeveer 6 naar zo'n 2 MB).

Ik wacht overigens op 7.0... lekker met ZFS spelen :P (voor wat ik gezien heb in 7.0-RC1 werkt dat vrij goed)
Tuurlijk, de klassieke make kernel/buildworld/installworld routines werken prima, maar bij het bijhouden van een x aantal machines werkt het vervelend omdat je 'officieel' je world moet installeren in single user mode, en er naar mijn mening toch nog teveel handelingen voor nodig zijn.
teveel handelingen kan ik een klein beetje inkomen (hoewel een onliner bij mij nog nooit gefaald heeft), maar voor <x> machines heeft 't me nog nooit veel problemen opgeleverd. Ik deed upgrades voor tientallen machines verspreid over 2 dagen met 1 centrale /usr/src en /usr/obj tree. Kwestie van op iedere machine een correcte make.conf hebben, en als je veel identieke bakken hebt is dat dus ook maar 1 keer de kernel bouwen.

een upgrade van FreeBSD, zelfs een major (dus bijvoorbeeld van 6.x naar 7.0) komt neer op:

cd /usr/src
make buildworld
make buildkernel
make installworld
make installkernel
mergemaster
reboot
Het enige 'vervelende' is wellicht dat je bij binaire upgrades eigenlijk de standaard GENERIC of SMP kernel moet gebruiken, dat kost je meestal een paar megabytes aan RAM omdat er een hoop in zit wat je niet gebruikt
Mikken ze nu nog steeds niet alles in modules default? Kost je ietswat meer tijd bij het booten, maar je kernel laadt dan ook verder helemaal geen overbodige meuk? Nu zul je aan mijn reactie hierboven al wel gemerkt hebben dat ik sowieso altijd custom static kernels bouw :)

[Reactie gewijzigd door arjankoole op 20 januari 2008 21:35]

Hm ik dacht dat het wel aangeraden werd om eerst de kernel te installeren en na een reboot pas de userland... omdat een rotte kernel (of een niet lekker lopende oude userland i.c..m een nieuwe kernel) wat eenvoudiger te herstellen is dan een kapotte userland (je hebt een backup van de oude kernel in /boot/kernel.old).

Dat is ook hoe het proces in de nieuwe freebsd-update methode nu gaat, bij een minor/major release upgrade doet ie dit:

- installeert eerst alleen de nieuwe kernel en vraagt hij je om te rebooten
- bij een nieuwe aanroep na de reboot installeert ie vervolgens de nieuwe userland. - bij een major update 6.x --> 7.0 vraagt ie vervolgens nog of je even al je ports wil herinstalleren i.v.m binaire interface-verschillen in de nieuwe libraries... daarna verwijdert ie bij een nieuwe aanroep de oude libraries van de oude major versie.

P.S: bij de compileermethode stond mergemaster -p trouwens ook nog tussen het lijstje, en make delete-old en make delete-old-libs voor het verwijderen van bestanden die niet meer bestaan in de nieuwe release.

Een gedeelde /usr/src en /usr/obj over NFS o.i.d. heb ik zelf noot gebruikt, dat is inderdaad wel iets wat tijd kan besparen (maar 1 keer de cvsup en compileersessies)
Mikken ze nu nog steeds niet alles in modules default? Kost je ietswat meer tijd bij het booten, maar je kernel laadt dan ook verder helemaal geen overbodige meuk? Nu zul je aan mijn reactie hierboven al wel gemerkt hebben dat ik sowieso altijd custom static kernels bouw
Ik bouw altijd een minimale kernel (eentje waarbij je zoveel mogelijk dingen in modules zet i.p.v. in de kernel image), en laad per machine de relevante modules vanuit /boot/loader.conf in de bootloader... als de machines niet al teveel van elkaar verschillen, kan je dan dezelfde kernel bakken en de loader.conf wat aanpassen op elke machine. Gaat natuurlijk niet werken als een machine single core is, en de andere dual core, of iets dergelijks.

Ik heb nog niet bekeken of ze nu de GENERIC kernel minimaal hebben gemaakt in 6.3 en 7.0... al wordt die ook voor de installatie media gebruikt als ik me niet vergis, en daar is een dergelijke jumbo kernel wel handig voor de hardwaresupport tijdens de installatie...

[Reactie gewijzigd door Sfynx op 20 januari 2008 21:55]

Hm ik dacht dat het wel aangeraden werd om eerst de kernel te installeren en na een reboot pas de userland
Klopt, dat is het advies al zolang ik FreeBSD gebruik (sinds 2.2.8), ik heb het alleen nog nooit fout zien gaan bij mezelf en bij anderen, op de meest uiteenlopende hardware.

Vandaar doe ik altijd een : "don't bother". Mocht 't een keer fout gaan, dan heb ik toch wel binnen een paar minuten gerepareerd.
ZFS zal zelfs in 7.0-RELEASE nog zwaar experimenteel zijn helaas. Ik houd al een tijdje de CURRENT mailinglist in de gaten, en er zijn nog steeds flinke problemen af en toe. Sowieso zal ZFS op i386 afgeraden worden, en misschien zelfs disabled, op AMD64 zijn er al minder problemen. Sowieso krijg je met flinke belasting (dikke rsyncs enzo) kernel panics, je moet zelf wat system settings tweaken, en hopen dat je bak niet crashed. Zelf geen ervaringen mee, maar dat leert de mailinglist. :(
Hm tja, waar dit filesystem me heerlijk op lijkt is een fileserver... dus het moet wel een beetje blijven werken :D Vooral de transactionele integriteit, interne compressie, eigen mirroring/raid faciliteiten en het compleet overbord gegooide concept van partities spreken me echt aan. En de manier van beheren, zonder downtime dingen aanpassen/resizen die vroeger echt niet op die manier konden zonder reboots of downtimes.

Bij het laden van de zfs kernel module werd het ook wel vrolijk gemeld dat het nog experimenteel is, ik ben benieuwd hoeveel tijd er nog overheen gaat voordat ik het voor serieuze dingen kan inzetten :)
Nog geen KDE 4? Alhoewel ik dat ergens wel logisch vind omdat BSD, naar wat ik denk toch, minder experimenteel is dan linux. Ook ligt de nadruk bij BSD waarschijnlijk meer op de veiligheid, en die is moeilijker te garanderen met gloednieuwe software.

[Reactie gewijzigd door IveGotARuddyGun op 20 januari 2008 11:39]

Vergeet niet dat je niet pers vast zit aan KDE 3, op den duur zal KDE4 gewoon in ports zitten en zou je gewoon moeten kunnen upgraden (wel even /usr/ports/UPDATING lezen uiteraard :D). En dat geldt ook voor alle software, ports is over het algemeen vrij up-to-date dus het is geheel mogelijk om de nieuwste versies van software te gebruiken.

Alleen vlak voor een release lopen de ports soms een beetje achter omdat men alles stabiel wilt maken voor een release.
KDE4 was ook nog niet uit toen 6.3 al in de code freeze zat. Bovendien is KDE4 wel te installeren (vanuit ports of packages), maar de ondersteunde versie is dus gewoon 3.5.7.
Als je echt naar een 'FreeBSD desktop' aan het zoeken bent, zou je DesktopBSD of PC-BSD eens kunnen proberen. Deze laatste heeft ook compizFusion, etc. geintegreerd (mss heeft DesktopBSD dat ook wel, maar daar ben ik niet zeker van).

[Reactie gewijzigd door Theraven1982 op 20 januari 2008 12:33]

..Veiligheid natuurlijk maar met de "bleeding edge" is ook de stabiliteit en de invloed van de software op elkaar nog niet zo duidelijk. En daar komt nog bij dat het wat tijd kost voor een complex Linux-pakket als KDE met de nodige scriptjes en patches cht goed werkend gekregen is op FreeBSD.
Een complex Linux-pakket als KDE?
In tegenstelling tot wat sommige mensen schijnen te denken, draait niet alles in de wereld om linux.
KDE is opgezet om te draaien op allerlei UNIX en BSD varianten. Er hoeft dus helemaal niets verbouwd te worden om het op freebsd aan de praat te krijgen.

Op de kde homepage staat ook het volgende

KDE4's full-featured applications run natively on Linux, BSD, Solaris, Windows and Mac OS X
Alleen in kdebase3 zitten al 10 patches om het aan de gang te krijgen onder FreeBSD. Dus het is inderdaad niet helemaal triviaal om KDE native te draaien, KDE wordt zeker wel primair ontwikkeld op n vr Linux. (Natuurlijk is FreeBD koel genoeg om KDE-4 zonder al te veel gedoe in Linux-compatibility te draaien maar of je daar nou blij van wordt..)
(Natuurlijk is FreeBD koel genoeg om KDE-4 zonder al te veel gedoe in Linux-compatibility te draaien maar of je daar nou blij van wordt..)
FreeBSD voert linux binaries sneller uit dan Linux het zelf kan. Dus echt een groot probleem is het niet.

Het is alleen te zot voor woorden om 't zo te doen en een teken van luiheid.
KDE4 is nog geen vervanging voor KDE3. Teveel bugs en nog niet alles is geimplementeert. De makers van KDE hebben dit ook al duidelijk laten blijken.

Zelf al even KDE4 geprobeerd, maar, binnen 5 minuten een desktop freeze. Gaat niet echt werken in een productie-omgeving.
Iemand enig idee waar 7.0 blijft? Volgens de schedule had de nieuwe release er al een paar dagen moeten zijn toch?
Er zijn nog een aantal openstaande issues voor 7.0
En, zoals altijd, houden ze zich niet zo strak aan deadlines. De focue ligt op stabiliteit en betrouwbaarheid en niet op de release date.
Dit is iets waar veel software fabrikanten een voorbeeld aan kunnen nemen.
Iemand enig idee waar 7.0 blijft? Volgens de schedule had de nieuwe release er al een paar dagen moeten zijn toch?
Zoals doctormetal uit opmerkt: uitstel om de laatste kreukels glad te krijgen. De prerelease is er al een tijdje, en ik heb eigelijk al geen serieuse problemen gemerkt sinds Beta 3.

mijn huidige maildoos:
[xxxxx@medusa ~]# uname -a
FreeBSD medusa.xxxxxxxxx.xxx 7.0-BETA4 FreeBSD 7.0-BETA4 #3: Tue Dec 11 12:44:09 CET 2007 root@medusa.xxxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/MEDUSA i386
Net even geupgrade van 6.2 naar 6.3. Weinig verschil te merken, maar ik kan me dan ook niet echt bugs herinneren van 6.2. :+
1 bug die er nog niet uit is, is dat ie Wireless Mouse+Keyboards wel herkent, maar alleen het keyboard kan gebruiken. Muis werkt niet. Op de mailinglists stond vorig jaar een gepatchde usm.ko, maar om 1 of andere reden zit die niet in 6.3 .

Voornaamste problemen die ik heb gehad met 6.2 waren niet zozeer bugs, maar meer problemen in de onderliggende structuur die voor problemen zorgde. USB-stack in combinatie met externe USB-HD's. Performance is op zijn best matig te noemen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True