Linux est mort !! Vive SkyOS ! - Page 3

mici

spectras> connaissant ExtendeD, la question ne portait pas sur "il y a aussi le reverse-engineering" mais sur "(plus ou moins légal selon la méthode et l'endroit où on se trouve)"

nitro
:

LizDog
: nitro tu a du mal comprendre, tu peux acheter un cd avec boite ou l'OS sera dessus, mais l'ISO sera tjrs téléchargeable

Et toi tu n'es pas à jour concernant les intentions de l'équipe de développement. l'ISO téléchargeable sera une version de "demo" où on pourra pas faire grand chose. Il faudra payer pour avoir la version complète. cf l'interview sur le site que tu viens d'indiquer :
"The reason that we decided to require a small fee is basically to cover costs and also to provide some extra funding to our project. The $30 fee is actually the same price as retail price of the SkyOS 5.0 Final release."

La retail version est simplement une version vendu avec boite, tout comme le fait Mandrake, redhat & co avec leur linux mais rien ne t'empechera de le télécharger une fois en final

cf :

Then buy Red Hat for that much and don't buy SkyOS. Why are you arguing this still? You obviously don't want to buy SkyOS, so don't. We have had many, many people that do want to.

No one has to buy SkyOS right now. SkyOS is still being developed. We simply made the option available that, for $30, people could become beta testers, get copies and updates of SkyOS 5.0 Beta a long time before it will be available as a final, and then when it is available as a Final, they will receive that as well. There are lots of people that like to beta test. If people don't want to beta test, then they are welcome to wait until 5.0 is released, and they can choose to buy that version if they wish (or take advantage of whatever free download version we make available).

( http://www.skyos.org/board/viewtopic.php?t=17721 )

La tournure "whatever free download version we make available" veut dire qu'ils n'ont même pas décidé de quoi la version gratuite aura l'air (ni même si elle existera, probablement). Peut-être que ce sera la version 4, peut-être que ce sera une version 5 avec la moitié des fonctionnalités en moins, peut-être que ce sera une version nagware de la version 5 qui n'arrêtera pas de vous demander de payer, on n'en sait rien!

Et en passant, pour ma Red Hat (et maintenant Fedora), je n'ai pas payé un sou, moi.

Pollux :
spectras> connaissant ExtendeD, la question ne portait pas sur "il y a aussi le reverse-engineering" mais sur "(plus ou moins légal selon la méthode et l'endroit où on se trouve)"

Euh, oui
"selon la méthode" : un reverse-engineering pourrait être légal ?

ExtendeD> Oups, désolé.

En France (et dans presque toute l'Europe, en fait), oui le reverse est légal, partant du principe qu'une fois que tu as acheté le matériel tu es libre d'en faire ce que tu veux pour en tirer pleinement parti.

=> Donc le reverse dans le but de programmer / améilorer un driver est légal. Le reverse pour corriger des bugs dans un logiciel propriétaire aussi.

Voici un texte intéressant, l'article 6 de la Directive Européenne du 14 mai 1991 (http://europa.eu.int/ISPO/legal/fr/proprint/logiciel/texte.html)

=> Article 6 :

1. L'autorisation du titulaire des droits n'est pas requise lorsque la reproduction du code ou la traduction de la forme de ce code au sens de l'article 4 points a) et b) est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un programme d'ordinateur créé de façon indépendante avec d'autres programmes et sous réserve que les conditions suivantes soient réunies:
a) ces actes sont accomplis par le licencié ou par une autre personne jouissant du droit d'utiliser une copie d'un programme ou pour leur compte par une personne habilitée à cette fin;
b) les informations nécessaires à l'interopérabilité n'ont pas déjà été facilement et rapidement accessibles aux personnes visées au point a) et
c) ces actes sont limités aux parties du programme d'origine nécessaires à cette interopérabilité.

2. Les dispositions du paragraphe 1 ne peuvent justifier que les informations obtenues en vertu de son application:
a) soient utilisées à des fins autres que la réalisation de l'interopérabilité du programme d'ordinateur créé de façon indépendante;
b) soient communiquées à des tiers, sauf si cela s'avère nécessaire à l'interopérabilité du programme d'ordinateur créé de façon indépendante ou c) soient utilisées pour la mise au point, la production ou la commercialisation d'un programme d'ordinateur dont l'expression est fondamentalement similaire ou pour tout autre acte portant atteinte au droit d'auteur.

Marrant, ça.

