Renault a écrit 7174 commentaires

Il gère ça le systemd ?

Je ne sais pas, mais comme il peut lire les scripts SysV, si tu arrives à le faire avec alors il pourra.

Quel est l'intérêt de systemd alors ?

La compatibilité ascendante ça te dit quelque chose ? Ça aide à faire la transition que ce soit pour les distributions ou les admins systèmes.

À quoi ça sert que LibreOffice sache lire des fichiers Words de 97 ? À quoi ça sert que Firefox sache ire des pages HTML 1 ? À quoi ça sert de lire les partitions NTFS quand on a ReiserFS ou BTRFS ? Etc.

C'est vrai que le concept du runlevel est ardu a saisir : la page Wikipedia d'ailleurs est d'une longueur monstrueuse.

Si tu avais lu la page, tu aurais vu qu'un numéro d'exécution chez l'un peut avoir une autre signification chez un autre. En gros, il faut adapter à chaque distribution le numéro selon que l'on souhaite. Il faut trouver cette information, la vérifier et tester. Ici comme c'est nommé, tu sais que quelque soit la distribution ça s'exécutera au niveau d'exécution que tu voulais. C'est plus simple non ?

arathorn:~# man systemctl
No manual entry for systemctl

Si tu n'as pas systemd, c'est normal que tu n'as pas d'entrée de manuel pour cet utilitaire.
Tu n'essayerais pas un peu de te foutre de notre gueule ?

mmh au hasard et suivant les cas : dans /etc/rc.d ou dans /etc/init.d. Le truc bon c'est que c'est valable pour quasiment tous les unix, pas juste linux.

Rien que pour le dossier de base, comme tu le montres, le nom du dossier peut changer.
Quelle portabilité incroyable !

C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.

Le mainteneur est confronté aux problèmes des sys admin. L'utilisateur final de systemd ce sont les mainteneurs et les sys admin, pas les autres qui effectivement ne verront pas une différence directe (mais indirectement, s'il y a moins de temps à passer pour gérer les services, la qualité globale du système augmente et cela permettrait de se concentrer sur d'autres tâches).

un pas de plus vers de la complexité non nécessaire dans le cas général.

Pourtant, les gens n'arrêtent pas de lister des cas où SysV a montré ses limites. Pour moi c'est la preuve que c'est nécessaire, pas pour tout le monde certes, et alors ? Gnome est une complexité non nécessaire pour certaines actions faisable plus efficacement en console, cela n'enlève pas son intérêt global d'exister.

En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.

À lire les anti-systemd qui veulent un retour à SysV et non vers une autre solution, on voit qu'il y a un soucis de discours.
C'est de la résistance au changement.

Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final…

Qui est l'utilisateur final ? L'admin système et le créateur de la distribution ont un gain évident dans l'affaire. L'utilisateur moyen non, mais est-ce qu'on râle sur des nouveautés de gcc que l'utilisateur moyen ne verra pas non plus ?

Le changement c'est bien quand c'est nécessaire.

Il faudra combien de messages avec la liste des gains apportés pour que tu voies que c'est nécessaire ?
Et combien de distributions vont devoir migrer pour te montrer qu'ils le font car ils savent qu'ils ont à y gagner ?

Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs).

Tout le monde s'en fout de ton besoin ou du mien. Dans le LL, le besoin qui est représenté est celui qui code. C'est comme ça. Ils dictent les changements car ils travaillent avant tout pour eux (ils veulent forcément que l'outil qu'ils développent répondent à leur besoin, à moins d'être maso et de programmer un utilitaire dont on ne souhaite pas l'utiliser).

Et si ton besoin n'a pas évolué, celui des autres oui, et systemd s'adapte à ce changement. D'autant qu'en étant compatible avec SysV, il peut satisfaire les "besoins" des "anciens".
Encore faut-il démontrer le besoin réel auquel répond SysV et pas systemd.

le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.

