arnaudus a écrit 5528 commentaires

Euh, je n'y connais pas grand chose dans le domaine, mais j'ai l'impression que l'actionnaire récupère sa mise en dernier, au contraire (c'est à dire, dans les faits, rien du tout). Il faudrait que les actifs soient énormes pour éponger les dettes et laisser quelque chose en plus, et si c'était le cas, l'entreprise aurait pu trouver des créanciers pour leur avancer de la trésorerie, non? (puisque les créanciers auraient eu des garanties).

Ils n'ont pas pu trouver en France de fonds suffisants pour rester indépendants

C'est une ligne de défense un peu étrange qu'on lit souvent de la part des entreprises qui sont en train de mourir. Pour moi, c'est le même argument que le mec qui veut qu'on lui prête encore 1000€ pour qu'il se refasse au casino, et qui attribue sa perte de 100000€ à l'enfoiré qui n'a pas voulu lui prêter les 1000€.

C'est super facile d'investir avec le pognon des autres. C'est aussi facile d'accuser les autres quand on ne sait pas ramener du cash.

Sur un plan purement rationnel, un investisseur n'a en général aucun intérêt à laisser couler une boite dont il est actionnaire. S'il ne veut plus remettre du pognon, c'est qu'il considère que la situation est foutue et qu'il ne reverra jamais son investissement initial. Bien sûr, il peut se tromper, mais il n'a aucune raison de le faire volontairement.

Ces application évoluent rapidement et doivent être très fréquemment mises à jour pour corriger des failles de sécurité.

Là je suis un peu paumé. N'est-ce pas l'intérêt majeur d'un système de paquets que de faire reposer la veille technologique et l'intégration des patches au mainteneur du paquet?

Mouais, je trouve quand même ça déplacé de faire ça devant tout le monde. Il peut très bien lui dire ce qu'il pense en mail privé, et officiellement dire qu'il s'est expliqué avec Andrew et qu'ils s'étaient assurés que ce genre de choses n'arriveraient plus.

Honnêtement, je ne trouve pas ça digne d'un chef, de dénoncer nommément les responsables de conneries. C'est des méthodes de management à la Cyril Hanouna, c'est ça? Si une telle chose a pu arriver, c'est à cause d'un problème d'organisation, puisque le système est censé être fait pour que ça n'arrive pas. Peut-être qu'Andrew a fait comme Linus, qu'il a laissé passé un truc dans l'urgence sans le voir.

j'avais des attentes bien plus grandes de choses pouvant venir de la part d'Andrew.

Dites donc, l'ambiance est toujours autant au beau fixe…

Non, je crois que ça ne marche pas du tout. En termes de droit d'auteur, tu ne transmets absolument rien au destinataire, ça reste ta lettre, tu lui donnes le droit de la lire, et c'est tout. Quand tu reçois un CD d'installation d'Ubuntu par la Poste, tu crois que tu récupères les droits d'auteur dessus? C'est absurde.

Si j'ai bien compris le texte de Maitre Eolas, le problème est que beaucoup de gens ne comprennent pas ce qu'est le secret de la correspondance. Le secret de la correspondance, ça protège l'auteur et le destinaire d'un courrier dans le sens où les intermédiaires n'ont pas le droit de l'ouvrir pour le lire. Ça n'empêche absolument pas le destinataire de le lire (ce qui est quand même implicite quand tu envoies un courrier) ni d'en faire usage comme il le souhaite (par exemple, en dévoiler le contenu ou en parler à qui on veut). Bref, c'est exactement la même chose que pour une conversation privée : si quelqu'un te confie un secret, tu as le droit d'en parler à tout le monde ou de le dévoiler dans les journaux (tant qu'il n'y a pas de diffammation) ; c'est impoli mais ça n'est pas illégal. La seule limite, c'est le respect du droit d'auteur, puisque tu n'as pas les droits pour diffuser une œuvre de l'esprit (mais c'est pareil que si on te récite un poëme ou qu'on te chante une chanson originale par téléphone). Ceci étant dit, s'il s'agit d'un SMS ou d'une info succinte, difficile de faire valoir son statut d'œuvre de l'esprit…

Bref, quand tu envoies une lettre à quelqu'un, c'est exactement comme quand tu racontes quelque chose à quelqu'un : il est libre de le raconter à qui il veut, la seule manière de protéger une information est de ne pas la dévoiler à n'importe qui. Après, ça peut être malvenu, impoli, mal élevé, ou relever de la goujaterie de dévoiler le contenu d'une correspondance privée, mais il n'est pas illégal d'être un goujat…

La théorie veut que le sérif trace une ligne de base qui facilite la lecture sur papier. De fait, c'est un peu dur à dire si ça fait une différence, parce qu'il y a très peu de bouquins en sans serif. Par contre, du fait de la résolution limitée des écrans, le sans serif est censé moins baver et ne pas mettre l'anti-aliasing à l'agonie.

Mais bon, si la seule critique typographique qu'on pouvait faire aux gens qui produisent des documents sous traitement de texte étaient le choix des polices serif/sans, ça serait miraculeux.

Pas style de titre souligné?

Encore heureux, c'est typographiquement hideux. D'une manière générale, le souligné n'existe pas en typographie. Tu ouvres n'importe quel livre composé par un professionnel, et tu n'as jamais de style souligné.

Le corps de texte en serif et les titres en sans serif

C'est pourtant une mise en forme assez standard. Je viens de vérifier sur ma pile de livres sur mon bureau (bouquins scientifiques), et sur 7 livres, j'en ai 3 en serif/serif, 3 en sans serif pour les headers /serif pour le texte, et un tout mélangé (texte en serif, titres de sections en sans serif, titres de chapitres en serif, et hauts/pieds de pages en sans serif). Pourtant ce dernier date de 1970 et sort de chez Harper & Row, donc a priori des gens qui savaient composer un bouquin.

Du coup, j'aurais tendance à penser que les titres en sans serif gras et le corps du texte en serif, pour un choix par défaut, ça n'est pas délirant.

N'importe qui peut utiliser le logiciel, mais n'importe qui ne peut pas le développer

Ça a toujours été comme ça. Personne n'est obligé d'accepter tes patchs, ni même d'argumenter pour expliquer pourquoi tes patchs ou tes rapports de bugs sont ignorés. En fait j'ai l'impression que tu ne sais pas trop comment fonctionnent les différentes communautés, certaines sont très ouvertes, certaines sont très fermées, et pour certains logiciels il n'y a même pas de communauté.

Dans tous les cas, tu es libre de développer, et si tu n'es pas content, tu forkes. Et si tu ne veux pas forker, tu n'envoies plus tes correctifs si tu n'es pas content.

C'est pas trop ma vision du libre.

Ta vision du libre, tu peux l'imposer dans le fonctionnement de la communauté qui s'est formée autour du logiciel que tu développes, et c'est déja bien. Avec une telle vision, tu devrais attirer des milliers de contributeurs dégoûtés de l'ambiance pourrie des autres communautés. Y'a plus qu'à.

Et au final, ça fait partie des petits trucs qui donnent l’impression que le noyau Linux est club de mecs et aide pas à se sentir à l’aise là-bas.

Tu sembles partir du principe que tous les mecs se sentiraient à l'aise là-bas, et ça n'est pas du tout le cas. Le kernel est un endroit où ça fritte, c'est une sorte de vestiaire de rugby, les mecs se mettent des grands coups de serviette mouillées et vont dans des bars à putes après les matchs. C'est tolérable parce que ça n'est pas une obligation d'aimer cette ambiance, on peut même apprécier le rugby en tant que spectateur sans pour autant imaginer aimer l'ambiance des vestiaires. S'il leur faut ça pour gagner, alors je ne vois pas vraiment le problème. Bien sûr, tu pourrais dire par exemple qu'il pourrait y avoir de bons joueurs de rugby qui ne boivent pas ou qui sont homos, et qu'ils se détournent de ce sport parce qu'ils ne supportent pas l'ambiance. C'est très certainement vrai, mais est-ce qu'un monde complètement lisse est aseptisé est réellement souhaitable? Les machos vulgaires, ça existe, et c'est très dur de les changer ; s'ils jouent bien au rugby ou contribuent au meilleur OS du marché, est-ce que ça ne revient pas à leur donner un rôle social où ils sont utiles?

Après tout, le logiciel libre c'est surtout une histoire d'initiative, et ceux qui ont le pouvoir, c'est ceux qui se sortent les doigts du cul. Torvald a créé autour de lui une communauté à son image, il a tout monté tout seul, grâce à son énergie et sa compétence indiscutée, à la fois (ce qui est très rare) sur le plan technique et sur le plan humain (oui, parce qu'étrangement, il y a des gens qui sont particulièrement motivés par les ambiances de compétition). Si j'étais big boss du noyau, ça n'est pas du tout comme ça que ça fonctionnerait. Mais le big boss du noyau, c'est Linus, et moi je suis le boss de mes propres fesses (et c'est déja pas mal).

