Merci je connais aussi, y en aussi sur les langages qui se compile.
Je n'ai pas dis le contraire, c'est toi qui expliquait que tu veux de l'analyse statique et que pour ça il te faut un compilateur.
Reste que ca prends un temps fou compare a une simple compil. Bref pas le truc que tu lances souvent.
C'est pas plus long que de faire des tests unitaires et de les lancer. C'est pas non plus plus long que de devoir corriger après que l'utilisateur ai découvert le bug. Ça permet de corriger des bugs en vrai (là où gcc te dit uniquement le minimum pour que ça compile (clang et icc sont meilleurs)). Si tu as besoin de moins de vérifications (puisque c'est ce que tu fais actuellement), il suffit de configurer ton outil pour tu verra que le temps d'analyse diminue. L'avantage c'est que tu peut avoir une analyse légère au cour de la journée et le soir tu lance l'analyse complète si ça prend tant de temps que ça.
Bien sûr si tu veux dire que comme ce n'est pas techniquement obligatoire, tu (toi ou d'autres) manque de rigueur pour le lancer c'est autre chose, mais ça peut se lancer via un builder avant la compil'.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Le JavaScript d'un autre cote, ca plante pas mais quand ca fait n'importe quoi bonjour pour debugger…Je hais les langages qui ne 'compilent pas' pour ca…le simple fait de compiler an -Wall -Wextra detecte beaucoup de typos, En JavaScript tintin…
Puis un jour tu va découvrir les analyseurs statiques (comme lint) et tu va comprendre qu'un compilateur ça sert à compiler.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Oui mais moi j'ai pas envie de ré-ouvrir toutes mes appli. J'utilise pas okular, mais dans le cas de firefox. Je veux qu'il puisse être arrêté et relancé sans tout perdre et sans avoir à le mettre dans une activité spécifique (mon navigateur n'est pas une activité à part entière). De plus je ne suis pas pas sûr que ce soit au gestionnaire de fenêtre de savoir rouvrir mes documents à la bonne page. Ça ne se factorise avec rien et il faudra le faire avec les documents PDF, HTML, opendocument, mais aussi mes musiques et mes vidéos.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Rien n'oblige l'init par défaut à être le même pour toutes les archis.
Ouai mais il faut se palucher dans les paquets le script sysvinit et le fichier ini systemd. Le programme de conversion ini systemd vers les scripts d'init n'est pas encore terminé, je crois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Les onglets dans le logiciel c'est quand même autre chose que ce que peux faire un gestionnaire de fenêtre. Notamment pour la restauration de la liste des onglets au redémarrage ou d'autres choses de cet acabit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
TiddlyWiki est un wiki qui tiens dans un unique fichier HTMl avec du JS dedans donc je pense qu'il y a des primitives pour écrire dans des fichiers (par contre les navigateurs hurlent à la mort quand ça arrive).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
il y a plus de simplicité grâce à un couplage plus fort
Moins fort, plutôt, non?
Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.
Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).
Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
Pour du calcul pur, la différence est de très loin négligeable. Ça influence la vitesse de démarrage de ton appli, la vitesse des appels systèmes et tu es plus lents sur les protections que te donne ton langage (le typage, la protection de la mémoire etc).
A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
Ça tombe bien avec JS qui a une lib standard assez petite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Au moins en C/C++ si ça merde ça plante ou ça leak mais dans les 2 cas c'est rapidement visible et corrigé.
La mauvaise gestion des chaines ça se vois rapidement ?
Je ne cherche pas à lancer un troll entre langage, hein ? Je dis juste que l'idée de tout faire dans un langage donné parce que c'est soit disant plus performant n'est pas une bonne idée (et mon exemple n'était être pas super bien choisi).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est pas si évident mais un programmeur mauvais ou moyen il fera toujours un app plus lente en JS qu'en C++, or le but du JS par défaut dans GNOME c'est justement d'attirer le dev moyen …
On retrouve la bonne vielle idée des bons et des mauvais programmeurs (généralement c'est à partir de là que je trouve la discussion inutile). D'un coté il y a les bons programmeurs qui maitrisent principalement l'assembleur et utilisent le C quand il faut coder vite et de l'autre il y a les nullos qui ne comprennent pas grand chose (ils n'ont même pas commencé à coder sur des machines 8bits en assembleur c'est dire !). Les premiers maitrisent l'informatique comme leur poche et de l'autre tout ce qu'ils connaissent d'un peu technique n'est que buzzword ou des acronymes qui servent à cacher la lourdeur de leur technologie.
Personnellement ce n'est pas mon avis. Tu peut avoir des personnes qui savent architecturer une appli sans pour autant très bien maitriser l'allocation mémoire et toutes les subtilités de synchronisation interprocessus et vis versa.
Rien ne t'interdit à toi ou aux autres bons/vrais programmeurs de contribuer aux appli toutes pourries pour les rendre meilleures ou d'en écrire d'autres en reprenant les idées de ses autres appli (rien ne t'oblige à les installer).
Enfin personnellement, pour une petite appli qui va se loger dans le systray pour m'indiquer un truc ou un autre de temps en temps, je préfère que ce soit écris dans un langage plutôt concis et plus maintenable ou plus facilement hackable qu'en C avec des risques de fuites mémoire entre autre.
Si le but est de descendre le niveau d'accès des dev à la plateforme GNOME au détriment des perfs et donc au détriment des machines un peu plus ancienne, perso je ne me reconnais plus du tout dans cet écosystème.
Comme je viens de le dire (et tu semble le concéder) c'est pas le langage le plus primordial dans la performance d'une application. Par contre oui ça rend le développement plus simple et ça c'est bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
ces composants deviennent de moins en moins utiles vu que les fonctionnalités qu'ils proposaient sont intégrés à systemd
Je comprends pour la plupart des logiciels mais je suis surpris pour cron et atd. systemd intègre ça ? C'est l'un des trucs que je trouvais sympa dans l'idée d'upstart représenter l'heure et le boot comme 2 évènements du système et de simplement permettre de déclencher des actions lorsqu'ils arrivent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Nagios a beau être en C la plupart des plugins sont en scripts
Tu parle des sondes ? Ce n'est pas leur éventuelles lenteurs qui ralentissent nagios (pour être plus précis qui l'empêcherais de monter en charge).
C'est pas tant le langage qui fait la différence que le fait de passer par une VM/interpréteur ou pas.
Juste au dessus tu viens de dire que c'est l'architecture qui fait la différence (et ça je suis d'accord). Interpréter, JIT ou compiler vers une VM le code est un peu plus rapide (il gagne de quelques facteurs) et les performances qu'on arrive à produire actuellement tendent à fortement limiter cette différence. Par contre si tu code plus ou moins bien c'est carrément la complexité de ton programme qui va en pâtir et là tu peut l'écrire en assembleur ou le bruler directement sur CPU ce sera toujours lent.
Ce qui fait que ton bureau est léger c'est probablement qu'il est plus simple. C'est peut être parce qu'il est mieux conçu et/ou qu'il fait moins de choses et/ou qu'il y a plus de simplicité grâce à un couplage plus fort. Mettre ça sur le dos du ou des langages c'est pas si évident à mon avis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
les commit en local ? genre par ex. un type pressé qui bosse dans le train… après la question reste entière si le mec ne fait pas de différence entre un bon commit et un mauvais commit.
L'intérêt d'un commit local est très très très limité pour des documents binaires. Il apporte à mon avis surtout une confusion entre ce qui est poussé et ce qui est commité.
les sous-dépôts ? On pourrais par ex. avoir un dépôt commun par équipe, qui sont ensuite merger dans un dépôt principal (par un « Con qui fait le Tri » ?) Comme ça les équipes bossent comme il faut, et quand le machine est prêt, finalisé, hop on l'envoi pour le partager avec tout le monde.
Ça ne m'a pas l'air d'être l'organisation décrite dans le journal. Il n'y a pas des équipes mais une équipe qui travail sur un document. De plus il ne parle pas d'une plateforme de publication, mais d'un groupe de personnes dans différentes entreprises qui éditent un document de manière collaborative.
(j'ai un peu l'impression de voir des commerciaux tenter de faire coller les besoins de quelqu'un à leur produi)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Quel est l'intérêt ? Tu pense que les utilisateurs vont avoir plusieurs branches locales ou plusieurs dépôts distants (généralement au contraire dans ces cas on préfère une révérenciel global) ? Sachant que tout les merges seront pourris et pour les même raison tout ce qui est manipulation de l'historique ou le cherry picking aussi.
Il ne faut pas proposer des DCVS juste parce que ça fait bien aujourd'hui de parler de ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2. Dernière modification le 11 février 2013 à 18:08.
Je n'ai pas dis le contraire, c'est toi qui expliquait que tu veux de l'analyse statique et que pour ça il te faut un compilateur.
C'est pas plus long que de faire des tests unitaires et de les lancer. C'est pas non plus plus long que de devoir corriger après que l'utilisateur ai découvert le bug. Ça permet de corriger des bugs en vrai (là où gcc te dit uniquement le minimum pour que ça compile (clang et icc sont meilleurs)). Si tu as besoin de moins de vérifications (puisque c'est ce que tu fais actuellement), il suffit de configurer ton outil pour tu verra que le temps d'analyse diminue. L'avantage c'est que tu peut avoir une analyse légère au cour de la journée et le soir tu lance l'analyse complète si ça prend tant de temps que ça.
Bien sûr si tu veux dire que comme ce n'est pas techniquement obligatoire, tu (toi ou d'autres) manque de rigueur pour le lancer c'est autre chose, mais ça peut se lancer via un builder avant la compil'.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Je ne les ai pas essayé, mais tu a regardé ceux-là ? http://doc.ubuntu-fr.org/analyseur_de_code_static#cc
Sinon d'assez réputé, il y a PC-Lint et PVS-Studio mais il semble qu'ils ne fonctionnent que sous Windows…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Puis un jour tu va découvrir les analyseurs statiques (comme lint) et tu va comprendre qu'un compilateur ça sert à compiler.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Presque parfait
Posté par barmic . En réponse à la dépêche KDE SC 4.10. Évalué à 4.
Oui mais moi j'ai pas envie de ré-ouvrir toutes mes appli. J'utilise pas okular, mais dans le cas de firefox. Je veux qu'il puisse être arrêté et relancé sans tout perdre et sans avoir à le mettre dans une activité spécifique (mon navigateur n'est pas une activité à part entière). De plus je ne suis pas pas sûr que ce soit au gestionnaire de fenêtre de savoir rouvrir mes documents à la bonne page. Ça ne se factorise avec rien et il faudra le faire avec les documents PDF, HTML, opendocument, mais aussi mes musiques et mes vidéos.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je ne comprends pas ces sous-entendus
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 2.
Ouai mais il faut se palucher dans les paquets le script sysvinit et le fichier ini systemd. Le programme de conversion ini systemd vers les scripts d'init n'est pas encore terminé, je crois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Presque parfait
Posté par barmic . En réponse à la dépêche KDE SC 4.10. Évalué à 9.
Les onglets dans le logiciel c'est quand même autre chose que ce que peux faire un gestionnaire de fenêtre. Notamment pour la restauration de la liste des onglets au redémarrage ou d'autres choses de cet acabit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise interprétation
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 3.
Si tu as un accès ssh, tu peut même faire un montage sshfs et utiliser un outil graphique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise interprétation
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 4.
Je ne sais pas pour le reste, mais nano gère la coloration syntaxique.
http://wiki.lolica.org/doku.php/articles/nano
http://korben.info/rajouter-la-coloration-syntaxique-a-nano.html
http://doc.ubuntu-fr.org/nano#ajouter_la_coloration_syntaxique
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise interprétation
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 5.
Je ne doute pas que c'est configurable ou qu'il prend la variable EDITOR
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Javascript et les fichiers
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
TiddlyWiki est un wiki qui tiens dans un unique fichier HTMl avec du JS dedans donc je pense qu'il y a des primitives pour écrire dans des fichiers (par contre les navigateurs hurlent à la mort quand ça arrive).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).
Pour du calcul pur, la différence est de très loin négligeable. Ça influence la vitesse de démarrage de ton appli, la vitesse des appels systèmes et tu es plus lents sur les protections que te donne ton langage (le typage, la protection de la mémoire etc).
Ça tombe bien avec JS qui a une lib standard assez petite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Avoir un second bureau ça crée une concurrence plutôt saine je trouve.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise interprétation
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 10.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
La mauvaise gestion des chaines ça se vois rapidement ?
Je ne cherche pas à lancer un troll entre langage, hein ? Je dis juste que l'idée de tout faire dans un langage donné parce que c'est soit disant plus performant n'est pas une bonne idée (et mon exemple n'était être pas super bien choisi).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 7.
On retrouve la bonne vielle idée des bons et des mauvais programmeurs (généralement c'est à partir de là que je trouve la discussion inutile). D'un coté il y a les bons programmeurs qui maitrisent principalement l'assembleur et utilisent le C quand il faut coder vite et de l'autre il y a les nullos qui ne comprennent pas grand chose (ils n'ont même pas commencé à coder sur des machines 8bits en assembleur c'est dire !). Les premiers maitrisent l'informatique comme leur poche et de l'autre tout ce qu'ils connaissent d'un peu technique n'est que buzzword ou des acronymes qui servent à cacher la lourdeur de leur technologie.
Personnellement ce n'est pas mon avis. Tu peut avoir des personnes qui savent architecturer une appli sans pour autant très bien maitriser l'allocation mémoire et toutes les subtilités de synchronisation interprocessus et vis versa.
Rien ne t'interdit à toi ou aux autres bons/vrais programmeurs de contribuer aux appli toutes pourries pour les rendre meilleures ou d'en écrire d'autres en reprenant les idées de ses autres appli (rien ne t'oblige à les installer).
Enfin personnellement, pour une petite appli qui va se loger dans le systray pour m'indiquer un truc ou un autre de temps en temps, je préfère que ce soit écris dans un langage plutôt concis et plus maintenable ou plus facilement hackable qu'en C avec des risques de fuites mémoire entre autre.
Comme je viens de le dire (et tu semble le concéder) c'est pas le langage le plus primordial dans la performance d'une application. Par contre oui ça rend le développement plus simple et ça c'est bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise interprétation
Posté par barmic . En réponse au journal Systemd dans Debian. Évalué à 5.
Je comprends pour la plupart des logiciels mais je suis surpris pour cron et atd. systemd intègre ça ? C'est l'un des trucs que je trouvais sympa dans l'idée d'upstart représenter l'heure et le boot comme 2 évènements du système et de simplement permettre de déclencher des actions lorsqu'ils arrivent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par barmic . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 2.
Je n'ai pas dis que les commerciaux sont ainsi, j'ai dis que des commerciaux le sont.
Je n'ai pas dis que ça n'existe pas, je dis que ça ne corresponds pas au workflow déjà défini (et à priori non modifiable).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
En effet.
Tu parle des sondes ? Ce n'est pas leur éventuelles lenteurs qui ralentissent nagios (pour être plus précis qui l'empêcherais de monter en charge).
Juste au dessus tu viens de dire que c'est l'architecture qui fait la différence (et ça je suis d'accord). Interpréter, JIT ou compiler vers une VM le code est un peu plus rapide (il gagne de quelques facteurs) et les performances qu'on arrive à produire actuellement tendent à fortement limiter cette différence. Par contre si tu code plus ou moins bien c'est carrément la complexité de ton programme qui va en pâtir et là tu peut l'écrire en assembleur ou le bruler directement sur CPU ce sera toujours lent.
Ce qui fait que ton bureau est léger c'est probablement qu'il est plus simple. C'est peut être parce qu'il est mieux conçu et/ou qu'il fait moins de choses et/ou qu'il y a plus de simplicité grâce à un couplage plus fort. Mettre ça sur le dos du ou des langages c'est pas si évident à mon avis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
Bien sûr parce que c'est le langage qui fait la performance. D'où par exemple la lenteur de shinken (python) face à nagios (C).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 9.
Linus et le projet GNU aurait pu se contenter de demander à IBM & co de libérer Unix.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Bon les développeurs Gnome sont idiots. Mais qu'en est il de ceux de Qt et de Windows ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Il n'a pas de classe, c'est normal parce qu'il fait de l'objet par prototype.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par barmic . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 2.
L'intérêt d'un commit local est très très très limité pour des documents binaires. Il apporte à mon avis surtout une confusion entre ce qui est poussé et ce qui est commité.
Ça ne m'a pas l'air d'être l'organisation décrite dans le journal. Il n'y a pas des équipes mais une équipe qui travail sur un document. De plus il ne parle pas d'une plateforme de publication, mais d'un groupe de personnes dans différentes entreprises qui éditent un document de manière collaborative.
(j'ai un peu l'impression de voir des commerciaux tenter de faire coller les besoins de quelqu'un à leur produi)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par barmic . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Et d'après toi ceux sont tous des… webmasters (et toc !) qui font ces choix ? Ou ils sont tous tombé sur la tête ?
Juste histoire que ton commentaire soit un minimum constructif (et mérite sa note).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SVN ou autre
Posté par barmic . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 4.
Quel est l'intérêt ? Tu pense que les utilisateurs vont avoir plusieurs branches locales ou plusieurs dépôts distants (généralement au contraire dans ces cas on préfère une révérenciel global) ? Sachant que tout les merges seront pourris et pour les même raison tout ce qui est manipulation de l'historique ou le cherry picking aussi.
Il ne faut pas proposer des DCVS juste parce que ça fait bien aujourd'hui de parler de ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)