Ce n'est pas expérimental. Systemd est en développement très actif mais j'ai connu très peu de problèmes avec. J'en ai connu avec SysV aussi…
Ce n'est pas comme avec PA où en effet au début les problèmes étaient plus la norme que le bon fonctionnement. Systemd fonctionne très bien. Puis après on ne peut pas accuser le développeur d'un programme d'avoir son outil dans des distributions par défaut. Ce sont elles qui font le choix et en sont responsables.

En termes de technos oui c'est plus ou moins récent, mais les concepts sous jascents sont loin de l'être.

Oui, enfin osef. Une technologie qui n'existait que dans un garage ou de manière inaboutie ce n'est pas très intéressant. Cela reste des nouveautés qui impliquent de nouveaux usages et de nouveaux besoins.

Typiquement udev (et HAL) permettent de gérer l'histoire des périphériques à chaud qui existaient depuis un bail mais qui sont populaires depuis seulement une décennie pour l'ordinateur moyen. Et étant donné la fréquence d'utilisation de ces périphériques aujourd'hui, heureusement qu'il y a des mécanismes similaires.

Le concept est certes vieux, mais comme il était discret, le cas d'utilisation n'était pas gérée ou de manière trop légère.

Et avec systemd, pof, ça marche en un clic ?

Non, mais certains problèmes qu'il y avait avec SysV n'existe plus, ou sont plus simples à gérer.
C'est là l'intérêt…

Etape obligatoire quelque soit ton gestionnaire de service non ?

Je ne dis pas le contraire. Mais certains semblent oublier que SysV nécessite un apprentissage.
Et la courbe d'apprentissage de systemd semble intéressante vis à vis de SysV.

Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD

Où j'ai dis ça ? J'ai l'impression que tu négliges le temps de rédiger un démon sous SysV de manière propre. Car oui, gérer cela de manière propre est assez long et périlleux par rapport à une unité de systemd qui t'abstrait de l'implémentation de concepts délicats à gérer comme les dépendances de processus ou du chemin d'accès à certains fichiers.

A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.

C'est à se demander si tu as lu la doc de systemd et si tu t'en es réellement servi un jour.
Les unités de systemd peuvent différer entre distributions pour un service donné. Systemd ne change rien à ce fait et chaque distribution peut avoir sa petite touche personnelle.

Ce qui change c'est que si Debian fait une unité adaptée pour httpd, un utilisateur de Fedora intéressé pourra copier/coller ce fichier et l'utiliser et ça fonctionnera. C'est ça qui est intéressant.
Essaye de le faire avec SysV, tu vas prendre un certains temps à adapter le script…

Satisfaire les besoins et les dépendances d'un service restera à ta charge.

Par chance, si tu connais les dépendances les gérer est bien plus simple avec systemd qu'avec ton script SysV. Et lui gérera ça pour toi partiellement, tu n'as qu'à lui fournir le nom et non le mécanisme entier.

Toutes les dépendances ne peuvent pas s'exprimer dans un unit systemd,

Référence nécessaire.
Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.

Note que l'inverse est sans doute plus vrai encore, de nombreux cas pourtant "simples" ne sont pas gérables proprement avec SysV.

Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.

systemd ne change rien sur ce fait (et SysV non plus), mais permet de s'affranchir de l'apprentissage de certaines choses avec un minimum d'apprentissage car on peut gérer des services sans être sysadmin d'un serveur critique tu sais…

je te garanti qu'elles n'utiliseront pas les mêmes units.

Possible, et en soit ça n'aura pas une grande importance.
Un fichier init donne les paramètres pour lancer un service dans une syntaxe précise et en couvrant un maximum de configurations possibles. Si une distribution veut changer un fichier unit pour une raison X ou Y, ce n'est pas grave car comme la syntaxe et les possibilités sont uniformisées, un fichier unit d'une distribution fonctionnera forcément dans une autre.

Avec SysV ce n'était pas le cas, car chaque service vérifie des trucs dans son coin de manière non harmonisée, les noms de fichiers ou les chemins d'accès diffèrent entre distributions, etc. Ce qui fait que le copier/coller n'est pas possible.

Systemd corrige cela et c'est déjà un grand pas en avant.

Oui mais il faut lire la documentation, se former. Tout comme pour les scripts SysV.

systemd te fait abstraction de beaucoup de concepts, mais tu peux comprendre son fonctionnement : il y a de la documentation, le code source est accessible, etc.

• Les scripts c'est pourri par ce que quand on connaît pas ça semble compliqué.

Pour deux personnes qui ne connaissent ni systemd, ni les scripts, systemd sera bien plus simple.

gentoo utilise des « runlevel » nommé par exemple.

Et alors ? le soucis c'est qu’il n'y a aucune convention de nom, pas toutes les distributions le font et en plus les niveaux d'exécution sont loin d'être les seuls problèmes notamment de compatibilité. Faute de s'accorder sur une norme commune, systemd aura le mérite d'agir comme standard de facto de manière efficace.

Si les scripts SysV ne sont pas portables entre distribution, on peut admettre alors que systemd est plus portable que l'ancienne proposition. Donc pourquoi critiquer systemd sur ce point et pas SysV ?

Pour l'autre aussi.
En fait la question est :
Prends deux apprentis admins systèmes qui ne connaissent rien en SysV et systemd.
Demande leur de créer chacun de leur côté un service X tout seul avec la doc.

Je ne suis pas sûr que celui qui fera du SysV finira le premier… Et en plus en traitant la chose correctement (dépendance entre services, etc.).

Oui bien sur. L'ennui c'est que ce choix disparaît avec le temps et les dépendances et que bientôt je ne l'aurais plus. Pourtant, mon approche a toujours une raison d'être.

Si le choix disparaît, c'est que les autres choix ne sont plus pertinents aux yeux des mainteneurs et que le point de vue qui justifie leur existence est marginale.

Tu te doutes bien que si tout le monde pensait comme toi, systemd ne s'imposerait pas… Et que si beaucoup de gens pensent comme toi ils peuvent maintenir le truc en parallèle. D'autant plus, qu'à écouter certains, systemd c'est la difficulté et SysV la facilité, alors qui est chaud pour donner du temps à le maintenir ? Bizarrement, plus grand monde…

Dans le premier cas, je peux arranger la chose, dans l'autre c'est beaucoup plus compliqué à arranger.

En partant de ce principe, tu codes en assembleur et tu n'utilises aucun programmes que tu n'as pas écrit ? J'en doute. Pourtant tous ce que tu utilises fait de l'abstraction pour toi, prennent des choix de conceptions que tu apprécies ou pas, etc. Pourquoi est-ce que là ce serait plus important qu'ailleurs ? Si tu as le besoin de manipuler profondément ce qu'il se passe, tu peux toujours te passer de systemd notamment en créant ta propre distribution à la main. Certains le fond, comme dans l'embarqué.

Or, le desktop c'est marginal pour linux.

Toutes les distributions qui utilisent systemd pour le moment sont plus orientées bureaux que serveurs. Et systemd est loin d'être inapte en utilisation serveur, au contraire, il simplifie la vie des administrateurs systèmes (qui ne pensent pas comme des programmeurs).

L'utilisateur a toujours pu exploiter le matériel qu'il avait sous la main, mais il devait le faire de manière explicite.

Oui mais le faire de manière explicite n'est pas toujours simple ou à la portée de tous.
Le faire à la main demande le temps d'apprendre à le faire, alors qu'en mode automatique tu n'as pas à t'en soucier. Personnellement quand j'utilise ma machine, je n'ai pas envie d'apprendre à monter une clé USB avant à la main. Pourtant à une époque j'ai du le faire, mais je l'ai fait car j'étais curieux et que j'avais le temps disponible pour ça.

Sauf que "au mieux" pour le mainteneur, ce n'est pas forcément au mieux pour moi. Alors oui ça fait le café tout seul mais une fois sur deux je me retrouve avec un cappuccino sucré quand je voulais un café noir.

Une distribution Linux est par définition un assemblage de composants logiciels afin d'avoir un système cohérent et utilisable. Par conséquent, ils font des choix de technologies, de logiciels et d'imbrications en vue d'une utilisation par une cible particulière. La distribution universelle (désolé pour Debian) n'existe pas et n'a pas de sens. Forcément certains choix plairont à certains et pas à d'autres. Et si tu n'aimes pas ces choix, bah go LFS.

En informatique, et tout domaine un petit peu complexe, tu fais confiance au travail d'autrui et par conséquent à des choix qu'ils ont fait (en général pour se faire plaisir avant tout). Tu es qui pour exiger que ton choix soit pris en compte ? Tu es libre de proposer une solution pour représenter ton choix et tes besoins.

Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur et le serveur c'est que du cas particulier, c'est pour ça qu'on paye des gens pour faire la config.

Bizarrement je constate que les administrateurs systèmes purs qui ont fait l'effort d'apprendre systemd sont contents du résultat. La critique est souvent porté par ceux qui n'ont pas essayé…
Sans compter que c'est Red-Hat qui paye le développeur principal de systemd. Red-Hat qui a je pense un coeur de métiers qui fait que s'ils se loupent sur le marché des serveurs ils vont le regretter. Alors on verra avec le temps mais je fais confiance au fait que Red-Hat ne souhaite pas torpiller son propre marché et qu'ils savent ce qu'ils font.

Résultat : l'admin devra se palucher une techno supplémentaire pour un gain qui est loin d'être acquis.

Je n'ai vu personne qui a appris à utiliser correctement systemd s'en plaindre. Bien au contraire, c'est plutôt bien accueillis.
Et oui l'administrateur système devra apprendre une nouvelle technologie, mais en informatique l'apprentissage est constant dans le temps. Apprendre une nouvelle technologie ne devrait pas faire peur, tout informaticien est payé pour être à jour de ce point de vue. Tu crois que Ken Thompson programme de la même façon en 1960 et aujourd'hui ? Tout change, tout évolue et il faut s'adapter et dans le milieu ce n'est pas quelque chose de nouveau.

tu choisis un soft principalement pour l'usage que tu en fais, pas parce que ça fait "plein de choses qu'on pouvait pas avant".

Ce que je voulais te mettre en évidence, c'est que tu utilises aujourd'hui des programmes dont le fonctionnement interne t'es largement inaccessible. Pourtant ces programmes remplacent avantageusement des programmes plus simples du passé. Donc si tu es prêt à t'accommoder de ça, tu peux le faire pour systemd.

Les technos actuelles existaient pour la plupart il y a 20 ans.

Pas trop non. Il suffit de voir la quantité de norme qui tentent de combler les lacunes de POSIX pour montrer que ça évolue nettement. La LSB, Freedesktop.org, les nouveautés du noyau Linux ou X.org ça ne te dit rien ? HAL, udev et autres non plus ?

D'ailleurs, dans le domaine du serveur tu as la virtualisation et les serveurs d'applications qui sont de plus en plus utilisés et que systemd prend en charge bien mieux que SysV. ces applications étaient marginales voire inexistantes il y a 20 ans…

Or, l'utilisation principale de Linux (l'OS) c'est le serveur

Référence nécessaire, je dirais que le téléphone mobile est équivalent maintenant.

'est une niche peu confrontée aux problématiques de matériel modulaire et de contexte de config qui change tous les jours.

Domaine qui est confronté aux migrations de systèmes, mises à jour et gestion des distributions où les scripts SysV n'étaient pas compatibles entre eux.

S'il faut se palucher en plus la doc de systemd pour démarrer 3 pauvres services sur un LAMP alors que 3 lignes de shell suffisent, alors c'est une usine a gaz.

Il faut se farcir la doc pour écrire un lanceur de LAMP en tant que démon. Doc bien plus obscur et moins généraliste entre distribution que ne peut le faire systemd.
Pour écrire un service sur systemd, c'est très simple et rapide. Le temps d'apprentissage est bien plus court.
Quand systemd sera bien ancré partout, ça posera moins de soucis dans ces situations…

