PasRPasS a écrit 25 commentaires

Arithmétique du codeur libre: ça fait plus de code système à maintenir. Donc c'est pas top... d'autant plus si le code à maintenir *en plus" de c/bash est particulièrement "brain damagé".

"Euhhh 700 classes c'est petit."
Tu veux dire que tu en as une plus grosse? Noooooooooooon! C'est pas possible. Dis combien!

Ils auraient pu tout faire en C/C++/CGI(pour le web). Mais bon... y sont pas doués, peu rien faire contre ça... par contre ils savent se faire mousser sur linuxfr... là ils sont doués.

Mais non!
La solution ultime: l'objet(TM).
C'est connu que l'objet(TM) n'est jamais sale et c'est LA solution(TM) de tous vos problèmes et pour "tous les projets qui se veulent en adéquation avec votre métier"(TM)

Allez! Maintenant t'achète mon gros kludge STP! Et que ça saute!

"c'est juste de répondre aux vrais besoins"
Rooooh! qu'elle est belle! Je peux la citer sur le site d'e-consultant.

"Bootstrap JDK

All OpenJDK builds require access to the previously released JDK 6. The JDK 6 binaries can be downloaded from Sun's..."

"Binary Plugs

Not all of the source code that makes up the JDK is available under an open-source license. In order to build an OpenJDK binary from source code, you must first download and install the appropriate binary plug bundles"

Donc non et non. Y a pourtant un GNU Makefile qui traîne. Du svn à la place d'un git pour un projet 3 fois plus gros que Linux... maladroit.
Bien tenté de la part de Sun.

Allez, après cette digression sur du faux libre, hope-là! Retour au vrai libre.

"ce que je veux dire": tu pourras dire tout ce que tu veux, mais cela n'empêchera pas que dans la majorité des cas les plateformes des vrais langages de haut niveau perl/python/lua/ruby... sont optimisées pour la distributions des sources et les kludges mono/java pour le byte code.

Ché pas moi, va voir du côté de CPAN pour perl et dis-moi si ils distribuent *significativement* des modules en byte code perl. Le "setup" du python serait par défaut pour travailler avec du byte code python? Ou encore tu vas me dire que le déploiement des applications J2EE se fait à partir des sources?

Si tu as saisis, tu comprendras que tout libriste un tant soit peu éclairé et pas trop neuneu verra l'arnaque comme le nez au milieu du visage.

T'es pas doué non plus toi:
Le monsieur était dans le contexte du perl/lua/python/ruby/php et java/mono *tout court*.

Si tu rajoutes le C... et bin... je les mets tous à la poubelle et je garde uniquement le C.

Effectivement, je préfère les interpréteurs aux VMs pour les langages de hauts niveau, et donc je vois parrot d'un mauvais ½il. Mais bon, si le libre doit avoir une VM... pourquoi pas parrot. Encore des ressources gaspiller sur des Kludges...

Je vois encore plus d'un mauvais ½il "la donation" de la VM adobe au projet mozilla... c'est plus un piège à c... pour pousser le web vers le support du byte code, pour nous servir des clients riches web proprios (là où bien heureusement java a échoué lamentablement). Et là, mon âme de libriste est férocement contre.

Tiens d'ailleurs l'intéropérabilité de mono/java est très limité avec les autres frameworks. Perl/Pyhton et encore plus, Lua, font des merveilles: je peux d'un code assembleur (je caricature) utiliser du code perl/python/lua sans que ce code soit "préparé" à l'avance. Tiens Python va plus loin encore et permet directement de monter les shared objects et d'y appeler des fonctions grâce aux ctypes. Lua est balaise lui aussi et perl c'est facile aussi avec XS.

