Larry Cow a écrit 5011 commentaires

En général, les sociétés qui passent par des systèmes de terminal serveurs du genre citrix, c'est parce qu'ils en ont marre des utilisateurs qui cassent tout sur leur poste.

C'est ça. On n'a jamais dit que la virtualisation (de ce type) remplaçait les serveurs de terminaux, juste que ça permettait une centralisation similaire pour les gens qui ont des besoins hétérogènes (et donc peu éligibles aux solutions à base de terminaux "à l'ancienne").

D'ailleurs, je ne comprends pas vraiment ce que prétendent offrir de plus les solutions de virtualisation dans ce domaine la.

Un mélange des deux mondes?

Avec une solution à base de terminaux telle qu'on en fait sans virtualisation, ça veut dire un OS serveur "sur mesure", et commun à tous les clients. Ce qui a les inconvénients suivants :

- difficulté (voire impossibilité) de faire tourner les OS desktops de son choix. Exit WinXP (pas forcément un mal).
- homogénéité "forcée". C'est souvent souhaitable, mais parfois on aime avoir _un_ poste avec une configuration radicalement différente (le graphiste qui a absolument besoin d'un Windows alors que tout le monde est sous Solaris, par exemple).
- isolation limitée des ressources. Si un utilisateur fait planter ou encombre le serveur (avec un "vrai" OS, ça ne devrait pas arriver, cela-dit), les applications de tout le monde en pâtissent.
- pour limiter l'impact du point précédent, on est donc plus ou moins forcés de mettre en place des permissions bien restrictives à chacun. C'est parfois souhaitable, mais pas toujours.

Avec une solution à base de virtualisation, en échange d'une demande un peu plus élevée en termes de ressources (bin oui, on ne mutualise plus l'OS, dans ce cas, mais seulement le matériel), on élimine tout ou partie de ces restrictions

- chaque utilisateur a sa propre machine, fut-elle virtuelle. Donc, potentiellement, l'OS de son choix.
- il pourra installer, si l'administrateur l'autorise, ce qu'il veut sur son poste.
- sans risquer de mettre ses collègues dans l'embarras (pas plus qu'avec des postes physiques séparés, en tous cas).

Sans compter qu'on pourrait panacher les deux approches, et faire tourner un (ou plusieurs) serveur de terminaux virtualisé pour le "tout venant", et des postes virtualisés spécifiques pour les besoins spécifiques.

Non, lui il est payé pour garder un oeil sur linux_fr_ ;)

Le C++? compatible avec le C? Mouarf. Ni dans un sens, ni dans l'autre ;)

Objective-C avait su garder cette compatibilité : un programme C restait un programme ObjC tout à fait valide. Je ne sais pas ce qu'il en est advenu avec Objective-C 2.0, par contre.

- techniques. Internet est basé sur des protocoles libres et standardisés, donc parfaitement bien gérés par des logiciels libres. Ce n'est pas pour rien si le routage d'Internet se fait avec quasi uniquement des logiciels libres, depuis les serveurs DNS jusqu'aux machinbox.

Va dire ça à Cisco, ça va les faire marrer en maudits.

- philosophiques. Internet permet le partage de la culture et la diffusion d'informations. C'est également le modèle de développement du logiciel libre: partager l'information. Le libre se distribue d'ailleurs majoritairement via Internet, à comparer avec le propriétaire qui se vend via des supports physiques.

Ta comparaison est injuste : tu compares le libre avec du vieux propriétaire. Le logiciel non-libre, de nos jours, ça n'est plus la bonne vieille boiboite de MSOffice en carton glacé. Le logiciel non-libre, de nos jours, c'est pour beaucoup de "cloud" (Facebook, Google, ...), de l'hébergé "clé en main", et du "DRMisé à activation" (Steam, ...).

Opposer logiciel propriétaire et internet, de nos jours, c'est un peu limite.

- intercepter des communications privées (HADOPI). Tu permettrais qu'on lise ton courrier, "des fois que" tu envoies un livre photocopié?

Il n'a pas tort, ça n'a rien à voir avec le libre. Ou, plus exactement, ça devrait concerner bien plus que les défenseurs du libre. Mais toujours est-il que je ne vois pas de lien direct entre "logiciel libre" et "le gouvernement s'octroie le droit de lire mon courrier".

- se passer d'une justice équitable avec un respect des droits de la défense.

C'est grave, mais même remarque : rien à voir avec le libre.

Verrouiller Internet.

C'est déjà plus pertinent.

