Marotte ⛧ a écrit 8696 commentaires

Sauf qu'au dernier moment, les proches de ses enfants lui ont fait part qu'ils voulaient conserver ces profils pour leur permettre un hommage, une présence, un souvenir par les outils numériques.

De ce que j’ai vu, pour Facebook, il y a de ça pas mal de temps, plusieurs années, c’est qu’on peut soi-même, sur le même principe qu’un testament, choisir ce que Facebook devra faire des données en cas de disparition définitive de l’abonné. Ce dernier peut notamment désigner un (ou plusieurs ?) comptes de confiance qui pourront continuer à gérer ses données, et de manière prévue pour ça. Pas simplement comme si le futur mort confiait ses identifiants à une autre personne avant son grand saut dans l’inconnu néant originel.

Je ne sais plus si c’est déjà arrivé où si c’est pas loin de se réaliser mais il y a eu (ou il y aura bientôt) un moment où le nombre de comptes appartenant à des personnes décédées dépasse le nombre de comptes de gens vivants… Sur FB, mais probablement ailleurs aussi.

Les « nouvelles technologies » commencent à ne plus être si nouvelles que ça !

Je suis d’accord avec toi. Cependant, si quelqu’un est en mesure d’administrer des pages perso par FTP il est capable d’avoir un job en automatique qui fait ça tous les mois depuis sa machine avec laquelle il se connecte à Internet très probablement plus d’une fois par mois. Ainsi pas de risque à oublier pendant trois mois. Ceci dit pour le cas du coma de plusieurs mois, là pas trop de solution simple.

Mais, « à hébergement donné on ne regarde pas les limitations » :)

Pour la petite histoire : j’ai fait "j’ai oublié mon mot de passe" pour mon espace Free mais je pense que je n’ai plus le compte mail associé visiblement. Fallait tenter !

tous les six mois

Six mois après la release pour être plus exact.

En gros : dès que le freeze est commencé, il est trop tard pour avoir des demandes

Debian sort quand elle est prête et c’est parfait. Mais dans mon souvenir il avait été décidé que les freezes aurait toujours lieu à une date prévue, tous les six mois je crois, précisément pour éviter les déceptions liées à la problématique que tu évoques. Ce n’est plus d’actualité ?

J’ai été longtemps utilisateur de unstable. Depuis quelque années j’apprécie d’être sous stable. Sid fonctionne bien globalement, certes, mais il arrive quand même parfois des problèmes assez cocasses, et la quantité et fréquence de mises à jour, si ça peut parfois l’être à un moment donné… n’est pas vraiment un kif de ouf pour quiconque.

Je suis sur la 12 actuellement, absolument satisfait, je ne me jetterai pas sur la 13, elle arrivera quand elle arrivera.

Au fil des années j’ai pris l’habitude de compiler régulièrement les quelques logiciels dont je souhaite avoir la dernière version. C’est sûr que c’est pas une solution qu’on peu proposer à une personne désireuse d’utiliser Linux tout en souhaitant éviter au possible de mettre les mains sous le capot. Mais aujourd’hui il y a les backports, déjà, ça répond à quelques besoins, et sinon, les solutions type Flatpack etc… que je n’ai jamais utilisées, mais qui j’imagine réponde au besoin d’avoir des versions très à jour de tel ou tel logiciel, font du relatif « retard » de Debian stable, comparé à Fedora par exemple, un problème nettement moins crucial que par le passé.

Demande de récupération de l'intégralité des données associées, sur les dizaines de services jamais utilisés avec ce compte (vu que ceux utilisés n'existent plus, on ne récupère rien, pas comme les JSON vides des services encore existants). 8j plus tard on peut détruire le compte, petit coup de clavier sec derrière la tête. Fin.

J’avais demandé à ce qu’on supprime le compte précédent (et ses données) que j’avais créé ici-même, et perdu l’accès du fait de ne plus l’utiliser et que l’email d’inscription, celle de mon FAI de l’époque, soit supprimé, et vous aviez refusé.

