zul a écrit 443 commentaires

Non le shell c'est nul et compliqué. Il faut le remplacer par des unit systemd (quoi on est pas vendredi :D).

1/ on peut activer sur des tas d’événements et gérer les dépendances, le timer n’est qu’un exemple. Pas seulement à d’autres services : y’a aussi des .device, des .mount, des .path, etc. Je commence à peine à l’utiliser alors je ne sais pas tout ce qu’il est possible de faire avec, mais dans tout les cas, c’est plus qu’avec cron. En fait c’est même pas comparable à cron.

On peut surement faire plein de trucs avec, je n'en doute pas. Moi je me contente de répondre à tes exemples, qui sont gérables facilement avec cron (un outil standard qui existe sur tous les unix du monde). Si tu veux montrer comment c'est bien, donne un exemple qui utilise des fonctionnalités "avancées" et montre comment ça correspond à un besoin réaliste.

2/ non les mails ne sont pas faits pour gérer des logs. WTF !!! (ça c’était pour la petite pique facile…)

C'est un peu un argument d'autorité. Ce n'est probablement pas un très bon outil pour un grand parc, mais pour quelques machines et un client mail un peu valable, c'est un outil de notification assez satisfaisant. Sur un gros domaine, tu va utiliser des outils de supervisions qui vont bien (et dans ce cas là, tu peux utiliser logger(1)).

4/ Plus simple ou plus compliqué ? Question de goût : quand j’ai voulu faire du cron, j’avais trouvé ça chiant.

Ce n'est objectivement pas un argument.

Je ne suis pas certain que comparer le design d'une orange et d'une pomme soit tres pertinent pour ce genre de sujet. Entre autre chose, OpenBSD n'est pas trop repute pour l'acceleration materielle de sa stack graphique

Il dit qu'il ne voit pas le rapport (à par qu'évidemment KMS est nécessaire pour arriver à ce but). L'architecture de séparation de privilège était présente depuis longtemps et Linux aurait pu la mettre en place aussi, sans avoir besoin de systemd. On a l'impression qu'on a besoin de systemd-logind pour arriver à ce résultat (avec des limitations d'autant plus) alors que c'était largement faisable sans tout ce bouzin.

Désolé de répéter la même chose, mais ça parait horriblement compliqué par rapport à cron (crontab -e en utilisateur). On va tourner en boucle sur les arguments sur le fait que cron ne gére pas finelement le problème de la multiple exécution du programme, mais si fetchmail mets plus d'une heure pour récupérer mes mails, y'a un sérieux problème.

Whaou. Très impressionant. Pour remettre les choses en perspective, ça fait un certain temps qu'on peut déjà le faire sous OpenBSD (privilège séparation, tout ça …). Pas besoin d'un truc compliqué comme systemd pour arriver à ce résultat.

En fait, j'ai une machine avec systemd (que je n'utilise pas beaucoup au final). J'ai quand même ragé dessus pour le peu que je l'ai utilisé

systemctl stop wpa_supplicant qui ne répond rien ou OK alors qu'il ne fait rien parce que c'est une dépendence de NetworkManager. Bref. Après un certain temps à râler, j'ai fini par comprendre et j'ai viré NetworkManager (oui je sais, je ne suis qu'un sale barbu).

Par acquis de conscience, j'ai jeté un coup d'oeil (très rapide) au man de systemd et de systemctl et je n'ai rien vu qui permettrait de résoudre facilement le problème énoncé (historique et analyse fine des logs). J'ai sûrement du raté le truc, mais manifestement, les experts systemd n'ont pas envie d'aider les pauvres êtres qui n'ont pas leur clairvoyance.

En une ligne tu checkes la présence du fichier PID, son contenu, s'il correspond à un process en cours d'exécution, si c'est bien une copie de ton script, tu quittes si c'est le cas et tu crées le fichier avec ton propre PID si c'est OK ? Le tout avec du locking pour gérer la concurrence ? Soit tu ne fais pas tout ça, soit tu appelles une fonction qui fait bien plus d'une ligne.

Marrant, tu considère que systemd est une solution simple mais que sourcer un fichier sh et appeller une fonction sh est un truc compliqué. Pourquoi pas. À ce niveau, on ne peut pas dire grand chose hein :)

mail ou syslog pour l'historique… c'est tellement pratique pour sortir des stats, filtrer, etc…

Je ne doute pas que systemd a une solution miracle à ce problème (analyser finement les données de sorties). Quelle est elle ?

