Obsidian a écrit 5303 commentaires

Bonsoir,

En résumé, je pense qu'il y a une très très grosse surestimation de niveau pour les dev du marché. Et je pense que malheureusement, ils n'en sont même pas réellement conscient, et ça m'inquiète pas mal, de voir à quel point on peu se déclarer "développeur expérimenté", en ayant a peine quelques bases. Et d'autre s'en foutent carrément, car si ils trouvent une boîte où il sont entouré de "médiocrité", ça permet de masquer la leur.

Je pense qu'il y a une bonne dose de fausse modestie dans ton post, caractéristique des gens qui commencent à avoir effectivement un peu de bouteille mais pas encore assez pour inspirer l'humilité, ni pour voir leurs connaissances commencer à vieillir et à décliner. Ce parce que la programmation intensive est une forme d'athlétisme à mon goût et qu'à l'instar de la plupart des sports de haut niveau, on ne peut pas la pratiquer efficacement jusqu'à l'âge légal de la retraite. J'ai donc quelques questions à te poser :

— Quel âge as-tu ?
— Quel âge en moyenne ont les postulants à ton poste ?
— Quel est le salaire que tu estimes correct à ce poste (celui que tu exigerais, pas celui que tu proposes) ?
— D'où sort ce test ? Tu comprends que si c'est toi qui l'a écrit, tes conclusions seront forcément biaisées, même si (« surtout » devrais-je dire) si tu t'estimes impartial ;
— Quel niveau estimes-tu avoir en C++ ? Je pensais moi-même en avoir fait pratiquement le tour (en lisant un certain nombre de cours) je me suis rendu compte qu'en définitive, je ne savais rien ou presque (j'exagère mais à peine) ;

… et surtout :

— Dans quelles conditions fais-tu passer ce test ? En situation, avec une machine dûment équipée, un café, et trois heures de tranquillité après lesquelles tu reviens voir tes candidats ou bien dans une salle d'examen sur papier, voire même sous forme d'interrogatoire avec un feutre et un tableau blanc ?
— Tes candidats ont-ils accès à la doc quand ils passent le quiz ? La programmation est quand même devenue une activité dans laquelle il vaut mieux savoir chercher que tout retenir par cœur (surtout quand on sait à quelle vitesse les connaissances deviennent obsolètes).

J'ai moi-même commencé à écrire mes premiers programmes en BASIC autour de 10 ans peu avant d'entrer au collège. J'en ai aujourd'hui 37. Cela fait donc 27 ans que j'écris des logiciels par passion ou professionnellement. Plusieurs accidents de parcours m'ont obligé à plusieurs reprises à quitter le circuit scolaire et à y revenir jusqu'à suivre une formation d'ingénieur en partenariat il y a un peu plus de cinq ans, que je n'ai malheureusement pas pu conclure car j'ai perdu mon emploi peu avant la fin. Il se trouve que depuis que je travaille, j'ai fait face à pas mal de situations différentes. Après avoir fait mon service national et quelques petits boulot, j'ai fait un certain nombre de mission en SSII comme pas mal d'entre nous (et comme pas mal d'entre nous, j'ai fini par claquer la porte). J'ai occupé mon avant-dernier poste pendant six ans à l'issue duquel mes collègues proches avaient une haute estime de moi, mais où pratiquement tous les autres pensaient que j'étais un stagiaire (même après six de boîte, oui).

Mon dernier employeur, en revanche, était une boîte de sécurité informatique dont le nom est assez connu dans leur secteur d'activité : il se trouve que j'ai été recruté avant même d'avoir postulé, par réputation, par un membre de l'équipe assez bien placé lui aussi et qui me connaissait simplement par les messages que je déposais depuis plusieurs années sur le forum que l'on fréquentait tous les deux. Je connaissais son pseudo de visu mais nous n'avions jamais pris contact avant cela. J'ai été pratiquement accueilli avec le tapis rouge par son superviseur qui visiblement me considérait également comme un « bon ». Je n'ai donc jamais rien prétendu et heureusement parce que mon recruteur m'a voué un respect tout au long de ma mission alors qu'objectivement, il était meilleur que moi ! À aucun moment je n'ai été franchement dépassé mais à aucun moment non plus je n'ai dominé un développeur de l'équipe de mon savoir et il a fallu que je travaille sans relâche pour me maintenir à niveau.

