freem a écrit 5019 commentaires

Parmi la liste des inits que j'ai découvert pendant l'init-war, il y avait runit, et je dois bien le dire: je ne vois pas quoi lui reprocher.

Du coup, je suis plutôt sv restart foobar, même si je pense qu'il ne serait pas compliqué de faire une commande proxy qui s'appellerait service et qui gérerait service foobar restart (ou l'inverse).
À noter tout de même, je me demande si c'est une bonne chose, ces commandes avec des sous-commandes qui se basent sur un ordre fixe d'arguments différents pour faire leurs tâches.
Perso, je préférerai, dans l'absolu, une syntaxe de type service --restart=foobar -rwhatever --restart=foobar,whatever plus simple à comprendre quand on mets le nez dans les scripts qui l'utilisent (sachant que le -rwhatever serait juste un alias court à --restart=whatever). M'enfin, je crois pas qu'un seul init implémente un truc de ce genre?

Il y a ça, mais aussi la question de la pertinence: déjà, les vulnérabilités sont adressées par leurs noms de baptême et non leurs CVE (je suppose qu'elles en ont?) donc au niveau maintenance sur le long terme ça risque d'être un peu chiant.
Et si c'est juste pour spectre et meltdown, alors c'est dommage, mais d'un autre côté, maintenir ce genre de choses pour l'ensemble des vulnérabilités risque d'être très coûteux en temps humain et aussi en code sur la longueur.

Du coup, je ne suis pas convaincu du tout que ce soit une bonne idée. Pour les gens soucieux des CVE potentielles sur leurs systèmes, il me semble qu'il existe déjà des paquets pour ce type de problématiques (celui de debian ne semble pas contenir "cve" dans son nom, ou alors aucun paquet ne me rappelle des souvenirs).

Concernant les failles, à priori, connaître la version du noyau est suffisant.

Si je ne m'abuse, il y a moyen de désactiver les patchs avec des paramètres en ligne de commande (ligne passée au noyau par le boot, hein, pas via un prompt urxvt) donc, non, la version ne suffit pas (quant à pourquoi désactiver, à priori, me semble que pour certains usages les correctifs peuvent avoir un impact non négligeable sur les perfs, même si ça sera pas le cas de nos machines de bureau).

500KB/s

Kilo Bits, ou Kilo Bytes, du coup? Je ne suis jamais sûr de comprendre quelle unité est la bonne quand c'est un b…

je n'utilise pas le chiffrement de mes email car personne dans mon entourage n'utilise le chiffrement d'email tout simplement parce que ce n'est toujours pas en 2018 accessible, utilisable et fonctionnel a 100% du temps en un clic pour l'utilisateur lambda,

De ce que j'ai testé, envoyer des messages signés et chiffrés avec thunderbird et claws-mail est simple comme bonjour. Pour la réception, je ne sais pas, à part les tests que j'ai faits en m'envoyant un mail à moi-même pour le fun.

La création du couple de clés est prise en main automatiquement quand on active les extensions, et la configuration pour activer (ou non) automatiquement l'un, l'autre, ou les deux, en fonction du message auquel on répond est également très simple (quelques options sans détails techniques dans une section de l'interface de configuration qui semble logiquement dédiée à ça), et pour le cas par cas, il y a des icônes parlantes (en tout cas, pour thunderbird, pour claws, on dirait que je les ai désactivées s'il y en a?) dans l'interface pour envoyer un message.

Les seuls problèmes que je vois, mais peut-être parce que je n'ai reçu des mails signés et chiffrés que de moi-même (pour tester) c'est qu'il ne semble pas possible d'assigner une clé publique à une adresse mail particulière, et donc vérifier si en plus d'être bien signé, le message l'est par la bonne personne.
Et je suis persuadé que c'est lié au fait que, justement, ma clé est déjà connue du système (puisque c'est ma clé d'origine).
Du coup, je veux bien que tu détailles ce que tu trouves compliqué? Peut-être le fait que la clé ne soit pas générée automatiquement en fonction du mot de passe utilisé pour imaps/smtps? Le fait que ces outils ne soient pas installés par défaut dans les clients (c'est peut-être le cas avec tails, remarques)?

On peut toujours trouver à redire

Perso, je l'ai réessayé récemment au boulot. Voici quelques inconvénients (par ordre d'importance, de majeur à négligeable) que je lui trouve:

• html obligatoire. Pour moi, c'est bloquant, je hais les mails en HTML. Et pour ajouter au problème, l'espèce de mise en page automatique est merdique (j'ose espérer que ça se configure, mais j'ai pas trouvé).
• temps de démarrage trop élevé. Désolé, pas de SSD au taf, et de manière générale, j'aime pouvoir utiliser les mêmes logiciels sur les PCs, parfois avec des contraintes de performances (ben oui, booter depuis un disque externe via USB, c'est moins rapide
• moins de lignes dans mon pstree. Il est déjà assez saturé comme ça avec le navigateur internet et cette cochonnerie de slack (pour le taf…). C'est peut-être un détail mais moi j'utilise très souvent cette commande.
• j'aime pas l'interface. Mais c'est une question de goût à l'état pur. Mention spéciale pour l'interface de configuration que je supporte difficilement, mais vu que c'est aussi valable pour firefox, ce n'est pas surprenant.

Bon, après, il a des points forts aussi, je pense notamment au fait d'être très simple à configurer (il est manifestement capable de se configurer automatiquement en fonction de certains fournisseurs) et supporte les agenda google (via plugins), choses dont claws ne semble pas capable.

En tout cas, je te rejoins que pour du mail pro ou qui sert réellement, un mail lourd est bien plus pratique:

• pas besoin d'être connecté pour avoir accès aux mails,
• pas besoin de lancer le navigateur internet pour si peu (~enfin, sauf dans le cas de thunderbird qui en est un~ oups, pas trolldi)
• possibilité d'intégrer avec un éditeur de texte local (entres autres), ça peux être utile pour diverses choses
• réactivité, y compris sur du matériel qui date de plus de 3 ans
• mises à jour intégrées au système, donc meilleur contrôle sur la sécurité voir même l'utilisabilité (j'ai utilisé pendant pas mal de temps un webmail qui n'étais pas à jour… ça n'a jamais posé problème en soit, mais je n'ai aucune garantie que les MàJ de sécurité de l'interface web étaient effectuées)

Et je suis sûr que j'en oublie.

Pour répondre à la problématique mot-à-mot de l'auteur, en langage compilé pour modifier le comportement d'un objet selon son instance, j'aurais soit utilisé:

• un tableau associatif "nom=>callback" (si on parle d'ajouter à la volée et en fonction de l'instance, mais je trouve ça sale)
• plus probable, un design pattern, probablement le décorateur: en gros, on ajoute à la classe «maîtresse» une instance (on un conteneur d'instances) d'une classe dont dérivent d'autres classes implémentant les comportements souhaités,
• des fonctions qui manipulent la classe, plutôt qu'embarquer un comportement volatile directement.

Tout ça pour dire que ce n'est pas un problème de langage compilé, et ce genre de techniques sont très utiles dès lors que l'on implémente des mécanismes de plug-ins, par exemple.

Le problème semblerait plutôt être que beaucoup de programmes écrits en C pourraient avantageusement être écrits dans un autre langage de programmation, qui ne soit pas un langage de bas niveau.

Ou alors, on pourrait considérer que le C pourrait fournir un minimum de support pour les chaînes de caractères dans le modèle length+data. Sauf que l'on s'expose alors à un autre problème, qui n'est pas si simple qu'il n'y paraît: dans l'article, l'auteur indique

Using an address + length format would cost one more byte of overhead than an address + magic_marker format

Traduction grossière: «Utiliser un format adresse + taille ne coûterait qu'un octet de plus par rapport au format adresse + valeur_magique».
C'était vrai à une époque donnée, sur un CPU donné, mais dans la pratique, les CPUs n'utilisent pas la même taille de mots, du coup, cette assertion est fausse dans pas mal de cas aujourd'hui. Accessoirement, ça limiterait la taille des chaînes de caractère à 65535 octets. Difficile, avec des fichiers de log ou des données XML un peu volumineux (avec UTF8, ça passera encore, mais en unicode 32, on a moins de 17000 caractères)…

Du coup, même si c'est vrai que ça pose des problèmes de sécurité quand on ne fais pas gaffe, et que c'est facile de ne pas faire gaffe, je pense que c'est un sacré raccourcis que de dire que c'est l'erreur la plus coûteuse.
Le C n'est pas juste fait pour tourner sur du matériel grand public, mais pour écrire du code portable (et pas forcément porté), efficace et puissant. Avec ces contraintes, le choix «null-terminated» était plus logique que celui d'utiliser des tailles: la taille des mots change avec les processeurs et le temps, les besoins aussi.
Du coup, le choix avec le moins d'impact sur les conceptions futures est bien le marqueur de fin: ce mécanisme marche juste sur la totalité des architectures sans la moindre modification de code, est indépendant du compilateur (quelle est la taille standard de size_t? Sur n'importe quel compilo ou CPU?).
Si l'on à besoin de manipuler beaucoup de chaînes de caractère, on prend un outil fait pour, quitte à introduire une dépendance (qui aurait éventuellement pu être incluse dans le standard, depuis, mais passons).

J'ai vu dans les commentaires que tu utilises apt-get, mais quelle distro? As-tu fait une mise à jour récemment? Je pose la question parce qu'il se peut que le nom de l'interface réseau ait changé si une MàJ majeure est passée par la (normalement, non, mais on sait jamais).
Tu indiques avoir fait ip link show mais tu n'indiques pas le retour complet, qui permettrait d'invalider la possibilité ci-dessus.

Quel gestionnaire réseau utilises-tu? Tu indiques ne pas utiliser d'interface graphique (bien que je doute que sois en TTY) mais ça n'indique pas comment le réseau est configuré chez toi. Personnellement, je n'utilise pas de daemon pour gérer le réseau, je le fais manuellement à partir de /etc/network/interfaces (avec le wpa_supplicant.conf qui va bien et mets les clés non dans la config mais dans le $HOME de mon utilisateur, histoire de pouvoir ajouter un réseau wifi sans être root…).
Si tu n'utilises pas de gestionnaire, peut-on voir le contenu de ce fichier?

Tu peux ping ta box, mais arrives-tu à ping une autre machine sur le LAN sur l'ethernet (donc, quand tu n'es séparé d'une autre machine que via un switch, ta box faisant potentiellement office de switch. Il n'y a pas de raison que non, mais ce petit test permettrais déjà de vérifier qu'il n'y a pas de problème de ce côté: peut-être n'est-ce pas du côté de ton PC, que ça merde)?

Une hypothèse qui n'a pas été abordée: un problème de routage? Que donne la commande route?

Notes: pour l'histoire de resolf.conf, un moyen relativement simple pour vérifier si c'est une merde dans le DNS est de balancer un simple # echo 8.8.8.8 > /etc/resolv.conf. Vu que ce fichier est de toute façon régénéré par le système… (par contre c'est pas propre de squatter le DNS de google, j'ai cru lire à plusieurs reprises que niveau sécurité c'est douteux, mais pour du test, ça ne devrais pas poser de problème j'imagine)

je ne pense pas que les charges soient le seul probleme, la peur de perdre le controle et la fierte du boulot bien fait (risque que ca cesse si les 1ers employes s'impliquent pas) sont probablement de tres gros freins aussi. en france on semble avoir tendance a se faire la guerre entre patron et employe, et dans les grosses boites je pense que c'est possiblement justifiable (des 2 cotes) mais dans les petites? j'en doute. il y a des francais bosseurs et employes, et de bons patrons, meme si tous ont leurs travers: on reste humains, et pour rien arranger, y'a histoire de fric

on n'a pas l'info exacte, mais sait qu'il y a un bon revenu deja, sauf que, comme souligne(pas par moi, j'avoue avoir oublie ce point important), bon revenu c'est vague, et si on enleve les 2/3, ca peut etre merdique.
J'avoue penser par reflexe d'employe que bon revenu est rapport a la charge de travail: 2k€/m net pour 70h/s, c'est pas un bon revenu (en dessous du smic je crois meme).

A mon avis, le probleme n'est juste lie aux charges, mais aussi au tout controlé: difficile j'imagine d'accepter de ceder des responsabilites quand la boite necessite du taf de qualite pour survivre, ce qui est je pense le cas de toutes les boites avec moins de 10 personnes et qui produisent, et quand on a toujours tout fait tout seul. les 1ers employes cadoit etre dur.

je connais aussi, assez proche du sens ici, la partie qui reste au vendeur d'un carnets de tickets, dont une sous feuille est ecrite en meme temps que la 1ere. pas usite par les particuliers, mais encore dans certains tertiaires (enfin, ya 3-4 ans)

De nos jours peut-etre, mais y'a 10 ans?

Et a 70h/semaine, pas moyen d'avoir quelqu'un de plus pour l'épauler?
Dans la liste des tâches que tu cites, à priori, rien n'empêche d'avoir plusieurs personnes.

Accessoirement, c'est pas parce que t'as les sources que tu as quelqu'un qui peut les comprendre, et parfois lire du code source est plus difficile que lire de l'assembleur…

Surtout que ce commentaire n'apporte pas de solution à l'absence de solution de l'article.

C'est quoi, le rapport?

si ça inclue des commandes qui écrivent dans des endroits protégés (autres que $HOME et /tmp en gros) ou qui sont pas dans le $PATH des user normaux, probable en effet.

M'enfin, au dela de ça, je me demande pourquoi ne pas utiliser directement les paquets logiciels de la distrib hébergée? Je veux dire, de mémoire, y'a des paquets xorg avec des "pilotes" pour virtualbox?

J'imagine qu'il faudrait faire attention si ça dépends de la libcaca.

Il paraît qu'il existe aussi des gens qui font leur taf correctement, même s'ils savent qu'ils vont partir à très court terme parce qu'ils ne veulent pas continuer de travailler dans leurs conditions présentes.
Par exemple, mon dernier contrat (la 1ère fois et j'espère la dernière) que j'ai rompu une période d'essai, j'ai fini par «résoudre» (identifier la cause réelle en fait, et donc résolu dans la foulée) l'un des problèmes majeurs(1) ayant motivé ma démission le dernier jour et achever ma 1ère compilation du soft sur lequel je devais bosser au bout de plus de 2 mois. Ça faisait pratiquement 1 mois que je cherchais un autre employeur.

N'empêche, j'ai fait ce que j'ai pu jusqu'à la fin.
Je ne dirais pas que c'est une bonne chose d'avoir envie de partir en moins de 3 mois, mais si l'employé est honnête et franc (bon, faut aussi savoir prendre du recul et pas juste envoyer chier le monde en crachant sur les collègues/services/whatever qui ont causé la démotivation) je pense que ça peut devenir une bonne chose pour l'entreprise, qui peut en tirer des leçons.
Je ne sais pas ce qu'ils sont devenus, mais j'ai dit ce que je pensais (en argumentant, à froid et en analysant les problèmes des divers côtés, le mien inclus) de la boîte quand ils m'ont demandé pourquoi je partais, et le fait d'avoir fait mon taf jusqu'à la fin à permis de confirmer que mes raisons étaient pas totalement déconnantes.

Je doute d'être le seul à avoir ce type de mentalité.

1: pour faire court: les devs d'un côté, un service d'admin «IT» de l'autre.
L'IT installe et maintien les systèmes de base: passwords UEFI, activation du matos (accélération matériel pour les VMs, par exemple), OS, softs installés, comptes utilisateurs éventuellement admin locaux, création et gestion des machines virtuelles, etc.
Les devs ont la responsabilité d'installer quelques outils supplémentaires dont ils ont besoin, qui peuvent être des patchs MS spécifiques (pour VS, dans le cas qui m'intéresse) considérés expérimentaux ainsi que l'installation des VMs (préalablement créées et configurées par l'IT, bien sûr).
In fine, le problème majeur qui m'empêchait de travailler, le plugin de VS vital, ne répondait juste pas. La cause? Une machine mal (voire pas) nettoyée.
Je passe sur les autres anecdotes désagréables qui se sont ajoutées à ce problème.

