daniel a écrit 113 commentaires

Mais ce n'est pas libre, puisque je ne peux pas redistribuer une version modifiée librement.

Sous GPL non plus tu peux pas, tu dois rendre accessible les sources et ça doit être du GPL.
Arretez moi si je dis des c**

quelqu'un connaît l'adresse d'un serveur dict en français ? j'ai découvert ça et c'est très pratique

et tu peux pas gérer la mémoire toi-même en java ???

Une question sur un détail qui m'emm... sur mozilla sous win (aie ouille tapez pas trop fort).
je suit les snapshots de mozilla depuis plusieurs mois, en utilisant l'archive complète.
Ben je suis obligé depuis quelques temps de garder le snapshot du 09/01, parce que dès que je télécharge une version plus récente et que je la lance je me prend un "connection refused" dans la gueule. quelqu'un a eu le même problème ?
Sous debian sid j'ai moz 0.9.7 et ça marche nickel

Effectivement, avec ces outils on peut faire des interfaces graphiques rapidement, dont le code ne ressemble pas a une usine a gaz ignoble. En plus ces langages (surtout Python) s'interfacent nickel avec le C, donc tu peux sans probleme les utiliser dans le cadre d'un projet qui utilise du C par ailleurs.

Tout à fait !
Pour moi le top c'est :
- utiliser python pour l'interface graphique et les entrées-sorties
- pour le coeur, utiliser un langage plus rapide et bas niveau comme le C/C++, ce qui permet d'avoir accès à toutes les librairies C existantes commes les extensions numériques par exemple

ça permet d'appliquer au maximum le principe de réutilisation de code, de faire des programmes qui soient portables (si on utilise des toolkits multi-plateformes) et maintenables, parce que le C devient très cryptique quand il s'agit de faire des interfaces graphiques.

Enfin je veux juste ajouter un lien vers un projet sur python et les interfaces graphiques, qui me semble ultra-intéressant, et qui mériterait de l'aide : http://anygui.sourceforge.net/(...)

DDD est le meilleur debuggeur que j'ai utilisé
ddd, comme la plupart des débuggeurs cités plus haut, est une interface graphique de gdb, mais bon la je cherche la petite bête. ddd est impressionnant, parce qu'il permet de débugger dans plusieurs langages Ada, C, C++, Chill, Fortran, Java, Modula, Pascal, Perl et Python (rien que ça), et qu'il permet grâce à gdb version 5 et +, de débugger le multi-thread.
comme débuggeur, insight aussi est très bien

d'autre part comme ide il y a aussi anjuta qui est couplé à glade pour faire des applis gtk.

Je tiens à ajouter que maintenant existent des langages de haut niveau comme perl et python qui permettent d'écrire des programmes avec gui de manière simple, ce qui rend l'utilisation de RAD moins importante.

ou mis en section humour ;)