Or, il se trouve que cette personne a été chargé, comme toi, de faire du recrutement ou au moins de participer aux entretiens. Comme il était très intransigeant sur ses propres connaissances, il l'a été également dans ses évaluations et là, objectivement, je pense que je n'aurais pas été capable de les passer.

J'avais moi-même également écrit mes propres tests d'évaluation, notamment en C++, il y a huit à dix ans, avec pas mal de pièges syntaxiques et de petites subtilités que j'avais moi-même rencontrées, en effet. Sauf qu'il ne s'agissait pas de procéder à un écrèmage systématique mais plutôt de voir facilement, en un coup d'œil, si la personne que j'avais en face de moi était capable de s'en sortir avec un peu de doc ou si elle était en mesure de me donner des leçons.

Ceci pour dire que je me reconnais totalement dans tes propos lorsque tu cherches à écrire le code le plus propre possible. Tu as entièrement raison de le faire et ne supporte pas les gens qui sont volontairement approximatifs quand ils exercent. Tu es probablement très compétent mais malgré cela, je pense que même toi, tu ne serais pas capable de passer un test de même niveau écrit directement par un programmeur de l'équipe que tu souhaites intégrer. D'une part parce qu'il serait lui-même très pointu dans son domaine et d'autre part parce qu'il serait au fait des problématiques rencontrées dans son secteur alors que tu ne le saurais pas encore à ce moment. C'est à cela que servent les périodes d'essai.

À la limite, si tu peux te le permettre, essaie d'envoyer par mail un exercice de second niveau à un candidat volontaire mais qui n'aurait pas forcément le niveau à l'entretien et laisse lui deux ou trois jours pour le mener à bien. Ça se faisait dans ma dernière compagnie. En général, on a de belles surprises de la part des personnes qu'on a jugé en premier lieu. Ça leur permet aussi de se relire, de déboguer et de prendre le temps d'examiner à tête reposée toutes les approches possibles pour choisir la meilleure .Et c'est bien ce que l'on attend d'eux, en définitive, lorsqu'ils sont en activité.

l'avis de Gary Hood

En fait, c'est « Gary's Hood ». :-) Ça se traduirait à peu près en « du côté de chez Gary »…

« Moi, mon DSI il a marché sous une échelle sur lequel il y avait un chat noir, et ben 6 mois plus tard il a eu un accident de voiture !
- Jésus Marie Joseph ! Quel inconscient ! C'est vraiment bien fait pour lui… »

En même temps, il l'a bien cherché aussi… :-)

C'est ma faute ! J'ai fait une faute de frappe. Je voulais dire « AU MOINS la largeur du clavier », bien sûr ! :-) Et évidemment, c'est mieux s'il y a de l'espace devant pour éviter d'avoir les yeux collés à l'écran et pour pouvoir pousser son clavier devant soi et utiliser une feuille de papier.

Sinon, à l'usage, la meilleure hauteur est bien 70 cm plutôt que 65. J'avais mesuré la hauteur du bureau de mon ancien travail où j'étais particulièrement bien assis mais, pris d'un doute, j'ai re-mesuré mon bureau actuel qui est plutôt une grande table sur tréteaux et qui est un peu plus bas en pratique.

David_Neil_Cutler pour ne pas le nommer (et puis si, tiens, finalement…).

Même sous un utilisateur non-privilégié, je suis sûr qu'il est possible de foutre le boxon en exploitant telle ou telle faiblesse dans le système. L'exécution de code dans lequel on n'a pas confiance est un risque énorme, root ou pas (sauf depuis une sandbox totalement confinée, ce qu'un utilisateur Unix classique n'est pas).

C'est ce qu'on dit depuis le départ. Sauf qu'au lieu de proposer des solutions, l'auteur du billet en question nous dit « bah, du coup, autant tourner en root ». C'est le même langage que le jacky qui nous soutient : « que je roule à 130 à 250 sur autoroute, de toutes façons je suis mort en cas d'accident alors autant rouler vite » (extrait authentique retraduit de mémoire mais tiré de feu thejackytouch.com).

