shbrol a écrit 519 commentaires

on est bien d'accord qu'ici on parle d'indépendance intellectuelle, pas d'indépendance financière, n'est ce pas ?

merci pour la syntaxe "<<\EOF patch", je connaissais pas, je gardes ça précieusement dans un coin.

Pour moi, il s'agit là d'un toponyme qui n'est pas français, et qui doit donc être prononcé selon la langue locale.

Ahem… juste de l'autre coté de la frontière, je te propose Hirmentaz, et un peu plus loin La Giettaz, qui obéissent exactement aux mêmes règles de prononciation locales. Et la Haute-Savoie, c'est officiellement en France, même si c'est récent.

Après, tu as le droit de prononcer comme tu veux, mais les locaux ont aussi le droit de te prendre pour un touriste, avec tous les désagréments que ça peut comporter.

il suffit de rajouter 'ssh this-ubook' devant la commande pour l'exécuter a distance, pas vraiment de différence de ce point de vue.

Simple, clair et précis. Je vais garder ça précieusement.
Merci beaucoup !

Ah, tu trouve que je pinaille déja, alors que je n'ai pas commencé…
Bon, j'y vais : POWERPC (tout en majuscule) et ça n'existe pas, c'est POWER ou PowerPC.

Dans ton message initial tu as dit:

Combien de temps l'architecture Power va survivre ?

Sans plus d'information de contexte, donc on ne sait pas si tu parles de POWER ou de PowerPC, parce que Power ca n'existe pas non plus.

Apres Zenitram a enchainé:

Apple s'est barré de Power

Et la c'est clair qu'il s'agit de PowerPC puisqu'il cite Apple.

Mais bon, je comprends que ça t'agace que je relève des imprécisions dans un message qui commence par "Je pense que tu es très mal renseigné."

1) Tout d'abord laisse moi te rappeler que le PowerPC, au départ, est une alliance entre : IBM / Motorola / Apple. Pas uniquement IBM.

Le POWER, au départ, c'est une architecture uniquement IBM tout seul. Ensuite vient PowerPC, avec Apple et Motorola.
(cf la page wikipedia que tu as donnée).

l'exemple montre comment se servir des shared_lock qui te permettent d'utiliser le RAII avec des mutexes. Ca permet d'eviter les problemes en cas d'exception dans le corps de la fonction, et hop on oublie le unlock()…
Et il montre aussi comment 'upgrader' un shared_lock, c'est a dire passer de shared/reader à exclusive/writer, et ceci sans unlock() au milieu (tu n'en a pas forcément besoin maintenant, mais ca va peut etre venir).
A premiere vue, tout ce qui est utilisé dans l'exemple stackoverflow utilise la norme.

Il y a de fortes chances que l'API proposée par boost soit la même que celle du futur standard.

D'apres http://en.cppreference.com/w/cpp/thread/shared_mutex, ce n'est pas dans c++11, mais c'est prévu pour c++14.

Par contre, ca existe déja chez boost il me semble.

Rhaa, c'est malin ça ! Faire la mise en prod du 'dredi le 'eudi, pour éviter le mauvais sort… bravo !

… ah, chouette, une mise en prod le 'dredi ! Vivement demain !

La même chose, indépendante du mirroir choisi, et en précisant la version suivie :

Package: *
Pin: release o=Unofficial Multimedia Packages, a=testing
Pin-Priority: 50

You are doing harm to Debian users, and it is not appreciated.

Quand on arrive a ce point dans la discussion, on peut se demander si le probleme c'est pas plutôt ces cochons d'utilisateurs, qui continuent à prendre leurs paquets multimedia chez Christian plûtot que dans les dépots officiels, avec tout le mal qu'on se donne pour eux…

En tout cas vous savez ce qu'il vous reste à faire si le dépôt debian-multimedia.org traine encore dans votre /etc/apt/sources.list.

Ca fait quand meme un moment que le dépot "debian-multimedia.org" ne répond plus, il a été remplacé par "deb-multimedia.org". Je cite la page du dépot:

10/05/2012 :
New domain name deb-multimedia.org
You must edit your /etc/apt/sources.list to replaces the old repository name by the new one.

01/11/2012 :
I started to remove suite from debian-multimedia.org
The first suite is stable and experimental then testing in september (done 03/09) and unstable in november (done 01/11).
Of course people should move to the new domain name right now.

