David Marec a écrit 472 commentaires

ip sauf si on veut un truc plus maintenu depuis 15 ans.
Pareil que ifconfig,

Sauf que l'interface utilisateur a complètement changé. Pour quelle raison ?
J'ai du mal à croire que l'on n'ai pas pu intégrer netlink sans que ce soit transparent pour l'utilisateur.

D'ailleurs les distributions récentes

Je n'ai ni vu ni construit de distribution sans ifconfig ou route.

Par contre, que iproute2 soit installé en standard, pas toujours.

On est loin de de la différence ipfw et pf

ipfw qui a aussi existé sous Linux au passage. C'est même le premier pare-feu linux, de mémoire.

ipfw était (est) orienté stateless alors que pf est complètement statefull.

eBPF est trop jeune pour dire s'il va continuer à vivre en parallèle de nftable ou le remplacer (ou disparaître).

Celui là est désormais utilisé pour faire un peu tout et n'importe quoi.
C'est surtout devenu une alternative à trace, perf et cie.

---

Et il vient aussi des BSD, comme son nom l'indique.

Les plantages sont aussi bien plus fréquents et les kernel panics je ne peux plus les énumérer tellement j'en ai eu.

Je n'ai jamais aucun plantage sur mes machines,des 12-Stables et des 12-Release. Toutes sont à jour (à la semaine pour les Stable), dont mon Desktop. Les autres tournent 24/24.

Par contre, je n'ai pas de portable. Ceux que j'ai eu entre les mains sont tous partis en distribil au fil des mois et des mises à jours.
Quelque soit leur OS, de Windows à Linux.

Avec Linux je les compte sur les doigts de la main.

Je ne peux pas en dire autant. Tous les linux, et j'en ai essayé des distro sur mon Desktop, ont fini par ne plus démarrer après deux ou trois mises à jour.

Comme le fait d'avoir 3 parefeu différents dans le kernel mais on les laisse « au cas où » pour éviter de gêner les utilisateurs

Vous avez jeté un œil sur le merdier des parefeux Linux, des outils de base de gestion du réseau en général ?

Mais à un moment donné il est nécessaire d'avancer et prendre des décisions pour réduire la maintenance et la complexité d'un quelconque projet.

Oui. Alors, pour piloter les interfaces réseaux sous linux, on choisit, ip ou ifconfig ?
Sachant que le premier sert aussi à manipuler les routes. Comme route.

Sinon, on continue de parser (argl) et d'écrire (snprintf ) dans le bordel du procfs, du sysfs et du debugfs, en plus de sysctl. On bouffe du fd /dev à coup d' ioctl ou on cause netlink ?

Quand on doit écrire son driver, on propose la totale pour être sûr de satisfaire tout
le monde ?

---

la réponse est oui.

C'est pas vraiment le cas. C'est une incompréhension de ta part.

Hum. Comme c'est joliment tourné.

Et si ils sont obligés de passer par linux, c'est parce que dans le L il y a "linux containers" :

Plus précisément, ils cherchent à monter une solution multi-OS.

Our intention is to become multi-OS with TrueNAS software residing on both FreeBSD and
Linux. Improvements to TrueNAS will generally apply to both OSes. However, the scale-out
feature set uses Linux tools and hence the decision.

The work to make OpenZFS 2.0 consistent between FreeBSD and Linux was critical to
enabling this multi-OS capability.

Le pb c'est que quand on nous explique les règles de ParcourSup, ça va vite, tu te dis qu'en 1000 lignes c'est codé.

Yakafocon (ctmetcsdc).

L'article est intéressant et la nouvelle, malheureuse.

Non, il est mauvais. Il est écrit par un journaliste qui ne sait pas de quoi il cause et qui ne cherche qu'à faire le buzz.

Quelques chipotages :

Non, tout est chipotage. Tout dans cet article est prétexte à s'indigner. S'indigner. On ne sait pas pourquoi, mais on va s'indigner quand même.

Rhôôô les salauds de développeurs qui publient pas leur code dès les premières lignes !

