Áttekintés: FreeBSD 6.1

FreeBSD

Egy kritikus hangvételű FreeBSD 6.1 elemzés született a minap egy olyan felhasználótól, aki évekig FreeBSD-t használt a desktop-ján, de a - szerinte - katasztrófális 5.x FreeBSD sorozat "hatására" Linux-ra váltott.
Az elemzésben megemlíti, hogy a bugos 5.x után a FreeBSD 6.0 véleménye szerint jó lépés volt a jó irányba, és hogy a 6.1-gyel a fejlesztők tartották ezt az irányt. A (némileg) rossz hír szerinte az, hogy a kisebb javítások dacára mindig nem tökéletes a 6.1.

A cikkíró szerint a legjobb jellemzés a 6.1-re az, hogy a 6.0 csiszolt verziója. A jó hír, hogy a 6.1 AMD64-es verziója jobb mint valaha. További jó hír, hogy a stabilitási gondok eltűnni látszanak, és a korábbi csomagkezelési problémái, amelyekkel a 6.0 telepítésekor találkozott, szintén megoldódtak.
Viszont a hálózati driverek frontján történt javítások ellenére problémája volt az Nvidia "nve" driverrel (timeout-ok AMD64-en), billentyűzet gondokkal küzdött a telepítés folyamán.

A cikk itt.

( trey | 2006. 05. 15., h – 09:51 )

Billentyűzet gondjaim nekem is voltak a 6.1 beta-val. A DL145-ös (AMD64) rendszeresen elfelejti egy idő után, hogy van rá billentyűzet (PS2) dugva. Most frissítettem 6.1-RELEASE-re, azóta nem voltam a pincében, de megnézem.

Viszont azt vettem észre, hogy a SCSI diszk sebesség javult. Egy diszken belüli Diszk - diszk közti nagy file másolásakor 45 MB/sec-et (folyamatosan, max. 46.28 volt minden tuning nélkül) is elérek. Eddig ilyet nem nagyon láttam. Vagy csak rosszul emlékszem?

--
trey @ gépház

( Yume | 2006. 05. 15., h – 10:20 )

Regi intel ppro-s gepen mar btxnel behal, tovabbra is, akarmit allitgatok biosban acpi/apm teren:)[masok erre tippeltek mikor kerdeztem milehet...]
Ill, desktopgepen amin minden mas boldogul a usb legacy/kvm switchen levo ps2(->usb a switch ofkoz) billenccsel telepiteskor rakellett bogoznom ps/2re a billt:), ugyanis telepiteskor mar nemreagalt hogy en kiakarom valasztani hogy usbbill-t kerekszepen;p
Amugy igy elso pillantasra tetszik [bar ez nem mervado, kb 1 honapja ismerkedek vele:P], gyors es stable [winhez/debianhoz/frugalhoz kepest].

Nekem régóta fennálló gondom a FreeBSD-vel a firewire busz inicializálása, amely bizonyos notebookokon "fatal trap"-hez vezet. Erről írtam is send-pr-t (ha menne az oldal, akkor meg is tudnám nézni itt, hogy kezdtek-e vele valamit).

A probléma többszörös véleményem szerint. Ugye adott a gond, boot-kor pánik, azaz telepíteni se tudom. Amit nem értek:

1.) miért kell a GENERIC kernelbe fixen, bootkor le nem tilthatóan (az OpenBSD-ben, hogy mindent le tudok tiltani) belefordítani a firewire-t? (válaszolok magamnak: gondolom a firewire-n keresztüli debug-hoz)
2.) ha a debug miatt, akkor miért nem tudnak egy failsafe kernelt tenni a telepítő CD-re, kiszedve belőle a koloncokat (usb, firewire, stb.) amivel fel lehetne húzni a rendszert, és utána tudna a paraszt fordítani magának egy saját kernelt? Mert most az az eljárás, hogy feltelepítek egy FreeBSD-t egy vmware-be, abban fordítok egy kernelt firewire nélkül, csinálok egy saját telepítő CD-t, azzal bootolok és telepítek.

Elég gáz ez így. OpenBSD-be egyenként le tudok tiltani minden problémás eszközt a bootkor az UCK-ban. Jó lenne ezt itt is megoldani.

A FreeBSD tesztelésekkor sok apró bosszantó hibával találkozik az ember, de nem jelent mindent a levlistára, mert azt tapasztalja, hogy

- vagy nem válaszol az érintett a levélre
- de ezzel szemben válaszol egy csomó olyan, akinek lövése sincs a problémáról (az időmet rabolja)
- ha válaszol is az érintett az első levélre, a másodikra már alig, de a következőkre nem nagyon, pedig _mindig_ szolgálok a kért adatokkal

Biztos nem bennem van a hiba, mert a bugreportjaim alapján más BSD-kben (DFly, OpenBSD) is született már (több) kommit (is), azaz aki akar, az tud velem együtt dolgozni a probléma megoldásán.

Na mindegy. Minden projektnek megvannak a maga gondjai.

--
trey @ gépház

"(ha menne az oldal, akkor meg is tudnám nézni itt, hogy kezdtek-e vele valamit)."

Közben megnéztem. Még mindig "open" státuszú. Pedig még a patch-et is mellétettem, ami javítja a hibát. Legalább annyit ugatnának vissza, hogy megnéztem a patchet, szar itt meg itt javítsd. Vagy megnéztem a patchet, jó, de ezért meg ezért nem commit-olom. De semmi válasz.

*sigh*

--
trey @ gépház

Tekintve, hogy Windows, Linux, (Open)Solaris, OpenBSD, DragonFly BSD (ebben már bekerült a patch), NetBSD (mondjuk ebben nincs a "gyári" kernelben firewire), operációs rendszereknek semmi bajuk nincs a firewire-rel, kicsi esélyt látok rá. De igazad van. Ettől még lehet szar. Mint ahogy az a gép is, amiben le lehet. Nem hinném, hogy az lenne a notebook-ok jóságának mérőszáma, hogy le lehet-e benne tiltani a firewire-t. Ha ez lenne, akkor szép számmal buknának meg a gépek a kritériumon.

--
trey @ gépház

Inkabb az az idegesito, hogy egy eleg draga berendezesbe egy ilyen nevetsegesen egyszeru funkciot nem implementalnak, szerintem jelentosen nem emelte volna meg a bios meretet es belefert volna a flash-be. Manapsag egyre tobb ilyen eszkozt hoznak sajnos forgalomba, ahol az alapveto konfiguralasi lehetosegek is hianyoznak

udv zoli

"Manapsag egyre tobb ilyen eszkozt hoznak sajnos forgalomba, ahol az alapveto konfiguralasi lehetosegek is hianyoznak"

A többség ilyen szerintem. Ehhez kell alkalmazkodni, és a véleményem az, hogy vashoz kell oprendszert csinálni és nem fordítva.

Ja és ettől eltekintve a további probléma ettől még fennáll.

--
trey @ gépház

"130k-ert meg a freebsd is mennyen rajta elsore? "

Senki nem mondta, hogy a szóban forgó gépek kerülnek annyiba.

"Kulonben is aki freebsd-vel foglalkozik az meg tudja oldani az ilyen problemakat."

Mármint, hogy feltelepíti? Elképzelhető. De az is, hogy nem akar vele foglalkozni. A f.sz se akar ilyennel szívni, van az embernek jobb dolga is.

És mi van ha használni is akarja? Vedd már észre, hogy a workaround csak azért kell, hogy egyáltalán telepítsd. Ha feltelepítetted, attól még nem lesz firewire-öd. Vagy az nem is cél, hogy javítsunk valamin? Inkább dobjuk ki, úgyse kell senkinek sem? A mellékelt 1 soros patch-csel __használható__ állapotba kerülne ezeken a gépeken a firewire port __és__ probléma nélkül telepíthető lenne a FreeBSD 5, 6 (mindegyik elhasal rajta). Szerinted tényleg könyörögni kellene a commit-ért? Én már ott tartok, hogy lesz.rom. Dillon-nak jó volt, nekik nem kell. Sajnálom.

--
trey @ gépház

( buran | 2006. 05. 15., h – 10:27 )

Hát az 5-ös sorozat tényleg elég fíreg volt, akkor én is elkönyveltem magamban, hogy FreeBSD-t majd csak sokára. Ezek szerint újra tesztelhetek... :-)

Na igen, de nekem a 6.0 volt az, amivel nagyot szívtam. 5 különböző gépen próbálkoztam vele (ebből kettő egy IBM xSeries220 és egy IBM Netfinity 5000) a másik három egyszerű desktop gép minden spec hardware nélkül. A három desktop-ra korábban az 5.3-ast meg az 5.2.1-es nagyobb gond nélkül sikerült telepítenem. De a 6-os installja során bármelyik gépen próbálkoztam, amikor elkezdte volna a csomagokat másolgatni a / -ba, 60%-nál Signal 11 error-al elszállt az egész. Mindegy volt hogy netről vagy CD-ről próbálkoztam az installal. A Signal 11 pedig szinte akármitől lehet, azonban ha 5 külöböző gépen ezzel száll el, és korábban az 5.x széria ezekre felkúszott, talán mégse a gépekben van a hiba...
Arról nem beszélve, hogy a 7 éves Netfinity szerveren a AMD pcnet32 chipsetes hálózati kártyával annyira nem tudott mit kezdeni, hogy boot során kernel panic-al elszállt a fenébe. Le kellett tiltanom BIOS-ból és beletenni egy másikat, hogy egyáltalán elindujon...
Szívesen kipróbálnám a FreeBSD-t is, de ezek a dolgok mindig elvették a kedvemet tőle. Talán majd most a 6.1. :-)