A mon avis de ce côté là ils sont passé à côté de la plaque.
Ce qui rend GNU/Linux plus facile que windows pour le développement (pas le dev web, l'autre ), c'est :
- la quantité invraisemblable de librairies,
- la transparence du système. Je veux dire par là que le système (1) a une architecture ouverte et ( 2 ) est très bien documenté pourvu qu'on ne soit pas anglophobe.

Sous win, sorti de msdn, il n'y a pas grand chose, et les arcanes du système ne sont pas vraiment détaillées.

moi je me sers de scilab. Je vois un seul problème avec scicos : il faut des notions d'autom pour l'utiliser. J'ai des connaissances plutôt basiques dans le domaine. quelqu'un pour me pointer vers une doc pas trop mal ?

linux mag et d'autres comme login par exemple, préfèrent faire écrire des articles par des gens qui savent de quoi ils parlent, quitte à ce que ça ne soit pas la dernière technologie que tout le monde utilise. Je préfère ça car j'apprend des choses das ces articles.

Curieux. Très intrusif. x86-only.

faux. dans le dernier changelog :

Supported Arches: ARM, i386, and SH

Je pense que le developpement de logiciel libre favorise l'innovation, grâce au feedback plus important et plus direct que reçoit le concepteur de LL tout au long du developpement du logiciel, et pas seulement au moment des release.
Les innovations en LL (pour moi) se voient dans les projets :
apache (le serveur apache2, cocoon, tomcat, ant, gump...). gump http://jakarta.apache.org/gump/(...) est un projet qui permet de coordonner les developpements de différents projets, en effectuant une compilation automatique à partir des dernières sources disponibles de chaque projet et en rédigeant des rapports de succès/ehecs avec interface web.
docbook-xml
python, surtout le projet anygui http://anygui.sourceforge.net(...) . ce projet consiste à avoir un programme qui detecte les plateformes graphiques disponibles et affiche le gui : le même code python peut renvoyer une interface native windows, qt, java, text, curse, gtk, beos, interface web...

ou en est savannah-phpgroupware ?

Le but du système de vote de linuxfr n'est pas lié au fait que chacun doit s'exprimer (si c'était que ça, alors il vaut mieux ne pas avoir de votes, chacun fait les commentaires qu'ils veut trollons ensemble).
Le but était de modérer le ton désobligeant de certains, les insultes, les faux arguments, etc. Ceci pour avoir des pages de commentaires lisibles, qui ne mettent pas trois ans à charger et où le débat d'idées est mis en valeur par rapport à la trollerie de notre bas-monde.
donc oui si le système de votes n'atteint pas ses objectifs il faut le remettre en question, et tenter d'éduquer les linuxiens pour les éclairer dans leur vote

Quelqu'un sait pourquoi cette doc ne fait pas partie du projet officiel de documentation Debian ?
l'adresse de la version française pour ceux qui ne la connaissent pas :
http://www.debian.org/doc/ddp.fr.html(...)
et la version originale (plus à jour) :
http://www.debian.org/doc/ddp.en.html(...)

je veux bien t'aider pour cette traduction.

En fait, même si ça concerne surtout Debian , je conseille à tout le monde (y compris ceux qui ne urent que par Mandrake, Redhat, Suse ou n'importe_laquelle_mais_surtout_pas_Debian) d'aller y jeter un coup d'oeil ils y apprendront surement quelque chose.

Pour se coordonner on pourrait voir du côté de http://www.debianworld.org/(...) ,qui réunit déja un bon nombre de doc Debian traduites en français. Peut-être que ce document est déja en partie traduit ?

j'avais cru comprendre d'après la lecture des listes de diffusion que les responsables de Debian comptaient se débarasser de la catégorie non-free, mais en incluant les programmes non-libres dans la catégorie Main, pas en jetant tous les softs non-libres au feu.

je rajoute un petit commentaire pour attirer vote attention sur un projet visant à améliorer/révolutionner la portabilité des applications écrites en python :
le projet anygui :
http://anygui.sourceforge.net/index.php(...)
et un article dur IBM : http://www-106.ibm.com/developerworks/linux/library/l-anygui/(...)

je sais je suis hors-sujet, mais j'aime beaucoup cette idée.

les pb de stabilité sous windows c'est peut-être vrai pour gimp mais beaucoup d'outils fonctionnent très bien sous win :
vim, perl, python, php tournent très bien (au niveau de la portabilité, je trouve perl et python mieux que java)
apache
bash
emacs
KDE est en train de se lancer.

A mon avis, pour intéresser des windowsiens au monde du libre il vaut mieux leur installer quelques applis comme ça. plus tard, lorsqu'ils auront été habitués aux outils et si ils veulent tenter linux, met-les devans un PC avec linux déja installé histoire qu'ils se fassent une idée.

Oh surprise, connaissant déja quelques morceaux de GNU, ils se sentent moins perdus.

Vous vous êtes jamais demandé comment ca se serait passé si vous aviez déja connu vi la première fois que vous avez vu un unix tourner ?

j'imagine que la première fois que tu te retrouve devant une linux et que c'est une debian, ça doit pas faire de mal de savoir déja utiliser dpkg et apt-get

Je me basais sur la date du premier commit du CVS.
Bon ben ça voudrait dire que le projet a à peu près un an et est donc plus jeune que la potato et peut-être même plus jeune que progeny Debian.
Ben ça m'apprendra a ouvrir ma gueule...

il y a un autres avantage que apt-get, en tout cas pour moi.
c'est vrai qu'il y a (très ?) peu d'aide automatisée, mais la documentation est très bien faite (c'est vrai que la plus grande part de la doc est en anglais mais bon...):

- des exemples de fichiers de config commentés et preque utilisables tel quel font que si l'on met un peu d'effort, on réussit à configurer sa machine, et on apprend des choses sur le système linux en général. quelqu'un qui n'utilise que suse depuis le début sans jamais avoir trop cherché à aller plus loin que ce que lui offre yast n'est pas forcément devenu compétent pour les autres distrib linux. avec Debian, si.

- pour chaque paquet Debian on a le changelog du développeur du logiciel, et celui du mainteneur du paquet. on connait donc les modifs apportées pour que ça marche sous debian, ainsi que les patchs de sécu appliqués.

- de même pour les kernel 2.4 distribués dans la sid et la woody le paquet contient le changelog de la version coorrespondante, la liste des modifications et patches appliqués par le mainteneur debian, et le fichier de config correspondant à la compil du noyau.

deity est "presque" utilisable.
En fait une des premières motivations des développeurs du nouveau système d'install était de ne plus utiliser dselect au moment de l'installation.

je peux savor pourquoi je me prend des votes négatifs ?
je suis en rapport avec le sujet, j'apporte des infos que j'ai vérifiées et je ne provoque rien ni personne. Ceux qui ont voté pourraient m'expliquer parce que là je vois pas.

En tout cas le projet existe depuis longtemps, au moins 1 an. Même s'il n'a pas suffisamment été avancé pour être mis en place, il a été initié AVANT la potato...

si tu regarde le cvs :
http://cvs.debian.org/debian-installer/(...)

Le projet était un peu (...) en sommeil, mais il y a déja du code et ce n'est pas qu'une présentation un peu commerciale du design du parfait installeur

Parce qu'elle est en python ?

plusieurs autres parties du système Debian sont en python si je ne me trompes pas trop.

le debian-installer existait déja avant la naissance de la société progeny. Je suppose que ç'est en partie pour ne pas avoir à mettre à la poubelle du code qu'ils ont mis du temps à taper, entre autres raisons.