Si tu trouves que certains débiles essayent de reproduire cette ambiance dans leur petits projets où deux contributeurs se battent en duel, c'est probablement vrai, et c'est un peu pathétique. Mais on s'en fout, des minables, il y en a partout, et ça n'a jamais empêché le monde de tourner.

Je suis certain qu'il est possible de monter des communautés de développeurs autour de grands projets libres en imposant une culture différente. Il suffit que les gens qui montent le projet aient la volonté d'imposer une ambiance de travail différente, et surtout qu'ils fassent en sorte que ça soit efficace et que les contributeurs soient compétents. On ne peut pas dire que le libre manque de grands chantiers : client email moderne, traitement de données multimédia, plateformes de développement, traitements de texte de nouvelle génération, jeux, IA… tant de choses à faire. Y'a plus qu'à faire ce qu'on veut de la manière dont on voudrait qu'elles soient faites.

Au passage, ça pourrait être intéressant d'avoir le point de vue de développeuses qui apprécient l'ambiance "kernel". Je trouve ça assez caricatural finalement d'imaginer que tous les mecs aiment se faire rabrouer et que toutes les filles sont des choses fragiles à qui il faut parler en douceur.

Beaucoup de gens sont rétribués pour des tâches communes. Les élus, par exemple. Les enseignants, les chercheurs aussi. Bref, l'État finance pas mal d'activités non-lucratives et paye des gens pour ça.

