CrEv a écrit 4577 commentaires

Je pense qu'il faut le prendre sous la forme d'une expression et non d'une insulte.
Mais cela peut aussi être pris comme un exemple d'utilisation où un smiley aurait pu te faire comprendre que ce n'était pas sérieux.

plussoie-moi.

Malheureux, tu as oublié tes cours de psychologie inversée...

Oué enfin c'est pas comme si free ne donnait pas l'impression de tout faire de cette manière.
Free a de très bon côté, mais celui là n'en fait pas partie. C'est toujours à l'arrache ce qu'ils font.
Et pourtant, ils ont bien réussi à avoir une archi correcte pour leur retransmission.

par contre une fois à la bourre, ils ne pouvaient rien faire d'autre.

Ils ont bien recodé le site dans la nuit (enfin avec plein d'erreurs mais bon)

Et je ne vois pas comment ils ne pouvaient pas s'attendre à un tel afflux...

(note : j'aime bien free, mais parfois ils donnent vraiment le bâton pour se faire battre...)

Vu à quel point ils sont à l'arrache sur le développement de leur offre (les services sont censés s'activer petit à petit) et sur le déploiement du réseau, ça m'étonnerait qu'ils aient eu le temps ne serait-ce qu'à penser à des applis de suivi de conso :-)

Je crois qu'il y a une erreur :

Vu à quel point ils sont à l'arrache, ça m'étonnerait qu'ils aient eu le temps ne serait-ce que de penser.

(oué désolé, mais mettre en place une belle archi pour retransmettre leur conf et ne pas être foutu de consolider le site d'inscription, ne pas être foutu de faire la différence entre une string et un int - genre suppression des 0 au début des valeurs des RIB, etc. La liste est longue quand même...)

Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct

Je suis pas sur de "context switch" mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial. Enfin si, l'écran clignote un peu, et ensuite tu as juste une petite popup qui vient de dire que ton driver a merdé et qu'il a été redémarré (en gros).
Pas d'écran bleu ni de pertes d'applications. Sous X, tout aurait été embarqué avec le driver au final, et tu perds toutes tes applications.

Pourtant c'est l'avenir

Mouai, l'avenir, le passé, ça se mélange beaucoup à ce niveau...
Au mieux on pourrait parler en partie de cycle, mais il y a aussi beaucoup de cas où ce n'est clairement pas l'avenir, en tout cas pas version terminal comme on connaissait.
Entre autre, beaucoup d'ordi portables, notebook, tablettes, smartphones, et ceux là c'est pas des terminaux.
Par contre, c'est en partie des terminaux web + apps connectées, donc c'est un peu des terminaux.

D'ailleurs, parfois la meilleur chose à faire est de recommencer à zéro. C'est, au bout d'un moment, le mieux, le plus efficace.
http://www.inc.com/magazine/201202/jason-fried/starting-over-get-real.html un lien comme un autre, sur le principe de recommencer. Je sais que c'est pas le même domaine, mais au final ça ne change rien.
Lorsqu'un architecture est dépassée, souvent il faut repartir d'une feuille blanche en ce concentrant sur le métier, le fonctionnel, et non tenter de modifier un mastodonte, ce qui ne fonctionner jamais, et il suffit de voir le retard de X dans le domaine pour s'en convaincre.

Alors qu'il eut été si simple de faire X12 compatible X11 avec abandon des trucs inutiles

Tiens, lorsqu'on lit les explications on a plutôt l'impression du contraire : X est trop bordélique à maintenir, personne ne le connait suffisamment bien pour l'améliorer significativement, etc.
Mais non, c'est vrai, ça doit pas être ça, ils le font uniquement pour le plaisir.

Perdez votre temps à réinventer la roue, pendant ce temps vos concurents avancent....

Ha oui, c'est pas comme si X était déjà en retard depuis un moment quand même.

Mais si c'était envisageable de modifier X pour avancer, ne crois-tu pas que ce serait déjà le cas ?

parfois pré-cochée

ça existe encore ? D'ailleurs, c'est pas interdit en France (si on parle de portions légales / contrats) ?

faire s'arrêter les gens pour qu'ils pensent un peu aux conséquences quand ils cliquent sur la case

Justement, si "les gens" ne s'arrêtent déjà pas pour lire les parties légales / contrats, pourquoi s'arrêteraient-ils pour lire ton pavé ? (qui au final d'ailleurs n'explique pas grand de plus que "j'ai lu, j'aime pas, je quitte" sans vraiment dire pourquoi, donc ça parait trop ou pas assez)

Et je m'arrête-là parce que sinon je crois que je vais tartiner ici aussi, à moins que mon clav

Ra mais non, faut pas la manger comme ça, c'est moche quand tu es en train d'écrire et que ton clavier se blo

Il me semble ici que bon nombre ont oublié le vieux dicton "If it works DONT't fix it"

Ben heureusement que beaucoup l'ont oublié.
C'est bien pour un truc critique en prod ça, mais c'est aussi le premier pas vers "ne bougeons pas, jamais !"

Justement non, le libre c'est aussi être capable de continuer à utiliser l'existant même si la boite qui développait le truc disparaissait.

Pourquoi "justement non" ? Les deux approches sont loin d'être incompatibles.

s'il veut s'imposer il doit convaincre

Oué mais faut aussi lire ce qui est écris, entre autre que ça peut embarquer un X par exemple.

J'aimerai aussi savoir comment se comportera une appli sous wayland en mode tilling, ça promet d'être assez laid

Quel est le problème ? Car "laid" ça ne veut rien dire, ni explique le problème qu'il pourrait y avoir.

Si des trucs [...] deviennent impossible sous Wayland

Et pourquoi ce serait-le cas ?
Où est-ce indiqué que ce ne sera pas possible ?
Il est même indiqué que ça embarquera un serveur X.
Il est indiqué que la compatibilité avec X est loin d'être oubliée et évidemment fait partie des préoccupation.
Le problème est là, un truc nouveau arrive, il n'est pas encore fini, et tout de suite on a droit à des "et si [bla bla bla j'en sais rien] alors c'est rien que de la merde"
Ca fait juste preuve d'immobilisme et de peur du changement. Et au final le libre n'est pas mieux qu'ailleurs sur ce sujet, alors qu'il devrait tirer partie de ses avantages, entre autre le fait d'avoir les sources pour pouvoir rendre compatible ce qui existe.

Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus, la résistance à Wayland promet d'être féroce.

Belle démonstration d'immobilisme...
Mais c'est vrai ça, refusons toute évolution.
Ha oui, et surtout, soyons féroce histoire de bien montrer qu'on ne veut pas évoluer.
En général, on appel ça, par exemple, des dinosaures, pas des barbus...

Moi qui croyait que dans le libre, contrairement à beaucoup de "proprio" on était capable de casser des choses lorsqu'elles sont obsolètes / non adaptées / non pertinents / qu'il y a mieux à faire.

(et c'est pas comme si tout était fait sans réfléchir un minimum comment être compatible avec X)

Ça m'a fait sourire de voir la montée en puissance de tes explications.

En général lorsqu'il s'agit de taper un peu sur mercurial je lâche pas trop l'affaire...
Non que je déteste mercurial, mais c'est souvent un second choix (git trop compliqué alors on prend mercurial, mercurial plus proche de svn, windows donc pas git donc mercurial, etc).
Mercurial a de bons points, il est tout de même relativement agréable à utiliser.
Mais il pêche toujours sur certains points, entre autre les subrepos et, surtout, la gestion des branches (et là je préfère, et de loin, git).

Maintenant, je l'utilise tous les jours, sans trop de problèmes particuliers.

il prend le HEAD, ce qui n'est pas forcément une bonne chose quand on veut pouvoir reproduire une version livrée à un client seulement avec le numéro de révision de Main.

Oué mais là c'est un autre problème : on ne livre pas un client avec juste un numéro de version de Main, on livre un client avec une version taguée, ainsi que ces modules. Et comme on a doit à du maven en plus (beurk) ben le tag du projet de base doit permettre de remonter l'ensemble avec les versions mavens (aucun snapshot dans la release).

hum, si je ne me trompe pas il faut un compte Google, et non un compte GMail.
Oui, il y a une différence.
N'importe quel compte mail peut service de compte Google, et donc utilisé pour blogger, docs, etc.

# initialise des répos A et B
$ hg init A && cd A && echo "A" > A.txt && hg ci -A -m "First commit in A" && cd ..
$ hg init B && cd B && echo "B" > B.txt && hg ci -A -m "First commit in B" && cd ..
# un main, qui va contenir mes subrépos
$ hg init main && cd main
# j'ajoute A
$ echo A = ../A > .hgsub
$ hg add .hgsub
$ hg clone ../A A
$ hg ci -m "Add A as a sub repo"
$ cat .hgsubstate
b48cea01eeae6bbb484e6062f8acc6b4924edfa6 A
# j'ajoute B
$ echo B = ../B >> .hgsub
$ hg clone ../B B
$ hg ci -m "Add B as a sub repo"
$ cat .hgsubstate
b48cea01eeae6bbb484e6062f8acc6b4924edfa6 A
de8150c86700e327cc1d4c9819b420b8fbe686dd B
# on clone le tout (histoire de faire comme si c'était distant)
$ cd ..
$ hg clone A cloneA
$ hg clone B cloneB
$ hg clone main cloneMain
# je vais faire un commit dans le clone de A dans mon clone de main
$ cd cloneMain
$ echo plop >> A/A.txt
$ hg st -S
M A/A.txt
$ cd A && hg ci -m "commit A"
$ cd ..
# on pousse, tout est ok, on va bien pousser la modif dans A (le vrai, distant)
$ hg push
pushing to ../main
pushing subrepo A to ../A
searching for changes
adding changesets
adding manifests
addinf file changes
added 1 changesets with 1 changes to 1 files
pushing subrepo B to ../B
searching for changes
no changes found
searching for changes
no changes found
# je vais dans mon clone de A, en dehors de main, et j'ai bien les modifs
$ cd ../cloneA
$ hg pull
pulling from ../A
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
$ hg up
1 files updates, 0 files merged, 0 files removed, 0 files unresolved
# je fais un commit dans mon clone de A et je pousse
$ echo plop >> A.txt
$ hg ci -m "Commit from cloneA"
$ hg push
pushing to ../A
searching for changes
adding changests
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
# je retourne dans mon clone de main : je n'ai aucune modification (normal il n'a pas été commité)
$ cd ../cloneMain
$ hg pull
pulling from ../main
searching for changes
no changes found
# si je vais dans A j'ai bien accès à ma modif
$ cd A
$ hg pull
pulling from ../A
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
$ hg up
1 files updates, 0 files merged, 0 files removed, 0 files unresolved
# en retournant dans le clone main, on voit qu'il y a eu des changements.
# d'ailleurs on voit le changement alors que le fichier est ok (le status
# est donc par rapport à l'état de .hgsubstate)
$ cd ..
$ hg st -S
M A/A.txt
# un commit va me permettre de dire que mon main doit prendre en compte cette
# nouvelle version de A
$ hg ci -m "Update after pull A"
committing subrepository A
# je push, tout est bien commité
$ hg push
pushing to ../main
pushing subrepo A to ../A
searching for changes
no changes found
pushing subrepo B to ../B
searching for changes
no changes found
searching for changes
adding changesets
adding manifests
adding file changes
adding 1 changesets with 1 changes to 1 files
# si je reprend un clone de main, j'aurais bien mes modifs
$ cd ..
$ hg clone main main2
$ cd main2
$ cat A/A.txt
A
plop
plop

Voici donc ce qui me gène :

• le pull n'est pas récursif et c'est lourd. Ok, on peut utiliser onsub mais ça ne me plait guère et ça ne règle pas tout
• tant que je ne suis pas allé dans un clone de main, mis à jour chaque sous répo et commité l'ensemble, quiconque récupérera un clone de main ne sera pas à jour sur A

Ce que je voudrais c'est pouvoir dire dans mon main : tu track A/default dans A. Et donc lorsque je fais un pull tu pull A, de sorte que ce soit toujours à jour.

Après, peut-être que c'est une mauvaise idée, j'en sais rien. Peut-être que c'est un mauvais usage de l'outil, c'est possible aussi. Mais en l'état c'est quand même un peu lourd malheureusement.

• je crée un répo main
• je "référence" deux sous répos A et B
• commit, push, tout va bien

• quelqu'un récupère main

• commit, push, pull, tout va bien

• je clone A tout seul, en dehors de main

• commit

• push

• je clone main ou je pull

• je n'ai pas les changements effectués dans A

Mon super répo est mort.
Pourquoi ? Parce que la révision à fetcher depuis chaque sous répo est dans un fichier .hgsubstate.
Donc lorsqu'on fait un push depuis main, ça met à jour ce fichier. Et lorsqu'on pull / clone on récupère cet état, donc tout va bien.
Mais si un commit est fait entre temps, c'est mort.
Et c'est super chiant de le mettre à jour.

Moi ce que je voudrais c'est un moyen de dire : ici c'est la branche plop du répo A Et si on commit puis pull main, ben on a la bonne révision.

Et franchement, pour ça subrepos c'est pas vraiment utilisable.
Et si en plus on utilise des outils comme eclipse qui ne gèrent pas les subrépos (et donc chaque projet va pusher tout seul dans son coin) ben ça ne sert plus à rien.

Après, j'ai peut-être loupé un truc...

Et surbrepository c'est ultra chiant, car si tu fais un push sur un des répos de ton subrépo, mais en dehors de ton subrépo ... ben tu viens de perdre le lien.
Donc c'est bien uniquement si tu fais les pull/push depuis ton répo principal contenant les sub répos.

Bon, je sais pas si c'est bien clair.
DIsons que j'ai un répo Main où j'ai mis en subrépo les projets A et B.
Si je commit dans A et B et fait les push / pull depuis main, c'est ok.
Si je fais un clone de A, en dehors de main, puis fait un push. Ben mon main ne sera jamais à jour.
Ca perd presque tout l'intérêt quand même...

la volonté de la régie publicitaire a-t-elle été de contourner la volonté de l'utilisateur ?

Pour ça, il faudrait déjà que tu puisses dire ta volonté à la régie. Et en effectuant une requête depuis ton ordinateur vers leur serveur pour afficher de la pub, c'est pas vraiment le bon message qui est envoyé...

une raison pour justifier l'utilisation des "trous" des applications...

Mais quel trou ?
Une iframe c'est tout ce qu'il y a de standard. Et poser un cookie aussi.
C'est juste que tu as eu, l'espace d'un moment, une illusion apportée par une option de paramétrage de ton navigateur.

devrait te faire comprendre

Merci de supposer de ce que je connais ou non...

Ok, c'était peut-être mal exprimé, mais rebase ou mq, dans les deux cas l'un des objectifs est d'avoir un historique linéaire.

Non, il y a là une grosse différence.
Là où tu dis que tu ne veux pas de cookies tiers, c'est au niveau de ton navigateur. Mais c'est pas une information qui est communiquée aux sites (ou plutôt de manière incomplète).
Surtout que là, tu fais passer les sites pour quelqu'un qui réalise une effraction. Mais c'est pas le cas du tout.
Surtout qu'il faut bien comprendre un point : en visitant un site, qui lui va afficher une pub, au final tu as visité les adresses de la pub. Donc c'est une communication initiée par ton navigateur (même si non souhaitée par toi). La pub ne rentre pas toute seule sur ton navigateur, en quelque sorte tu lui as dit de venir. Après, on te fais croire qu'il y a une option qui permet de dire "rentres si tu veux mais laisse tes chaussures à l'entrée" ... sauf que cette option ne couvre pas tous les cas.
Rien ne dit que le cookie posé par une iframe ne devrait pas être là. Donc il arrive.

Ou alors simplement que si ton fichier fais quelques giga c'est quand même plus lourd de se déplacer dedans, non ?

Ben franchement, je ne me vois pas bosser sous mercurial sans rebase ou mq (sachant qu'au final avec mq on fait du rebase en gros).
Le rebase est vraiment pour moi une fonctionnalité indispensable. Le problème sans est qu'on se retrouve constamment, lorsqu'on bosse à plusieurs, avec des merge inutiles, juste là au moment où on se synchronise avec le taff des autres.
Je me souviens d'un post de Torvalds (faudrait que j'arrive à remettre la main dessus) qui expliquait à quelqu'un proposant un patch que son historique était tout pourri, bourré de merge inutiles. Avec un rebase, beaucoup moins de problèmes.
C'est pas parce que le merge fonctionne qu'on doit l'utiliser n'importe comment. Et, pour moi en tout cas, l'historique est vraiment très important, sa propreté et sa logique aussi.

http://lmgtfy.com/?q=git+rebase&l=1

Je reproche à Google, et aux autres régies utilisant ce système, d'outrepasser mon choix (ou celui fait par défaut par mon navigateur) de ne pas avoir de cookie tiers. Je ne veux pas de cookie tiers, mais ils font croire à mon navigateur que j'en ai voulu un.

Dans ce cas il faut peut-être reprocher aux navigateurs de te proposer un choix (ne pas vouloir de cookie tiers) alors qu'ils ne sont pas capable de le faire.
Car c'est bien là finalement le problème. L'iframe étant une solution pour placer des cookies tiers, le choix de bloquer les cookies tiers devrait s'y appliquer aussi (par rapport au parent de l'iframe).

Mais pourquoi ?
En général quasiment aucun système ne s'utilise avec un login non sensible à la casse.
Pourquoi donc le faire ?