J'avoue que je suis personnellement en 2.6.15 et que qemu+kqemu marche vraiment très bien. WindowsXP est d'une réactivité surprenante dans la machine virtuelle Linux ;-)
Faut pas exagérer non plus. Ca fait pas mal d'année que les modules Perl utilise le YAML pour spécifier leur fonctionalité.
Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !
Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.
Mais tu as déjà tout cela dans Perl dés aujourd'hui et dans toute distribution linux (et en plus généralement installé par défaut).
Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...
Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.
Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...
On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.
Sur une debian, il n'y a pas besoin de modifier pam pour prendre en compte l'identification ldap ! Il suffit en effet de modifier comme tu l'as fait le fichier /etc/nsswitch.conf et de configurer le fichier /etc/libnss-ldap.conf
Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...
Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.
D'un autre coté, on peux aussi chiffrer avec des algorithmes assez léger en ressources comme bowfish. Par exemple
ssh -c blowfish
Sur un réseau local dont on est quasi-sur, chiffrer de la sorte évite de tout faire passer en clair ce qui peut tout de même être dangereux et offre une garantie en générale suffisante.
J'ai utilisé LTSP (version 3) pendant quelques temps. Ca marche plutôt bien mais, il ne fallait pas utiliser gnome ou kde. Trop lourd. Cela surcharge le serveur central inutilement.
J'avais fait une configuration aux petits oignons pour mes utilisateurs avec icewm et rox-filer. C'est moins beau mais tu peux alors facilement doubler ou tripler le nombre d'utilisateur sur le serveur central !
Un autre solution à LTSP consiste avec mettre un serveur XVNC sur le serveur central et à installer un client vnc sur les postes des utilisateurs. Cela permet d'éviter de rebooter. Cela n'a pas le même objectif non plus mais permet d'augmenter encore le taux d'utilisation du serveur central (en plus au niveau de la configuration du serveur X du serveur central, c'est quasiment la même chose).
Enfin, plutôt que d'utliser ssh -CX pour chiffrer les transactions, on pourrait aussi mettre freenx. Ca gère une bonne partie de la problèmatique (et ca s'appuie sur ssh). D'ailleurs, ce serait bien que freenx fusionne dans les projets xorg et ssh.
Non, ce n'est pas un projet de gestion de projet mais de gestion des collaborations. Au sein d'un projet, il est clair que l'on peux s'arranger.
Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.
C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.
Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".
Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.
IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.
> ça oblige à continuer avec les mauvais choix de design qui ont été
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)
Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).
C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.
C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.
Meyer se fait parfois le chantre de la programmation objet, notament dans son bouquin. Il a cherché a faire un langage unifié et cohérent. Il passe beaucoup de temps a fusionné le concept de "thread" et celui d'objet dans scoop (toujours pas implémenté à ma connaissance) et il laisse un brèche ouverte avec le concept de covariance qui, tu es d'accord, peut rendre les programmes invalides !
Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !
Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.
Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).
Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.
Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)
Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.
Je suis assez d'accord avec toi avec les + et les manques. Je continue de penser que la contravariance est mieux qua la covariance, surtout qu'elle n'engendre aucun problème de typage. les personnes qui ont développé Sather l'ont bien montré.
Il manque aussi les itérators de Sather qui simplifie grandement l'arbre des classes.
Enfin, en plus de pouvoir rajouter des méthodes a des classes, il faudrait aussi pouvoir supertypé l'arbre des classes, c'est à dire introduire une nouvelle classe en plein milieu de l'arbre.
Un des problèmes d'Eiffel est que l'arbre des classes est trop rigide et trop imbriqué, du coup, c'est très difficile de le faire évoluer. Or, par définition, un langage se doit d'évoluer, il y a toujours quelques erreurs de conception.
> Ca ne t'empêche pas de le faire tourner sur une Debian si tu veux
Ca, je suis au courant. Ils ne valident que RHEL et Suse. Or la debian est super utilisé (évidement, on va tous dire que sa distribution est super utilisé mais il faut être aussi réaliste, la debian avec son développement communuatiare, indépendante... est incontournable, sauf pour les logiciels propriétaire !).
Il pourrait donc au moins faire l'effort pour la debian, surtout que la certification debian ne coute pas un centime contrairement a RHEL (enfin or cout de développemnt). Il suffit de mettre sur le site un paquet valable pour debian. C'est pas comme sous Windows ou il faut payer pour avoir le logo Microsoft Certified.
T'entend quoi par là ? La grande majorité des écoles d'ingénieur en mécanique sont des écoles publiques. Les frais d'inscription sont heureusement encore faible (je dis encore car avec leur réforme des universités qu'ils ont mis de coté mais qu'ils gardent au cas où, ca risque de faire mal).
Sinon, pour Catia, c'est un problème de CV. Tu places 10 fois mieux tes étudiants en stage s'ils ont fait du Catia, car Catia est largement numéro 1.
Pour les coùts, Dassault ou IBM sont capables de te donner en taxe d'apprentissage ce qu'ils te demandent en licence... ce que ne sont pas toujours capable de faire les concucrrents payant. Bilan : il faudrait être fou pour choisir autre chose !
Pour l'avoir enfin essayer avec XP sous Linux+qemu+kernelkqemu..., je peux dire que XP est BEAUCOUP plus reactif avec cette nouvelle version. Je ne vois quasiment pas la différence avec un Windows natif.
Tout cela est bien subjectif mais heureusement, il n'y pas pas que les chiffres pour nous guider.
Je connais quelqu'un qui a vu tourner Catia sous Linux ! De toute manière, tout ca sont des mensonges, ces logiciels ayant été conçu sous UNIX, le portage sous Linux devrait être relativement simple, surtout qu'OpenGL tourne maintenant relativement bien.
Catia (Dassault) est marié à IBM depuis le début. IBM doit protéger ses stations. Si Catia, comme SolidWorks tourne sous Linux, c'est la fin des stations scientifiques sous Windows ainsi que sous les autres UNIX. En plus Dassault a une politique plus proche de Microsoft, exploitant au maximum son monopole, que de l'open source. Même dans les projets RNTL (Réseau National des Technologies Logiciels), il ne joue le jeu de l'open source que du bout des doigts, contraint et forcés.
Il faut aussi savoir que pas mal des ces logiciels tournent sous Windows avec Exceed, qui est un serveur X non libre ! Alors, ne leur laissez pas dire que c'est optimisé pour la plateforme Windows ! Bref, ils n'ont aucune volonté d'ouverture.
Le seul qui fait des effort est ProE qui d'ailleurs marche très bien.
Ces histoires de logiciels scientifiques ne tournant pas sous Linux n'ont aucune raison d'être aujourd'hui autre que politique.
Pour ceux que ca intéresse, Matlab, Comsol (FemLab), Fluent, Ansys tourne très bien sous Linux. Les deux premiers ont même des versions complètement native sous AMD64 (pour fluent, il y a des bouts en 64b et d'autre en 32b, pour Ansys, je n'en sais rien).
Et lorsque tu as un GROS logiciel de type Catia, il serait idiot de la part de Dassault de le livrer sans toutes les librairies (Non, ne rêvez pas, Catia n'existe pas en version Linux sauf chez Dassault).
Un des problèmes est que Fabrice n'est pas très clair. A une époque, il parlait d'une certaine somme d'argent pour libérer le code. Combien ?
Si on ne sais pas la somme qu'il souhaite, ni le valeur du compteur à un instant t, qui irait donner de l'argent. Le module se développant, la somme souhaité augmente...
Bref, on n'a aucun moyen de savoir où on en est, et ce point là est effectivement génant.
Surtout que j'ai lu hier que le module libre qvm86 pouvait aller aussi vite que l'ancien module kqemu dans certain cas, il est donc un peu bête que ce module ne soit pas intégré en standard dans qemu. On arrive à la limite de la logique du semi-libre où un module non libre est privilégié devant un module libre, du seul fait du principal (et génial) développeur.
# Changement de nom
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Sylpheed-Claws 2.2.0. Évalué à 6.
Pourquoi pas Sylclaws !
[^] # Re: Module d'accélération kqemu pour qemu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Module d'accélération kqemu pour qemu. Évalué à 4.
[^] # Re: XML c'est bien
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 4.
Pour les grosses structures, les scientifiques ont aussi des solutions qui marchent depuis des années, binaire et multiplateforme : HDF par exemple.
Je ne dis pas que HDF résoud tous les problèmes, simplement qu'il faut arréter de nous mettre du XML partout.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !
Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.
[^] # Re: /proc
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 4.
Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...
[^] # Re: Uniformisation des formats ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.
Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...
On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.
# identification ldap
Posté par Sytoka Modon (site web personnel) . En réponse au message soucis d'authentification sur apache et ldap. Évalué à 2.
Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...
Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.
Bon courage
[^] # Re: Soft ou distrib complète?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux Terminal Server Project 4.2. Évalué à 3.
ssh -c blowfish
Sur un réseau local dont on est quasi-sur, chiffrer de la sorte évite de tout faire passer en clair ce qui peut tout de même être dangereux et offre une garantie en générale suffisante.
[^] # Re: Mythes...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux Terminal Server Project 4.2. Évalué à 6.
J'avais fait une configuration aux petits oignons pour mes utilisateurs avec icewm et rox-filer. C'est moins beau mais tu peux alors facilement doubler ou tripler le nombre d'utilisateur sur le serveur central !
Un autre solution à LTSP consiste avec mettre un serveur XVNC sur le serveur central et à installer un client vnc sur les postes des utilisateurs. Cela permet d'éviter de rebooter. Cela n'a pas le même objectif non plus mais permet d'augmenter encore le taux d'utilisation du serveur central (en plus au niveau de la configuration du serveur X du serveur central, c'est quasiment la même chose).
Enfin, plutôt que d'utliser ssh -CX pour chiffrer les transactions, on pourrait aussi mettre freenx. Ca gère une bonne partie de la problèmatique (et ca s'appuie sur ssh). D'ailleurs, ce serait bien que freenx fusionne dans les projets xorg et ssh.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 7.
Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.
C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
En voici un sorti de la documentation de Sather. Il est vrai qu'il vaut mieux comprendre un peu le système de type de Sather pour tout piger.
http://www.icsi.berkeley.edu/~sather/Documentation/EclecticT(...)
Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".
Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.
IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 6.
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)
Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).
C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.
C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 3.
Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !
Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.
Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).
Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.
Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)
Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
Il manque aussi les itérators de Sather qui simplifie grandement l'arbre des classes.
Enfin, en plus de pouvoir rajouter des méthodes a des classes, il faudrait aussi pouvoir supertypé l'arbre des classes, c'est à dire introduire une nouvelle classe en plein milieu de l'arbre.
Un des problèmes d'Eiffel est que l'arbre des classes est trop rigide et trop imbriqué, du coup, c'est très difficile de le faire évoluer. Or, par définition, un langage se doit d'évoluer, il y a toujours quelques erreurs de conception.
[^] # Re: Catia de Dassault Systemes
Posté par Sytoka Modon (site web personnel) . En réponse au journal logiciels de CAO sur Linux. Évalué à 2.
Ca, je suis au courant. Ils ne valident que RHEL et Suse. Or la debian est super utilisé (évidement, on va tous dire que sa distribution est super utilisé mais il faut être aussi réaliste, la debian avec son développement communuatiare, indépendante... est incontournable, sauf pour les logiciels propriétaire !).
Il pourrait donc au moins faire l'effort pour la debian, surtout que la certification debian ne coute pas un centime contrairement a RHEL (enfin or cout de développemnt). Il suffit de mettre sur le site un paquet valable pour debian. C'est pas comme sous Windows ou il faut payer pour avoir le logo Microsoft Certified.
Bref, il ne se défonce quand meme pas trop....
[^] # Re: Catia de Dassault Systemes
Posté par Sytoka Modon (site web personnel) . En réponse au journal logiciels de CAO sur Linux. Évalué à 2.
> version de Linux
Pourquoi ? Il suffit de compiler en statique et d'avoir une archive autonome... que les personnes installent où elles veulents, en général sous /opt
[^] # Re: Catia de Dassault Systemes
Posté par Sytoka Modon (site web personnel) . En réponse au journal logiciels de CAO sur Linux. Évalué à 2.
T'entend quoi par là ? La grande majorité des écoles d'ingénieur en mécanique sont des écoles publiques. Les frais d'inscription sont heureusement encore faible (je dis encore car avec leur réforme des universités qu'ils ont mis de coté mais qu'ils gardent au cas où, ca risque de faire mal).
Sinon, pour Catia, c'est un problème de CV. Tu places 10 fois mieux tes étudiants en stage s'ils ont fait du Catia, car Catia est largement numéro 1.
Pour les coùts, Dassault ou IBM sont capables de te donner en taxe d'apprentissage ce qu'ils te demandent en licence... ce que ne sont pas toujours capable de faire les concucrrents payant. Bilan : il faudrait être fou pour choisir autre chose !
[^] # Re: CVS : Ce n'est pas précisé
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Virtualisation complète avec kqemu. Évalué à 2.
Tout cela est bien subjectif mais heureusement, il n'y pas pas que les chiffres pour nous guider.
[^] # Re: Je trouve que l'UE se trompe.
Posté par Sytoka Modon (site web personnel) . En réponse au journal L'UE se méfie de Vista. Évalué à 2.
[^] # Re: Catia de Dassault Systemes
Posté par Sytoka Modon (site web personnel) . En réponse au journal logiciels de CAO sur Linux. Évalué à 9.
Je connais quelqu'un qui a vu tourner Catia sous Linux ! De toute manière, tout ca sont des mensonges, ces logiciels ayant été conçu sous UNIX, le portage sous Linux devrait être relativement simple, surtout qu'OpenGL tourne maintenant relativement bien.
Catia (Dassault) est marié à IBM depuis le début. IBM doit protéger ses stations. Si Catia, comme SolidWorks tourne sous Linux, c'est la fin des stations scientifiques sous Windows ainsi que sous les autres UNIX. En plus Dassault a une politique plus proche de Microsoft, exploitant au maximum son monopole, que de l'open source. Même dans les projets RNTL (Réseau National des Technologies Logiciels), il ne joue le jeu de l'open source que du bout des doigts, contraint et forcés.
Il faut aussi savoir que pas mal des ces logiciels tournent sous Windows avec Exceed, qui est un serveur X non libre ! Alors, ne leur laissez pas dire que c'est optimisé pour la plateforme Windows ! Bref, ils n'ont aucune volonté d'ouverture.
Le seul qui fait des effort est ProE qui d'ailleurs marche très bien.
Ces histoires de logiciels scientifiques ne tournant pas sous Linux n'ont aucune raison d'être aujourd'hui autre que politique.
Pour ceux que ca intéresse, Matlab, Comsol (FemLab), Fluent, Ansys tourne très bien sous Linux. Les deux premiers ont même des versions complètement native sous AMD64 (pour fluent, il y a des bouts en 64b et d'autre en 32b, pour Ansys, je n'en sais rien).
[^] # Re: quand même je me pose une quuestion ....
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 2.
[^] # Re: Je trouve que l'UE se trompe.
Posté par Sytoka Modon (site web personnel) . En réponse au journal L'UE se méfie de Vista. Évalué à 2.
Sachant qu'une machine qui n'est pas à jour est une machine morte, surtout sous Windows, IE est indispensable.
[^] # Re: Je trouve que l'UE se trompe.
Posté par Sytoka Modon (site web personnel) . En réponse au journal L'UE se méfie de Vista. Évalué à 3.
[^] # Re: Intérêt ???
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de PlanFacile pré 2.0. Évalué à 2.
http://www.insilmaril.de/vym/
[^] # Re: Pourquoi propriétaire?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Virtualisation complète avec kqemu. Évalué à 5.
Si on ne sais pas la somme qu'il souhaite, ni le valeur du compteur à un instant t, qui irait donner de l'argent. Le module se développant, la somme souhaité augmente...
Bref, on n'a aucun moyen de savoir où on en est, et ce point là est effectivement génant.
Surtout que j'ai lu hier que le module libre qvm86 pouvait aller aussi vite que l'ancien module kqemu dans certain cas, il est donc un peu bête que ce module ne soit pas intégré en standard dans qemu. On arrive à la limite de la logique du semi-libre où un module non libre est privilégié devant un module libre, du seul fait du principal (et génial) développeur.