Bitrig - kevésbé konzervatív OpenBSD fork

OpenBSD

A Bitrig a FAQ-ja szerint egy OpenBSD fork. A célok közt szerepel, hogy a fejlesztők csak aktív, fejlődő platformokra szánják. Mint írják, régi platformokra fejleszteni jó móka, de inkább mégis az újabb dolgokra koncentrálnak. Így jelenleg az i386 és az amd64 támogatott. Tervben van az ARM eszközök támogatása. Nem zárkóznak el más architektúrák támogatásától sem, de régi dolgokkal nem kívánnak foglalkozni.

További cél, hogy az alaprendszert olyan kis méretben tartsák, ahogy az csak lehetséges, gondolva a beágyazott rendszerekre. Fogadnák a közreműködni vágyó GSoC tanulókat.

Az OpenBSD-vel ellentétben nem GCC-vel, hanem clang 3.1-gyel készítik. A tervekben szerepel új funkciók - virtualizáció, journaling stb. - bevezetése is.

A projekt útiterve itt. A FAQ itt. A projektoldal itt.

( Zahy v | 2012. 06. 13., sze – 10:03 )

Célnak gyönyörű. Csak nehezen hihető, hogy lsz is belőle valami. Nyilván, ha kidobjuk a GCC-t, és helyére rakjuk a CLangot, akkor máris könnyedén csökkenthetjük az architektúrák számát, hiszen van pár olyan, ami az LLVM-nél *még* (ki tudja meddig) nem támogatott. Én a fenti kijelentés ("csak aktív, fejlődő platformokra") mellett nem merném leírni, hogy *terv* az ARM valamikor a jövő ködébe vesző támogatása.
Mindenesetre a virtualizáció és a journaling meg a minimalizmus szép célok, térjün vissza rájuk mondjuk 2 év múlva, lássuk az ARM és a minimalizmus legalább megtörténik-e addigra. Amúgy fel lehetne venni a MIPS-lapkákat is, beágyazott vackokban az is sűrűn előfordul.
(Ja, szerver, célkütyü, vagy desktop a cél? Nem, nem olvastam el a linkeket.)

PPC es sparc64 azert az x86(_64)/arm paros mellett szvsz messze elmarad. Csak BE miatt pedig minek? Ha minden supportalt platform LE, akkor csak azert hozni egyet ami nem, hogy legyen, pazarlasnak tunik.

Az endian problemakat tesztelje az, aki tobb platformot tamogat, neki relevans.

--
|8]

Ezt ki tudnad fejteni bovebben? Nekem nem vilagos, hogy mikent lehet csunyat bukni ha a masik endiannest tudatosan ignoraljuk.. (nyilvan esszeru keretek kozt; pl ha egy protokoll BE, akkor az LE architekturan is legyen BE, es hasonlok - de ezen szvsz a egy BE architektura egeszen pontosan semennyit nem segit :P)

--
|8]

Már nem emlékszem melyik program volt, de valami hálózati kommunikációt sikerült úgy leprogramozni, hogy a htonl-ntohl konverziót simán kifelejtették a kódból. Mivel kizárólag ugyanolyan architektúrájú (és endiannessű) gépeken tesztelték, volt nagy pofáraesés, amikor egy másik endiannessű géppel az amúgy csont nélkül forduló alkalmazás nem tudott beszélgetni.

És igen, bele se gondoltak abba, hogy kéne ilyesmivel foglalkozni.

> Már nem emlékszem melyik program volt, de valami hálózati kommunikációt sikerült úgy leprogramozni, hogy a htonl-ntohl konverziót simán kifelejtették a kódból

Ezen nem segit onmagaban az, hogy van BE arch. Az nem implikalja az LE<->BE tesztelest. Ha nem gondolnak ra, hogy archok kozott is kene tesztelni, akkor hiaba van BE arch.

Viszont LE<->BE tesztelest kivaloan meg lehet ugyis csinalni, hogy a fejlesztett OS nem tamogat BE-t: fogsz egy olyan OS-t, ami viszont igen. Es ugy meg egyszerubb is, mert neked nem kell extra archot tamogatni. ;)

--
|8]

Nem tudom, szerintem egy (nem annyira)$RANDOM OS hasznalata teszteleshez lenyegesen kevesebb eroforrast igenyel, mint egy extra arch.

A mindket irany meg nem erdekes, ha eleve csak LE-re akar az ember koncentralni, mert nem eri meg a BE a befektetest. Lehet massal tesztelni, kevesebb eroforrassal, es igy tobb ido marad arra koncentralni, amit hasznalnak is a fejlesztok is, meg a celkozonseg is.

--
|8]

( hrgy84 | 2012. 06. 14., cs – 20:56 )

"régi dolgokkal nem kívánnak foglalkozni."
Pedig az i386 az eleg regi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal