zeSixty4Douille a écrit 75 commentaires

Tu peux desactiver le "fsck -y" lors des reboot. Sous Solaris 10, c'est desactive (ou alors + rapide).

Cette specificite d'UFS explique les performances du "rm" vs ecriture sur le disque.

P.S. : dans quels cas tu dois faire un hard -reboot sur tes wks sous solaris ? tu utilises SPARC ou AMD ? moi il n'y a que les coupures de courant qui font rebooter mes machines, et je fais de la 3D (il a fallu pas mal de temps au + de 1000 dev de NVidia pour faire des drivers fiables).

Il y a quand même une nouveauté interéssante selon moi, c'est qu'ils sortent des paquetages pour toutes les distros.

Au-dela des nouveautés proposées, il y a aussi le "feature freeze" concernant la version 3.5, aujourd'hui.

c'est vrai que le nombre des nouveautes n'est pas hallucinant concernant KDE seul. Il y a quand même 2, 3 trucs que je trouve bien sympa. Entre autres, l'intégration plus possée du viewer pdf dnas konqueror.


Puis je mérite un petit moinssage OK, car j'aurais pu propose mon aide, et je n'ai aucun problême avec Sylpheed ...

pourquoi il n'y a pas de news concernant KDE 3.4.2 ?

que Scribus ne soit qu'en "dépêche de seconde page" passe, mais c'est qd même un projet méritant KDE.

D'autant plus quand on constate les turpitudes de certains projets comme Mozilla dans leurs relations avec les mainteneurs de certaines distribs (tout ce qui n'est pas impactant pour Windows).

KDE propose déja des paquets fonctionnels pour toutes les distro importantes. Ils vont même pousser le vice jusqu'a ne promouvoir que distros qui ne soutiennent que Gnome (Ubuntu et FC).

Peut-être ne sont-ils pas assez bon sur le plan marketinje ... (c'est quoi ce projet qui ne demande même pas de donnation sur 1/3 de leurs pages web ...)

on peut importer des projets Eclipse en plus avec Netbeans 4.x. Eclipse me pose certains problemes, mais la derniere version est moins pire qu'avant sous Linux, par rapport a la version Windows.

Bref, manque plus que l'un des deux nous offre un plugin C++/C/Fortran/Perl/Python (avec ou sans completion).

Au dela des modifications d'architecture pour simplifier l'acceleration materiel, Exa ameliore l'acceleration Software.

Zack Rusin et Lars Knoll, c'est qd meme 2 gars au niveau d'un Alan Cox. C'est marrant de voir des dev de KDE/Qt faire du C.

moi aussi j'aime le c et pas la glib (c sauce gnome).

l'avantage du c pour le binding, c'est la simplicite du "language linker", cela permet aussi d'avoir un meilleur controle a l'edition de liens.

Le choix du cpp n'empeche pas Qt et KDE de faire des bindings tres rapidement, donc cela ne justifie pas le choix de gnome. L'autre paradoxe qui me fait aimer KDE par rapport a gnome, c'est la 'quasi' compatibilite binaire entre les versions 3.1, 3.2, 3.3, 3.4, malgres les options de compilation qu'utilisent les distros et le partage des composantes entre les appli.

Pour moi, utiliser la STL est un GROS handicap. Meme en 2005.

Faire abstraction de l'OS, c'est le but de tout le monde (sauf de la MFC).

je pense que le "Limited Edition" signifie qu'elle ne sera seulement distribuee via le site de Mandrake.

Il y a aussi le fait qu'il est difficile aujourd'hui de compiler 1 seul kernel, qui fonctionne sur toutes les machines, qui integre les dernieres nouveautes et reste modulaire. Une Fedora est stable, car 3 utilisateurs sur 5 recompile le kernel.

En tout cas, leur version de KDE 3.3.2 pete le feu (sur x86-64). Il y a de nombreux backport de KDE 3.4.

il y a des backports des principales nouveautes de KDE 3.4 dans le KDE 3.3.2 de Mandrake.

Par exemple KPDF, amaroK, les patches dans KHTML, et pour x86 et x86-64, la limitation du scoping des symboles (demarrage + rapide).

J'aime vraiment KDE, mais au lieu de conseiller SuSE sans arguments (autre que le numero de version), il aurait fallu qu'une personne test la version 64-bit de la Mandrake 10.2 (ou LE 2005) par rapport a la SuSE 9.2.

Sinon il y a aussi la KLAX quii est pas mal, qui fonctionne mieux chez moi qu'une Ubuntu.

depuis le 2.6, les APIs internes du noyau peuvent changer, ce qui doit rendre le noyau plus complique a maintenir.

Pour cette raison, Fedora change de noyau comme de chemise, mais qu'en est-il pour les autres distrib ?

Ils ont du s'apercevoir aussi que tout le monde n'utilise pas de Thinkpad, que meme certains essayent de profiter de periferiques USB. Meme que d'autres peuvent detester HAL. Puis d'autres encore aimeraient comprendre pourquoi il ne faut plus compiler certains modules direct dans le noyau, sans explications.

rien a voir avec la libc. tu devrais pouvoir changer pour une application la taille des pages pour les archi le supportant (pour la heap, la stack ou le code). On devrait pouvoir le faire pour une lib ou un process precis.

Quand au gains, j'ai vu certains scenario passer 50 % de leurs temps a convertir des adresses physiques en adresse virtuel en 32-bit (dependant de l'archi).