Chiffres amusants, dommage que l'on ne puisse savoir qui rompt le plus les périodes d'essai: l'employé ou l'employeur? Bon, après, je doute que l'on puisse facilement avoir l'information de manière fiable.

on ne te demande pas ta carte d'identité en entrant.

Ça dépend, si t'as une tête un peu trop jeune et que tu demandes un truc alcoolisé, le patron peut le faire (je dirais même en a l'obligation). Mais disons que la consommation d'alcool est une feature des gens identifiés comme majeurs (bien que la méthode d'identification numéro 1 soit de qualité douteuse) :)

L’insécurité, les fabricants de processeurs s’en chargent directement !

Meltdown et Spectre sont si loin que ça dans les mémoires? L'insécurité, ce n'est pas forcément voulu.
Sinon, il y a pas mal de code auquel personne n'a accès qui fait l'interface entre le matériel et les pilotes de périphérique. S'il faut vraiment citer un exemple de ce type de logiciel, dont la sécurité reste à prouver (dans un sens comme dans l'autre à ma connaissance) on peut parler de l'IME.

Rien n'interdit aux gens de continuer a chercher un boulot mieux adapte une fois en poste

C'est sûr, à condition de ne pas être trop cassé à la fin de la journée et d'avoir la possibilité de prendre des RDV facilement sur le temps de travail.

Surtout que démissionner en période d'essai est assez facile.

C'est un fait, ça m'est arrivé une fois.

Il me semble meme que pas mal de personnes font ca.

Vraiment? Je pense que je suis le seul que je connaisse qui l'ait fait? Enfin, c'est pas comme si je connaissais tant de monde que ça, je te l'accorde, mais j'ai jamais eu l'impression que c'était très utilisé (que ce soit par les patrons ou les employés, pour le coup: les patrons semblent préférer les CDD courts en guise de période d'essai, pour une raison que je ne connais pas).
Bon, je répond juste sur mes impressions et mon expérience personnelle, hein, si y'avais des chiffres un peu plus scientifiques sur le sujet, ça serait intéressant, pour confirmer ou infirmer les opinions des gens sur cette fameuse période d'essai, notamment (et pour la culture perso aussi).

j'ai utilisé les lignes de commande pour exécuter le fichier "VBoxLinuxAdditions.run" seulement je n'arrive pas à exécuter le fichier, car je n'ai pas les droits…

Il faut que le fichier soit marqué exécutable pour ça, root ou pas. Pour le marquer exécutable avec une interface graphique (d'autant que ça change selon l'environnement en plus), je ne sais pas comment faire, mais en ligne de commande: chmod +x.