C'est complètement idiot : non seulement ça ne règle pas les problèmes de sécurité en question mais ça en amène plein d'autres.

(sauf depuis une sandbox totalement confinée, ce qu'un utilisateur Unix classique n'est pas).

C'est bien de cela qu'on parle également : un pseudo-utilisateur, une prison chroot voire une VM comme sur Android.

Mon propos était que sur une machine de bureau classique, il n'y a pas de serveur HTTP ou SQL qui tourne, ce qui élimine la question.

Encore une fois, tu as mal lu :

1. Il est effectivement très peu probable qu'un serveur HTTP tourne sur une machine de bureau. Une base de données en revanche, l'est déjà nettement plus ;
2. On se moque que des serveurs fonctionnent déjà ou pas sur la machine de bureau : le problème — entre autres — est que n'importe qui ou n'importe quoi peut en lancer un s'il est root. Et je ne parle pas de lancer une infrastructure préalablement installée : un simple script shell suffit pour se mettre à l'écoute avec nc.
3. Même si ton virus avait besoin d'un serveur Apache pleinement configuré lié à une base MySQL (ce serait gonflé), en tant que root, il lui suffirait de lancer un « apt-get » ou un « yum install » pour les obtenir !

Pourquoi autoriser l'exécution de "scripts" chargés depuis l'extérieur ? Quel est le cas d'usage ?

La vraie question, depuis le départ, est : « pourquoi autoriser l'utilisateur lambda à travailler sous root ? Quel est le cas d'usage ? ».

Et quel est l'intérêt, plutôt que de l'ouvrir sur le port 8080 ?

C'était un simple exemple mais puisque tu le demandes, l'avantage est que ça permet au monde entier d'y accéder par défaut depuis leur navigateur sans avoir à préciser un port et, notamment, depuis des clients se trouvant derrière des pare-feux d'entreprise dont, bien souvent, seul le port 80 est ouvert vers l'extérieur par défaut. C'est d'ailleurs une des raisons pour lesquelles on a inventé les web services…

Ça peut-être n'importe quoi d'autre : en ouvrant les port 135 à 139, tu peux transformer automatiquement la machine-zombie en serveur SMB Windows public pour faire du dépôt massif de fichiers, spécialement quand il sont illégaux. Ce qui est particulièrement fort, c'est qu'avec les lois merveilleuses du dernier quinquennat, c'est le titulaire de l'accès Internet qui est responsable même si c'est fait complètement à son insu, et c'est à lui de prouver sa bonne foi. Que se passerait-il, par exemple, si on retrouvait sur sa machine un répertoire entier, bien distinct, d'images pédophiles ? Ce ne serait pas du « cache », comme celui de son navigateur, et ce serait difficile d'affirmer qu'elles sont arrivées là par hasard. L'utilisateur a le temps d'avoir de gros ennuis avant qu'une personne compétente et motivée arrive à mettre le doigt sur le cheval de Troie.

Enfin, un dernier exemple très répandu : ouvre le port 25 et tu fais un Open Relay pour envoyer du spam. Il fut un temps où les Freebox étaient livrés avec ce port 25 bridé en émission par défaut (sur les serveurs autres que ceux de Free) pour cette raison et qu'il fallait aller le débloquer (une seule fois) sur sa console de gestion, ce qui était plutôt une bonne chose à mon goût. Je ne sais pas si c'est toujours le cas ou pas.

Le journal parle d'un "système mono-utilisateur classique", j'imagine qu'il s'agit d'une machine de bureau, pas d'un serveur où on fera effectivement tourner différents services sous différents utilisateurs.

Ce n'est pas la question. Relis bien le commentaire : ce n'est pas les serveurs eux-mêmes qui nous intéressent mais le fait que ceux-ci ont facilement la possibilité de déclarer un pseudo-utilisateur pour fonctionner sous leur propre identité et être protégé des attaques venant du compte utilisateur principal, et cela même sans être root, ce qui limite beaucoup les risques en cas de FAILLES non révélées dans ces serveurs.

