CrEv a écrit 4577 commentaires

heu, juste comme ça, le troll il est réchauffé depuis quand ?

juste parce que la balise ça doit faire un moment quand même qu'elle est intégrée, on peut ptetre passer à un autre argument non ? ;)

> Elle ferait mieux de se contenter de ce que propose sa distribution.

Non mais sérieux, tu crois vraiment ce que tu as écris ? ou alors il manque un smiley ...

Histoire de compléter, ils peuvent le promouvoir tant qu'ils le veulent, du moment que lightning ne sera pas compatible il n'y a aucune chance que je (et surement d'autres) migre vers cette version...
Avoir lâché lightning est juste une connerie sans nom à mon sens

> Illisible, en tous cas peu clair, et pas si symétrique (t'as une accolade seule sur sa ligne, l'autre sur la ligne du if, donc c'est pas la même chose)

En fait non, c'est justement symétrique
L'accolade fermante représente un "end if" et dans ce cas, si tu prend if() { comme begin et } comme end c'est symétrique.
Après, faut juste lire différemment le code, c'est tout.

Et de là à trouver ça illisible.. Vu que je ne lis pas les accolades, ton deuxième exemple est pour moi inutile, l'accolade ne sert à rien sur sa ligne, à moins que tu ne saches qu'il faut en mettre une après un if

c'est bien pour ça que je parle d'un éditeur avec coloration syntaxique (et non d'un langage utilisant la couleur comme élément syntaxique)
Déjà chacun peut choisir la couleur qu'il veut, le thème qu'il veut et pas (peu) de problèmes pour ça. De plus, il n'y a pas que la couleur, mais aussi la mise en forme (gras, italique, souligné, etc)

Mais par contre, qui imprime encore du code ? A quoi ça sert ?

> La couleur est un plus mais ne doit pas être essentielle
Oui, elle ne doit pas être essentielle pour le code, mais les outils sont importants pour coder efficacement.

> Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ?

ça je pense que c'est possible, mais en quoi faire grossir les entête (et par la même les besoins en terme de bande passante) vont faire baisser la latence d'HTTP et réduire la bande passante utilisée ?

autant je comprend bien l'exemple précédent, autant celui là je suis contre, tout comme l'absence d'accolades.
Car si ça peut sembler sympa en lecture, en debug ça devient horrible.
Imaginons un bug sur 'je fais ça', comment y placer un point d'arrêt ... sans réecrire le code ?
Comment savoir si je suis rentré dans le corps if ?
Comment je rajoute un 'else' également ?
Même sans être en debug, cela est génant. En debug, on interdit d'autant les possibilités d'édition à la volée.


> Il ne faut pas faire cela pour les parties essentielles du code mais on peut souvent le faire pour gérer les conditions initiales ou les tests d'erreur.

oui, mais le problème (en tout cas tel que je le vois tous les jours) c'est que si on autorise quelque chose, tout en sachant exactement pourquoi on l'autorise une fois, il y aura toujours un autre pour le faire là où il ne faut pas.
Et au final, on se retrouvera avec de la merde genre :

for(..montemplatemoisi... idx = 0; idx < ...plopplop.getLength() && plop(); ++idx) if
{
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
  plop
}
else
{
  plop
  plop
  plop
  plop
  plop
  plop
}

(^- code véridique, je l'ai gardé au travers de mes boulots comme condensé de mauvais examples)

En gros, si dans l'absolu je suis d'accord que c'est pas méchant et que ça peut apporter un mieux sur certains points, du moment que c'est bien utilisé, je trouve que les inconvénients (en terme de maintenance) sont bien plus nombreux.

> les boucle for de Go illisible par exemple
et si on voyait la même chose avec une coloration syntaxique efficace ? (prenant en compte tout le langage)
par exemple ce qui se trouve entre for/if/while/... et { pourrait être mis en évidence, et dans ce cas on aurait :
- lisibilité avec un bon éditeur (ce qui pour moi est bien plus important que la lisibilité sans)
- moins de caractères à tapper, moins de parenthèses oubliées
- conséquence du dernier, plus "fiable" dans le sens où si on ne peut pas avoir d'erreur (de frappe, d'attention) sur les parenthèses c'est un plus (genre if(myFunction(getMyParameter()) { qui est faux)
alors oui, un bon éditeur pourrait aussi le mettre ne évidence, mais en fait oui les parenthèses ne servent à rien dans ce cas...

> Et si on passait directement au XMPP, ca serait pas mieux ?

ha ben oui, ça résoudra surement le problème de latence d'avoir du xml bien verbeux plutôt que du plain text qu'on pourrait ptetre gziper par contre

on me siffle dans l'oreille que google aurait aussi travaillé sur un xmpp modifié pour être plus léger, moins verbeux, non ?

> grouper plusieurs instructions sur la même ligne afin d'améliorer la lisibilité

Dans quels cas ?
Pour ma part j'ai très souvent l'impression que condenser le code de cette manière améliore très très rarement la lisibilité (sauf pour le développeur qui trouve que c'est mieux, concis toussa,, mais finalement pour ne pas dire lisible que par lui ou pour réduire un nombre de ligne inutilement)

franchement je suis pas à le défendre, mais ton commentaire montre juste que tu n'as pas l'air de savoir à quoi ressemble Qt en fait...

$ rpm -qa | grep -i libqt
libqtgui4-4.5.2-0.10mdv2009.1
libqtopengl4-4.5.2-0.10mdv2009.1
libqthelp4-4.5.2-0.10mdv2009.1
libqtconcurrent1-1.2.1-0.1mdv2009.1
libqtdesigner4-4.5.2-0.10mdv2009.1
libqtxml4-4.5.2-0.10mdv2009.1
libqttest4-4.5.2-0.10mdv2009.1
libqtclucene4-4.5.2-0.10mdv2009.1
libqtwebkit4-4.5.2-0.10mdv2009.1
libqtxmlpatterns4-4.5.2-0.10mdv2009.1
libqtcore4-4.5.2-0.10mdv2009.1
libqtsql4-4.5.2-0.10mdv2009.1
libqtscripttools4-4.5.2-0.10mdv2009.1
libqt4-devel-4.5.2-0.10mdv2009.1
libqtscript4-4.5.2-0.10mdv2009.1
libqtdbus4-4.5.2-0.10mdv2009.1
libqtnetwork4-4.5.2-0.10mdv2009.1
libqtsvg4-4.5.2-0.10mdv2009.1


Maintenant, il est possible d'écrire un programme utilisant genre libqtcore et libqtnetwork et tu n'aura aucune dépendance vers X
Et si tu as des dépendances vers X c'est que tu as de mauvais packages...

oups vi, mauvaise frappe et mauvaise relecture ...
spa de ma faute si j'utilise emacs pour bosser ... (véridique en plus ;) )

exact, la souris ne sait tellement rien faire que t'es obligé d'utiliser le clavier pour émuler les boutons manquant ... quoique, je confond peut-être avec une souris designée pour gnome...

donc en fait, ce que tu dis c'est que tu as mal codé, pas testé les cas particuliers mais c'est de la faute à python car il a fait exactement ce que tu lui as demandé de faire ?

Mais en codant de la sorte (et si python est insensible à la case), t'es sur que tu vas pas non plus utiliser une variable maVariable alors qu'il y avait déjà mavariable plus haut, mais comme c'était dans une condition particulière ça explosera seulement 3 mois plus tard ?

> Si Python était insensible à la casse on aurait déjà moitié moins de problèmes.
franchement j'aimerais bien voir comment on aurait moitié moins de problèmes...
en général l'avantage donné à l'insensibilité à la case est surtout de montrer que dans certains cas où on écrit de mauvais programmes n'importe comment ben finalement ça peut qd même marcher...

de mon côté je préfère juste un poil plus de rigueur...

> Peut être qu'ils devraient être activé par défaut si on installe kde, mais lequel?

oui mais non, au contraire d'autres distribution c'est plus complexe que le simple choix d'un thème (en même temps s'il y en a 1 en main et 2 en contrib celui a activer serait celui le provenant de main) :
et si j'installe kde + gnome ?

ben oui, contrairement à beaucoup d'autres, mandriva est relativement "desktop agnostique" (mis à part les outils en gtk) et permet d'installer aussi bien gnome, kde, e, lxde, etc
y compris évidemment en parallèle (ma machine de boulot contient à la fois gnome et kde)

On est loin sur ce point de vue d'une {k|.}ubuntu fraiche ne comportant qu'un seul environnement.
A voir par contre, le contenu des One, vu qu'elles sont par défaut gnome / kde peut-être qu'elles ont les thèmes correspondant par défaut.

Donc voici ce qui explique probablement une différence de style par rapport à d'autres. Et à choisir, je préfère largement cela.
Evidemment dans ce cas c'est un peu plus à moi de faire mon environnement mais c'est déjà ce que je fais, donc ça me va.

Concernant ensuite les couleurs, il faut aussi voir (si cela n'a pas changé) que les couleurs dépendent de la version (powerpack, free, one). On peut toujours discuter de la couleur initiale, il est assez facile de la changer, j'aime en général pas mal leur version bleu gris light (je sais plus comment elle s'appelle)


Mais donc globalement, le problème de l'intégration ne se résume pas du tout à sélectionner un thème (même bien fait). Si on contraint fortement l'environnement on peut, mais sinon, on parle d'intégration dans quoi ? Et si on veut que ce soit relativement sympa dans la plupart des environnements des concessions sont nécessaires, et je trouve ça beaucoup mieux qu'un style assez bien leché mais qui craint dès qu'on ouvre un soft d'un autre type (kde sous gnome, gtk sous kde, qt sous ce qu'on veut, etc)

sans vouloir casser ta comparaison (je suis pas fan des red hat), tu compares quelles versions ?
car tu indique RHES 4.0 qui est assez vieillote, non ? La 5 est quand même sortie depuis 2007, il serait intéressant de comparer des versions assez semblables, non ?

> et les Mandriva.
c'est à dire ? (vu que tu ne compare que par rapport à redhat)

> Pour quelle raison un état ne devrait-il pas chercher à améliorer sa compétitivité ?

parce que tu as mal lu...
la phrase, que tu cites, veut dire :
"L'état ne devrait pas [...] pour augmenter [...]"

A aucun moment ils ne disent qu'il ne faut pas chercher à améliorer sa compétitivité, mais mais qu'il ne faut pas, dans ce but, commencer à lutter contre Microsoft bla bla.

Ok c'est assez proche et ça pose des questions, mais tout de même c'est pas la même chose ;)

>« je suis obstiné mais flemmard, je vais écrire quelques centaines de lignes de code histoire que ma machine bosse sans moi »

c'est pas un peu le principe de l'informatique / informaticien ? ;-)

http://linuxfr.org/2006/11/02/21567.html

> et ce même RMS a fondé une distro GNewSens qui est une Ubuntu dite libre.

t'es sur que c'est RMS ? je crois pas...

> L'utilisation est très agréable (quoi qu'un peu lente)

juste pour avoir des précisions, quel lien alors avec sa rapidité provient de l'utilisation de Pluf, framework PHP5 très optimisé et d'une manière générale, d'une attention pour la performance. tiré de la news

Sinon, comme le commentaire précédent, une installation simplifiée serait réellement appréciable, même si ça ne m'empêchera pas de le retester bientôt (j'utilise redmine pour le moment, mais InDefero me semble assez agréable à utiliser et faisant suffisament de choses pour moi)
Reste à voir (j'ai pas encore cherché, donc patapai) comment fonctionnent les workflow de gestion de bug (important pour moi)

> popup qui revient à l'infini, qui t'empêche à la foi de fermer l'onglet et la fenêtre, c'est un problème. Un utilisateur lamda devant ça il fait quoi, il redémarre sa machine ?

oui, et au redémarrage suivant il utilise chrome/chromium et jette firefox aux oubliettes

ok, désolé j'avais pas pris la phrase là concernant les outils d'admin, pour moi ça reste qq chose légèrement à côté, je pensais que tu parlais surtout des applications fournies par défaut (genre kde + gimp + firefox)

> en 2005/2006 il battait son plein et perso je ne supportais pas ce format qui m'avais casse plusieurs installation lors de mise a jours

sur quoi comme distrib ?
car c'est vraiment très rare les fois où j'ai eu ce genre de problème, et même bien avant 2005-2006...

> Et la pour rentrer dans ton troll c'est la faute du perl...
sauf que tu es encore une fois à côté de la plaque...
le troll n'est pas du tout sur perl, mais sur le fait de vouloir refaire les choses à partir de zéro tout ça parce que le langage intéresse moins alors que ça fonctionne déjà
et ça c'est débile, surtout si on regarde ce que ça a donné
le prédécesseur de yum (me souvient plus du nom) est juste inutilisable, yum commence à s'améliorer pas mal, mais que d'énergie alors qu'un équivalent existait déjà.
Si c'était pour faire mieux je dis pas hein, mais pour ça...

> Je trouve carrement debile les outils en Gtk sur un bureau KDE d'ou mon choix de pardus
Et ben voilà, tu vois que tu peux donner un vrai argument ;)

(par contre, même si c'est pas top, je préfère avoir des outils en gtk (ou en ncurses pour la plupart hein) que pas d'outil du tout...)

> malheureusement mandriva a eu des problemes de qualite qui ont fait que la version suivante a ete une ubuntu...
oki, donc en fait ça n'avait rien à voir avec deb / rpm / apt / urpm* / perl / python / plop

De la même manière (je sais que c'est pas le même commentaire mais bon) pour ce qui est de l'installeur, mandriva avait déjà une bonne grosse longueur d'avance, même lorsqu'on nous rabachait que oubountou c'était plus mieux en avance que c'était le prems, bla bla bla

> avoir un equivalent pour les rpm

tiens, faudrait que je regarde depuis quand la suite urpm est dispo et utilisable, mais disons que dans mes souvenirs je dois utiliser çà depuis en gros au minimum 8 ans et ça existait surement avant.
Il y a eu des progrès ensuite (de même que chez debian y'a aussi apititude qui remplace parfois apt-get) mais ça fait bien longtemps qu'il y a la solution pour rpm
et c'est pas parce que redhat/fedora se tripote avec des solutions foireuses que ça existait pas (ben oui, mais vous comprenez, c'est du perl, alors il vaut mieux tout réécrire en moins bien plutôt que d'utiliser un logiciel qui marche...)