Ce n'est pas le cas de tout les splashscreen, je viens de relancer StarOffice5.2 sous Solaris pour voir et le splashscreen ne disparait pas quand tu clique dessus.
C'est vrai que c'est plus intelligent comme comportement, mais a ce moment la il faut que ce soit marqué sur le splashscreen que cliquer dessus ferme le splashscreen, autrement l'utilisateur n'etant pas devin...
Merci pour la capture d'écran, ça me confirme que c'est bien juste un splashscreen, sans rien d'autre, ce qui me permet de pousser le cri suivant: les splashscreen, c'est NUL!!
Je préfererais de loin que l'application lance une fenetre toute bete, avec le même contenu que le splashcreen, car on peut MINIMISER simplement une fenetre, pas un splashscreen.
Si le splashscreen reste 20s a l'écran (penser aux utilisateurs avec des machines peu puissante, ou avec peu de mémoire), les utilisateurs vont le haïr le splashscreen.
Le top serait même d'ajouter dans cette fenetre de démmarage une barre de progression avec un texte qui explique ce que l'appli est en train de faire: comme ça tu sais si l'application est bloquée ou pas.
Je suis convaincu que la majorité des développeurs Java pensait de bonne foi, qu'importé un point jar était l'équivalent de la liaison dynamique pas statique.
J'ai lu /. et d'ailleurs une bonne partie des intervenant le croyait toujours car l'explication de l'homme de loi de la FSF était aussi claire que d'habitude quand un homme de loi parle, c'est à dire nébuleuse..
Pff, un avocat ça ne doit pas savoir répondre par oui ou par non..
Quelqu"un connait-il une license "équivalente" à la LGPL, mais qui n'aurait pas ce problème?
Ce serait bien si la FSF en proposait une de ce type..
>Le féminisme est un courant visant à discriminer les hommes des femmes.
T'en as d'autres des bétises du même genre?
Pour moi le fénismisme consiste a tenter de corriger une société dominée par les hommes, retablir l'équilibre si tu veux..
Si je me souviens bien la France a été un des derniers pays à accorder le droit de vote au femmes, et il y a toujours une grande différence de salaire entre hommes et femmes a qualification égale, il y a encore du boulot!
Pour moi, le féminisme, c'est être contre les discriminations anti-femme, alors féminisme==discrimination, quelle bétise!
J'ai presque cru a un troll a un moment, mais si tu y crois vraiment, c'est encore pire..
Pour les algorithme limités par la bande passante mémoire, en général la BP est utilisée surtout par les données pas par les instructions, donc si tu gagnes 20% de place avec des intructions x86 vis a vis du ARM, tu ne gagnes pas 20% de BP mémoire.
Et ce d'autant plus que les caches instructions font pas mal leur boulot..
>Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Donc tout ceux qui ont conçus des nouveaux CPU ces dernières années sont des billes: ils ont tous concus des RISC a la place de CISC, même Intel! Les VLIW sont des descendants des RISC pas des CISC: architecture load/store, jeux d'instructions facile a decoder, pleins de registres, etc..
>Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Ta logique me parait curieuse là: si l'IPC d'un code est limité, alors on est limité par la latence des unités de calcule, pas par celle de la mémoire! C'est vrai qu'en général un CPU attend la mémoire, mais je ne vois pas quel est le rapport avec l'IPC.
Pour ce qui est de l'opteron, c'est sûr que leur controleur de mémoire intégré a l'air intéréssant, je suis curieux de voir si AMD arrivera a suivre l'évolution rapide des mémoires..
>Ben non, au contraire, le SIMD permet de diminuer le nombre d'instructions nécessaires pour une même tâche ;)
Tu as raison pour le mode SIMD, mais je pense quand meme que quand le x86 a evolue du x86, au 286, au 386, la densite de code a du baissé un peu.
Une question cependant: j'ai cru comprendre qu'Intel poussait le SSE2pour remplacer totalement le x87, meme pour les operations ou tu ne peux pas exploiter le SIMD, est-ce possible?
Parce que a ce moment la, il y aurait bien une augmentation de taille provoquée par l'architecture pourrie du x87.
>Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
>Non, c'est uniquement pour les opérations sur les entiers 64 bits. Ce qui est logique car dans 99% des cas les entiers 32 bits suffisent.
Je crois que c'est faux là: pour toute operations ou tu veux acceder aux 16 registres, ou bien si tu veux utiliser un espace d'adresse memoire sur 64 bit, tu as besoin de l'opcode supplémentaire, meme pour des operations 32-bits.
A propos du trace-cache, il m'a toujours parut tres petit (d'autant plus que les instructions y sont stockees en mode "décompressé"), je serai curieux d'avoir des chiffres sur les temps d'attente provoquées par cette petite taille..
>les procs l'aujourd'hui ne sont ni totalement CISC ni totalement RISC.
Dans RISC ou CISC, IS ça veut dire Instruction Set, ce qui se traduit par Jeu d'Instruction: les instructions *externes* exécutés par le CPU.
L'implémentation n'a RIEN A VOIR la dedans: pour parler technique il y a eu des RISC implementé avec du micro-code, par exemple.
Et RISC == 1 cycle/instruction, cela n'a quasiment jamais été vrai quasiment toutes les RISC ont une instruction de multiplication qui ne s'execute pas en 1 cycle (si je me souviens bien le MIPS est special la-dessus).
Si tu compares les jeux d'instructions d'un ARM, d'un Sparc, d'un Alpha, meme s'ils ont quelques instructions complexes, ils sont quand meme beaucoup plus proches du concept RISC que ne le sera jamais le jeu d'instruction d'un 80x86.
>Cela me fait de lire ça... le code x86 est plus compact qu'un code arm thumb.
Moui, euh vu les ajouts successifs d'opcode pour ajouter telle ou telle feature (MMX,SSE,SSE2)., la densite du code en x86 a du baissé un peu..
Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
L'augmentation du nombre de registre compensera un peu, moins de load/store a faire pour cause d'utilisation de trop de registre..
Ceci dit tu confonds la densité du code (une des forces des CISC) et la complexité d'analyse des instructions (une des faiblesses des CISC).
La densité est avantageuse du points de vue bande passante mémoire, occupation des caches mais se paye par une complexité des décodeurs d'instructions bien plus grandes.
Si tu regardes tout les CPU non-compatible 80x86 sorti recemment , ce sont tous des RISC (les VLIW sont beaucoup plus proches des RISC que des CISC), dans ce sens les RISC ont "gagné" (a prendre avec des grosses pincettes).
Par contre, la ou je suis d'accord avec toi, c'est que les x86 explosent tout au niveau performances/prix, la compatibilité avec l'existant l'a emporté sur les avantages ou inconvenient du jeux d'instruction.
>> Il y a un gros patch pour Arm qui est resté en dehors du kernel du test, je crois.
>Faudrait savoir ce que tu veux. Tu reproche à Linux d'accepter trop facilement les patch et après c'est le contraire...
Je ne reproche rien a Linux ni a Linus, je dis juste qu'il y a des compromis a faire: soit tu evolue tres vite avec des feature complexe, multiplateforme, soit tu te concentre sur un kernel qui evolue lentement pour la securite.
C'est la raison principale pour les differents BSD: NetBSD est plus portable que Linux et OpenBSD est (je pense) plus securise que Linux.
Donc quand on dit que Linux fait tout bien, moi je dis que c'est de l'exageration: Linux fait tout pas mal, mais les OS qui se focalise sur un point en particulier remplisse mieux ce point qu'un OS plus generaliste.
>> Par exemple, si je ne m'abuse la stabilisation du kernel 2.6 se fera d'abords uniquement sur x86
> C'est absolument faut. Si t'as un bug report pour Arm ou Sparc, il sera accèpté !
Il y a un gros patch pour Arm qui est resté en dehors du kernel du test, je crois.
Donc forcement, cela limite l'interet des kernel de test pour Arm..
[]
>Pour OpenBSD tu sous-entends qu'intrinsecquement OpenBSD ne peut pas évoluer aussi vite que Linux. Pour Linux tu sous-entends que n'importe quoi est ajouté sans vérification. Or Linux est un des noyaux les plus contrôlés.
OpenBSD ne *veut* pas evoluer aussi vite que Linux, ils ont meme choisis de ne pas pousser le SMP pour avoir du code plus simple a auditer..
Quand a "Linux est un des noyeaux les plus controles", c'est a voir, je me souviens d'un probleme de securite (2.4.20?) il n'y a pas si longtemps, mais ce n'est qu'anecdotique.
Je ne connais pas de statistique comparant les trous de securite pour OpenBSD vs Linux, donc forcement, c'est difficile a comparer objectivement.
Si tu considere Linux comme l'OS, il y a énormément de distributions Linux alors qu'il y a peu de systeme *BSD: les BSD peuvent être considéré comme des distributions.
Si tu considère Linux comme le kernel, (ce qui est plus logique ici), "tout bien" est un peu exagéré: il y a quand même de grosses divergences comme par exemple les systemes temps réel "dur", ou les architecture non-x86 qui sont souvent traitées au second plan.
Par exemple, si je ne m'abuse la stabilisation du kernel 2.6 se fera d'abords uniquement sur x86, note que ce n'est pas une critique, je comprends l'interet, mais quelque-chose me dit qu'avec NetBSD, ce genre d'attitude aurait du mal a passer!
De plus je suis sur que le rythme d'introduction des nouvelles features dans Linux, n'irait pas avec OpenBSD: cela poserait un problème pour revoir toutes ces lignes..
Donc ce n'est pas "tout bien" mais plutot "tout pas mal", et ceci dit c'est uniquement un choix des développeurs, cela n'a rien a voir avec la licence GPL vs BSD!
Les *BSD restent tous accessibles a chacun d'entre eux: rien n'empeche de prendre du code de xBSD pour le mettre dans yBSD, d'ailleurs ils le font..
S'il n'y a pas plus d'échanges entres les kernel BSD, c'est que leurs centres d'intéret sont tellement éloignés que ça limite forcément les échanges..
Ce qu'évoque Linux, c'est plutot le risque qu'une entreprise prenne le code de *BSD, ne le rende plus publique et essaye de vendre leur produit en mettant en avant leurs modifications par rapport au code 'normal', c'est un risque certes, et c'est même probablement arrivé, mais en tout cas, cela n'a pas du tout bloqué le développement des systèmes BSD, ce qui est le principal!
Je trouve un peu curieux son opinion sur la license BSD, si on prend l'exemple de l'OS, il y en a seulement 3 differents avec chacun des préocuppations bien differentes.
Il a le droit d'avoir son opinion, mais en pratique "BSD==nid a fork", cela n'a pas l'air d'être le cas!
Tu es de mauvaise foi, il y a 2 standards:
- le standard qui correspond a un ensemble de regles edites par un organisme de standardisation, dans ce cas le WEC, standard de jure.
- le standard de fait qui correspond a l'implementation predominante sur le marche, dans ce cas IE, tres largement devant tous les autres.
Le standard de fait, n'est pas le contraire du specifique dans le cas ou il correspond a une implementation qui ecrase tout le monde, ce qui est la situation des navigateurs web..
Pour ça je suis d'accord: "l'éducation sentimentale": un vrai cauchemar en taupe, je m'en servais comme berceuse pour m'endormir: 2 pages par jour, c'est radical!
90% de la classe n'a pas réussi a lire le bouquin en entier, alors que ça pouvait être super-important pour les concours!
Je trouve incroyable que l'école n'essaye pas d'attirer vers la litérature en prenant des auteurs intérressant, on croirait qu'ils cherchent a dégouter de la lecture!
Posté par reno .
En réponse à la dépêche Darkness.
Évalué à 1.
Et les appareils photos? Tu as oublié la séance de photos avec Juliette Binoche!
Bon c'est vrai qu'il y avait là aussi des miroirs stratégiquement placés :-)
J'ai tellement aimé "L'Insoutenable Légéreté de l'Etre" que j'ai voulu lire le livre: mmhhh, Kundera c'est "spécial" on dira (beuuurrrrkk).
> Les diplomés d'informatique européen n'ont pas vraiment de soucis à se faire de ce point de vue avant un bon moment.
N'importe quoi!!
Je bosse pour Alcatel et dans mon projet le nombre de développeurs a chuté de beaucoup car une grosse partie de l'activité a été transféré en Roumanie.
Les développeurs Roumains sont surement moins aguerris que les Français, mais comme au même prix tu peux embaucher beaucoup plus de développeurs Roumains, les décideurs se sont dit que cela compenserait, ce qui est un calcul risqué mais éventuellement très rentable économiquement.
Je connais entre autre un gars qui est très, très mal a cause de ça..
Bin il ne peut pas y avoir des cartes en ventes avant que le bus soit disponible!
ATI et NVidia ont l'air bien chaud pour porter leurs cartes graphiques avec une interface PCI Express.
Je suis curieux de voir si c'est juste une lutte marketing ou si cela aura vraiment un impact sur les performances des jeux: j'aurais tendance a penser que le gain sera assez faible..
>> je ne vois pas trop l'intérêt
>> d'un DoS "local" (hors serveur FTP mal configuré).
>1) Va dire ça aux administrateurs d'une université qui se battent contre les >élèves eux mêmes qui jouent au WaRiOrS sur les serveurs de la faq, ... C'est
>con, mais c'est comme ça :-(
C'est si frequent que ca?
Un eleve qui cherche a passer root sans se faire remarquer, ca ne doit pas etre tres rare, OK mais un eleve qui cherche a faire un DOS, cela me parait curieux: il y a de fortes chances que l'eleve soit viré a la suite de son DOS..
>Et sinon, je vois pas en quoi l'absence de {} augmente la lisibilité...
Et bien, ca force a indenter correctement: c'est penible a ecrire, mais plus agreable a relire et comme ca, on est sur que tous le monde indente de la meme maniere.
Sinon entre ruby et python, je trouve que les deux se valent pour un programmeur experimenté: je prefere la syntaxe de Ruby mais Python est plus utilisé (plus de librairie).
Pour un debutant, je pense qu'imposer l'indentation des sources, plus l'absence des $, @ font pencher la balance pour Python..
Beurk, ça me parait encore pire que le BASIC pour débuter!
Personnellement j'aurais tendance a preferer Ruby, mais c'est apres avoir utiliser le shell et le Perl, pour un débutant je conseillerais Python sans hésitation.
Pour ce qui est de la recherche a Google, a deux balle, franchement aucun interet..
[^] # Re: A bas les splashscreen!
Posté par reno . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
Ce n'est pas le cas de tout les splashscreen, je viens de relancer StarOffice5.2 sous Solaris pour voir et le splashscreen ne disparait pas quand tu clique dessus.
C'est vrai que c'est plus intelligent comme comportement, mais a ce moment la il faut que ce soit marqué sur le splashscreen que cliquer dessus ferme le splashscreen, autrement l'utilisateur n'etant pas devin...
[^] # A bas les splashscreen!
Posté par reno . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 3.
Je préfererais de loin que l'application lance une fenetre toute bete, avec le même contenu que le splashcreen, car on peut MINIMISER simplement une fenetre, pas un splashscreen.
Si le splashscreen reste 20s a l'écran (penser aux utilisateurs avec des machines peu puissante, ou avec peu de mémoire), les utilisateurs vont le haïr le splashscreen.
Le top serait même d'ajouter dans cette fenetre de démmarage une barre de progression avec un texte qui explique ce que l'appli est en train de faire: comme ça tu sais si l'application est bloquée ou pas.
[^] # Re: Sortie de Qt 3.2
Posté par reno . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
[^] # Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par reno . En réponse à la dépêche La LGPL s'applique à Java exactement comme pour C/C++. Évalué à 1.
OK donc faire une librairie (un .jar) en Java est totalement identique a la faire en C/C++ du point de vue de la LGPL.
(Ouf!) Pas de quoi en faire un fromage, effectivement.
# Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par reno . En réponse à la dépêche La LGPL s'applique à Java exactement comme pour C/C++. Évalué à 4.
Je suis convaincu que la majorité des développeurs Java pensait de bonne foi, qu'importé un point jar était l'équivalent de la liaison dynamique pas statique.
J'ai lu /. et d'ailleurs une bonne partie des intervenant le croyait toujours car l'explication de l'homme de loi de la FSF était aussi claire que d'habitude quand un homme de loi parle, c'est à dire nébuleuse..
Pff, un avocat ça ne doit pas savoir répondre par oui ou par non..
Quelqu"un connait-il une license "équivalente" à la LGPL, mais qui n'aurait pas ce problème?
Ce serait bien si la FSF en proposait une de ce type..
[^] # Re: Féminisme, informatique et logiciels libres
Posté par reno . En réponse à la dépêche Féminisme, informatique et logiciels libres. Évalué à 3.
T'en as d'autres des bétises du même genre?
Pour moi le fénismisme consiste a tenter de corriger une société dominée par les hommes, retablir l'équilibre si tu veux..
Si je me souviens bien la France a été un des derniers pays à accorder le droit de vote au femmes, et il y a toujours une grande différence de salaire entre hommes et femmes a qualification égale, il y a encore du boulot!
Pour moi, le féminisme, c'est être contre les discriminations anti-femme, alors féminisme==discrimination, quelle bétise!
J'ai presque cru a un troll a un moment, mais si tu y crois vraiment, c'est encore pire..
[^] # Re: Mouarf...
Posté par reno . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
Et ce d'autant plus que les caches instructions font pas mal leur boulot..
>Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Donc tout ceux qui ont conçus des nouveaux CPU ces dernières années sont des billes: ils ont tous concus des RISC a la place de CISC, même Intel! Les VLIW sont des descendants des RISC pas des CISC: architecture load/store, jeux d'instructions facile a decoder, pleins de registres, etc..
>Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Ta logique me parait curieuse là: si l'IPC d'un code est limité, alors on est limité par la latence des unités de calcule, pas par celle de la mémoire! C'est vrai qu'en général un CPU attend la mémoire, mais je ne vois pas quel est le rapport avec l'IPC.
Pour ce qui est de l'opteron, c'est sûr que leur controleur de mémoire intégré a l'air intéréssant, je suis curieux de voir si AMD arrivera a suivre l'évolution rapide des mémoires..
[^] # Re: Mouarf...
Posté par reno . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
Tu as raison pour le mode SIMD, mais je pense quand meme que quand le x86 a evolue du x86, au 286, au 386, la densite de code a du baissé un peu.
Une question cependant: j'ai cru comprendre qu'Intel poussait le SSE2pour remplacer totalement le x87, meme pour les operations ou tu ne peux pas exploiter le SIMD, est-ce possible?
Parce que a ce moment la, il y aurait bien une augmentation de taille provoquée par l'architecture pourrie du x87.
>Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
>Non, c'est uniquement pour les opérations sur les entiers 64 bits. Ce qui est logique car dans 99% des cas les entiers 32 bits suffisent.
Je crois que c'est faux là: pour toute operations ou tu veux acceder aux 16 registres, ou bien si tu veux utiliser un espace d'adresse memoire sur 64 bit, tu as besoin de l'opcode supplémentaire, meme pour des operations 32-bits.
A propos du trace-cache, il m'a toujours parut tres petit (d'autant plus que les instructions y sont stockees en mode "décompressé"), je serai curieux d'avoir des chiffres sur les temps d'attente provoquées par cette petite taille..
[^] # Re: [RC]ISC
Posté par reno . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
Dans RISC ou CISC, IS ça veut dire Instruction Set, ce qui se traduit par Jeu d'Instruction: les instructions *externes* exécutés par le CPU.
L'implémentation n'a RIEN A VOIR la dedans: pour parler technique il y a eu des RISC implementé avec du micro-code, par exemple.
Et RISC == 1 cycle/instruction, cela n'a quasiment jamais été vrai quasiment toutes les RISC ont une instruction de multiplication qui ne s'execute pas en 1 cycle (si je me souviens bien le MIPS est special la-dessus).
Si tu compares les jeux d'instructions d'un ARM, d'un Sparc, d'un Alpha, meme s'ils ont quelques instructions complexes, ils sont quand meme beaucoup plus proches du concept RISC que ne le sera jamais le jeu d'instruction d'un 80x86.
[^] # Re: Mouarf...
Posté par reno . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
Moui, euh vu les ajouts successifs d'opcode pour ajouter telle ou telle feature (MMX,SSE,SSE2)., la densite du code en x86 a du baissé un peu..
Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
L'augmentation du nombre de registre compensera un peu, moins de load/store a faire pour cause d'utilisation de trop de registre..
Ceci dit tu confonds la densité du code (une des forces des CISC) et la complexité d'analyse des instructions (une des faiblesses des CISC).
La densité est avantageuse du points de vue bande passante mémoire, occupation des caches mais se paye par une complexité des décodeurs d'instructions bien plus grandes.
Si tu regardes tout les CPU non-compatible 80x86 sorti recemment , ce sont tous des RISC (les VLIW sont beaucoup plus proches des RISC que des CISC), dans ce sens les RISC ont "gagné" (a prendre avec des grosses pincettes).
Par contre, la ou je suis d'accord avec toi, c'est que les x86 explosent tout au niveau performances/prix, la compatibilité avec l'existant l'a emporté sur les avantages ou inconvenient du jeux d'instruction.
[^] # Re: En français... et à propos de la GPL
Posté par reno . En réponse à la dépêche Linus Torvalds : annonce noyau 2.6 et une interview. Évalué à 1.
>Faudrait savoir ce que tu veux. Tu reproche à Linux d'accepter trop facilement les patch et après c'est le contraire...
Je ne reproche rien a Linux ni a Linus, je dis juste qu'il y a des compromis a faire: soit tu evolue tres vite avec des feature complexe, multiplateforme, soit tu te concentre sur un kernel qui evolue lentement pour la securite.
C'est la raison principale pour les differents BSD: NetBSD est plus portable que Linux et OpenBSD est (je pense) plus securise que Linux.
Donc quand on dit que Linux fait tout bien, moi je dis que c'est de l'exageration: Linux fait tout pas mal, mais les OS qui se focalise sur un point en particulier remplisse mieux ce point qu'un OS plus generaliste.
[^] # Re: En français... et à propos de la GPL
Posté par reno . En réponse à la dépêche Linus Torvalds : annonce noyau 2.6 et une interview. Évalué à 1.
> C'est absolument faut. Si t'as un bug report pour Arm ou Sparc, il sera accèpté !
Il y a un gros patch pour Arm qui est resté en dehors du kernel du test, je crois.
Donc forcement, cela limite l'interet des kernel de test pour Arm..
[]
>Pour OpenBSD tu sous-entends qu'intrinsecquement OpenBSD ne peut pas évoluer aussi vite que Linux. Pour Linux tu sous-entends que n'importe quoi est ajouté sans vérification. Or Linux est un des noyaux les plus contrôlés.
OpenBSD ne *veut* pas evoluer aussi vite que Linux, ils ont meme choisis de ne pas pousser le SMP pour avoir du code plus simple a auditer..
Quand a "Linux est un des noyeaux les plus controles", c'est a voir, je me souviens d'un probleme de securite (2.4.20?) il n'y a pas si longtemps, mais ce n'est qu'anecdotique.
Je ne connais pas de statistique comparant les trous de securite pour OpenBSD vs Linux, donc forcement, c'est difficile a comparer objectivement.
[^] # Re: En français... et à propos de la GPL
Posté par reno . En réponse à la dépêche Linus Torvalds : annonce noyau 2.6 et une interview. Évalué à 2.
Si tu considère Linux comme le kernel, (ce qui est plus logique ici), "tout bien" est un peu exagéré: il y a quand même de grosses divergences comme par exemple les systemes temps réel "dur", ou les architecture non-x86 qui sont souvent traitées au second plan.
Par exemple, si je ne m'abuse la stabilisation du kernel 2.6 se fera d'abords uniquement sur x86, note que ce n'est pas une critique, je comprends l'interet, mais quelque-chose me dit qu'avec NetBSD, ce genre d'attitude aurait du mal a passer!
De plus je suis sur que le rythme d'introduction des nouvelles features dans Linux, n'irait pas avec OpenBSD: cela poserait un problème pour revoir toutes ces lignes..
Donc ce n'est pas "tout bien" mais plutot "tout pas mal", et ceci dit c'est uniquement un choix des développeurs, cela n'a rien a voir avec la licence GPL vs BSD!
Les *BSD restent tous accessibles a chacun d'entre eux: rien n'empeche de prendre du code de xBSD pour le mettre dans yBSD, d'ailleurs ils le font..
S'il n'y a pas plus d'échanges entres les kernel BSD, c'est que leurs centres d'intéret sont tellement éloignés que ça limite forcément les échanges..
Ce qu'évoque Linux, c'est plutot le risque qu'une entreprise prenne le code de *BSD, ne le rende plus publique et essaye de vendre leur produit en mettant en avant leurs modifications par rapport au code 'normal', c'est un risque certes, et c'est même probablement arrivé, mais en tout cas, cela n'a pas du tout bloqué le développement des systèmes BSD, ce qui est le principal!
[^] # Re: En français... et à propos de la GPL
Posté par reno . En réponse à la dépêche Linus Torvalds : annonce noyau 2.6 et une interview. Évalué à 2.
Il a le droit d'avoir son opinion, mais en pratique "BSD==nid a fork", cela n'a pas l'air d'être le cas!
[^] # Re: énorme cet article !
Posté par reno . En réponse à la dépêche Sur 01Net, 'chat' Linux ou Windows. Évalué à 2.
- le standard qui correspond a un ensemble de regles edites par un organisme de standardisation, dans ce cas le WEC, standard de jure.
- le standard de fait qui correspond a l'implementation predominante sur le marche, dans ce cas IE, tres largement devant tous les autres.
Le standard de fait, n'est pas le contraire du specifique dans le cas ou il correspond a une implementation qui ecrase tout le monde, ce qui est la situation des navigateurs web..
[^] # Re: OpenOffice.org vs Microsoft Office : Chronique d'une migration réussie à grande échelle
Posté par reno . En réponse à la dépêche OpenOffice.org vs Microsoft Office : Chronique d'une migration réussie à grande échelle. Évalué à 2.
Bin si quand meme, le format de fichier de StarOffice est ouvert, lui.
Pas encore standardisé d'accord, mais bon c'est tout de meme deja pas mal!
[^] # Re: Les ordinateurs portables dans les collèges un an après
Posté par reno . En réponse à la dépêche Les ordinateurs portables dans les collèges un an après. Évalué à 3.
De l'auteur le plus chiant du monde ?
Pour ça je suis d'accord: "l'éducation sentimentale": un vrai cauchemar en taupe, je m'en servais comme berceuse pour m'endormir: 2 pages par jour, c'est radical!
90% de la classe n'a pas réussi a lire le bouquin en entier, alors que ça pouvait être super-important pour les concours!
Je trouve incroyable que l'école n'essaye pas d'attirer vers la litérature en prenant des auteurs intérressant, on croirait qu'ils cherchent a dégouter de la lecture!
[^] # Re: l'insoutenable ignorance des jeunes :)
Posté par reno . En réponse à la dépêche Darkness. Évalué à 1.
Bon c'est vrai qu'il y avait là aussi des miroirs stratégiquement placés :-)
J'ai tellement aimé "L'Insoutenable Légéreté de l'Etre" que j'ai voulu lire le livre: mmhhh, Kundera c'est "spécial" on dira (beuuurrrrkk).
[^] # Re: Seconde édition de "Systèmes d'exploitation"
Posté par reno . En réponse à la dépêche Seconde édition de "Systèmes d'exploitation". Évalué à 1.
Un exemple parmi d'autres: la VM de Linux en 2.6 est très fortement inspiré de celle de FreeBSD.
[^] # Re: Seconde édition de "Systèmes d'exploitation"
Posté par reno . En réponse à la dépêche Seconde édition de "Systèmes d'exploitation". Évalué à 2.
N'importe quoi!!
Je bosse pour Alcatel et dans mon projet le nombre de développeurs a chuté de beaucoup car une grosse partie de l'activité a été transféré en Roumanie.
Les développeurs Roumains sont surement moins aguerris que les Français, mais comme au même prix tu peux embaucher beaucoup plus de développeurs Roumains, les décideurs se sont dit que cela compenserait, ce qui est un calcul risqué mais éventuellement très rentable économiquement.
Je connais entre autre un gars qui est très, très mal a cause de ça..
Alors pas de souci a se faire, tu rêve!!
[^] # Re: Apple présente les nouveaux G5 et OSX.3 (Panther)
Posté par reno . En réponse à la dépêche Apple présente les nouveaux G5 et OSX.3 (Panther). Évalué à 2.
[^] # Re: Une Xbox non modifiée sous linux, c'est désormais possible
Posté par reno . En réponse à la dépêche Une Xbox non modifiée sous linux, c'est désormais possible. Évalué à 1.
>> d'un DoS "local" (hors serveur FTP mal configuré).
>1) Va dire ça aux administrateurs d'une université qui se battent contre les >élèves eux mêmes qui jouent au WaRiOrS sur les serveurs de la faq, ... C'est
>con, mais c'est comme ça :-(
C'est si frequent que ca?
Un eleve qui cherche a passer root sans se faire remarquer, ca ne doit pas etre tres rare, OK mais un eleve qui cherche a faire un DOS, cela me parait curieux: il y a de fortes chances que l'eleve soit viré a la suite de son DOS..
[^] # Re: Perl pour débuter la programmation?
Posté par reno . En réponse à la dépêche Début d'une série d'articles sur Perl. Évalué à 1.
Et bien, ca force a indenter correctement: c'est penible a ecrire, mais plus agreable a relire et comme ca, on est sur que tous le monde indente de la meme maniere.
Sinon entre ruby et python, je trouve que les deux se valent pour un programmeur experimenté: je prefere la syntaxe de Ruby mais Python est plus utilisé (plus de librairie).
Pour un debutant, je pense qu'imposer l'indentation des sources, plus l'absence des $, @ font pencher la balance pour Python..
[^] # Re: Début d'une série d'articles sur Perl
Posté par reno . En réponse à la dépêche Début d'une série d'articles sur Perl. Évalué à 7.
Je te rappelle que là, il s'agit de debuter la programmation, alors pour ce qui est de programmer proprement..
La question interressante est plutot, quel language reste a peu pres lisible meme quand on programme mal?
Et la réponse est: pas trop le C et surtout pas le Perl !!
# Perl pour débuter la programmation?
Posté par reno . En réponse à la dépêche Début d'une série d'articles sur Perl. Évalué à 3.
Personnellement j'aurais tendance a preferer Ruby, mais c'est apres avoir utiliser le shell et le Perl, pour un débutant je conseillerais Python sans hésitation.
Pour ce qui est de la recherche a Google, a deux balle, franchement aucun interet..