Si je publie un logiciel libre, je donne juste les droits garantis par le libre (et ceux garantis par l'open source sont théoriquement équivalent).

Absolument pas. Il existe une grande différence entre les licences. C'est pourquoi elles existent. Ne serait-ce que l'opposition copyleft/non-copyleft.

De plus, certains bouts du code seront soumis à des licences propriétaires (donc non réutilisables)

Et d'où vient cette assertion ?
Je ne vois rien qui le démontre dans cet article.
Si c'est au lecteur de faire ses propres recherches, ce n'était pas la peine d'écrire un article.

Et en quoi un bout de code propriétaire n'est pas réutilisable ?

Si la sécurité d'une infrastructure dépend du fait qu'un code soit propriétaire, il y a quelque chose d'incorrect dans la conception du produit.

Non. C'est juste un choix.Il n'est nullement indiqué que la licence de ces parties de l'infra est propriétaire. Ils disent juste qu'il ne publieront pas d'info là dessus.

Et contrairement à ce que veux faire croire cet article, ça ne change rien à la licence du produit généré sous cette infrastructure.

Linux lui-même a longtemps été dépendent d'une brique propriétaire dans son infra: bitkeeper.

Voilà.

C'est même écrit dans la doc.

Pourtant le Comité Scientifique qui conseille le gouvernement était très réservé, voire absolument contre (je n'ai pas de source, mais je me souviens d'avoir vu passer ça plusieurs fois).

Vous n'avez pas de source parce que c'est exactement l'inverse:

https://www.liberation.fr/checknews/2020/03/15/le-conseil-scientifique-avait-il-valide-la-tenue-des-elections-municipales_1781749

Ce dernier a confirmé à Checknews que le conseil n’était pas opposé à la tenue des élections.
De fait, son président, Jean-François Delfraissy, s’exprimait sur ce sujet vendredi. «Une des décisions prises par le président de la République est de conseiller […] une réduction très forte de la vie sociale des personnes au-dessus de 70 ans. Ces personnes néanmoins auront accès aux courses tous les jours. La question posée était : est-ce que finalement aller voter est comparable avec aller faire ses courses dans un supermarché. Le conseil scientifique a considéré qu’il n’y avait pas d’élément pour penser qu’il y aurait un surrisque pour ces personnes à condition que les élections soient organisées de façon pratique […]. Le risque n’était pas plus grand que la possibilité qu’on leur laisse de continuer de faire leurs courses», expliquait-il.

Oui mais ça fait plus d'un an que les urgentistes et autres hospitaliers alertent sur l'état lamentable du service de santé.

Faux. Ça fait plusieurs années que le personnel des urgences alertent sur la l'encombrement des urgences.

1. Ça dure depuis plus d'un an. Bien plus.
2. Il ne s'agit que des urgences.
3. Il n'a jamais été question d'un «état lamentable du service de santé». Bien au contraire, il est très performant.

Et il y aurait beaucoup à redire sur l'encombrement des urgences, comme l'avait dit un medecin urgentiste, mais pas de ceux qui braillent le plus fort:

«plus de moyens, ce serait ajouter du bordel au bordel.»

Vous êtes déjà dans la récupération politique.

Je ne vois d'autres formulation plus pondérée

Pas tout à fait, il affirme obtenir « des résultats positifs » et les associe à son traitement.
Il n'y a rien de «pondéré» là dedans.

Les sondages sont autant pertinents que les deux études du sieur Raoult.

Ici dans le cas du torchon de Raoult (j'assume le mot de torchon, ce truc n'est pas une étude clinique), et de la polémique autour, justement les autorités sanitaires ne sont pas complaisantes vis-à-vis des études baclés.

Ce cirque me rappelle les «études bâclées» du professeur Jacques Benveniste.
Vous vous souvenez ? La «mémoire de l'eau».

Même processus, buzz médiatique, gros blahblah victimaire sur le thème «soyont modernes, on se fout des protocoles, les protocoles c'est le moyen-âge », mesure des résultats à la louche …

Tiens, il était « médecin immunologue » d'ailleurs. #COMME PAR HASARD

Il faut aller boire à la source.

Ça avait été présenté l'année dernière et c'est arrivé avec systemd-245, début mars.

Avec userdb , systemd-repart et plein d'autres petits trucs.

---

«I'm not a fan». (ctmetcsdc)

… Un autre site de partage de ressources.

• tutorial pour une mise en place sous FreeBSD.

https://gabgoh.github.io/COVID/index.html

Je n'ai aucune idée de la manière dont Firefox gère les GPUs, mais comme j'ai un peu bossé dessus, quelques pistes:

Intel a libéré le code HD de ses GPU en 2017/2018, dans l'ordre d'encapsulation:

1. libVA ;
2. le media driver pour VA-API: Il génère le pilote nommé iHD_drv_video.so que vous devez trouver dans ${usr_lib}/dri/ ;
3. le media SDK, qui va généré la bibliothèque libmfx.

Gstreamer va plutôt utiliser le media-driver alors que ffmpeg va préférer le media-sdk.

Le media driver peut vous apporter VP9 et HEVC(H265) selon les cartes. Consultez le tableau sur le site.

• Gstreamer: plugin vaapi, de mémoire ça ne fonctionne vraiment qu'à partir de gst-1.12.4 (mais en tout cas, pas la 1.12.0) ;
• ffmpeg: plugin libmfx ;
• Il existe un plugin Gstreamer pour le media-sdk, mais je n'ai jamais réussi à le faire fonctionner correctement .

il me semble que Firefox est plutôt basé sur gstreamer ?

Dans tous les cas, installer les vautils pour débugger et configurer les variables d’environnement pour rediriger le vaapi vers iHd, plutôt que i965.

export LIBVA_DRIVERS_PATH=${usr_lib}/dri/iHD_drv_video.so
export LIBVA_DRIVER_NAME=iHD

Peu probable.

Pour ça, il faudrait une coupure générale des réseaux internet.

---

Voire d’électricité, puisqu'on peut encore jouer en local, sur console, smartphone ou PC.

Est-ce que Zaclys se sent armé de supporter une grosse montée en charge ?

Je viens de proposer des accès aux services «cloud» aux enseignants de mes enfants.
Mais mes machines sont juste calibrées pour un usage domestique/familial et ne seront peut-être pas capables de tenir face à des milliers de requêtes.

---

Déjà, stopper les boinc qui tournent.

https://gcc.gnu.org/gcc-8/changes.html

Le premier argument de execve est par convention le nom du programme.

Pour compléter, ceci sert lorsque un programme est un lien vers un autre, plus générique.
Et que le comportement de ce dernier dépend du nom sous lequel on l'a appelé, comme les utilitaires busybox par exemple.

Qu'est-ce qui vous fait dire ça ?

En fait, vous avez raison, j'ai confondu avec la famille des exec().

Le premier argument de execve est par convention le nom du programme.

J'ai exhumé ceci:

  /* Child side.  */
  # SHELL_NAME vaut "sh"
  # SHELL_PATH vaut "/bin/sh"
  const char *new_argv[1];
  new_argv[0] = SHELL_NAME;
  new_argv[1] = NULL;
  [...] 
  /* Exec the shell.  */
  execve (SHELL_PATH, (char *const*) new_argv, __environ);
  /* NOT FOUND */
  exit (127);

---

Je me demande si le fonctionnement n'est pas différent sous FreeBSD.

Bonjour, ça fonctionne avec un PTY.

C'est étudié pour ;)

Plusieurs remarques,

• Si vous utilisez fopen, répondez par fclose, il est peu probable que vos close(f) soient valides. Un stream et un descripteur de fichier sont deux choses différentes.

• Puisque vous allouez dynamiquement le buffer, faites le uniquement dans le processus père. Sinon, le processus fils va hériter d'une copie.

• De même pour les bashargs, dans le fils.

• Pour moi, vous lancez toujours un bash … qui lance un autre bash (vérifiez avec ps).

• Sortez du while tout ce qui ne doit être fait qu'une fois (le timeout).

• Pas besoin du else, soit execve remplace complètement le processus, soit il échoue:

 execve(..);
 perror("marche po\n");
 exit(EXIT_FAILURE);

• si vous voulez voir quelque chose dans votre fichier,
  faites des fflush.

• Maintenant que vous avez tout écrit à la main, vous pouvez lire le manuel de forkpty
  voire les sources.

• et utiliser un poll ou un epoll.

---

C'est con tous ces #define _XOPEN_SOURCE et autres, hein.
Pour éviter ce bordel, passez sous FreeBSD.

Je pense avoir corrigé le reste .

Vous n'avez pas correctement alloué basharg.

Le prompt ne s'affiche pas.

Je ne sais pas pourquoi, mais là, j'ai la flemme de faire le tri dans tous ces pipes .

Utilisez un pty comme suggéré. C'est la manière canonique de faire ce genre de chose.

Au passage, utilisez les constantes STDIN_FILENO et STDOUT_FILENO à la place de 0 et 1.

vous devriez de plus vérifier que le fils ne s'est pas terminé avec waitpid, après chaque timeout sur select par exemple.

J'ai aussi l'impression que vous allez lancer deux bash avec votre execve.

Et votre buffer n'est pas initialisé:

char buff[MAX_BUF_SIZE];   
memset(buff,0,sizeof buff);

Euh … vous utilisez le même argv que celui passé à main là.

char* const basharg[]={"-i",NULL};
execve("/usr/local/bin/bash",basharg,NULL);
perror("Execve failed\n");
exit(EXIT_FAILURE);

// pas besoin de else