Psychofox a écrit 10743 commentaires

mouais c'est pas vraiment le fait que c'est plus facile de voir qui est important, ce serait plutôt qu'on puisse l'éditer directement...j'espère que c'est aussi le cas. Sinon ça ne sert à rien.

une sorte de Voltalinux donc (un core linux + pkgsrc) ?

faut arrêter avec le délire de persécution.

y'a pas de raison, ça s'installe bien sur d'autres distribs.

Par supporté, faut juste entendre qu'IBM fera du support dessus.

ben c'est la que tu rejoins le point que j'ai cité plus haut à savoir que "La plupart gardent ce qui marchent et ne mettent à jour qu'en cas de réinstall de l'OS, ou lorsqu'ils sont coincés".

Mais ça ne répond pas à ma question. Ou est le problème ? En quoi Linux rend la tâche de mise à jour manuelle des logiciels plus difficile que sur les autres OS ? Je vois plutôt le contraire...

je crois que ultimate stunts (la sorte de clone de 4d sport driving / stunts) par exemple le demande. Je dis ça de mémoire parce que j'en ai testé quelques uns et ne suis plus sur duquel.

Certes pour l'utilisateur avancé cela ne pose actuellement pas trop de problème et l'intervalle de parution de beaucoup de distributions tourne autour de 6 mois mais pour l'utilisateur "ordinaire" cela peut poser des difficultés insurmontables.

J'ai de la peine à comprendre le problème ?

Que fait l'utilisateur ordinaire sous un windows ou macos X pour mettre à jour ses applications et suivre les nouvelles versions ? Hormis pour quelques applications comme acrobat qui proposent de se mettre à jour toutes seules (ce qui peut-être fait sous linux, mais ça regarde le developpeur de l'appli, pas les distribs ni l'utilisateur), c'est l'utilisateur qui le fait à la main.

Hors il n'y a rien dans les distribs linux qui empêche l'utilisateur d'installer ses applis à la main sans passer par les packages officiels de la distrib.

De plus la plupart du temps l'utilisateur "ordinaire" d'un os proprio ne suis même pas les nouvelles versions de ses logiciels (il a déja du mal à avoir un antivirus à jour). La plupart gardent ce qui marchent et ne mettent à jour qu'en cas de réinstall de l'OS, ou lorsqu'ils sont coincés (du genre quelqu'un leur envoit un fichier que le version ne lit plus). Quelque soit l'OS, y'a que les bidouilleurs et accros du tout nouveau qui mettent à jour leur gaim/winamp/etc régulièrement.

concernants les differentiels, ils étaient pilotés electroniquement jusqu'en fin 2005. Et la règlementation a changé depuis 2006 justement. Probablement pour aider les privés et petits constructeurs comme Skoda ou Hyundai (qui ont quand même quitté la scène cela dit).

il ne s'agit pas de part de marché mais des taux d'utilisations vers des sites web francophones..

eclipse powered :o)

oups oui désolé...

je confirme, ça m'a l'air extra lourd au premier abord...

Et à part la lourdeur et une présentation un peu différente (onglets, sorte de touche "compose"...) , je ne trouve pas que ça apporte grand chose. En plus on se retrouve avec un gros mélange avec des bites de dialogues et menus gtk et du java (désolé je ne connais pas bien les noms des différentes biblio graphiques java...). Pas très consistent donc.

C'est fourni sous une licence sun qui stipule que les composants suivants ont leurs licence propre :