Il est tout-à-fait possible de faire en sorte que les scripts chargés depuis l'extérieur et lancés naïvement depuis l'interface graphique soient exécutés par défaut sous l'identité d'un pseudo-utilisateur. Au lieu de cela, l'auteur du billet préconise non seulement de tout faire depuis la même identité, comme c'est généralement le cas, mais en plus de le faire en root !

Qu'on soit bien d'accord : pendant très longtemps nous avons utilisé sans gros problème des machines sans aucun droits d'accès : on a utilisé des huit bits pour beaucoup d'entre nous et MS-DOS a prédominé sur PC une quinzaine d'années. Seulement, nous étions bien moins informatisés qu'aujourd'hui et surtout beaucoup moins connectés. Et encore, malgré cela, les gens qui ont connus cela savent à quel point il était facile de se faire refiler une disquette vérolée, même en 5"¼. Même le Goupil du nanoréseau de mon collège en 1990 l'avait été.

Je ne suis pas contre faire des machines complètement ouvertes pour la simplicité de la chose, à condition qu'elles restent au sein d'un réseau qui — lui — est sécurisé comme il le faut et administré par une personne compétente. Ce n'est pas non plus ce que préconise le blog.

Ouille ! Il a fallu que je fasse le test quand même pour vérifier que c'était bien un gag… :-)

Hello,

D'expérience, et en ce qui me concerne, la hauteur idéale du bureau est 65 cm. À ajuster éventuellement entre 60 et 70 cm. Je te conseille de faire l'essai quelques temps et de voir si cela te convient.

Ensuite, il est essentiel d'être assis face à son écran avec son clavier devant soi. Si tu places ton moniteur sur le coin de ton bureau et que ton clavier est parallèle à ce moniteur, donc en biais par rapport au bord de la table, tu devras te tourner sans arrêt pour l'utiliser et tu seras victime d'un douleur vive entre les omoplates avant la fin de la journée.

Il est très important également que tes avant-bras reposent sur le bureau lorsque tu tapes au clavier : pour cela, prévois l'espace pour « deux claviers ». Autrement dit, laisse un espace vide entre le bord du bureau et ton clavier correspondant à moins de la largeur dudit clavier. Ça te permet aussi de le pousser facilement vers le fond si tu veux prendre une feuille de papier devant toi. Pendant la frappe, l'essentiel du poids de tes bras va reposer sur cet espace et tu verras qu'à l'usage, c'est très confortable.

Enfin, il te faut un fauteuil à roulettes. Malgré l'encombrement, je te suggère vivement d'en choisir un à accoudoirs et de régler ton siège pour que ceux-ci soient à peu près au niveau de la table, quitte à le rabaisser en fin de journée pour le ranger en dessous. J'avais eu la chance de trouver un confortable fauteuil en cuir (ou imitation, mais très bien imité quand même) à 55 € chez Office Dépôt il y a quelques années mais ce genre de promo est rare. En général, il faut compter pas loin du double. N'oublie pas, enfin, un tapis de sol en plastique. Même si tout cela fait monter la note, c'est un équipement que tu conserveras des années, plus longtemps encore que ta machine, probablement. Si tu ne veux pas te retrouver avec un stratifié complètement rayé ou, pire, avec une moquette complètement à refaire, c'est un investissement intéressant.

Je trouve l'argumentation biaisée. À la base, même s'il n'y a qu'un seul utilisateur sur la machine, « root », c'est : cet utilisateur + tout le reste. Il n'y a pas spécialement d'avantage à utiliser root plutôt que son propre compte en temps normal. Ensuite :

l'utilisateur de base à déjà l'accès complet au réseau : « il peut recevoir et envoyer des données à n'importe quel serveur sur n'importe quel port ». Combiné au point précédent, cela signifie que l'utilisateur de base peut se faire voler ses données par n'importe quel programme exécuté avec ses propres droits.

