Anonyme a écrit 62265 commentaires

Ben, justement, tu n’es pas dev C. Et encore moins dev apparemment.

Ouais, c'est super sympa pour les mainteneurs des distributions qui décideront d'organiser le système autrement. C'est juste de l'égoïsme, "Moi je ne vois pas pourquoi je changerais ça, donc je le met en dur". 1) tu n'es jamais sûr que tu n'auras pas besoin de le changer, et 2) tu n'es jamais sûr que quelqu'un d'autre n'aura pas besoin de le changer.

La question c'est, est ce qu'il y a une raison valable pour voulloir changer ca. Si il n'y en a pas, alors il ne faut pas qu'il y ait d'option pour le changer:
- ca simplifie le code
- si l'option est la, des gens vont l'utiliser sans reflechir et rajouter des incompatibilités entre distributions pour rien
- si quelqu'un a une raison valable pour changer ca, il est toujours possible d'envoyer un patch pour rajouter l'option

Au hasard si je regarde le code de procps, on trouve des trucs comme ca:

if (!freopen("/proc/self/maps", "r", stdin))

https://gitorious.org/procps/procps/source/9c7e8b82f872e2d46ce866255ff132e0e6a0f937:pmap.c#L156

Mon dieu procps hardcode des chemins dans son code ! Et un grep '/proc' dans les sources montre qu'il y en a plein.

Le truc que toi tu as du mal à comprendre c'est que tu as rien relevé du tout. On peut pinailler sur ce genre de trucs sur le code du noyau de la meme facon et sur à peu près 100% du code qui existe partout ailleurs.

Bah, par exemple, à la problématique du type qui gère une distribution et qui ne veut pas que les applications décident à sa place de l'arborescence du système?

Et le type qui veut mettre la liste d'utilisateurs dans /etc/utilisateurs plutot que /etc/passwd, remplacer /proc par /processus, /var par /données, il fait comment ?

Effectivement, mais ca ne change pas grand chose, dans les 2 cas ca ne fonctionne pas.

Ca serait mieux si systemd gerait correctement ce cas la, mais ca n'a rien d'un bug critique. Et Lennart ne semble pas etre contre un patch qui ameliore les choses. Donc en fait je vois pas quel est le problème et ce que le lien vers ce bug était censé montrer.

Sans passer par là, une simple constante définie dans un fichier regroupant toutes les constantes.

Ca servirait à quoi, à part compliquer le code en rajoutant un doute sur la valeur de la constante ?
Les constantes c'est utile pour une valeur utilisée à plusieurs endroits et susceptible de changer un jour. Pour quelquechose qu'on prevoit de ne pas changer, ca complique pour rien.

Si par erreur tu compiles ton noyau et n'inclus pas les cgroup, erreur bête, ben ton PC ne démarre pas correctement.

Oui, et si par erreur tu compiles ton noyau et n'inclus pas le driver pour ton disque, ton PC démarre pas non plus. Donc rien de nouveau, si tu compiles ton noyau en incluant pas ce qu'il faut, il est possible que ca ne boot pas, avec ou sans systemd.

Exemple : ligne 123 à 234, avec un mélange de if avec blogcs entre {}, et sans {}, des else if imbriqués dans tous les sens, qui fait qu'on a du mal à voir ce qui se passe.

Les blocks avec {} ou pas suivant si il y a plusieurs lignes ou pas, c'est aussi le coding style utilisé pour le kernel. Mais personne ne parle de code spaghetti pour le kernel. Et le niveau d'imbrication ne me semble pas non plus extraordinaire.

A mon avis ce code est trop long et aurait du être splitté en plusieurs fonctions.

Moi je ne suis pas certain que splitter cette fonction simplifie quelquechose.

Personnellement je ne vois pas en quoi ca serait du code spaghetti.

J'ai lu rapidement tty-ask-password-agent.c, et il ne m'a pas semblé particulierement complexe de comprendre ce que ce code fait. Ca me semble etre fait de facon assez propre.

Et quel est le problème avec ce bug ?

systemd a besoin des cgroups pour fonctionner, c'est pas nouveau.

Au bout de quelques échanges assez vifs, Kay Sievers a fermé le ban (et le
ticket bugzilla!) en déclarant qu'il ne s'agissait en aucun d'un bug (en tout
cas, pour lui, ça ne concerne pas systemd).

Pas exactement. Il a expliqué que bugzilla n'est pas fait pour les discussions, et demandé d'en parler plutot sur la mailing list. Ce qui ne me semble pas forcement une mauvaise idée: reserver bugzilla pour suivre les taches en cours ou il y a réellement quelquechose à faire, et utiliser la mailing list pour les discussions ou tout le monde n'est pas encore tombé d'accord sur ce qu'il fallait faire.

Et sinon des desaccords entre differentes personnes sur des projets open source, il y en a tous les jours, ca n'a rien d'exceptionnel. Sauf que la ca concerne systemd donc t'as des gens qui sont la pour profiter de chaque occasion pour sortir un "ca traduit bien un état d'esprit de la part des développeurs de systemd".

