Vlákno názorů k článku Proč není Hurd ani po dvaceti letech hotový? od Michal2 - Na vine je akademicke prostredi. Kdyz chci neco...
-
Michal2 (neregistrovaný)
Na vine je akademicke prostredi. Kdyz chci neco vymyslet- akademicke prostredi je pro to perfektni. Na zakladni vyzkum idealni.
Kdyz ale chci neco opravdu vytvorit- pak je jedno z nejhorsich moznych. Vetsi koncentraci v praxi nepouzitelnych snilku naprosto odtrzenych od reality s hlavou v oblacich a nulovym tahem na branku svet nevidel. Navic maji vetsinou zapornou motivaci- kdyz praci dokonci tak by se museli venovat necemu jinemu. Publikovatelne vysledky generuje i neustale motani se v miste, tak nad nima nikdo s bicem nestoji...
-
Kirk (neregistrovaný)
A ono je nekde dano, ze Hurd smi programovat jen zamestnani na univerzite a Linux jen lide pracujici v komercni sfere?
Neni.
Proste je to tak, ze Linux "funguje" a "fungoval", takze na sebe nabalil mnozstvi vyvojaru a dal uz to byl jen efekt snehove koule.
Zatimco Hurd se do te nabalovaci faze nikdy nedostal.
Nejde o to, ze ho vyviji akademici, jde o to, ze ho vyviji malo lidi.
-
Problém Hurdu je jednoduchý.
Všechny mikrokernely a vynikající a úspěšné mikrokernely, které znám začaly tímto: fuck off POSIX!!!
Problém je, že mikrokernel se musí naprogramovat a nabídnout jiné základní služby, než si představují akademici a musí se vybodnout na mnoho unix-like standardů jako je POSIX a řada dalších.
POSIX může být emulován až někde ve vyšších vrstvách.
Když si vzpomínám, jak jsou koncipované archiktektury úspěšných mikrokernelů, a zejména v průmyslu je jich mnoho, protože jiná architektura nedokáže zajistit potřebné vlastnosti jako je spolehlivost či další – všechny mají základníslužby nePOSIXové a neUNIXOvé.
Dokáží emulovat posix i unix služby. Ale je to pouze emulace ve vyšší vrstvě.
Akademici bohužel mají díky svým sklonům k čistotě velkou úctu ke standardům a mnoho z nich je svázáno s boomem unixu a vše navazujících standardů.
Ale doporučuji se podívat třeba na QNX.
Hurd to prohrál, protože v jádru se příliš soustředí na unix a jeho standardy. Jádro měl udělat úplně po svém a jinak. Zapomenout na unix, na posix i další – a pochopit, že unix like věci budou jen emulace. Bohužel mám pocit, že Hurdu trvalo 20 let, než přetavili mozek do tohoto poznání – a teď mohou začít.
-
Přesně tak.
Hurd se snažil o totéž co feministky. Feministky se snaží být muži a lepší,než muži – a nějak se to nedaří.
Hurd jako mikrokernel se snažil být makrokernelem, respektive poměřovat se s makrokernelem a jít jeho cestami.
Každý mikrokernelový operační systém to prohraje, když se bude snažit dělat koncepty a služby makrokernelového systému. A to se stalo Hurdu.
Cokoli ostatního je zástupný problém. Hurd pouze zjistil, a pravděpodobně ještě bude zjišťovat, že s koncepty makrokernelu nevnikne žádný dobrý mikrokernel, a ještě to bude trvat tak 200 let.
Mikrokernel musí být od počátku i myšlenkami mikrokernel. Snažit se mikrokernel uplácat podle principů přesně protikladného uspořádání, tedy monolitu a nejprotikladnějšího monolitu – unixu prostě úspěšný mikrokernel nevyvolá.
Neexistuje tvrdší monolit, než unix. Nelze proto unixové principy uplatňovat na přesně opačnou architekturu – mikrokernel. Tedy v low level částech.
To je celý problém Hurdu. Nic jiného.
-
Yenya (neregistrovaný)
> Hurd to prohrál, protože v jádru se příliš
> soustředí na unix a jeho standardy.Tuhle implikaci příliš nechápu. Pokud chci mít z hlediska POSIXových aplikací verifikovaný a spolehlivý systém, je mi v zásadě jedno na které úrovni bude ten POSIX implementovaný. Verifikovat musím vše od POSIXového rozhraní nahoru.
Pokud chce být HURD jádrem pro GNU systém (který má celý user-land psaný pro POSIX), asi mu nic jiného než soustředit se na dobrou podporu POSIXu nezbývá.
Když bych se posunul o úroveň abstrakce výš - co je teda konkrétně na POSIXovém rozhraní tak špatného, že to brání efektivnímu použití mikrokernelové architektury?
-
> Nejde o to, ze ho vyviji akademici, jde o to, ze ho vyviji malo lidi.
A ja myslim ze presne o to jde, ze akademici jsou ta pricina. Linusuv cil byl (mozna ne uplne presne, ale v principu) rozbehat to na svym kompu, udelat nejaky fs a spustit pod tim gcc. Kdo chce vic at si to dopise a posle patch. Je jasne, ze na tohle chytnete daleko vic lidi, nez kdyz vasi prioritou bude mikrojadro, design a cistota. Proste kdyby to opravdu chteli rozbehat, tak resi uplne jine veci nez prechod na jine mikrojadro kazdych pet let. Sice by se dopustili kompromisu, ale bylo by to venku.
Ostatne vidim to i u sebe na svych soukromych hracickovych projektech. 20% casu travim implementaci noveho a 80% upravama a cistkama tak aby se mi to libilo. V praxi je ten pomer 70:30 a vysledky jsou samozrejme nekde jinde.
-
??
To jsem nekde rekl?
Ma teorie je, ze kdyz nekdo da na prvni misto cistotu a kvalitu navrhu, tak nesezene tolik lidi na vyvoj (treba proto, ze ostatni maji jiny nazor na to, co znamena kvalita, nebo nakolik se dopoustet kompromisu) jako nekdo, kdo si da za cil produkcni nasazeni (cti nejak to rozbehat :-) ). Dalsi tvrzeni je, ze tyto priority stanovili "akademici".
Jak to souvisi s TeXem netusim (pokud vim, tak ho Knuth stvoril aby v nem napsal knihu) a uz vubec jsem si nevsiml, ze bych zminoval, ze by se neco melo hazet do kytek.
-
Biktop (neregistrovaný)
Udělat čistý návrh napoprvé je holý nesmysl, případně dotek všehomíra. I v rukopisech největších skladatelů najdete škrtance, i největší malíři si předkreslovali a v průběhu realisace museli předělávat. Vývojář, který dělá něco nového, nejen nějakou rutinní záležitost, nutně musí postupovat ve dvou krocích:
1) Vytvořit si (teoreticky čistou) představu, jak by to mělo fungovat a podle ní zmastit velmi ušmudlanou, leč funkční implementaci.
2) Na základě získaných zkušeností s implementací přistoupit k přehodnocení těch nejzásadnějších konfliktů s teoretickými představami a celé to udělat znova, z jedné vody načisto; smířit se s tím, že dokonalá čistota není.