Même les boîtes privées financent des tâches communes (syndicats interprofessionnels, comités de normalisation, organisations diverses et variées, plus ou moins éthiques ou morales). Dans une certaine mesure, beaucoup de contributeurs aux logiciels libres sont payés pour ça (il n'y a qu'à voir le poids des professionnels dans les contributeurs du kernel…).

Ça peut prendre du temps et beaucoup d'énergie pour convaincre un État de financer une tâche collective, mais ça n'est pas impossible. Par contre, il faut un minimum d'organisation, et de bonnes raisons. Parce qu'il ne faut pas non plus imaginer qu'on va toucher son chèque parce qu'on bricole du code libre dans son garage…

en droit français du moins — ce n’est pas obligatoire.

Pour le réutiliser dans le cadre d'une correspondance privée, peut-être pas, mais pour le publier, on tombe sous le coup du code de la propriété intellectuelle avec tout ce qui va avec (après, tout dépend du contenu de la correspondance. Il faut que ça soit une œuvre de l'esprit).

Ah oui, mais on parle du moteur de recherche, là, pas de l'email. Ça n'est pas tout à fait pareil, parce que le moteur de recherche, on lui donne les infos volontairement. On peut aussi aller trifouiller dans les options de confidentialité de Google pour lui demander de ne pas garder l'historique, je crois (après, je ne sais pas s'il le fait vraiment). La différence avec Gmail, c'est qu'on ne transmet pas volontairement un email à Google, on le transmet à un correspondant.