Apache Ant v.1.5.4
Apache Ant v.1.6.5
Apache Axis v.1.0
Apache Axis v.1.4
Apache Derby v.10.2.2
Apache Harmony
Apache Jakarta Commons BeanUtils v.1.6
Apache Jakarta Commons Codec v.1.3
Apache Jakarta Commons Collections v.2.1.1
Apache Jakarta Commons Collections v.3.1
Apache Jakarta Commons Digester v.1.5
Apache Jakarta Commons Discovery v.0.2
Apache Jakarta Commons EL v.1.0
Apache Jakarta Commons HttpClient v.3.0
Apache Jakarta Commons Lang v.2.2
Apache Jakarta Commons Logging v.1.0.4
Apache Jakarta JSP Standard Tag Library v.1.1
Apache Jakarta ORO v.2.0.8
Apache Jakarta Tomcat Jasper2 v.1.0
Apache Lucene v.1.4.3
Apache Tomcat v.5.5.17
Apache Xalan-Java v.2.5.2
Apache Xalan-Java v.2.6
Apache Xerces-J v.2.6.2
BCEL v.5.0
Bitstream Vera Fonts v.1.10
Boost v.1.27
BrowserLauncher v.1.4b1
Cairo Binding
Cairo Library v.1.0.2
Eclipse v.3.2.2
Eclipse v.3.3
eRCP v.1.0.2 SWT Mobile Extensions
Expat v.1.2
fdlibm v.1.5
HSQLDB v.1.7.1
ICU4C v.3.4.1
ICU4J v.3.4.5
Independent JPEG Group's LIBJPEG Release 6B
Info-Zip UnZipSFX stub file v.5.50
Info-Zip (unzip.c only) unzp50p1
JavaCup v.10k
JPEG 6b
JTOPEN v.4.4
MATH DTD v.4.01
MD5
Mozilla Binding
msvcr71.dll
OpenOffice.org v.1.1.0
OSGi Materials 4
Pixman v.0.1.6
Quick v.1.0.1
RegExp v.1.2
Root Certificates
RSA Data Security, Inc. MD5 Message-Digest Algorithm
STLPort v.5.0.2
Unicode Data Files
W3C DOM Level 3 Core specification
WSDL4J v.1.5.1
WTP v.1.5.3
XML4C v.5.4
XML4C v.5.5 (Xerces-C++ v.2.6)
XML-APIS v.1.2
XSLT4C v.1.7
Zlib v.1.1.4
zlib v.1.2.2
zlib v.1.2.3

Donc il y'a bien des bouts de OOO...

Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.
Ca confirme donc ce que je disais :
(passage en gras ce sur quoi tu confirme mes dires)

Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.

ça ne confirme rien, c'est hors sujet...

Dire 'c'est pourri jusqu'a la moelle' (traduction de defective by design : on pourra jamais en faire qqch de bien sans tout recasser), ben désolé pour moi c'est pas une 'petite critique sans importance'.

Sauf que citer "defective by design" comme fait plus haut sans lui ajouté l'explication qui suit, c'est juste passer un post à la machette pour lui faire dire ce qu'on veut.

D'ailleurs pourri jusqu'à la moelle n'est pas du tout une bonne traduction de defective by design. pourri implique une décomposition, dégradation. defective by design au contraire implique que le choix du design est mauvais à la base. Bref comme tu sais très bien pervertir les phrases des autres pour y donner le sens que tu veux, c'est pas vraiment la peine que je continue la discussion.

je n'ai pas vu une argumentation qui tient la route, juste un passage à la machette du post précédent suivi d'accusations ou remarques évasives. Sa seule argumentation c'est "openbsd n'utilise que gcc3.3" sans qu'il ne se pose la question du pourquoi et du comment. Le-dit pourquoi étant très bien expliqué dans la citation de espie@.

Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.
Et je tend a etre plutot de son avis.

Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.

'fin sauf si tu considère que quelqu'un a plus de légitimité à critiquer le Guitarangi da Gamba s'il ne sais pas jouer de la musique...

Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc.
Et tu quote un truc qui ne parle pas de pcc, ca tombe bien.

note qu'il y'a un "si" dans ma phrase, parce que l'idiot n'est pas capable de se rendre compte qu'OpenBSD n'est pas un être humain mais un OS. Et je contredis un post lançant des accusations vagues et sans sources, c'est donc difficile d'être plus précis...

Du reste personne n'a vomi sur gcc
Non dire que c'est 'defective by design' ou alors que le "design is perverted", c'est des compliments hein

euh...as tu une idée de la notion de contraste et de nuance. Entre ne pas être d'accord avec un choix de design (comme l'est Marc Espie) et "vomir" dessus, il y'a une nuance. Si espie@ "vomissait" sur gcc, il ne se serait jamais cassé le cul à y contribuer...

J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc

euh...qu'est-ce que tu fais dans ce journal alors ?

Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...

C'est qui OpenBSD ? personne. Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc. La seule chose que Theo et Miod ont fait, c'est accepter l'inclusion de pcc dans le cvs de openbsd pour pouvoir bosser dessus.

Maintenant faut pas mélanger les propos personnels d'un leader de projet, les choix techniques de plusieurs autres et les avis de ses utilisateurs...

