--- Topic for #taee is Next talk: "The Hurd: a GNU approach to OS design Friday Dec 13, at 21:00 GMT Wolfgang Jaehrling | Comments #qc; Spanish #redes; Dutch #taee
garoeda	vragen op #qc , nederlandse vertaling op #taee en misschien spaans op #redes
garoeda	dank u
garoeda	Wolfgang: mag ik?
garoeda	i ga vertellen over the HURD, waarom GNU het ontwikkelt, zelfs al hebben al een zeer volwassen en populaire kernel voor het GNU systeem, we hebben het hier over Linux
garoeda	the Hurd is echter geen kernel, samen met de GNU C bibliotheek (glibc) en de GNU Mach microkernel geeft het de functionalieit die traditioneel gegeven wordt door een Unix kernel
garoeda	deze 3 componenten tesamen met de rest van het GNU systeem (met oa. gcc, GNOME etc.. en zelfs niet GNU software zoals X11) geven ze een POSIX conform operating systeem
garoeda	nu enkele opmerkingen over de terminologie
garoeda	de GNU Hurd (of kortweg de Hurd) is de naam van een deel van het systeem. GNU/Hurd is de naam van het gehele systeem. je kan "GNU/Hurd" zien als "het Hurd gebaseerde GNU-systeem"
garoeda	het systeem werkt als volgt:
garoeda	applicaties van de Unix-wereld (ik zal ze POSIX-applicaties noemen) gebruiken functies in de C bibliotheek waar ze Unix kernel-calls zouden aanroepen. dit zijn basisfuncties zoals read(), write(), fork() enzoverder
garoeda	de C bibliotheek communiceert met de Hurd-servers om deze functies te implementeren
garoeda	maar de Hurd servers zijn op geen enkele manier speciaal, het zijn normale programma's. Ze kunnen dus ook de C bibliotheek gebruiken
garoeda	je kan deze Hurd-servers zien als Daemons
garoeda	we hebben een server die het ext2 bestandssysteem implementeert
garoeda	een andere implementeert het TCP/IP protocol
garoeda	we hebben zelfs een server die /dev/null implementeert
garoeda	een kleine opmerking over POSIX conformiteit
garoeda	sommige mensen denken zelfs dat Windows NT POSIX conform is
garoeda	dat is niet echt het geval, het implementeert maar een paar _basis_ onderdelen van POSIX
garoeda	terwijl GNU/Hurd helemaal POSIX conform is, modules de bugs natuurlijk :)
garoeda	dit iszeer belangrijk , we zijn nog altijd compatibel, je kan dus al de vrije programma's die je gebruikt bop GNU/Hurd gebruiken, tenminste als deze wat portable geschreven zijn
garoeda	dus de GNU/Hurd is een combinatie van comlete compatibiliteit en nieuwe concepten
garoeda	laat ons het hebben over deze nieuwe concepten
garoeda	oh, ik heb een stuk overgeslagen
garoeda	ik heb zelfs veel overgeslagen, ik wou eerst spreken over de geschiedenis en de motivatie achter de Hurd
garoeda	zoals jullie misschien wel weten, Richard Matthew Stallman startte met de ontwikkeling van het GNU systeem in 1984
garoeda	het primaire doel was om 'vrij' te zijn, beter dan proprietary systemen te zijn op moreel, sociaal en esthetisch vlak
garoeda	maar het had ook als doel om technologisch beter te zijn
garoeda	als je het GNU software vergelijkt met Unux software zal je waarschijnlijk opmerken dat Unix software willekeurige limieten heeft. bijvoorbeeld: in vele Unix tools worden input lijnen van meer dan 1024 stilletjes afgeknipt
garoeda	vraag: hoe zit het met het draaien van niet-vrije software op the hurd?
garoeda	het is mogelijk om niet-vrije-software te draaien op de GNU/Hurd maar ik hoop dat niemand dat echt wil doen
garoeda	we zijn niet compleet binair compatibel met GNU/Linux dus je kan de meeste niet-vrije-software niet gebruiken. Er zijn enkele technische redenen waarom het problematisch is om ABI (Application Binary Interface) compatibel te zijn. Ik kan hier later meer over vertellen als er interesse tot is
garoeda	vraag: mogelijk zijn tot en wettelijk mogen zijn andere dingen. is de lgpl-ness van glibc voldoende om alle programma's af te schermen van de GPL 'linking" clausule (om hurd servers te gebruiken)?
garoeda	ja dat is voldoende, je kan zelfs direct met Hurd servers communiceren aangezien je Remote Procedure Calls gebruikt. er is dus geen linken in het spel
garoeda	ok, terug naar het originele onderwerp: de willekeurige Unix programma limieten en waarom GNU beter wil zijn
garoeda	in feite is het gehele design van de Hurd gebaseerd op het idee om geen willekeurige limieten op te leggen aan de gebruikers
garoeda	dus als je een ISO image van een cd-rom loopback wil mounten kan je dat doen als gebruiker zonder speciale permissies nodig te hebben. Dat is geen probleem daar de iso9660fs-server gaat draaien met jouw user-id. het is gewoon een programma dat je start
garoeda	maar je kan veel meer doen dan dat
garoeda	in feite, je kan al de aspecten van je systeem veranderen naar keuze. je kan je eigen wereld maken, gebruik makende van POSIX componenten waar je wilt en je eigen componenten op andere plaatsen
garoeda	vraag: zijn er geen veiligheidsproblemen als je de gebruikers toelaat om de filesystem namespace aan te passen? of is de gebruiker die de mount uitvoert de enige gebruiker die het nieuwe bestandssysteem kan zien
garoeda	wel, daar kan ik veel op zeggen :-)
garoeda	en hij gaat verder, vraag: indien zo, wat gaat er gebeuren als 2 gebruikers het zelfde mount point willen mounten (dat gaat zowiezo problemen geven...)
garoeda	ik ga de tweede vraag beantwoorden aangezien dat dat gemakkelijker is :à
garoeda	je kan alleen iets mounten op een node die van jou is. dus 2 gebruikers kunnen nooit dezelfde node gebruiken
garoeda	dit beantwoordt gedeeltelijk je eerste vraag
garoeda	je kan dit allen doen in je eigen home directory (of in plaatsen zoals /tmp of /var/tmp natuurlijk°) maar dat is geen beperking. je kan ook je eigen copy van de complete Hurd starten in je eigen home directory, je hebt dus een eigen root bestandssysteem (dat anderen niet kunnen zien) en je kan het aanpassen zoals je wilt
garoeda	een kleine onderbreking hier: kan je ook iets mounten voor N gebruikers (bv een iso image in een loop device) ?
garoeda	ik bn niet op de hoogte van een eenvoudige manier om dit momenteel te doen. het is conceptueel zeker mogelijk om je eigen authenticatie server op zetten maar dat is enig werk...maar het is mogelijk
garoeda	alles vereenvoudigen dat iederen ooit zou willen is een taak waarmee we ergens in de toekomst gaan beginnen ;)
garoeda	terug naar de vraag over de security problemen
garoeda	sinds je allerlei willekeurige dingen kan plaatsen in jouw gedeelte van het bestandssysteem kan je iemand in de val lokken als hij jouw gedeelte van het bestandssysteem opvraagt.
garoeda	bijvoorbeeld, als je een bestandssysteem in je homedir plaatst dat volledig virtueel is (denk aan /proc op GNU/Linux) en dynamische een eindeloze directory tree genereert , is het moeilijk voor de administrator als hij je homedir wil verwijderen als hij je account weggooit ;)
garoeda	hij zou dus eerst al je eigen bestandssystemen moeten verwijderen
garoeda	als hij dat doet is alles in orde
garoeda	dat is de prijs die je moet betalen als je je gebruikers toelaat om hun eigen omgeving te veranderen. mensen moeten enkel op de hoogte zijn dat het mogelijk is om de omgeving te veranderen
garoeda	maar ik denk dat een persoon die zoiets niet weet over zijn systeem eigenlijk geen servers met meerdere gebruikers zou moeten adminnen ;;)
garoeda	vraag: is er een eenvoudige manier om gebruikers te verhinderen hun eigen bestandssysteem te mounten, voorkomen dat iemand while true ; do mount : done doet?
garoeda	als je een bestandssysteem server start ben je eigenaar van de proces...de vraag is dus eigenlijk hetzelfde als: "kan de administrator voorkomen dat een gebruiker veel processen start" en natuurlijk is dat mogelijk. het is zelfs mogelijk om dat op Unix te doen. ik ben niet zeker in hoeverre  het geimplementeerd is op GNU/Hurd op dit moment
garoeda	als je in het _algemeen_ wil beperken dat gebruikers zelf servers draaien is dit zeer makkelijk
garoeda	gebruik een bestandssysteem voor /home dat dit niet ondersteunt. je kan heel makkelijk zo'n bestandssysteem maken, in feite, sommigen mensen doen dit per ongeluk wanneer ze Debian GNU/Hurd installeren en zich afvragen warom sommige dingen niet werken ;)
garoeda	dus, GNU/Hurd probeert geen limieten op te leggen aan de gebruiker als dat vermeden kan worden. het is erg genoeg dat de hardware beperkt is, waarom zouden we bijkomende beperkingen in de software stoppen? :)
garoeda	(behalve in de gevallen waarin we dingen _willen_ beperken wegens veiligheidsredenen)
garoeda	er is een ander leuk aspect van het systeem: de Unix filosofy zegt dat iemand kleine en simpele programmatjes moet schrijven die flexibel met elkaar gecombineerd kunnen worden. zo doen we het in de Hurd; de Unix kernel schendt dit principe sinds scheduling, hardware ondersteuning, bestandssystemen, netwerk protocols etc.. allemaal door die kernel gedaan worden
garoeda	dit wil niet zeggen dat de Unix designers dom waren natuurlijk, ze waren eigenlijk heel slim
garoeda	ze moesten Unix designen voor computers die minder krachtig waen dan de huidige rekenmachines, het was dus gewoon nodig om het zo te doen
garoeda	in the Hurd gaan we er vanuit dat het tijd is geworden om de oude beslissingen te hierzien omdat er al zoveel veranderd is
garoeda	toen waren user gedefinieerde bestandssystemen niet mogelijk, dus niemand vroeg ernaar; maar vandaag wil iedereen ze en er zijn verschillende aanpakken mogelijk om ze aan te bieden
garoeda	het GNOME-vfs is hier een een voorbeeld van, KDE's ioslaves een ander, libferris nog een ander
garoeda	ze hebben allemaal iets gemeenschappelijks: ze doen dingen op een manier waarop hun nuttigheid beperkt wordt: je moet programma's schrijven om ze te gebruiken. bestaande programma's hebben er geen voordeel van
garoeda	en dit is een belangrijk voordeel van de Hurd: we doen dit op bestandssysteem niveau, je moet dus geen enkele POSIX conforme applicatie aanpassen om van de voordelen van the Hurd te genieten !
garoeda	wolfgang finds this so exciting
garoeda	ok, nu naar enkele concrete voorbeelden
garoeda	natuurlijk hebben we bestandssystemen zoals ext2fs, ufs en fatfs
garoeda	en in toevoeging hiervan hebben we ook netwerk bestandssystemen zoals nfs en ftpfs
garoeda	het laatste is heel leuk, je kan bijvoorbeeld dingen doen zoals "tail -n 2 /ftp/ftp.debian.org/pub/welcome.msg"
garoeda	sommige mensen vinden dit niet leuk met als argument "operaties zoals appenden aan een bestand gaan verschrikkelijk inefficient zijn over ftp" dat is waar, maar als je dat als een probleem ziet moet je dat feature niet gebruiken :-) het is dikwijls wel handig om dit feature te hebbn
garoeda	vraag: hoe gaat ftps dingen zoals verkeerde paswoorden en 'timeout' doorgeven aan POSIX applicaties?
garoeda	in toevoeging tot deze bestandssystemen hebben we er ook virtuele zoals GNU/Linux /proc en devfs heeft
garoeda	maar er is veel meer dan dat
garoeda	een server kan soms maar een enkele node aanbieden, zoals /dev/null en /dev/random
garoeda	en we hebben zelfs een heel schattige server: de "run" translator. (oh, ik vergat bijna te zeggen dat servers die binnen een filesystem translators genoemd worden)
garoeda	wanneer je 'run' start geef je het een shell commando mee. wanneer je dan het bestand opent waar 'run' zich bevindt zal het dat commando uitvoeren en wanneer je ervan leest krijg je de output van het commando
garoeda	dus je kan zeggen om "fortune" uit te voeren, iedere 'cat foo' gaat een nieuw fortune cookie tonen
garoeda	(ze kunnen gebruikt worden om random signatures van emails te maken of voor wat je maar kan bedenken)
garoeda	opmerking: in het voorbeeld is 'foo' een translator, niet? ik bedoel een run-translator
garoeda	ja, het is de node waar de run-translator zich bevindt, het "mountpoint"
garoeda	dit mag allemaal heel leuk zijn maar er zijn veel meer mogelijkheden
garoeda	een translator hoeft niet enkel een bestandssysteem protocol te implementeren, het kan eender welk protocol implementeren
garoeda	bijvoorbeeld, de IP stack implementeert de socket interface, bijvoorbeeld
garoeda	vraag: draait de translator met de privileges van diegendie 'run' starte of met de privileges van diegende die de read(2) uitvoert
garoeda	de translator draait altijd met de privileges van de eigenaar van de node die het 'translates' (het mountpunt)
garoeda	de permissies moeten dus juist staan, zoals altijd
garoeda	er is een simpele reden voor
garoeda	als iso9660fs 'translates' /cdrom (of /mnt/cdrom als u dat wil), dan heeft het toegang nodig tot /dev/cd0. hetzelfde voor eender welk ander bestandssysteem: als je een ext2fs hebt op /var dan moet die server ins staat zijn om te schrijven naar bv. /dev/hd0s3. en natuurlijk mogen gebruikers niet in staat zijn om hier rechtstreekse toegang tot te hebben
garoeda	ok ,het laatste wat ik zei was de IP stack die een socket interface aanbiedt (die beschikbaar is op /servers/socket/inet en -als je protocol nummers wil gebruiken ipv namen- /servers/socket/2
garoeda	natuurlijk ben je niet beperkt tot de interfaces die de Hurd gebruikt, je kan je eigen interfaces gebruiken en het bestandssysteem gebruiken als namespace voor de eerste handshake (ontmoeting) tussen de server en zijn gebruikers)
garoeda	denk voor jezelf even na over de dingen die je hiermee kan doen. ik ben er zeker van dat je goede ideeën kan vinden. het heeft geen belang of het virtuele bestandssystemen zijn , op zichzelfd staande nodes of iets geheel anders
garoeda	vraag: hoe zit het met taal onafhankelijkheid? is C de enige keuze om translaters te coden?
garoeda	lang geleden heeft iemand een module geschreven om translators te schrijven in perl (hij heeft er een module mee geimplementeerd). later heb ik een module geschreven die je toelaat translators te schrijven in Ruby (en ik heb er een translator mee geschreven maar niet echt een nuttige ;-))
garoeda	algemeen gezien is er nog veel werk nodig om het handiger te maken om willekeurige translators te schrijven in eender welke taal
garoeda	ik ben daar zelf heel geïnteresseerd in maar momenteel zijn er andere dingen die veel belangrijker zijn
garoeda	als er dus iemand geïnteresseerd is om hieraan te werken, aarzel niet om mij te contacteren
garoeda	vraag: als je het niet erg vindt (hehe, je moet me wel moe zijn :-)) wat staat er bovenaan de lijst van dingen die nog gedaan moeten worden?
garoeda	wel, ik ben niet zeker dat je die lijst kan onthouden :-)
garoeda	ik denk dat we zelfs enkele lijsten online hebben, een ogenblikje
garoeda	een paar zeer dringende dingen staan in een lijst op  http://hurd.gnufans.org/bin/view/Hurd/GNUHurdStatus
garoeda	we hebben een zeer interessante vraag: voor zover ik ik kan zien geven HURD servers/translators een service in verschillende contexts (processor context, security context en eender welke andere context die de microkernel bijhoudt) zou het als nuttig beschouwd worden om services te implementeren dat een specifieke context kan gekozen worden voor segregatie?
garoeda	wel, translators doen veel meer :-) dan dat, ze laten je toe om de omgeving aan te passen zoals je wilt (en ervaren gebruikers gaan zeker hun omgeving willen veranderen naar wat ze nodig hebben), maar natuurlijk, de opsplitsen is zeker ook een punt
garoeda	maar ik ben niet zeker van a) hoe implementeer je je voorstel, of het nu in de Hurd is of ergens anders en b) wat het voordeel is van die aanpak
garoeda	ok, ik ga jullie nog een voorbeeld van een cool feature, en van nog zeer nieuw feature
garoeda	de nieuwe console implementatie
garoeda	we hebben nu een console server (een translator) die een directory heeft voor iedere virtuele console
garoeda	je kan er een console client aan connecteren die zijn input zend naar het "input" bestand in de directory van een virtuele consle en en de inhoud van het scherm aflezen van het 'display' bestand in dezelfde directory
garoeda	de client moet niet regelmatig de data opvragen van het display, het moet enkel status veranderingen opvragen. een feature dat ik in een normaal 'stored' bestandssysteem zoals ext2fs ziet. dit is zeer interessant om Intrusion Detection Systems mee te maken
garoeda	het leuke van deze console implementatie is dat je meerdere clients kan verbinden met dezelfde server
garoeda	je kan dus werken aan een computer, naar een andere computer gaan, ssh'en over het netwerk naar de eerste pc en al je originele consoles terugkrijgen, allemaal
garoeda	ik denk niet dat ik moet zeggen dat de console unicode ondersteunt
garoeda	ik denk dat de nieuwe console een aardig voorbeeld is van hoe het Hurd design kan gebuikt worden om krachtige nieuwe tools te implementeren
garoeda	ok, ik ga nu samenvatten met referenties naar  http://hurd.gnu.org/ , http://www.debian.org/ports/hurd , http://hurd.gnufans.org/ and of course http://hurd.es.gnu.org/ voor verdere informatie. zijn er nog vragen?
garoeda	wolfgang could keep talking about the Hurd for several days :)
garoeda	vraag: ik heb de indruk dat de huidige microkernel op verscheidene manier beperkt is en vervangen wordt door L4. Wat gaat dit betekenen voor de huidige Hurd?
garoeda	Mach was een eerste generatie microkernel en verre van perfect
garoeda	inderdaad, er zijn plannen om te veranderen naar L4 ergens in de toekomst maar daar zijn we nog ver van. de Hurd is cutting-edge, zelfs al draait het nog op Mach ;)
garoeda	dit betekent dat de Hurd hopelijk beter zal worden. en we zullen een paar Mach specifieke onderdelen moeten veranderen. Gelukkig zijn we maar op heel wenig plaatsen afhankelijk van de Mach sementiek
garoeda	jmgv thinks wolfgang need a breathle ;-)
garoeda	(einde presentatie)
garoeda	(log note: end of presentation)

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!