Sans compter la maintenance qui est simplifié avec de nouveaux usages possibles.

Mince, les scripts SysV de Debian ne tournaient que sous Debian (avec de la chance sur plusieurs versions de suite et ses dérivées) et pendant une longue époque avec bash. Alors je n'ose même pas imaginer le résultat sur une Red-Hat ou un OpenBSD…

Tu vois que finalement ce n'est pas un véritable problème, ce n'est pas pire qu'avant.

Oui, parce qu'il y a bien que Lennart pour dire que la portabilité ça sert à rien, que la philosophie Unix est un échec, et d'autres types de conneries.

Il a dit surtout que la portabilité ne sert à rien si cela implique que tout logiciel ne soit compatible qu'au dénominateur commun et dans le cadre d'un système de démarrage cela fait sens.

En écoutant certains, il faudrait que tous les programmes soient compatibles avec toutes les plateformes. Mis tu veux atteindre ce but comment avec un code un minimum propre tout en gardant des spécificités à chaque plateforme ? Le noyau Linux propose une API avec des fonctionnalités innovantes, hors norme POSIX (car cette norme n'évolue plus), à quoi ça sert de faire de telles fonctionnalités si aucun programme n'en profite en raison de la sacro sainte portabilité ? À quoi ça sert pour un programme qui est par essence lié au noyau d'être portable ? Déjà que les scripts SysV ne sont pas portables d'une distribution à une autre, au moins systemd aura malgré son lien au noyau Linux amélioré la portabilité entre elles.

La portabilité c'est bien, oui, il faut travailler en ce sens. Mais pas à n'importe quel prix, que ce soit en performance, en qualité du code ou en fonctionnalités proposées. La portabilité impose des contraintes que tu ne peux pas toujours accepter, c'est comme ça. Est-ce grave ? Non, même si c'est souhaitable de rendre le code le plus portable possible.

Sans compter que la réponse est connue : si les paquets sont bien faits c'est beaucoup plus simple à maintenir qu'un truc a gestion de dépendances.

C'est certain qu'un programme qui fait moins de chose est plus simple à maintenir car la partie complexe est laissée à l'opérateur humain. est-ce vraiment souhaitable ? La gestion des dépendances fait gagner beaucoup de temps et d'énergie à l'opérateur humain qui n'a à ce soucier que du nom du programme qu'il souhaite pour l'avoir fonctionnel.

Alors oui au moins tu sais exactement ce que tu fais, mais tu payes le prix par moins de confort et plus de temps à gérer cela à la place de l'ordinateur (qui est pourtant un outil fait pour automatiser les tâches et libérer l'humain de la répétition). C'est un choix de vie, tu comprendras que certains ont d'autres priorité que toi.

M'enfin, pour ma part, je préfère faire à la main (même mal)

Tu pars mal, préférer mal faire quelque chose quelque en soit la raison derrière me paraît bien futile. Pourquoi vouloir faire mal ? Tu n'as rien à y gagner…

en shell une fois pour toutes

À chaque mise à jour majeur des programmes que tu lances tu devras certainement retoucher aux scripts de lancement. Si tu changes de distributions aussi. Bref, ce n'est pas gravé dans le marbre.

machins automatisés font plus ou moins bien a chacun de mes boots (détection de matos, séquençage des scripts de démarrage etc), ajoutant encore un peu plus à la balkanisation des linux.

