> Connaitre VI est indispensable, et VI ne sera jamais abandonné
C'est pour ça que sur mes machines je fais toujours un alias vi=emacsclient -t
Ca a toujours son petit effet (outre rendre le système utilisable)
(histoire que le post soit constructif)
et avec emacs en "serveur" et les alias vi, e=emacsclient -c -n c'est immédiat et nikel comme utilisation, à la fois en console et graphique, avec les mêmes fichiers dans les différentes fenêtres. Surement le mieux que j'ai trouvé pour le moment comme ide.
> Après venir expliquer ... ben c'est bon, je le ferais plus.
ra mais volà, faut pas prendre la mouche tout le temps hein !
tu fais un truc, ok.
on comprend pas vraiment à quoi ça sert, ni comment, ni pourquoi, soit (mais ça s'améliore depuis qq messages je crois avoir saisi ;))
tu le partage super bien (même si ça ne me sert à rien)
après si tu te braque dès que les commentaires fusent, ça cloche ! on est sur dlfp quand même !
surtout que tu as donné le bâton pour te faire battre, tu parles de conso, de gains peu quantifiables voir tout simplement très faibles et tu coupe court à la discussion tout de suite ?
alors ok on est pas (encore) vendredi mais quand même, faut pas partir comme ça ;)
(en plus, la réponse était intéressante puisque tu expliques que de toute façon tu n'utilise pas de l'ethernet, c'est un point utile car explique facilement qu'un serveur http ne fasse pas l'affaire et aurait surement permis de comprendre plus tôt le but de ton soft si tu l'avais précisé ;))
> Le prix de l'énergie augmente et la moindre économie est importante.
dans ce cas, as-tu fait le rapport entre installer un serveur http et le configurer proprement et le temps passé à développer ton laf, le tester, le configurer, et venir expliquer à quoi ça sert ?
Car si on suit ton raisonnement il y a intérêt que la balance soit dans le bon sens...
ok, mais comment tu veux avoir des commits locaux (branche ou pas) et ne pas avoir de commande pour dire d'envoyer au serveur ?
Et là fin du commentaire ne pose pas de problème, un repo central et tout le monde fait un git clone ce celui-ci, tout le monde push ses branches dessus, donc pas de prob, tu peux le faire avec git.
faudra j'essai, jamais tenté encore
Mais la philosophie est différente, dans le cas d'un rebase on modifie l'historique après coup (ou plutôt non pas l'historique mais ce qu'on va envoyer)
Avec Mq, stg c'est plus une manière de travailler
Au début, j'avais essayé une première fois stg sans trouver à quoi ça servait ni l'intérêt et, pour une raison très merdique (git-svn, pas de merge, que du rebase et du cherry-pick pour moi) je voulais avoir un historique clean lorsque je développe. Donc j'ai retenté stg et là ce fut une révélation !
A tel point que je ne me vois pas trop travailler sans un procédé similaire désormais.
d'où l'intérêt de bosser avec, au choix :
* des outils tels stgit, Mq ou autre
* des branches locales (ou pas) perso qu'on merge ensuite
A lire, on peut croire qu'il ne faut pas qu'il y ait de commit qui ne build pas. En réalité, de moins point de vue, c'est faux. Il ne faut pas de commit qui ne build pas, dans les branches publiques. Dans une branche perso, une branche d'expérimentation, etc ça ne pose pas de problème.
L'avantage des dcvs est justement de permettre en général d'avoir le meilleur des deux mondes ;)
Il est vrai que pour ça j'utilise énormément stgit [http://www.procode.org/stgit/] ce qui fait finalement que je réalise se nettoyage avant de réellement commiter
mais le principe est bien là
En gros, les dcvs ça ne sert pas forcément (le D j'entends) mais les gestionnaires de sources un tant soit peu évolués (basés sur le merge, commit locaux, etc) sont maintenant indispensables pour moi.
Si j'avais l'équivalent sans le côté pleinement distribué je l'utiliserai quand même (bien que le côté distribué soit intéressant, même dans de petites équipes)
en fait, le problème est là : on évite de commiter du code à moitié terminé et on se sépare les tâches pour ne pas tous bosser sur le même fichier en même temps
Déjà, éviter de commiter du code est la pire connerie possible. Souvent ça se termine par quelques cas de figures :
- le code n'est de toute façon pas commité
- ça dure trop longtemps, comme il n'y a pas d'historique c'est galère de savoir ce qui a été fait, refait, défait, etc
- un bug, une tâche ou une demande impromptue arrive, comme c'est pas commité mais qu'on veut pas tout perdre on fait les deux en même temps et c'est la merde
Ensuite, séparer les tâches ok, séparer les fichiers ... c'est juste une limitation de svn, car il n'y a pas besoin, nécessité avec un vrai gestionnaire de source.
Evidemment si tout le monde à sa branche et fait nimp, ça déconnera lors des merges. De l'autre côté, avoir sa branche n'empêche pas de bien séparer son taff donc il n'y a pas de prob normalement (et beaucoup de conflits sont gérés par le dcvs, c'est leur force de se baser sur le merge comme opération de base)
> j'ai vraiment tout faux depuis le début ?
non, point.
Mais il y a beaucoup mieux et productif à faire !
Voir par exemple les liens que j'ai donné plus haut, ça ne parle pas forcément de 1 branche par dev, mais c'est des pistes intéressantes.
Le principe des dcvs c'est en gros : tu commit tout le temps, chaque truc, tu ne perd jamais l'historique, et ensuite tu merge et tu passes à la suite (vu que le merge est simple tu passes pas 3 plombes dessus)
> Perso j'ai une devise : quand on ne sait pas, on ne fait pas.
malheureusement si tout le monde suivait ça, la productivité mondiale baisserait drastiquement...
(en même temps une gui c'est bien mais vu comment ça rame... peut-être que sur de petits code ça tourne, mais sur un vrai bon soft, c'est la merde absolue...)
> quand le paquet sera installé d'office en 10.10.
ha oué, génial ... vachement envie que mon ordi envoie des ping sur un serveur canonical (journalier) alors que j'ai rien demandé (si on prend le cas OEM)
Et après les gens se plaignent de l'iphone ... avec un ping on sait aussi (en général) où la personne se trouve...
> au niveau fonctionnel on est à peu près au même niveau que GIT (bon, le stash/index manque, peut etre 2 3 autres fonctions sympathiques, n'empeche que l'essentiel est là).
oué, enfin sauf les branches locales nommées sous git qui n'existent pas sous mercurial (oui je sais, il y a des extensions mais j'ai jamais retrouvé ce qu'il y a sous git)
Sinon, pour la GUI : le problème c'est que les cas sont nombreux, complexes, donc pour faire un gui propre et complète pour git / mercurial c'est compliqué. Si on rajoute en plus le support d'extensions (dont certains sont indispensables, comme stgit) ça devient le bordel.
Donc, peut-être qu'un jour egit sera potable, pour le moment il ne sert pas à grand chose...
> Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant
toutes mes condoléances
> mon repo est en SVN < 1.4
si en plus tu t'amuse avec des trucs obsolètes ;)
> ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.
ouch !
heu ...
bon courage ;)
Je bosse avec svn + git-svn, autour de moi on a du svn, des branches ... ben c'est déjà pas évident d'envisager une migration git (essentiellement pour les raisons de GUI) donc si les dev n'utilisent pas du tout les branches, c'est po gagné (mais si ça marche je veux bien la recette ;))
As-tu regardé du côté de bazaar ? Les perfs sont assez désastreuses, mais c'est assez bien foutu et pour une migration cvs/svn vers un dcvs c'est très intéressant.
Sur le _principe_ je suis d'accord. Dans les faits, pas totalement.
Déjà, concernant la séparation avec les libs, pourquoi pas, mais en réalité on se retrouve tout de même très souvent à devoir mettre à jour l'un lorsqu'on met à jour l'autre (la séparation est assez rare, tout du moins pour les applis desktop, pour les parties plus basses ça fonctionne mieux). Mais reste que ça c'est pas non plus l'apanage des projets libres.
Ensuite, sur la partie c'est libre donc on papote toussa ... heu, oui mais pas toujours, et surtout on peut papoter tant qu'on veut, lorsqu'une distrib sort avec des softs d'il y a presque un an ben c'est cool mais les dev upstream peuvent faire ce qu'ils veulent c'est la merde.
Et d'ailleurs il y a aussi plétore de softs (plus ou moins important) libre qui sont gérés par un très petit groupe voir une personne et donc qui peuvent faire ceci.
Bon ok, ça fini souvent tôt ou tard en fork, mais pas toujours ;)
Il suffit de regarder l'histoire de nagios, ou un groupe central le gère. S'ils le voulaient, ils pourraient très bien modifier le protocole rapidement, et les autres softs liés auraient probablement du mal à suivre. Mais oui, le côté libre facilite quand même car rien n'empêche de forker et de remettre la compatibilité par exemple, mais c'est lourd.
En fait si je réagissais c'est surtout que ta réponse était inutile.
Le gars t'écris ce qu'il pense avoir compris de ton soft, demande si c'est bien ça et toi ... tu lui dis simplement non (et là tu refais pareil, c'est juste un copié collé de ce que tu as déjà écris).
Lorsque quelqu'un ne comprend pas ce que tu racontes, c'est souvent autant de sa part (il n'a pas bien lu, n'a pas les compétences, etc) que de celui qui a expliqué (mal expliqué car dans son truc, oublis de détails, etc) et c'est ce point que je pointais.
Maintenant, perso je ne suis toujours pas sur d'avoir compris ce que glandouille ton soft, et je pense que le problème vient du fait que tu parles de www-data alors que tu ne l'utilise pas, non ? (en clair désolé mais si certains ont compris de quoi tu parles, c'est loin d'être le cas de tout le monde et loin d'être limpide - en plus d'avoir le sentiment de lire que ce que fait ton soft c'est crade)
Oui, c'est bien pour ça que ça réagissait par rapport à Quand MSN change subrepticement son protocole et donc au fait que ça change sans prévenir.
Evidemment, si les changements sont prévenus à l'avance, si c'est bien fait il y a plus de chance pour que ça passe bien.
Mais encore une fois c'est pas lié au libre, si j'ai un soft proprio de serveur d'IM et que je préviens que je vais changer de protocole, les clients peuvent changer.
Ce qui a du mal à être compris on dirait c'est que je réagissais sur le lien protocole de MSN qui change -> normal c'est MS c'est proprio donc ça pue
D'ailleurs, on voit bien que même dans le libre, même en prévenant ce qui coince, ça ne marche pas non plus -> http://linuxfr.org/comments/1150952.html#1150952
(pour ceux qui ne veulent pas lire, wormux debian est avec une version de protocole incompatible avec les versions actuelles...)
c'est pas le sujet, tu dévies le problème pour conforter ton opinion
Si c'est un protocole standard qui ne change pas alors il n'y a pas de problème lorsqu'il change puisque ça n'arrive pas.
Mais ça on s'en fout dans la discution
Si on a MSN qui change de protocole il faut mettre à jour les clients et ça pue.
Si je fait un soft de IM avec un protocole et qu'il change ... ben c'est pareil, faut mettre les clients à jour et ça pue, le fait que ce soit libre facilite les choses mais ne résout pas le problème.
Si j'utilise par exemple un truc pas standard (pas officiel, un draft ou un truc du genre) pour faire de la vidéo sur jabber par exemple. Imaginons que je l'utilise dans un serveur libre, et un client libre.
Si le serveur change de protocole sans avertir quiconque, ben je suis dans la même merde que si j'avais msn, le temps de mettre à jour le client, et le temps qu'il n'arrivera jamais dans stable.
oué enfin ce serait un projet open source qui changerait de protocole du jour au lendemain ça ne changerait pas grand chose au problème (au mieux ce sera un peu plus facile)
oui c'est multi-plateforme, ça tourne sous mac depuis les premières versions (c'était d'ailleurs le super argument de microsoft pour prouver que ce qu'ils ont fait est multi-plateforme). Maintenant, pour linux c'est une autre histoire...
> Un truc comme ça : http://developer.apple.com/safaridemos/threesixty.php ?
nop ...
ça c'est pas grand chose, là on parle de mélanger des photos faites par des utilisateurs, pas forcément les mêmes, pas avec la même lumière, angle, etc et assembler le tout pour recréer la scène en 3d. On est loin de ça (qui plus est ça rame un peu sur mon chrome...)
Il doit y avoir des vidéos qui trainent, mais c'est loin de cette démo d'apple.
> Streetview est en Flash, mais pas Maps.
oué alors là si on commence à jouer là dessus on va pas aller bien loin.
StreetView fait partie de Maps (c'est même dispo dans les api google maps) et reste que c'est en flash. C'est un composant de Maps.
Donc oui, tu vois la carte basique, mais tu n'as pas tout.
> Reste que c'est encore très lourd et pas franchement optimisé
Qu'est ce qui est très lourd ?
Html5 ? oui
> Flash oui, mais Silverlight n'a justement pas l'air de prendre. Tu as des stats ?
Flash 10 est dans les 97% je crois, silverlight dans les 65%. Je suis pas sur que 65% des utilisateurs soient sous chrome / safari supportant du html5 aujourd'hui.
Et pour les autres sous windows n'ayant pas silverlight, c'est surement car ils n'en ont pas eu besoin car ça s'intalle facilement (comme flash quoi)
en même temps, faudrait se plaindre à novell s'ils annoncent que ça marche alors que non.
Pour l'activeX, l'intégration de google earth dans google maps, elle nécessite aussi un plugin, non ?
> les hiérarchies établies ne laissent pas se développer des idées originales.
en terme de contraintes techniques ok, mais en terme d'idée je trouve au contraire qu'ils font des efforts et bing maps est parfois bien devant google maps (mais il y a silverlight)
[^] # Re: "base de données" ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie de Redis 2.0.0. Évalué à 4.
(désolé ;) )
[^] # Re: Ca existe toujours ça ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Vim 7.3. Évalué à 4.
C'est pour ça que sur mes machines je fais toujours un alias
vi=emacsclient -tCa a toujours son petit effet (outre rendre le système utilisable)
(histoire que le post soit constructif)
et avec emacs en "serveur" et les alias vi, e=emacsclient -c -n c'est immédiat et nikel comme utilisation, à la fois en console et graphique, avec les mêmes fichiers dans les différentes fenêtres. Surement le mieux que j'ai trouvé pour le moment comme ide.
[^] # Re: Heuuu
Posté par CrEv (site web personnel) . En réponse au journal Launch And Forget. Évalué à 3.
ra mais volà, faut pas prendre la mouche tout le temps hein !
tu fais un truc, ok.
on comprend pas vraiment à quoi ça sert, ni comment, ni pourquoi, soit (mais ça s'améliore depuis qq messages je crois avoir saisi ;))
tu le partage super bien (même si ça ne me sert à rien)
après si tu te braque dès que les commentaires fusent, ça cloche ! on est sur dlfp quand même !
surtout que tu as donné le bâton pour te faire battre, tu parles de conso, de gains peu quantifiables voir tout simplement très faibles et tu coupe court à la discussion tout de suite ?
alors ok on est pas (encore) vendredi mais quand même, faut pas partir comme ça ;)
(en plus, la réponse était intéressante puisque tu expliques que de toute façon tu n'utilise pas de l'ethernet, c'est un point utile car explique facilement qu'un serveur http ne fasse pas l'affaire et aurait surement permis de comprendre plus tôt le but de ton soft si tu l'avais précisé ;))
[^] # Re: Heuuu
Posté par CrEv (site web personnel) . En réponse au journal Launch And Forget. Évalué à 2.
dans ce cas, as-tu fait le rapport entre installer un serveur http et le configurer proprement et le temps passé à développer ton laf, le tester, le configurer, et venir expliquer à quoi ça sert ?
Car si on suit ton raisonnement il y a intérêt que la balance soit dans le bon sens...
[^] # Re: plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
Et là fin du commentaire ne pose pas de problème, un repo central et tout le monde fait un git clone ce celui-ci, tout le monde push ses branches dessus, donc pas de prob, tu peux le faire avec git.
Il y a une commande git pour ça !
[^] # Re: plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
Mais la philosophie est différente, dans le cas d'un rebase on modifie l'historique après coup (ou plutôt non pas l'historique mais ce qu'on va envoyer)
Avec Mq, stg c'est plus une manière de travailler
Au début, j'avais essayé une première fois stg sans trouver à quoi ça servait ni l'intérêt et, pour une raison très merdique (git-svn, pas de merge, que du rebase et du cherry-pick pour moi) je voulais avoir un historique clean lorsque je développe. Donc j'ai retenté stg et là ce fut une révélation !
A tel point que je ne me vois pas trop travailler sans un procédé similaire désormais.
[^] # Re: plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
* des outils tels stgit, Mq ou autre
* des branches locales (ou pas) perso qu'on merge ensuite
A lire, on peut croire qu'il ne faut pas qu'il y ait de commit qui ne build pas. En réalité, de moins point de vue, c'est faux. Il ne faut pas de commit qui ne build pas, dans les branches publiques. Dans une branche perso, une branche d'expérimentation, etc ça ne pose pas de problème.
L'avantage des dcvs est justement de permettre en général d'avoir le meilleur des deux mondes ;)
[^] # Re: plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
mais le principe est bien là
En gros, les dcvs ça ne sert pas forcément (le D j'entends) mais les gestionnaires de sources un tant soit peu évolués (basés sur le merge, commit locaux, etc) sont maintenant indispensables pour moi.
Si j'avais l'équivalent sans le côté pleinement distribué je l'utiliserai quand même (bien que le côté distribué soit intéressant, même dans de petites équipes)
[^] # Re: plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 0.
Déjà, éviter de commiter du code est la pire connerie possible. Souvent ça se termine par quelques cas de figures :
- le code n'est de toute façon pas commité
- ça dure trop longtemps, comme il n'y a pas d'historique c'est galère de savoir ce qui a été fait, refait, défait, etc
- un bug, une tâche ou une demande impromptue arrive, comme c'est pas commité mais qu'on veut pas tout perdre on fait les deux en même temps et c'est la merde
Ensuite, séparer les tâches ok, séparer les fichiers ... c'est juste une limitation de svn, car il n'y a pas besoin, nécessité avec un vrai gestionnaire de source.
Evidemment si tout le monde à sa branche et fait nimp, ça déconnera lors des merges. De l'autre côté, avoir sa branche n'empêche pas de bien séparer son taff donc il n'y a pas de prob normalement (et beaucoup de conflits sont gérés par le dcvs, c'est leur force de se baser sur le merge comme opération de base)
> j'ai vraiment tout faux depuis le début ?
non, point.
Mais il y a beaucoup mieux et productif à faire !
Voir par exemple les liens que j'ai donné plus haut, ça ne parle pas forcément de 1 branche par dev, mais c'est des pistes intéressantes.
Le principe des dcvs c'est en gros : tu commit tout le temps, chaque truc, tu ne perd jamais l'historique, et ensuite tu merge et tu passes à la suite (vu que le merge est simple tu passes pas 3 plombes dessus)
[^] # Re: Encore une attaque gratuite sur OVH?
Posté par CrEv (site web personnel) . En réponse au journal Ô vache, v'la le retour du monopole de la poste. Évalué à 6.
malheureusement si tout le monde suivait ça, la productivité mondiale baisserait drastiquement...
[^] # Re: et pourquoi pas bazar ?
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
(en même temps une gui c'est bien mais vu comment ça rame... peut-être que sur de petits code ça tourne, mais sur un vrai bon soft, c'est la merde absolue...)
# plop
Posté par CrEv (site web personnel) . En réponse au journal Ubunteros, Comptez vous !. Évalué à -2.
ha oué, génial ... vachement envie que mon ordi envoie des ping sur un serveur canonical (journalier) alors que j'ai rien demandé (si on prend le cas OEM)
Et après les gens se plaignent de l'iphone ... avec un ping on sait aussi (en général) où la personne se trouve...
# plop
Posté par CrEv (site web personnel) . En réponse au journal Mercurial ou GIT. Évalué à 2.
oué, enfin sauf les branches locales nommées sous git qui n'existent pas sous mercurial (oui je sais, il y a des extensions mais j'ai jamais retrouvé ce qu'il y a sous git)
Sinon, pour la GUI : le problème c'est que les cas sont nombreux, complexes, donc pour faire un gui propre et complète pour git / mercurial c'est compliqué. Si on rajoute en plus le support d'extensions (dont certains sont indispensables, comme stgit) ça devient le bordel.
Donc, peut-être qu'un jour egit sera potable, pour le moment il ne sert pas à grand chose...
> Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant
toutes mes condoléances
> mon repo est en SVN < 1.4
si en plus tu t'amuse avec des trucs obsolètes ;)
> ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.
ouch !
heu ...
bon courage ;)
Je bosse avec svn + git-svn, autour de moi on a du svn, des branches ... ben c'est déjà pas évident d'envisager une migration git (essentiellement pour les raisons de GUI) donc si les dev n'utilisent pas du tout les branches, c'est po gagné (mais si ça marche je veux bien la recette ;))
As-tu regardé du côté de bazaar ? Les perfs sont assez désastreuses, mais c'est assez bien foutu et pour une migration cvs/svn vers un dcvs c'est très intéressant.
Quelques liens pour compléter (et pour relever le niveau de mon message...) :
- Bazaar workflows [http://wiki.bazaar.canonical.com/Workflows]
- A successful git branching model [http://nvie.com/git-model]
- a guide to branching in mercurial [http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)]
- mercurial workflows: branch as needed [http://stevelosh.com/blog/2010/02/mercurial-workflows-branch(...)]
- mercurial workflows: stable & default [http://stevelosh.com/blog/2010/05/mercurial-workflows-stable(...)]
-bonus : [http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/]
[^] # Re: Des mises à jour et du grand public
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à 3.
Déjà, concernant la séparation avec les libs, pourquoi pas, mais en réalité on se retrouve tout de même très souvent à devoir mettre à jour l'un lorsqu'on met à jour l'autre (la séparation est assez rare, tout du moins pour les applis desktop, pour les parties plus basses ça fonctionne mieux). Mais reste que ça c'est pas non plus l'apanage des projets libres.
Ensuite, sur la partie c'est libre donc on papote toussa ... heu, oui mais pas toujours, et surtout on peut papoter tant qu'on veut, lorsqu'une distrib sort avec des softs d'il y a presque un an ben c'est cool mais les dev upstream peuvent faire ce qu'ils veulent c'est la merde.
Et d'ailleurs il y a aussi plétore de softs (plus ou moins important) libre qui sont gérés par un très petit groupe voir une personne et donc qui peuvent faire ceci.
Bon ok, ça fini souvent tôt ou tard en fork, mais pas toujours ;)
Il suffit de regarder l'histoire de nagios, ou un groupe central le gère. S'ils le voulaient, ils pourraient très bien modifier le protocole rapidement, et les autres softs liés auraient probablement du mal à suivre. Mais oui, le côté libre facilite quand même car rien n'empêche de forker et de remettre la compatibilité par exemple, mais c'est lourd.
[^] # Re: Heuuu
Posté par CrEv (site web personnel) . En réponse au journal Launch And Forget. Évalué à 6.
Le gars t'écris ce qu'il pense avoir compris de ton soft, demande si c'est bien ça et toi ... tu lui dis simplement non (et là tu refais pareil, c'est juste un copié collé de ce que tu as déjà écris).
Lorsque quelqu'un ne comprend pas ce que tu racontes, c'est souvent autant de sa part (il n'a pas bien lu, n'a pas les compétences, etc) que de celui qui a expliqué (mal expliqué car dans son truc, oublis de détails, etc) et c'est ce point que je pointais.
Maintenant, perso je ne suis toujours pas sur d'avoir compris ce que glandouille ton soft, et je pense que le problème vient du fait que tu parles de www-data alors que tu ne l'utilise pas, non ? (en clair désolé mais si certains ont compris de quoi tu parles, c'est loin d'être le cas de tout le monde et loin d'être limpide - en plus d'avoir le sentiment de lire que ce que fait ton soft c'est crade)
[^] # Re: Heuuu
Posté par CrEv (site web personnel) . En réponse au journal Launch And Forget. Évalué à 7.
[^] # Re: Venez aider à la sortie de Squeeze !
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à 6.
[^] # Re: Des mises à jour et du grand public
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à 3.
Evidemment, si les changements sont prévenus à l'avance, si c'est bien fait il y a plus de chance pour que ça passe bien.
Mais encore une fois c'est pas lié au libre, si j'ai un soft proprio de serveur d'IM et que je préviens que je vais changer de protocole, les clients peuvent changer.
Ce qui a du mal à être compris on dirait c'est que je réagissais sur le lien protocole de MSN qui change -> normal c'est MS c'est proprio donc ça pue
D'ailleurs, on voit bien que même dans le libre, même en prévenant ce qui coince, ça ne marche pas non plus -> http://linuxfr.org/comments/1150952.html#1150952
(pour ceux qui ne veulent pas lire, wormux debian est avec une version de protocole incompatible avec les versions actuelles...)
[^] # Re: Des mises à jour et du grand public
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à 5.
Si c'est un protocole standard qui ne change pas alors il n'y a pas de problème lorsqu'il change puisque ça n'arrive pas.
Mais ça on s'en fout dans la discution
Si on a MSN qui change de protocole il faut mettre à jour les clients et ça pue.
Si je fait un soft de IM avec un protocole et qu'il change ... ben c'est pareil, faut mettre les clients à jour et ça pue, le fait que ce soit libre facilite les choses mais ne résout pas le problème.
Si j'utilise par exemple un truc pas standard (pas officiel, un draft ou un truc du genre) pour faire de la vidéo sur jabber par exemple. Imaginons que je l'utilise dans un serveur libre, et un client libre.
Si le serveur change de protocole sans avertir quiconque, ben je suis dans la même merde que si j'avais msn, le temps de mettre à jour le client, et le temps qu'il n'arrivera jamais dans stable.
[^] # Re: Des mises à jour et du grand public
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à 5.
[^] # Re: Venez aider à la sortie de Squeeze !
Posté par CrEv (site web personnel) . En réponse à la dépêche Debian Squeeze est gelée. Évalué à -4.
> Bref, moi j'aime bien Debian stable
au moins tu n'es pas perdu, avec la stable tu retrouve un bureau linux des années 2000...
[^] # Re: Your computer isn't supported
Posté par CrEv (site web personnel) . En réponse au journal Bing Does OpenStreetMaps. Évalué à 3.
[^] # Re: Your computer isn't supported
Posté par CrEv (site web personnel) . En réponse au journal Bing Does OpenStreetMaps. Évalué à 2.
[^] # Re: C'est pas nouveau...
Posté par CrEv (site web personnel) . En réponse au journal Bing Does OpenStreetMaps. Évalué à 0.
nop ...
ça c'est pas grand chose, là on parle de mélanger des photos faites par des utilisateurs, pas forcément les mêmes, pas avec la même lumière, angle, etc et assembler le tout pour recréer la scène en 3d. On est loin de ça (qui plus est ça rame un peu sur mon chrome...)
Il doit y avoir des vidéos qui trainent, mais c'est loin de cette démo d'apple.
> Streetview est en Flash, mais pas Maps.
oué alors là si on commence à jouer là dessus on va pas aller bien loin.
StreetView fait partie de Maps (c'est même dispo dans les api google maps) et reste que c'est en flash. C'est un composant de Maps.
Donc oui, tu vois la carte basique, mais tu n'as pas tout.
> Reste que c'est encore très lourd et pas franchement optimisé
Qu'est ce qui est très lourd ?
Html5 ? oui
> Flash oui, mais Silverlight n'a justement pas l'air de prendre. Tu as des stats ?
Flash 10 est dans les 97% je crois, silverlight dans les 65%. Je suis pas sur que 65% des utilisateurs soient sous chrome / safari supportant du html5 aujourd'hui.
Et pour les autres sous windows n'ayant pas silverlight, c'est surement car ils n'en ont pas eu besoin car ça s'intalle facilement (comme flash quoi)
[^] # Re: C'est pas nouveau...
Posté par CrEv (site web personnel) . En réponse au journal Bing Does OpenStreetMaps. Évalué à 3.
Pour l'activeX, l'intégration de google earth dans google maps, elle nécessite aussi un plugin, non ?
> les hiérarchies établies ne laissent pas se développer des idées originales.
en terme de contraintes techniques ok, mais en terme d'idée je trouve au contraire qu'ils font des efforts et bing maps est parfois bien devant google maps (mais il y a silverlight)