Bizarrement j'utilise OwnCloud6 (dernière en date) sans aucun problème. Pourrais-tu préciser tes conditions d'utilisation, qui doivent manifestement être différentes des miennes ?

Un avantage de Grisbi est son format de fichier assez simple. Cela permet d'ecrire assez facilement des scripts qui vont lire un fichier grisbi pour faire ce genre de pages:
http://treasurer.mageia.org/

traytraybon :)

pour ton 1)

100 % des utilisateurs disent la verité

pour le 2)
je n'explique jamais rien, car la personne en face n'a pas le meme niveau que moi, il faudrait d'abord que je le mette a niveau, puis que je fasse une these pour lui expliquer pourquoi ca marche pas.

3) si il insiste, j'aime bien raconter une histoire qui n'a rien avoir, celle qui passe le mieux c'est : ah mais c'est comme l'accident nucleaire de three miles island ! je te raconte … .

elle est bien longue si il décroche avant la fin c'est qu'il s'en tape et la conclusion me plait :

Il n'est plus demandé aux opérateurs de comprendre ce qui se passe (car il y a de très grandes
probabilités pour qu’ils se trompent, aussi compétents soient-ils), mais il s'agit de leur donner des actions à faire en fonction des paramètres dont ils disposent. C’est ce qui s’appelle « l’approche par état ».

pour les liseuses j'avais tenté quelques livre SF en anglais mais même si cela amélioré ma compréhension de l'anglais écrit, j'avais toujours du mal pour la compréhension de l'anglais parlé.

et je veux absolument améliorer ma compréhension, et si possible devenir bilingue.

partant d'un niveau médiocre éducation nationale, j'ai mis un coup de fouet a ma compréhension avec les pages de man de linux en anglais et surtout des serie/film chinois, Coreen sous titré en anglais. chinois et koreen car ils gerent les droit d'auteur plutôt "a leur facon". :

1. les sous titre c'est de l'anglais parlé ecris :), du coup cela permet de tenir une conversation rapidement
2. il y a pas mal de sujet abordé le champ est vaste donc c'est assez cool
3. grâce au point droit d'auteur les tracker ne ferme pas les portes de manière brutale avec les serveurs à la police. J'en suis sur un depuis presque 6 ans ! mais ca peut changer
4. j'ai améliorer mon allemand assez facilement avec ce principe, mais j'aime regarder les série de coree ou de chine.

il y a un défaut quand même, pour parler j'y arrive mais c'est plus dure que la compréhension, j'arrive tenir des réunion téléphonique en anglais (accent français) mais je suis littéralement mort de fatigue a la fin.

bilingue ? 2 langue ? je n'y crois pas, il y a le son que ta langue et respiration doive produire, cela ce met en place vers l age de 5 ans, passé cette étape c'est assez dur de perdre son accent sauf a travailler beaucoup pour gagner pas grand choses :).

Sans blague.

C’était une blague qui n’avait pas vocation à refléter toute la réalité de ce bas monde. Mais si tu préfères quelque chose de plus proche, locate te conviendrait-il ?

Ben quoi ? Tu n'aimes pas compiler gcc//glib/gtk sous Windows et Mac OS ?

Je vais enfin pouvoir me la couler douce et faire le glandu de base qui ne connaît pas find ;D

Comme tu le dis très bien, le kernel a une politique de zéro régression, ce qui n'a jamais été le cas de systemd.

J'ai du mal à comprendre ce que ca vient faire la.

Tu veux dire que systemd aurait une politique de "le plus de régressions possible" ? Et pour cette raison le nombre de bugs ouverts sur le kernel n'a aucune importance et ne montre rien concernant sa stabilité, contrairement à systemd ou le nombre de bugs ouverts est bien une preuve du manque de stabilité ?

Il suffirait donc que Lennart déclare "on a une politique de zéro régression" pour du jour au lendemain etre considéré comme un logiciel stable ?

Ah, ça y est, on en est là: Il faut absolument du time to market, y compris en pondant du code dégueulasse architécturé comme les téléphonistes le faisait même pas il y a 20 ans ?

Sauf que ce code dégueulasse et architécturé n'importe comment:
- il fonctionne
- il est plutot fiable. En tout cas suffisement pour qu'un grand nombre de distributions aient décidé de se baser dessus pour un composant critique.
- il ne semble pas poser de problème particulier à ses mainteneurs qui se débrouillent visiblement bien pour le faire evoluer sans tout casser.

Après, qu'il ne plaise pas à un expert autoproclamé en qualité de code, c'est pas très important.

Masquer un bug sur une fonctionnalité qui n'a plus aucun interet.

Mais c'est systemd, il faut forcement trouver un truc negatif.

gitlab, par rapport à ma première installation qui date de la version 5, s'est grandement amélioré. Et si les gems peuvent être un problème car installées à La RACHE®, aujourd’hui, j’oserais dire qu’il y a les conteneurs, voir même les chroot si on n’a pas comme objectif la sécurité ;)

La documentation est bien foutue, les guides d’upgrade sont foutrement terribles et faciles d’accès, donc changement de version de Ruby à part, c’est très simple et ça se préprod facilement ;)