reno a écrit 3886 commentaires

Je pense que le succes de IE6 s'explique assez facilement:

quand tu mets a jour ta version de Windows, tu peux en profiter pour mettre a jour IE.

(avec une liaison haut-debit quand meme).



Les gens ont l'habitude de IE, qui marche pas mal (sauf quand il se plante et "entraine" Windows avec)

Alors pourquoi changeraient-ils?

Mis à part la forme, si je comprends bien l'auteur de l'article trouve que la LGPL n'est pas satisfaisante.
C'est dommage: je trouve le concept intéréssant: un "juste milieu" entre les licenses GPL et BSD.

Si je me souviens bien au départ ceux qui ont dévéloppé Ogg Vorbis était intéréssé par la LGPL, mais ils ont finalement placé une partie du projet sous la licenses BSD.

Est-ce que vous connaissez des licenses "plus solides" qui remplissent le même rôle que la license LGPL?

J'hésite..
(une moule ça ne se déplace pas facilement :-)

C'est "réservé" au développeur ou pas?

Etant seulement utilisateur (à part 2-3 coup de mains pour les traductions)...
et à priori trop fainéant pour vraiment aider..

> Je veux un vrai vote blanc !

Moi, aussi.. Et si on votait pour ?
:-)

Desole, je n'ai pas pu me retenir..

Euh: QNX, Chorus sont des micro-noyau qui sont utilisés ils me semblent!

Les micro-noyaux ont connus un succès certains dans les systèmes embarqués.



Pour le desktop, je pense que MacOS X quand il sera installé "par défaut", atteindra rapidement un nombre d'utilisateur tout à fait respectable.



Pour les serveurs, là je ne vois pas.. MacOS X peut surement être utilisé comme serveur, mais ce n'est pas sa destination premiére.

Tu as un lien?

Pour NT, c'est sûr.

Pour 2k et XP je croyais que Microsoft avait réécrit ses piles..

Dans KDE 3.0 Konqueror supportera totalement toutes les transparences des PNG, je crois.

De mémoire, ils ont prévus de le sortir vers février, et comme:
1) en général les développeurs de KDE respectent bien leurs prévisions
2) c'est surtout un portage vers Qt3 sans "redesign" complet comme KDE 1.x -> KDE 2.

Sauf que StarOffice/OpenOffice n'est pas destiné à être rentable pour Sun..

C'est une arme anti-Microsoft: cela permet d'affaiblir a Sun d'"affaiblir" Microsoft pour pas trop cher..
Mais je doute beaucoup que ce soit une activité rentable..

Avec le prix des licenses de Microsoft en augmentation constante, je pense que de plus en plus de gens vont penser à utiliser StarOffice plutot que Office.

Dans mon entreprise (une GROSSE boite), on a installé StarOffice sur toutes les stations des développeurs (une centaine de personnes sur le site), cela "soulage" les "PC métaframe" utilisés pour Office.
Cela nous a évité d'avoir à installer des PC supplémentaires..

La compatibilité StarOffice(StarWrite)/Word n'est pas parfaite (parfois le formatage des documents complexe est un peu bizarre) mais ça marche pas mal du tout StarOffice (quand on a de la RAM de libre..)

"La diversite est toujours profitable"

Euh ça dépend!!!!!

La diversité des applications du style vim/nedit/emacs, d'accords!!

KOffice/Abiword/OpenOffice/Lyx, ça pose déjà plus de problème d'interopérabilité au niveau format de fichier..
Et les dévelopeur sont repartis sur beaucoup de projets: les projets avancent lentement (même si la concurrence peut être stimulante d'un autre coté).

Plusieurs formats de packaging: rpm, le format de Debian, etc.. La, à part une perte de temps et d'effort totalement ABSURDE je ne vois pas l'intéret..

Un installeur par distribution: perte de temps et d'effort.. Résultat: une distribution saura reconnaitre le materiel X mais pas Y et une autre Y mais pas X --> beurk!
Et ça dure depuis pas mal de temps..
Un installeur unique sous 2 formes: texte et graphique, avec une base de rêgles et de script que tout le monde amméliorerait devrait être plus fiable.

Mais les distributions aurait beaucoup de mal a se distinguer: on n'est pas près d'avoir un installeur "en béton armé"..

Merci pour l'URL sur les diapos..

Sinon, je sais qu'un exokernel ce n'est pas la meme chose qu'un micronoyau..
Mais je me demandais pourquoi personne ne semble s'interesser aux exokernels (a part les chercheurs du MIT) alors qu'apparemment ce type de noyau s'inscrit dans le "mouvement de decentralisation" (comme Hurd) avec, d'apres l'article que j'ai lu, des performances comparables (voire superieures) au noyaux monolithiques..

QNX, Chorus sont deux micronoyaux qui fonctionnent vraiment par exemple.
Et il y en a d'autres..

Je me souviens que quelqu'un avait parle de les mettre en ligne..

Sinon quelqu'un s'y connait en exokernel?
D'apres ce que j'ai cru comprendre, c'est le meme principe que Hurd mais avec un noyeau encore plus petit et avec des bonnes performances..
Mais bon, apparemment les exokernel c'est encore un sujet de recherche, et je ne crois pas qu'il y ai de tentative pour en faire un OS utilisable..

Pas d'accord pour thread, fil n'est pas une bonne traduction: c'est du mot a mot!

Si tu tiens a traduire; je prefere "processus leger" ou tache..
Tache est plus court mais n'est pas tres "clair": pour beaucoup de personne tache == processus..

Mais les deux ne sont pas tellement employes: si tu parles de thread a quelqu'un dans l'informatique il voit de quoi tu parles, si tu lui parle de processus leger, il y a tout les chances d'avoir le dialogue suivant:
- qu'est-ce que c'est un processus leger?
- une thread
Un peu paradoxal, non pour une "traduction"? :-)