D'un autre côté, l'informatique a changé, le matériel est modulaire (clés USB qu'on branche et débranche, carte Wifi qu'on active selon le besoin, pareil pour le Bluetooth, etc.), les interfaces réseaux peuvent changer, le fait d'avoir le réseau en permanence n'est pas une garantie, etc. Bref, il faut gérer ces cas pour que les programmes derrières fonctionnent correctement mais aussi pour que l'utilisateur puisse exploiter le matériel qu'il a sous la main.
Tu regrettes l'époque du montage de la clé USB à la main ? Tu regrettes la douce époque où la batterie ne durait que 15 minutes car tout le matériel était activé sans possibilité de couper ce qui ne sert pas ? Bref, oui l'informatique a évolué et pour profiter du matériel et des logiciels à disposition ils faut faire des tâches automatisés qui va s'adapter au contexte pour faire ce qu'il y a à faire. C'est de l'optimisation et tout le monde y gagne. Oui les programmes sont du coup plus complexes, mais je pense que tu utilises ssh et non telnet, que tu prends Firefox et non Mosaic pour aller sur le Web, que tu utilises Torrent et les courriels plutôt que USENET, que tu n'utilises pas une interface tty uniquement, etc.

L'ennui c'est que plus ça va, moins c'est faisable à cause de dépendances plus ou moins fumasse à ces usines a gaz.

Reste à démontrer qui est l'usine à gaz. Je pense qu'on ne doit pas avoir la même définition d'une usine à gaz. Déjà ce terme implique que le programme surconsomme par rapport à son efficacité et au vu de ce qu'il est capable de faire, il est bien performant.

Dans aucun musée que j'ai visité les expositions avaient une lumière directe du soleil dessus.
Si le musée fait entrer de la lumière extérieur, souvent les œuvres n'ont qu'une réflection de cette lumière et tu te doutes que la réflexion diminue grandement l'impact par rapport à une source directe…

Alors que l'effet du flash sur les pigments a été bien vérifié et les œuvres préhistoriques sont un exemple frappant.

Pour ceux qui ont roupillé en cours de chimie, mécanique quantique et biologie, on y apprend que la photosynthèse et d'autres réactions liées à la lumière dépendent aussi de la longueur d'onde.
Donc une lumière plus intense, avant le seuil, a un impact plus fort mais si la longueur d'onde diffère alors tu ne peux pas tirer directement de conclusion.

Je n'arrive plus à retrouver la source, c'était dans un livre portant sur la 2e GM.
Après je ne me souviens pas des détails, mais de ce que j'ai pu retrouver c'est que globalement le premier recensement français date de 1801, mis en place par Napoléon, et qu'à l'époque (jusqu'à une certaine date mais laquelle ?) où l'origine ethnique était mentionnée.

Du coup c'est peut être le recensement en général qui est utilisé et que le lien avec Napoléon est uniquement le fait qu'il l'ait instauré (et éventuellement Vichy a utilisé les papiers de l'époque pour retrouver des descendances).

Un recensement est à priori anodin et montre qu'entre de mauvaise main tout fichier peut être très mal exploité. Tu noteras qu'aujourd'hui l'État ne questionne plus la religion ou l'ethnie de ses habitants, que c'est illégal et je pense que la 2e GM n'y est pas étranger.

Ce n'est pas ce que j'ai pu voir hier en trainant sur les sites de conservation d'œuvres d'art. En gros, il semble que 10 ans d'exposition à 500 lux revient à peu près à 100 ans d'exposition à 50 lux. Les pigments (biologiques au moins) absorbent les photons de manière proportionnelle à l'intensité de la lumière, je ne vois pas pourquoi les mécanismes de dégradation ne fonctionneraient pas de cette manière.

Le problème c'est que tu regardes uniquement le facteur intensité lumineuse.
Un Flash émet à une longueur d'onde différente de celle de la lumière ambiante ce qui est sans doute bien plus agressif que la simple intensité lumineuse.

De plus dans ce genre de phénomènes (absorption énergétique au niveau de l'atome) tu as des effets de seuil ce qui fait qu'une lumière plus intense peut être nécessaire pour dégrader fortement.

Si tu ne l'as pas remarqué, Mozilla (tout comme le Projet Fedora d'ailleurs) ne font des publications que le mardi.
Le mardi est souvent une journée de choix pour mettre à jour un programme (pour un sys admin) : le week-end c'est mort car les gens ont souvent une autre activité, le lundi est souvent là pour rattraper les activités du week-end, après le mercredi ça commence à être tendu pour tester et faire un retour en arrière en cas de soucis avant le week-end suivant…

