GNU Hurd még idén?

Hurd

A Free Software Foundation (FSF) elnöke, Richard M. Stallman szerint még ebben az évben megjelenthet a GNU operációs rendszer, a HURD. RMS szerint a GNU operációs rendszer a maga mikrokerneles magjával, a HURD-del jobb, mint a Linux."A GNU kernel működik, így most már a GNU rendszerrel tudunk foglalkozni a GNU/Linux helyett, amelyet az emberek eddig használtak" mondta Stallman, aki jelenleg Indiában tartózkodik, ahol egy GNU/Linux Nap vendége lesz. Stallman igencsak rossz néven veszi azt, hogy az emberek a Linuxról, mint operációs rendszerről beszélnek, hiszen az csak egy kernel.
"Az valójában a GNU/Linux, amelynek a kernele a Linux", mondta. Stallman szerint nagyon lesújtó az, amikor az emberek az ő munkájukról írnak és nem az ő nevükön hívják, egyszerűen elfelejtik őket.

Stallman állítása szerint az FSF GNU rendszerének kernele, a Mach sokkal erősebb mint a Linux, hiszen mikrokerneles felépítésű és nem monolitikus, mint a Linux.

"A mikrokernel felett szerver programok futnak (HURD), amelyek elvégzik a kernel magasszintű feladatait. Például a fájlrendszerek, a hálózati protokollok és minden más szerverek formájában van megvalósítva. A végeredmény az, hogy nagyon könnyű a rendszer egyes részeit kicserélni és hozzáadni ahhoz, miközben az fut."


Kapcsolódó témák:

Az IDG eredeti cikke

A GNU/HURD rendszer hivatalos weblapja

A Debian HURD portjának weblapja

Debian HURD CD-k az ftp.fsn.hu-n

( porneczi v | 2002. 03. 13., sze – 13:49 )

Kivancsi vagyok ra, hogy hasznalataban miben fog elterni a linuxtol, es mennyire lesz 'eros'.

( jonci | 2002. 03. 13., sze – 14:01 )

Akkor a Debian Linux es a Debian HURD csak a kernelben fog kulonbozni es 1-2 csomagban vagy egyik .deb csomag sem lesz kompatibilis?

( gaboro | 2002. 03. 13., sze – 14:12 )

ez azt jelenti, hogy az oszes hardvertamogatas, ami a linux kernelben letezik, portolva lesz a hurdhoz service-kent?
vagy mar van is? kiveve persze a zart forrasu dolgok, mint az nvidia meghajto.

aki mar hasznalta, milyen a debian/hurd? hasznalhato, gyorsabb, jobb, milyen?

( sz | 2002. 03. 13., sze – 16:10 )