Mais sur le fond, je suis d'accord, les requêtes dans un moteur de recherche peuvent être beaucoup plus informatives et beaucoup plus intimes que les emails. Google sait avant tout le monde (et parfois même avant toi!) si tu es malade, si tu es enceinte, si tu t'es fait virer, si tu cherches à mettre ton fric aux Caïman, si tu aimes les photos de nains nus, si tu montes une entreprise ou si tu cherches un avocat spécialisé dans le divorce. D'un autre côté, c'est quand même plus facile de rendre ces requêtes non-nominatives si on le souhaite ; je ne suis pas certain que l'historique soit conservé si longtemps que ça (ne serait-ce que pour des raisons de stockage --- 1000 milliards de requêtes par an, ça ne fait pas tant que ça, remarque, quelques Po par an peut-être).

Après, c'est la même chose pour tout tiers de "confiance" : ta banque, ton FAI, la sécu, ton employeur, ou la RATP on des données très personnelles sur toi et les membres de ta famille. J'imagine (peut-être naïvement) qu'elles sont relativement bien protégées des intrusions extérieures chez Google comparé à ces derniers.

En fait, le problème est que personne ne semble souhaiter identifier le problème précisément. On parle de problème de vie privée ou de libertés individuelles, mais sans plus de précisions, on ne peut pas parler de solutions. Qu'est-ce qui pose problème avant tout?

1) que les emails passent par un état déchiffré avant d'être affichés sur l'écran? Mais dans ce cas, est-ce qu'on met les filtres anti-spam dans le problème? Est-ce qu'on n'autorise que le client mail à filtrer les spams, tagguer les pubs, avertir en cas de tentative de hameçonnage?

2) que les emails puissent être analysés par des algorithmes. Ceci dit, ça pose le même problème que les filtres anti-spam, et avec le développement inévitable de l'IA, les algorithmes vont de mieux en mieux comprendre ce qu'on raconte. Est-ce que des tags "personnel", "urgent", "interne", "nouveau client" ajoutés par un algo poseraient des problèmes de confidentialité?

3) que les emails puissent être interceptés par autre chose que le serveur de destination. C'est un problème, mais ça ne résoud pas le cas des webmails populaires.

4) que les emails puissent être analysés à des fins commerciales. Autrement dit, si Google veut faire des études scientifiques sur les évolutions du vocabulaire ou la longueur des phrases, OK, mais si c'est pour afficher de la pub, pas d'accord.

5) que les emails puissent être accessibles à des prestataires privés

6) que les emails puissent être accessibles à des services gouvernementaux

7) que les emails puissent être lus par des êtres humains.

8) que les emails puissent être lus par des êtres humains à des fins illégitimes, illégales, ou non-éthiques.

On peut ajouter autant de niveaux supplémentaires qu'on souhaite. Et en fonction de ce qu'on souhaite, on peut discuter des solutions, et on peut même discuter de l'existence du problème—et du niveau de fantasmes qu'il y a dans la présentation d'un grand problème qui n'est jamais réellement explicité.

Au final, on parle aussi beaucoup de problèmes potentiels, mais pas de problèmes réels. Si on désactive adBlock, on peut voir les publicités proposées par gmail. C'est une bonne expérience, parce qu'on peut réellement s'apercevoir à quel point les algorithmes ne comprennent rien. "J'ai changé le bébé, il n'y a plus qu'une couche, il faut en racheter" -> Dulux Valentine; "Le frigo est vide" -> Darty, etc. Imaginer que Google connait tout de votre vie est réellement de l'ordre du fantasme, Google a en effet les données qui permettrait de vous connaitre si un être humain passait suffisamment de temps à lire et analyser vos mails, mais les algos n'attrappent que quelques mot-clés, ne semblent avoir aucune mémoire ni aucunes capacités analytiques. Ou s'ils les ont, ils ne les utilisent pas pour cibler les pubs. Ou bien s'ils détectent un esprit critique ils font exprès de vous mettre des pubs idiotes pour vous faire croire qu'ils sont incapables de tout savoir sur vous. Ou alors ils s'en foutent réellement de votre vie.

Concernant sort, là tu bloques sur l'écriture OO mainstream on dirait.

