reno a écrit 3879 commentaires

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..

Tiens il faudra que j'essaye rpm-get..

La liste des miroirs pour urpmi ?
Je crois que urpmi ne fonctionne que quand tu lui donnes un "media" donne.
urpmi.addmedia <nom> ftp://.....(...) with <chemin relatif au hdlist>.
Pour plus de renseignement: man urpmi.addmedia.

Je trouve aussi que les distributions ne se piquent pas assez de choses entre elles.

C'est vraiment dommage qu'il y ait presque autant d'installeur que de distrib..
On arrive a des situations ubuesque du style
- ma carte A est reconnue par la distribution toto mais pas tata.
- ma carte B est reconnue par tata mais pas toto.

Beurk!

Mais bon, le syndrome NIH ca marche aussi sous Linux: rpm/deb, installeur, etc..

Si tu crois vraiment a tous ce que tu viens de dire, j'ai un beau pont a te vendre..

Deux petit conseil:
- lis le Hennesy & Patterson sur la conception des architectures RISC.
- pour les filtres photoshop: l'unite AltiVec est certe tres puissante, mais elle n'accelere que certaines partie de certains programme: typiquement les filtres..

En calcul entier, les PPC actuels sont un peu faible, de plus la memoire est un gros point faible: un RISC a besoin de plus de bande passante qu'un CISC..

Apple soutient toujours le CHRP?

Il avait fait un petit comparatif Visual C++/ Gcc en C++ non-standard (ne pas utiliser std::cout)/ Gcc avec C++ standard.

Le resultat au niveau temps de compilation, taille des binaire gener'e etait sans appel: Visual C++ etait plus rapide et generait des binaires plus petit que Gcc.

Avec en plus les probleme suivants de Gcc avec du C++ standard:
-grosse augmentation du temp de compilation
-le binaire genere est beaucoup plus gros.

Le probleme persistait avec Gcc 3.0...

Ca plus les "problemes" de KDE avec le linker..

Bref, pour le C++, Gcc c'est pas encore vraiment top..

Je trouve que ton message est tres bien et je suis d'accord sur presque tout.

La ou je ne suis pas d'accord:
> et si les US voulaient ils auraient pu éliminer
> Sadam depuis longtemps, dès la guerre
> d'ailleurs, mais ils ne l'ont pas fait.

Euh, ce n'est pas forcement si facile de tuer quelqu'un, ca depend pas mal de l'entourage, de ses moyens de protections, de sa chance..

Un exemple: Hitler, qui a survecu a tous les attentats..

Maintenant je suis plutot d'accord qu'ils auraient du tout faire pour l'eliminer lui plutot que d'affamer le pays entier!

Et s'il y en a un autre du meme genre qui prend la place: meme traitement..

que l'entrevue ne parle pas du "petit" probleme d'insolvabilite..

Il aurait ete interressant de savoir qu'est ce qui a cause cette situation..

Qui dit P4 + DDR dit plus de vente du P4, meme si c'est avec un chipset VIA plutot qu'Intel.

Donc, a priori ce serait l'interet d'Intel d'autoriser VIA a vendre ses chipsets..

Je pense que Intel doit quand meme faire plus de benefice sur un P4 que sur un chipset!!
Or P4 + Rambus --> trop cher et P4 + SDRAM PC133 --> performance pauvre (pas assez de bande passante avec la memoire).
Le resultat?
Les ventes du P4 n'ont pas atteint le niveau espere par Intel.. Logique..

Intel devrait donc chercher a avoir le plus tot possible P4 + DDR pour eviter d'avoir des defections vers AMD et l'Athlon.. Or ils font un proces a VIA??

Bref, je ne comprends vraiment pas la position d'Intel.

Juste une petite question "innocente"..

Non je dis ca parce que quand j'ai lu la FHS, je l'ai trouve tellement bien faite (ce n'etait pas la 2.2 mais une vieille version) que j'etais incapable de repondre a ca..

Bah, c'etait juste pour dire que la hierarchie de fichier sous Unix c'est toujours le b... (d'ailleurs le Nemeth "UNIX System Administration Handbook" est d'accord!)