Anthony Jaguenaud a écrit 1967 commentaires

Je suis en gentoo depuis 2003, malgré les diverses tentative de séparation, je n’ai jamais réussi à me séparer du système de paquet, de la configuration « simple », de la documentation fournie…
Ma femme est passée sous GNU/Linux un peu contrainte… carte mère qui fume, besoin urgent de faire un truc. Windows qui ne reconnaît ni le lecteur CD ni l’interface réseau sur la nouvelle carte mère… reboot sous GNU/Linux installé un an auparavant. Depuis c’est bon, plus de windows et une debian stable.
Les enfants sont sous GNU/Linux debian également. Ils voient du windows à l’école ce qui permet de voir un peu de tout.

Dit autrement, a quand une implémentation d'openssl en rust ?

Si seulement un langage sans possibilité de faille existait… il y a longtemps qu'il serait utilisé.

Merci de l'information.

jessie semble vulnérable

Jessie sera vulnérable encore 15 jours trois semaines. C'est dû au processus de validation des paquets. Ils rentrent dans sid, et si ça ne casse rien, au bout de 15 jours trois semaines, c'est automatiquement descendue dans "testing". Après, il est fortement déconseillé d'utiliser testing à d'autre fin que du test. Le bon choix reste stable ou sid.

C'est la mode de faire une révolution de design avec du retro. Ce n'est pas le cas que dans l'informatique d'ailleurs.

Encore 3.

Encore 52.

Encore 53.

Merci pour la stratégie, j'ai effectivement atteint 2048. Par contre, je n'ai pas compris ta dernière phrase :

maintenant il est plus chronophage ;)

Tu voulais écrire : il n'est plus chronophage.
Ou bien : il est pluS chronophage.

Tiens, je remarque que je ne sais pas écrire "plus" avec le 's' en gras avec markdown.

Après, c'est une question d'habitude, j'ai fait sur un projet une RPP avec un américain, il a justifié de déroger aux règles de codage par : « Vous n'avez qu'à savoir codé ! »
En quoi il n'a pas tort, car finalement les règles de codage limite l'imagination et la compréhension du langage. Et nos experts restent des éternels débutants. D'un autre côté, quand tu passes 2mns à comprendre une ligne, c'est pas forcément très pérenne à long terme pour la reprise du code.

Exemples de perles rencontrées:

// Copie d'une chaine on s'assure que le dernier octets et bien un zéro si ça déborde...
char dest[taille];
strcpy(dest,src)[taille] = '\0';

// Dans un cas on apelle la fonction envoie_reseau et envoie_dbus dans l'autre.
(a < b?envoie_reseau:envoie_dbus)(param1,param2);

Moi, j'aime pas. Le compilateur sait optimiser pour nous. Et les gens qui écrivent ça, c'est généralement avec l'excuse de la performance.

Et bien, je ne trouve pas du tout, je trouve un 0400 bien plus lisible qu'un S_IRUSR | S_IWUSR

Je comprends, puisque S_IRUSR | S_IWUSR devrait être 0600, non ? :-p

C'est plus le rapport d'une anecdote qu'une charge contre systemd. La charge contre systemd, elle vient dans les commentaires, ce n'est pas l'objet du journal.

Moi ce qui m’a surpris, c’est la réaction le Lennart que je traduirai par : « Quoi ? personne n’a essayé sans les cgroup ? »
Après, ils ont une suite de tests automatique, si j’ai bien compris, donc ajouter un test ou au moins ça vautre pas et hop c’est réglé.

C'est parfait ! Comme ça, ça donne du code vraiment portable !

Bah c’est pas grave, systemd n’est pas prévu pour fonctionner avec autre chose que Linux.

Sauf que dans un cas le noyau te dit : "Heu je ne peux pas monter root" et dans l'autre ton init se vautre sans rien te dire, puisqu'il fait un segfault.

Il faut tester le retour de asprintf

Non, sous Linux malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

En soit c'est bug et ça ce n'est pas dramatique, ça se corrige.

Le problème c'est que le logiciel plante. Pour un system d'init, ça semble peu robuste. Si par erreur tu compiles ton noyau et n'inclus pas les cgroup, erreur bête, ben ton PC ne démarre pas correctement. Ce qui semble génant, d'autant que le cas est géré proprement ailleurs dans le code.

Ça semble évident que si la performance est le principal critère, que tu développes une architecture adaptée. Mais dans 99% des cas, les performances sont suffisante en faisant attention à ce qu’on fait. Pour un tri, on peut choisir le tri à bulle pour des petites quantités, mais sinon un bon quicksort c’est mieux.
Mon propos était surtout sur le codage. Si l’architecture ne répond pas au besoin, de toute façon, tu es mal.

On peut optimiser ce genre de chose en C par exemple, je mets côte à côte des champs de structure proche pour le sens, voir des structure de structure. Mais on peut aussi déstructurer pour mettre côte à côte les éléments souvent accédé ensemble… ça rend la structure moins lisible, mais comme les champs on de grande chance d’être sur la même ligne de cache, on gagne en performance. On peut aussi faire du prefetch ça évite de trop déstructurer. On peut aussi éloigner les éléments accédés par des thread différents, surtout si on défini des affinités sur les CPU/cœur.

Mais rendre le code moins lisible doit toujours venir en dernier recours, après l’architecture et le choix des algorithmes ayant les complexités les plus efficaces pour le problème traité.