Pas que ça m’est dérangé plus que ça à l’époque mais aujourd’hui j’ai saisi l’intérêt.
De conserver le contenu tout simplement, aussi futile qu’il soit.

Mais de plus, il m’est arrivé de retourner voir ces quelques pages d’antan. Elles ont cet intérêt remarquable aujourd’hui d’être un moyen de me prévenir de tout re-façonnage mental excessif de mon « moi » :)

persos free.fr en ligne depuis plus de 20 ans

La vache… Étrangement je me souviens du nom du compte que j’avais créé, alors suite à la lecture de ton commentaire je viens de vérifier : ça répond toujours, c’est une page blanche mais le titre de la page montre que c’est bien à moi. Je ne sais plus si j’avais tout viré ou bien laissé des trucs accessibles mais sans index. En tous cas ça m’était totalement sorti de la tête.

J’aurais pas cru que c’était encore en vie ce truc là. Je n’ai plus touché à ce truc depuis au moins quinze ans, c’est manifestement vide de tout contenu qui serait même un poil utile, et objectivement abandonné. Je serais Free je me serais dégagé depuis belle lurette :) ne serait-ce que pour récupérer le nom d’utilisateur.

Mais maintenant « grâce » à toi je sens que je vais passez un temps bien trop long à essayer de voir si je peux récupérer les accès (au FTP).

Cela dit je trouve que c’est tout à leur honneur, à Free, de ne pas uni-latéralement mettre fin à ce service, gratuit et sans engagement aucun (pas lié à un forfait quelconque).

Tu as raison, j’ai confondu « rémunérée » et « à visée rémunératrice potentielle » :)

En tous cas en dehors de ce cas que tu fais bien de citer, ça me semblerait abusif de qualifier de « professionnel » toute activité bénévole, quand bien même appartiendrait-elle au même domaine que le poste rémunéré objet du contrat. Mais c’est sûr que ça a un fort potentiel de bataille juridique ce type de clause. Peut-être pas abusive, mais « abusée » je trouve. Comme déjà dit, sorti de la probité minimum imposant de ne pas œuvrer à concurrencer son employeur pendant son temps dit « libre », et encore que ça puisse se discuter, ça tombe sous le sens. Pourquoi pas une clause : « Je m’engage à ne pas dérober à mon employeur l’outil de travail qu’il me confie ni mettre le feu aux locaux hébergeant l’entreprise, ou tous locaux quels qu’il soit pendant mon temps de travail. »

Ça me fait penser aux annonces d’emplois qui indiquent : « sérieux exigé » ou « les compétences pour le poste sont indispensables » ou autre formulation du même genre. Comme si un candidat pouvait espérer un poste dans une entreprise dans laquelle on se foutrait de tout et qu’il pourrait mal faire, ou ce serait acceptable qu’il ne fasse rien du tout. Tout aussi peu probable, un employeur qui pouvait tolérer de recruter un boulet incapable…

J’ai toujours trouvé ça ahurissant. Faut croire que la quantité de chose que l’on peut faire (nous humains en général) par pure convention sociale sans réfléchir une seconde à la chose en question est assez conséquente. Et surtout, accepter, qu’« à l’évidence » … on ne peut pas soi-même s’exempter totalement, voire même pas sensiblement… de cette nature, est assez fascinant. Fascinant comme regarder un sol situé cinq-cents mètres plus bas en se tenant au bord d’un perchoir non muni d’une barrière solide à même de convaincre notre cerveau que la probabilité de chute est négligeable ! :)

Et ça suffira à tout le monde.

Tu verras dans cinq ans !

Je connaissais l’existence de ce débat mais j’ai découvert (enfin si j’ai compris inversement aussi bien que j’ai lu de travers !) que Hurd n’était à ce jour pas le plus prometteur des micro-kernels pour les spécialistes, car pas assez micro et pas aussi performant qu’on pourrait le souhaiter (et ce qui ne serait pas un problème de Mach, mais de Hurd en particulier ?). En tous cas c’est intéressant comme morceau d’histoire pour avoir une idée du chemin qu’a emprunté Linux au cours de ce presque dernier quart de siècle, pour être ce qu’il est aujourd’hui. À savoir, sans tentative de de troll d’aucune sorte de ma part, le noyau *NIX le plus florissant de tous les temps, même si des noyaux BSD ont eux (lui ?) aussi quelques réussites notables, mais fatalement moins visibles du fait de leur licence je pense.