Volt korabban itt egy hir, miszerint a kerneltrap-en megjelent egy interju Neal Walfielddel, az egyik HURD fejlesztovel. erdemes elolvasni, jokat mond. azt allitja, hogy a HURD lassabb lesz majd, mint a linux, valamennyivel. mivel mikrokernel, tobb context switching kell majd, tobb kommunikacio, stb. ahhoz hasonlitotta ezt, mint amikor anno nekialltak atterni assemblyrol C-re. valamennyivel az is lassabb volt, de nem jelentosen [ebbe ne menjunk bele, h mikor mennyivel es miert.. (;], viszont joval konnyebben karbantarthato. A driverek., amiket itt szervernek neveznek, nem kernel modban, hanem user spaceben futnak. ez okozza majd a sok taskvaltast es a sok processzek kozotti kommunikaciot, ami majd a lassulast okozza. ellenben egy hiba user space beli driverben nem dobja hanyatt majd az egesz rendszert, hanem lehetoseg lesz leallitani. vagy ujrainditani, mint a windowst altalaban nem lesznek kompatibilisek a Debian GNU/Linuxszal. viszont ott vannak a binary-all szekcioban levo csomagok, amik biztos, h kompatibilisek lesznek. pl perlnek sok modulja elvegre csak plain text, postgresql-doc se eppen fugg az architekturatol...

probalni nem probaltam, de amint lehetoseg lesz ra, nyilvan (; alig varom mar h beirhassam: kill -9 vfat

sziasztok.

sz

( sz | 2002. 03. 13., sze – 16:12 )

Volt korabban itt egy hir, miszerint a kerneltrap-en megjelent egy interju Neal Walfielddel, az egyik HURD fejlesztovel. erdemes elolvasni, jokat mond. azt allitja, hogy a HURD lassabb lesz majd, mint a linux, valamennyivel. mivel mikrokernel, tobb context switching kell majd, tobb kommunikacio, stb. ahhoz hasonlitotta ezt, mint amikor anno nekialltak atterni assemblyrol C-re. valamennyivel az is lassabb volt, de nem jelentosen [ebbe ne menjunk bele, h mikor mennyivel es miert.. (;], viszont joval konnyebben karbantarthato. A driverek., amiket itt szervernek neveznek, nem kernel modban, hanem user spaceben futnak. ez okozza majd a sok taskvaltast es a sok processzek kozotti kommunikaciot, ami majd a lassulast okozza. ellenben egy hiba user space beli driverben nem dobja hanyatt majd az egesz rendszert, hanem lehetoseg lesz leallitani. vagy ujrainditani, mint a windowst <; uj driver/server pedig majd akar ugy is installalhato lesz majd, h: apt-get install isofs, ami szerintem eleg nagy flexibilitast jelent majd (; valamint eleg sokat beszel meg az urge valami ujfele biztonsagi modellrol, amit akkor nem igazan fogtam, h mi hogy is van (;

Drivereket tekintve viszont szivas lesz majd. ugyan nem hasznaltam en 2.2 elotti kernelt [csak egyszer, slink installnal vmelyik 2.0.x-et, amig a 2.2 le nem fordult], de szerintem most olyan lesz a helyzet majd, mint mondjuk anno az 1.0-as Linux kernel megjelenesekor. gondolom, akkor se volt meg LVM meg DRI a kernelben... hat a HURDban most meg hangkartya nem lesz, meg ki tudja, mi minden mas nem lesz meg (; es szinten csak szerintem, joval lassabban fog majd fejlodni, mint a Linux manapsag [szinten ne menjunk bele, h ez a lassusag elony is lehet (;]. nem all majd mogotte akkora fejlesztoi bazis, mint a Linux mogott, se cegek nem lesznek majd annyian, mint a Linux mogott. [Ez is lehet jo is, rossz is altalaban nem lesznek kompatibilisek a Debian GNU/Linuxszal. viszont ott vannak a binary-all szekcioban levo csomagok, amik biztos, h kompatibilisek lesznek. pl perlnek sok modulja elvegre csak plain text, postgresql-doc se eppen fugg az architekturatol...

probalni nem probaltam, de amint lehetoseg lesz ra, nyilvan (; alig varom mar h beirhassam: kill -9 vfat

sziasztok.

sz

( sz | 2002. 03. 13., sze – 16:20 )

Volt korabban itt egy hir, miszerint a kerneltrap-en megjelent egy interju Neal Walfielddel, az egyik HURD fejlesztovel. erdemes elolvasni, jokat mond. azt allitja, hogy a HURD lassabb lesz majd, mint a linux, valamennyivel. mivel mikrokernel, tobb context switching kell majd, tobb kommunikacio, stb. ahhoz hasonlitotta ezt, mint amikor anno nekialltak atterni assemblyrol C-re. valamennyivel az is lassabb volt, de nem jelentosen [ebbe ne menjunk bele, h mikor mennyivel es miert.. (;], viszont joval konnyebben karbantarthato. A driverek., amiket itt szervernek neveznek, nem kernel modban, hanem user spaceben futnak. ez okozza majd a sok taskvaltast es a sok processzek kozotti kommunikaciot, ami majd a lassulast okozza. ellenben egy hiba user space beli driverben nem dobja hanyatt majd az egesz rendszert, hanem lehetoseg lesz leallitani. vagy ujrainditani, mint a windowst <; uj driver/server pedig majd akar ugy is installalhato lesz majd, h: apt-get install isofs, ami szerintem eleg nagy flexibilitast jelent majd (; valamint eleg sokat beszel meg az urge valami ujfele biztonsagi modellrol, amit akkor nem igazan fogtam, h mi hogy is van (;

Drivereket tekintve viszont szivas lesz majd. ugyan nem hasznaltam en 2.2 elotti kernelt [csak egyszer, slink installnal vmelyik 2.0.x-et, amig a 2.2 le nem fordult], de szerintem most olyan lesz a helyzet majd, mint mondjuk anno az 1.0-as Linux kernel megjelenesekor. gondolom, akkor se volt meg LVM meg DRI a kernelben... hat a HURDban most meg hangkartya nem lesz, meg ki tudja, mi minden mas nem lesz meg (; es szinten csak szerintem, joval lassabban fog majd fejlodni, mint a Linux manapsag [szinten ne menjunk bele, h ez a lassusag elony is lehet (;]. nem all majd mogotte akkora fejlesztoi bazis, mint a Linux mogott, se cegek nem lesznek majd annyian, mint a Linux mogott. [Ez is lehet jo is, rossz is <; szinten ne menjunk bele. de pl egy SGI fele XFS jo lenne ha lenne (; tekintve, h minden adatom XFS particion van/lesz]. Ugyanakkor a driverek fejlesztese szerintem ezek utan mar egyszerubb lesz, leven ott van elottuk egy GPL pelda, h mifele modon kell adott eszkoz driverenek mukodnie.

Jonci: hat szerintem a Debian GNU/HURD az csak egy kulon architektura lesz. en ugy gondolom, h a csomagok altalaban nem lesznek kompatibilisek a Debian GNU/Linuxszal. viszont ott vannak a binary-all szekcioban levo csomagok, amik biztos, h kompatibilisek lesznek. pl perlnek sok modulja elvegre csak plain text, postgresql-doc se eppen fugg az architekturatol...

probalni nem probaltam, de amint lehetoseg lesz ra, nyilvan (; alig varom mar h beirhassam: kill -9 vfat <; ez viszont meg soka lesz...

sziasztok.

sz
[francnak irok en ilyen hulye smiley-kat? (;]

( uid_558 | 2002. 03. 14., cs – 13:09 )

Izlesek es pofonok, a monolitikus es a mikrokernel melletti elkotelezettseg inkabb amolyan vallasi meggyozodes targya, mert mindkettonek megvannak a maga elonyei es hatranyai. Mindenesetre a 2.4-es linux kernellel 1 ev utan is vannak gondok, IMHO tulnott a dolog azon a bonyolultsagi szinten amit a monolitikus arhitektura meg hatekonyan le tud kezelni.

Reszemrol szivesen aldozok akar 10% teljesitmenyveszteseget is a biztonsag oltaran, es azert elmeletben itt a mikrokernel verhetetlen, pontosan amiatt hogy az elszigetelten futo szerverek hibai csak sajat maguk mukodeset befolyasoljak. En amugy a mono-mikrokernel parhuzamot az asm-c helyett inkabb a c-c++-szal szemleltetnem. Valamivel tobb az overhead, viszont jobb az enkapszulacio, nagyobb a biztonsag...

Azt azert meg nem kene elfelejteni, hogy igenis letezik mikrokerneles "unix" QNX neven... Na persze nem webszervereket hanem atomeromuveket biznak ra... Raadasul meg realtime is a draga, szoval csak nem lehet akkora bukas maga az arhitektura ;)

Summa summarum, en igenis josolok jovot a hurd-nak, a linuxszal szemben, pont azert amiert a C-t is lenyomta mara a C++