Combien de lignes dans le script lancé par cron pour vérifier que la même tâche est pas déjà en cours d'exécution en lisant un fichier PID merdique avec tous les contrôles qu'il faut lui appliquer

Normalement 1 que tu dois mettre dans le shell script, vu que c'est surtout lui qui sait si il a le droit ou non d'être exécuter plusieurs fois en parallèle

Combien de lignes pour gérer le log convenablement ?

Aucune idée de ce que tu entend par là, mais logger(1) peut aider (syslogd(8) peut aider aussi).

Pour avoir l'historique des exécutions ? Savoir si ça s'est bien passé ?

mail(1) ou syslog

Ce code compile déjà en C ou en C++. Quand à ce qu'il fait réellement, c'est un autre problème :)

Déjà, rien que de voir comment tu parles, on voit que tu ne comprends pas le succès de GitHub.
Clone in Desktop.

Super, un outil qui ne marche sur aucun système sur et pour lequel je développe.

Tu en es encore à dire que GitHub est pourri plutôt que de te demander pourquoi il est adoré.

Non, je n'ai jamais dit que Github est pourri. Pointe moi où j'ai dit ça. J'ai dit que ce n'était pas une révolution, j'ai dit que je l'utilisais, et j'ai dit que le workflow de Github n'est pas "plus simple", la preuve en est du tas de "pull request" pourrie que je dois gérer.

La plupart des gens n'ont pas envie d'apprendre la CLI pénible de git. github est ce qui a rendu git utilisable pour le plus grand nombre.

Il n'y aucune façon d'utiliser github correctement sans connaitre git. Remarque, ça explique comment je me retrouve à avoir de nombreuses pull request à partir de la branche master d'un fork, rebasé 12 fois, avec 3 commits sans lien et des commits messages pourris. C'est ça "faciliter le boulot d'un mainteneur".

Le workflow 'normal' d'une proposition de patch pour github à partir de rien, c'est

• se loger sur github : click click
• forker le projet : click click
• cloner ton fork : git clone …. (cli)
• configurer le remote : git remote add … (cli)
• créer une branche feature : git checkout -b my_feature (cli)
• coder, commiter : git add …, git commit (cli)
• pusher sur ma branche : git push origin my_feature (cli)
• resortir son navigateur et appuyer sur pull request (click click + tapoter une explication).

vs

• cloner le dépot : git clone … (cli)
• créer une branche feature (cli)
• coder, commiter (cli)
• préparer un patch : git format-patch master (cli)
• envoyer un mail avec le patch ou ouvrir un bug sur le bug-tracker

Je me demande qui est le plus barbu (ou si c'est pas franchement strictement équivalent).

Non, pas vraiment, c'est un "peu mieux", dans le sens que les applications vont dépendre d'un "runtime", qui contient à priori les "bibliothéques" de base. Mais contrairement à aujourd'hui où il n'y a qu'un "runtime", tu pourra en avoir n en parallèle (il suffit de jouer avec LD_LIBRARY_PATH ou RPATH ou ld.so.conf pour faire la même chose aujourd'hui).

bla bla mailing list

La plupart des mailing-list accepte les mails des gens hors-ml (souvent après modération dans 99% du temps). Donc ce n'est pas un grave problème. D'autant plus que si c'est un simple "bug + patch", le bugtracker est plus approprié (et celui-ci ne spam pas grand chose en général).

Mais il illustre un autre avantage (mineur je le reconnais) de cette incitation au fork : même si un jour le dev initial décide (sur un coup de tête, problème légal,…) de tout supprimer, le code est toujours là. Avantage que n’auront pas les petits projets sur des trucs genre sourceforge.

Euh, par définition, tous les gens qui ont le dépôt git ont la même chose, pas besoin de github …

D'après N3499, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html

Underscores work well as a digit separator for C++03 [N0259] [N2281]. But with C++11, there exists a potential ambiguity with user-defined literals [N2747]. While the likely resolution will be some form of "max munch" rule, some mechanism must be present to disambiguate when max munch is too much.

Que de hargne :) C'est ton opinion, en aucun cas des faits objectifs.

Il me semble que plein de projets arrivent très bien à vivre sans github, avec des mails et des diffs, des petits projets comme "linux", "*bsd", "xorg".

Ce qui t'embète sans doute, c'est de simplifier la vie de mainteneur (sur GitHub, il accepte ou pas ton patch, tout est prêt, pas à s'embeter, ton nom tout ça tout comme il faut, la discussion a eu lieu ailleurs). GitHub est super pour répartir le travail.

Franchement, je ne vois pas ce qu'apporte github de plus réellement (même si je l'utilise beaucoup) à par une "jolie UI web". Pour le mainteneur, c'est kif kif. La partie compliqué de la gestion patches, c'est la discussion et le test, le 'merge' en pratique, c'est peanuts.