Je me suis dit que de nombreux utilisateurs ou contributeur aux LL et à Linux parmi les moins dégarnis pouvaient probablement ne jamais avoir entendu parler de ce débat, quasi préhistorique, d’où ce post.

Sur l’artificialisation des sols : une grande partie sont des mine à ciel ouvert mais ce n’est pas toute. Je ne crois pas qu’on puisse, mais peut-être ai-je tort (?), considérer qu’une mine souterraine artificialise les sols est je crois plus faible. La production de biocarburant qui accaparerait des hectares de terres cultivables me semble plus dangereuse.

Aucune solution actuelle n'est vraiment acceptable sur le long terme.

Donc en fait, on devrait se résoudre à principal du changement climatique (si on ne compte pas la décroissance et la sobriété?

Je me demande également c’est que pourrait-être une « activité professionnelle non rémunérée pour son propre compte »…

Je me demande également c’est que pourrait-être une « activité professionnelle non rémunérée pour son propre compte »…

Tu utilises CoreOS/ContainerOS sur ta machine personnelle, ou ton poste de travail professionnel si tu es informaticien ?

Même pour les serveurs, la conteneurisation vient avec sa problématique, tout comme la virtualisation qui en possède aussi, comme elle a des avantages.

La conteneurisation est une très bonne solution aux déploiements complexes, distribués, et avec un fort besoin de changement de mise à l’échelle rapide.

C’est typiquement le cas d’un fournisseur de solution SaaS. Pas que, mais c’est quand même le cas le plus évident et sur lequel je pense que personne ne remet en cause la supériorité de la conteneurisation pour ça.

Si tu as besoin d’un cluster on-pemises distribué sur deux ou trois sites comme backend pour du big-data, avec la possibilité de disposer de hardware dédié, alors y ajouter une couche de conteneurisation « parce que c’est possible et que c’est l’avenir » me semble pas judicieux.

Je serais dans ce cas très curieux d’entendre les arguments en faveur de ce que je pense être un mauvais choix d’architecture.

Les aficionados des la conteneurisation te diront peut-être qu’il faut utiliser Kubernetes, Rancher (et sûrement d’autres trucs additionnels) et écrire/utiliser un opérateur qui se chargera de faire tout cela à ta place ensuite. Puis développer sous Eclipse Che, c’est beaucoup mieux !

Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev …

Moi aussi j’ai un peu de mal avec cette hype autour de la conteneurisation. C’est une technologie très intéressante, voire indispensable aujourd’hui, pour gérer les déploiements complexes sur des systèmes d’information immenses et protéiformes, ou pour la prod’ éventuellement comme tu le dis, mais sur de petits SI avec une topologie relativement simple, et à fortiori en tant que développeur « isolé », c’est la définition même d’overkill je trouve.

Quand on ajoute à ça la continuelle métamorphose de l’écosystème, où tous les six mois un nouveau produit va enfin résoudre les problèmes, ce qu’il fait généralement, mais que six mois plus tard un nouveau produit est présenté comme tel, pareillement, ça donne pas une confiance terrible dans la viabilité de l’approche, et surtout pas en tant que solution universelle et évolution incontournable.

Je ne comprends pas trop ce que tu veux dire, mais les environnements virtuels permettent justement de résoudre ce problème.

Je m’interroge sur la question de savoir si de cette solution (les venv) au problème (des incompatibilités nombreuses) ne découlerait pas un autre problème : celui de la redondance et de la complexité globale.

heureusement car bon nombre se scripts d'initialisation dont en Bash dans l'os

De moins en moins grâce (ou à cause selon le point de vue) à systemd.

Tu prêches un convaincu.

Je pense aussi aux mots clés et built-in : wait, trap, kill voire coproc.

Le multiprocessing en Python perso je trouve ça lourdingue à écrire.

offre la possibilité par exemple d’utiliser le noyau de FreeBSD

Ce qu’offre aussi bien évidemment le système FreeBSD lui-même (je préfère préciser).

C’était plus de l’ordre de la boutade que du troll mais oui, je réalise bien que ce n’est pas un propos sérieux. Les propos sérieux ne sont pas ma spécialité, j’y très recours très rarement ;).