J'ai pas tout lu, mais juste un commentaire : GCC n'est pas un compilateur super otpimisé x86.
Ensuite, programmer en assembleur n'implique pas un code plus rapide qu'en C, l'x86 étant maintenant basé sur une architecture plus RISC que CISC, l'optimisation en assembleur est d'ailleurs compliquée par les pipelines, un compilateur adapté s'en sortira mieux, en moyenn..

gnaaa ?

Euh, GCC compile également très bien du code RISC, et si, les optimisations sont faites en utilisant les caractéristiques du processeur, y compris déroulages de boucles et réordonnancement des intructions sur les processeurs RISC.
Bon c'est sûr, il fait pas de déroulage de boucle externe. Mais je connais aucun compilateur capable de faire ça.

Par ailleurs, j'ai pas entendu parler de l'introduction d'aléas dans les processeur de la lignée de x86. Mais ptêt que j'ai raté qqc ? Je googlerai un peu, mais je doute quand même. Tu voulais ptet parler de SIMD plutôt ?

(dsl, terrain miné, je viens de faire 3 mois de prog sur des DSP )

spectras :
gnaaa ?

Euh, GCC compile également très bien du code RISC, et si, les optimisations sont faites en utilisant les caractéristiques du processeur, y compris déroulages de boucles et réordonnancement des intructions sur les processeurs RISC.
Bon c'est sûr, il fait pas de déroulage de boucle externe. Mais je connais aucun compilateur capable de faire ça.

Par ailleurs, j'ai pas entendu parler de l'introduction d'aléas dans les processeur de la lignée de x86. Mais ptêt que j'ai raté qqc ? Je googlerai un peu, mais je doute quand même. Tu voulais ptet parler de SIMD plutôt ?

(dsl, terrain miné, je viens de faire 3 mois de prog sur des DSP )

GCC est notoirement moins bon qu'un compilateur spécialisé sur une plateforme, parce qu'il faut équilibrer entre portable et optimisé - le langage intermédiaire n'est pas toujours le plus adapté -
La deuxième question est pour moi, les aléas ?

- dsl, je viens de passer plus de 3 ans sur l'architecture des ardinateurs... -

GCC est notoirement moins bon qu'un compilateur spécialisé sur une plateforme, parce qu'il faut équilibrer entre portable et optimisé - le langage intermédiaire n'est pas toujours le plus adapté -

- Un exemple particulier ? Ou alors peut-être une catégorie d'optimisation que GCC a oublié d'implémenter (on sais jamais, ça peut arriver) ?

- Oui, la deuxième question est pour toi, les aléas. Pour qqn qui vient de faire trois ans sur l'architecture des ardinateurs, c'est dommage de pas faire le rapprochement entre

l'x86 étant maintenant basé sur une architecture plus RISC que CISC

et

j'ai pas entendu parler de l'introduction d'aléas dans les processeur de la lignée de x86

spectras
: - Oui, la deuxième question est pour toi, les aléas. Pour qqn qui vient de faire trois ans sur l'architecture des ardinateurs, c'est dommage de pas faire le rapprochement entre

l'x86 étant maintenant basé sur une architecture plus RISC que CISC

et

j'ai pas entendu parler de l'introduction d'aléas dans les processeur de la lignée de x86

Le jeu x86 a été optimisé récemment pour qu'un jeu "réduit" soit plus optimisé et plus utilisé, tandis que les autres instructions restent... pour la compatibilité. C'est en ça qu'il deviens plus RISC.
C'est pour ça que je n'ai pas vu le rapport avec les aléas.

Ca ne change rien au fait que :
1) les processeurs x86 n'ont pas de pipeline pour le traitement des instructions, mais les exécutent les unes après les autres
2) optimiser un jeu réduit d'instructions n'en fait pas des instructions RISC pour autant. Par exemple, même l'instruction x86 la plus simple, comme inc a la capacité de lire depuis la mémoire, effectuer le calcul et réécrire dans la mémoire. Ce qui est contraire à la philosophie du RISC.
En RISC, il te faudrait 3 instructions. La première lit la mémoire et écrit dans un registre. La seconde fait le calcule. Et la troisième écrit le registre dans la mémoire.
3) certaines instruction super-spécialisés sont absolument inégalables en RISC. Genre repnz scasb

En plus, si tu veux réellement optimiser tes programmes x86, tu gagneras bien plus en leur faisant utiliser MMX/MMXEXT/SSE/SSE2/3DNow qu'en bricolant ou en changeant de compilateur (soit dit en passant et au risque de me répéter pout la 3ème fois, si tu en connais qui optimise mieux que GCC...)