donc les utilisateurs habituels, qui font des mises a jour régulières, se sont déja rendu compte du changement de domaine et ont modifié leur configuration. Evidemment, il y a un risque pour la machine qui sort de six mois d'hibernation dans un placard, qu'on met à jour sans précautions, et qui va contacter notre ami ukrainien… lequel n'a encore rien mis en ligne pour l'instant. Bref…

Pour alimenter le troll: oui, les logiciels qui n'etaient présents que chez Christian sont petit à petit apparus chez Debian, ce qui fait dire à certains qu'il pourrait y avoir redondance. Mais si on veut des version récentes, le choix est vite vu:

XBMC sur les dépots officiels :

• stable: 2:11.0~git20120510.82388d5-1+b1
• testing: 2:11.0~git20120510.82388d5-1+b1
• unstable: 2:11.0~git20120510.82388d5-1+b1
• experimental: 2:12.0~git20130127.fb595f2-1

XBMC sur deb-multimedia.org :

• stable: 4:12.2-dmo2.wheezy1
• testing: 4:12.2-dmo2
• sid: 4:12.2-dmo2

Personnellement, je préfère les releases officielles, mais vous faites comme vous voulez.

Le générique de « Il était une fois l'homme » où l'on voit ces mecs se faire cramer par la fusée qui décolle à la fin.

… et la terre qui explose.

Mais aussi :

• Le générique de fin du prisonnier, avec la tête du n°6 qui grossit au dessus d'une vue du village, et des barreaux qui se referment

Merci pour la dénonciation des plugins fautifs, je vais regarder de plus près à quoi ils servent : le cache, je ne sais pas, les derniers ajouts dommage c'était sympa, et c'est idiot si ça bouffe du CPU en permanence.

Pour les DirtyRegions, j'avait déja modifié la config pour la 11, je vais vérifier les changements apportés par la 12.

Mmh… interessant. Peux tu donner un peu plus de détails sur les plugins à désactiver pour optimiser l'utilisation CPU ?

Lucrèce, pas Lutèce…

J'ai sous les yeux des CV de candidats stagiaires Master 2 MIAGE. Visiblement, l'enseignement de l'Ada est toujours d'actualité.

Je préfèrerais voir mes impôts partir dans un programme de financement d'ordinateur+internet pour les démunis, là ça servirait à quelque chose.

Oui, ça servira au moins à enrichir le vendeur d'ordinateur et le fournisseur d'accès.

Et puis on appellerait ça le "Plan informatique pour tous"… mais on me dit dans l'oreillette que ceci a déjà été fait, avec le succès que l'on connait.

Le mot important dans la phrase, c'est "correct", dans le sens "correct pour la norme C". Dans le texte original, ca doit être "well formed".

Bref, ça n'empêche pas d'écrire et compiler les programmes auxquels tu penses. Ces programmes vont répondre au besoin (peut-être), tourner indéfiniment (sauf bug), donc fonctionner correctement du point de vue de l'utilisateur. Par contre, du point de vue de la norme, il n'est pas "bien formé", parce qu'il ne se termine pas.

Heu, attends… tu veux dire qu'on pourrait acheter tout ça en une seule fois, sur un même support physique, ce qui veut dire que le marchand va renoncer à te vendre ça à la découpe, petit à petit, en encaissant à chaque fois ?
Alors, il ne faut surtout pas espérer que ce paquet tout-en-un soit au prix habituel où tu trouves une seule version par support physique. Ca sera plutôt le prix habituel, multiplié par le nombre de versions présentes (et il y aura des clients pour ça…)

La vérité, c'est que tout le monde sait que ça s'appelle une panosse.

Oui, j'ai bien compris le probleme que pose le masquage des extensions, c'est la réponse proposée qui m'intrigue : puisque l'utilisateur ne pourra pas distinguer 'foo.c' et 'foo.o' sans les extensions (2x 'foo'), alors le système devrait interdire des fichiers qui ne diffèrent que par l'extension.
Ca règle le probleme de l'utilisateur, qui verra maintenant 'foo.c' et 'bar.o' affichés sous la forme 'foo' et 'bar'. Par contre, il faudra aussi expliquer cette nouvelle règle à messieurs Makefile et associés, ca va ête croustillant.
C'est quand même plus simple si on affiche le nom complet du fichier, avec son extension, non ?
(en gros, cacher les extension, c'était créer un problème là ou il n'y en avait pas…)