Bah non, ma compréhension du problème est que la généricité de la fonction sort() impose l'utilisation d'itérateurs uniquement parce que les containers de la STL n'héritent pas d'une interface commune.

L'écriture qui est sympa c'est sort(v) pourquoi est-ce que cela devrait être v.sort()?

L'intuition est peut-être la chose au monde la moins partagée, mais pour moi les signatures "intuitives" de ces deux fonctions devraient être

std::vector<T> sort(const std::vector<T> &);
void vector<t>::sort();

Je trouve très surprenant en général que y = f(x) puisse modifier x, et les compilos récents n'ont aucun mal à optimiser v = sort(v) correctement. Ceci dit, j'ai peut-être tendance à tenter de retrouver en C++ des concepts qui viennent des langages de plus haut niveau.

elle va supporter l'écriture vi |= action::sort | action::unique;

On peut voter quelque part pour le support du Brainfuck dans C++19?

Je veux un tableau dans une classe concrète? std::vector<>. C'est générique et je m'en sers.

J'ai l'impression qu'on ne se comprend pas, et au bout d'un moment ça tourne en rond. Je pense que personne ici ne parle de ne pas utiliser les conteneurs de la STL ; utiliser la STL n'a pas grand chose à voir avec la programmation générique.

La question (telle que je la comprend), c'est de choisir entre

struct EtatCivil {
   string nom;
   string prenom;
};

et

template<typename n, typename p>
struct EtatCivil {
    n nom;
    p prenom;
};

comme paradigme de base. Sans aller jusqu'à prétendre qu'il faut 100% de l'un ou de l'autre, mon argument c'est que la plupart des problèmes ont une solution avec l'un ou l'autre, et que comme les deux sont très difficilement fongibles, on va orienter l'ensemble de l'architecture du programme dans un sens.

Je veux trier un tableau ? std::sort()

Je pense que c'est un excellent exemple. C'est générique? OK. Mais l'ergonomie est dégueulasse, parce que tu as oublié que ça s'utilisait comme ça : std::sort(v.begin(), v.end());. Évidemment, à force de voir ça, on est habitué, mais tu ne trouves pas que v.sort() serait bien plus élégant? Il permettrait aussi le polymorphisme si tous les containers dérivaient d'une interface STL_cont. Bref, la programmation générique pour la bibliothèque standard, c'est un choix technique, mais ça me semble assez excessif de prétendre que c'est pratique et ergonomique ; d'une manière générale, la STL est relativement imbittable, les syntaxes sont contre-intuitives, et le code est assez illisible.

je sais ne pas pouvoir vouloir d'un T ITruc::operator non plus—oui, de connaitre la limitation, ça oriente fortement ce que je m'autorise à vouloir faire.

Oui, donc dans les faits si tu ne veux pas utiliser le polymorphisme, bah la programmation à base de templates ne te pose pas de problème :-) Encore une fois, mon point de vue n'est pas de dire que la programmation générique c'est pourri, c'est de dire que le C++ OO et le C++ générique (au sens de templates non triviaux sur des objets complexes) sont philosophiquement et techniquement incompatibles. On peut concevoir tout un projet en C++ OO ou en C++ générique, mais ça va fortement conditionner le sous-ensemble du C++ et les designs qu'on va utiliser.

Bien sûr, on peut écrire des trucs hybrides, ça va compiler, et ça va faire d'excellents exercices pour les gens qui aiment se prendre la tête. La question, c'est plutôt "est-ce que des projets réels vont utiliser ça"?

PS: Truc peut tout à fait hériter de ITruc ou de TrucImpl. C'est même assez classique quand on veut combiner une variabilité dynamique avec une statique.

C'est super bancal comme solution, parce que ça demande une surcouche, et que l'interface n'est pas templatée. Prenins un exemple trivial : je veux faire un vecteur de vecteurs de différents types. On peut bien créer quelque chose comme vector<MyVec*> avec des MyvecT<T> qui dérivent d'une classe MyVec, mais à ma connaissance on ne peut pas avoir une méthode MyVec::at(size_t i) const qui retourne le bon type (*).

