🚲 Tanguy Ortolo a écrit 12224 commentaires

Il est à noter que la censure d'État sur Internet existe déjà en France, sur décision judiciaire il me semble, pour des motifs tels que l'organisation de jeux d'argents non autorisés. Cette censure est mise en œuvre par les grand opérateurs d'accès à Internet, sous la forme de mensonges dans les réponses de leurs services de résolution de nom de domaine.

Merci, mais rien de tout cela n'indique pourquoi systemd est nécessaire, ni même en quoi il faciliterait quoi que ce soit. Pourquoi un simple startx en utilisateur ne pourrait pas lancer X sans setuid root ?

Debian propose toujours SysV, même dans la testing : ce n'y est plus l'init par défaut, mais il est toujours là.

Donc il existe du bon dans le secret industriel comme dans les brevets.

Si tu fais référence à la chartreuse, le secret, qui permet que seuls les pères chartreux en produisent, n'a rien de bon pour le consommateur. Si la recette été connue, il y aurait des tas de concurrents proposant des liqueurs tout à fait identiques et donc substituables, pour un prix inférieur. Ce serait en revanche certainement difficile pour les pères chartreux.

On est d'accord. Personnellement, je trouve que vu les abus actuels, le système de brevet ne contribue plus à son but initial qui est de favoriser l'innovation. En revanche, je ne pense pas qu'il soit judicieux de l'abolir, pas dans tous les domaines en tout cas. Il serait à mon avis plus utile de le réformer, en imposant des contraintes telles que :

• rémunération de l'office des brevets indépendante du volume de brevets accordés ;
• pas de prototype qui fonctionne ⇒ brevet invalide ;
• homme de l'art incapable de reproduire un prototype qui fonctionne à partir du brevet ⇒ brevet invalide ;
• brevet invalide pour ce genre de raison ⇒ amende dissuasive pour l'auteur et pénalité pour l'employé de l'office de brevet qui l'a accordé quand on le découvre, par exemple à l'occasion d'un procès ;
• brevet inutilisé pendant N d'années ⇒ brevet automatiquement invalidé, avec publication régulière d'une liste de ces brevets invalidés.

Je pense notamment à un brevet récent d'IBM sur un système de protection contre les tirs d'arme à feu par film du projectile, analyse de sa trajectoire et stimulation neurale de l'utilisateur pour lui faire éviter la balle façon Matrix : ce truc n'est pas réalisable aujourd'hui, donc leur prototype n'existe pas et leur description de ce système est bidonnée ; ce genre de pratique mériterait une amende pour IBM et une pénalité sur le salaire de l'employé qui a validé cette connerie. Voire un licenciement pour faute, parce que son boulot est d'analyser les demandes de brevets, ce qu'il n'a pas fait dans ce cas.

Le système de brevets a des inconvénients, de plus en plus significatifs au fur et à mesure qu'on en abuse, mais il ne faut pas oublier son but initial, enfin, ce qu'on m'a appris comme tel : inciter les inventeurs à publier leurs inventions plutôt que de recourir au secret industriel.

En effet, sans système de brevet, un inventeur cachera spontanément ses inventions, pour éviter qu'on les copie et en tirer ainsi un avantage concurrentiel. Or, l'innovation nécessite une grande part de copie, d'inspiration et d'amélioration sur l'existant, le secret industriel étant ainsi nuisible à l'innovation. Le système de brevet fournir ainsi un avantage concurrentiel artificiel, sous le forme d'un monopole temporaire garanti par contrainte légale, avec pour contrepartie l'obligation pour en bénéficier de publier son invention, permettant ainsi à quiconque de l'imiter — pas pour la vendre telle quelle, ça c'est interdit — pour l'améliorer ou s'en inspirer de façon générale.

Je ne vois pas le rapport avec systemd.

Pas de problème. Je ne trouve pas ma syntaxe si difficile à lire à partir du moment où 1. on n'a pas de coloration déconnante, et 2. on considère bien que toute la commande à substituer entre les parenthèse est interprétée à part. Au contraire, je trouve ça plus lisible qu'avec des échappements, dont j'ai d'ailleurs peur qu'ils ne fonctionnent pas du tout (le shell verra une commande avec des \", c'est quoi ça ?).

Et pour ce qui est d'encadrer de guillemets inutilement, je pars du principe que l'utilisateur, ou celui qui modifiera mon script, pourra mettre les pires conneries dans mes variables, donc je blinde. Une bonne habitude à prendre d'ailleurs, consiste à forcer l'arrêt des options avant de donner un argument variable à une commande histoire de se prémunir des variables commençant par un tiret, genre :

ln -s -- "$file" "$target"

Carrément pas, le shell interprète à ma connaissance la substitution de commande avant les guillemets qu'elle contient. En tout cas, dash fait ainsi :

$ echo pouet > "pouet pouet"
$ echo "$(cat "pouet pouet")"
pouet

Et bien ça dépend de ce dont tu as besoin, mais typiquement tu as besoin du nom/de la ligne de commande

name="$(cat "/proc/${pid}/comm")"
command="$(cat "/proc/${pid}/cmdline")"

Sous Debian, ok. Mais je veux dash pour ses performances, et en plus sous Gentoo ce n’est pas conseillé de changé la cible de /bin/sh pour autre chose que bash.

Ça c'est un réglage local, pas un truc qui devrait nécessiter une adaptation des scripts. Mauvaise distribution, changer distribution.

1: essayer de parser la sortie de 'ps' de manière fiable et on en reparle de la soi-disant supériorité du texte comme sérialisation.

