Fabrice Devaux a écrit 118 commentaires

Tu parles sûrement de IDE vs. AHCI, ce qui n'a rien à voir avec disque dur vs. SSD. Je me trompe ?

Je fais quelque chose qui ressemble un peu. Mon but n'est pas d'avoir l'historique, mais d'être notifié par e-mail de toutes les opérations sur mon compte, le plus tôt possible. Le script suivant tourne dans un cron toutes les N heures en semaine :

    #!/bin/bash

    BALANCE=`boobank -b XXX list -f simple --select balance -c "id=XXX" 2>/dev/null`

    echo $BALANCE | diff $HOME/.account_balance - > /dev/null

    if [ $? -ne 0 ]; then
            echo $BALANCE > $HOME/.account_balance
            BALANCE="Solde du compte : $BALANCE EUR\n\n"

            (echo -e $BALANCE; boobank -b XXX  history XXX 2>/dev/null) | cat -v | mail -s "[Compte courant] Operation" YYY
    fi

Et l'e-mail indique les dernières opérations sur le compte.

J'ai rien bité.
(Pas de ta faute, je suis développeur système, vos trucs de web ça me dépasse totalement.)

Et un bookmark plus "grand public".
http://www-verimag.imag.fr/wordpress/maraninx/une-petite-experience-de-vulgarisation-sur-le-bug-meltdown/

Soyons clairs, le débat ici est sûr les coûts de structure délirants des grandes entreprises, et leur comptabilité analytique foireuse qui les mène à prendre des décisions encore pires.
Donc quand je parle de "ce que le salarié voit", j'entends "salaire net".
Il y a un autre débat, tout aussi intéressant mais hors sujet ici, sur le pourcentage réel de ponction de l'État sur les revenus, dans lequel la question de la CSG non déductible a sa place.

Tu argumentes pour défendre quelque chose que j'ai déjà pris en compte. Le coût journalier s'entend bien évidemment en jours réellement travaillés par an, donc les congés payés sont déjà pris en compte, c'est pour cela que j'ai divisé par 220 (tu peux diviser par 210-220… ça dépend des contrats de travail).