Si la programmation générique était fongible avec la POO, alors le langage devrait assimiler un template à une interface, et autoriser des choses comme vector * v; qui se comporteraient comme des pointeurs vers des classes virtuelles pures. Je ne sais pas si c'est pour des raisons techniques ou philosophiques que le C++ a choisi des syntaxes incompatibles, mais je ne vois pas comment on peut l'interpréter autrement que par la volonté de définir deux dialectes qui ne sont pas destinés à cohabiter dans le même code.

(*) Enfin si, je crois qu'on peut si la méthode retourne un void* qu'on peut caster avec un typename qu'on aurait défini dans Myvec<T>. Je ne sais pas s'il existe une personne sur terre qui pourrait croire que c'est une bonne idée.

Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires.

Et du coup, il faut combien de décennies d'apprentissage avant de savoir choisir le bon paradigme?

pour gérer la mémoire, par défaut je vais utiliser des unique_ptr<> qui sont génériques.

Je pense que personne ne considère qu'utiliser les conteneurs de la STL revient à faire de la programmation générique.

Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué

Je n'aime pas le fenouil braisé. Est-ce que ça veut dire que j'ai peur du fenouil braisé? Est-ce légitime de m'expliquer que la seule raison pour laquelle je n'aime pas le fenouil braisé est que je n'y suis pas habitué? Au bout d'un moment, c'est agaçant.

Reste que ce ne sont pas des paradigmes opposés.

Si, parce qu'ils sont incompatibles, et qu'ils répondent tous les deux au même besoin de base (utiliser le même code pour appliquer les mêmes opérations à des objets différents qui partagent un certain nombre de propriétés). Si on va au-delà des simples conteneurs style STL, on se retrouve avec des possibilités d'architectures parallèles (d'un côté, Truc<A> et Truc<B>, d'un autre côté TrucA et TrucB qui dérivent de Truc), avec chacun leurs paradigmes, leur syntaxe, leurs contraintes et leurs avantages. Mélanger les deux dans un projet un peu complexe me semble assez incongru, au moins autant que de mélanger des paradigmes C et C++, par exemple.

Je pense qu'en 2017 nous publierons de petites dépêches pour expliquer les aspects de la programmation générique et surtout la méta-programmation (et un peu de programmation fonctionnelle) car c'est l'intérêt de coder en C++.

Bah, je n'ai rien personnellement contre la programmation générique. C'est juste que le C++ OO et le C++ générique ressemblent de plus en plus à deux dialectes distincts, au moins autant que le C et le C++98. Et s'il est techniquement possible de mélanger les deux (le compilateur le comprend), c'est de plus en plus compliqué de les faire cohabiter dans le même projet. Mon impression est que de toutes manières les programmeurs ne vont plus pouvoir s'en sortir avec les deux paradigmes à la fois; d'un côté on aura le monde des design patterns et du typage dynamique, et de l'autre côté on aura les templates de templates et le typage statique.

Par contre, du coup, appeler tout ça "C++" et continuer à prétendre que c'est le même langage, ça n'est pas très sain. Pour recruter quelqu'un dans une boîte ou dans un projet, il va falloir préciser quels aspects du C++ on souhaite privilégier. De même, il pourrait être sympa de commencer à définir des sous-ensembles plus ou moins officiels qu'on pourrait passer aux compilateurs, pour vérifier qu'on respecte bien le cadre imposé. J'ai appris il y a peu de temps que pour émuler ce comportement, certains n'acceptaient que d'anciennes versions des compilateurs, ce qui me semble profondément stupide (on peut ne pas vouloir autre chose que du C++98 tout en voulant profiter des corrections de bugs et des optimisations des compilos récents).

Le mot-clé template fait peur, démystifions-le ;-)

Je ne pense pas que ça soit les templates qui fassent peur, c'est l'ensemble pas très intuitif des syntaxes associées.

D'abord, merci pour cette série d'articles, c'est assez agréable de pouvoir passer 5 minutes à lire quelque chose d'assez compact sur chaque nouveauté plutôt qu'une énorme dépêche ultra-résumée.

