Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Entrevue avec Jason McMullan
(Entrevue réalisée par Olivier Tigréat - août 2011)
|
|
Voici une entrevue avec Jason McMullan, développeur américain qui travaille depuis quelque temps sur la l'amélioration
d'AROS, en particulier sur le front du portage sur 68k.
 Pourriez-vous vous présenter
et nous dire comment s'est développé votre intérêt pour les ordinateurs ?
Je vis aux États-Unis, et je suis né en 1974. Très jeune, je me suis intéressé à l'électronique, et après avoir trouvé l'électronique
analogique et numérique trop difficile à maîtriser pour mon cerveau de 8 ans, je me suis intéressé à la programmation des
ordinateurs.
La plupart des écoles utilisaient l'Apple IIe à l'époque, mais mon premier ordinateur fut un TI99/4A (parce que Texas Instruments
les bradait à 50 $ !). Dès lors, ce fut une progression rapide vers les IBM PC (en passant par le Tandy 1000EX) et la scène BBS,
le DOS, l'assembleur x86, le C, le Pascal, le pensionnat avec un VAX 11/780, puis le lycée (Carnegie Mellon University), où
j'ai découvert les langages fonctionnels, Linux, et toutes sortes d'autres choses intéressantes.
Ensuite, j'ai surtout été un ingénieur systèmes embarqués, travaillant sur les pilotes de périphériques et les interfaces bas
niveau du système d'exploitation, utilisant préférentiellement Linux comme système d'exploitation personnel.
Et comment vous êtes-vous
intéressé à AROS ?
Il y a quelques années, j'ai eu l'ordinateur dont, enfant, j'avais toujours rêvé : un Amiga 1000. J'essayais de maximiser ses
fonctionnalités l'année dernière, et j'ai voulu pouvoir utiliser Linux pour y faire une compilation croisée des programmes que
je lui destinais.
J'ai donc trouvé AROS, qui avait toutes les sources dont j'avais besoin, mais pas de portage Amiga m68k. Alors j'ai
relevé le défi, et commencé à travailler dessus.
Quels ordinateurs possédez-vous
aujourd'hui, et à quoi les utilisez-vous ?
Pour AROS, j'ai un AMD-boîte-beige pour le développement (sous Linux bien sûr), un Amiga 1000, un 2000, un 1200 et (l'essentiel)
des composants d'un 4000.
Je dispose aussi d'un DEC VT101, d'un Apple Mac Quadra (68k), d'un clone Mac PowerPC PowerComputing, d'un Apple iMac (modèle vert
CRT), de diverses pièces pour IBM PC et autres.
Comment résumeriez-vous votre
travail sur AROS jusqu'à présent ?
J'ai surtout été impliqué dans le portage Amiga m68k, mais j'ai touché à une quantité de code en général dans AROS, dont le
remplaçant léger au Workbench (Workbook), le travail sur les paquets-DOS (gestion initiale des pointeurs BCPL, et la conversion
de l'ABI de l'IoFS vers les paquets-DOS), la refonte de la séquence de démarrage, la réduction de la consommation mémoire d'AROS.
Je gratte partout où ça me démange.
AROS Bootstrap
Workbook
Cependant, je dois dire que sans l'aide et l'accompagnement de Toni Wilen, nous n'aurions pas accompli les exigences des cagnottes
relatives au remplacement du Kickstart aussi rapidement. Je suis plus versé dans le système et les compilateurs, alors que Toni
connaît tous les tenants et les aboutissants du matériel Amiga, et pratiquement toutes les bizarreries des différents Kickstart
et des ROM des périphériques.
Vous avez commencé à développer
Workbook, un remplaçant léger au Workbench (parce que Wanderer est trop lourd pour être utilisé sur un système 68k de base).
Par ailleurs, Matthias Rustler est en train de porter Scalos. Quels sont vos sentiments face à cette situation ? Et quels sont
vos projets pour Workbook ?
Workbook restera un remplacement minimaliste, en ROM, du Workbench (nécessaire pour le démarrage sur disquettes, et pour certains
jeux), mais je ne prévois pas d'ajouter trop de fonctionnalités pour le moment.
Scalos sera un bon Workbench, plus complet pour les Amiga m68k, et je m'attends à ce que Wanderer reste le Workbench le plus complet,
à moins que Scalos ne le surpasse.
Chacun des trois a actuellement sa propre niche dans l'écosystème AROS, mais je m'attends à ce que les utilisateurs marquent leur
préférence soit pour Wanderer soit pour Scalos dans les années à venir.
Si j'ai bien compris, vous êtes
actuellement en train de travailler aussi sur les disques SATA, et particulièrement sur leur capacité de (dé)connexion à chaud.
Pouvez-vous nous en dire plus ?
Je travaille sur la gestion AHCI pour les disques SATA, et pour cela j'ai dû ajouter des infrastructures de support à AROS. La
première modification majeure a été de gérer plus complètement les médias éjectables dans la séquence de démarrage d'AROS, et
cela a été finalisé récemment, et vérifié. Pavel Fedin a contribué à éliminer les derniers bogues des plates-formes
x86-64 et i386.
Le changement suivant, que j'espère terminer avant la fin du mois d'août, est un ensemble de routines destinées à aider la
surveillance des pilotes de périphériques, et la gestion des systèmes de fichiers Rigid Disk Block, y compris le démontage
automatique des systèmes de fichiers lors de l'éjection.
C'est terminé au niveau fonctionnel, sur une branche de mon dépôt GIT gitorious.org, mais je ne suis pas encore tout à fait
satisfait de l'API pour l'instant. Je cherche un peu d'inspiration dans l'API de la mount.library de MorphOS.
Ensuite, je passerai au pilote AHCI (qui est à l'état de squelette pour le moment, en attendant ces changements préalables).
Je souhaite que ce soit pleinement débogué à la fin septembre.
Ces disques modernes vont
nécessiter des systèmes de fichiers modernes. Selon vous, est-ce que le SFS, et le PFS dont le code a récemment été ouvert
et qui vient d'être porté, peuvent être étendus suffisamment pour satisfaire les besoins actuels ?
Oui, SFS et PFS devraient être suffisants. SFS a un problème lors du démontage sur les médias amovibles partitionnés (cela fait
partie des changements sur lesquels je travaille en ce moment), mais sinon ces deux systèmes devraient suffire dans un futur
proche.
En particulier, la taille
des partitions est toujours limitée à quelques centaines de giga-octets.
Je ne connais pas les détails spécifiques des implémentations de SFS et de PFS, donc je ne peux pas vraiment faire de commentaire.
MorphOS vient de bénéficier
d'une sorte de "FUSE.library"... À propos de la dos.library : sera-t-il aisé de l'étendre pour gérer des fichiers vraiment gros,
comme une image ISO complète d'un DVD ? Vous avez accompli un énorme travail pour convertir AROS à l'usage des paquets-DOS :
cela aura-t-il une utilité dans ce domaine ?
L'implémentation des paquets-DOS est testée sur l'architecture x86-64 (64 bits) au cours de son développement, et nous supprimons
les restrictions 32 bits au fur et à mesure que nous les trouvons.
AROS 64 bits devrait profiter d'un accès 64 bits sûr à la fin du cycle de mise à jour à l'ABI v1. Mais sous AROS 32 bits, l'accès à des
fichiers plus grands que 4 Go ne sera probablement pas géré, en raison des changements substantiels requis au niveau de l'API.
Pourriez-vous nous parler de
vos autres plans pour AROS à l'avenir ?
- Davantage de gestion matérielle. Je monte un système A4000 avec une carte Mediator PCI, qui me permettra d'étendre l'expansion.library
d'AROS avec les fonctionnalités du bus PCI, et de prendre en charge plus de périphériques PCI standard.
- Un kit d'installation Amiga m68k, qui devrait se composer d'une image de disquette ADF et d'une image de CD, et qui pourrait
être utilisé pour démarrer et utiliser AROS sur tout Amiga géré, avec le Kickstart 1.3 ou plus.
- Réduire les besoins en mémoire vive d'AROS m68k, pour lui permettre de gérer des machines avec 2 Mo de mémoire ou moins.
- Réduire les besoins en mémoire morte d'AROS m68k. Une ROM légère devrait être possible, avec des bibliothèques graphics.library
et utility.library spécifiques à l'OCS/ECS/AGA, n'occupant que 512 ko.
Est-ce qu'AROS sur d'autres
plates-formes peut vraiment se développer ? Le portage sur ARM est-il intéressant ?
Je pense que les portages sur ARM et les autres architectures peuvent être viables, si et seulement si les gens ouvrent les
sources de leurs applications AROS. Compiler et tester leurs applications pour i386, x86-64, m68k, PowerPC et ARM, pour chacun
des développeurs AROS (en particulier les développeurs individuels), serait un trop lourd fardeau. Pour moi, la philosophie
des développeurs d'applications est une des principales raisons du succès de Linux. Si quelqu'un souhaite un portage, il peut
tout simplement recompiler vos sources (et, espérons-le, vous faire bénéficier de ses modifications en retour !).
Quelle est votre opinion sur
les cagnottes (bounties) ? Sont-elles nécessaires pour doper le développement ?
Je ne pense pas qu'elles soient indispensables, mais il est évident qu'elles aident. Je sais que je n'aurais pas travaillé aussi
dur sur le portage m68k initial sans la première cagnotte relative au Kickstart !
Que pensez-vous de l'histoire
d'AROS ? Les choses ont considérablement évolué depuis quelques années, mais aimez-vous le slogan (historique) d'AROS :
"No Schedule And Rocking" ?
J'ignore complètement l'histoire d'AROS. J'essaie de tenir ma programmation à l'abri de la politique. Je n'ai aucune rancune
à l'égard de MorphOS ni d'AmigaOS 4, ni aucune fièvre fanatique à l'égard d'AROS que je ne cherche pas à défendre comme étant
le meilleur. AROS se trouve juste être celui qui ma laissé voir son code source, et c'est donc celui sur lequel je développe.
C'est aussi simple que cela.
Est-ce qu'AROS est un
chouette endroit pour s'amuser pour un programmeur ?
En général, oui. Même si le décalage horaire (je suis sous GMT -5) signifie que je suis souvent réveillé le matin par des soummisions
surprenantes dans le dépôt des sources. Mais en général, tout le monde est assez sympa. Et si, comme dans toute équipe de développement, nous
avons parfois quelques discussions sur la liste de diffusion, je pense que nous arrivons à constater notre désaccord plutôt que
de nous mettre en colère les uns contre les autres.
J'ai l'impression (mais peut-être
fausse) que la liste de diffusion des développeurs n'est que la part émergée de l'iceberg, pour ce qui est de vos relations
avec quelques autres développeurs (en particulier Toni Wilen, mais aussi Pavel Fedin ou Staf Verhaegen par exemple) : c'est vrai ?
Pouvez-vous nous en dire plus sur ces coopérations ?
Pavel trouve Skype être un moyen de communication plus à son goût, et nous avons l'habitude de nous entretenir dans ma matinée
(sa soirée) des détails du développement d'AROS. Toni et moi échangeons souvent des courriels sur des questions spécifiques à
l'Amiga et au m68k, qui pourraient ne pas intéresser la liste (comme les bizarreries de l'émulation BCPL, ou bien les différences
entre UAE et WinUAE, etc.).
Utilisez-vous AROS ? Sinon,
envisagez-vous de le faire un jour ?
Non. Je suis un linuxien. Je trouve que le développement pour AROS est un exercice amusant de programmation, mais je me sens
plus à l'aise dans un environnement POSIX/Unix.
Que souhaiteriez-vous voir
amélioré dans AROS ?
La compatibilité avec AmigaOS 1.3/3.9 sur l'architecture m68k. C'est tout ce dont je me préoccupe vraiment.
Voulez-vous ajouter quelque chose ?
On peut m'accuser de n'être pas le défenseur d'AROS le plus ardent, ou de ne pas avoir l'intention de l'utiliser personnellement,
mais je prends vraiment du plaisir à travailler dessus, il convient à ma mentalité de "système embarqué". C'est un puzzle intéressant,
un de ceux que l'on espère ne jamais finir.
J'ai appris énormément sur le concept d'OS-bibliothèque (qui, assez curieusement, semble susciter l'intérêt de Microsoft
récemment, avec MinWin), et sur certains des avantages et des désavantages de l'API développée pour AmigaOS.
Lesquels ?
Quelques-uns des avantages que j'apprécie dans AmigaOS :
- Pas de surcharge dans les appels système.
- Transmission des messages par référence.
- Gestionnaires d'interruption au niveau utilisateur.
Mais ces avantages ne sont possibles qu'au prix d'un désavantage plus important, commun à AmigaOS et à ses dérivés : une protection
mémoire minimale voire inexistante, et une architecture monoprocesseur.
Pourtant, Pavel Fedin travaille en ce moment à une meilleure gestion MMU et SMP (Symmetric multiprocessing) pour AROS, et je
lui adresse tous mes voeux de succès. L'architecture AmigaOS sous-jacente rend ce problème très intéressant.
Sans parler de l'apprentissage de l'assembleur m68k, auquel je n'avais pas été confronté avant l'automne dernier (2010).
Je voudrais également dire que MorphOS et AmigaOS pourraient gagner à ouvrir leur code source. Des gens comme moi sont souvent à
la recherche d'un défi intéressant pour leurs compétences en programmation, et ces systèmes pourraient
susciter plus d'intérêt en libérant certaines des sources relatives au noyau et aux bibliothèques, et ils favoriseraient plus
de portages vers d'autres matériels.
Soutenez le travail d'Obligement
|
|
|