Quelqu'un connait?

J' ai suivit les liens mais je n'ai pas bien compris pourquoi Intel l'avait poursuivit en justice..

Certains supports de cours se trouve sur le site web de Parinux:

http://www.parinux.org/conf-supports.php(...)

Pas beaucoup, malheureusement..

Ce n'est pas un troll.. (soit dit en passant je trouve plutot rigolo de perdre des points sur un post ou je me auto-scoré a -1).

Tu vois dans KDE, le systeme du objprelinker?
Ce n'est pas pour se faire plaisir qu'ils ont fait ça, mais pour combattre les insufisance du linker/loader pour les librairies partagées: en gros à chaque fois que tu charges un librairie partagée, les symboles sont relogés ce qui peut être très gourmand en temps..
A terme le relogement ne devrait plus etre fait qu'une fois (sauf en cas de conflit)


Sinon une étude a montrée que ~650 Ko de mémoire sont perdus pour chaque applications KDE non-lancées par la bidouille des kdeinit.
C'est un probleme lié au GCC/binutils.

http://dot.kde.org/1000983828/(...)

Ces problèmes ont été rapportés il y a déja un certain temps, mais ils ne sont toujours pas corrigés.. (en version stable tout au moins)
Car c'est du niveau "tres grand gourou" pour pouvoir faire ces corrections..
CQFD: même en open-source, un bug n'est pas forcement corrigé le lendemain..

Pour la correction de petits trucs, oui..

Mais bon, ça fait combien d'ANNEE que KDE est handicapé par les faiblesses de GCC et des binutils?

Pourquoi le problème est lent a être corrigé? Parce que personne n'est payé pour le faire et que le problème est très complexe..

Bref "la supériorité incontestable du libre", c'est un argument religieux ça, rien de plus.

Hop -1 car totalement hors-sujet.

Heu oui desole, j'ai joue a la demo de FAKK pas a celle de FAKK2.

Greffier rayez ma derniere phrase :-)

Merci d'avoir corriger.

J'ai joue' a la demo sous Windows et ca n'a aucun interet: pas de rythme, maniabilite du personnage approximative.. Beurk.

Le seul interet de FAKK est que le personnage que l'on controle est une bimbo en tenue sexy.. On sent l'influence de Lara Croft.
Un peu leger comme argument de vente..

>> * AUCUNE possibilité de déclarer des variables! (comme en Python, d'ailleurs)

>C'est commun à absolument tous les langages de scripts, et même tous les langages faiblement typés je crois.

Bin et Perl ?? Une "exception notable" non??
Ca doit etre encore le language de script le plus utilise (les shells mis a part bien sur).

Je suis d'accord que Ruby et Python restent beaucoup plus propres que Perl, malgres ce defaut, mais bon Perl est tellement moche (a mon avis) que ce n'est pas un exploit..

Les fautes de frappes bien planqués qui ne se montrent que chez le client (loi de Murphy), ca arrive et c'est quand meme dommage que ni Ruby ni Python ne permette d'éviter cela..

J'ai meme vu sur la mailing-list de Ruby que matz (l'inventeur de Ruby) avait fait une erreur de ce type (je ne me souviens plus exactement quel message, désolé).

Dans l'entreprise ou je bosse, les regles de codage en Perl imposent l'utilisation de "use strict" et aussi les warning (pour eviter l'utilisation de variable non-definie).

Je trouve que ca fait gagner du temps de developper en activant ces options..

J'aime bien Ruby aussi, mais il y a quand meme des trucs qui me gene:
* AUCUNE possibilité de déclarer des variables! (comme en Python, d'ailleurs)

En Perl, la déclaration des variables est optionelle (et non nécéssaire par défaut), mais elle existe: c'est très utile pour les gros programme, moins pour les petits scripts.

si ecrivez le code suivant en Ruby:

maVariable = 1
if ( <une condition> )
then
maVariablee = 2 <-- faute de frappe
end

<utiliser maVariable>

Il n'y aura aucune erreur.. Bon courage pour retrouver pourquoi le script ne marche pas dans certains cas.

Ruby et Python sont "plus strict" que Perl pour la lecture de variable inconnu, cela limite le probleme..
Mais franchement c'est un peu dommage: Ruby et Python sont meilleurs (a mon avis) que Perl pour écrire des gros programmes mais ils leur manque tous les deux la déclaration de variable et l'équivalent de "use strict"..

* un petit defaut:
a = b + c
ou
a = b +c
peuvent avoir des comportements differents..

Non, c'est compatible avec la GPL.

D'accord pour la premiere partie.

Pas d'accord pour la seconde: la license BSD autorise tout a fait les entreprises a "piquer du code", c'est le choix des developpeurs, point final.

Moi, personellement j'aime bien cette "traduction".

Ce n'est pas tres employe, mais je trouve que ca resume bien l'esprit..

Donc bonne journee aux bitouilleurs et aux autres :-)

Vu dans les logs du kernel d'Alan Cox:
2.4.10-ac6:
[coupe]
PPP over ATM support (Mitchell Blank,Jens Axboe)

loopkin vu que tu as l'air de comprendre comment ca marche (ce qui n'est pas mon cas), ca va changer quelque chose ca?

Mis a part que ceux qui utilisent le driver Alcatel n'auront plus a patcher le noyau, je veux dire..