"sticky notes est toujours fourni avec gnome": ah bon? Bien entendu il est aussi accessible que son kludge d'alter ego?
"il est moins populaire": bah c'est comme MSN. Il est mis en avant agressivement, les users lambda ne verront que lui et forcément ils l'utiliseront avant tout. Belle façon d'acquérir de la popularité!
"Est-ce que tu râles si les distrib fournissent konqueror ou firefox alors qu'on pourrait se suffire de w3m pour aller sur internet ?" Bien sûr, c'est vrai que la complexité d'une application de prise de note est comparable à la complexité d'un navigateur internet moderne... bien qu'on est des super codeurs "libres" capable de le faire!
"Si tu n'aimes pas mono/tomboy, ne l'installes pas c'est aussi simple que ça. Rien ne t'interdit d'installer gnome sans lui." Les dernières fois que j'ai regardé, il était imposé par défaut, mais il paraît que Debian à capter le piège, maintenant il faut qu'Ubuntu suive (et les autres bien entendu).
Donc pas d'affolement, ne t'inquiète pas, si on continue sur cette lancé, j'aurais bientôt plus à me plaindre...

"c'est faux": non c'est vrai. Pour le moment les langages comme le python/perl/ruby/lua/javascript etc... sont orientés vers la distribution des sources et non pas de byte code. Java/Mono le sont par contre. Et sérieux, en tant que libriste je préfère les sources au byte code...

Fréquent certes, mais ça ne veut pas dire qu'il faut trouver ça bien.

Hope une nouvelle thread sur le sujet suivant:
Est-ce que java est vraiment GPL?
Peut-on installer un framework java *fonctionnel* à partir des sources par un simple:

configure;
make install

Oh!
Debian a réagi?? Ça ressemble à une super bonne nouvelle.
Bon, je ne suis pas rentrer dans le détails, mais en effet il semble que Debian ne s'est pas fait avoir. En tout cas si en sid ils sont rester du côté claire de la force... je sens que je vais me mettre à installer à nouveau des desktop debian gnome... mais alors, et Ubuntu dans l'affaire, ils suivent? La dernière fois que j'ai regardé ct pas brillant sur ce point là...

Toi, tu as loupé pas mal de marches:
Est-ce que tu as vu comment s'est imposé cette bouse de mono dans gnome?
Grosso modo, l'application sticky notes qui faisait très bien ce qu'elle faisait écrite en C et *simple* fut remplacé par l'autre truc qui fait le café et qui tire la dépendance du giga Kludge qu'est mono.
La chose la plus intelligente aurait été de laissé sticky notes, et laisser le choix à l'utilisateur de bloater sont système si il éprouve le besoin de plus de "features" pour une application de prise de note. Je te raconte pas les frondes du Novell Blog system, qui règne en despote pas du tout éclairé sur la communauté gnome, sur tout ceux qui ont essayé de sauver gnome de cette abomination.
Et puis perso, je préfère largement le python au c# (lua à l'aire pas mal: 1,1 Mo décompressé), mais si je peux le faire en C, je le fais en C et j'évite d'imposer le Kludge des frameworks de ces plateformes à mes communautés, car je suis un codeur libre, mais j'essaye de rester raisonné, car beaucoup oublient qu'ensuite il faut maintenir le tout, et plus c'est gros et complexe, plus c'est difficile et plus il faut de monde. D'ailleurs c'est une excellent méthode pour faire du faux libre: un gros giga Kludge que seul tes codeurs peuvent faire évoluer et maintenir... Mono et Java sont de beaux exemples pour Sun et Novell. Donc les codeurs libres qui piffent pas ça et qui ne veulent pas assumer, et bin je leur enverrai bien Chuck leur faire leur fête pour éviter qu'ils nous pourrissent nos desktops chéris avec leur cochonneries.

Je m'en fous de IsNotGood.
Ce que je veux savoir c'est si je peux avec le tar.bz2 des sources de java (toutes en GPL?), je peux faire un:
configure;
make install
et avoir une plateforme java complète et fonctionnelle.
Alors?

Salut le clown
Tu connais le "contexte" d'une dépêche: dans la dépêche sur mercurial y a GIT... GIT c'est du C... or dans cette dépêche mon opinion est python<C...
Dans cette dépêche, y a zope, c'est du python... hum... et java... et mon opinion dans ce contexte c'est java<python.
Bon, alors en fait, au lieu d'un pythonsaibien et d'un pythonsapu clownesque je te propose le théorème suivant qui recoupe 2 contextes différents... sisi:
java<python<C

Je dois avouer que je préfère le C.

"Es-tu sur que sa légèreté va en prendre un coup ?"