Vouloir filtrer le P2P, c'est porter atteinte à la neutralité des réseaux,

Non, vouloir filtrer le P2P c'est vouloir porter atteinte à la neutralité des réseaux. Mais l'enculage de mouches sémantiques (une nouvelle espèce), si comme tu le prétends (et j'en suis le premier convaincu) les contournements sont monnaie courante pour les usages illégitimes, gageons que les usages légitimes ne devraient pas avoir trop de mal à se recycler.

En tous cas, c'est ce qu'on pourrait t'objecter. Et accessoirement, je doute que les gens de Skype (notamment) acceptent de perdre le marché français sans protester.

Par contre, si les FAI bloquent le P2P, ils bloquent ses usages légaux, et tuent l'indépendance d'Internet.

Dieu merci, Internet marchait très bien avant les "P2P" actuels (qu'il ait fonctionné sur un modèle décentralisé au même moment reste vrai, mais c'est un autre débat et ce n'est pas le modèle décentralisé qui est combattu par ce projet, merci de ne pas tout mélanger).

Je comprends un peu ce que veut dire le gusse qui se fait moinsser à tout bout de champ : la défense du P2P n'est pas aussi lié à la défense du logiciel libre qu'on voudrait bien nous le faire croire. Et, même si je trouve bittorrent bien pratique à l'heure actuelle, je conçois qu'on puisse militer pour le LL sans pour autant verser une larme à la mort de celui-là.

J'ai fait du Caml, à l'école. À l'époque, je voulais aimer ça : théoriquement, il avait toutes les caractéristiques pour me plaire. Il permettait le meilleur des trois mondes (interprétés, compilé et "entre les deux" à la Java), il était libre, performant, bien maintenu, "différent". N'empêche que - et ce fut mon dramounet - j'ai toujours été plus lent en Caml qu'en C++ (ce que je pratiquais, alors).

Avec le temps, et à contre-coeur, j'ai fini par abandonner Caml, en gros dès que j'ai eu trouvé des remplaçants au C++ (ObjectiveC, puis Python, dans mon cas).

Alors effectivement, j'avais connu des langages impératifs avant, ça joue surement...

je n'aime pas le principe de l'interprété

Ca s'est vu :)

Pour le reste, j'ai trouvé chez Python un relativement juste équilibre. Effectivement, j'y ai perdu une certaine efficacité à l'exécution, par rapport au temps où je faisais du compilé. Mais j'y ai terriblement gagné en temps et en plaisir de développement. Et ça, je ne suis pas prêt à le perdre. Et vu ce qu'on voit de nos jours (les gens d'OpenMoko qui trouvent des parades pour éviter de multiplier l'impact de l'interpréteur par le nombre de programmes, les gens de PyPy qui refont Python en Python "pour la beauté du geste" et qui en tirent des enseignements capables d'améliorer les autres implémentations, et j'en passe et des meilleurs...), je ne dois pas être le seul (y'a déjà l'auteur de ce journal, logiquement).

Alors oui, c'est un langage interprété, il a des particularités qui ne plaisent pas toujours, il est relativement lent, c'est pas un vrai langage d'homme bien velu comme C, c'est pas chatoyant comme le costard Armani d'un consultant J2EE, ça fait pas fumer les méninges comme OCaml ou Haskell, ça passe moins bien à l'échelle qu'Erlang, ... Oui, chaque langage a ses avantages et ses inconvénients. Et chaque "toolkit" apporte aussi son lot de plus et de moins. Entre faire du PyGtk et du Qt en C++, j'hésite pas un instant et je choisis le C++. Mais quand j'ai pas envie de me traîner environnement de développement monstrueux derrière moi et de coder "à l'envi", je choisis Python. Et quand j'ai trop bu, je fais du Java.

Que vient faire la partie binaire dans la discussion? Ca n'a absolument rien à voir avec le source, qui n'a absolument pas à changer entre GCC 3.3 et GCC 3.4 (changement d'ABI d'un et un seul compilo)?

Certes, par contre il y a eu aussi des modifs côté source entre la version 3 et la version 4 (notamment dans la "tolérance" à certaines pratiques de développement qui s'est durcie).

Tu peux chercher toutes les raisons que tu veux, il n'empêche que le développement en C++ ne t'apporte pas plus de garantie qu'en Python, et que tout ce que tu trouves à y redire c'est ce que tu reproches au mec d'en haut que je sais plus qui c'est : dans la théorie, c'est pérenne, dans la pratique ça l'est pas.

Si tu veux tout savoir, je n'aime pas (plus, en fait) C++, mais pas pour ces questions de pérennité à la manque. De même que si j'aime Python, çà n'a rien à voir avec ça non plus, et ça m'agacera probablement aussi le jour où mon code ne sera plus compatible avec la version "mainstream". Pour moi, tout ce débat sur la pérennité du code est un faux problème, du moins tant qu'on ne fait pas entrer dans l'équation un langage pour lequel la dite pérennité a été un critère fondateur. Et ça n'est le cas ni de Python, ni du C++ (le C s'en sort un peu mieux, mais ça n'a pas non plus été une volonté exprimée au départ, il me semble).

Tu amènes des choses, des défauts sur un côté où Python a éliminé le problème : pas de compilation (donc un package de plusieurs Mo pour un simple "Hello world").
Ca repart toujours dans le truc "vive le monopole de Python, avec Python pas d'incompatibilité du au monopole")

Unmatched parenthesis ;)

