C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros.
Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.
Ensuite, par essence, une application KDE ou GNOME va faire appel à pas mal de bibliothèques que les autres applications de cet écosystème utilisent aussi. Ces écosystèmes étant gros, les runtimes le font aussi. Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.
Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.
Ça donne l'impression que c'est avec des œillères, il y a d'autres solutions qui existent depuis plus longtemps ça aurait était intéressant de faire un état de l'art avant de pondre quelque chose et pas que d'un point de vu technique mais aussi d'un point de vu écosystème.
L'état de l'art a été fait, et Flatpak a trouvé des solutions pour conserver la flexibilité d'installation, avoir un bac à sable tout en évitant d'avoir un système trop lourd et difficile à maintenir en terme de sécurité. Aucune solution existante ne permettait de gérer tout ça à la fois. Surtout l'aspect bac à sable par ailleurs qui est manquant et non trivial à implémenter.
Attention à ne pas tout confondre. Je ne suis pas expert du sujet d'autant que la terminologie est ici assez confuse. J'espère ne pas me planter.
D'abord Silverblue tire origine du projet Atomic d'un point de vue historique, il est normal de parler d'Atomic car c'est évidemment comme cela que ça s'est construit.
Ensuite, de ma compréhension, le projet Atomic en tant que tel n'est pas mort. D'ailleurs Atomic en lui même n'est qu'une collection d'outils, d'une conception particulière. Silverblue utilise toujours ces outils et n'a pas changé de conception non plus.
Ce qui a changé c'est que Fedora Atomic, qui est le nom de l'ancien Fedora Cloud en se basant sur le projet Atomic, a changé pour devenir Fedora CoreOS. Pour notamment tirer profit de CoreOS qui a été racheté par Red Hat et dont le but de ce système collait parfaitement avec le besoin de Fedora Cloud / Atomic. Ce qui en tant que tel n'a pas d'impact pour Silverblue car c'est un produit indépendant. Et Silverblue ne cherche pas à exploiter CoreOS car le but diffère quelque peu sur ce point : sa cible c'est un ordinateur personnel, pas d'être en lui même dans un conteneur pour lancer une application.
Il y a un fichier json dans le répertoire /home (mais pas dans le répertoire /home/user qui est lui chiffré) qui contient les informations relatives au compte : groupes, ID, potentiellement ces données, etc.).
Oui, je ne dis pas spécialement le contraire tu noteras.
Avoir une swap égale à la RAM est utile pour hiberner, ou alors cela signifie que tu as beaucoup de RAM qui ne sert à rien l'essentiel du temps quand tu as besoin d'hiberner. C'est plus une précaution qu'une nécessité dans mon message.
Après se tromper dans l'accès à un tableau signifie que tu n'as au choix :
Pas vérifié la taille du tableau avant l'accès ;
Pas utilisé d'itérateur.
Ce n'est pas bien.
En plus je suis toujours dubitatif de recevoir une erreur pour ça. Tu en fais quoi, de cette erreur au runtime ? Étant donné que c'est surtout un problème de bonne pratique plus que d'une erreur légitime.
Or, être capable de détecter cette erreur au runtime a un coût non nul. Ça peut se comprendre qu'ils décident de ne pas le considérer comme une erreur valide.
Je précise que la plupart des langages modernes agissent ainsi malgré une meilleure préoccupation de la gestion des erreurs qu'à l'époque du C. Je pense à Rust notamment où l'accès direct hors du tableau est possible et génère une belle erreur de segmentation à l'ancienne.
L'hibernation c'est copier l'intégralité de la RAM dans la swap pour pouvoir couper l'alimentation électrique totalement (donc aucun risque de perte de données en cas de coupure de courant entre temps).
Au redémarrage, la machine restaure l'état de ta mémoire entièrement.
Ta swap doit avoir de libre au moins la taille totale de la mémoire allouée. Donc en général, au moins la taille de ta RAM soit ici 8 Gio.
Le swap est indispensable pour l'hibernation (donc ceux qui s'en servent en ont besoin).
Sinon le swap reste utile. Sur mon portable je ne pourrais pas travailler sans, quand une compilation Yocto a des pics de besoin de mémoire que ma machine ne peut satisfaire, le swap récupère les pages inutiles de la RAM.
La swap est utile dans une certaine mesure pour récupérer les pages inutilisées pour maximiser la taille des caches du système ce qui améliore les performances. Si ta RAM est trop limite par rapport au besoin évidemment. C'est-à-dire quand il est fréquent que tu utilises plus de 75% de ce dernier.
Mais après quand ça swappe trop, la machine est en effet inutilisable. Cela m'est arrivé quelques fois, 3-4 Gio de swap sur le SSD, il était impossible de sauver la machine sans l'éteindre brutalement.
Pas encore, les discussions internes parlaient du premier semestre 2020. Mais difficile de dire si le planning initial sera maintenu dans la situation actuelle.
Qui sait, peut être demain lors de l'annonce de sortie !
Pour information OS/2 était à la base une collaboration entre IBM et MS. Suite à un désaccord, MS a poursuivi son travail exclusivement sur Windows tandis que IBM a repris la charge de OS/2 mais sans succès pour ce dernier.
Ce n'est en effet pas une source d'énergie perpétuelle. ;)
Techniquement d'ailleurs, ce n'est pas une source d'énergie en tant que telles : ces ondes électromagnétiques sont faites par l'Homme pour émettre la radio, le wifi, etc.
L'idée est donc que certains appareils peu gourmands et portables puissent récupérer cette énergie disponible un peu partout plutôt que de réclamer de l'énergie additionnelle.
Ce serait une forme d'optimisation pour réduire la consommation de ces appareils. Mais si jamais tu n'as pas de l'énergie primaire suffisante pour générer ces ondes, ça ne pourra pas fonctionner. :)
D'où le fait que ce soit une source d'énergie me paraît assez impropre.
Comme barmic l'a dit tu écris et publies ce que tu veux, c'est ton droit.
Non ton code n'est clairement pas parfait, il ne faut pas le prendre mal, j'ai donné les éléments qui m'ont sauté aux yeux pour que tu puisses faire mieux la prochaine fois. Moi aussi j'ai écrit (et j'écris à l'occasion) du code sale. Et je suis content quand quelqu'un m'explique ce que je pourrais améliorer.
Bref, ne prends pas la mouche, il n'y a pas de raisons…
Une erreur de quoi ? Il ne s'agit pas d'une erreur, je sais très bien que systemd est plus qu'un système d'init et c'est bien ça que je lui reproche.
Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.
Comportements qui posent problème lorsque tu n'es pas dans les cvlous. Systemd oblige ton besoin à s'adapter à l'outil, plutôt que de s'effacer et de laisser l'admin faire ce qu'il a a faire.
Sur la plupart des OS qui implémentent le même type d'approche, la plupart du temps, tu as tout ce qu'il faut pour configurer un service proprement. Et dès que tu as un besoin qui sort de ce qui t'es proposé" tu peux implémenter le comportement que tu veux. Rien n'oblige de le faire en shell, tu peux le faire avec du python, du ruby, lua, ou n'importe quoi d'autre.
Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie… Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.
Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.
J'aime pas les trucs qui me cachent des choses.
Rien n'est caché, le code de systemd est dispo si tu y tiens.
Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.
Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.
Oui enfin, quand un service fait les choses différemment des autres c'est bien souvent parce qu'il a besoin de faire les choses différemment.
Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.
Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.
Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.
Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.
Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.
En fait, une phrase résume bien la raison pour laquelle je n'aime pas systemd : "A full exposition of systemd would take a book on its own." alors que les systèmes d'init plus classiques n'ont besoin que d'un chapitre dans un bouquin d'admin système, et de connaitre un peu le scripting shell pour être compris.
Je pense que la véritable erreur est là. systemd n'est pas juste un système d'init, c'est une collection de services bas niveau dont gestionnaire d'init mais aussi de session, etc. Donc il est normal qu'il soit plus complexe et complet, l'ensemble des parties de systemd est bien plus vaste que init.
En plus systemd a de nombreux comportements qui sont fournis d'entrée de jeux. Il suffit de configurer le service pour exploiter le comportement qu'on veut. init de SysV est vraiment rudimentaire, la complexité est en fait dans le script shell du service et tu dois tout faire à la main. Donc oui systemd est complexe à côté, mais la complexité est cachée à l'utilisateur et assumé de manière commune à tous les services.
Et systemd peut prendre en charge de manière uniforme tous les services, configurer SELinux, le redémarrage en cas de crash de l'application, etc. Avec init chaque service le fait à sa sauce, parfois ne le gère pas, parfois de manière différente d'un autre, etc. Bref, ce n'est pas parfait non plus…
Il faut comparer ce qui est comparable, systemd n'est pas qu'un système d'init et au niveau fonctionnel systemd gère la complexité lui même et ne la reporte pas sur le shell et les scripts de démarrages de chaque service.
Moins de femmes très malades que d'homme (c'est dit partout), par contre je me suis trompée d'hormones, ce sont les œstrogènes, désolée.
Oui, malheureusement c'est bien une corrélation et non une causalité. Difficile de dire si ce sont les hormones ou autre choses qui peuvent l'expliquer à ce stade. Comme l'indique la page que tu cites d'ailleurs.
Après attention à faire la différence entre corrélation et causalité. En particulier en médecine où les corrélations sont nombreuses avec une causalité cachée.
cela fait quand même 2 ans que les service hospitalier et d'urgence font des grèves pour attirer l'attention sur le drame qui s'y passe, ce n'est pas au 1 mars. je rappel ce magnifique journal :
Je ne vois pas le rapport.
Non pas qu'un système hospitalier à bout de souffle soit souhaitable ou que cela n'a pas accru certaines difficultés, mais la crise liée au coronavirus n'a que peu à voir finalement avec le système de santé en tant que tel.
D'ailleurs globalement les hôpitaux ont su tenir la charge au niveau nationale et il aurait fallu un budget totalement irréaliste pour avoir assez de lits et de personnels pour faire face à une vague non contrôlée par des mesures fortes.
D'ailleurs on le voit, tous les pays ont dû prendre des mesures fortes pour y mettre fin. Même ceux avec pourtant de bonnes capacités hospitalières car toute façon aucun système hospitalier ne peut faire face à une vague non contrôlée. Et la France d'ailleurs n'est pas si mal que ça sur ce critère.
Le problème est plus dans l'anticipation et la prévention, mais ce n'est pas simple. C'est un virus nouveau, il a fallu ingérer de nouvelles données constamment, les réactions trop virulentes de nos précédents gouvernements face aux précédentes épidémies asiatiques ont sans doute refroidi les gouvernements actuels de faire pareil cette fois pour une maladie finalement peu létale en elle même.
En tout cas ça permet de révéler certaines choses qui permettront de mieux gérer une telle situation si elle se reproduit, et pour le dé-confinement.
Bref, la gestion de l'épidémie aurait été tout aussi difficile même avec des services hospitaliers au taquet. Car pour faire face à une horde de malades, tu ne peux pas surdimensionner le système autant.
Tu penses vraiment que c'est grâce au confinement strict (c'est à dire que l'on oblige par la loi à ne pas sortir de chez soi) que l'Allemagne, les Pays-bas et la Suède n'ont pas eu à se confiner ?
À part la Suède que je ne connais pas, les autres pays ont quand même des restrictions strictes à défaut d'un réel confinement. Ce n'est pas faites ce que vous voulez. Donc ne crois pas que chez eux le virus n'a aucun impact alors que chez nous c'est sévère, pour l'Allemagne aussi l'économie va souffrir, les allemands aussi subissent des restrictions légales fortes.
Et la Corée du Sud ? Et Taiwan ? C'est grâce à nous également ?
La Corée du Sud et Taiwan ont l'expérience des épidémies asiatiques de ces 20 dernières années, ça aide à se préparer et à avoir citoyens comme politiciens au taquet.
Ensuite ils ont eu massivement recours à des technologies qui hérissent le poil à certains ici pour faire du confinement très ciblé. Niveau liberté individuelle et vie privée c'est assez limite par rapport à ce qui est autorisé en Europe à ce sujet.
Donc oui ils s'en sortent bien mais ils ont fait des choix. Ce n'est en tout cas uniquement parce que le citoyen local est plus consciencieux.
Comment se fait-il qu'en Allemagne, au Portugal ou même aux Pays bas et en Suède (même si l'histoire n'est pas finie), les modèles ne fonctionnent pas de la même façon (moins de conséquences sur le social et l'économie et également moins de morts) ?
Car l'épidémie n'est pas quelque chose de uniforme que ce soit dans une région ou dans le monde.
Tout d'abord un R0 n'est pas une valeur constante liée au virus. Elle dépend énormément de la densité de population, des échanges au sein de celles-ci, des habitudes culturelles, etc.
Chaque pays a des habitudes et une structure de sa population qui impacte +/- la contamination. D'où le fait que de comparer la situation en Suède avec la France de manière directe n'a pas un grand sens.
Ensuite une épidémie dépend beaucoup des échanges au sein de la population. Plus on tarde à limiter ces échanges au début, plus les conséquences seront fortes et dans la durée. Mais d'ailleurs on le voit, en France l'épidémie a surtout touché le Nord, l'Est et Paris. Le confinement a stoppé les flux avec les autres régions de manière suffisamment forte que les cas sont restés concentrés dans ces régions.
C'est d'ailleurs le cas en Italie ou Espagne où les régions très peuplées et touchées au début de l'épidémie qui concentrent l'essentiel des cas, les régions plus éloignées et moins dense ont profité du confinement pour stopper assez tôt la propagation.
C'est aussi probablement ce qui a aidé à protéger certains pays comme l'Allemagne ou la Suède qui ont été probablement moins touchés à l'origine. Et les mesures prises localement et par les pays voisines ont été suffisamment efficaces pour que le confinement général ne soit pas nécessaire.
De même qu'il n'est pas sûr que de nouveaux confinements soient nécessaires chez nous à l'avenir même si ça remonte. Par contre la vie normale comme avant sans restrictions cela mettra du temps à se revenir oui.
Le code reste quand même assez discutable. Même si cela reste un petit bout de code il y a de quoi améliorer
Déjà les macros CHECK_ERR et INT_ARG n'ont aucun intérêt, faire des fonctions à la place serait plus lisible et permettrait au compilateur de produire des messages d'erreurs plus sympas.
D'autant que le second est erroné. Il fait appel à des variables qui ne son présentes que dans main et qui ne sont pas passés en paramètres. Donc en somme cette macro n'est pas réutilisable alors que cela ne coûterait rien de le faire en fonction.
char* endptr = 0;
Il est préférable d'initialiser un pointeur à NULL plutôt que 0.
if( !*arg || ( *arg && **arg != '-' ) )
Il vérifie que l'argument débute par un tiret mais ne vérifie pas la taille pour être sûr que l'argument a bien plus d'un caractère ce qui serait je pense pertinent.
Puis il vérifie deux fois que arg n'est pas nul, c'est inutilement redondant.
Ce n'est pas une erreur en soi mais la ligne me semble inutilement longue et complexifie la lecture de la boucle. La commande devrait être dans le corps de la boucle quitte à utiliser un do while qui serait plus judicieux ici.
Globalement le main je le découperais en plein de fonctions encore, il y a moyen.
Bref, c'était ma revue de code. Elle vaut ce qu'elle vaut.
La courbe en S est le bon modèle quand tu es en mode on ne fait rien où la seule limite pour propager le virus est de trouver de nouveaux malades potentiels, donc non infectés par le passé.
Après pour modéliser les mesures d'un confinement, il ne fonctionne pas, car il faudrait modéliser proprement l'impact réel du confinement mis en place ce qui n'est pas évident du tout et très variable d'un pays à l'autre.
[^] # Re: Intéressant
Posté par Renault (site web personnel) . En réponse à la dépêche Présentation de Fedora Silverblue. Évalué à 4.
Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.
Ensuite, par essence, une application KDE ou GNOME va faire appel à pas mal de bibliothèques que les autres applications de cet écosystème utilisent aussi. Ces écosystèmes étant gros, les runtimes le font aussi. Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.
Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.
L'état de l'art a été fait, et Flatpak a trouvé des solutions pour conserver la flexibilité d'installation, avoir un bac à sable tout en évitant d'avoir un système trop lourd et difficile à maintenir en terme de sécurité. Aucune solution existante ne permettait de gérer tout ça à la fois. Surtout l'aspect bac à sable par ailleurs qui est manquant et non trivial à implémenter.
[^] # Re: Mais où est CoreOS ?
Posté par Renault (site web personnel) . En réponse à la dépêche Présentation de Fedora Silverblue. Évalué à 8.
Attention à ne pas tout confondre. Je ne suis pas expert du sujet d'autant que la terminologie est ici assez confuse. J'espère ne pas me planter.
D'abord Silverblue tire origine du projet Atomic d'un point de vue historique, il est normal de parler d'Atomic car c'est évidemment comme cela que ça s'est construit.
Ensuite, de ma compréhension, le projet Atomic en tant que tel n'est pas mort. D'ailleurs Atomic en lui même n'est qu'une collection d'outils, d'une conception particulière. Silverblue utilise toujours ces outils et n'a pas changé de conception non plus.
Ce qui a changé c'est que Fedora Atomic, qui est le nom de l'ancien Fedora Cloud en se basant sur le projet Atomic, a changé pour devenir Fedora CoreOS. Pour notamment tirer profit de CoreOS qui a été racheté par Red Hat et dont le but de ce système collait parfaitement avec le besoin de Fedora Cloud / Atomic. Ce qui en tant que tel n'a pas d'impact pour Silverblue car c'est un produit indépendant. Et Silverblue ne cherche pas à exploiter CoreOS car le but diffère quelque peu sur ce point : sa cible c'est un ordinateur personnel, pas d'être en lui même dans un conteneur pour lancer une application.
[^] # Re: Comment ça marche ?
Posté par Renault (site web personnel) . En réponse au lien [en] Lennart Poettering veut prendre ses aises dans votre $HOME. Évalué à 3.
Il y a un fichier json dans le répertoire /home (mais pas dans le répertoire /home/user qui est lui chiffré) qui contient les informations relatives au compte : groupes, ID, potentiellement ces données, etc.).
[^] # Re: Go est lent, Rust est rouillé !
Posté par Renault (site web personnel) . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 4.
Oui tout à fait, je me suis mal exprimé sur ce point.
Mais cela ne change rien, tu ne récupères pas une erreur que tu peux traiter normalement.
[^] # Re: Mise en veille
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 4.
Oui, je ne dis pas spécialement le contraire tu noteras.
Avoir une swap égale à la RAM est utile pour hiberner, ou alors cela signifie que tu as beaucoup de RAM qui ne sert à rien l'essentiel du temps quand tu as besoin d'hiberner. C'est plus une précaution qu'une nécessité dans mon message.
[^] # Re: Go est lent, Rust est rouillé !
Posté par Renault (site web personnel) . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 5.
Après se tromper dans l'accès à un tableau signifie que tu n'as au choix :
Ce n'est pas bien.
En plus je suis toujours dubitatif de recevoir une erreur pour ça. Tu en fais quoi, de cette erreur au runtime ? Étant donné que c'est surtout un problème de bonne pratique plus que d'une erreur légitime.
Or, être capable de détecter cette erreur au runtime a un coût non nul. Ça peut se comprendre qu'ils décident de ne pas le considérer comme une erreur valide.
Je précise que la plupart des langages modernes agissent ainsi malgré une meilleure préoccupation de la gestion des erreurs qu'à l'époque du C. Je pense à Rust notamment où l'accès direct hors du tableau est possible et génère une belle erreur de segmentation à l'ancienne.
[^] # Re: Mise en veille
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 6.
L'hibernation c'est copier l'intégralité de la RAM dans la swap pour pouvoir couper l'alimentation électrique totalement (donc aucun risque de perte de données en cas de coupure de courant entre temps).
Au redémarrage, la machine restaure l'état de ta mémoire entièrement.
Ta swap doit avoir de libre au moins la taille totale de la mémoire allouée. Donc en général, au moins la taille de ta RAM soit ici 8 Gio.
[^] # Re: doublons avec Machines ?
Posté par Renault (site web personnel) . En réponse au lien GNOME Connections, a remote desktop client for GNOME : first public release. Évalué à 3.
Apparemment Machines est destiné aux cas plus complexes, qui nécessitent plus d'options.
Les deux utilisent le même code derrière donc c'est surtout une question d'interface et de simplicité d'usage.
[^] # Re: Mise en veille
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 2. Dernière modification le 28 avril 2020 à 10:58.
D'autant qu'il y avait des moyens pour ajouter ce bouton à côté des autres. Comme des extensions.
[^] # Re: earlyroom
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 5.
Le swap est indispensable pour l'hibernation (donc ceux qui s'en servent en ont besoin).
Sinon le swap reste utile. Sur mon portable je ne pourrais pas travailler sans, quand une compilation Yocto a des pics de besoin de mémoire que ma machine ne peut satisfaire, le swap récupère les pages inutiles de la RAM.
La swap est utile dans une certaine mesure pour récupérer les pages inutilisées pour maximiser la taille des caches du système ce qui améliore les performances. Si ta RAM est trop limite par rapport au besoin évidemment. C'est-à-dire quand il est fréquent que tu utilises plus de 75% de ce dernier.
Mais après quand ça swappe trop, la machine est en effet inutilisable. Cela m'est arrivé quelques fois, 3-4 Gio de swap sur le SSD, il était impossible de sauver la machine sans l'éteindre brutalement.
[^] # Re: Petite bourde des modérateurs
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 6. Dernière modification le 27 avril 2020 à 22:29.
Pas encore, les discussions internes parlaient du premier semestre 2020. Mais difficile de dire si le planning initial sera maintenu dans la situation actuelle.
Qui sait, peut être demain lors de l'annonce de sortie !
[^] # Re: Petite bourde des modérateurs
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 32 est déconfiné. Évalué à 6.
Ça pourrait être amusant. :)
Dommage pour la publication en avance, mais ça va, ce sera bon pour demain. ;)
[^] # Re: IBM 💖 IBM
Posté par Renault (site web personnel) . En réponse au journal Lenovo 💖 Fedora. Évalué à 7.
Pour information OS/2 était à la base une collaboration entre IBM et MS. Suite à un désaccord, MS a poursuivi son travail exclusivement sur Windows tandis que IBM a repris la charge de OS/2 mais sans succès pour ce dernier.
[^] # Re: Références
Posté par Renault (site web personnel) . En réponse au lien Rayons T : des scientifiques du MIT découvrent le moyen d’exploiter une nouvelle source d’énergie. Évalué à 5.
Ce n'est en effet pas une source d'énergie perpétuelle. ;)
Techniquement d'ailleurs, ce n'est pas une source d'énergie en tant que telles : ces ondes électromagnétiques sont faites par l'Homme pour émettre la radio, le wifi, etc.
L'idée est donc que certains appareils peu gourmands et portables puissent récupérer cette énergie disponible un peu partout plutôt que de réclamer de l'énergie additionnelle.
Ce serait une forme d'optimisation pour réduire la consommation de ces appareils. Mais si jamais tu n'as pas de l'énergie primaire suffisante pour générer ces ondes, ça ne pourra pas fonctionner. :)
D'où le fait que ce soit une source d'énergie me paraît assez impropre.
[^] # Re: Petite review
Posté par Renault (site web personnel) . En réponse au journal bout de code pour relancer une commande dans certaines conditions. Évalué à 4.
Comme barmic l'a dit tu écris et publies ce que tu veux, c'est ton droit.
Non ton code n'est clairement pas parfait, il ne faut pas le prendre mal, j'ai donné les éléments qui m'ont sauté aux yeux pour que tu puisses faire mieux la prochaine fois. Moi aussi j'ai écrit (et j'écris à l'occasion) du code sale. Et je suis content quand quelqu'un m'explique ce que je pourrais améliorer.
Bref, ne prends pas la mouche, il n'y a pas de raisons…
[^] # Re: Merci pour la dédicace ... :)
Posté par Renault (site web personnel) . En réponse au journal Petites brèves en vrac. Évalué à 4.
Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.
Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie… Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.
Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.
Rien n'est caché, le code de systemd est dispo si tu y tiens.
Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.
Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.
Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.
Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.
Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.
Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.
Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.
[^] # Re: Merci pour la dédicace ... :)
Posté par Renault (site web personnel) . En réponse au journal Petites brèves en vrac. Évalué à 10.
Je pense que la véritable erreur est là. systemd n'est pas juste un système d'init, c'est une collection de services bas niveau dont gestionnaire d'init mais aussi de session, etc. Donc il est normal qu'il soit plus complexe et complet, l'ensemble des parties de systemd est bien plus vaste que init.
En plus systemd a de nombreux comportements qui sont fournis d'entrée de jeux. Il suffit de configurer le service pour exploiter le comportement qu'on veut. init de SysV est vraiment rudimentaire, la complexité est en fait dans le script shell du service et tu dois tout faire à la main. Donc oui systemd est complexe à côté, mais la complexité est cachée à l'utilisateur et assumé de manière commune à tous les services.
Et systemd peut prendre en charge de manière uniforme tous les services, configurer SELinux, le redémarrage en cas de crash de l'application, etc. Avec init chaque service le fait à sa sauce, parfois ne le gère pas, parfois de manière différente d'un autre, etc. Bref, ce n'est pas parfait non plus…
Il faut comparer ce qui est comparable, systemd n'est pas qu'un système d'init et au niveau fonctionnel systemd gère la complexité lui même et ne la reporte pas sur le shell et les scripts de démarrages de chaque service.
[^] # Re: Porteur sain ?
Posté par Renault (site web personnel) . En réponse au journal Covid19. Quid du volontariat ?. Évalué à 3.
Oui, malheureusement c'est bien une corrélation et non une causalité. Difficile de dire si ce sont les hormones ou autre choses qui peuvent l'expliquer à ce stade. Comme l'indique la page que tu cites d'ailleurs.
Ils n'ont plus qu'à creuser comme on dit.
[^] # Re: Porteur sain ?
Posté par Renault (site web personnel) . En réponse au journal Covid19. Quid du volontariat ?. Évalué à 3.
Source ? Je n'en ai même pas entendu parler.
Après attention à faire la différence entre corrélation et causalité. En particulier en médecine où les corrélations sont nombreuses avec une causalité cachée.
[^] # Re: C'est quoi la suite
Posté par Renault (site web personnel) . En réponse au journal Covid19. Quid du volontariat ?. Évalué à 3. Dernière modification le 24 avril 2020 à 12:16.
Je ne vois pas le rapport.
Non pas qu'un système hospitalier à bout de souffle soit souhaitable ou que cela n'a pas accru certaines difficultés, mais la crise liée au coronavirus n'a que peu à voir finalement avec le système de santé en tant que tel.
D'ailleurs globalement les hôpitaux ont su tenir la charge au niveau nationale et il aurait fallu un budget totalement irréaliste pour avoir assez de lits et de personnels pour faire face à une vague non contrôlée par des mesures fortes.
D'ailleurs on le voit, tous les pays ont dû prendre des mesures fortes pour y mettre fin. Même ceux avec pourtant de bonnes capacités hospitalières car toute façon aucun système hospitalier ne peut faire face à une vague non contrôlée. Et la France d'ailleurs n'est pas si mal que ça sur ce critère.
Le problème est plus dans l'anticipation et la prévention, mais ce n'est pas simple. C'est un virus nouveau, il a fallu ingérer de nouvelles données constamment, les réactions trop virulentes de nos précédents gouvernements face aux précédentes épidémies asiatiques ont sans doute refroidi les gouvernements actuels de faire pareil cette fois pour une maladie finalement peu létale en elle même.
En tout cas ça permet de révéler certaines choses qui permettront de mieux gérer une telle situation si elle se reproduit, et pour le dé-confinement.
Bref, la gestion de l'épidémie aurait été tout aussi difficile même avec des services hospitaliers au taquet. Car pour faire face à une horde de malades, tu ne peux pas surdimensionner le système autant.
[^] # Re: C'est quoi la suite
Posté par Renault (site web personnel) . En réponse au journal Covid19. Quid du volontariat ?. Évalué à 5.
À part la Suède que je ne connais pas, les autres pays ont quand même des restrictions strictes à défaut d'un réel confinement. Ce n'est pas faites ce que vous voulez. Donc ne crois pas que chez eux le virus n'a aucun impact alors que chez nous c'est sévère, pour l'Allemagne aussi l'économie va souffrir, les allemands aussi subissent des restrictions légales fortes.
La Corée du Sud et Taiwan ont l'expérience des épidémies asiatiques de ces 20 dernières années, ça aide à se préparer et à avoir citoyens comme politiciens au taquet.
Ensuite ils ont eu massivement recours à des technologies qui hérissent le poil à certains ici pour faire du confinement très ciblé. Niveau liberté individuelle et vie privée c'est assez limite par rapport à ce qui est autorisé en Europe à ce sujet.
Donc oui ils s'en sortent bien mais ils ont fait des choix. Ce n'est en tout cas uniquement parce que le citoyen local est plus consciencieux.
[^] # Re: C'est quoi la suite
Posté par Renault (site web personnel) . En réponse au journal Covid19. Quid du volontariat ?. Évalué à 5.
Car l'épidémie n'est pas quelque chose de uniforme que ce soit dans une région ou dans le monde.
Tout d'abord un R0 n'est pas une valeur constante liée au virus. Elle dépend énormément de la densité de population, des échanges au sein de celles-ci, des habitudes culturelles, etc.
Chaque pays a des habitudes et une structure de sa population qui impacte +/- la contamination. D'où le fait que de comparer la situation en Suède avec la France de manière directe n'a pas un grand sens.
Ensuite une épidémie dépend beaucoup des échanges au sein de la population. Plus on tarde à limiter ces échanges au début, plus les conséquences seront fortes et dans la durée. Mais d'ailleurs on le voit, en France l'épidémie a surtout touché le Nord, l'Est et Paris. Le confinement a stoppé les flux avec les autres régions de manière suffisamment forte que les cas sont restés concentrés dans ces régions.
C'est d'ailleurs le cas en Italie ou Espagne où les régions très peuplées et touchées au début de l'épidémie qui concentrent l'essentiel des cas, les régions plus éloignées et moins dense ont profité du confinement pour stopper assez tôt la propagation.
C'est aussi probablement ce qui a aidé à protéger certains pays comme l'Allemagne ou la Suède qui ont été probablement moins touchés à l'origine. Et les mesures prises localement et par les pays voisines ont été suffisamment efficaces pour que le confinement général ne soit pas nécessaire.
De même qu'il n'est pas sûr que de nouveaux confinements soient nécessaires chez nous à l'avenir même si ça remonte. Par contre la vie normale comme avant sans restrictions cela mettra du temps à se revenir oui.
[^] # Re: oui
Posté par Renault (site web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à 5.
Outre les points que tu soulignes, Folding@Home agrège probablement la puissance cumulée de toutes les machines ayant calculé récemment.
Or contrairement à un supercalculteur, ces machines ne bossent pas à plein temps pour F@H. Quand elles ne sont tout simplement pas éteintes.
[^] # Re: Petite review
Posté par Renault (site web personnel) . En réponse au journal bout de code pour relancer une commande dans certaines conditions. Évalué à 6.
Le code reste quand même assez discutable. Même si cela reste un petit bout de code il y a de quoi améliorer
Déjà les macros CHECK_ERR et INT_ARG n'ont aucun intérêt, faire des fonctions à la place serait plus lisible et permettrait au compilateur de produire des messages d'erreurs plus sympas.
D'autant que le second est erroné. Il fait appel à des variables qui ne son présentes que dans main et qui ne sont pas passés en paramètres. Donc en somme cette macro n'est pas réutilisable alors que cela ne coûterait rien de le faire en fonction.
Il est préférable d'initialiser un pointeur à NULL plutôt que 0.
Il vérifie que l'argument débute par un tiret mais ne vérifie pas la taille pour être sûr que l'argument a bien plus d'un caractère ce qui serait je pense pertinent.
Puis il vérifie deux fois que arg n'est pas nul, c'est inutilement redondant.
Ce n'est pas une erreur en soi mais la ligne me semble inutilement longue et complexifie la lecture de la boucle. La commande devrait être dans le corps de la boucle quitte à utiliser un do while qui serait plus judicieux ici.
Globalement le main je le découperais en plein de fonctions encore, il y a moyen.
Bref, c'était ma revue de code. Elle vaut ce qu'elle vaut.
[^] # Re: A posteriori
Posté par Renault (site web personnel) . En réponse au journal Simulation situation en Italie. Évalué à 4.
La courbe en S est le bon modèle quand tu es en mode on ne fait rien où la seule limite pour propager le virus est de trouver de nouveaux malades potentiels, donc non infectés par le passé.
Après pour modéliser les mesures d'un confinement, il ne fonctionne pas, car il faudrait modéliser proprement l'impact réel du confinement mis en place ce qui n'est pas évident du tout et très variable d'un pays à l'autre.