Tu sais lire, il a écrit "peut-être" alors avant de "Avant de s'insurger"...

"Dans l'absolu rien de prouve"... elle est belle celle-là, XFCE a vocation à être léger, pas gnome, donc à priori c'est plus léger, mais c'est évident qu'il faudrait aller vérifier, mais c'est très probable rien qu'avec la batterie des bibliothèques de gnome.

Je veux que les gens puissent *installer* optionnellement mono et ses logiciels, pas qu'ils puissent *désinstaller* optionnellement mono et ses logiciels. Donc je voudrais qu'ils puissent installer *optionnellement* tomboy, donc mono.
Je ne tolère pas plus ORCA écrit en python pour gnome "officiel" qui me donne de l'urticaire également, même si je tolère plus python que mono:
perl/python/ruby sont des plateformes basés sur des langages dynamiques, conçus pour avant tout pour faciliter la distribution de code sources, à ne surtout pas confondre avec java/C# qui sont à compilation statique conçus avant tout pour la distribution de byte code. Et je ne parle pas de la controverse sur mono/C#.
Si tu trouves ça incohérent, ou plutôt que les tenants et aboutissants t'échappent... ché po... laisse tomber l'informatique...

Pas faux, il a surtout beaucoup de côtés commençant par un C.

Les réseaux wimax sont déployés dans leur version mobile mais "bridée" en mode nomadisme. Y a un rapport de l'ARCEP sur le déploiement du wimax à Séoul.
Bref... accès internet illimité non bridé sur votre mobile... et quand les téléphone s mobiles ne seront plus que des terminaux VoIP sur le net... miam!
Est-ce qu'on aura assez d'IPs v4 en France quand tout ce petit monde sera sur IP? Hum... faudrait compter.

XFCE, pour ma part, est surtout le seul moyen d'avoir un bureau "officiel" basé sur GTK+ SANS cet m.... de bloat de mono. (Bon y a gentoo avec le mono use flag, mais les users lambda avec leurs distros basées sur des packages binaires sont n... bin ouaip...).
Gnome part en vrille, je suis dégouté mais bon, je ne perds pas espoir.

Une solution et une seule:
Pré-installation sur une vaste majorité des ordinateurs.
(pas 0.000001%... mais c'est un début on va me dire mais un début qui est loooong)

Non, tu as raison. Techniquement, Mercurial est une copie de GIT en python. Perso, ça me fait ch... qu'il soit en python, déjà automake en perl c'est à peine supportable alors vive GIT et son code en C. Tiens, l'autre jour j'ai aperçu un wiki dont le versioning est construit sur git.
Par contre les très mauvaises choses sont les mauvaises habitudes que vont prendre les codeurs utilisant SVN....

4 millions de ligne de code? 700 classes?
Elle est énOooOrme celle là.

Bref... cobol vers java... pas brilliant. Obsolète vers obsolète. Bravo.

700 classes: Wouhahou! Je te parie que tout ça va être maintenable comme un airbus A380 avec une clé de 12.

Bon au moins ce sont des serveurs tournant avec GNU/Linux. Une lueur d'espoir dans un océan de...

C'est toujours du Yum/RPM, mandriva?
Yum c'est du python, c'est très mal choisi pour un gestionnaire de paquets.
bash/c est le maximum autorisé pour des outils systèmes... pour ceux qui ne voit pas pourquoi, il faut arrêter de faire de l'informatique... comprendre allez bossez sur du MS, là vous pourrez faire des outils systèmes en VB.
Mais bon, les autres distros c'est pas beaucoup mieux:
Debian: aptitude en C++.
Gentoo: portage en python.
...

Bin tiens du java... voir plus loin... parce que je le vaux bien.
Il est toujours pas libre ce bloat de langage obsolète.
Y en a qui n'ont toujours pas compris que les langages de pseudo-haut niveau à compilation statique sont dépassés (cf java et ces sous-copies). Il faut utiliser les langages de vrai haut niveau (vraiment dynamiques) comme ruby/perl/python/lua/javascript couplés à des modules en C (allez... j'y met aussi le C++).
Bref, j'encourage fortement les gens à rester sur la version Zope et surtout passer à autre chose si la version Zope ne leur convient pas.