Maintenant, oui, c'est vrai. Et après? Si le problème est éliminé, c'est l'essentiel? Et si la résolution a apporté d'autres soucis, on peut discuter de ceux-ci. Mais, au passage, le "simple hello world" qui fait plusieurs Mo, c'est de la mauvaise foi à l'état pur : le hello world "opérationnel" en Python ne fait que quelques octets (strlen('print "hello world"') + 1, à vue de nez). Si tu veux compter tout l'interpréteur dedans, et c'est ton droit, il ne faut pas oublier que ça te fournit l'environnement de développement pour le "même prix", et que pour être juste tu pourrais compter g++ dans le score du C++. On peut jouer à ce petit jeu là longtemps, et personne ne gagnera.

Avec ton argumentation, Linux c'est pourri il y a des problèmes tout le temps

Hein? Je défends un langage pour lequel les spécifications ne sont pas gravées dans le marbre, et tu arrives à en déduire que je critique le changement?!

Pour information, je n'ai pas prétendu que Python était immuable ni rien, j'ai juste fait remarquer que le langage que tu défendais ne brillait pas vraiment pas la stabilité de ses interfaces. Pour ce qui est de la compatibilité binaire sous win, c'est à peu près comme sous Linux : ça dépend. Des softs vieux de 13 ans qui tournent encore (modulo une recompilation, certes), ça peut se trouver. Des softs qui tournent tels quels, j'en ai qui datent de 1999/2000 environ. Et encore, je ne parle que des softs "compilés", j'ai des scripts shell plus anciens que ça qui marchent du feu de dieu. Et pareil, des programmes de 95 qui sont infoutus de tourner sur un Windows récent, j'en ai. Pas besoin d'aller chercher des merdes en mode DOS, il y a quantité de softs qui se basaient sur l'absence de protection mémoire de win9x et qui se vautrent comme des merdes depuis win2k.

C'est le truc rigolo : je retrouve exactement sur le principe les arguments des Windowsiens ici-même appliqués à Python. et ça ne vous choque pas?

Et je suis certain qu'on pourrait faire l'inverse et appliquer les arguments des Linuxiens (diversité, choix, libre accès au source, développement à la portée de tout un chacun). C'est vraiment une question de point de vue, et ça me déçoit un peu de voir ta prose, d'ordinaire assez douée pour éviter les œillères et autres intégrismes à deux balles, donner dans la dialectique de nightclub.

Te donnes pas cette peine : des compilos qui la respectent dans son intégralité, on en cherche encore. Mais au moins il a une norme. Et ça, ça change tout ;)

Ben oui, mais moi ca m'embête de ne pas savoir si mes programmes vont passer en 3.0 ou 4.0 etc...

Dans ce cas, tu souhaiteras probablement éviter le C++. Ou en tous cas le C++ libre. À moins que les changements d'ABI de gcc aient déjà disparu de l'inconscient collectif, parce que c'était franchement plus lourd à gérer que ce que fait Python pour le passage de 2 à 3.

Alors ok, ça s'est un peu calmé et ça n'était lié qu'à un seul compilateur. Sauf qu'en C++, l'interopérabilité entre les implémentations, c'est loin d'être ça. Et que, comme en Python, rien ne garantir l'avenir. Life sucks.

Il y a des tas de raisons de ne pas aimer Python et (un peu moins) des tas d'aimer C++. Mais de grâce, mets-les en concurrence sur des points où C++ est vraiment gagnant, si tu veux mettre en lumière ses qualités.

Je ne vois pas en quoi le fait qu'il ne soit pas libre enlèverait quoique ce soit à son efficacité.

