Batchyx a écrit 1261 commentaires

Wow… C'est vraiment nier la réalité, la transformer pour être en accord avec ses fantasmes.

C'est plutôt toi qui lis des choses que je ne dis pas.

Je n'ai jamais dis que la majorité voulais virer systemd, j'ai dis qu'ils y a des gens qui cherchent à le virer.

Personnellement, je connais aucun système de boot assez générique, généraliste, simple et facile pour contenter tout le monde. Et je crois que ça n'existera jamais. Toute tentative d'unifier ça va forcement se terminer par un standard supplémentaire.

Quasi-tout le monde (on parle de ce qui doiven tse taper la maintenance hein, pas les trolleur qui foutent rien) veut mettre systemd sur Linux, et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.

Si le système de boot est maintenu par la distribution, le boot de chaque système est maintenu par l'administrateur. Si l'administrateur peux pas gérer et agencer son boot comme il veut parce que le système de boot est trop borné ou trop imprévisible, c'est lui qui devra trouver une autre solution, pas le mainteneur de la distribution.

Si tout le monde ou presque regarde systemd, c'est peut-être parce qu'il répond au besoin?

Il répondra pas à tout les besoins. Surtout sur les systèmes ou lancer udev invoque l'OutOfMemory Killer du noyau dans les secondes qui suivent.

Personne ne met un flingue sur la tête des gens.

Ben non, personne n'est obligé de réparer son système pour qu'il marche. C'est tellement plus marrant d'acheter du matériel et d'installer des systèmes dont tu ne peux pas te servir pour ce que tu veut en faire.

Personne ne te met un flingue sur la tête pour que tu livre des choses qui marchent à un client, pourtant tu le fait quand même, non ? (enfin j'espère)

Personne ne devra changer d'outil,

Tu prend le problème à l'envers. Ceux qui découvriront que systemd ne correspond pas à leur besoin devront changer d'outil. Faudrait quand même avoir un système qui marche à la fin, même s'il faut le maintenir soit-même. Parfois c'est la meilleure solution. Et parfois c'est la seule.

Il faut croire, la vue du déploiement de systemd, que non, systemd va en tuer des système d'init (où ils seront tellement peu utilisé qu'on ne se fera plus chier à ce que tout soit compatible avec les vieux standards), donc non, on n'est pas en plein dedans.

Avant, si je devais faire un démon à peu près portable, il suffisait généralement que je file un script rc.d pour les Linux et Unix-like, et peut-être de quoi avoir un service Windows et/ou un job launchd pour MacOSX.

Maintenant, je doit faire tout ça, et aussi un unit systemd pour les distros qui utilise ce truc. Le script d'init ne va pas disparaître, vu que BSD est pas près de passer à systemd.

Un standard de plus.

Et puis, bon, la, sortir ça pour un logiciel comme ça, va jusqu'au bout et gueule qu'il y a trop de distros Linux, c'est chiant.