Je disais « de l’Univers » car Debian ne se veut pas une « simple » distribution GNN/Linux, mais un « OS universel », qui vise à faire fonctionner TOUT les ordinateurs, offre la possibilité par exemple d’utiliser le noyau de FreeBSD, et développe même, avec le FSF, un noyau (basé sur un micro noyau et donc, sur le papier, censé être mieux que Linux). C’est à ma connaissance, en tant que distribution GNU/Linux celle qui supporte le plus d’architectures matérielle.

Le noyau Linux est d’ailleurs lui-même assez « universel », étant donné le nombre d’architectures et de matériel qu’il supporte (du gadget connecté au super-calculateur…), à ma connaissance (relativement limitée), aucun autre noyaux type *NIX commercial n’était jamais arrivé à ça.

Ils disent aussi que les dauphins se sont mieux débrouillés que nous quand ils leur ont passé le sonar, et que s'ils ont besoin d'un OS un jour, c'est à eux qu'ils le passeront. Ou aux manchots, bien sûr.

si un interfaçage direct entre cerveau et machine est disponible je suis d’accord qu’on le réserve en priorité aux dauphins ! Sans aucun doute. ^^

Commentaire supprimé

environnement virtuel dédié précisément à cette application.

Un environnement par appli ça veut bien dire que l’on peut se retrouver avec appliA qui nécessite bibtruc.≥ X.Y.Z et appli2 qui nécessite bibtruc =X.Y.U ?

Ce qui aura une fâcheuse tendance à l’effet boule-de-neige, avec les dépendances de dépendances, et qu’il faut donc avoir peu d’applis en cour de développement ou bien beaucoup d’espace disque à disposition ? Pas simple à gérer, sans parler de l’effort intellectuel nécessaire quand on se retrouve à devoir travailler en parallèle avec deux versions d’une lib qui sont « un peu différente » ?

J’ai l’impression que les lib externes, il faut vraiment réfléchir à deux fois, en Python comme pour tout langage, et que « réinventer la roue », ou internaliser le morceau de code de la dite lib au sein même de son appli, vaut parfois mieux que prendre une lib pas hyper stabilisée dont on va utiliser p-e 10%, non ?

On peut à mon avis le qualifier de langage de programmation en bon est dû forme du fait qu’il soit « Turing-complet ». Ceci dit le Brainfuck l’est également, ce dernier est d’ailleurs le plus dépouillé que l’on puisse faire comme langage Turing-complet à ma connaissance (et c’est très beau, àmha ^^).

Mais un shell est conçu, et de plus configuré par défaut, pour servir d’interface entre l’utilisateur et le système, pour une utilisation « interactive ». Pour prendre un des exemples les plus parlant : en Python, Perl ou d’autres langages interprétés, une erreur de syntaxe entraîne la fin de l’exécution de l’interpréteur, il « n’ira pas plus loin », alors qu’en Bash (et autres), à moins de lui spécifier de s’arrêter sur tout code d’erreur (via set -e), et donc pas uniquement les erreurs de syntaxe… il continuera, en passant à la commande suivante. C’est compréhensible : si une erreur de syntaxe stoppait ton shell, par exemple que tu te trompais et essayais d’exécuter une commande qui n’existe pas, et que tu devais alors de re-logger au système à chaque fois, tu deviendrais fou.

Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un import os histoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc… tu te rendras vite compte que ce n’est pas fait pour.

Entendons nous bien, je ne veux décourager personne d’écrire des programmes en shell, c’est le langage que j’utilise moi-même le plus, mais ce que je souhaite faire passer comme message, c’est que sans prendre conscience de cela, je ne crois pas qu’on puisse avoir une bonne expérience avec Bash. On ne peut pas comparer sur un pied d’égalité un shell d’un côté, et de l’autre un langage de programmation conçu comme tel « dès le départ ».