Enfin, il y a de nombreuses optimisations que tu peux faire déjà en C. Par exemple, le blocage de cache se fait très bien en C, ainsi que le déroulage de boucle interne et externe

spectras :
Ca ne change rien au fait que :
1) les processeurs x86 n'ont pas de pipeline pour le traitement des instructions, mais les exécutent les unes après les autres
2) optimiser un jeu réduit d'instructions n'en fait pas des instructions RISC pour autant. Par exemple, même l'instruction x86 la plus simple, comme inc a la capacité de lire depuis la mémoire, effectuer le calcul et réécrire dans la mémoire. Ce qui est contraire à la philosophie du RISC.
En RISC, il te faudrait 3 instructions. La première lit la mémoire et écrit dans un registre. La seconde fait le calcule. Et la troisième écrit le registre dans la mémoire.
3) certaines instruction super-spécialisés sont absolument inégalables en RISC. Genre repnz scasb

En plus, si tu veux réellement optimiser tes programmes x86, tu gagneras bien plus en leur faisant utiliser MMX/MMXEXT/SSE/SSE2/3DNow qu'en bricolant ou en changeant de compilateur (soit dit en passant et au risque de me répéter pout la 3ème fois, si tu en connais qui optimise mieux que GCC...)
Enfin, il y a de nombreuses optimisations que tu peux faire déjà en C. Par exemple, le blocage de cache se fait très bien en C, ainsi que le déroulage de boucle interne et externe

La philosophie du RISC, c'est l'orthogonalité et contrairement à ce qu'on croit, RISC n'implique pas jeu réduit, mais plutôt chemin de données câblé et non micro-programmé. Et le RISC tire parti de la vitesse de la mémoire, ce qui fait que c'est tout aussi rapide. Fréquence élevé n'implique pas performances élevées.
Le but du pipeline n'est pas, par hasard, de traiter les instructions les unes après les autres, mais en chevauchant les fetch, ... ?
Tu as déjà vu le coeur RISC ARM11 ? jette un coup d'oeil, l'ISA x86 n'arrive pas à la cheville...

Et cl compile mieux que GCC... mais comme dit, juste pour x86, pas pour le reste, en globalité, GCC gagne par portabilité. Les seuls progrès qui sont encore faisables au niveau des compilateurs, c'est l'optimisation, le reste ne cause plus de publications et brevets. Ceux qui ont des sous peuvent en profiter, pas les autres.

spectras
:

Il y a plusieurs inexactitudes dans ton message...

1) les processeurs x86 n'ont pas de pipeline pour le traitement des instructions, mais les exécutent les unes après les autres

Faux. Il y a une pipeline! La différence est que le matériel veille à ce que ça ne change pas la sémantique (sauf pour le code automodifiant, mais bon...). (En d'autres mots, ce n'est pas un VLIW.) Par exemple, il n'y a pas de "delay slots". Et les conflits stallent la pipeline (alors que pour les VLIW, c'est au compilateur de veiller à ce qu'il n'y ait pas de conflits, et d'insérer des nops pour forcer des stalls).

En plus, si tu veux réellement optimiser tes programmes x86, tu gagneras bien plus en leur faisant utiliser MMX/MMXEXT/SSE/SSE2/3DNow qu'en bricolant ou en changeant de compilateur (soit dit en passant et au risque de me répéter pout la 3ème fois, si tu en connais qui optimise mieux que GCC...)

