oué mais la tu vois, tu touche la grande différence entre ces outils...
Jamais (ou rarement plutôt) je fais une sélection a la souris...
Et sous emacs, le mieux est même d'utiliser un mode qui le fait avec C-Enter
Il est alors possible de se déplacer a chaque coin de la sélection pour saisir du texte à l'intérieur / à l'extérieur des deux verticales, de remplacer, etc
Il est donc parfait pour rajouter un texte commun a plein de lignes en une fois (un commentaire par exemple)
> «Listes modifiables» au lieu de Listes éditables.
juste en passant, pour moi ce n'est pas le même sens et les deux sont bien français je trouve.
Une liste modifiable indique plutôt une liste dont on va changer l'ordre.
Une liste éditable me fait plus penser qu'on va éditer les valeurs composant cette liste en priorité, ce qui correspond tout à fait aux listes qu'on trouve dans les formulaires dans laquelle on peut tout de même saisir une entrée.
Après, c'est ptetre moi aussi (ça serait pas la première fois...)
heu ... les liens de ce genre c'est juste pour qu'on comprenne pas ce que c'est et qu'on aille pas voir de quoi il en retourne et donc que le fortran disparaisse dans les abîmes informatiques à tout jamais ?
justement, le mosieur te parles de zoom entre deux niveaux précalculés quand le zoom est entre deux niveau de zoom
genre tu as des tuiles au 1/50000 des tuiles au 1/100000 et tu veux afficher quelque chose au 1/75000
Pour des documents, des images, etc ça se comprend.
Pour de la carto ça ne se fait pas (genre même pour les orthophotos chez google le tuilage ne se recouvre pas)
En gros en carto on a plutôt deux cas, soit des serveurs de tuilage et on utilise que des zooms précalculés, soit on utilise des serveurs qui recalculent les données systématiquement (ou non avec du cache) pour tout niveau de zoom toute emprise demandée.
Donc pour en revenir à ce que LaurentJ disait, forcément si tu as une image à une définition donnée, que tu la zoom (l'image même) tu as finalement moins d'information et une moins bonne précision que le zoom où tu te place le nécessiterait, d'où l'apparition de problèmes, de trous, d'incohérence, etc
(sais pas si c'est compréhensible, au moins je me comprend... ;))
heu non, en carto (mon boulot c'est justement de coder des applis cartographiques en web) les tuiles ne se chevauchent jamais.
> vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails)
Lorsqu'on utilise des tuiles (du "tile cache" en fait) les niveaux de zoom sont toujours prédéfinis et l'intégralités des tuiles (toute portion visible à tout niveau de zoom autorisé) sont précalculé.
Ce qui peut prendre ... pfiou trop de temps entre autre, et aussi qu'il est beaucoup plus rapide d'accéder à des fichiers (qui peuvent être avec plusieurs niveaux de cache que ce soit sur les durs ou sur de la ram) que de lire les données et de les calculer.
> Donc, montre moi la licence de Launchpad (avant libération).
Comme on dit, mon cul tu l'as pas vu pourtant il existe...
> Mais comme il n'était pas distribué avant, il ne pouvait pas être pas open-source.
Mais ne serait-ce en contradiction avec ta phrase précédente :
> un programme patché sans redistribué les source tout en étant considérer comme libre
ainsi que
> Pourtant, tu utilise du logiciel libre en utilisant Google sans avoir accès aux sources.
Que je comprenne : le logiciel (non distribué) est libre ou non ?
Le fait qu'un logiciel ne soit pas distribué t'empêche de réclamer des droits liés à sa diffusion, mais ne change pas le statut de celui-ci.
> je n'ais pas vu Google redistribué le source des noyaux qu'ils font tourner.
Et alors, cela enlève-t-il le fait que Linux soit open-source ?
Cela ne donne aucun droit / devoir concernant les modifs qu'on fait, mais c'est tout.
Linux reste tout de même un logiciel libre.
> Si personne n'a le logiciel, il n'y a pas de licence qui s'applique
> présenter un programme patché sans redistribuer les source tout en étant considéré comme libre
Donc en fait tu viens d'écrire que tu était d'accord avec ce que j'ai indiqué....
Bien qu'aucune licence ne puisse s'appliquer car il n'y a pas diffusion, rien n'empêche de considérer le logiciel comme propriétaire. Et rien n'empêche aux propriétaires de se logiciel d'en indiquer une licence (utilisable dans le cas où le logiciel serait distribué) ainsi que leur décision ou non d'en faire un logiciel propriétaire.
> Mais tout ceci est du chipotage, mais j'aime bien troller débattre sur le sujet
heu... tu aurais du barrer l'autre mot, car là j'ai eu du mal à saisir le débat ...
Allez, je résume :
- Canonical : launchpad (alors propriété de Canonical) n'est pas libre !
- les autres : oui mais non, si on considère la distribution alors il n'y a pas de licence, en fait on en sait rien mais on veut _croire_ que launchpad est libre mais pas diffusé
(s'en suit l'agréable nouvelle d'apprendre que Canonical a finalement libéré launchpad)
Tiens mais au fait, le titre Launchpad is now open source indique bien que Launchpad vient de passer en open source, non que Launchpad est maintenant distribué, sous la licence open-source qu'il avait précédemment...
J'ai écris un soft dans mon garage bureau, j'y ai associé un fichier de license BSD, et ait indiqué que cette licence s'appliquait à mon programme.
Maintenant oui, tant que je l'ai filé à personne personne ne le verra et ne l'utilisera.
Mais dans tous les cas, j'aurais très bien pu déclarer que le logiciel n'est pas open source et ne pas le diffuser sous licence libre.
C'est exactement ce que launchapd était.
Le texte cité proviens de la faq de launchpad, avant qu'ils la change.
Maintenant ce que je trouve très génial (mais vraiment) c'est la capacité qu'on les gens à refuser ce que les propriétaires de launchpad écrivent.
Canonical déclare que Launchpad n'est pas open-source mais les gens débatte sur le fait que oui ou non c'est distribué.
(et si le débat portait réellement sur ça, pourquoi la agpl existe ?)
Franchement je sais pas ce qu'il vous faut de plus...
(maintenant je me réjoui de sa libération, à voir comment ça marche et si je peux en mettre un chez moi pour tester mais c'est un très bon point qui enlève un peu de l'hypocrisie précédente)
> en fait, il n'était sous rien du tout et la seule chose de certaine, c'est qu'on ne pouvait pas avoir le code source ni rien du tout.
En fait ... non !
Il était explicitement stipulé dans la FAQ de Launchpad que c'était non libre.
A partir de là, tout discutions sur la mise à disposition ou non de l'application ne servait plus à grand chose ... puisque les personnes derrière Launchpad indiquait que c'était pas libre.
> Personnellement j'ai de plus en plus de difficulté à apprécier la production cinématographique française[...]. Je prendrais par exemple le dernier film a la mode "les beaux gosses" [...] même si c'est reussi
A vrai dire j'ai du mal à comprendre.
Tu dis que tu as du mal à apprécier des films que tu dis être réussi.
Où ce situe donc le problème ?
Pour ma part, j'ai vu pas mal de bons films cette année, y compris des films français (par exemple : MR73, diamant 13, pour elle)
J'ai peut-être pas une culture ciné très grande, mais je ne retrouve pas vraiment ce que tu dis.
Peut-être est-ce aussi toi qui a changé et qui recherche autre chose, non ?
(entre autre faut voir ce qu'on recherche dans un film, pour moi c'est surtout pour me changer les idées, me détendre, ceci explique peut-être cela)
Si tu as A qui dépend de B en version 1.0
A étant installé (donc B aussi en 1.0)
C dépend de B en version >= 1.0 <= 1.5
Tu installes C, ça roule
Maintenant D est créé avec comme dépendance A et B en version > 1.0
Comment tu fais ?
Si tu installe D, il faut A qui lui veut B=1.0 mais D veut B>1.0
s'il existe un A supérieur venant avec B>1.0 alors tu peux t'en sortir
Par contre, si cette version de A vient avec une version de B=1.6 il faut supprimer C par exemple
m'enfin c'est un exemple moisi, bateau, et pas précis, mais ça touche seulement le début de tes problèmes
lorsque tu aura un nombre conséquent de paquet tu sera bien obligé de jeter ton modèle et d'en faire un vrai, par contre nécessitant beaucoup plus de taff que ça...
Va lire par exemple la note 3 que j'ai mise plus haut
j'oubliais un commentaire sur le passage cité : si apt a des grosses lacunes, alors qu'il fonctionne depuis des années, a nécessité pas mal de taff (plus d'une semaine) etc, je doute que ce soit tout seul comme ça en une semaine que ça marche.
La résolution des dépendances moi comme ça, sans trop réfléchir, ça me fait plutôt penser à de la Theorie_des_graphes ce qui est un poil plus complexe que d'avoir une bête liste de dépendances
> J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct
Juste parce que je pense que c'est des choses comme ça qui font que les gens n'ont pas forcément confiance / ne croient pas en ton projet :
C'est pas parce que tu as mis une semaine entière que c'est bien.
Tu peux très bien faire de la merde toute ta vie, comme bien concevoir / coder en général, le temps n'a que peu d'influence et dépend aussi (beaucoup) de l'expérience acquise.
Je pense par exemple que tu minimise _beaucoup_ le problème de résolution de dépendance, qui est au contraire au coeur d'un gestionnaire de paquet
Par exemple, si tu lis http://fr.opensuse.org/Libzypp/Gestion_des_paquets il y a le passage suivant :
En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.
Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.
(l'emphase est de moi)
Voici les notes correspondantes :
# [1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
# [2] http://en.wikipedia.org/wiki/Computational_complexity_theory
# [3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
# [4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006
La manière dont tu réponds montre justement que tu n'as pas ce qu'il faut pour résoudre correctement les dépendances, dans un temps correct (installer, faire des tests sur 2 - ha non, 1 - paquet ne prouve strictement rien est est vraiment un cas particulier hyper simple)
Dans toutes ces histoires de paquet, y'a pas un truc d'oublié ? la gestion des dépendances par exemple, non ?
Et c'est pas juste une table ou une liste hein, souvent derrière ça y'a des algos, des dépendances plus ou moins forte. Si tu veux une résolution rapide c'est pas simple non plus, si tu veux aussi les installer dans le bon ordre, etc
A voir aussi lorsque des logiciels ont des dépendances vers des versions différentes (mais pas forcément incompatible non plus...)
m'enfin tout ça pour dire que personne n'en parle et que sans ça ton système de paquet ben il marchera pas bien (et c'est vrai, si on compare chez mandriva c'est pas du ressort de rpm mais de urpmi, chez debian c'est pas deb mais apt-get/aptitude - si je ne me trompe pas)
> Je suis plutôt pour un code très aéré, donc avec des tabulations de 8 caractères, des accolades à la ligne, etc.
oué enfin c'est pas parce que tu met l'accolade à la fin d'une ligne que tu peux pas passer de ligne là où c'est nécessaire.
Par contre spa méchant mais du code avec des tabulations de 8 j'oublie direct... (et si c'est codé en français encore plus...)
Et faire ces propres conventions de codage c'est bien mais varier à ce point ... ben heu, c'est pas pour rien que les conventions sont souvent assez proche (accolade mise à part)
oui mais non
si pour la main droite la disposition penchée des touche peut être intéressante, qu'en est-il de ta main gauche ?
(ou alors on a pas les même mains...)
Le poignet gauche est souvent cassé pour tapper
combien penchent leur clavier légèrement sur la droite ?
mais franchement le merge c'est pas encore ça
Le cherry picking ça marche encore assez bien, mais le merge de branches ... non
Dès que les branches sont un peu trop vieilles c'est toujours galère
En plus, le problème d'svn est qu'on perd complètement l'historique de merge
Si je merge une branche dans une autre, j'applique en fait localement les commits de la branche à merger dans la copie de la branche de destination.
Je gère les conflits, toussa, et ensuite je commit
Mais voilà, le merge est finalement _un_ commit
Si je n'indique pas en commentaire tout ce qui est fait dans mon commit, les révisions mergés par exemple, ben c'est perdu
J'ai aussi rencontré plusieurs fois des problèmes sur un svn merge --reintegrate (alors que c'est le but, que ça marche sans se poser de question...)
Pour le moment, un collègue utilise git-svn pour ses branches (enfin depuis 2 jours)
Moi j'ai aussi essayé mercurial mais sans vraiment de succès pour la gestion svn, mais je vais continuer dans se sens dans l'espoir d'avoir un truc vraiment intégré à windows, eclipse, linux, etc
on verra bien ce que ça donne
Mais l'approche décentralisée apporte des choses intéressantes, surtout si on prend l'habitude de faire des branches, même locales, pour tout ce qu'on fait. Ca permet de vraiment bien organiser les choses, mais aussi le développeur ne peu plus dire "désolé je suis en train de tout refactorisé, j'en ai pour 2 jours sans commiter et ton problème ben on verra plus tard" dans ce cas ce serait dans une branche, un problème arrive ? on change vite fait de branche, le travail commencé n'est pas perdu, on peut développer plusieurs choses en parallèle !
pas que dans les services maternités
mais je nuancerais un peu car c'est pas dans le cas précité, les infirmières font déjà du boulot de secrétariat en temps normal (gestion des entrées, sorties, paperasse diverse, "standard", etc) (et le 3 mois, faut pas pousser - justement - et même si ça arrive, c'est plutôt lié au travail debout, qui n'est pas spécifique aux infirmières mais qui a les même effets)
C'est simplement que dans certains cas on va moduler un peu le travail pour faciliter la tâche et éviter des problèmes (ma femme est enceinte, infirmière dans un hopital psy).
La charge de travail reste la même mais dans ce cas précis par exemple elle va moins au contact de personnes violentes et décharge les autres infirmières sur d'autres points.
Juste un peu de modulation quoi, mais bon, pour ça pas besoin d'une loi idiote...
> tu places le débat sur un terrain technique.
oui car le problème vient en bonne partie d'outils inefficaces
> Quand SVN aura les mêmes fonctionnalités
> quand SVN aura
> il y aura
oué ben quand il aura des fonctionnalités vraiment intéressante je reverrai peut-être mon jugement, en attendant il est à la ramasse. Et avoir des commits locaux ne servira à rien tant qu'on ne pourra pas faire de merge sereinement
Et comme le modèle de svn ne permet pas de le faire...
> Avec un VCS décentralisé, le gars va publier dans son coin, sans forcément en parler, et ça restera comme ça (comportement individuel par défaut). Avec un VCS centralisé, il va discuter avec la communauté pour qu'il puisse intégrer sa modification dans la branche principale (comportement collectif par défaut).
Oui mais au moins il l'aura publié
L'exemple que je prenais, et je l'ai justement précisé, partait du cas où la personne fait une modif initialement pour elle, sans vraiment se soucier du besoin d'autres.
Avec un système centralisé ou non il n'ira pas la proposer aux dev :
- pas de temps
- pas l'envie / le besoin
- communauté fermée (ça existe trop souvent aussi)
- besoin de "faire ses preuves" avant de pouvoir réellement proposer quelque chose
Mais dans un cas ce sera utilisable, dans l'autre il l'aura gardé en interne et personne n'en saura rien.
Alors oui, c'est technique mais dans ce cas l'outil peut permettre d'améliorer l'ensemble même pour quelqu'un que ça n'intéresse pas forcément et qui devrait faire des efforts avec un système centralisé incapable de gérer convenablement ce genre de cas
> Un VCS décentralisé facilite le fait de faire un truc dans son coin, là où un VCS centralisé favorise le retour au projet initial, à mon avis.
Heu non, avec une version décentralisé on a un outil permettant d'aider le développeur à le faire, en permettant dès l'origine (inclus dans les fonctionnalités de base) de fusionner son travail avec la branche principale.
Sans un tel outil, ça ne favorise en rien le retour au projet initial.
En continuant l'exemple de RoR :
un gars à une idée, un souhait à implémenter, qq chose à coder mais ne fais pas partie de l'équipe de dev, et ne veut de toute manière rajouter qu'une petite chose et ne pas en faire partie (ça arrive pour plein de raisons)
- avec une version centralisée : il va faire un checkout qq part, modifier son code, le garder en local et l'utiliser. Il a sa version modifiée. Si le trunk / tag / branche sur laquelle il s'est basé change ... ben c'est pas forcément facile, au mieux un svn up par exemple mais c'est pas forcément simple
- avec une version décentralisée : il fait son clone, fait sa branche propre, code son truc dedans. Jusque là il gagne déjà le fait que ce soit commitable dans sa branche. Il peut ensuite la publier s'il en a envie (et non envoyer des patch... ça a des bons et des mauvais côtés). Si la branche principale évolue ... ben c'est quand même un peu plus facile à gérer
Mais surtout, dans le deuxième cas s'il la rendue publique, et par exemple juste envoyé un mail en disant "j'ai rajouté tel truc" ça devient plus facile à intégrer ponctuellement que de lui autoriser à commiter dans le dépot principal ou récupérer des patch, y'a l'historique, toussa ...
Que tu n'ai pas besoin d'un système décentralisé je comprend. Qu'il y ait une telle aversion, j'ai plus de mal à comprendre...
[^] # Re: alternative?
Posté par CrEv (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 1.
Jamais (ou rarement plutôt) je fais une sélection a la souris...
Et sous emacs, le mieux est même d'utiliser un mode qui le fait avec C-Enter
Il est alors possible de se déplacer a chaque coin de la sélection pour saisir du texte à l'intérieur / à l'extérieur des deux verticales, de remplacer, etc
Il est donc parfait pour rajouter un texte commun a plein de lignes en une fois (un commentaire par exemple)
Mode cua : http://www.emacswiki.org/emacs/CuaMode
Vraiment important comme mode ça.
Faire des sélection (y compris verticales) à la souris ... ben heu comment dire ... faut déjà lacher le clavier quoi
[^] # Re: Quelques corrections
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie de Django 1.1. Évalué à 2.
juste en passant, pour moi ce n'est pas le même sens et les deux sont bien français je trouve.
Une liste modifiable indique plutôt une liste dont on va changer l'ordre.
Une liste éditable me fait plus penser qu'on va éditer les valeurs composant cette liste en priorité, ce qui correspond tout à fait aux listes qu'on trouve dans les formulaires dans laquelle on peut tout de même saisir une entrée.
Après, c'est ptetre moi aussi (ça serait pas la première fois...)
[^] # Re: Et pendant ce temps
Posté par CrEv (site web personnel) . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 1.
[^] # Re: Tuiles…
Posté par CrEv (site web personnel) . En réponse au journal Et un site de plus sans flash : mappy. Évalué à 2.
genre tu as des tuiles au 1/50000 des tuiles au 1/100000 et tu veux afficher quelque chose au 1/75000
Pour des documents, des images, etc ça se comprend.
Pour de la carto ça ne se fait pas (genre même pour les orthophotos chez google le tuilage ne se recouvre pas)
En gros en carto on a plutôt deux cas, soit des serveurs de tuilage et on utilise que des zooms précalculés, soit on utilise des serveurs qui recalculent les données systématiquement (ou non avec du cache) pour tout niveau de zoom toute emprise demandée.
Donc pour en revenir à ce que LaurentJ disait, forcément si tu as une image à une définition donnée, que tu la zoom (l'image même) tu as finalement moins d'information et une moins bonne précision que le zoom où tu te place le nécessiterait, d'où l'apparition de problèmes, de trous, d'incohérence, etc
(sais pas si c'est compréhensible, au moins je me comprend... ;))
[^] # Re: Ben moi..
Posté par CrEv (site web personnel) . En réponse au journal Linus à propos des contributions de Microsoft. Évalué à 7.
[^] # Re: Tuiles…
Posté par CrEv (site web personnel) . En réponse au journal Et un site de plus sans flash : mappy. Évalué à 2.
heu non, en carto (mon boulot c'est justement de coder des applis cartographiques en web) les tuiles ne se chevauchent jamais.
> vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails)
Lorsqu'on utilise des tuiles (du "tile cache" en fait) les niveaux de zoom sont toujours prédéfinis et l'intégralités des tuiles (toute portion visible à tout niveau de zoom autorisé) sont précalculé.
Ce qui peut prendre ... pfiou trop de temps entre autre, et aussi qu'il est beaucoup plus rapide d'accéder à des fichiers (qui peuvent être avec plusieurs niveaux de cache que ce soit sur les durs ou sur de la ram) que de lire les données et de les calculer.
enfin c'est comme ça pour la carto en tout cas
un peu de lecture ;)
http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
[^] # Re: Fix
Posté par CrEv (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.
Comme on dit, mon cul tu l'as pas vu pourtant il existe...
> Mais comme il n'était pas distribué avant, il ne pouvait pas être pas open-source.
Mais ne serait-ce en contradiction avec ta phrase précédente :
> un programme patché sans redistribué les source tout en étant considérer comme libre
ainsi que
> Pourtant, tu utilise du logiciel libre en utilisant Google sans avoir accès aux sources.
Que je comprenne : le logiciel (non distribué) est libre ou non ?
Le fait qu'un logiciel ne soit pas distribué t'empêche de réclamer des droits liés à sa diffusion, mais ne change pas le statut de celui-ci.
[^] # Re: Fix
Posté par CrEv (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
Et alors, cela enlève-t-il le fait que Linux soit open-source ?
Cela ne donne aucun droit / devoir concernant les modifs qu'on fait, mais c'est tout.
Linux reste tout de même un logiciel libre.
> Si personne n'a le logiciel, il n'y a pas de licence qui s'applique
> présenter un programme patché sans redistribuer les source tout en étant considéré comme libre
Donc en fait tu viens d'écrire que tu était d'accord avec ce que j'ai indiqué....
Bien qu'aucune licence ne puisse s'appliquer car il n'y a pas diffusion, rien n'empêche de considérer le logiciel comme propriétaire. Et rien n'empêche aux propriétaires de se logiciel d'en indiquer une licence (utilisable dans le cas où le logiciel serait distribué) ainsi que leur décision ou non d'en faire un logiciel propriétaire.
> Mais tout ceci est du chipotage, mais j'aime bien troller débattre sur le sujet
heu... tu aurais du barrer l'autre mot, car là j'ai eu du mal à saisir le débat ...
Allez, je résume :
- Canonical : launchpad (alors propriété de Canonical) n'est pas libre !
- les autres : oui mais non, si on considère la distribution alors il n'y a pas de licence, en fait on en sait rien mais on veut _croire_ que launchpad est libre mais pas diffusé
(s'en suit l'agréable nouvelle d'apprendre que Canonical a finalement libéré launchpad)
Tiens mais au fait, le titre indique bien que Launchpad vient de passer en open source, non que Launchpad est maintenant distribué, sous la licence open-source qu'il avait précédemment...
[^] # Re: Fix
Posté par CrEv (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.
Maintenant oui, tant que je l'ai filé à personne personne ne le verra et ne l'utilisera.
Mais dans tous les cas, j'aurais très bien pu déclarer que le logiciel n'est pas open source et ne pas le diffuser sous licence libre.
C'est exactement ce que launchapd était.
Le texte cité proviens de la faq de launchpad, avant qu'ils la change.
Maintenant ce que je trouve très génial (mais vraiment) c'est la capacité qu'on les gens à refuser ce que les propriétaires de launchpad écrivent.
Canonical déclare que Launchpad n'est pas open-source mais les gens débatte sur le fait que oui ou non c'est distribué.
(et si le débat portait réellement sur ça, pourquoi la agpl existe ?)
[^] # Re: Fix
Posté par CrEv (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 1.
Comme indiqué plus haut ... non c'est faux
tiré de https://help.launchpad.net/FAQ#head-34295746b9c12bbe42eee4a9(...) en février 2008
Franchement je sais pas ce qu'il vous faut de plus...
(maintenant je me réjoui de sa libération, à voir comment ça marche et si je peux en mettre un chez moi pour tester mais c'est un très bon point qui enlève un peu de l'hypocrisie précédente)
[^] # Re: Fix
Posté par CrEv (site web personnel) . En réponse à la dépêche Launchpad libéré !. Évalué à 2.
En fait ... non !
Il était explicitement stipulé dans la FAQ de Launchpad que c'était non libre.
A partir de là, tout discutions sur la mise à disposition ou non de l'application ne servait plus à grand chose ... puisque les personnes derrière Launchpad indiquait que c'était pas libre.
[^] # Re: un troll de moins
Posté par CrEv (site web personnel) . En réponse au journal Launchpad est libre. Évalué à 0.
toi t'as jamais essayé emacs o_O (qui écrave vi, vim et gvim pour ça !)
# plop
Posté par CrEv (site web personnel) . En réponse au journal exception culturelle francaise. Évalué à 5.
A vrai dire j'ai du mal à comprendre.
Tu dis que tu as du mal à apprécier des films que tu dis être réussi.
Où ce situe donc le problème ?
Pour ma part, j'ai vu pas mal de bons films cette année, y compris des films français (par exemple : MR73, diamant 13, pour elle)
J'ai peut-être pas une culture ciné très grande, mais je ne retrouve pas vraiment ce que tu dis.
Peut-être est-ce aussi toi qui a changé et qui recherche autre chose, non ?
(entre autre faut voir ce qu'on recherche dans un film, pour moi c'est surtout pour me changer les idées, me détendre, ceci explique peut-être cela)
[^] # Re: dépendance
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 4.
A étant installé (donc B aussi en 1.0)
C dépend de B en version >= 1.0 <= 1.5
Tu installes C, ça roule
Maintenant D est créé avec comme dépendance A et B en version > 1.0
Comment tu fais ?
Si tu installe D, il faut A qui lui veut B=1.0 mais D veut B>1.0
s'il existe un A supérieur venant avec B>1.0 alors tu peux t'en sortir
Par contre, si cette version de A vient avec une version de B=1.6 il faut supprimer C par exemple
m'enfin c'est un exemple moisi, bateau, et pas précis, mais ça touche seulement le début de tes problèmes
lorsque tu aura un nombre conséquent de paquet tu sera bien obligé de jeter ton modèle et d'en faire un vrai, par contre nécessitant beaucoup plus de taff que ça...
Va lire par exemple la note 3 que j'ai mise plus haut
[^] # Re: dépendance
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 4.
La résolution des dépendances moi comme ça, sans trop réfléchir, ça me fait plutôt penser à de la Theorie_des_graphes ce qui est un poil plus complexe que d'avoir une bête liste de dépendances
[^] # Re: dépendance
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 4.
Juste parce que je pense que c'est des choses comme ça qui font que les gens n'ont pas forcément confiance / ne croient pas en ton projet :
C'est pas parce que tu as mis une semaine entière que c'est bien.
Tu peux très bien faire de la merde toute ta vie, comme bien concevoir / coder en général, le temps n'a que peu d'influence et dépend aussi (beaucoup) de l'expérience acquise.
Je pense par exemple que tu minimise _beaucoup_ le problème de résolution de dépendance, qui est au contraire au coeur d'un gestionnaire de paquet
Par exemple, si tu lis http://fr.opensuse.org/Libzypp/Gestion_des_paquets il y a le passage suivant :
En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.
Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.
(l'emphase est de moi)
Voici les notes correspondantes :
# [1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
# [2] http://en.wikipedia.org/wiki/Computational_complexity_theory
# [3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
# [4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006
La manière dont tu réponds montre justement que tu n'as pas ce qu'il faut pour résoudre correctement les dépendances, dans un temps correct (installer, faire des tests sur 2 - ha non, 1 - paquet ne prouve strictement rien est est vraiment un cas particulier hyper simple)
# dépendance
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 5.
Et c'est pas juste une table ou une liste hein, souvent derrière ça y'a des algos, des dépendances plus ou moins forte. Si tu veux une résolution rapide c'est pas simple non plus, si tu veux aussi les installer dans le bon ordre, etc
A voir aussi lorsque des logiciels ont des dépendances vers des versions différentes (mais pas forcément incompatible non plus...)
m'enfin tout ça pour dire que personne n'en parle et que sans ça ton système de paquet ben il marchera pas bien (et c'est vrai, si on compare chez mandriva c'est pas du ressort de rpm mais de urpmi, chez debian c'est pas deb mais apt-get/aptitude - si je ne me trompe pas)
[^] # Re: Le Francais te tuera...
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
oué enfin c'est pas parce que tu met l'accolade à la fin d'une ligne que tu peux pas passer de ligne là où c'est nécessaire.
Par contre spa méchant mais du code avec des tabulations de 8 j'oublie direct... (et si c'est codé en français encore plus...)
Et faire ces propres conventions de codage c'est bien mais varier à ce point ... ben heu, c'est pas pour rien que les conventions sont souvent assez proche (accolade mise à part)
[^] # Re: Ma vie sans bépo
Posté par CrEv (site web personnel) . En réponse au journal Après 4 semaines de bépo. Évalué à 3.
si pour la main droite la disposition penchée des touche peut être intéressante, qu'en est-il de ta main gauche ?
(ou alors on a pas les même mains...)
Le poignet gauche est souvent cassé pour tapper
combien penchent leur clavier légèrement sur la droite ?
[^] # Re: Ma vie sans bépo
Posté par CrEv (site web personnel) . En réponse au journal Après 4 semaines de bépo. Évalué à 2.
comment on "pense" objectivement ?
[^] # Re: svn-merge
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
mais franchement le merge c'est pas encore ça
Le cherry picking ça marche encore assez bien, mais le merge de branches ... non
Dès que les branches sont un peu trop vieilles c'est toujours galère
En plus, le problème d'svn est qu'on perd complètement l'historique de merge
Si je merge une branche dans une autre, j'applique en fait localement les commits de la branche à merger dans la copie de la branche de destination.
Je gère les conflits, toussa, et ensuite je commit
Mais voilà, le merge est finalement _un_ commit
Si je n'indique pas en commentaire tout ce qui est fait dans mon commit, les révisions mergés par exemple, ben c'est perdu
J'ai aussi rencontré plusieurs fois des problèmes sur un svn merge --reintegrate (alors que c'est le but, que ça marche sans se poser de question...)
Pour le moment, un collègue utilise git-svn pour ses branches (enfin depuis 2 jours)
Moi j'ai aussi essayé mercurial mais sans vraiment de succès pour la gestion svn, mais je vais continuer dans se sens dans l'espoir d'avoir un truc vraiment intégré à windows, eclipse, linux, etc
on verra bien ce que ça donne
Mais l'approche décentralisée apporte des choses intéressantes, surtout si on prend l'habitude de faire des branches, même locales, pour tout ce qu'on fait. Ca permet de vraiment bien organiser les choses, mais aussi le développeur ne peu plus dire "désolé je suis en train de tout refactorisé, j'en ai pour 2 jours sans commiter et ton problème ben on verra plus tard" dans ce cas ce serait dans une branche, un problème arrive ? on change vite fait de branche, le travail commencé n'est pas perdu, on peut développer plusieurs choses en parallèle !
[^] # Re: Une loi pour rien?
Posté par CrEv (site web personnel) . En réponse au journal Télé-travailler en arrêt maladie ou maternité: la proposition de Frédéric Lefebvre. Évalué à 2.
mais je nuancerais un peu car c'est pas dans le cas précité, les infirmières font déjà du boulot de secrétariat en temps normal (gestion des entrées, sorties, paperasse diverse, "standard", etc) (et le 3 mois, faut pas pousser - justement - et même si ça arrive, c'est plutôt lié au travail debout, qui n'est pas spécifique aux infirmières mais qui a les même effets)
C'est simplement que dans certains cas on va moduler un peu le travail pour faciliter la tâche et éviter des problèmes (ma femme est enceinte, infirmière dans un hopital psy).
La charge de travail reste la même mais dans ce cas précis par exemple elle va moins au contact de personnes violentes et décharge les autres infirmières sur d'autres points.
Juste un peu de modulation quoi, mais bon, pour ça pas besoin d'une loi idiote...
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
oui car le problème vient en bonne partie d'outils inefficaces
> Quand SVN aura les mêmes fonctionnalités
> quand SVN aura
> il y aura
oué ben quand il aura des fonctionnalités vraiment intéressante je reverrai peut-être mon jugement, en attendant il est à la ramasse. Et avoir des commits locaux ne servira à rien tant qu'on ne pourra pas faire de merge sereinement
Et comme le modèle de svn ne permet pas de le faire...
> Avec un VCS décentralisé, le gars va publier dans son coin, sans forcément en parler, et ça restera comme ça (comportement individuel par défaut). Avec un VCS centralisé, il va discuter avec la communauté pour qu'il puisse intégrer sa modification dans la branche principale (comportement collectif par défaut).
Oui mais au moins il l'aura publié
L'exemple que je prenais, et je l'ai justement précisé, partait du cas où la personne fait une modif initialement pour elle, sans vraiment se soucier du besoin d'autres.
Avec un système centralisé ou non il n'ira pas la proposer aux dev :
- pas de temps
- pas l'envie / le besoin
- communauté fermée (ça existe trop souvent aussi)
- besoin de "faire ses preuves" avant de pouvoir réellement proposer quelque chose
Mais dans un cas ce sera utilisable, dans l'autre il l'aura gardé en interne et personne n'en saura rien.
Alors oui, c'est technique mais dans ce cas l'outil peut permettre d'améliorer l'ensemble même pour quelqu'un que ça n'intéresse pas forcément et qui devrait faire des efforts avec un système centralisé incapable de gérer convenablement ce genre de cas
[^] # Re: Mode avocat du Diable
Posté par CrEv (site web personnel) . En réponse au journal Télé-travailler en arrêt maladie ou maternité: la proposition de Frédéric Lefebvre. Évalué à 10.
et on ouvre aussi la voix aux pressions de l'employeur...
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 4.
Heu non, avec une version décentralisé on a un outil permettant d'aider le développeur à le faire, en permettant dès l'origine (inclus dans les fonctionnalités de base) de fusionner son travail avec la branche principale.
Sans un tel outil, ça ne favorise en rien le retour au projet initial.
En continuant l'exemple de RoR :
un gars à une idée, un souhait à implémenter, qq chose à coder mais ne fais pas partie de l'équipe de dev, et ne veut de toute manière rajouter qu'une petite chose et ne pas en faire partie (ça arrive pour plein de raisons)
- avec une version centralisée : il va faire un checkout qq part, modifier son code, le garder en local et l'utiliser. Il a sa version modifiée. Si le trunk / tag / branche sur laquelle il s'est basé change ... ben c'est pas forcément facile, au mieux un svn up par exemple mais c'est pas forcément simple
- avec une version décentralisée : il fait son clone, fait sa branche propre, code son truc dedans. Jusque là il gagne déjà le fait que ce soit commitable dans sa branche. Il peut ensuite la publier s'il en a envie (et non envoyer des patch... ça a des bons et des mauvais côtés). Si la branche principale évolue ... ben c'est quand même un peu plus facile à gérer
Mais surtout, dans le deuxième cas s'il la rendue publique, et par exemple juste envoyé un mail en disant "j'ai rajouté tel truc" ça devient plus facile à intégrer ponctuellement que de lui autoriser à commiter dans le dépot principal ou récupérer des patch, y'a l'historique, toussa ...
Que tu n'ai pas besoin d'un système décentralisé je comprend. Qu'il y ait une telle aversion, j'ai plus de mal à comprendre...