Rien, mais par contre quand on choisit un langage, le fait de savoir qu'il y a une implémentation un tant soit peu indépendante, c'est un gros plus.

Et en REBOL avec un interpréteur libre?

Il y a VB le language et VB l'IDE. Les deux ont le même nom.

C'est totalement tiré par les cheveux. Faire du VB sans l'interface VB était, du temps de sa popularité, hors de propos. Je veux bien qu'avec l'avènement de .Net il soit possible de faire du VB dans notepad et de lancer un interpréteur là-dessus en ligne de commande.

Mais le VB qui a marqué le monde informatique, c'est un VB dans lequel langage et GUI étaient indissociables (propriété qu'on retrouve aussi dans ce cher Windev, par exemple). C'est même probablement pour cela que ça a marché.

Oui enfin faut pas charier non plus. Si on va par là, tous les langages sont potentiellement "Visual". La particularité de VB était d'embarquer un interface de construction d'interface (de construction d'interface de ... bon on a compris) par défaut. Python n'embarque pas ce genre de choses. Si tu veux vraiment un "VB libre", il y a Gambas.

Je ne vois pas ce qu'il a de "Visual".

Je confirme, ça tourne au poil sur un EeePc 701 (bon ok, j'ai pas testé sous Xandros, mais sur une Debian ça marche nickel). Franchement, je m'attendais pas à ça : une bonne surprise de plus ;)

D'ailleurs, c'est quoi ce "PopCap" libre? Je ne trouve que le "PopCap Games Framework" qui n'a pas l'air trop ouvert, personnellement.

Je lis un peu partout que irrKlang est libre, et ça me chipote un peu. Je viens de revérifier, le site précise bien "irrKlang is free for non commercial use." [1]

(irrlicht, lui, semble libre)

[1] http://www.ambiera.com/irrklang/features.html

Ayant eu aujourd'hui à maintenir un bout de code ruby pourtant pas crade, je peut te dire qu'il existe des langages bien pires que Java.

Certes (brainfuck et goto++, c'est pas pour les chiens), mais Java est probablement le plus mauvais rapport "agrément/chance de tomber dessus".

J'avais oublié à quel point le duck typing ca faisait faire coin coin a ton programme quand il s'exécute et qu'il passe a l'endroit ou tu as oublié de changer le nom d'une fonction renommée,

Je connais très mal Ruby (voire pas du tout), mais quel rapport entre le duck-typing (ou fait de juger du type d'un "truc" en fonction de ses capacités/caractéristiques utiles plutôt que selon une déclaration préalable) et ton problème de symbole introuvable (qui si je ne m'abuse aurait été réglé tout seul par un "refactor" automatisé)?

ou encore le bonheur de pas avoir une exception de levée lors d'un dépassement d'index dans un tableau

Encore une fois, Ruby n'est pas tellement mon domaine, et je n'irais pas le défendre bec et ongles. M'enfin ça me paraît fou qu'il ne gère pas un truc pareil.

Mais bon, si on va par là, les langages qui imposent aux exceptions d'être des classes, alors que la plupart du temps une simple chaîne suffirait amplement...

On a testé vserver et xen, l'utilisation de xen déjà intégré dans le kernel nous a convaincu.

Quelle(s) distrib(s)?

Vu que c'est vendredi, je me permettais de faire remarquer que Java, c'est l'antithèse du langage "attirant" : verbeux en diable, favorisant des cycles de développement poussifs, nécessitant un environnement de développement lourdingue, générant des applications mal intégrées à leur entourage, etc.

Et on peut pas s'électrocuter en léchant l'enveloppe?

* Sun libère Java sous licence GPL (c'est pas fini, c'est pas complet mais y a déjà du concret) ;

C'est assez récent, et les projets libres en Java ne sont pas un phénomène récent.

* Sun a bien moins une réputation d'anti-libre que MS ;

et

* Java a toujours été multi-plateforme, et c'est Sun qui a fait le travail. Pour C#/.Net/Silverlight/... MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).

Correct. Rien à redire. Si ce n'est que ce n'est pas tant sur l'aspect "libre" de Java que mon "appeal-detector" tiquait. J'étais plus sur le langage lui-même : sa syntaxe, les pratiques qui lui sont associées, etc.

Cela dit, programmer dans le libre, c'est essentiellement une question d'envie, d'appétence, et pas seulement une question technique.

D'un autre côté, vu le nombre de projets libres en Java, l'appétence n'est pas tant un problème que ça.