Je trouve desolant qu'actuellement, Linus passe plus de temps a faire des fixes pour les portable IBM qu'a developper serieusement. Les mecs de Debian et de Fedora devrait lui lacher la grappe.

Je trouve desolant aussi que l'on parle ENCORE de l'ACPI.

J'aime pas IBM.

pfffffffff

les outils qu'IBM mettra a disposition seront-ils libres ?

Zend Technologie est-ce cote en bourse ?

Vous comptez les exercer quand vos options chez IBM ?

la musique, c'est quand meme un vieux truc par rapport au jeux video non ? Il y avait de la musique AVANT les trucs d'entubage en ligne.

On peut deplorer que les jeux video ne soient pas cross-plateforme, OK. Mais les consoles n'ont pas encore toutes la meme archi, les jeux profitent du HW et l'aspect artistique est encore lie aux capacites de la machine. C'est vachement moins vrai pour un morceau de musique.

Ce que je ne souhaite pas, c'est que la musique devienne comme le jeux videos. La musique n'a pas ete inventee pour faire vendre la prochaine generation d'OS Microsoft / Apple.

je sais que pour les distribs basees sur les rpm, on peut utiliser les src.rpm puis les compiler avec les options que l'on veut.

moi je n'arrive meme pas a faire un dladdr ou un nm sur une lib, dans les distrib releasee. il faut juste se retrousser un peu les manche pour pouvoir le faire. Ca aurait ete bien d'avoir un article qui parle de ca au lieu de parler de gconf ....

Pour corriger un probleme sur la Beta d'XP, tu pouvais acceder au CVS ??? La beta d'XP, c'etait du Windows 2000, c'est pas un truc completement nouveau style NT ou Mac OSX.

Pourquoi tout ramener a Microsoft, par ton commentaire tu soulignes le probleme de la news, qui souligne que ce ne sont que les utilisateurs qui trouvent les bugs !!! limiter la detection de bug dans le libre a bugzilla, SUPER, tu merites de te faire plussoyer ....


C'est une mauvaise chose de ce baser sur des exemples (du style MySQL). Mais je peux t'assurer qu'un changement de compilateur peut reveler des problemes. Quand tu fais de la certification, tu certifies une appli, c'est par rapport a une plateforme, c.a.d un compilateur, un OS, et toutes les dependances de l'appli (pourquoi certains UNIX livre l'OS et le compilateur ensemble ??? essaye de linker KDE ExtraGears compiler en gcc 2.95 avec KDE compile avce gcc 3.4.3 )... mais c'est pas le sujet de la news.

Dans les softs fourni par Microsoft, tu dois prendre en compte le probleme de la compatibilite binaire, qui limite les modifications potentielles qu'ils peuvent appliquer. Puis entre le CVS de Microsoft et le client finale, il n'y a qu'eux, et une fois que le client final a le produit, il ne peut plus trop y avoir de modifications. La compatibilite binaire doit etre assuree tout au long de la vie du produit.

Entre le CVS de KDE, et ce que tu vas trouver dans ta distrib, il y a de tres nombreux intermediaires, et pas seulement ta distrib. Deplus, il n'y a moins de contraintes conscernant la compatibilite binaire.

Microsoft a des contraintes supplementaires par rapport aux logiciels libres. Ce que j'entends par tests autos, ce sont des tests qui vont te permettre de valider une modification. Dans leur contexte, ils n'ont pas le choix que de tout tester via des tests auto. Si tu prends une nouvelle CG, les drivers seront fait par NVidia, donc hors de question de ne pas tester dans tous les sens. Tu prends Sun, ils developpe eux meme leurs drivers, mais la contrainte est la meme conscernant la compatibilite binaire.

Le libre a d'autres contraintes, c'est d'etre portable, de limiter les dependances sur des techno ponctuelles, et d'interesser les developpeurs. Tu prends un truc comme "udev", qui s'est impose soudainement dans les distrib recentes, tu n'as pas de telles modifications dans un produit proprio en cours de vie, encore moins si c'est une version de Windows.

Donc la demarche de faire des tests autos dans le libre est moins utile, et plus chiante a mettre en oeuvre. De toutes facon, tu installes MySQL a la main, tu as un minimum de tests evidement, mais faire des tests exhaustifs, alors que c'est pas leur plateforme de dev, que le compilateur que tu utilises, c'est meme pas gcc, si tu veux que ca marche, il faut commencer par interesser le dev. Et pas tout miser sur les tests autos, car tu ne peux pas prevoir tous les problemes a l'inverse, chez Microsoft tu n'as pas cette incertitude.

L'article arrive comme un cheuveux sur la soupe, sans rien prendre en compte, et ne parle meme pas de l'existant conscernant la facon qu'on les releases de version majeur de ce faire.