Sur le fond, quand je lis le code proposé, je me dis quand même qu'on est carrément en train de définir un nouveau langage avec la programmation générique. Je n'ai pas l'intention de résoudre en un commentaire la discussion éternelle sur le fait que C++ est ou n'est pas un langage orienté objet, mais mon point de vue est quand même que le multi-paradigme a une limite, c'est celle de la compréhension croisée entre les différents programmeurs.

Concrètement, j'ai un mal fou à discuter avec les «petits jeunes» qui apprennent la syntaxe générique du C++, parce que j'ai quand même l'impression que pour beaucoup d'applications, la programmation OO et la programmation générique permettent de faire des choses qui se superposent largement, mais qui sont assez incompatibles. On peut partir sur un design à base de templates ou sur un design à base de hiérarchies de classes, et une fois ce choix fait, on a quasiment deux dialectes incompatibles. Ça va devenir de plus en plus compliqué de définir ce qu'est le C++, puisqu'au final quelque chose comme "le logiciel est codé en C++" ne voudra plus dire grand chose, à part qu'il est compilable par un compilateur C++.

Tu n'as pas à le faire, la plupart des sites ont une liste de CGU longue comme le bras que tu es censé respecter quand tu consultes le site. Ceci dit, la plupart du temps, il ne s'agit que de rappels légaux (respect du droit d'auteur, etc), d'une liste de trucs qu'ils se permettent de faire avec tes données personnelles (à peu près tout, en général), de toutes les permissions que tu donnes en utilisant le site (installer des cookies, stocker ton IP et la signature de ton navigateur, transmettre tout ça à leurs partenaires commerciaux, etc), de l'adresse à qui tu peux t'adresser en cas de recours, et de leur droit à te bloquer si tu ne respectes pas les CGU.

Ceci dit, je ne sais pas vraiment à quel point tout ça est opposable, puisque c'est planqué dans un petit coin. Mais bon, ça vaut bien les conditions générales de vente des supermarchés, qui sont affichées en police 8 à 3m de hauteur derrière une pub à la caisse centrale.

Dans tous les cas, devoir cliquer sur "oui j'ai lu les CGV et je suis d'accord", ça n'est juste qu'une précaution juridique parmi d'autres. S'il n'y a pas de case, le vendeur peut toujours (à raison) argumenter du fait que le contrat de vente est conclu par la transaction financière (et que si tu payes c'est que tu as pris le soin de te renseigner), et l'acheteur pourra toujours prétendre que personne ne lit les CGV et qu'il y a tromperie quand elles ne sont pas "standard" (ce qui est vrai aussi). Sur le fond, les CGV doivent avoir plus de valeur que les CGU (parce qu'il y a contrat de vente), mais les clauses doivent en être identiques. À mon avis, la seule différence est qu'ils peuvent très facilement bloquer ton accès au site si tu n'es pas lié financièrement, alors que bloquer ton IP quand tu as un abonnement pose un réel problème.

J'imagine que tu n'as déja pas le droit de les bloquer (ça doit figurer dans les conditions générales d'utilisation). Ça ne change donc rien pour toi.

Je pense que c'est très mal expliqué, mais j'ai l'impression que l'idée est que les auteurs des blogs s'engagent à ne pas publier des choses déja protégées par le droit d'auteur ( = contenu original). Ça ne veut pas forcément dire que le contenu est librement réutilisable. De toutes manières, la formulation est tellement foireuse ("libre de droits" ne veut rien dire de particulier, à part peut-être qu'on peut espérer le réutiliser sans payer) que je ne vois pas ce qu'on peut en faire.

Je pense que c'est exactement ça: remplacer les concours de la fonction publique par des contrats de droit privé.

Ça ne coûte pas moins cher mais ça permet de singer les méthodes de management du privé, avec en plus de grosses dérogations (par exemple la possibilité de faire 5 ou 6 ans de CDD avant d'être remplacé par un autre CDD, ou l'absence de prud'hommes et la quasi-impunité de l'employeur).