Bitrig - kevésbé konzervatív OpenBSD fork

 ( trey | 2012. június 13., szerda - 8:55 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

:
szép süti :)

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.)

clang arm-ra apple miatt nagyon fejlodik, phoronix-en olvastam egy cikket, hogy a 3.0-s clang pandaboardraver gcc 4.6-ra

szerk.: es beneztem, bizonyos teszteken ver ra
___
info | Tresorium

ceges hatterrel rendelkezik a project, fizetett fejlesztokkel

kewl, remélhetőleg jobban fejlődik majd, mint az openbsd

Te is benne vagy ?

--
http://bsdbased.com

nem

Mondjuk a ppc és a sparc64 sem halott platform ha már itt tartunk. Legalább egy big endian platformot meg kellene tartani, hogy a kódot lehessen azon is tesztelni.

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]

erről a little endian vs big endian vitáról mindig eszembe jut Swift Gulliverjéből Lilliput kontra Blefuscu tojásfeltörési háborúja:)

Remelem tudod, hogy eleve onnan jon a kifejezes :-)

> Az endian problemakat tesztelje az, aki tobb platformot tamogat, neki relevans.
Ezzel csak az a gond, hogy konnyen e;eg csunyakat lehet bukni, ha ezt elfelejtjuk (vagy plane tudatosan keruljuk).

+1

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]

De mennyivel jobb, ha a masik gepen nem valami $RANDOM OS fut, hanem a sajatunk, amin mindket iranyba lehet tesztelni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Így van. Pont van egy ilyen bug az openbsd-ben és ppc-n azonnal kijött, máskülönben ki tudja mikor veszik észre.

A szál itt kezdődik:
http://marc.info/?l=openbsd-misc&m=133960958410103&w=2

Ó de szép! Kösz a linket.

Nem semmi.. :D

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]

Volt (Van) ilyen MPI implementacio, marmint nem lehet keveerni oket, de nem ilyen "trvilais" bugok miatt.

OpenMPI 1.1 elott.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"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

sejtettem, hogy lesz valaki...

--
trey @ gépház