[BSD] Re: 6.0...

[Adam Szilveszter]

Mohacsi Janos wrote:

> On Wed, 18 Aug 2004, Zahemszky Gabor wrote:
> 
>> Antal Rutz writes:
>>
>>> hopsz: 
>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.62&r2=1.63&f=h 
>>> ide is eljutottunk.
>>
>> De ugy latom a BRANCS nevet elfelejtettek atirni:
>> CURRENT => FUTURE Szemelyes velemenyem szerint nem lett volna hatrany, 
>> ha elobb kisse stabilla teszik az 5-os agat,

En is jobban orultem volna ha elobb az 5.3 rendesen kesz. Most ugy tunik 
nekem, hogy a fejlesztok ugy dontottek, hogy ha torik ha szakad az 5.3 
akkor is stable lesz ha percenkent megborul. Ezt ugyan moralisan ertem 
(a nagyon hosszu atmenet az 5.x-re mar tenyleg kezdte kikezdeni a 
felhasznalok bizalmat es a fejlesztok lelkesedeset is) de helyesnek nem 
tartom. Ha nem megy valami, akkor becsuletesebb beismerni, es hagyni 
hatha majd jobb lesz kesobb. Az teny, hogy - mint korabban is irtam - a 
Linux kernel fejlesztesben is nagyjabol ez volt az a fejlesztesi szint, 
aminel a nagy penzes szponzorok megjelentek. A BSD-nel ezeket most se 
latni. Es hobbibol ezeket a felsorolt dolgokat meg persze a tobbit 
csinalni nagyon nehez, es nem mindenki egy Poul-Henning akit hajlandok a 
userek megfizetni azert, hogy azon dolgozzon ami szerinte fontos, hanem 
legjobb esetben is csak azert, ami szerintuk fontos.

>> meg megcsinaljak vegre a 
>> lenyegesebb dolgokat (gvinum;
> 
> 
> Ez tenyleg hianyzik, de nekem megy a vinum FreeBSD 5 alatt.

De nem teljes ertekuen, es nemi villongas utan most mar Greg Lehey is 
beismeri ezt es az embereknek azt ajanlja, hogy alljanak at gvinum-ra, 
mert o mar nem fogja a sajatjat megcsinalni. Es itt jon be a valoban 
"agyigenyes" projektek problemaja: hiaba van ott a nyitott forras, ha 
nagyon keves ember ert hozza a megfelelo szinten akkor nem tudjak 
folytatni, ha az eredeti developer kilep.

>> RAID 0-5;
> 
> 
> RAID 0-t es 1-et probaltam.

Ha a gvinum menni fog akkor ezzel nem lesz gond. Ha.

>> ACPI + SMP egyuttmukodes;
> 
> 
> Ez is megy Dell szerveren. IBM szerveren doglott az az ACPI, de annyira, 
> hogy a konzol meg is fagy ACPI-val. Szerintem itt a hanyadek ACPI 
> implementaciokkal van baj.

Igen nagyon sok a szutykos hardver, meglepoen sok a szerver osztalyban 
(ahol pedig nem made in China cuccok vannak) ld a rengeteg gondot 
ServerWorks csipekkel... regi hw-el sose fog menni rendesen az ACPI, az 
ujakkal elvileg egyre jobban de par BIOS frissites azert meg kelleni fog 
hozza. Allitom, hogy a zart forrasu win driver nagy resze is ilyen 
szutyok cuccok miatti workaround, amit azonban rejt az NDA... a kod 
alapjaban ugyanaz (Intel ACPI-CA referencia implementacio) mint pl 
FreeBSD-ben is van.

>> mindennel egyuttmukodo thread megvalositas;
> 
> 
> Mire gondolsz?

Jelenleg harom szalkezelo konyvtar is van 5.x-en, amibol nyilvan csak az 
egyik kell, a masik kettot be kell olvasztani ha van meg amit az az egy 
nem tud. Most ugy tunik, hogy a kivalasztott a libpthread lesz. De 
bizonyos elemek meg hianyoznak a puzzle-bol, pl a mostanaban 
implementalt Thread Local Storage (TLS). Nem kell elfelejteni, hogy a 
Linux vilagban pont ez a munka pl nagy reszt bizony fizetett RH 
programozoknak koszonheto, mert az ilyen aprolekos szutyok munkat 
lelkesedesbol nem szoktak csinalni.

De emlitheto lenne az a zavaroan nagy szamu ToDo item is, ami mar 
igazabol 5.2-re, vagy esetleg mar elobb kellett volna, de nem lett 
kesz... erdemes megnezni a listat.

Ez persze nem jelenti azt, hogy a FreeBSD nem egy jo rendszer. De azt 
igen, hogy most jutott odaig, hogy mar nem eleg a mult dicsosegebol elni 
es orulni, hogy milyen jol megy meg mindig, hanem fel kell allni es 
csinalni kell, ugy, ahogy az eredeti CSRG kutatok se feltek volna 
nekiallni es megcsinalni. Es lehetoleg ugyanolyan magas szinvonalon. 
Ezert orulok annyira a "The Design and Implementation" konyv uj 
kiadasanak...

Sz.