Ça permet aussi et surtout — entre autres choses — à n'importe qui d'ouvrir un port inférieur à 1024. N'importe quel script pourrait par exemple lancer un serveur web sur le port 80 d'une machine-zombie, par exemple.

l'utilisateur de base peut lancer n'importe quel programme. Il lui suffit de le télécharger et de l'exécuter. Donc le compte root ne protège pas les données des virus, il ne protège que les fichiers systèmes (les moins importants).

Même chose : ça limite énormément la portée de ce que peut faire le programme, comme manipuler ou même bronsoniser les processus d'à côté. Au hasard, un httpd un peu chiant qui occuperait déjà le port 80. :-) Même le tableau au milieu de l'article est orienté : « Run installed programs : Root √ ; User : √ ». Ça, ce n'est pas un mal nécessaire, c'est le fonctionnement normal d'un système multitâches : c'est à cela qu'il sert, et ce n'est pas censé être une faille en soi.

Ça veut surtout dire que non seulement éviter d'utiliser root reste une évidence, mais que ce n'est pas suffisant : même en tant qu'utilisateur, il faut prendre des précautions. En tout cas si on est paranoïaque puisque dans le cas contraire, c'est toute cette discussion qui n'a plus d'objet. Et là, par contre : néant. On aurait aimé qu'il parle des principales techniques de compartimentage utilisées sous Unix, comme par exemple l'utilisation de pseudo-utilisateurs : les principaux services comme Apache, Postgresql et Mysql sont presque tous configurés aujourd'hui, pour utiliser le leur. En bossant sous root, il suffit d'un seul kill pour tous les mettre par terre ou corrompre leurs données. En utilisateur normal, sans le mot de passe, point de salut et celui-ci — contrairement à sudo — n'est pas saisi toutes les dix minutes ou stocké en clair à un endroit identique sur toutes les machines (enfin, en principe). Il n'est quand même pas difficile de configurer l'interface graphique de l'utilisateur débutant pour qu'elle lance par défaut un script externe avec l'identité d'un pseudo-utilisateur plutôt que celle de l'utilisateur en cas de doute. On aurait bien aimé également qu'il nous parle de chroot, qui permet de mettre en place relativement facilement un bac à sable pour lancer les applications potentiellement dangereuses.

D'autre part, root n'est pas seulement le vecteur préféré des agressions extérieures : c'est aussi le moyen de réparer son système quand le reste ne marche plus : par exemple, mkfs réserve par défaut 5 % d'espace pour root au moins sur la partition système. Son home dir se trouve également sur une partition distincte ou directement sur la partition système. Ça permet d'une part de se loguer quand on ne peut plus monter /home et de faire tourner le système quand un log fou a rempli sa partition. Bosser en root, c'est contourner volontairement tous les garde-fous mis en place par le système. Enfin, il y a le fait que root n'est un utilisateur normal et que bon nombre de contrôles sont faits directement au niveau du noyau pour savoir si l'uid en vigueur est ou non égale à zéro.

Ça avec le fait que dès que l'on déclara un second (vrai) utilisateur ou lorsque l'on travaillera sur un système centralisé, il faudra perdre toutes ces mauvaises habitudes acquises sans raison valable. Alors pourquoi faire ?

Si tu essaies ça sur une Fedora récente, tu risques d'être déçu. :-)

rm -rf /home c’est 10 minutes montre en main pour restaurer une sauvegarde

Une quoi ? :-)

Non. C'était dit avec légèreté mais c'est bien « censées », avec un C, que l'on attend ici.

→ Censé : dont on attend quelque chose de précis (et qui n'est pas toujours au rendez-vous) ;
→ Sensé : qui a du sens (par exemple : « des propos sensés »).

Qu'on fasse la faute, ce n'est pas bien grave, elle est extrêmement courante. Mais aller corriger une seconde fois un post pour la RÉTABLIR, cela nécessite de s'y pencher.

Ces personnes qui sont sensé diffuser du savoir et de l'intelligence n'ont même pas un échantillon sur eux.

« Censées » /o\

On avait aussi évoqué cette façon de faire, il y a quelques temps :-)