Sauf que si tu as un compilateur auto-vectorisant (branche de développement tree-ssa-lno de GCC, ou alors celui d'Intel), le compilateur utilise ces instructions tout seul.

Miles
: La philosophie du RISC, c'est l'orthogonalité et contrairement à ce qu'on croit, RISC n'implique pas jeu réduit,

Sais-tu ce que représentent les initiales RISC?!

Et cl compile mieux que GCC...

Tu veux dire celui de M$VC? Tu rêves! GCC donne des performances comparables à ICC, M$VC est loin derrière.

PUT1 KEVIN TU N'AS PLUS DE TOUCHE "S" SUR TON CLAVIER ?

Non bon aller tu ecrit MSVC et pas cette immondice OK ?

Déjà, je suis gentil à l'appeler M$VC et pas M$WC, alors la ferme!

kler M$WC suxxxx, vive Ti-GrosCaCa !!!
nan mais t'as quel age ?...

---

edit : double cross

!kick Kevin Kofler
--- Kick : Kevin Kofler kické(e) par LizDog

Aprend a écrire ou achete un nouveau clavier

M$WC ?

Et puis bon, le "la ferme" n'est pas très approprié :
[sondage=14243]

Microsoft ?

oui

ba M$ c très bien

on va trouver un p'tit nom pour TIGCC aussi, voyons ... TIG©© par exemple ...

Hum, nspp (mais rotfl quand même)

Kevin Kofler
:

Miles
: La philosophie du RISC, c'est l'orthogonalité et contrairement à ce qu'on croit, RISC n'implique pas jeu réduit,

Sais-tu ce que représentent les initiales RISC?!

Je sais TRES bien, mais il y a une différence entre ce que ça veut dire et ce qu'on croit que ça veut dire.
Le CISC est en référence aux processeurs des années 70 à séquenceur micro-programmé et dont les mots d'instruction pouvaient aller jusqu'à 100 octets!!
RISC et CISC ne sont pas des ISAs, mais une architecture interne, sinon comment Philips aurait pu sortir un 8051 en RISC alors que les Intel sont des CISC et qu'ils sont compatibles broche à broche ?
et je maintiens qu'il existe des RISC avec des jeux bien plus compliqués que des CISC!

pour GCC et VS : http://www.osnews.com/story.php?news_id=5602&page=3, première page sous google, mais si tu en trouves d'autres prouvant le contraire, je veux bien jeter un coup d'oeil - et n'oublions pas non plus les programmes que gcc ne compile pas... ou Code Warrior, ... -

tig©©

Je n'ai pas dit du mal du RISC. Je sais parfaitement que pour des applications temps réel type traitement de vidéos, les DSP sont incontournables, et que les x86 ne sont pas du tout faits pour ça.
Ce que je dis, c'est que les x86 ne s'orientent pas du tout vers une architecture RISC. Au contraire, on assiste à une démultiplication du nombre d'instructions, et des instructions de plus en plus complexes. Quand au pipeline, faut même pas espérer.

Franchement, quand tu regardes les nouvelles instructions, par exemple PMULUDQ tu vas pas me dire que on s'oriente vers justement cette orthogonalité caractéristique des RISC ?

PMULUDQ xmm1,xmm2/m128
Multiplies the first operand (destination operand) by the second operand (source operand) and stores the result in the destination operand. The source operand can be a unsigned doubleword integer stored in the low doubleword of an MMX register or a 64-bit memory location, or it can be two packed unsigned doubleword integers stored in the first (low) and third doublewords of an XMM register or an 128-bit memory location. The destination operand can be a unsigned doubleword integer stored in the low doubleword an MMX register or two packed doubleword integers stored in the first and third doublewords of an XMM register. The result is an unsigned quadword integer stored in the destination an MMX register or two packed unsigned quadword integers stored in an XMM register. When a quadword result is too large to be represented in 64 bits (overflow), the result is wrapped around and the low 64 bits are written to the destination element (that is, the carry is ignored).

Et cl compile mieux que GCC...

Il produit des exécutables de vitesse d'exécution comparable, mais plus gros (quoique lui reprocher ça est probablement injuste, vu qu'il est lié au format binaire (PE) qu'il est obligé générer). A part la vitesse de compilation qui est meilleure (principalement grâce aux en-tête précompilés, d'ailleurs), je vois pas.

#ifdef troll
Soit dit en passant, le cl livré avec VS6 n'est même pas c++ ansi. Essaie donc de compiler ça :
for (int i = 0 ; i < 3; i++) cout <<i;
for (int i = 0 ; i < 3; i++) cout <<2*i;
Il te dira que i est défini deux fois, et refusera de compiler. Alors que le c++ ansi dit clairement que sorti du for, i n'est plus définie
#endif

#ifdef troll
Soit dit en passant, le cl livré avec VS6 n'est même pas c++ ansi. Essaie donc de compiler ça :
for (int i = 0 ; i < 3; i++) cout <<i;
for (int i = 0 ; i < 3; i++) cout <<2*i;
Il te dira que i est défini deux fois, et refusera de compiler. Alors que le c++ ansi dit clairement que sorti du for, i n'est plus définie
#endif

C'est loin d'être le seul pb de VC++ 6 de ce point de vue là... Même VC++ 7.0 (.NET 2002) n'est pas parfait. En revanche VC++ 7.1 est largement mieux