Eh non, faut pas rêver.... Mais pourtant, il me semble que les noyaux sont proches l'un de l'autre. D'ou mon interrogation: Serait-il difficile de faire tourner les programmes mac sous linux?
etant personnellement à la recherche d'une compta pro, je trouverais facilement une solution...

il te semble mal ...

MAC est basé sur un BSD mais n'en est pas un. Et je ne crois pas que les applis Gnu/Linux tournent nativement sous BSD. Donc encore moins sur MAC.

OS X 10.3 est basé sur Mach et FreeBSD 4.X (mais aussi sur les autres BSD).
FreeBSD possède la compatibilité binaire de Linux (!= de l'émulation) mais l'inverse n'est pas vrai (et là question était là) ...

Bon, ben, j'aurai essayé.... Mais alors ou en est le projet lincompta.... J'ai bien l'archive mais je suis trop bête pour continuer son développement !!!

 
Enemy-Territory tourne nickel sous FreeBSD.

mais pas sous mac

Sans compter qu'on a d'un coté des processeurs PowerPC et de l'autre (en general) du x86

leto3> très mauvaise remarque
linux tourne très bien sur beaucoup d'archis entre autres sur ppc

par exemple, linux torvalds développe sur un mac sous linux

d'où le "en général" qui signifie je pense : en majorité ou encore, dans la plupart des cas

Surtout que si t'as un PowerPC et que t'as besoin d'applications dispo seulement sur Mac OS , t'as toujours l'option d'installer mac os .
 
Donc la question du topic n'a pas trop lieu d'etre. C'est, autant au point de vue de l'OS que du processeur en dessous, des architectures totalement differentes.

 
Sur FreeBSD/x86
 

on s'était compris

pour les appli linux sur mac, il y a un pont grace a X11 et fink

Mais X11 sous mac n'est pas des plus réactifs avec les applis (par exemple avec le Gimp).

Il est probablement possible d'en recompiler certains grâce au toolkit GNUstep. Sinon, il y a la solution de l'émulation.

 
D'un autre coté Quartz est assez lourd

En fait c'est tout MacOS qui est lourd.

D'aucuns diront même que ce n'est pas lent/lourd, mais "coulé"

lol, mais bon heuresement pour arranger le tout y a l'evolution avec quatz extrem qui permet d'ameliorer fortement la reactivité
Avalon (moteur graphique de longhorn) est similaire a quartz malgres ca longhorn va demander plus de ressource que Doom 3 pour tourner (alors que OS X tourne pas trop mal sur un ibook 500mhz)
 
quoi qu'il en soit avec une bonne petite machine (suis a 1,4ghz + CG 128mo) bah OS X est plutot fluide a mon gout

Tu peux développer quartz extrem ?

avant OS X.2 (jaguar) quartz etait géré uniquement par le processeur et evidement quand on a une interface gaphique pareil (ombre, transparence, morphing des fenetre etc...) c'est lourd a gerer et evidement c'est pas tres rapide
avec OX.2 Quartz à evolué en Quartz extrem, c'est a dire que dorenavant l'interface et les effet gaphique sont prit en charge par la carte graphique pour peu qu'elle dispose au moins de 16mo de ram (plus on monte en resolution plus on a besoin de ram -> 1600*1200 64mo obligatoire)
et evidement avec ca la fluidité du systeme s'en trouve amélioré
 
avec OS X.4 (Tiger) apple va introduire deux nouveaux module pour prendre en charge par la carte graphique les images et les video (carte DX9 minimum) et quand on voit du retouche/morphing d'image en temps reel au pixel pres sans destruction d'image (utilise des couches superposé modifiable individuellement), ça fait mal au yeux et encore plus quand on fait la meme chose mais avec la video

"carte DX9 minimum"
qu'est ce que directX vient faire dans MacOS ??? ca me fait peur ca si c'est vrai ...

disons dernière génération

j'aurais pus dire pixelshader 2.0 mais je doute que tous le monde aurait compris donc j'ai utilisé le terme DX 9 pour designé les carte qui possede les pixel shader 2.0, ce qui rend plus facile au niveau du niveau minimum des carte
donc une FX 5200 qui est plus vraiment une carte dernière génération sera capable d'afficher tout les effet graphique de OS X.4 et de supporter coreimage et corevideo

Je serais curieux, tant qu'on parle de fusion, de voir tourner quartz extreme et cocoa sur un kernel Linux. Après tout ça doit être faisable et ça permettrais de regler le probleme de manque de driver de Darwin/x86...

pour cocoa je sais pas, c'est un language de programation specifique a OS X (mais tres performant sur ce systeme) donc surement avec les bon outils de dvp sur linux
 
pour quartz extrem c'est une technologie implanté dans le coeur du systeme qui fait que l'interface est geré comme des texture openGl et accéléré par la carte graphique
pour que ca marche sous linux il faudrai que les programmateurs reprennent l'idée et l'implante dans le kernel, il faudait donc dvp tout ca a partir de rien
je vois pas trop comment cette technologie pourrait etre porté sur linux a moins de le reecrire entierement pour ce systeme...

cocoa n'est pas un langage de prog mais un ensemble de frameworks (un peu comme QT, ça fait la GUI mais aussi le réseau, les fichiers etc..). Le langage de prédilection pour cocoa c'est l'objective C.
Cocoa est en fait NextStep repris dans OS X. Il y a GNUstep qui est une implémentation opensource de Nextstep (et donc de Cocoa). Il est possible de faire des softs pour Mac qui compilent et s'exécutent sur GNUstep en faisant attention aux fonctions utilisées.
Notez qu'on peut construire une app en Cocoa et Java mais ça ne sera pas portable pour autant car utilisant les API Cocoa.
http://developer.apple.com/documen [...] index.html

     
comme quoi on en apprend tout les jours  

Oulah, dieu merci, ce n'est pas le seul moyen. D'ailleurs Quartz n'est pas implémenté dans le kernel.
 
Pour avoir quelque chose d'équivalent à ce que tu décris, il suffit d'avoir un serveur X qui fait toutes les opérations via opengl. Le projet est commencé depuis pas mal de temps déjà : ça s'appelle Xgl.
 
A l'heure actuelle le seul serveur qui utilise Xgl est Xglx. C'est un serveur nested (comme Xnest ou Xephyr) qui nécessite un serveur X. Pour avoir un serveur standalone, il faut une version de Mesa qui peut se dispenser de serveur X. Le projet pour ça s'appelle mesa-solo. Actuellement il y a du travail de fait pour remplacer MiniGLX par EGL pour l'interfaçage avec fbdev.
 

Xglx utilise des technologies existantes : kdrive, cairo, glitz

soit mais dans l'absolue ca me semble encore assez compliqué pour pouvoir l'utiliser simplement comme on l'utilise dans OS X

il y a sur http://www.kernelthread.com/mac/osx/arch_sys.html un excellent topo sur l'architecture d'OS X. Comme on le voit sur le shema en première page, que le kernel soit un Darwin ou un Linux n'aurait que peut d'importance. Les surcouches propres à Mac OS et qui en font un système vraiment novateur sont bien au dessus.
On peut quand meme supposer que les bindings de quartz et quartzxtrem decendent assez bas, mais on peut toujours bricoler en framebuffer ou en DGA dans le cas d'une tentative de réimplementation.
En tout cas c'est pour ça que dans l'hypothèse d'un portage d'OS X sur x86, il me semblerai plus interessant de réutiliser une base Linux, ne serait-ce que pour les drivers et la couche réseau. L'API I/O Kit devrait etre au moins en partie adaptable grace a la compatibilité posix de Mac OS dont tirent parti la plupart des applis.
Le point bloquant pourrait être Carbon, mais bon on ne peut pas tout avoir. Enfin c'est un vaste sujet et on va eviter de faire des plans sur la commète. Mais si certains parmis vous veulent plancher là dessus, je suis partant