IsNotGood a écrit 5009 commentaires

> Le bonhomme te parle d'un choix, pas que ça doive ou ne doive pas marcher avec ubuntu

Il a dit que c'est basé sur Ubuntu.
Actuellement je fais un truc basé sur DirectShow. Le proter ailleurs est quasi impossible. Et si je dis que c'est basé sur DirectShow c'est car j'en dépend.

> qu'ils ont réuni en utilisant ubuntu

Utiliser un truc, c'est différent de baser une solution sur une truc. Quand tu te base sur quelque chose, ça veut dire que tu en dépend. C'est ta base. Si tu ne l'a plus, tout s'écroule.

> on a surtout le "lock-in" de ton cortex

Parlons du tient qui ne sait toujours pas lire.

Merci pour la réponse.
Je vois l'idée globale, mais je reste très sceptique.

> et même sur le site de Britney Spears.

Ruby on Rails, le célèbre framework (dexit dlfp : http://linuxfr.org/2007/12/11/23448.html ), n'a qu'a bien se tenir.

> Drupal peut notamment être utilisé comme simple moteur de blog

Et forum.

Drupal a aussi plein de modules (plus ou moins utile, de plus ou moins bonne qualité, mais on y trouve son bonheur).

J'utilise Drupal depuis quelques semaines et c'est vraiment excellent.

Et j'espère bien voir Britney Spears au prochain Drupalcon à Buston.
Laissez tomber RoR, c'est pas assez glamour.

> Avec ce genre de post, tu rends inutilement techniques les choses

Si parler d'url est technique...

> Le podcast est un standard de facto pour bloguer n'importe quel contenu numérique. Comment ça marche on s'en f... à part les développeurs.

Ben met un "bête" " <a href="......">label</a> " et ça marche aussi les doigts dans le nez avec un simple clic. Bref, pas besoin de potcast pour que ça marche.

> Si tu critiques, essaie au moins de faire semblant de maitriser le sujet !

J'ai fait semblant. Du mieux que j'ai pu.

> Déjà ce qui fait peur, c'est qu'il faille passer une url.

$ svn info | grep ^URL
Et tu l'as l'url.

> On peut pas le faire sur place, en étant deconnecté ?

Vas pas sur dlfp, on ne peut pas poster des commentaires en batch.

zul exige un dlfp décentralisé !

> http://linux.die.net/man/1/git-bisect

Le "git bisect run my_script" est effectivement cool.

> git contrairement à svn est documenté par des pages man ...

la command svn est très bien documentée.
Exemple :
$ svn help update
update (up): Actualise la copie de travail par rapport au dépôt.
usage : update [CHEMIN...]

  La copie de travail est actualisée à la révision HEAD ou à la révision
  précisée par l'option -r.
  L'opération effectuée sur chaque objet est donnée par un caractère :
    A  ajouté
    D  supprimé
    U  modifié
    C  en conflit
    G  fusionné

  La première colonne concerne l'objet, la seconde ses propriétés.
  Un 'B' en troisième colonne indique qu'un verrou a été volé ou cassé.

Options valides:
  -r [--revision] ARG      : ARG (peut aussi être une étendue ARG1:ARG2)
                     L'argument d'une révision peut être :
                       NUMÉRO       numéro de la révision
                       '{' DATE '}' révision disponible à cette date
                       'HEAD(       dernière révision du dépôt
                       'BASE'       rév. de base de la copie de travail
                       'COMMITTED'  dernière propagation à ou avant BASE
                       'PREV'       révision juste avant COMMITTED
  -N [--non-recursive]     : opère sur un seul répertoire
  -q [--quiet]             : essaie de se taire
  --diff3-cmd ARG          : utilise ARG comme commande de fusion
  --username ARG           : précise le nom d'utilisateur ARG
  --password ARG           : précise le mot de passe ARG
  --no-auth-cache          : ne conserve pas les éléments d'authentification
  --non-interactive        : pas de demande interactive
  --config-dir ARG         : fichiers de configuration dans ce répertoire
  --ignore-externals       : ignore les références externes


Ça vaut un man.

$ mkdir $HOME/svn
$ mkdir -p $HOME/svn/$PATH
$ svnadmin creeate $HOME/svn/$PATH
$ svn import -m "import initial" $HOME/$PATH file://$HOME/svn/$PATH
$ svn co file://$HOME/svn/$PATH $PATH

Et voila. Après du change $PATH par ce que tu veux et l'affaire est pliée.

> La simplicité ? je ne pense pas que svn soit plus simple que git ou mercurial

Pourquoi pas.

> Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?

J'en sais rien. Mais svn reste puissant. copie gratuite, une révision est un snapshot, accès concurrent au serveur sans problème, les conflits sont gérés, les attributs (type mime, information sur eof (native, crlf, etc), bit exécutable), les liens symboliques, synchronisation de dépôt, backup à chaud, etc.

> Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).