Et c'est entre autres pour ça que c'est une révolution, que beaucoup de monde aime, qu'il devient incontournable pour les mainteneurs (et donc par ricochet les contributeurs)

Révolution, révolution, arrête de regarder les shows apple :) C'est une jolie UI web avec un aspect communautaire et une super centralisation (malin pour un protocole décentralisé :D). Même "git" ce n'est pas une révolution, c'est juste celui qui marche (en comparaison à Monotone / Darcs / bazar).

Ce qui prouve une fois de plus l'absurdité du système de moinssage :)

Sauf qu'on a mangé deux "crises" au milieu, la bulle Internet et la "crise de 2007-2020" :D Les banques, en ce moment, elles sont beaucoup plus réticentes à investir.

ufs est supporté dans linux, en tout cas sous sa forme d'ufs2. Ça ne gère probablement pas toutes les fonctionnalités comme softupdates, mais c'est supporté en lecture/ecriture.

Moaui. L'écriture c'est une option de compilation désactivée par défault (et activée par aucune grosse distro je pense). Ça ne supporte que ffsv1 (dans la terminologie NetBSD), pas ffsv2, pas de log, pas de soft update. Bref, en pratique, on ne peut pas écrire :) (et je ne parle pas que faire les différences de terminologies (slice et cie) difficile à récupérer sous Linux). (y'a plus qu'à écrire des patchs :D)

L'ext4 seulement en lecture seulement à partir de maintenant?!

On attendait tes patchs, c'est pour ça :)
Et je ne parlerai pas du support lamentable d'ufs dans linux (je sais, on attend mes patchs ! :D)

-Est-ce que le jeu serait portable sous Android facilement?

Non, la BGE ne tourne pas directement sur Android. Tu peux passer par gamekit qui est un moteur alternatif pour Blender (qui comprend tout ce qui est brique logique) mais le langage de script est lua vs python pour BGE. Donc il faut se retaper un paquet de truc

Est-ce que c'est facile ?

Je ne dirai pas que c'est facile, mais c'est certainement plus facile qu'un "processus classique" pour un jeu. Pas mal de choses sont intégrées de base (son, 3D, physiques, animation, …). L'intégration avec la partie modeling est "parfaite" vu que c'est le même outil. Et tu peux développer des trucs sans savoir vraiment développer à l'aide des briques logiques. Après, dès que tu veux faire des choses compliqués, va quand même falloir comprendre un minimum OpenGL, un minimum la gestion de la physique, … et savoir faire du python.

C'est sûr que la version systemd est beaucoup plus simple, mais gère t'elle vraiment la même chose que le script que tu nous montre ? (rotate, ulatencyd clear ALL …).

En plus, ce script est bien documenté, bien indenté, réutilise des fonctions "standards" (pour l'init dudit système). Bref, pas grand chose à lui reprocher.

Dans NetBSD 7, on pourra, cf la présentation de Marc à ce sujet

https://archive.fosdem.org/2013/schedule/event/lua_in_the_netbsd_kernel/attachments/slides/278/export/events/attachments/lua_in_the_netbsd_kernel/slides/278/kernel_mode_lua.pdf

Après, le nombre d'interface lua dans le noyal existante est assez faible

Oui, je pensais au concept derrière dbus, pas à "l'implémentation de référence"

De quel droit ?

Lis le début du post que tu indique (par exemple
https://bbs.archlinux.org/viewtopic.php?pid=1148064#p1148064)

2.C'est un dev Arch qui parle ici, c'est donc une source officielle.

J'espère que les devs Arch ont le droit a une certaine liberté de parole quand même, i.e. le droit de ne représenter que soit-même et pas forcément l'avis du "projet".

3.Si tu as un lien donne-le. Je vais pas aller fouiller la mailing-list.

Des trolls sur systemd sur les mailing archlinux, y'a l'air d'en avoir eu presque autant que sur linuxfr. Le mail de proposition (publique) de la migration c'est

https://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023389.html

et c'est strictement pas argumenté (encore moins que le thread du forum) (mais ça ne veut pas dire qu'il n'y a pas de discussion avant ou sur des ml privées).

Il s'agit d'udev, pas de dbus.

Oui mea culpa, je n'étais manifestement pas bien réveillé. De toute façon, dbus va aller dans le noyal, ça résoudra le problème :D (et l'implémentation de référence du client sera dans systemd :D)