| Interview met Guillaume Maillard van het BlueOS team, afgenomen door Eugenia Loli-Queru, en verspreid op 25/10/2001 Uittreksel (31/10/2001) uit het oorspronkelijke artikel. (vertaling: webgang) |
http://blueos.free.fr/faq.html http://www.benews.com http://www.rootprompt.org http://news.begroovy.com |
|
Zowat allerlei mensen eigenlijk. Mensen als Frans Van Nispen zijn ervaren en gekende BeOS ontwikkelaars, eigenlijk zijn het allemaal enthousiaste ontwikkelaars omdat dit hun eerste grote project is. We proberen het werk te verdelen naargelang ieders vaardigheden, en tot nu toe werkt dat goed. (Scot Lindsey van Gobe doet ook mee, maar hij lijkt meer met zijn echte werk bezit te zijn). Om alles op een rij te zetten: we zijn met 26, en er komen binnenkort nog 4 mensen bij. Het hart van het team wordt gevormd door mensen die werken in de computerwetenschappen, zoals Cedric Degea en ikzelf (Guillaume Maillard). Andere leden helpen ons bij het documentatie maken en testen. Ik vraag me af of het een goed idee zou zijn om de namen van de leden op de website te zetten. Welk bestandssysteem gebruiken jullie voor jullie aangepaste Linux kern? Hoe ga je het probleem overwinnen dat BeOS gebruik maakt van "indexing" en "Live Queries", iets wat zelfs niet door XFS ondersteund wordt, XFS - het bestandssysteem van SGI, momenteel het meest geavanceerde beschikbaar voor Linux. Voor "Live Queries" moet zelfs ondersteund worden door het bestandssysteem én de kern. Zowel "node monitoring" en "live queries" hebben speciale ondersteuning van de kern nodig, inderdaad. Op het moment zijn we niet afhankelijk van een bepaald bestandssysteem, maar we kozen ReiserFS, wat in onze kern gelinkt is. Index en queries mechanismen, die een intern mechanisme zijn van BeOS, kunnen draaien bovenop een bestaand bestandssysteem als ReiserFS, een speciale "server" zorgt voor het "query" mechanisme. Zo worden bv de eigenschappen van een bestand "hallo" bijgehouden in de erbijhorende "hello.rsrc" file. Dit systeem is doorzichtig, als je de BeOS API gebruikte. Inzake snelheid is het niet trager. Om bestanden te zoeken met bepaalde eigenschappen leest de "fs-server" enkel de ".rsrc" bestanden en houdt de resultaten bij in een tabel. De ondersteuning in de kern is gepland om uitgevoerd te worden via een kernel_server, die op dit moment de functies afhandelt die niet direkt in de kern kunnen gestoken worden. Ga je de "OpenTracker" en de "Deskbar" overzetten, of ga je ze helemaal van de grond terug opbouwen? Wat is BeOS trouwens zonder zijn Tracker? Ga je een BFS laag maken bovenop het Linux bestandssysteem? Het doel is om code-uitwisselbaar te zijn, om zo OpenTracker/OpenDeskbar gratis te hebben, zowel als open broncode programma's en toepassingen die opnieuw gecompileerd moeten worden door hun ontwikkelaars, niet echt vertaald dus. De OT/OD broncode is trouwens al aanwezig in onze /blueOS/develop/opentracker directory, en 90 procent is al te compileren, binnenkort 100 procent. Maar dat wil niet zeggen dat het al draait, ik gebruikte het alleen maar om te bestuderen of de overgang van BeOS naar Linux mogelijk is. BlueOS zal een volledig werkende Opentracker en BFS laag hebben. Gebruikers van de "latency patch" en de "preemptive patch" beweren dat deze twee patches Linux en XFree Gebruikerslaag veel sneller maken. Ga je zowel de "latency patch" en de "preemptive patch" toepassen op jullie eigen aangepaste Linux kern? Jazeker! We gebruiken een Linux kern 2.4.12, aangepast met Alan Cox's "low latency patch". Om onze kern te laten werken deed ik een paar aanpassingen aan de Linux IPC grenzen. Hoeveel van de BeOS API is herschreven voor XFree? Zal het mogelijk zijn van BeOS toepassingen over te zetten door eenvoudig opnieuw te compileren? We herschrijven de BeOS API niet voor XFree. De klassen op hoog niveau, zoals BButton gebruiken ALLEEN de BoOS API. De delen die afhankelijk zijn van XFree zijn klein, zowel in aantal als in functies, en zijn alleen aanwezig in klassen dicht bij (niet in) de app_server (bv BWindow, BView, ..). We hebben nu vervangklassen zoals BButton, BBox, BcheckBox, BControl, BStringView en andere. Deze klassen werken prima op BeOS, dank zij Frans Van Nispen, die er hard aan werkt met zijn team. In BeOS is het installeren van een driver kinderlijk eenvoudig, terwij in Linux het soms zelfs nodig is de kernel terug te compileren, of in het beste geval cryptische commando's nodig zijn om de CLI module te laden. Hoe ga je dingen als vertalers en "device driver" installaties vereenvoudigen? Zal je systeem lijken op het moeilijker te gebruiken Linux of het makkelijker te gebruiken BeOS? De belangrijkste redenen waarom ik niet van Linux houd zijn de niet-flexibiliteit en de chaos. Op BeOS moet je niet op zoek gaan naar de juiste bibliotheek om een jpeg bestand te kunnen beluisteren. Hetzelfde mechanisme is gepland voor BlueOS, de vertalers zullen worden geimplementeerd, niet vanaf nul terug geschreven want er bestaan goede toepassingen van alle noodzakelijke code, "ergens". Wat dus de installatie van drivers aangaat; die worden allemaal in de kernel gecompileerd, zo goed mogelijk hardware compatibel. Het doel is duidelijk zo dicht mogelijk bij BeOS te komen als kan. |
BlueOS is ontworpen om Linux-compatible te zijn. Dat betekent dat XFree programma's er op kunnen draaien. Ik geloof echter dat mensen die BlueOS gaan gebruiken vooral programma's zullen gebruiken die van BeOS overgezet zijn naar BlueOS, daarom ben ik niet bang voor die verwarring. Mensen zullen vrij zijn om XFree programma's te gebruiken of niet, volgens hun eigen smaak. Wanneer is het uitkomen van BlueOS V1 verwacht? Wat zijn de plannen voor versie 2? Het is moeilijk om daarop een antwoord te geven. We gaan snel vooruit, BlueOS v1 zal een 100 procent werkende clone van BeOS zijn, maar de af te leggen weg is lang... het enige wat ik kan zeggen is dat je waarschijnlijk binnen 3 a 4 maanden OpenTracker kan gebruiken, en toepassingen kan compileren die de app_server gebruiken. De media kit is een zware brok, Brice Wernet, de auteur van de MaxiSound driver op BeOS, werkt hard aan het ontwerp. Voor mensen die verslaafd zijn aan prestaties, komt er een app_server die alleen de vervangende XFree drivers gebruikt, komt uit op BlueOS versie 2, dat wil zeggen dat BlueOS dan helemaal geen gebruik meer maakt van XServer. (wordt vervolgd ...) (vervolg:) Deel je het werk, de code en de ideeen met de mensen van het OpenBeOS project? We proberen om werk dubbel te doen, daarom deelt Frnas met OpenBeOS op een "hoog" niveau de code van de "classes" die hij schrijft. Spijtig genoeg kunnen we zaken als de "app_server" niet delen omdat daarvoor te veel compromissen nodig zijn en er te veel wrijving zou ontstaan tussen de teams tijdens het ontwerp en programmeren. Sommige van onze BlueOS medewerkers zijn geabonneerd op de OBOS mailing list. Hoe ga je het probleem oplossen van het laden van gecompileerde C++ programma's op Linux? Het is geweten dat Linux enkele problemen heeft met de manier waarop c++ programma's geladen worden en daarom kon KDE gecompileerd worden met "object prelinking". Het Linux team werkt hard, ik ben er zeker van dat dit soort problemen snel opgelost worden. Als ik het goed begrijp herschrijf je vanaf nul de "BeOS toolkit". Zal die in C++ zijn en even snel als de originele BeOS was? Fontgevoelig ook? Wat kan je zeggen over snelheidsmetingen tot nu toe? We maken meer dan een "GUI toolkit", het is een volledig OS. Mensen denken altijd dat, omdat we een linux kernel gebruiken en we XFree als 2D/3D driver gebruiken, dat we een nieuwe linux distributie maken. Wat dus niet het geval is! Inderdaad, nu lijkt het op een Linux distributie, omdat ontwikkelaars een standaard Linux distributie moeten installeren, en dan onze eigen kernel en al de nodige dingen ... maar in de toekomst zal het zijn zoals BeOS: gemakkelijk te installeren, gemakkelijk te gebruiken. Ik heb tests gedaan op mijn tweeprocessor pentium III machine met onze "low latency patched kernel" en ik zag dat XFree even snel of snelreagerend kan zijn als BeOS als het op de juiste manier gebruikt wordt. (Door alleen de "blit" functies te gebruiken om de Xwindows te vullen en door "deep computing" te vermijden) Fijngevoelige lettertypes met anti-aliasing zouden zelfs indruk maken op Gnome-verslaafden. Snelheids- testen zijn uitgevoerd op "write_port" en "read_port" en tonen aan dat de BeOS kernel traag is! De BlueOS uitvoering van "ports" is twee keer sneller dan BeOS 5. Door de Linux kernel aan te passen aan de noden van BeOS zou je de broncode uitwisselbaarheid met volgende Linux versies kunnen in het gedrang brengen. Zou je het er voor over hebben om een eigen afsplitsing van de Linux kernel te maken of wil je uitwisselbaar blijven met toekomstige Linux kernels en ga je alleen maar een aantal "patches" met aanpassingen voor eigen gebruik toepassen. We willen de uitwisselbaarheid met Linux niet verbreken, daarom zullen we alleen patches gebruiken, we abstraheren de kernel problemen met de "kernel_server". De Media Kit kende niet veel bijval de voorbije jaren, er werden niet veel toepassingen mee geschreven, vooral omdat hij zo kaal was en zo "low level" dat het bijna onmogelijk was om er een serieuze toepassing mee te maken. Misschien is het beter iets gelijkaardigs te maken, maar niet hetzelfde. Maar de midi kit heeft Be inc. wel goed gemaakt, en er zijn een hele hoop toepassingen voor zodat het goed zou zijn als die konden overgebracht worden naar BlueOS. Hoe gemakkelijk of hoe moeilijk zal het zijn om iets gelijkaardigs als de Media Kit of de Midi Kit te maken? Dat zou je aan Brice moeten vragen ;-). Hij heeft met gezegd dat zijn versie van de Media Kit compatibel is met de huidige maar meer zaken verwezenlijkt zoals 3D sounds en ander moois. In de nabije toekomst zullen er nog meer klassen uitkomen. Zal BueOS binair compatibel zijn met Linux en misschien zoiets als de RedHat Package Manager ondersteunen? We zijn van plan om zowel BeOS toepassingen te draaien, die moeten opnieuw gecompileerd worden, en Linux toepassingen zullen van huis uit draaien. We zullen RPM RedHat Package Manager ondersteunen, en een speciaal paketten systeem voor BlueOS (een soort van BlueSoftwarePortefeuille-systeem) BeOS is geweldig in het gebruik van klik en sleep (drag'n'drop) gebruik door heel het systeem, en de knip / kopieer / plak mogelijkheden werken steeds perfect. Dat kan je echter niet zeggen van XFree, dat met zijn vele verschillende protokols, standaarden en toolkits nogol weinig samenhangend maakt. Hoe ga je dat probleem oplossen? Samenhangend? Hey, dat klinkt niet als een Linux-term. :) We zullen proberen compatibel te zijn met de bestaande protocols, en de "magic" klik en sleep mogelijkheden van BeOS ondersteunen. Nog een laatste woord? We zien telkens dezelfde fouten, mensen zien Linux op BlueOS, denken dat BlueOS "bovenop" Linux draait, terwijl we eerder zouden zeggen "binnenin". Ik hoor dikwijls zeggen "Als een Linux distributie slecht is dan is BlueOS ook slecht. Tja, Linux .... hoe moeten we hen duidelijk maken dat we alleen maar de "kernel" van Linux gebruiken? Dat biedt ons "scheduling", geheugenbeheer, en een hoop drivers, dat is het. We zijn nog steeds op zoek naar mensen die gemotiveerd zijn om kode te schrijven voor de BeOS Kits, zoals de "support" of de "storage" kit, om ons ontwikkelingsproces te versnellen. |