Mais la situation reste la même : quelqu'un a engagé des ressources pour obtenir une copie de l'œuvre. C'est juste pas le même quelqu'un.

Et alors ?
J'ai engagé des ressources pour télécharger la Fedora 20 (environ 40 minutes de CPU et de bande passante), est-ce que à ce titre j'oblige tout le monde à me donner des royalties en cas de redistribution de ce que j'ai téléchargé ? Est-ce que ça a un sens ? Personnellement non, rien n'a été produit en ce sens.

Qu'est ce qui t’empêcherai de vendre des copies de DVD d'OpenSuse ?

Rien, mais je ne peux obliger personne à ne pas récupérer ma copie via bittorrent et obliger de me rémunérer s'ils redistribuent ces copies. Tout simplement parce que je n'ai aucun droit sur cette production, elle ne m'appartient donc pas. Je peux faire ce que je veux mais je ne peux rien imposer aux autres. C'est pareil avec le cas de la photo, et je trouve ça sain.

by car le gars il a du talent pour faire une copie d'une œuvre, et que cette clause lui permet d'associer son nom à cette copie, pour qu'éventuellement un jour on fasse appel à lui pour un boulot.

Normalement le by est lié sur la qualité d'être auteur et non diffuseur. Dans ce cas, il ne peut être associé à by.

nc car ayant engagé des ressources pour réaliser cette copie, il peut ne pas souhaiter que d'autres personnes puissent se faire de l'argent à partir du fruit de son travail (la copie).

J'engage des ressources des tas de choses dans la vie sans que je cherche une quelconque rémunération "obligatoire" de celle-ci.