C'est peut-être parce que ps n'est pas fait pour ça, encore que ça ne me semble pas bien difficile en précisant qu'on ne veut pas d'en-tête et qu'on veut des colonnes bien précises. Mais bon, si j'ai besoin d'informations sur un processus dans un script, j'irai plutôt chercher dans /proc.

Mettons que nous avons monté un système de fichiers btrfs sur /mnt

Pour info, ce genre d'utilisation de /mnt est caduque depuis, pfiou, au moins cinq ans. Aujourd'hui, /mnt est dédié aux montages temporaires, typiquement : voyons voir ce qu'il y a dans cette image ISO. Les montages permanents doivent se faire soit dans un répertoire logique, dans ton cas probablement /var/local/backup, soit dans un répertoire lié au médium de stockage, lorsqu'il s'agit par exemple d'un point de montage pour le lecteur optique, indépendamment de son contenu qui peut varier /media/cdrom.

#!/bin/dash

En pratique, on fait appel à un outil très particulier pour réaliser la glue : le shell (bash pour respecter la norme de fait, dash pour respecter la norme des pénibles — ou ses perf. —, zsh pour les vrais hommes).

Non ! Dash doit être vu comme une implémentation d'un shell Unix standard, qui fournit peu de chose de plus. Bash est une autre implémentation, qui fournit pas mal de choses en plus. Mais coder pour Dash, c'est une erreur, si ton code tourne sous Dash il tournera sous n'importe quel implémentation de shell standard, y compris Bash, et il est inutile de cibler /bin/dash, est nuisible dans la mesure où cela empêcherait sans raison de le lancer sur un système qui ne fournit pas Dash.

Bref : tu as presque de bonnes habitudes, continue comme ça mais cible /bin/sh.

Et on voit poindre des tas d'améliorations possibles. Là, le "OnCalendar=--* 04:00:00" n'est qu'une des syntaxes possibles, assez proche de celle de la cron, mais bien plus lisible, merci les "-" et les ":" pour enfin distinguer date et heure. Mon principal reproche à ce stade : ça ne gère pas encore les timezones, un point indispensable dans mon activité pro. Mais rajouter demain une clause "TimeZone" ne semble pas insurmontable.

Bof, ce serait plus lisible ainsi : OnCalendar=*-*-* 04:00:00+02:00 (pour un décalage horaire fixe) ou OnCalendar=*-*-* 04:00:00/Europe/Paris (pour un fuseau horaire politique avec potentiellement un changement d'heure).

Affiche le styliste (F11). Dérive un style de caractère par défaut, intitule-le d'un nom correspondant au sens de ce que tu veux (genre : important), règle-le pour qu'il utilise le couleur de police de ton choix. Recommence pour chacun des styles que tu veux créer.

Si la notion de style logique ne te dit rien, il va d'abord falloir apprendre de bonnes notions de bureautique. Pour de vrai j'entends, pas comme la merde qu'on apprend à l'école hein.

Déjà, la bonne façon de faire ça est de créer des styles logiques, dans ton cas des styles applicables au caractère (et non au paragraphe), portant non pas des noms de couleurs, mais les noms correspondant à ce que représentent ces couleurs (disons par exemple important, à retenir, ou je ne sais quoi). Ensuite, afficher en permanence le styliste (F11), puis l'utiliser en double-cliquant sur le style pour l'appliquer à la sélection.

À mon avis, uniquement au texte, mais je n'en suis absolument pas sûr : à vérifier.

Ben non.

Ouais, on dit ça maintenant, mais j'attends de voir. Avec Lennart, je me méfie. (Mais si, je vous assure, je ne fait que maintenir udev dans le même dépôt que systemd mais ça restera tout à fait indépendant, je vous jure. Mais bien sûr, et maintenant ?)

git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.

Si, et heureusement : un gestionnaire de versions qui copierait intégralement chaque version gaspillerait pas mal de place. Dans ses concepts de base, Git peut être vu comme gardant chaque version intégralement, mais s'y ajoute une couche de déduplication, même interne aux fichiers.

Qu'est-ce que c'est qu'un séparateur de chiffres ? L'espace ou le point qu'on met en français pour séparer les tranches de milliers à des fins de lisibilité ?

Tiens, il serait sans doute pertinent de suggérer comme amélioration au paquet grub-efi dans Debian d'ajouter une option de configuration initiale permettant d'installer une copie de l'image principale comme boot/bootARCH.efi pour ce genre d'implémentation merdique.

Par contre une toute dernière question, le fichier "grubx64.efi" (ou "bootx64.efi") est-il définitif (aka crée lors de l'installation et ne bouge plus) ou régénéré à chaque mise à jour de GRUB ou du noyau  (auquel cas cette manœuvre sera à répéter à chaque mise à jour sous peine de plus pouvoir démarrer) ?

C'est l'image principale de GRUB, donc elle est générée à chaque nouvelle version de GRUB. Elle est en revanche indépendante de la version du noyau et de la configuration de GRUB (dans le sens où on peut changer la configuration de GRUB sans avoir à modifier son image principale).

Une partition système EFI étant en FAT, et FAT étant un système de fichiers déficient, on ne peut malheureusement pas faire de lien symbolique…

EFI ayant été défini… par Intel, c'est du joli, qu'ils fassent de la merde avec leur propre spec…

Pas bête comme comparaison. La limite, c'est que le bricolage, c'est assez largement pour soi-même ou essentiellement les gens très proches, évidemment.