totof2000 a écrit 1920 commentaires

Ah bon ? Je ne le savais pas … faut dire que je ne vois plus le temps passer … (j'ai pris un coup de vieux d'un coup). "Victime" d'Amazon ?

Je ne sais pas s'ils pourraient le commander, mais sur Paris il y a peut être https://www.cql.fr/libraire/le_monde_en_tique et si tu n'es pas sur Paris, peut-être qu'en les appelant tu pourrais te le faire envoyer ?

Sinon je suis allé voir chez Eyrolles, aparamment il n'y est pas.

https://www.nextinpact.com/article/68048/shelly-plug-s-prise-connectee-avec-mesure-consommation-presque-parfaite

personnellement, pour des copies d'arborescences, j'aurais tendance à plutôt utiliser rsync (surtout si la quantité de données à copier est importante). L'avantage : si pour une raison ou une autre la copie s'arrête en cours de route (coupure électrique par exemple), c'est plus facile à reprendre là ou on en était.

J'ai oublie ce lien : https://www.forth.com/resources/forth-programming-language/

est ce qu'il existait des "logiciels" écrits avant les années 80, dans les premiers appareils électroniques?

https://fr.m.wikipedia.org/wiki/Forth_(langage)

Jle cite :

1971 voit la première application d'envergure : Moore utilise Forth pour développer le logiciel de pilotage du radiotélescope de Kitt Peak (Arizona) sur deux mini-ordinateurs 16-bits. Il y est bientôt rejoint par Elizabeth Rather, qui devient le deuxième programmeur Forth. Par ses performances et sa souplesse d'emploi, l'application intéresse rapidement d'autres observatoires, et en 1976, Forth est adopté comme standard par l'Union internationale d'astronomie.

Après une première modernisation du logiciel de Kitt Peak en 1973, Moore et Rather fondent Forth, Inc., pour promouvoir le langage et ses applications. En 1976, une première version exécutable sur microprocesseurs 8-bits est disponible sous le nom de MicroFORTH.

https://www.forth.com/resources/forth-apps/

J'adore ce langage.

J'ai l'impression qu'il s'agit d'une histoire de gros sous entre deux entreprises qui cherchent à tirer la couverture à eux seuls. Est-ce que ça veut dire que lorsqu'on utilise une appli qui est présente dans l'&app store, chaque publicité vue est taxée de 30% par Apple ? Pourquoi ? Est-ce que l'affichage de pub fait appel à une infra Apple ?

D'autant plus que beaucoup d'imprimantes permettent de se passer de cette appli web d'administration ( peut-être plus difficile pour certaines imprimantes récentes pas cher, mais d'un autre côté, on a aussi la qualité qu'on paye).

elle doit être quelque part dans un des fichiers inclus à ton fichier source.

Justement, plus c'est cretin plus j'aime

Retour de congés
Jouer au lieu de bosser
Et on est virés

Cafard de rentrée
Petit jeu pour consoler
Je me fais moinsser

De plus ça permet d'implémenter des interpreteurs ASN.1 légers, qui ne doivent pas gérer les différentes interprétations possibles qui pourraient être une conséquence d'une souplesse syntaxique trop large.

Quelque part je me dis qu'ASN.1 est peut-être a voir comme le XML, ou comme le langage intermédiaire d'un compilateur : ce n'est pas parce que c'est du texte qu'il faut le générer manuellement : peut-être qu'un langage plus souple avec un ide adequat serait plus efficace ?

J'ai oublié d'insister sur ce point :

c'est pas souple

Je pense que c'est volontaire. Mettre trop de soulesse dans une spécification d'échange réseaux, c'est à mon avis se tirer une balle dans le pied, la porte ouverte à des ambigüités d'interprétation.

Je vois un peu ASN.1 comme la notation BNF pour décrire les langages de programmation.

LDAP, c'est un peu comme SNMP, c'est vieux, les syntaxes ASN.1 sont horribles, la doc est nulle, c'est pas souple…

On peut reprocher beaucoup de choses à ASN.1, mais :
- c'est du déclaratif
- beaucoup de langages savent le parser. Il y a même des parsers en ligne
- la spécification est suffisamment précise, et moins ambigüe qu'une spécification en yaml ou toml. Je peux peut-être me tromper mais seul le xml avec une DTD ou un schéma xml pourrait être une alternative fiable. Mais dans ce cas, il ne suffirait pas d'apprendre uniquement XML, mais la spécification du langage également (un peu comme le SVG pour le vectoriel). Mais en cherchant un peu, je suis tombé sur cet article : https://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf

Tout ça pour dire qu'il ne faut pas tout mélanger : le protocole, la spécification, l'implémentation et le stockage. Le truc c'est que j'ai l'iumpression qu'aujourd'hui ça n'intéresse plus grand monde de travailler sur ce genre de techno dans le libre, et que c'est surtout ça qui fait qu'Openldap ou ses alternatives sont toujours vieillottes.

Je considère en effet qu'utiliser deux formats d'archives différents, dont un peu fréquent avec peu de bindings dans les langages classiques, est un défaut.

Euh … c'est une question de point de vue. Debian était là bien avant tout ça non ? Du coup, ne serait-ce pas la faute des langages classiques qui n'implémentent pas le binding en question ?

Alors ca, permet moi d'en douter. Les mecs qui sont sur site sont ceux qui sont systématiquement en retard a la reunion, parce qu'il tape le bout de gras je sais pas ou.

Je ne comprend pas ce que tu veux dire. L'impolitesse n'a rien à voir avec l'absence ou la présence, et ce comportement, je l'ai vu pas mal de fois en télétravail avec des gens qui se connectaient en retard parce qu'ils étaient sur une autre réunion (qui parfois consistait à faire sortir pisser le chien).

Sans compter que l'attention des gens dans la salle est mauvaise, ils discutent entre eux, ils se cassent en plein milieu pour aller voir un gars, si ca dépasse de 2 min, la salle est reclamee par les suivants, etc..

Généralité exagérée. La encore, quand tu sais faire les choses il n'y a pas de problème. Il suffit que la réunion soit préparée, timeboxée et recadrée, avec un ordre du jour, et c'est beaucoup plus facile. Et encore une fois ce problème n'a rien à voir avec le télétravail ou le présentiel. J'ai vu nombre de réunions dans mes missions en télétravail pendant le covid ou la moitié des gens arrivaient en retard, soit parce que les gens n'attivaient pas à se connecter au pont téléphonique, soit parce que les gens avaient un problème de VPN, soit parce qu'ils étaient sur une autre réunion avant …

C'est quand meme pas facile dans un train bonde de sortir son PC et de coder avec. Désolé mais non, le transport ca reste une pure perte de temps.

Dans un train bondé tu peux au moins lire, ou regarder des vidéos. Apres j'évite d'aller bosser à des endroits comme à La Défense donc les transports bondés, je ne connais pas trop. J'ai toujours pu trouver un moyen de sortir le PC pour coder en général.

Encore un truc de l'ancien monde qui te demande du temps et de l'organisation, la ou aujourd'hui tu te fais un truc en 5 min a la maison.

Hein ? Le truc que tu fais en 5 mn … Je ne sais pas ce que tu teprépares en 5 mn. Un sandwich ? Ca te prend 5 mn de plus pour l'emballer. Perso je fais un peu plus élaboré, surtout depuis que j'ai un robot cuiseur. Le temps de préparation reste le même, etça prend 5 mn de plus pour le mettre en boite. Et encore, j'ai tendance à préparer des trucs en avance pour les mettre à congeler et les réchauffer plus tard, chez moi quand je suis en télétravail, ou au bureau quand je suis sur site donc ça ne change pas grand chose. Il faut juste le sac adéquat pour transporter le tout, c'est peut-être le seul point bloquant à mon avis.

l'asociabilité de la moitié des personnes qui ne mangent jamais avec personne, ni ne sorte boire un verre et ne prenne un café qu'à reculons ;

Si. Je crois que ca s'appelle la politesse ou un truc comme ca.

Non non. Rien à voir avec la politesse. Chacun est libre de faire ce qu'il veut. On peut refuser poliment de faire tout ce que tu dis.

Je vais essayer de répondre objectivement à tes arguments.

'impossibilité de faire une réunion autrement qu'en visioconf, car il n'y a jamais toutes les personnes sur le même site.

J'ai connu. Mais avoir des salles de réunion sur chaque site avec les gens dans chaque salle peut être une solution. Pas la panacée je l'accorde, mais ça peut être utile. L'avantage de ce genre de réunion c'est que les gens sont moins tentés de faire autre chose pendant qu'on discute de sujets importants.

l'openspace avec des gens qui parlent fort alors que tu es en conférence ;

Là je pense que c'est toi qui t'organise mal: Pourquoi tu ne fais pas ta conférence dans une salle de réunion ? Ca s'organise.

le collègue à côté qui est dans la même conférence ce qui donne un double son dans les oreilles ;

Idem : Pourquoi ne vous mettez vous pas dans une salle de réunion tous les deux ?

la bataille de température entre ceux qui veulent la clim à 17°C et ceux qui ouvrent la fenêtre par 40°C ;