Il a bossé, il souhaite se faire payer, mais il a obligation de diffuser gracieusement le fruit de son travail (car copie fidèle d'une œuvre du domaine publique). Comment fait-il pour remplir son frigo à la fin du mois ?

Le gars a été, si j'ai bien compris, été contacté pour faire une copie. Il a sans doute été payé pour se déplacer et faire cette action par la personne qui l'a demandé. C'est cette personne qui doit lui payer un "forfait" pour ce travail. Il n'y a aucune obligation d'être rentier car il a fait une copie d'une oeuvre dont il n'a aucun droit dessus. Si je copie un DVD de OpenSUse je peux être rentier à vie dessus ? Ca n'a pas de sens…

Si le gars a dépensé des sous pour faire cette copie pour son plaisir ou dans le but de se faire des sous, qu'il accepte le droit d'auteur en question qui lui interdit toute rente exclusive dessus. Sinon qu'il change de métier s'il veut se nourrir.

Avec la lumière souvent basse des musées (qui est ainsi pour protéger ce qui est exposé) cela n'offre pas un grand résultat. Puis s'ils doivent être derrière chaque visiteur pour s'assurer l'absence de flash, je crois qu'ils ne sont pas sortis de l'auberge.

Ils le font, mais comme le montre la page que tu cites, ils se réfèrent pour cela à une loi portant sur les documents administratifs.
Donc oui, selon cette loi ils sont dans la légalité mais il faudrait prouver que les productions de Gallica sont dans le cadre des documents administratifs. Comme cela a été dit plus haut, c'est douteux et je doute fortement que ça soit réellement le cas.

ni les conservateurs de musées (qui interdisent souvent les prises de vue autres que celles des photographes officiels)

Pour le coup, je pense qu'ils ont raison.
Un musée, pour peu qu'il soit un minimum fréquenté, si les photos étaient autorisés tu aurais un taux de flash assez élevé. Le flash des appareils photos, qui est une lumière puissante, abîme les couleurs de l'œuvre que ce soit une peinture, une photo ou tout autre support où la couleur est importante. Il est dans la mission des conservateurs (d'où leur nom) de mettre en œuvre des dispositifs pour protéger sur le long terme ce qui est sous leur responsabilité. Car les restaurations ne sont pas sans pertes.

Tu noteras que dans un musée de nombreuses pièces sont sous verre et autres dispositifs pour empêcher sa dégradation au cours du temps (enfin la limiter).

Donc certes ce qui est exposé peut être dans le domaine public, mais cela n'autorise pas le public à abîmer involontairement ce qui est présenté. C'est le rôle des musées que de les protéger et donc de limiter les reproductions et autres photographies à des professionnels.

Après on pourrait les obliger à mettre à disposition les prises de vues en haute définition sur un site librement accessible, pour le moment ils peuvent en faire ce qu'ils veulent ce qui est légal mais douteux dans le cadre des missions publiques.

Je pense que c'est ça l'astuce : aucune entreprise ou organisation ne pourrait traiter autant de données, mais la NSA a des pouvoirs spéciaux : elle peut croiser les données traitées individuellement par les FAI, par Google, par les opérateurs télécom, etc. Ce n'est pas les données brutes qu'elle récupère, mais des données déja analysées—et ça, ça me parait tout à fait possible. Si tu sniffes internet au hasard, tu vas te taper des flux de streaming, des bouts de fichiers excel attachés à des emails dont tu n'as pas la fin… Le vrai défi, c'est l'analyse des données. Le fait de disposer de pétabytes de données brutes non contextualisées me semble finalement peu inquiétant, sauf pour l'analyse a posteriori.

Ce qui intéresse Google, la NSA est autre ne sont pas les données brutes mais les métadonnées. C'est assez simple de virer "le bruit" pour garder l'essentiel.
Par exemple on sait très bien que le volume des métadonnées par utilisateur varie peu au cours du temps contrairement aux données brutes qui explosent car le multimédia pèse de plus en plus lourd à cause de la qualité des données. Google ne s'intéresse pas aux bits de données concernant la vidéo HD de Ypoutube que tu regardes, mais à son titre, sa date de demande, sa fréquence de visite, etc. Et ça c'est rien en volume et à traiter par rapport aux images, sons et vidéos qui pèsent lourds mais n'intéressent personnes.

Donc si ils peuvent largement collecter assez d'informations, en évitant d'analyser les données pour se concentrer sur les métadonnées. Et pour faire ça à l'échelle planétaire ils ont largement les moyens.

La seule différence, c'est que tu n'est pas un vrai client de Google. Mais sur le fond, ça fait des décennies que des entreprises ont des données sur ta vie privée, et qu'il faut juste espérer qu'elles respectent la loi, qu'elles stockent bien ces données de manière à ce qu'un tiers ne puisse pas y accéder, etc.

Cette différence est selon moi non seulement vitale, mais tu en oublis une autre. Mon FAI et ma banque sont normalement liés au droit français, droit français qui est décidé notamment en partie par moi.
Google dépend du droit américain sur lequel je n'ai aucune véritable influence car n'étant pas citoyen américain je n'ai aucun moyen de faire entendre ma voix là bas réellement (je ne peux pas me présenter dans leur processus législatif alors qu'en France je peux le faire). Et quand tu vois que l'État américain est un des États avec des dispositifs puissants pour collecter et analyser les données librement, oui c'est important.

Je sais que l'État français n'a pas autant de pouvoir ce qui rend ce type d'actions non légitimes. Sans compter que théoriquement je peux influer l'État français sur la question.

Et que mon FAI et ma banque aient des données, c'est normal, je suis client et j'utilise leur service. Si demain je ne suis pas content je vais voir ailleurs et ma vie privée sera associée à une autre entreprise (ou personne, si je vais dans un FAI associatif et que je me passe de la banque…). Alors que Google étant présent partout, même sans être client chez eux je suis pisté. la seule solution étant soit de filtrer les pages avec Google (d'où les extensions), soit éviter ces sites (ce qui est je pense une solution anormale). Disons que dans un cas je choisis de donner mes données, dans l'autre pas. Et personnellement je fais plus confiance à ma banque concernant mes données personnelles où légalement il ne peut pas en faire grand chose et qui gagne son argent autrement que Google qui a besoin de ces données et de les vendre pour vivre.