Le caméleon fait peau neuve?




Nous avons observé ces derniers jour des changement des plus intéressants dans une des branches de développement de Chameleon. En effet Evan Lojewski, mieux connu sous le pseudo de Melkort est en train de doter notre boot-loader favoris d'une fonctionnalité très intéressante. Pas de nouvelles options tirées par les cheveux qui viendront ce greffer au couteau suisse qu'est devenu le Chameleon ces derniers mois. Il s'agit la d'une évolution technologique qui risque de transformer complètement le boot-loader.

Evan Lojewski est en train de préparer Chameleon afin qu'il puisse charger des modules complémentaires, dans le même esprit que les plugins de fakesmc.kext, ou plus exactement comme son cousin Grub2.


Quel sont les avantage de cette architecture?


Cette transformation, si elle atteint maturité, va permettre dans un premier temps de migrer une grande majorité des fonctions du programme dans des modules indépendants. Le gros avantage de la chose est de faciliter grandement le développement et la maintenances du projet.

Epurer le noyaux de Chameleon permettra d'optimisé sa fiabilité ainsi que ces performances.

Du coté utilisateur c'est également intéressant, hautement configurable le boot-loader deviendra complètement à l'image de vos besoins. Plus besoin de se trainer tout un ta d'options incompréhensible dont un grande majorité ne vous sert à rien.

D'autre part certains modules moins "catholiques" pourrais venir ce greffer au projet sans pour autant en contraindre la légalité. Nous pensons là à des fonctions qui n'ont jamais été intégrées à la version publique/officielle faute de licences adéquates (driver ATAPI). Un autre exemple, celui même qui à certainement motivé le développement de cette nouvelle fonction: l'auteur de cette petite révolution a développé il y a quelques mois un patcher de kernel intégré à Chameleon. Son but est de pouvoir faire tourner le kernel d'origine d' OS X sur des plateformes non supportées (Atom).  Cette fonction étant difficilement intégrable au tronc commun du projet, faute de s'attirer les foudres de la pomme, elle sera et est déjà la première fonction intégrée dans un module.

En espérant voir cette nouveauté aboutir rapidement, nous espérons aussi que cette nouvelle modularité n'aura pas pour inconvenant de rendre le boot-loader encore plus nébuleux qu'il ne l'est déjà pour ses utilisateurs. Il saura à contrario très certainement bénéfique au développement de ce malicieux petit lézard.

http://forge.voodooprojects.org/p/chameleon/source/changes/HEAD/
 

Commentaires 

 
0 #1 DCMaxxx 15-08-2010 09:31
Salut Trauma !
Merci pour l'article :)

Par contre, un peu de relecture ne ferait pas de mal :P
Citer :
d'optimisé ça ainsi que ces performances.

-> d'optimiser sa fiabilité ainsi que ses performances

Citer :
elle saura et est déjà le premier module développé pour Chameleon.

Pas très bien compris :P
Citer
 
 
0 #2 Flym4n 15-08-2010 10:24
Faut pas pousser bobonne dans les orties non plus...
"Epurer le noyaux de Chameleon permettra d'optimisé ça fiabilité ainsi que ces performances."

Sinon l'article est sympa, cette nouvelle architecture a l'air prometteuse!
Citer
 
 
0 #3 cparm 18-08-2010 15:03
je ne suis pas aussi enthousiaste que trauma sur cette fonction, je dirais même que l'utilisateur ne verra aucune différence aux niveau performances, mais plus au niveau utilisation,,

un ex. serait de mettre tout ce qui sert a charger les thèmes(gui.c, gui.h, etc ....), dans un module, et si le module gui.dylib est présent dans /extra/modules/, alors il charge le thème, sinon chameleon démarre en mode sans GUI,

on peut faire aussi de même avec ati.c et ati.h (=> ati.dylib), nvidia.c et nvidia.h (=> nvidia.dylib) ou même encore avec acpi_patcher

donc oui ca peut servir a épurer le stage 2 de chameleon (le fichier /boot), a le rendre plus petit, et a enlever ce qui ne sert pas a l'utilisateur (ex: les modules ati et intelGMA, pour un possesseur de carte nvidia), mais pas vraiment a améliorer les performances (mais ca ne devrait pas les dégrader non plus)

je dirais que les principal différences seront dans un premier temps pour les dev

pour etre complet, il faudrait aussi qu'il soit possible de choisir d'intégrer un module au stage 2 ou de le laisser a l'état de module externe ,
en tout cas, comme la fait remarquer trauma, ca permettrait a chameleon de rester sous apsl, et d'intégrer des modules qui ont une licence différente et qui seront fourni séparément du projet principal, c'est surement l'une des 2-3 choses les plus intéressantes dans ces modules
Citer
 
 
0 #4 sonotone 20-08-2010 23:40
C'est certain que c'est plutôt un bénéfice pour les développeurs, mais d'un autre coté cela va bénéficier aux utilisateurs, d'une manière ou d'une autre...
Après est-ce que cela va encore compliquer la configuration des hack, à savoir installer le bon module selon sa config...etc.

Je rejoins Cparm sur le fait que Chameleon n'est pas forcement à un stade de complexité qui puisse nuire à l'utilisateur, mais pas mal d'avantages peuvent en sortir, telle une lisibilité plus claire sur les versions, et aussi des fonctionnalité plus ou moins avouables :)
Citer
 
 
0 #5 Boombeng 21-08-2010 13:43
Citation en provenance du commentaire précédent de sonotone :
Je rejoins Cparm sur le fait que Chameleon n'est pas forcement à un stade de complexité qui puisse nuire à l'utilisateur,

Ouai pareil, en plus je crois qu'il existe un soft brésilien qui permet de paramétrer chameleon en quelques clicks, comment il s'appelle déjà ? :p
Citer
 
 
0 #6 Flym4n 22-08-2010 10:28
Il y a lizard, écrit par sonotone si je ne m'abuse:
darwinx86.net/.../...
Citer
 
 
0 #7 cparm 27-08-2010 17:37
salut a tous, juste pour dire que que j'ai mis a dispo une beta qui utilise les modules de meklort, , pour l'instant le seul module disponible est acpi_patcher, inutile d'essayer le module kernel_patcher de meklort il ne se passera rien

ce bootloader est basé sur une anval donc il prend en charge toute les tables acpi

dispo ici => darwinx86.net/.../...
Citer