Pourquoi ? Si toutes ces distributions respectent un standard de fait que je peux utiliser (au hasard, POSIX, FHS, ou l'API du noyau Linux), j'ai aucun problème avec ça. La seule chose chiante c'est les bugs que chaque distribution se prend. Mais heureusement qu'il y en a plusieurs. Si il y en avais qu'une seule, j'aurai aucun moyen d'échapper à ses bugs.

Sérieux, tu sais lire ce que sont les 4 libertés?

Je vois pas le rapport avec la choucroute. Note les trois premiers mots de ma réponse. "Dans la pratique".

Si tu as un problème réseau avec NetworkManager et que ta seule solution est de le virer montre plutôt que tu ne sais pas l'utiliser correctement. NetworkManager est très puissant.

Ah bah, t'a ptet raison, je sais peut-être pas l'utiliser correctement. NetworkManager doit être tellement puissant que je suis pas obligé de remonter des patches à son code moche pour lui rajouter des fonctionnalités.

Je vais pas en dire plus, je risquerai d'être odieux. Ah je le suis déjà ? Mince alors.

Apres dans la realite, je ne connais aucun logiciel qui remplace un autre. Il y a toujours quelques choses qu'on gagne, quelques choses qu'on perd.

Non. Dans la pratique, on remplace jamais les logiciels qui marchent. Ceux là, on oublie presque qu'ils existent. Par contre on cherche à remplacer les logiciels qui marchent pas, qui sont de la merde, qui sont totalement inadaptés à ce qu'on veut faire, qui sont trop lent, trop gros, trop stupides, trop inutilisables ou trop limités.

Si il y a autant de gens qui cherchent à remplacer NetworkManager, systemd, udev ou dbus, il faudrai peut-être regarder pourquoi.

Depuis quand tu peux remplacer qt par gtk ou par les efl sans changement ? Et bind par dnsmasq ? Ou bash par csh ?

La question ce n'est pas savoir si tu peux sans changement, c'est comment tu peux, et avec quels changements.

Et puis, sérieusement, t'a vraiment besoin de Qt/GTK/EFL pour afficher un pov' texte sur une matrice LCD 200x40 ? T'a vraiment besoin de bind pour servir deux trois pecnos sur ton réseau local ? Ou d'un shell utilisable par un humain pour lancer deux trois scripts de démarrages sur une machine sans utilisateur ? Ou de lancer une session gnome pour afficher un écran de login ? Parce que dans tout les cas, ça va ptet te convenir à toi, mais chez d'autres, ça sera lent, chiant, inutilisable, ou les trois à la fois. Et ils devront changer ça.

Systemd apporte une coherence inter distribution qui n'existe pas sous Linux.

C'est complètement stupide comme idée. Systemd n'apportera jamais de cohérence entre Linux, BSD et Windows de toute façon, et les logiciels ne vont pas s'arrêter d'être portable.

En fait, systemd ne va même pas apporter de cohérence dans les distributions Linux puisqu'il y aura des distributions Linux qui ne l'utiliseront pas et qui pourront même pas rester compatibles avec celles qui l'utiliseront tellement systemd n'est pas générique. Je vais pas encore ressortir le fameux XKCD, mais on est typiquement en plein dedans, Systemd n'est qu'un standard supplémentaire pour en unifier d'autres.

Si tu a envie d'unifier des distributions Linux (et d'autres OS), tu fait pas des grosses implémentations monolithiques de standard hyper-spécifiques, tu fait des standard comme POSIX, FHS, LSB ou autres qui sont suffisamment génériques pour être applicables sur toutes les distributions Linux et Unix-like et voir même le gros OS monolithique qu'est Windows. Pas un faux "standard Systemd" qui dépend de D-Bus et de plein d'API spécifiques à Linux, et que tu ne peux pas intégrer à un système existant sans devoir tout refaire.

Mais bon, il ne faut pas oublier ce qu'est le logiciel libre. C'est un logiciel qui peut etre librement modifie pour etre adapate a SES propres besoins.

Raté. Un logiciel libre, c'est un logiciel qu'on réutilise. T'en vois souvent des logiciels clairement inadaptés se faire modifier en profondeur pour coller à un autre besoin ? Moi pas. À la place, je vois des grosses réimplémentations plus ou moins génériques, parce que d'une part ça prend moins de temps, ça collera mieux au besoin et que ça sera plus facile à maintenir qu'un fork d'un logiciel clairement pas fait pour et ou upstream ne voit même pas l'utilité du besoin.

À l'arrache:

# gif animé transparent avec 5 ms entre les frames, bouclage infinie et 400x200
set term gif animate transparent opt delay 5 loop 0 size 400,200
# sortie dans funky.gif
set output "funky.gif"
# variable sur quoi j'vais itérer
it = 0
# dessine une première fois
plot [0:10] [-1:1] cos(it) * cos(x)
# redessine en incrémentant it de 0.1 jusqu'à 6.28.
while (it < 6.28) {
it = it + 0.1
replot
}

Après, si tu veut du plot paramétrique ou sphérique, gnuplot sait faire.

L'inlining sert surtout à virer des branches et des cas impossibles. L'exemple typique c'est la fonction qui vérifie ses paramètres et qui renvoie une erreur lorsqu'ils sont incorrects, alors que le code appelant ne passe que des paramètres corrects. Points bonus quand le code appelant vérifie la valeur de retour.