Codez proprement, et ne perdez pas de temps a maintenir des tests unitaires.

Debian, le truc qui a 12 ans de retard sur les autres distrib, qui essaye toujours de stabiliser KDE 2.2 avec gcc 2.95 ?????????

ou mieux, tu definies 1 variable de debug differentes pour chaque module de chaque framework. de toutes facon, je l'appelerais meme pas DEBUG cette variable, pour deboguer, tu compile en "-g".

J'aime vraiment pas les ASSERT de partout aussi, ainsi que les tests redondant sur les pointeurs NULL.

Si un probleme peut intervernir dans ton code qui n'implique pas forcement un crash, alors la OK. Tu ne deposeras jamais une ligne de code dans le noyau comme cela.

Je vais répondre differement cette fois :

Simplemenet, selon moi, si on pouvait deboguer directement du code optimise sur les distrib majeurs, ca vaudrait 1000 fois mieux que des tas de tests autos a maintenir.

tu passes d'un extreme a l'autre.

1 - je n'ai jamais dit qu'il ne fallait pas faire des tests autos, j'ai simplement dis que c'est la demarche du nivellement par le bas. Les entreprises qui font du proprio utilisent principalement les testsautos pour tester les dependances (CORBA, Orcle, DB2, Java, la CG, le compilateur .......). Microsoft, pour certifier du HW, et pour eviter d'employer 150 indous.


2 - La meilleur chose a faire pour apprendre Qt si tu n'as pas de connaissances prealable :
1-> faire les tutoriaux,
2-> consulter rapidement la doc,
3 -> COPIER pour ne pas perdre de temps, voir mieux, tu regardes l'archi depuis le code deja compile (tu peux trouver la classe la composante qui fait le travaille dont tu as besoin, puis tu peux a nouveau consulter la doc).

Ne me dis pas que tu as appris la MFC depuis la doc ??? sans consulter qq exemples et que finalement, ce sont eux qui t'ont permis d'avancer ...


Je maintiens que les tests autos c'est une perte de temps pour le libre, cela dit, ca ne veut pas dire que c'est inutile, je consacre 40 % de mon temps a faire du code qui tests differents cas de figure, JE FAIS PAS LA LECON de morale , avec des arguments a 2 balles en vantant des bienfaits triviaux. Quand tu as acces aux sources, il y a autant de "release manager" que de presonne qui compile leur programme. Donc cet article n'a rien a faire en premiere page (mais j'en ai franchement rien a foutre qu'il y soit, mais j'avais une plus haute estime pour ce site).

Pour moi les tests autos, c'est le nivellement par le bas.

bravo, moi je veux savoir comment programmer des compteurs HW sur ma machine pour profiler mon appli, je prends une application qui les utilisent, puis libs, puis les symboles puis je comprends.

Certe ca ne marche super quand c'est une API complexe, ou de haut niveau, quoique. J'ai appris OpenGL comme cela, et c'est surement plus optimise ce que je fais que ce que font les dev qui lisent toues les doc, sans rien comprendre (va leur demander de placer un prefetch, ou autre...).

Regarde Linus, il a commencer en regardant le code assembleur de petit jeu, puis les a ameliore.

Pour la question des tests que souleve l'article, je trouve cela VRAIMENT indignant sur la connaissance qu'on les modo des dev du libre. Il ne s'agit pas de ne pas faire de tests auto, il s'agit de comprendre l'interet d'avoir acces aux sources, de comprendre qu'il vaut bien mieux perdre du temps a faire du code vraiment clean, qui donne envi, portable, qui passe nickel sous valgrind, plutot que de perdre du temps a tester toutes les combinaisons de fonctionnalite betement. Encore une fois, je prefere un petit bug a du code pourri.

Imagine devoir faire des tests auto du release manager de KDE ... tu dois tester toutes les options de compilation, sur toutes les plateformes, avec toutes les CG du monde, sur plusieurs niveau de Xorg et de toutes les autres dependance (pour faire comme l'industriel de binaire). Ca t'avancera a quoi ? il n'y aura pas moins de bug. Par contre si ton code est lisible, en 20 minutes un utilisateur eclaire pourra t'aider. Ca plus une bonne communication.

c'est banale et caricaturale ce que tu dis.

C'est evident qu'il faut tester ce que l'on fait.

Le probleme c'est que l'article c'est :

"ouuuiiinn, y a pas de techniques triviales pour faire des tests de regression dans le libre. Sachez mes enfants que dans les entreprises serieuses, il y a ce que l'on appelle des tests. Important les tests me direz-vous, mais oui, qu'en pensez-vous? sachez aussi que la doc c'est important !"

"je suis de bonne humeur ce matin!"

Allons de ce pas implementer VB dans KDE pour faire ouvrir des URL a Konqueror.

Vite, gerons correctement les exceptions et testons les pointeurs NULL.

Ce qui compte dans le libre, c'est la qualite du code. Et pas se reposer sur des techniques pour prevoir comment prevoir la meteo.