Ignatz Ledebur a écrit 427 commentaires

Pour ceux qui veulent savoir où ils en sont avec l'alcool linuxfr, un petit script viteuf :

#!/bin/sh
stuff () {
    date "+%s"
    date -d"$1" "+%s"
    shift 1
    echo $*
}

echo $(stuff $@) | awk '{ days = ($1-$2)/84600
                       print "Interventions/jour: " $3/days
                       print "Karma/intervention: " $4/$3}'

En arguments, la date de création du compte (AAAAMMJJ), le nombre d'interventions, et le karma. Ex :

$ ./trollfrmystat 20030423 20460 6639
Interventions/jour: 4.89726
Karma/intervention: 0.324487

À noter que j'ai compté des journées de 24h, quand il serait plus juste de leur retrancher a minima 8h (sommeil+tâches domestiques éloignant du PC). Vous pouvez donc augmenter le premier chiffre d'un bon tiers.

Ouais, enfin, ramené au nombre d'interventions, il n'y a quand même pas de quoi pavoiser : 6639/20460, ça nous fait… 0.3244709 par intervention. Le prix de la dissidence (que la bien-pensance ambiante empêche de s'exprimer à loisir, rappelons-le), probablement.

J'entends bien que ça découle de la parallélisation, mais quel est l'intérêt de paralléliser, à part aller plus vite ? Sauf à soutenir que systemd est accidentellement parallélisable, je ne vois pas comment on peut soutenir que ça n'a rien à voir avec le design initial…

C'est pas un peu contradictoire avec soutenir que la vitesse de systemd n'est qu'accidentelle et pas du tout un point essentiel de design ? :|

Le coréen a aussi cette réputation. Et notons qu'inversement l'anglais, bien que réputé plus facile, est pire que le français pour ce qui est de l'orthographe. Un bon article du Tigre sur (entre autres) ce sujet.

À part en fermant le flux de sortie, mais là, en shell, je ne sais pas faire.

exec 1>&-, qui plantera à peu près n'importe quelle commande tentant d'écrire sur la sortie standard.

Bon en fait tout ça c’était pour dire que Bash c’est un langage de script, et on l’a utilisé pour faire un système d’init complet, plusieurs milliers de lignes qui à priori était difficilement maintenables vu la rapidité à laquelle il a été adopté sur différentes distributions

Ce serait un argument acceptable (au delà de l'effet de mode, souvenons-nous de KDE4, et rappelons qu'un démarrage plus rapide est très vendeur pour les distros grand public) si udev était resté une brique indépendante. Ceux qui auraient voulu maintenir un init à base de scripts aurait pu le faire sans problème exactement comme avant et ça aurait àmha été beaucoup moins polémique (alors que là, couplé avec une certaine… attitude à la tête du dev de systemd, ça ne pouvait qu'être détonnant).

Bah donc systemctl --list-dependencies --reverse foobar.service, non? L’option --reverse ça fait bien le contraire.

Bah non :

Yes, I tried it with the --reverse. That still doesn't help me if I am trying to design a target which is shutting down services. It doesn't take conflicts into account.

And indeed, that's not really what I needed. What I really needed is a "what will happen if I run 'systemctl isolate battery.target', given my current system state vis-a-vis what services are currently running?"

Et la suite qui enfonce le clou :

And in turn, I need this because I want to shut down a number of services when I do the equivalent of "enter runlevel N" in sysvinit speak, where I created runlevel N by first cloning runlevel 3 via something like "rsync -avH --delete /etc/rc3.d /etc/rc4.d" and then manually adding and deleting some symlinks. From looking at the contents of /etc/rc4.d, it's immediately obvious what will happen when I enter runlevel 4, both in terms of which services will get started, and more importantly, which services will get stopped.

From looking at the contents of battery.target and related systemd config files, it is NOT obvious, especially with how the /etc/init.d backwards compatibility feature seems to create implicit phantom services files and phantom multiuser.target.wants entries.

 

Et donc systemd prend en charge les touches de changement de luminosité?

C'est ce qu'il aimerait comprendre justement.

seulement pour les entiers parce que sinon c’est bien ==

-eq c'est pour forcer un contexte arithmétique, qui va avec -lt/-gt… qui n'ont pas d'équivalent pour les chaînes de caractères. Et pour les chaînes de caractères, ce n'est pas "==" mais "=" en shell POSIX. Ça pourrait paraître mauvais, mais dans la mesure où les espaces sont requis autour de l'opérateur de comparaison et proscrits autour de celui d'assignation, le risque de confusion est nul (pas comme en C).

Note que Perl a fait les choix inverses ("eq" pour les chaînes, "==" pour l'arithmétique), je passe donc assez régulièrement de l'un à l'autre sans plus de douleur que ça.

on utilise -a et -o

Usage découragé par POSIX à présent. Perso, je trouve cependant ça assez pratique pour combiner des tests composés, par ex. "[ -d dir/ -a ! "$flag1" ] && [ "$flag2" -o ! "$flag3" ]".

sauf que maintenant il faut utiliser $()

C'est beaucoup plus cohérent, puisqu'on récupère en fait la sortie d'un sous-shell "( … )", de sorte que tu peux écrire "$(echo a; echo b; echo c)"

Pour le reste sur cette partie, d'autres on répondu mieux que je ne saurais le faire.

se résous avec systemctl list-dependencies --reverse foobar.service (trouvé dans les commentaires de son post);

Tu aurais du lire la suite, où il dit qu'il a justement besoin du contraire (dans le commentaire que conclut la première citation que j'ai faite) :

systemctl list-dependencies will tell you what is required for a service is started, and will partially help if you want to figure why a service wasn't started. The problem is I was trying to do the reverse. That is, I'm trying to create a battery.target that is just like graphical.target, except that certain things like tor.target, pcscd.target, etc., that tend to wake up the CPU more than 10 times a second aren't started (and in fact will stop them if I run "systemctl isolate battery.target"). I could do this by creating a battery.target file that included some conflicts, but apparently that caused something else to get shutdown, and that something else made fn-F5 and fn-F6 stop to configure the screen brightness (although xbacklight -set 5 still worked).

So what I really need is a "systemctl --verbose isolate battery.target" which tells me exactly which services it is starting up, and which services it is stopping, and why. Basically, what I need is something like "make -n -d" (although hopefully with a slightly better output format). Maybe there's a secret command option or environment variable or log file that will tell me all of this. But I've looked through all of the FAQ's and man pages I could find, and I couldn't find it.

Nan mais franchement, on peut pas dire que la syntaxe des conditions soit simple à comprendre par exemple.

Ça ne m'a jamais frappé par rapport à tout ce que j'ai pu toucher (Perl, AWK, C, Python, Ocaml). Qu'est-ce que tu trouves dur exactement ?

Euh… chez moi ça marche, donc c’est que ça ne doit pas être si merdique que ça.

Oui, mais ce n'est pas le cœur de son propos, car ici il parle de design. Il ne dit pas « c'est nul, ça ne marche pas », mais « quand ça ne marche pas, c'est très difficile de comprendre pourquoi. »

Perso, si j'ai un jour besoin de faire un init, je sais que je peux lire de A-Z celui de ma distro pour comprendre comment les choses s'imbriquent et saisir ce qui est essentiel pour bien démarrer. Ce juste en connaissant le shell et en utilisant les manuels. En C, ce sera beaucoup moins évident, et pas seulement à cause de la faiblesse de mon niveau (les langages de script sont nés précisément parce que le C est difficile à manipuler).

Les goûts, les couleurs, toussa. Moi j'adore le shell et j'aime beaucoup le Perl, alors que je trouve le PHP hideux, et que l'unique fois où j'ai touché du JS j'ai sangloté sous la douche durant 5h. Il n'y a rien de rationnel en fait, à part qu'on préfère ce qui nous déstabilise le moins et donc ce qui nous est le plus familier. :)

Note pour le troll que parmi ceux qui trouvent le shell plus clair que ce dont il est question ici, il n'y a pas que des râleurs inutiles et incompétents en design :

Shell scripts are explicit, and easily debuggable. Systemd may be "magic" in that it doesn't require all of this explicit commands, but debugging its implicit dependencies and conflicts makes all of the magic disappear, and makes the result pure hell.

Ça rejoint assez bien ce qui s'est produit dans LFS.

Pas tant via GNOME que via udev. Le mainteneur principal de LFS n'aime pas systemd et trouve les scripts shell plus simples et pédagogiques. Le problème c'est qu'udev est devenu trop compliqué à extraire de systemd. Aussi, pendant un temps, l'idée a été de lancer les scripts d'init de LFS via systemd (c'est dire si le gars n'est pas sectaire), mais là encore la complexité du montage a eu raison de sa bonne volonté, si bien qu'aujourd'hui la LFS principale (développée, rappelons-le, en parallèle avec la LFS-systemd) utilise eudev.

Bon, après je ne dis pas que c'est effectivement un plan de conquête du monde de RH, certains comportements à la tête du développement, relevés entre autres par Linus, pouvant suffire à expliquer.

(le suffrage universel, c'est celle de 1793
universel masculin, aurais-je dû préciser.

Sans infirmer la teneur générale de ton propos, rappelons quand même que 1789 débouche sur la Constitution de 1791, instaurant une monarchie parlementaire à suffrage censitaire (le suffrage universel, c'est celle de 1793, dans un contexte politique beaucoup plus saignant). La notion de Peuple a toujours eu des contours flous (autre exemple, le We, the People de la Déclaration d'indépendance US ne comprenait bien entendu pas les fort nombreux esclaves).

Je n'en doute pas, ce que je voulais dire c'est que ça se fait probablement au même pro rata que pour les droits perçus, selon la logique que celui qui est le plus diffusé sera le plus copié. Résultat, on file le gros des thunes à des gens qui en sont déjà blindés.

Dans la mesure où c'est quelque chose que le posteur choisi d'afficher, je pense que oui. Souvent on y trouve humour, positionnement idéologique, soutient à telle ou telle cause/site… c'est un peu comme si on retirait les citations en exergue dans un bouquin.
Mais à la réflexion, je me demande si c'est pas plutôt un <hr/> qui conviendrait (ça paraît un meilleur marqueur de séparation d'un point de vue sémantique HTML).

Juste là-dessus :

Ça ne me semble pas pertinent de la laisser lisible.
Selon l'accessibilité, il me semble que si : le contenu doit être au maximum le même, indépendamment de sa qualité.

Comme pour n'importe quelle évolution dans le code du site. Normalement, on structure d'abord les pages en texte, puis on habille en CSS. En l'occurence, je trouve vraiment que ça fait défaut au niveau de la structure : sur un terminal braille, par exemple, il est impossible de distinguer la signature du commentaire avant de l'avoir lue pour réaliser qu'elle ne fait pas sens.
Enfin bon, si c'est vraiment trop galère tant pis, je n'insiste pas (plus). :)

A priori, il suffit de les mettre dans un <p class="sigdash">. Ensuite, côté CSS un .sigdash{display:none;} et c'est réglé, celle-ci peut alors mettre ce qu'elle veut, non?

C'est que, comment dire… dans ces tribus-là le terme "libre" est cosmogoniquement associé à:
* #fantasme_morbide_de_la_gratuité
* #union_soviétique
* #hippies_drogués_polygames

Quand on arrive enfin à 2000h garanties, le département marketing t'appelle pour te dire que les gens n'achètent pas un truc plus cher qui tient plus longtemps.

Le soucis, c'est que c'est impossible à savoir au moment de l'achat, puisqu'il faut attendre le retour sur plusieurs années pour certifier que le truc est vraiment solide à l'usage. Le seul repère pour le consommateur reste donc la marque, soit quelque chose de très flottant (il y a souvent plusieurs gammes qui ne disent pas toujours leurs noms) et facturé non pas tant par rapport au coût de fabrication qu'à ce que les gens sont prêts à débourser pour avoir un produit de tel modèle. Il va également sans dire que faire des économies sur le modèle Y succédant au très renommé modèle X peut générer un surplus de marge conséquent…

Ce qui pose d'autant plus la question de l'évaluation de ce manque : comment estimer un phénomène qui n'a par définition aucune manifestation publique (contrairement au partage de fichiers) ?

La chose sûre cependant est que ceux dont les contenus sont sous verrou numérique devraient être exclus du partage. Puisqu'on n'a pas le droit de les casser, leurs copies ne peuvent relever que du piratage, CQFD.

C'est expliqué là. En gros, il faut que tu fasses partie d'une société de gestion (ex. la SACEM). Ce qui veut sûrement dire que le partage final se fait comme d'habitude : les gros ont les doigts pleins de crème pendant que les petits bouffent leurs pompes.

Bof… tu crois vraiment que W3C ça dit quoi que ce soit à la masse des utilisateurs finaux de ce genre de plugins ? Déjà HTML, CSS, Javascript, je doute que ce soit très causant, alors les bidulles chargés de mettre de l'ordre dans tout ça n'en parlons pas. Le vrai intérêt est plutôt auprès des fournisseurs de contenus, auxquels tu peux vanter ta solution vaguement normalisée. Quelque part, c'est plutôt un bon signe qu'ils se soient sentis obligés de faire pression sur le W3C…

Okay sur le principe, mais dans les faits ça ne change rien. Que tu aies un format à la noix sanctifié par un organisme de standardisation ou simplement poussé en standard de facto par le poids d'une entreprise, c'est une différence marginale et on ne peut donc pas dire qu'on bascule ici dans l'inconnu.
Du reste, s'il est sûr que le W3C fait le jeu des DRM, il ne faut pas se leurrer non plus, les fournisseurs de contenus s'y seraient de toute manière accrochés, tant c'est la clé de leur (vieux) modèle économique. D'où c'est peut-être au final un mal pour un léger mieux, car dans l'hypothèse où le W3C aurait tenu bon, rien ne dit qu'on ne se serait pas retrouvé avec une jungle de solutions hétérogènes, ce qui aurait bien plus compliqué la vie des utilisateurs d'OS libres.

C'est plus au niveau du display que de la fenêtre en fait, ce qui n'a au final pas d'importance puisqu'on est de toute manière obligé de maximiser le navigateur pour évaluer les limites du rendu.