Certes il a un rôle particulier mais n'est-ce pas le cas de tout les langages?

Sans aller jusqu’au Brainfuck, qui est d’abord un jeu et clairement pas un outil qui puisse rendre le moindre service en dehors de l’exercice intellectuel, oui, des langages il en existe de toute sorte (on peut prendre CommonLisp ou Erlang par exemple, relativement exotiques comparé aux langages les plus répandus), peu se ressemblent vraiement. Mais « shell interactif » c’est vraiment un rôle (et pas un paradigme de programmation…), assez à part. Selon moi, on est pas obligé de voir les choses de la même manière.

Pour avoir eu à migrer une appli toute simple en Python (écrite par quelqu’un d’autre), simplement de RHEL7 vers RHEL8, je vois ce que tu veux dire. Le fait qu’il m’ait fallu, comme l’explique Benoît Sibaud, recourir à pip freeze pour installer très précisément la version X.Y.Z des quatre ou cinq bibliothèques utilisées (de mémoire stomp, request, … me souviens plus des autres) ça m’a surpris.

Je suis peut-être un vieux con qui n’a rien compris à la vie, ce qui me va parfaitement jusqu’à maintenant, mais lorsqu’il s’agit d’« appli » destinée à répondre à des problématiques de devops, qui ne sont ni énormes ni potentiellement destiné à devoir « passer à l’échelle » comme on dit, je n’ai jamais rien trouvé de plus satisfaisant que Bash. Certes c’est absolument incommode à écrire, bourré de subtiles pièges plus surprenant les uns que les autres, mais une fois que ça fonctionne ça ne va pas casser aussi facilement, simplement parce qu’on passe à une version majeur supérieure du système. La plupart du temps ça fonctionne avec zéro modification. Au pire, il faut voir que Bash 5 (la version actuelle) propose des « mode de compatibilité », pour faire tourner le script écrit il y a 15 (?) ans pour Bash 3.2 et qui tourne depuis, que personne ne veut, ne peut ou n’a les moyens de ré-écrire entièrement, et que les utilisateurs finaux considèrent comme crucial de ne surtout pas perturber.

Ce serait totalement idiot de développer des applications complexes, pour lesquelles le paradigme objet, ainsi que la cohérence et les performances brutes de l’interpréteur sont pratiquement indispensables, en Bash (ou un autre shell), mais ça me semble tout aussi idiot de se priver de l’intégration d’un shell avec le système, qui rend de fait le concept de « déploiement » anecdotique, offert par le shell en la matière.

Attention je n'ai pas dit que l'on ne pouvait pas utiliser pip sous Debian. Juste qu'il faut passer par un environnement virtuel.

OK je vois. Oui le recours à un “Virtual env” pour utiliser Python c’est devenu indispensable. Il faut s’y habituer. C’était une vrai question, je me demandais si tu ne faisais pas référence au fait que pip ne permettait plus l’utilisation de sa fonctionnalité de recherche des dépendances (peut-être est-ce de nouveau possible ? Ça fait un moment que je n’ai pas fait de Python). Pour Bash la recherche, et l’installation, de dépendances ça passe par apt ou dnf, what else !? ^^

Pour résumer le fond de ma pensée : Python est un outil formidable, mais il ne remplace pas le shell, ce sont vraiment deux outils différents, àmha.

Ceci dit pour Python comme pour Bash, le soin à apporter à la sélection des dépendances qu’on va utiliser (leur pérennité, stabilité, notoriété) ne doit pas être négligée.

Faudrait lui montrer que sous Linux elle peut utiliser des smileys et des symboles divers pour les noms de fichiers. ^^

$ ls plop*
'plop ✔'

on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.

Je ne savais pas et je suis très étonné, pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien).

Gardons à l’esprit que Bash est d’abord un shell, et non un langage de programmation à proprement parler bien que ce soit le mailleur langage pour programmer, si on veut bien se le dire.

Je plaide coupable. Ton commentaire est très juste par ailleurs.