Ouais, ouais, ouais....
Si on sait faire un patch et qu'on n'est pas un manchot ça je gère ce type de situation (qui reste exceptionnelle).
Effectivement, si tu bousses tous les jours dans le train, il vaut mieux un DVCS.

> git est juste mieux

Mieux pour quoi ?
Pour les trucs de ouf comme Linux où il y a 200 branches en parallèle et aucune synchronisé ? Ou tout le monde s'échange des patchs pour faire des testes ? Ou 50 branches différente veulent tester le patch bidule ?
Oui dans ce cas, git est mieux. Indiscutable mieux.

Désolé d'être modeste, mais je ne bosse pas sur ce type de projet. Je n'ai pas le niveau.
Et désolé d'être cruel, mais il n'y a qu'une toute petite minorité de développeur qui peuvent s'aventurer dans Linux (je parle du coeur, je ne parle pas d'écrire seulement un driver (ce qui est très respectable)).
Et fait, je ne suis pas modeste, j'ai la prétention d'être un bon développeur. Pas une pointeur pour bosser sur le noyau Linux, mais un bon développeur. Un mec qu'on ne berne pas si je peux me permettre.

Il y en a qui jongle avec les diff et merge à longueur de journée. Je les admire.
Tu fais parti de cette catégorie ?
Bravo pour toi.
Mais tout le monde n'est pas dans cette catégorie.
Il ne faut pas laisser croire qu'un bon programmeur, qui fait son taff correctement, qui est une bonne contribution, un développeur sur qui tu peux faire confiance et pas un développeur qui te vomie un patch en disant que pour les bugs il regardera ça plus tard, a besoin d'être dans cette catégorie.
Que s'il se satisfait de subversion alors ce n'est qu'un minable. C'est faux.

Et les autres ne devrait pas croire d'utiliser git est une preuve d'intelligence ou la marque d'un bon développeur. Git n'est qu'un outil parmis d'autre. Ça doit s'apprendre 3 ou 4 jours.

> Rien que pour les perfs

Franchement, t'es un développeur ?
Tu pisses 500 000 lignes de code par jour ?
Ou tu t'amuses à alimenter ta gentoo à coup de checkout ?

Lorsque je développe, si j'attend 5 minutes subversion dans une journée, c'est vraiment le maximum de chez maximum.
M'enfin, contrairement à toi je ne pisse pas 500 000 lignes de code par jours ni ne fait un "svn update" de tous les sources installés sur ma bécane.

> rien que le fait de ne pas avoir besoin de continuellement être connecté au réseau, est déjà un intérêt.

Ben tu n'en a pas besoin pour svn.
Tu auras besoin d'être connecté lorsque tu as besoin du dépôt (commit, log, etc).
Tu en a pas besoins pour diff, revert, status, etc.

> Et pour le merge, tu fais comment avec SVN ?

Avec la commande "svn merge".
Surpris ?

> jamais l'historique des merge.

Juste.

> Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.

Super. Si tu fais 2000 commit dans la journée c'est définitivement un plus. Si tu n'en fait que 10 en moyenne (ce qui est une belle valeur lorsque tes commit sont fait intelligement), ben t'as gagné au mieux 1 minute.
Mais c'est super sinon.

C'est que ça...
Un bloque note...

> C'est faisable avec un SCM classique, à la main, mais c'est très chiant.

$ svn switch -r 100 [url]
$ # tu testes, ça marche.
$ svn -r 101 [url]
$ # tu testes, ça ne marche pas. Tu notes sur un postit que la version (ou changeset si tu préfères) 101 a introduit une régression
$ svn update # tu passes à la version HEAD
$ # Tu récupères (ou visualise seulement) le diff qui a introduit le bug (tu peux le faire n'importe quand).
$ svn diff -c 101 > patch_qui_sucks # le '101' que tu as écrit sur le postit
$ # tu peux évidement regarder le log du "changeset" 101
$ svn log -r 101
# blabla

Et voila.

Après tu peux faire des trucs plus exotique comme :

$ svn switch [url]/branche_stable
$ svn merge -c 101 [url]/trunk
$ # ça marche sur la version stable. Donc le "changeset" 101 n'est pas le seul en cause dans le problème.
$ # un autre bug a probablement aussi été intégré à la de développement dans autre version que la version 101.
$
$ # tu peux forcer la version d'un sous-répertoire
$ svn update -r 90 lib
$ # le répertoire lib est à la version 90 et le reste à la version 95 par exemple
$ svn merge -c 101
$ # Damned, ça marche ! Le problème est une combinaison d'un bug dans /lib et du "changeset" 101


C'est si compliqué que ça ?
Bien des choses sont possibles avec svn si on le connait. Et fort heureusement il n'est pas compliqué tout en étant puissant.

Si git est plus simple, j'aimerai bien un démontration comme je viens de le faire avec svn.

> Subversion ne permet pas de gérer plusieurs changesets en local.

Bof...
Les copies sous Subversion ne sont pas cher. Donc l'admin te fait une branche sur le server et l'affaire est pliée. Les bons admin laissent tous les utilisateurs faire des copies dans, par exemple, branches/devel. Aucun risque de perdre des données, c'est versionné :-)
Une fois le boulot terminer, il suffit d'un "svn rm ma_branche". Et rien est perdu évidemment. Ce n'est simplement plus visible dans la version HEAD.

Et comme ça tu profites des sauvegardes du serveur, les autres peuvent piocher dans ton boulot ou y participer en un rien de temps, etc...
Plein d'avantages à ne pas négliger.

Mais si t'aime bosser en solo...

> C'est particulièrement énervant quand on veut faire une modification importante, mais pas suffisante pour créer une branche.

Les branches sous subversion ne coûte rien.

> Hem , tu connais les podcasts?

Pour ceux qui ne savent pas, un "podcasts", c'est simplement une entrée rss avec une url en "pièce jointe" ou attribut.
C'est tout. Rien de magique. Évidement, il y a plein de bidule pour enrober la chose et justifier la mistérieuse appellation podcast.

> Des fois, c'est bien que l'outil reste simple.

Mouaif. Il te faut un navigateur web, un lecteur rss, Itunes, Amarok, ...
Pour la simplicité c'est discutable.

> Et là j'ai cliqué sur l'émission du 14/2 pour l'écouter.

Idem pour liferea (qui peut aussi faire lecteur puisqu'il utilise Firefox (et donc ses plugins)).

> Va demander à de nombreux développeurs en forfait 1 mois de maitriser les outils de merge, les concepts des DVCS avant d'être opérationnels avec tout ce qu'il ont d'autres à assimiler dans leur nouveau contexte alors qu'on leur demande juste de sauvegarder leur travail dans un espace securisé.

La question est surtout :
Pour quel gain ?
Pour la majorité des projets, ça n'apporte rien. D'un côté c'est pénalisant et souvent ça n'apporte rien.
Pour ma part, et je suis développeur, je n'ai jamais senti le besoin d'un DVCS. Ceci dit, je n'en nie pas les atouts, je n'en conteste pas le principe. Le développement de Linux (le noyau) est une "forêt d'arbre avec plein de branches". Tous les projets n'ont pas cette complexité. Fort heureusement.

C'est un peu comme connaitre l'assembleur. Pour certain projet c'est super. Mais que ça soit super (voire indispensable) pour certains projets, n'implique pas que c'est important pour tous les projets. Imposer l'assembleur ou un DVCS comme ticket d'entré à un projet sans une bonne justification est contre productif.


En passant, un hommage à Subversion.
Subversion est un excellent gestionnaire de version. Pas révolutionnaire, c'est clair. Mais excellent. Incontestablement l'un des meilleurs. Je suis navré de voir comme il est si souvent "boudé" alors que les développeurs de subversion ont fait un excellent travail, avec une remarquable compréhension du besoin, le tout avec un souci de la qualité (fiabilité, compatibilité, documentation, internationnalisation, etc) que j'aimerai voir dans beaucoup de projet.
Chapeau bas.

La superbe doc de Subversion :
http://svnbook.red-bean.com/en/1.4/svn-book.pdf
Pour ceux qui ne connaissent pas les gestionnaires de version, c'est aussi une excellente lecture.

> si l'intégrateur vend des machines basées sur une distrib (ici ubuntu)

Diable, une machine n'a pas à être basé sur un OS.
C'est déjà assez casse couille de répéter qu'une machine n'est pas conçu pour Vista contrairement à ce que dit la propagande MS, il ne va pas falloir qu'on fasse de même pour Ubuntu j'espère.


- Bonjour, je voudrais cette machine avec Slackware
- Désolé cette machine est basée sur Ubuntu et ne marche qu'avec Ubuntu
- Ben ça me troue le cul.

> Je ne crois pas que ça te dérangerai le moins du monde si quelqu'un te disait qu'il vend du matos préinstallé avec un OS basé sur une distrib RedHat ou Fedora.

Ici tu ne dis pas la même chose. Le matos n'est pas basé sur l'OS. Tu dis seulement qu'il y a une offre avec Red Hat/Fedora préinstallé. Heureusement que le matos n'est pas basé sur un OS.

> un OS basé sur une distrib RedHat ou Fedora.

Ici tu spécifies bien que c'est une distribution. C'est-à-dire la mise en oeuvre d'un ensemble de programme/librairie. Enfin tu parles d'un OS ce qui est très proche d'une distribution. Donc les spécificités de Red Hat ou Fedora se retrouveront probablement dans l'OS et ça peut être important pour l'utilisateur de l'OS (qui peut-être un développeur, un admin, etc qui recherche une fonctionnalité spécifique de OS (SeLinux, GFS, etc)). Mais que les spécificités d'Ubuntu se retrouve dans un "système biomed", j'en doute beaucoup. Que l'utilisation de la solution "biomed" soit impactée par les spécificités d'Ubuntu, j'en doute beaucoup. Que cette solution ne marche pas sans les spécificité d'Ubuntu, j'en doute beaucoup, etc.

Je vais te donner un mauvais exemple :
- "Je fais un site web qui est basé sur Fedora"

Ce n'est pas car j'utilise Fedora que c'est basé sur Fedora.
J'utilise Apache, PostgreSQL, Php, etc... C'est plus basé sur ces technologies que sur Fedora.
En fait, mon site web est basé sur Drupal. Drupal tourne avec Apache ou IIS, MySQL ou PostgreSQL ou Oracle, et donc tourne aussi sur Windows, Mac OS, *BSD, etc.
On est passé de "basé sur Fedora" à "basé sur Drupal (voire php)" (ce qui n'a rien à voir).

C'est une chose d'utiliser une distribution, c'est tout autre chose de dire qu'un logiciel est basé sur une distribution.

Un autre mauvais exemple :
- "libvirt/virt-manager (ou IcedTea ou beaucoup d'autres) est basé sur Fedora"
libvirt/virt-manager a été développé sous Fedora, a longtemps marché que sous Fedora. Libvirt a utilisé Fedora. Mais ce n'est pas basé sur Fedora. C'est basé sur Xen, KVM, Qemu, Linux, etc mais pas Fedora.
Quand Fedora a un truc en exclusivité, je ne dis pas que ce truc est basé sur Fedora. Je dis qu'il est uniquement sur Fedora actuellement.


> Je ne vois pas ce qui peut vous donner de l'urticaire.

On voit ici (et j'en fais parti) des gens qui parlent beaucoup d'intéropérabilité, d'indépendance, de standard, etc.
Et voilà qu'on nous sort des solutions "biomed" basées sur Ubuntu !?!
Et en plus on devrait applaudir des deux mains !


> Je ne crois pas que ça te dérangerai le moins du monde si quelqu'un te disait qu'il vend du matos préinstallé avec un OS basé sur une distrib RedHat ou Fedora.

J'ai fait un journal qui parle entre autre de Red Hat, de l'offre Red Hat de service. Je n'ai pas dit que les solutions proposées sont basées sur RHEL. Pour certaines c'est pourtant presque raisonnable de le dire. Notament pour tout ce qui utilise Red Hat Cluster avec GFS. C'est du logiciel libre, mais il n'y a quasiment que Red Hat qui le met en oeuvre. Que met en oeuvre Ubuntu que d'autres ne mettent pas en oeuvre ? Qu'à Ubuntu de spécial pour qu'une solution logiciel soit basée spécifiquement sur Ubuntu ?

On a le "lock-in" Windows. On va avoir le "lock-in" Ubuntu ?
Ben ça me donne de l'urticaire.

De toi ?

Et les explosions de X11. Le secteur psychologie/dépression va avoir du boulot.

Trève de plaisanterie, c'est le "ls se basent sur de l'Ubuntu" qui me dérange. Ils se basent peut-être sur GNU/Linux mais sûrement pas sur Ubuntu.
Où alors Ubuntu a des exclusivités proprios ?

Au delà de ces "détails", ce qui me pose problème, c'est l'intérêt de la chose.
Pour un cracker en herbe ça doit être cool. Pour un admin soucieux de ses bécanes et qui fait bien son boulot, c'est plus discutable.

> Les standards c'est bien, mais des fois ca fait plus de mal qu'autre chose.

Les standards (les vrais, pas les conneries à la MS) c'est bien, ça ne fait jamais de mal.
Tu n'as pas obligation de les utiliser !
Mais s'ils répondent à ton besoin, au-lieu de réinventer la roue et ajouter des problèmes d'intéropérabilité, prend un standard. C'est fait pour ça.

> Mieux:

Pas vraiment.
Dans mon cas, si tu fais une avance rapide et va "dans le futur", mplayer attend que les données arrivent. Idem s'il y a un embouteillage sur le réseau. Avec ton exemple mplayer quitte et tu dois le relancer.
Afin j'ai seulement besoin de wget pour enregistrer.

J'image que d'autres l'avaient remarqué, mais c'est maintenant hypra facile d'écouter France-inter.
L'url pour le directe : http://mp3.live.tv-radio.com/franceinter/all/franceinterhaut(...)
C'est du mp3, donc c'est "libre" en Europe.

Si vous voulez écouter ET enregistrer le direct, c'est trivial
$ wget --quiet http://mp3.live.tv-radio.com/franceinter/all/franceinterhaut(...) &
$ mkfifo fifo
$ tail -f --bytes=[un grand nombre] franceinterhautdebit.mp3 > fifo &
$ mplayer fifo

On peut aussi faire "mplayer -cache 30000" ainsi on peut avancer et reculer sur ta taille du tampon (avec 30 Mo, ça donne beaucoup de temps).