Je suis d'accord avec toi, j'ajouterai juste qu'il ne faut pas se focaliser sur les perfs au début. C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non. Dans le second cas, il faut faire du profiling pour chercher où gagner des perf. Il vaut mieux gagner 1% de perf dans une routine utiliser 50% du temps que 30% dans une utilisé 1% du temps. Ca semble évident, mais ça ne l'ai pas lors de l'analyse.
Sur les perf, le cache joue mais pas que. J'avais benchmark une petite routine il y a une dizaine d'année sur un power PC. Au premier passage elle prenait 2µs. A partir du second 1.8µs le code était dans le cache instruction. Au 18ième passage, on passait d'un coup à 800ns, dû à la mise en route de la prédiction de branchement et au non vidage des caches.

Une chose me semble évidente, c'est qu'un compilateur fera toujours mieux que nous. Sauf peut-être à passer 2 mois sur 50 lignes de code.

Le point que tu rates dans l'analogie, c'est que moi, utilisateur et pas développeur, je veux avoir mon mot à dire sur les outils des développeurs (que je ne rémunère pas qui plus est), et je leur demande d'en chier parce que je ne veux pas avoir à faire à leurs nouveaux outils.

Le point que tu rates dans ton analogie, c’est qu’on parle bien d’IDE, je t’aide : Integrated Development Environment. Donc oui, pour un développeur je ne trouve pas ça déconnant.
Pour un admin système, il y a plusieurs niveau. Mme Michu, elle s’en fout, elle ouvrira pas de fichier systemd. L’admin de base fera confiance à sa distrib, avec peut-être une modif ici ou là, mais ce sera un copier/coller d’un forum.
L’admin expert, lui, avoir une machine de turing pourrait l’aider, mais pas forcément tout le temps.

Au départ, je ne voulais pas réagir, car les pro-systèmed sont largement majoritaire, et que ceux si ont tendance à insulter directement les autres. Mes réactions n’ont eu pour but que de relever des arguments que je trouve non pertinent, (le beau code parce qu’il utilise des extensions d’un compilateur…) en aucun de mettre en doute la sacro-sainte parole.

Ça me rappelle une étude sur les utilisateurs d’apple dont la marque éveillait dans le cerveau les mêmes zones que la foi. Et j’ai parfois l’impression que c’est pareil pour les pro-systemd. On ne peut argumenter ne serait-ce qu’un cas sans en prendre plein la tronche gratos. C’est quoi la prochaine étape, venir nous démolir la tronche ?

J’aimerai vraiment pouvoir discuter dans ce débat sereinement. Systemd apporte des évolutions sympas, tout le monde n’en ressent pas le besoin, et certains critique sa vampirisation de truc comme udev. Est-ce un délit ? Devrait-ce être un délit ? Faut-il prévenir l’exécutif ?

Dans le débat, si on prend les mots violent, de dénigrement et qu’on classe cela entre les pro et les anti, car apparemment on a pas le droit d’être juste perplexe, je suis certain de savoir de quel côté est la violence des mots.

sur ce à la prochaine.

Sinon moi je ne fais pas de développement, alors ce serait bien qu'on arrête de passer du temps sur ces absurdités de IDE et autre RAD et qu'on revienne à des choses simples et prouvées telles que Emacs/Vim, un Makefile fait à la main, et la compilation en ligne de commande dans un autre terminal. Ça a marché pendant des années, c'est le summum de la souplesse parce qu'il n'y a aucun cas de figure qui ne soit pas faisable, alors qu'un outil d'aide au développement peut mettre des restrictions à cause de conventions ou de la logique interne.

Je trouve ton analogie excellente. Dans un cas, tu as un produit globalement fini, mais limité par design. De l'autre tu as un outil tellement ouvert qu'il a l'air inaccessible.

Que certains préfère une solution plutôt que l'autre justifie-t-il de traiter les minoritaires de relou, réfractaire, etc. ?

Salut,
Pour aider la mise à jour de OSM, y-a-t-il une application adroid ayant une interface très simple, utilisable en conduisant.
Du genre :

1. Choix d'une couche (ex: vitesse limite)
2. Affichage de l'information actuelle en fonction de la couche en cours.
3. Un affichage des limitations possibles.
4. On appuie directement sur la limitation de vitesse en cours, et au moment des changement.

OSM tracker n'est pas mal, mais je n'ai pas trouvé comment faire en conduisant en sécurité.

Chez moi aussi, pas de ralentissement…

Par contre, dans dolphin, la recherche n'a pas l'air au top… du coup c'est activé, mais mes amis reste find et grep.

Je me vois mal faire du ssh client sur un serveur mail ou web.

Mais telnet oui. euh… OK, tu évites bien soigneusement de répondre à la question, c'est un signe.

Non, tu n'as pas compris la réponse. Je t'invite a essayer : telnet www.google.fr 80 puis GET index.html (ou quelque chose de proche).

Bah vu que systemd ne comprends ni les descriptions en anglais ni les pages de man, ces métadonnées ne pouvait être destinées qu’à un outil client…

C'est amusant, il y a deux cas :
* Les scripts c'est pourri par ce que quand on connaît pas ça semble compliqué.
* Systemd c'est simple.

Sauf que moi, je connais et comprends les scripts. Le fait que les métadonnées ne pouvait être destinées qu'à un outil client te semble évident parce que tu connais l'outil. Admettre que tout n'est pas limpide pour quelqu'un qui ne connais pas l'outil est trop dur pour votre égo ?

gentoo utilise des « runlevel » nommé par exemple.

2e et 3e ligne c'est pour systemctl ça me parait évident.

Ce n’était pas évident pour moi non plus. Mais je suis un peu neuneu.

a dernière ligne, c'est pour indiquer l'équivalent du runlevel (mais bien plus puissant) côté systemd. Sauf qu'au lieu d'avoir des numéros imbitables, on a directement le nom. Léger avantage systemd.

Pour l’avantage, certaines distribution utilise aussi des « runlevels » nommé, oups, ce n’est pas une exclusivité.

Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.

Ben si, /etc/init.d/