Pour tuer le confinement je me suis remis à programmer

[Patakesse]

Mais je ne doute pas qu'il soit AUSSI un fou furieux de la programmation (en plus d'être un fou furieux tout court)

 

[svoglimacci]

Mais je ne doute pas qu'il soit AUSSI un fou furieux de la programmation (en plus d'être un fou furieux tout court)

Ouais, les deux !
Mais tu n'es pas triste non plus visiblement.

J'ai (un peu) connu un gars (de loin, on s'est à peine parlé par forum interposé) très actif sur le P2P qui patchait un programme P2P serveur en ram parce qu'il n'avait pas les sources. Et qui contactait Intel pour leur signaler que le driver de leur carte réseau avait une erreur, elle ne tenait pas plus de x millions de connexions ou je ne sais quoi. En fournissant le correctif bien entendu.
Le genre de gars capable de hacker son sandwich au jambon...

 

[Patakesse]

Oui ça ressemble fort à ce que je faisais quand j'étais jeune

Le code auto-modifiant, les redirections des fonctions système, les patches de l'OS qu'on fait directement en RAM puis qu'on dump sur disque, le désassemblage et débogage système (avec une carte), le crack de protections logicielles, le hacking du Minitel, que de bons souvenirs !

Mais je m'incline, j'ai jamais hacké un sandwich au jambon.

 

[andre.gerald]

Merci @magellan
Je vais envoyer le lien de la discussion au fiston !!!

 

[svoglimacci]

Mais je m'incline, j'ai jamais hacké un sandwich au jambon.

Je suis sûr que si
Il y a des gens qui, lorsqu'ils regardent de l'électronique, donnent l'impression que celle-ci a peur pour son intimité et veut se sauver en courant. J'en ai croisé deux ou trois, tu me sembles faire partie de cette famille
Bon, on arrête le cirage de pompes

 

[andre.gerald]

Mais je m'incline, j'ai jamais hacké un sandwich au jambon.

Il parait que c'est le plus difficile à faire ça

 

[magellan]

Il n'a fait que republier l'exemple de la doc de la fonction

Tu es vilain toi
Il y a eu d'autres posts, tout de même

Non il n'est pas vilain il a raison.
Et comme je ne m'approprie pas le code d'autrui, j'ai bien cité la source ainsi que le code collé vient de là-bas

 

[magellan]

Oui ça ressemble fort à ce que je faisais quand j'étais jeune

Le code auto-modifiant, les redirections des fonctions système, les patches de l'OS qu'on fait directement en RAM puis qu'on dump sur disque, le désassemblage et débogage système (avec une carte), le crack de protections logicielles, le hacking du Minitel, que de bons souvenirs !

Mais je m'incline, j'ai jamais hacké un sandwich au jambon.