https://linuxfr.org/users/claudex/journaux/rsf-et-charlie-hebdo-d%C3%A9couvrent-les-m%C3%A9faits-de-la-centralisation#comment-1287327

Hier William Lowe a rejoint Charles Broson

Charles Broson ? Un rapport avec le broson de Higgs ?

« find », comme développé dans les commentaires ci-dessous, est vraiment ce qu'il te faut. L'avantage étant que, du coup, ça fonctionne avec tous les shells.

Mais pour le reste, la boucle « for » sert précisément à faire ce qui n'est pas pris en charge par les outils eux-mêmes. Il faut savoir que quand tu écris une expression globale (man 7 glob), comme une étoile seule ou n'importe quelle expression contenant des étoiles et/ou des points d'interrogation, c'est le shell qui développe l'expression avant d'appeler la commande. Essaie par exemple « echo * », ou « echo Debut * Fin ».

Ça veut dire que la commande elle-même n'a aucun moyen de savoir a priori si tu as saisi une étoile ou si tu as manuellement entré une liste de fichiers. Cela veut dire également que ce n'est pas la commande elle-même qui fait l'analyse syntaxique des caractères jokers pour ensuite décider ou non de faire un traitement groupé. C'est juste que la plupart des commandes sont faites pour appliquer leur traitement à chacun des fichiers dont on leur passe le nom.

Le lien vers la charte des bonnes pratiques est brisé.
Au moment où je lis la dépêche, le lien correct semble être :

http://www.lebulletin.fr/fiches-pratiques/sous-menu-test/1757-2013-29-charte-des-bonnes-pratiques-de-la-collaboration

… mais vu la façon dont il est construit, il y a des chances pour qu'il devienne à son tour caduque sous peu.

Bonjour,

Pas tout-à-fait : l'expression en question doit plutôt être lue « ce qui est pointé par c va recevoir le résultat de a+b. ».

Un pointeur est une variable qui contient une adresse en mémoire. Le format de celle-ci est donc dépendant de l'architecture sur laquelle tu travaille mais, a contrario, sera complètement indépendant de la donnée qui se trouve à cette adresse.

Quand tu passes des arguments à une fonction, ceux-ci se retrouvent dans la pile et sont gérés comme s'il s'agissait de variables locales. Ainsi, mais si elles portent le même nom, les variables « a », « b » et « c » de ta fonction add sont complètement indépendantes de celle de ta fonction main et, par conséquent, les arguments en langage C sont toujours transmis par COPIE.

Mais dans le cas présent, ce que tu passes en troisième paramètre est littéralement « l'adresse de la variable c ». Puisque « c » est un entier, l'information en question est donc forcément un « pointeur sur un entier », d'où la manière de rédiger le prototype de add.

Passer à une fonction l'adresse d'une variable extérieure à cette fonction lui permet donc d'écrire dedans, entre autres.

Bonjour et bienvenue,

J'imagine que tu le sais déjà mais où cas où et d'une manière générale, il existe une page de manuel pour pratiquement toutes les commandes et fonctions du système d'exploitation. Elles sont le vademecum de tout utilisateur d'UNIX et sont accessibles depuis la ligne de commande de cette façon : man scp.

La man page précise que les modes, donc les droits d'accès, sont conservés. Par contre, l'identifiant du propriétaire et du groupe ne peuvent pas l'être, ne serait-ce que parce que cela implique que les bases des utilisateurs soient identiques des deux côtés.

Tu peux aussi t'en convaincre en soulignant que « [ ] » servent à spécifier une liste de caractères admissibles à une position donnée. Le point « . » signifiant « n'importe quel caractère », cela n'aurait pas de sens de l'insérer au sein d'une liste et au milieu d'autres caractères ordinaires qui, par définitons, sont déjà pris en compte par le « . » avec les autres.

Moi, ça me convient très bien.
Je pense que l'auteur aurait aimé que ce soit en HTML, tout simplement, pour le consulter en ligne.

Malheureusement, c'est un fichier PDF

 Ça c'est un moindre mal. Ça aurait pu être un *.doc, par exemple.

s/baseline/vaseline/

Essaie « nautilus » (en minuscules) par exemple…