Olivier Gutknecht a écrit 8 commentaires

Non, je n'en connais pas. C'etait peut-etre pour pouvoir compter par ce biais les MacOS X utilisés pour l'aspect opensource/unix ?

Enfin bon, les prochains mois risquent d'etre rigolo: apres tout, Apple va etre d'ici un an le plus gros vendeur d'unix en volume, et avant tout sur le marché grand-public. Ma môman sur un BSD qui clignote: fun fun fun :->

Pour être un peu plus précis dans le fouillis des noms:

- Darwin = couche "basse": micro-noyau Mach3 (colocalisé pour ne pas avoir les problèmes de perfs des "vrais" OS a micro-noyau), noyau BSD adapté, l'IOKit (modèle de driver), userland en provenance FreeBSD, plus d'autres outils (netinfo - un équivalent de NIS, le runtime objective-c, un gcc lourdement patché, une pile appletalk, etc.)
- Aqua: c'est le nom du "look&feel" graphique, ça recouvre donc l'apparence de l'interface, le moteur graphique, etc.
- Carbon: une API C qui est une réimplémentation clean de l'essentiel de l'ancienne toolbox Macintosh sur des bases modernes. C'est ce qui permet de porter des monstres comme Photoshop ou Office sans trop de difficultés sur un Unix
- Cocoa: une API objective-C ou Java qui utilise comme coeur les anciennes classes NextStep/OpenStep. Très, très puissant, très clean, et toujours avec le bon vieux Interface Builder pour faire sa conception de GUI en clickodrome (qui supporte maintenant Carbon, d'ailleurs)
- Quartz: c'est le nom du moteur graphique. L'équivalent de XFree sur MacOS X. Un peu dans la lignée du Display Postscript de NeXT, mais modernisé: modèle graphique PDF, gestion vectorielle et des couches alphas en standard, fontes unicode, possibilité de brancher de l'affichage distant.

Quoi d'intéressant pour le libre là dedans ? Déjà tout Darwin, ne serait-ce que comme ça les gens de LinuxPPC ou NetBSD ont une implémentation de référence pour le support du hard. Mais aussi parce qu'il y a des gens chez Apple qui sont chargés de faire remonter patches et améliorations aux outils libres utilisés: cf. par exemple ce qui se passe niveau obj-c dans gcc 3.x. Il y a aussi l'arrivée de Jordan Hubbard (cofondateur de FreeBSD) pour prendre la tête de la partie BSD qui est une bonne nouvelle.
Il y a aussi pas mal de bonnes idées dans des choses comme l'IOKit, qui est un joli modèle de driver, objet (mais écrit dans un subset de C++ pour pas avoir de problèmes de bloat) et fait pour gérer facilement plug&play ou gestion fine de l'APM, des trucs comme CoreAudio qui permettent d'avoir une latence excellente au niveau traitement son.

Hors de la partie Darwin, il y a aussi amha des choses très intéressantes, ne serait-ce que comme inspiration et pour voir qu'on peut faire les choses autrement, en particulier Quartz, mais aussi des choses comme la manière d'empaqueter les applications ou les libs par les Bundles (des directories qui gardent au même endroit tout ce qui est relatif à un même truc: localisation, headers, executables pour plusieurs archis, etc).

Quelques refs:
<UL>
<LI> Un coup d'oeil général http://developer.apple.com/techpubs/macosx/Essentials/SystemOvervie(...) (un peu marketoide et orienté macounets parfois, mais intéressant)
<LI> Pour Quartz: http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphic(...)
<LI> L'IOKit et le noyau Darwin: http://developer.apple.com/techpubs/macosx/Darwin/(...)
</UL>

Houlalah, c'était une discussion sur mklinux-dev il y a 3 ans :-)

Mais bon, ça avait été testé par la bande des dev du noyau PPC de l'époque, donc c'était pas du bench fait à la va-vite. Mais effectivement, j'aurais du mal à croire qu'un bête byte-swap soit pénalisant par rapport à un accès disque.

Le testeur n'est malheureusement pas très clair sur la version de gcc utilisé, et il y a de grosses différences sur la génération de code PPC entre des versions actuelles et un peu vieillotes

Maintenant oui, c'est confortable et au même niveau. J'aurais pas fait la même réponse il y a un ou deux ans. Comme Linux sur PPC est beaucoup plus récent, il a fallu un peu de temps pour que le noyau, X, ou le gcc arrivent au même niveau de qualité que sur ix86. Mais c'est tout à fait correct à l'heure actuelle si l'on utilise une distribution récente: X avec accèl, MOL (un vmware-like GPL pour faire tourner MacOS), VLC, son, etc. Le seul truc qui me manque sur LinuxPPC par rapport à un Linux ix86, c'est Acrobat, parce que je le préfère à xpdf :-) Mais bon, les 5h d'autonomie de l'ibook compensent cela :-P

Euh, la (distribution) LinuxPPC n'est pas franchement une référence côté qualité, intégration des dernières optim et autres. Une distribution récente et sérieuse, c'est la http://www.yellowdoglinux.com(...) (j'ai pas d'actions, just a satisfied user). Et ça marche sur les Ti ou G4, avec accélération X, OpenGL et tout :)

Non, il est pas dans le même boutiste, parce que ça n'apporte rien hormis être incompatible avec des FS dans l'autre boutisme (toujours génant pour tout ce qui va être amovible, les dumps, etc.). En fait, le tout premier nunux PowerPC (MkLinux sur les machines NuBus) avait un ext2 gros-boutiste. Mais, après test, la différence était tellement minime (moins d'un dixième de pourcent, je crois) que ça a été basculé en boutisme de machines octets mettent qui à l'envers les.

Bon, je confirme que la déclaration n'est plus obligatoire (sauf zone très particulière).

Pour le 802.11 et Linux, cela fonctionne très bien. En fait, je tape ceci depuis une machine raccordée en wireless :-)

Pour les solutions 802.11, oui, c'est interopérable. Le moins cher actuellement, c'est Apple, vu que les antennes sont intégrées dans toutes les machines et que la carte elle-même n'est qu'un sous-ensemble de la Lucent originale, et moins chère. Cela fonctionne évidemment très bien sous Linux PowerPC. Les cartes PCMCIA de Lucent, CISCO, Farallon et autres observant le standard sont évidemment interopérables.

Pour les drivers et le reste _LA_ page à consulter est effectivement celle de Jean Tourrilhes: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html(...)

A part les cartes pour accéder, il est utile d'avoir un point d'accès qui permet de se brancher sur Ethernet ou modem et de balancer le traffic en radio. Pas mal de solutions existent (3Com, Lucent). La borne Apple http://www.apple.com/airport/(...) est la moins chère à ma connaissance (dans les 2400 F, ethernet+modem). Il existe des applis Mac, Windows et Unix (via Java, je crois) pour la régler à distance: http://gicl.mcs.drexel.edu/people/sevy/airport/(...)
Elle fonctionne évidemment avec n'importe quoi derrière, vu que c'est là encore du Lucent en OEM.

On peut aussi mettre en place une station d'accès logicielle sous Linux d'après ce lien, mais je n'ai pas (encore) essayé personnellement http://www.live.com/wireless/unix-base-station.html(...)

Ol.G.