C'est un des problèmes du présentiel dont je souffre le plus (je ne supporte pas la chaleur, et je suis mal autant l'été que l'hiver car l'hiver le chauffage a tendance à aller trop fort pour moi).

le café moins bon qu'à la maison ;

A chacune de mes missions on a réussi à s'organiser pour avoir au moins aussi bon

les heures perdues dans les transports ;

Ca dépend du trajet. J'ai eu des époques ou je passais plus d'une heure en transpports aller et plus d'une heure au retour, mais je profitais de ce temps pour faire des choses que je ne prenais pas forcément le temps de faire quand je ne prenais pas les transports. Entre autre lecture, apprendre d'autres langages de programmation … mais pour que ça se passe bien, il ne faut pas trop de changement dans le trajet sinon ça ne sert à rien.

le choix de manger soit dans des snacks pour obèses, soit dans des restos hors de prix ;

Ca dépend effectivement ou tu vas. Mais il reste toujours la possibilité de préparer sopn repas chez soi et de l'emmener (ce que j'ai fait à une époque). Aujourd'hui, avec les robots d'aide à la cuisine (qui sont devenus accessibles à tout le monde), c'est plus facile qu'avant.

la débilité de 99% des gens qui veut absolument des contacts physiques (serrage de mains, check, bises…) alors qu'on est encore en pleine pandémie ;

Ca, rien ne t'oblige à le faire.

l'asociabilité de la moitié des personnes qui ne mangent jamais avec personne, ni ne sorte boire un verre et ne prenne un café qu'à reculons ;

Ca on s'en fout. On parle boulot. Tant qu'ils sont là lorsqu'il faut qu'ils soient là, le reste c'est leur problème.

les problèmes de réseaux, car la DSI est moins compétente qu'un gérant de cybercafé amateur.

Bof … Les problèmes de réseau tu les rencontre aussi quand tu es au télétravail. Peut-être même plus que quand tu es en interne : problèmes de VPN, de lenteur parce que les infras ne sont pas prévues pour …

C'est le truc le plus moche qui existe en gestion de dépendances et de paquets. Je suis pas fan de python, beaucoup de monde le sait ici, et la gestion des dépendances est pour moi le "reflet" de l'état d'esprit du monde python.

Je ne dis pas que je n'ai jamais eu de problèmes avec ruby, mais je trouve que c'est beaucoup plus cohérent. Et même nodejs et npm me posent moins de souci.

Je pense que le meilleur moyen de gérer ce genre de souci avec Python, c'est de tout faire dans un conteneur. Et éviter Python comme langage de script secondaire. C'est certes un investissement en temps, mais une fois que c'est fait, on arrive à s'en sortir. Et l'avantage d'un conteneur, c'est que ton image, une fois en prod, tu la versionnes et la stocke dans un repo d'image. Et elle fonctionnera toujours. Si tu dois générer une image version N+1, et qu'il y a un problème, tu peux toujours revenir à la version N. Et avec un bon système de build (chaine de CI standardisée) tu masques une grande partie de la complexité aux devs.

Le problème que j'ai constaté avec le télétravail, c'est que ça ne favorise pas toujours l'esprit d'équipe. Il manque quelque chose.

Après, peut être qu'imposer 3 jours en permanence à tout le monde c'est un peu trop, mais d'un autre côté, laisser tout le monde tout le temps en TT, c'est peut-être tomber dans l'autre extrême.

Il serait peut-être plus judicieux de laisser les équipes s'autogérer, avec des périodes ou ils sont plus souvent en TT, et des périodes ou ils sont plus souvent en présentiel, en fonction des projets, et n'intervenir que lorsque les équipes n'arrivent plus à atteindre leurs objectifs ?

Mais au fina, cette solution n'est pas forcément non plus la panacée car elle risque de créer des tensions et jalousies entre équipes.

Dans tous les cas, juger juste sur la base d'un article, sans savoir ce qui se passe à l'intérieur de l'entreprise est un peu facile je trouve.

j'apprends pas à pas!

C'est un plaisir que de t'aider à apprendre. Je t'encourage à persévérer.

Tu es sûr de ne pas trouvert un fichier .deb plutôt qu'un .tgz ?

Avec un fichier .deb tu aurais juste à exécuter la commande sudo apt-get install ou l'ouvrir avec le gestionnaire d'application de ta distribution.

sur cette page :

http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=FR&CN2=&DSCMI=137793&DSCCHK=6ad0441b6800826481a6cab0848927ad8b12c699

choisir epson-inkjet-printer-escpr_1.7.21-1lsb3.2_amd64.deb pour un OS 64 bits de type debian/ubuntu/mint