Ici même dans les débuts du forum (enfin à l'époque de précence pc) il y avait des monstres en hack/sécurité web et j'en passe. Je me souviens de l'un d'eux qui avait fait une leçon de choses à un user pénible qui menaçait avec prétention le fonctionnement de notre antre...

L'autre a appris à ses dépends que l'expertise n'était pas de son côté! (je vous passe les détails)

 

[magellan]

Sinon côté codage mes expériences personnelles hors boulot.
- Coder sur Atari ST pour maîtriser le comportement des cracks posés sur les jeux. Passionnant
- Lecture des magazines dédiés comme feu ST Mag. J'adorais leurs pages sur le codage, les hacks, et même les DIY! Il y avait notamment un projet de scanner fixé sur une imprimante matricielle. Cela semble absurde, mais que ça marchait bien pour l'époque, à un coût réduit.
ça m'a mis aussi (un peu hein) à l'électronique où j'ai de petites bases à présent.
- Tentatives d'overclock sur Atari ST. Pas si concluant que ça, l'immense majorité des jeux ne géraient tout simplement pas un plafonnement du framerate, d'où un cauchemar.
- Installation d'un freeboot (seuls les "vrais" savent de quoi il parle le monsieur )
- Modification de sauvegardes à l'arrache pour saisir le raisonnement du stockage des données en hexa dans un dump
- Discussions intenses avec des gars qui faisaient partie de groupes de pirates (de l'époque). C'était passionnant que de chercher à comprendre les protections, notamment celle appliquée sur le jeu Dungeon Master.

(en anglais)
- Par la suite développement avec un pote d'un petit moteur de résolution de combat avec des règles simplifiées issues des règles de AD&D (je ne sais plus quelle édition des règles). C'était assez comique de faire, via des bidouillages sauvages dans le comportement, de voir un mage adverse (joué par l'ordinateur) balancer une boule de feu, faire donc des dégâts, puis se tirer systématiquement comme un lâche! :lol!:

 

[SergioVE]

Dans le genre pro, j’ai connu un Gus qui, quand il avait une erreur sur une compil COBOL, corrigeait directement le code machine défectueux du compilateur... Certes il travaillait à la réception et à la distribution des versions successives de ce compilateur, mais tout de même...

 

[magellan]

Dans le genre pro, j’ai connu un Gus qui, quand il avait une erreur sur une compil COBOL, corrigeait directement le code machine défectueux du compilateur... Certes il travaillait à la réception et à la distribution des versions successives de ce compilateur, mais tout de même...

là on est dans un calibre de haut niveau.
D'un point de vue pro, je garde un très (très très très) mauvais souvenir d'un produit "open source" casé par un éditeur. Le truc suggérait de faire du full Javascript de partout, jusqu'à la base objet intégrée...

Et ce truc était pétri d'une quantité dingue de bugs.

Donc concrètement, avec le collègue avec qui on devait tenter d'utiliser ça, on en est arrivés à faire des hotfix et les transmettre à l'éditeur au fil de l'eau pour obtenir quelque-chose d'un tant soit peu exploitable.

Résultat des courses: le tout à la benne au bout de quelques mois. Mais bon, aller corriger le produit de l'éditeur pour pouvoir s'en servir, ça devient délirant.

 

[SergioVE]

Mais je ne doute pas qu'il soit AUSSI un fou furieux de la programmation (en plus d'être un fou furieux tout court)

Pour réussir dans un domaine, faut être un peu fou furieux, non ?

 

[magellan]

Pour réussir dans un domaine, faut être un peu fou furieux, non ?

Je ne pense pas pour le coup. Etant encore actif d'un point de vue pro, j'affirme que l'immense majorité des devs ne sont pas des psychopathes de la technologie. Je pense même que les différentes générations de développeurs sont très différentes, parce qu'elles correspondent à des époques vraiment distinctes.
- Les tous premiers étaient ce qu'on peut qualifier de pionniers. Ils devaient tout faire "à la main", ceci imposant une rigueur implacable, ainsi qu'une connaissance aigue des technologies mises en oeuvre. Cependant, la plupart n'ont pas su (pu?) évoluer vers de nouvelles technologies faute d'envie et/ou d'opportunité.
- La deuxième génération (en gros la mienne on va dire) a perdu une part non négligeable de cette problématique car tout avait évolué vers une certaine simplification technologique. Quand je dis simplification, j'entends par là l'émergence des langages de haut niveau rendant plus "simple" l'accès aux couches basses des machines. Mieux encore: via les outils WISIWYG beaucoup en sont arrivés à ignorer la complexité réelle de la construction d'une application. Dans le lot tu as encore une part de fondus qui cherchaient à tout comprendre, plutôt que de rester cantonné à une portion congrue du métier.
- La génération actuelle qui profite énormément de ces outils qui mâchent le travail, mais qui, ayant baigné dès l'enfance dans la technologie, n'ont plus aucun scrupule à faire preuve d'imagination et de revendiquer leur métier. Ce n'est pas si récent que le développeur est perçu comme une personne "normale" avec un métier technologique, là où 20 ans en arrière on était des "geeks" sens péjoratif du terme. Eux profitent donc de ne pas avoir de crainte à bidouiller dans toutes les technos, mais pour beaucoup certaines pratiques semblent obsolètes.

Quand je dis cela, c'est à grosses mailles. Mais si je compare le métier d'aujourd'hui à celui d'il y a 20 ans, on ne se pose plus tant de questions que ça sur l'occupation disque/mémoire, on ne craint plus d'encombrer le processeur, et la gestion des données sur le réseau ne fait plus avoir des crises d'angoisse. Les bandes passantes actuelles permettent de ne plus se préoccuper de la taille des images par exemple, là où avant on collait carrément des processus sur les serveurs pour compacter toute image déposée dessus afin de les restituer en qualité inférieure certes, mais suffisante pour que l'affichage puisse fonctionner "partout" (ou presque).

Je ne dis pas qu'ils sont moins compétents. Loin s'en faut. Chaque époque a ses compétences propres. Ce que je dis, c'est que les raisonnements de développement ne sont plus les mêmes. En plus, avec le recul, les "anciens" ont profité d'un respect des entreprises où ils bossaient, car personne ne comprenait le métier, et tout le monde devait reconnaître la nécessité de ne pas les pressurer car les sociétés étaient très tributaires de profils relativement rares. Aujourd'hui, c'est hélas bien moins vrai, car la prolifération des "développeurs" sur le marché du travail les rend à la fois moins vitaux, donc jetables, et malheureusement moins "respectables". C'est particulièrement dégueulasse avec ces foutues usines à stagiaires qui usent à mort les jeunes pour faire des pages web à bas coût. Ces salopards les écoeurent, les pressurent, et se font un fric fou sur le dos de passionnés qui deviennent vite cyniques, voire abandonnent totalement suite à une très mauvaise expérience.

 

[andre.gerald]

@magellan
Mon fils a trouvé ta réponse sympa et utile !!
Donc merci pour lui

Remarque sur les développeurs:
J'ai pour habitude de souvent dire: Le salut vient plus des développeurs que du matériel

En effet:
On a des CPU et des GPU bourrés de cores qui si ils bossent pas en parallèle deviennent inutiles:
Exemple:
Avec Adobe Première Pro je n'utilise plus les encodeurs de Mainconcept qui sont lents mais un plugs gratuits fait par un développeur passionné qui donne des exports rapide de qualité.
Développer un soft qui utilise toutes les capacités des CPU & GPU actuels doit être un sacré challenge ? Je me trompe ??

Apple par exemple vend des appareils souvent à des prix honteux quand on regarde ce qu'ils mettent à l'intérieur ..Mais en vidéo par exemple ils ont un soft (FCP) qui exploite au maximum les possibilités matérielle de leur machine, d'après ce que j'ai cru comprendre.
La dernière version de CC2020 (je ne l'ai pas) a je crois progressé côté export @Patakesse devrait le confirmer

 

[magellan]

@magellan
Mon fils a trouvé ta réponse sympa et utile !!
Donc merci pour lui

Remarque sur les développeurs:
J'ai pour habitude de souvent dire: Le salut vient plus des développeurs que du matériel

En effet:
On a des CPU et des GPU bourrés de cores qui si ils bossent pas en parallèle deviennent inutiles:
Exemple:
Avec Adobe Première Pro je n'utilise plus les encodeurs de Mainconcept qui sont lents mais un plugs gratuits fait par un développeur passionné qui donne des exports rapide de qualité.
Développer un soft qui utilise toutes les capacités des CPU & GPU actuels doit être un sacré challenge ? Je me trompe ??

Apple par exemple vend des appareils souvent à des prix honteux quand on regarde ce qu'ils mettent à l'intérieur ..Mais en vidéo par exemple ils ont un soft (FCP) qui exploite au maximum les possibilités matérielle de leur machine, d'après ce que j'ai cru comprendre.
La dernière version de CC2020 (je ne l'ai pas) a je crois progressé côté export @Patakesse devrait le confirmer

Ta question est simple, mais la réponse est délicate

On a des CPU et des GPU bourrés de cores qui si ils bossent pas en parallèle deviennent inutiles:
Exemple:
Avec Adobe Première Pro je n'utilise plus les encodeurs de Mainconcept qui sont lents mais un plugs gratuits fait par un développeur passionné qui donne des exports rapide de qualité.
Développer un soft qui utilise toutes les capacités des CPU & GPU actuels doit être un sacré challenge ? Je me trompe ??

Non ils ne sont pas inutiles car leurs performances individuelles sont telles qu'elles permettent d'accéder à une multiplication de threads (fils d'exécution) sans que tu aies grand-chose à gérer. Aujourd'hui, on a tellement poussé les OS et les logiciels à ventiler leur usage des coeurs qu'une appli à thread unique profite de son coeur dans son coin... sans attendre son tour dessus. Les préceptes de gestion préemptive des fils d'exécution sont tellement avancés que cela peut même être un avantage sciemment choisi au moment du codage. Mais là c'est à la marge et très complexe dire si, oui ou non, ça fait sens d'aller vers telle ou telle structure codée.

Ensuite: utiliser les capacités GPU/CPU n'est de base pas forcément un vrai challenge au sens où les langages et les librairies actuelles intègrent très majoritairement tout ce qu'il faut. Par exemple, si tu veux tester du machine-learning, les librairies documentées permettent sans grosse difficulté d'aller chercher de la puissance processeur (GPU/CPU) là où elle est selon ta machine. En gros? Tu lui donnes un ordre, et si ta machine dispose d'une CG permettant des instructions spécifiques (style CUDA pour simplifier énormément), cela va se faire sans des efforts dingues.
Je caricature naturellement: bien équilibrer la charge est un challenge, et cela l'a toujours été. C'était même pire avant, notamment sur les serveurs où, là, tu étais carrément sur des multiprocesseurs et non des multicoeurs. Il fallait donc aller bien plus loin dans la gestion de tes threads, identifier techniquement ce que ta machine pouvait autoriser, et surtout faire énormément attention à l'allocation mémoire pour ne pas créer des goulets d'étranglement.

Là où il y a challenge, c'est d'être capable de bien exploiter les possibilités de ces machines, et derrière de faire en sorte que tous ces éléments exécutés en parallèle se synchronisent correctement... et que cette synchronisation vaille la peine.
Schématisons très vulgairement: (l'exemple que je vais donner sera très grossier mais qui peut faire sens)
- Admettons une conversion d'une vidéo d'un format A (son+image) vers un format B (son et image dans des codecs différents)
- Admettons que la conversion audio ne peut pas être segmentée, pas plus que la conversion vidéo
- Cela donne que seuls deux flux parallèles peuvent bosser; la vidéo d'un côté, et de l'autre l'audio.
Résultat: pour avoir le fichier final, il faut forcément attendre que le plus lent des deux ait fini son job. Est-ce vraiment un gain de paralléliser? En principe... oui, à condition que les coeurs utilisés n'aillent pas perdre du temps à cause d'autre processus de ta machine. Il peut être plus rentable de saturer un coeur pour tout faire seul.
Si l'on pousse ce raisonnement, on peut dire (par exemple)
- L'audio a x plages (5.1 par exemple). Faisons chaque plage sur un coeur pour accélérer cette gestion de conversion
- La vidéo peut être découpée par segments quelconques (peu importe le raisonnement technique, là c'est pour l'exemple), traitons chacun de ces segments en parallèle.

Tu as donc les outils, les composants, ça n'est pas "complexe" en principe, mais ça le devient dès que tu veux faire les choses correctement.

Je soupçonne que ton exemple met en exergue deux choses:
- Adobe n'a pas réformé ce composant. Ses performances sont meilleures qu'avant car les coeurs uniques, eux aussi, sont meilleurs que les anciens sur les mêmes exécutions
- Que le plug in dont tu parles tire bien parti de cette puissance de parallélisation... ou tout bêtement qu'il a identifié que le code d'origine était "sale", parce que ça aussi, hélas, ça existe!
Ce n'est pas parce que deux algorithmes donnant le même résultat ont des performances différentes tirent ou pas partie de la puissance réelle de nos machines. Si je vais au bout du vice: ta librairie A moncoeur bien conçue fera mieux qu'une librairie B en multicoeurs mal foutu.

Pour finir (et encore): le fait de multiplier les coeurs a pour avantage fondamental de permettre de paralléliser à mort les processus avec une latence extrêmement faible. Lorsqu'on n'avait qu'un coeur (ie les machines du style Atari/amiga et j'en passe... jusqu'aux premiers multicoeurs PIV et équivalents), paralléliser revenait en fait à coller des tâches avec des priorités distinctes dans une file d'attente, le tout nuisant naturellement aux performances. C'est un sujet ultra délicat car là je ne fais que caricaturer à mort. Pour avoir bossé sur un softphone (téléphone virtuel sur un PC), la parallélisation à l'époque forçait à prendre en compte le fait que toutes les machines n'avaient pas des coeurs supplémentaires, que l'empilement de tâches d'attente pouvait ralentir inutilement l'environnement, et que s'il y avait quoi que ce soit de gourmand en cycles machine on pouvait vite avoir des latences (sonnerie en retard, activation des fonctionnalités de téléphonie prenant du temps....)

 

[andre.gerald]

R ??
Pas compris @magellan ?

 

[svoglimacci]

R

C'est aussi ce que je pense !

 

[Storos]

R

Pas mieux! C'est à la fois concis et précis: c'est à ça qu'on reconnait les vrais pros…

 

[magellan]

@magellan
Mon fils a trouvé ta réponse sympa et utile !!
Donc merci pour lui

De rien, comme je l'ai déjà dit: tu as tous les éléments sur la toile (en tout cas bien des trucs). Tance le pour qu'il fasse en premier réflexe une recherche sur stackoverflow et developper mozilla pour voir si la librairie qui l'intrigue n'est pas déjà documentée, voire utilisée avec des exemples concrets.

Je n'ai rien inventé, j'exploite ce que les autres ont eu à découvrir avant moi.

 

[magellan]

Pas mieux! C'est à la fois concis et précis: c'est à ça qu'on reconnait les vrais pros…

Ton groin toi