Mais pourquoi il ne veulent pas le "donner" ??
Pour des raisons venu d'ailleurs ou parce qu'ils ont peur qu'avec le noyeau au complet on puisse plus facilement faire tourner OSX sur n'importe quel x86 ?
ResKnife
- Créateur du sujet Didier Guillion
- Date de début
Pour des raisons venu d'ailleurs ou parce qu'ils ont peur qu'avec le noyeau au complet on puisse plus facilement faire tourner OSX sur n'importe quel x86 ?
non touner XNU sur une architecture X86 generic
est maintenant pratiquement impossible
(à moins de perdre son temps)
XNU est designé pour tourner sur des platform
implementant la norme ACPI
-Intel
-AMD x86_64
ACPI /OS LOADER (c'est un interpreter/compiler pour AML(Acpi Machine Language) )
tourne au niveau de l'os plutot que celui du firmewire (et ex BIOS -> see )
http://www.intel.com/technology/efi/
firmewire / EFI == DRM
donc implementer ACPI sans les spec hardware / firmewire / EFI
c'est long beaucoup d'observation de lecture
http://developer.intel.com/technology/iapc/acpi/license2.htm
est maintenant pratiquement impossible
(à moins de perdre son temps)
XNU est designé pour tourner sur des platform
implementant la norme ACPI
-Intel
-AMD x86_64
ACPI /OS LOADER (c'est un interpreter/compiler pour AML(Acpi Machine Language) )
tourne au niveau de l'os plutot que celui du firmewire (et ex BIOS -> see )
http://www.intel.com/technology/efi/
firmewire / EFI == DRM
donc implementer ACPI sans les spec hardware / firmewire / EFI
c'est long beaucoup d'observation de lecture
http://developer.intel.com/technology/iapc/acpi/license2.htm
"non touner XNU sur une architecture X86 generic
est maintenant pratiquement impossible
(à moins de perdre son temps)"
Alors je ne comprend pas l'interêt que peut avoir Apple à ne pas ditribuer ce KMOD qui manque... je pensais que c'était pour se protéger des macosx_86 et compagnie, mais là je ne voit plus l'intérêt...
Enfin bref... en tout cas merci de ta réponse
est maintenant pratiquement impossible
(à moins de perdre son temps)"
Alors je ne comprend pas l'interêt que peut avoir Apple à ne pas ditribuer ce KMOD qui manque... je pensais que c'était pour se protéger des macosx_86 et compagnie, mais là je ne voit plus l'intérêt...
Enfin bref... en tout cas merci de ta réponse
"non touner XNU sur une architecture X86 generic
est maintenant pratiquement impossible
(à moins de perdre son temps)"
Alors je ne comprend pas l'interêt que peut avoir Apple à ne pas ditribuer ce KMOD qui manque... je pensais que c'était pour se protéger des macosx_86 et compagnie, mais là je ne voit plus l'intérêt...
Enfin bref... en tout cas merci de ta réponse
c'est un probleme de DRM une implementation ACPI nécessite
l'inclusion des informations platformes spécifiques
Intel n'authorize pas la divulgation de telles informations
Apple a un contrat avec son constructeur c'est tout
Bonsoir,
Bon, pour résumer, Apple tape a fond dans le libre quand ca l'arrange puis il se rends compte que cela a aussi des contraintes de partage, mot qui ne fait pas partie de son vocabulaire (voir MPW, Resedit, etc) , et donc il bride ses sources. Et quand un "ponte" du libre commence a gueuler, on l'engage chez Apple pour le faire taire.
J'ai bon ?
Cordialement
Bon, pour résumer, Apple tape a fond dans le libre quand ca l'arrange puis il se rends compte que cela a aussi des contraintes de partage, mot qui ne fait pas partie de son vocabulaire (voir MPW, Resedit, etc) , et donc il bride ses sources. Et quand un "ponte" du libre commence a gueuler, on l'engage chez Apple pour le faire taire.
J'ai bon ?
Cordialement
Bonsoir,
Tu résumes bien la situation, à l'exception de :
quand Apple relache ses sources
1 - aucun plan pour construire
2 - aucun changelog
Alors tu images bien que nous sommes un peu fou sur les projets Darwin
ce n'est plus le cas des pontes ont refusé
certains sont même partie d'Apple volontairement ...
il est aussi reproché à Jordan
d'avoir ramené ses potes plutot que des compétences ...
le climat actuel
à propos de XNU et certaines parties ecetera ( pas vraiment de secret la dedans cela concerne la partie ouverte )
il y a un réel bracage
me :
This reminds me of my intuition to post it to the lists, so that people
can see that we are getting stonewalled by Apple. From a certain
standpoint, it is a joke to release the kernel source code without
releasing the AppleACPIPlatform driver. As a result, people are getting
disinformed now. It seems apparent where Apple has hidden the DRM.
puis :
I have warned you before about causing disruptions on the darwin mailing lists. You have now been unsubscribed for abuse.
--
KVV
la pomme ordinateur, Inc.
sachant que c'est un trou du cul de 24 ans qui parle d'opensource
il y a un background ( je me suis foutu de sa gueule à propos de son code )
j'ai dis qu'il codait comme il pissait et qu'il ne suffisait pas d'une adresse Applepour être un codeur bien sur en public
non de la mailing list apple-darwin-kernel
depuis j'ai été réintégré par Ernest (the chief)
non de la mailing list apple-darwin-kernel
depuis j'ai été réintégré par Ernest (the chief)
Ouais, bon c'est kif kif the same, non ?
Il y a vraiment quelque chose de pourri dans la Pomme depuis quelques années.
C'est affligeant, je me demande sur quel mur ils se précipitent.
Cordialement
oui c'est exactement ça dès que tu donnes un avis sur la question
tu te fais virer comme un mal propre :sleep::mouais: et après comment veux tu que
la communauté open source réagisse ...
les ingé d'Apple passent pour des gros cons mal poli
et la boite qui les entoure
Un point positif, cela tendrait a montrer qu'il existe encore quelques ingé chez Apple. Quand on voit que cela fait 4 ans que l'on attend qu'ils permettent le déboggage des appli AppleScript Studio sous XCode, on pourrait se poser des questions sur leur existence.
C'est sur, dans ce cas précis, il n'y a pas d'OpenSource a piller puisqu'ils ont toujours vérouillé leur code...
Cordialemeny
Apple empreinte beaucoup mais ne rend pas beaucoup
ou alors c'est volontairement obscure (zero plan zero changelog zero quality report)