Après, avec les inlining etc., il est possible que cela ait un effet sur la fonction englobante bsearch (pour laquelle le param key n'est naturellement pas défini en restrict).

Si le param key n'est pas défini en restrict mais que tu a le droit de considérer qu'il l'est, j'ai du mal à comprendre pourquoi le code n'est pas considéré comme étant invalide.

Dans tout les cas, si la fonction de tri se fait assez inliner et que la valeur à chercher ne sort pas trop d'un coin paumé ou d'une arithmétique de pointeur foireuse, le compilo va s'en rendre compte tout seul qu'il n'y a pas d'aliasing possible. En fait je vois même pas l'intérêt de mettre du restrict ou du const sur une fonction qui va se faire inliner la tronche.

Dans tous les cas, effet du restrict ou pas, les perfs resteront supérieures ou égales au code c++. Le restrict est juste une petite indication supplémentaire au compilo mais cela n'est pas le coeur de la solution, celui-ci étant l'inlining.

Il va falloir m'expliquer comment la perf dans ce cas pourrai être supérieure au code C++. Que ça soit égal, c'est ce à quoi je m'attend, mais supérieure ?

Les version C et C++ ne sont surtout pas du tout équivalentes:

Sans blague. L'interface requise pour bsearch() et std::equal_range() n'est pas du tout la même. Donc les fonctions ne font pas la même chose. T'en a d'autres comme ça des portes ouvertes à enfoncer ?

La plupart des algorithmes de la bibliothèque standard réclament une fonction de comparaison qui introduit un ordre strict faible. Pour les non-matheux, ça veut dire une fonction booléene compare(a,b) qui doit retourner vrai si a est strictement en dessous de b. On teste l'égalité trivialement avec not compare(a,b) and not compare(b,a), même si en pratique, c'est souvent testé en même temps que les inégalités à coup de branches du style :

if (compare(a,b)) { /* a en dessous de b */ }
else if (compare(b,a)) { /* a au dessus de b */ }
else { /* a équivalent à b */ }

Par défaut, ça utilise std::less (donc a<b). Là le monsieur doit avoir un tableau d'entiers trié par ordre décroissant, et à choisi de ré-implémenter std::greater plutôt que d'utiliser celui qui est dans la bibliothèque standard.

Ça dépend pour qui.

On va dire que t'as fait tes interviews dans la mauvaise boite…

C'est pas comme si je pouvait choisir dans quelle boite je fait mes interview. J'ai juste le choix de là ou je postule.

On peut parler de C++11 aussi, si tu veux. Combien de codeurs C++ connaissent son existence ? Combien ont déjà expérimentés avec ? Et surtout: Combien l'ont réellement pratiqué pendant une durée suffisante pour monter en compétence dans des boites qui sont encore au standards d'il y a 5 ans ? Et c'est bien plus vieux que PHP 5.4.

Ton job ca va être d'analyser et de comprendre.

Ce n'est pas ça que tu évalue lors d'un entretien d'embauche. Ce que tu évalue est une personne stressée qui est potentiellement au chômage en crevant la dalle, qui va se retrouver en face d'un pair qui va plus préjuger que juger, sur des critères totalement différents à la fois sur le résultat et la démarche, et auquel il est plus ou moins malvenu de poser des questions.

Au final, celui qui s'en sortira le mieux c'est le beau mâle blanc valide du même age que le recruteur, avec le moins de problème, le plus à l'aise et qui n'est pas trop mauvais techniquement, et sans doute déjà en poste. En gros, le mec qui avait le moins besoin du job.

Si tu considère qu'un entretien d'embauche c'est la même chose qu'un entretien avec des clients, ou que la personne auquel tu fait un entretien d'embauche se comporte de la même manière que si il était hors période d'essai, t'est mal barré.

En entretient l'important c'est d'adapter ton approche et surtout de discuter et d'expliquer.

Avec certains recruteurs, si tu commence à discuter ou à poser des questions, c'est déjà fini pour toi. T'est censé répondre aux questions et c'est tout, il à des cases à remplir (mais tu va pas scruter ce qu'il est en train d'écrire, ça serait impoli).

Si tu t'attend à ce que le mec te pose la question "qu'est ce que vous attendez de moi ?", alors fait lui bien comprendre que tu n'est pas le recruteur sadique qu'ils ont vu juste avant avec qui ils ont foiré leur entretien. Et non, le mettre à l'aise n'est pas suffisant, ça, le recruteur d'avant l'a fait mieux que toi.

Alors le mec est obligé de deviner tes intentions sans pouvoir poser de questions. C'est difficile, et c'est normal que tes candidats se trompent. Et va pas leur dire que c'est de leur faute.

5.4, ça fait quoi, 2012 ? Et tu voudrai pas par hasard des gens avec 5 ans d'expérience là dedans, pendant qu'on y est ?

Faire adopter une nouvelle version d'un langage, c'est difficile, quelque soit le langage. Pense qu'une grosse boite à redmond vent encore des compilateurs qui supportent pas C99, qui date de 14 ans.

vCard ? Format simple ? On parle bien du même là ?

On parle bien du format avec 3 version différentes avec 3 grammaires incompatibles entre elles (et ne parlons pas de la réunion des trois), dont une (2.1) ou le numéro de version peut se trouver n'importe ou (y compris à la fin) ? ou l'encodage peut changer n'importe quand, et ou l'encodage par défaut dépend du contexte (ex type MIME quand c'est attaché à un mail) ? Ou un peut mettre une vCard 2.1 entière dans une propriété AGENT d'une autre vCard 2.1 (ça sert à renseigner le secrétaire d'une personne) ? Avec des extensions sauvages d'organismes indépendants ? Avec plein de fonctionnalités à la sémantique non définies que personne n'utilise mais que le format t'impose de gérer quand même ? Ou la version la plus utilisée (2.1) est la plus pourrie ?

T'est mignon.

Dans le test, je me contrefiche de comment il a codé réellement, et encore moins que ça fonctionne à la fin. Qu'il ai mis commentaires ou pas. Qu'il ai factorisé ou pas. Et surtout des règles de coding. Ce qui m’intéresse, c'est la logique employé.

Est ce que tu l'a dit au candidat ? Tout me laisse à penser que non. Et même moi en tant que candidat je pourrai pas réfléchir à ce que veut vraiment l'examinateur en ayant la tête dans le guidon, j'aurai quand même tendance à vouloir faire du code propre et maintenable, du type de ceux dont les gens sont près à me payer pour faire. Toi tu t'attendait à du code torché en 1h40 qui va aller à la poubelle avant la fin de la journée.

Ce qui m’intéresse, c'est la logique employé.

Et pourtant, au bout des trois heures, […]Il n'avait pas testé son code une seule fois

Donc en gros t'est en train de nous dire que tu voulais surtout savoir comment le mec raisonne, que le candidat l'a parfaitement bien compris, qu'il s'est concentré à te montrer comment il raisonne. Et ensuite tu viens te plaindre qu'il n'a pas pensé à tester son code ?

Je vais t'apprendre un scoop: Si tu ne dit pas ce que tu veux, tu n'aura pas ce que tu veux.

Ton candidat à déjà deviné une grande partie de ce que tu voulais, mais c'est manifestement pas assez. T'a passé toutes ses compétences techniques (peut-importe qu'elles soient maigres, ou pas assez avancées à ton goût) à la trappe parce que il ne t'a pas assez bien cerné. Et après on se plaint des entretiens d'embauches qui ne sélectionnent pas les gens les plus compétents.

Personne ne leur à dit qu'aujourd'hui, avoir l'UID à 0 n'est pas la même chose qu'avoir tout les droits/capabilities ?

Ça risque de troller sec (surtout avec 642872e7cb9658da4b48d81ca366961a), mais bon :

Mon lieu de travail à changé. Les 12 heures sont du temps de transport.

Tu parle du gars qui ne contribue plus depuis qu'on lui à sucré 12 heures de son temps libre hebdomadaire ?

Il y a déjà des documents qui sont sortis sur Daala, pas les plus intéressants, certes, mais d'autres vont venir. Et une fois que le doc a été publié, MPEG-LA ne peut pas le breveter.

Ah bon ?

Bien-sûr que si il peut le breveter. Le brevet sera invalide, certes, mais ça te coûtera 3 millions pour le prouver.

C'est une réponse générique que l'on peut faire à n'importe quoi de brevetable, d'ailleurs.

Non, celui qui est contrôlé par l'OS.

Pourquoi pas _pkg-server._sub._http._tcp ?

(OK il faut une indirection et ça sera aussi visible en tant que _http._tcp, mais bon …)

Mais qu'est-ce que vous foutez pour avoir besoin de 16/32G dans un téléphone?

C'est pour installer Debian dessus, bien sûr!

ça me fait juste peur : c'est quoi ce 0.001, ça sort d'où ? et le 0.98 etc…

C'est genre clairement expliqué dans le manuel utilisateur: c'est de le coefficient de friction de la loi de coulomb

Sauf que Wireshark n'est pas une voiture, mais une dépanneuse.

C'est un peu comme les dépanneurs/remorqueurs de la SNCF qui fonctionnent à l'essence (ou à d'autres sources d'énergies qui puent) alors que les voies sont toutes électrifiées.

Ce jeu reste quand même Thief tout craché, avec le même environnement, ambiance, armes et gameplay.

Sachant que l'une des caractéristiques principales du gameplay de Thief est de forcer le joueur à éviter les combats à tout prix (le héros est mauvais combattant, n'a pas d'armure et à autant sinon moins de point de vie que les gardes, qui sont nombreux et rarement isolés), je doute que The Dark Mod possède un jour un système de combat évolué.

Pour info lo = loopback = interface réseau système.

C'est quoi une "interface réseau système" ? Techniquement, toutes les interfaces réseaux sont gérées par le système, vu que pour le noyau, la définition même d'une interface réseau n'est qu'une abstraction des couches inférieures, abstraction qui est notamment utilisée par les implémentations des protocoles IP.