Du reste personne n'a vomi sur gcc. Le titre de undeadly, c'est "BSD Licensed PCC Compiler Imported" et le log de l'ajout dans le cvs est "Import ragge's version of PCC into our tree, so we can hack on it more easy. ok deraadt@ miod@" et pour netbsd c'est "Initial import of ragge's version of pcc, version 0.9.8. This is the latest version of the portable C compiler" suivi d'une description et un historique de pcc. Rien dans tout cela n'attaque le projet gcc.

> Les besoins diffèrent, les distros diffèrent.

Pourquoi cette fatalité ? Où est-ce que c'est écrit ?

Parce que c'est la nature humaine.

Voila pourquoi tout le monde ne porte pas les mêmes chaussures, les mêmes pantalons. La même diversité existe dans tous les domaines, voila pourquoi il existe un gazillions de logiciels pour extraire des archives ou lire des fichiers audio sous windows, voila pourquoi il n'existe pas 1 marque d'automobiles, voila pourquoi on ne vit pas tous dans des maisons identiques, voila pourquoi certains préfèrent le bleu, d'autres le vert, etc ,etc.

olalala que c'est beau et facile de faire des remarques sur des sections de 5 mots qui ne sont même pas des phrases entières...ça évite de réfléchir.

Tu ne t'es pas posé la question du pourquoi justement gcc est en 3.3 dans openbsd ?

Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.

La question est : pourquoi il y a t-il autant de distributions, et pourquoi Linux ne perce pas ?

ça c'est très relatif. Si tu prends en compte les attaques incessantes contre linux et le marché desktop bouclé par certaines entreprises, je trouve que linux perce pas mal.

Petite remarque dont on parle souvent très peu :

certains jeux libres utilisent des prérequis non libres. Exemple : certains jeux nécessitent la librairie proprio fmod. Alors certe, celle-ci est gratuite et dispo sous linux, mais elle n'est pas libre.

tu veux des recommandations pour un psy ? Parce que la dans le genre "je crache ma haine et ma frustration sur tout ce qui bouge", tu nous sors le grand jeu depuis un petit moment...

Ce n'est pas parce qu'un projet est actuellement dépendant de gcc qu'il n'a pas le droit de critiquer certaines lacunes ou choix. Maintenant, si tu prends toute remarque négative comme une insulte envers ce projet, on ne peut plus rien dire dans ce cas la et rien n'avancera.

je te renvoies à nouveau vers la réponse de Marc Espie sur undeadly, notamment la partie sur le dev de gcc :

GCC is developed by people who have vastly different goals from us. If you go back and read the GCC lists, you'll notice several messages by me where I violently disagree with the direction it's following. Here is some *more* flame material.

- GCC is mostly a commercial compiler, these days. Cygnus software has been bought by redhat. Most GCC development is done by commercial linux distributors, and also Apple. They mostly target *fast* i386 architectures and PowerPC. A lot of work has been done on specmarks, *but* the compiler is getting bigger and bigger, and slower and slower (very much so).

- GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.

- There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.

- The whole design of GCC is perverted so that someone cannot easily extract a front-end or back-end. This is broken by design, as the GPL people do believe this would make it easier for commercial entities to `steal' a front-end or back-end and attach it to a proprietary code-generator (or language). This is probably true. This also makes it impossible to write interesting tools, such as intermediate analyzers. This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.

- As a result, you cannot have the new interesting stuff from newer GCC without also losing stuff... every GCC update is an engineering nightmare, because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.

- it's also very hard to do GCC development. Their branching system makes it very likely that some important work is falling between the cracks (and this happens all the time). If you develop code for GCC, you must do it on the most recent branch, which is kind of hard to do if your platform is currently broken (happens *all the time* if you're not running linux/i386). Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.

- some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes, which depend on mmap() at a fixed location.

- there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.

- some of the optimisation choices are downright dangerous, and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).

- don't forget the total nightmare of autoconf/libtool/automake. Heck, even the GCC people have taken years to update their infrastructure to a recent autoconf. And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.

I could actually go on for pages...

I've actually been de facto maintainer of GCC on OpenBSD for a few years by now, and I will happily switch to another compiler, so frustrating has been the road with GCC.

Je sais pas les cowon on les trouve à la fnac et dans d'autres boutiques (en tout cas en Suisse)...

j'ai justement cité cowon (mais j'aurai pu citer aussi trekstor) car ils supportent officiellement linux, ogg et compagnie. C'est pas du "ça marche par ce qu'on a de la chance qu'ils aient utilisé des choix technologiques compatibles sans volonté spéciale de supporter le libre".