Mon calcul est donc correct, c'est bien 240 euros de coût journalier salarial effectif pour l'entreprise, soit moins d'un tiers du coût total annoncé. Le reste passe majoritairement dans les chefs (donc en majorité dans le contrôle et le micro-management, dans ces boîtes), qui sont d'ailleurs officiellement considérés comme improductifs (au moins sur ce point l'entreprise ne se ment pas) puisque leur coût est répercuté sur celui des employés.
Moi aussi j'ai eu du mal à y croire au début.

On peut faire le calcul exact si tu veux. En reprenant ma fiche de paie, je touchais 36k brut, soit 28k net, soit 53k superbrut (en gros, superbrut = 1.9 * net, et non 2 *
brut comme tu le dis—c'est vrai en général et je l'ai vérifié sur une fiche de paie d'époque).
Les congés payés n'ont rien à voir, ils font partie du salaire brut annuel.
Cela pour 220 jours de travail par an soit 240 euros par jour = 32% du coût moyen journalier officiel.

J'ai donc un peu exagéré en parlant du cinquième, la réalité étant un peu moins que le tiers. Ça ne change pas vraiment mon propos ;)

J'ai entendu un truc que j'aime bien sur la diffusion de l'incompétence dans une entreprise :
A people hire A people
B people hire C people
C people hire their friends

La comptabilité analytique, c'est l'analyse détaillée des coûts. Par exemple, c'est ce qui permet à Apple de dire qu'un iPhone lui coûte tant à produire. Le problème, c'est que c'est loin d'être fiable, parce qu'il faut faire énormément d'hypothèses diverses, et qu'on ne peut pas toujours s'en servir. Exemple tout bête, tu fais tes divisions et tu calcules qu'un développeur logiciel dans ta boîte te coûte en moyenne 750 euros par jour (rigole pas, c'est exactement le prix que je coûtais en tant qu'ingénieur débutant dans une grande entreprise industrielle). Bon, en réalité le développeur voit un cinquième de ça, et tout le reste c'est des coûts de structure débiles (notamment le salaire de ses chefs). Donc, quand un sous-traitant arrive et te propose un contrat à 600 euros par jour, tu dis "ouais, génial, c'est moins cher que d'embaucher". Mais c'est une erreur de raisonnement. Sauras-tu la trouver ?

Le coût marginal d'un indicateur, c'est combien coûte à l'entreprise le fait de rajouter un indicateur. Ces indicateurs ont un coût énorme pour les entreprises car il faut les créer, donc payer tes employés à les remplir (et cela prend un temps fou, à peu près deux heures par semaine dans mon expérience personnelle). Et en plus, ils ont un coût caché en terme de corruption de la culture d'entreprise parce que tout le monde va mentir sur ces indicateurs (vu que ta carrière en dépend et qu'ils sont bidonnables).

L'outil de compta analytique, je ne sais pas à quoi il fait référence, mais je me souviens par exemple d'un outil où on pointait notre journée de travail par tranches de 2 heures. Je précise qu'il fallait pointer 8h par jour alors que le contrat était de 7h30, et que les réunions d'équipe (avec 5 chefs pour 25 personnes on n'en manquait pas) n'étaient pas pointables, donc on les imputait aux projets. Projets dont le temps était déterminé par négociation avec le chef. "Fabrice, il te faut combien de temps pour faire ça ?" (avec un "cahier des charges" qui tient en quatre lignes donc impossible à analyser) "oh, je dirais 20 jours" "OK je t'en donne 5".

Merci infiniment à l'auteur du journal d'avoir décrit exactement ce que j'ai vécu chez… allez, je la nomme, Michelin. Heureusement que la boîte a des acquis sur lesquels elle peut s'appuyer…

Hein ? Non. L'URSSAF se contente d'un original, et parfois on peut même faire sans et ça passe.

tant qu'il n'y a pas d'affichage interactif du contenu des registres, ça me fait une belle jambe

C'est pour ça que cgdb n'est pas adapté au travail en assembleur. J'utilise https://github.com/cyrus-and/gdb-dashboard à la place.

silicone

silicium

Mon expérience personnelle et directe, c'est que La Poste prend au sérieux les plaintes sur la qualité de service. Peut-être que ce n'est pas vrai dans tous les cas, mais il ne faut pas faire de généralités en disant que c'est impossible de se plaindre auprès de La Poste… parce que c'est bien, bien pire (à tous les niveaux, d'ailleurs !) chez les concurrents, qui sont en général bien plus chers !

Tu appelles le service client de la Poste, tu déposes ta réclamation, ça prend 15 minutes au téléphone et le problème est en général réglé rapidement parce que l'employé se fait taper sur les doigts. Je l'ai fait deux ou trois fois dans les années écoulées.

L'intérêt principal du fichier client d'EDF et GDF (désolé, leur nouveau nom est tellement ridicule que ça rejaillirait sur mon propos de l'utiliser), c'est de pouvoir identifier la ligne à partir d'un nom ou d'une adresse.
Pour mémoire, l'identifiant unique d'un point d'abonnement EDF ou GDF s'appelle point de livraison (PDL) ou point de comptage et d'estimation (PCE, ça c'est pour le gaz). C'est ce numéro à 14 chiffres, qui n'est pas écrit sur le compteur (!), qu'il faut théoriquement donner pour s'abonner à un fournisseur d'énergie. L'adresse, le nom de l'ancien occupant, … ne sont pas valables, c'est le PDL qu'il faut. EDF et GDF, avec leur fichier client, peuvent aisément retrouver ce PDL à partir de ces informations. Les autres fournisseurs ne le peuvent pas, sauf si l'ancien occupant, par chance, était client chez eux.
Ainsi, si vous emménagez dans un logement et que vous voulez vous abonner chez Direct Énergie, il vous faudra trouver le PDL et le PCE. Essayez un peu de demander au propriétaire ou à l'ancien locataire, pour voir la tête qu'ils vous feront. Par contre, pour vous abonner chez EDF/GDF, il suffit d'appeler et de donner quelques informations parcellaires, et ils pourront établir l'abonnement.

Peut-être que ce que je raconte a déjà changé, n'ayant pas été confronté au problème depuis quelques années. Lors de mon déménagement récent, Direct Énergie a pu trouver les PDL et PCE à partir de l'adresse.

Le fonctionnement est le même pour l'ADSL, sauf que cette fois-ci tous les fournisseurs ont accès à la base France Télécom. L'identifiant cette fois-ci s'appelle ND (numéro de désignation) - parfois NDI lorsque la ligne est inactive - et il ressemble à un numéro de téléphone. Et là, bon courage pour le retrouver, car il n'apparaît pas sur la facture. Par chance, tous les fournisseurs peuvent le retrouver (avec plus ou moins de succès) en faisant des recherches dans la base France Télécom.

Il faut effectivement ne pas s'arrêter au prix de l'appareil et investir un peut à l'achat. Et c'est peut être ça le problème. Tout le monde ne peut pas se permettre cet investissement initial. Tout en sachant qu'un lave-linge à 100€ ou 100CHF de chez Aldi, on est sûr qu'il ne sera pas réparable.

Bof. Rien ne permet d'indiquer que l'électroménager premier prix est moins réparable. En fait, dans mon expérience personnelle, ça serait plutôt l'inverse…

J'espère que cette annonce va vraiment être suivie d'effet. Apparemment jusqu'à présent ce n'était pas la joie, voir par exemple https://perso.aquilenet.fr/~sven337/francais/2014/08/11/Reparation-four-Seb-delice-turbo-OF265800.html

Rendre les produits réparables, ça demande non seulement d'avoir des pièces détachées ("à prix coûtant"), mais aussi d'avoir accès aux schémas et à la documentation technique sans passer par un "réparateur agréé" qui rend les réparations prohibitives. Or, il me semble que Seb est une marque très connue pour son réseau de réparateurs professionnels en dehors desquels rien n'est possible.

Tu ne vois pas l'intérêt d'un gros débit Internet, tant mieux pour toi, tu dois être un espèce rare sur LinuxFR !

Pour développer en télétravail, j'ai pas l'impression qu'avoir un énorme débit soit hyper pertinent. J'veux dire c'est pas des commits git et des connections SSH qui vont te bouffer ta bande passante. Tant que c'est stable tout va bien.

Et pourtant… Sur des gros projets ce n'est pas rare d'avoir plusieurs Go à transférer dans la journée, et quand tu es devant l'écran à attendre, ça fait rapidement du temps perdu (des fois on arrive à faire autre chose, mais pas toujours).

Et ne vous méprenez pas sur la "province" ou la "campagne" mais il existe des villes de moins de 2500 habitants avec un débit internet capable de faire de la télé HD depuis longtemps.
La grosse différence vient aussi du fait que le même matos et/ou tuyaux sont utilisés par 2500 habitants au lieu de 30 ou 40000

Pas que : il y a aussi que dans une petite ville, on est statistiquement plus proche du DSLAM, puisque l'aire urbaine est moins étendue ! :)
Ça n'est pas toujours vrai - s'il n'y a pas de DSLAM, c'est pas rare de se retrouver avec un débit ADSL catastrophique - mais s'il y en a un, c'est très courant d'obtenir en moyenne un débit plus élevé qu'en ville. (Source: mon expérience personnelle. Chacun est libre de ne pas être d'accord.)

La complexité que je vois à MQTT, c'est que c'est quelque chose de plus à apprendre à utiliser, alors que les problèmes que ça règle sont souvent soit carrément imaginaires, soit facilement réglés autrement. Et qu'au final tous ces logiciels tout faits ont des limitations sérieuses, différentes pour chacun en fonction de ses besoins précis, qui vont poser problème.

On voit régulièrement des gens qui font leur premier ou deuxième montage domotique, et qui attaquent le sujet par la question "qu'est-ce que je peux installer comme logiciel serveur pour gérer cela". Au final, je trouve amusant d'avoir plus de code côté serveur, écrit par d'autres et donc pas forcément bien maîtrisé, que de code dans les "devices" - et surtout ça détourne les gens du coeur du sujet, qui est de créer et installer les "devices", pas de se poser des questions de logiciel serveur.

Je ne doute pas que ça peut rendre service, mais attention à ne pas régler le mauvais problème : il n'est pas nécessaire de se préoccuper de ce genre de logiciel pour faire de la domotique. Comme amélioration, une fois que les dispositifs sont en place, pourquoi pas, mais attaquer avec cela dès le début ne me semble pas vraiment justifié. De mon point de vue c'est un peu comme choisir la peinture avant d'avoir creusé les fondations.

(EDIT: Mosquitto, c'est environ 15kLoC dans les répertoires src/ et lib/. Je crois que ça prouve bien mon argument… j'avais cité 4k au pif, mais en fait c'est bien pire.)

Personnellement, ça me fait toujours un peu sourire de voir des gens utiliser 4000 lignes de code logiciel côté serveur, et un paquet de code côté client, juste pour faire communiquer leur cinq ou six dispositifs domotiques.
J'ai écrit mon propre système from scratch, qui combine un serveur UDP et une "webapp" en Flask, et les clients (ESP8266 + un Raspberry Pi avec un nRF24L01+ pour s'interfacer avec des arduino) envoient des paquets UDP ou des requêtes HTTP selon le besoin. C'est plus léger que MQTT, ça m'évite de me prendre la tête à comprendre des concepts compliqués totalement inutiles, et ça fait exactement ce que je veux. J'ai une quinzaine de montages divers qui communiquent de cette facon, et ça fonctionne très bien.

Évidemment, chacun fait comme il veut, mais n'oubliez pas que le DIY, c'est valable pour le logiciel aussi !
Pour justifier une plateforme logicielle complexe, il faut avoir un usage complexe, ce qui n'est quasiment jamais le cas en domotique, même avec un capteur et un actionneur par pièce.

(Par ailleurs je n'aime pas trop ESPEasy, qui est un peu heavyweight à mon goût.)

Dans le code que tu cites, deux macros, UNIX64 et WIN64, sont définies, et utilisées pour émettre du code qui est différent du 32 bits (et pas que en ce qui concerne l'ABI, en admettant ta supposition que la différence d'ABI "ne compte pas", ce qui est faux par ailleurs puisque ça a un impact sur les perfs). Le code est moins différent que ce qu'on pourrait croire (ce qui par ailleurs ne prouve rien à part que personne n'a pour l'instant fait l'effort, dans x265, d'écrire du code spécifique x86-64).
Et je ne parle même pas de PIC qui semble activé par x265 en x86-64 et pas en x86, ce qui va générer du code différent (sachant qu'un des avantages du x86-64 est justement qu'il permet de faire du PIC avec de meilleures perf que le x86 grâce à l'adressage RIP-relatif)… en d'autres termes, x265 désactive PIC en x86 pour pas se prendre une trop grosse claque en perf !

Mais si on retire tout ce qui gêne ton argumentation, alors oui, le code est le même. Et de la même façon, si on retire tous les avantages de x86-64, alors oui, x86 est supérieur. C'est ce qui semble être ton propos depuis le début, certainement motivé par l'intention de contredire les intervenants quel que soit leur propos, en étalant tes connaissances comme si tu étais le seul à en avoir.

x86-64 a quelques inconvénients qui à part dans certains cas très précis - auxquels tu as, semble-t-il, été confronté, de telle sorte que ça colore ton expérience et ton discours - sont largement compensés par les avantages. Je pose justement cette question en entretien d'embauche, et ça fait des "points bonus" de savoir dire que l'augmentation de la taille des pointeurs peut poser des problèmes en terme d'empreinte mémoire, mais pour l'instant on ne m'a jamais servi d'argument solide pour dire qu'il vaut mieux développer en x86. Le seul qui tiendrait la route c'est celui de maximiser la compatibilité avec les anciennes machines.

Au fait, gros malin, le jeu dont tu parles s'appelle Xonotic, pas Xonotix. Ça fait désordre pour ta crédibilité :)

Je crois qu'à ce stade, tout le monde sait à quoi s'en tenir, donc je m'arrête là.

il faudrait quand même essayer de se renseigner avant de raconter n'importe quoi hein…

Oui, ça serait pas mal que tu te renseignes avant de raconter n'importe quoi.

c'est le même code assembleur qui sera utilisé en i386 ou en amd64

C'est faux.

Pardon—mon commentaire mélangeait HIGHMEM et PAE. Entre 1G et 4G en x86, le noyau se débrouille avec HIGHMEM et PAE n'est pas nécessaire, uniquement utile comme dit par quelqu'un en dessous pour le bit NX et quelques détails du genre.

Ça n'a complètement rien à voir avec PAE, mais l'idée c'est de créer un "fichier" temporaire dans /dev/shm (ou n'importe quel tmpfs), et de le mapper dans l'espace d'adressage de l'appli avec mmap. Cela permet de manipuler plus de mémoire physique que ce que l'espace virtuel permet, à condition de un-mapper à chaque fois qu'on a fini de s'en servir. En plus, les données peuvent être mises en swap par le noyau. Parfait quand l'appli veut se créer un cache de trucs qui sont pas utilisés souvent mais qui doivent être en mémoire.
En 64 bits, vu que l'espace virtuel est immense, on ne s'embête pas avec cette technique, mais en 32 bits c'est très utile.