Yves Martin a écrit 98 commentaires

Très intéressant pour des déploiements Ansible.

Par contre, pour des besoins plus variés, mon équipe a choisi et déployer Backstage https://backstage.io/ en y intégrant nos processus, avec formulaire de soumission de demandes de changement, déclenchement de workflows, pour l'instant avec du Terraform ciblant GitHub, Azure, AWS…

Je recommande KeypassDX sur Android https://f-droid.org/fr/packages/com.kunzisoft.keepass.libre/, très pratique avec son clavier intégré pour remplir les formulaires.
En synchronisant la base de données par WebDAV; depuis un NextCloud mais finalement tout "drive" devrait faire l'affaire, mes mots de passe (et les codes OTP) sont accessibles partout.

De même, sauf que je venais juste de commencer à utiliser Gandi, donc une seule adresse email sur mon domaine et pour l'instant, c'est encore gratuit chez Infomaniak.

L'intérêt que pourrait présenter Graal VM en compilation native pour ce type de code est le temps de démarrage du processus et l'économie du JIT lors des premières exécutions qui sont donc immédiatement optimales.
Et aussi l'empreinte mémoire devrait être faible qu'avec une exécution en JVM/Hotspot car le tas/heap n'est pas la seule zone mémoire allouée par la JVM, il faut y regarder plus en détail et vérifier les allocations natives pour le metaspace (.class, code produit par le jit, zone de traitement du gc…)

Visiblement personne n'a tilté sur la typo

D'après ce documentaire, la présentation de Jodorowsky a en fait amené l'adaptation de Lynch.

J'ai tilté concernant les "Corrigés en Matlab".
Du coup, je fais la publicité pour GNU Octave: https://www.gnu.org/software/octave/

Pourquoi pas, mais je trouve que c'est encore trop de travail.

Pour un système de billeterie avec point de vente, on codait les services REST en Java et le client en JS/Angular.

Pour une communication supplémentaire (dans le sens, introduite après architecture) entre l'interface "vendeur" et une tablette d'affichage et de saisie destinée au "client", on a vite fait le choix du WebSocket avec un protocole d'échange de messages texte très simple.

On avait déjà ActiveMQ pour assurer du traitement asynchrone en JMS, alors ajouter le support WebSocket s'est limité à créer une queue par POS dans ActiveMQ… le plus long a été de passer en SSL à travers un reverse-proxy. Quantité de code spécifique ajouté au projet, proche de zéro. On a juste sélectionné un client WebSocket en JS.

Évidemment ce n'est pas comparable en terme de performance, tout dépend des objectifs - mais je pense que la conclusion est la même: répondre le plus rapidement possible au besoin avec les compétences de l'équipe.

Et je pense malheureusement que le C++ n'offre pas le cadre initial qui permet de le faire.

Dans ma boîte, on fait essentiellement du Java et du C# mais l'incontournable JS et son écosystème "mouvant" nous pose un problème d'efficacité, de rentabilité et de maintenance à long terme - dans notre contexte de développement sur-mesure (durée de vie > 5 ans), il est difficile de financer à nouveau une "mise à jour" (par exemple après 2 ans) de frontend JS (en général de complexité moyenne à élevée) quasiment au même prix que sa conception initiale… Bref si possible, on préfère fournir une application de bureau en JavaFX ou WPF.

Et ça l'est encore plus "dégueulasse" aujourd'hui avec le millefeuille de compatibilité empilé dans les puces "amd64" (c'est quand même AMD qui l'a inventé…)
Même si c'est aujourd'hui codé en microcode sur du hardware simplifié (à quel point ? peut-on parler d'un quasi RISC ?), l'interface assembleur proposée au dévelopeur reste des plus désespérantes. Bon tout le monde s'en fout, on n'écrit plus en langage d'assemblage et on n'assemble plus à la main non plus !

Hum, je pensais que c'était du Z80 dans les Sega. D'après wikipedia, il y a bien eu les deux 68000 et Z80 !
On est en train de documenter l'archéologie des temps modernes, là, non ?

"tu es con, ne pars pas dans une impasse, d'ici 5-10 ans, les machines se programmeront elles-même"

Alors celle-là, c'est une responsable d'orientation en lycée qui me l'a sorti en 1982… comme quoi il y eu du progrès ;)

J'ai l'étrange sentiment que les jeunes "utilisent" sans s'intéresser à ce qui se trouve à l'intérieur du capot - d'ailleurs de nos jours, c'est même devenu plus difficile avec la "mécanique" automobile qu'avec l'informatique libre ! Ce qui semble se confirmer par le désintérêt annoncé pour les filières scientifiques (à l'exception de bio/pharma peut-être…)

Le Motorola 6809 qui équipait mon magnifique TO8D en 1987 (attention 650 Ko de RAM quand un Amstrad CPC n'en avait que 128 !)
De nombreuses écoles françaises étaient équipées en TO7, TO8, TO8D, T09 avec leur fameux crayon optique !

Je n'aurai pas du voter pour la famille équivalente des 680xx car il y a bien un zéro de moins (et plusieurs bits de registres aussi) et cela aurait éviter les commentaires concernant la "classe moyenne / haute".

On peut se réjouir que l'informatique d'aujourd'hui démocratise l'accès à la connaissance (ou à la débilité, c'est au choix…) indépendamment de ses moyens (OK faut mettre 20 euros par mois dans son ADSL)

Pfff ça ne nous rajeunit pas un sondage pareil. J'ai fait du langage d'assemblage sur les 6809, Z80, Pentium, HP Saturn… et maintenant j'aimerai bien me mettre à l'ARM (téléphone, smarttv samsung, synology…)

Y'a pas à dire l'assembleur, ça forge le caractère… et surtout la patience. Nostalgie.

Il existe (ou a existé) "Allogène" http://www.epi.asso.fr/fic_pdf/dossiers/d14p101.pdf
dont on ne trouve pas grandes traces…

Si les auteurs pouvaient le publier, ce serait une bonne base plus solide plutôt que de reprendre de zéro. Même si il est certain que le code doit être modernisé pour les plate-formes modernes.

C'est avec ce genre de chiffres qu'il y a trois ans, on développait un accès "mobile" pour un service uniquement pour iOS, sous prétexte que les ventes mensuelles étaient les plus importantes… ignorant ainsi tout "le parc déployé" (à l'époque JavaME plus répandu et Android commençant)

Comme si les utilisateurs changeaient de téléphone tous les 6 mois… Bref, ce qu'il faudrait, ce sont des chiffres des téléphones encore en utilisation, et c'est probablement plus difficile à obtenir que pour des navigateurs web.

Et je dirai même heureusement que la communauté a fait le forcing en janvier/février pour monter une infrastructure complète afin d'assurer la survie des Maemo N900 et MeeGo N9 avant ce rachat on ne peut plus prévisible !

Je me mets aussi à sa place, enfin façon de parler… Entre la motivation de participer à un projet passionnant et la "vraie vie" (hein, la famille, les factures à payer…), la moindre des choses que l'on peut attendre c'est de la reconnaissance.

Alors pour tous ceux qui comme moi utilise son dépôt… la meilleure façon de le remercier est de cliquer sur "Donate" http://deb-multimedia.org/donate pour au moins financer sa facture d'hébergement (voir les graphes de bande passante).

D'accord.

Du coup j'ai cherché si un anti-virus sous Linux existait pour adresser certaines menaces en espace utilisateur comme un keylogger que tu mentionne. Rien de bien concluant, à part le vieux message rassurant "pas besoin d'anti-virus" sous Linux.

Je me demande si je ne vais pas faire tourner mon navigateur en nobody dans un chroot ou encore dans une VM… La paranoïa me guette.

-> []

Une applet Java "simple" s'exécute dans un contexte de sécurité très restreint et n'est en mesure d'utiliser que le CPU, la RAM (jusqu'à une certaine limite), afficher son interface, recevoir les événements clavier/souris et communiquer en http/s avec son serveur d'origine - celui depuis lequel l'applet a été téléchargée.

Pour faire plus, il faut signer l'applet et de fournir un fichier de permissions. L'utilisateur se voit alors demander s'il fait confiance à l'entité à l'origine de la signature - bien sûr s'offre à lui le choix "oui ou non" - mais sur quoi le cerveau lambda va-t-il cliquer par défaut sans même lire ?

L'exploit dont on parle permet de court-circuiter cette contrainte de signature et l'applet s'exécute alors sans SecurityManager comme s'il s'agissait d'une application Java "de bureau" avec l'accès à toutes les ressources: systèmes de fichiers, réseau, possibilité d'exécuter du code natif… Mais cette exécution reste sous l'identité de l'utilisateur qui exécutait le navigateur et la JVM. Difficile donc de faire le rapprochement avec les setuid/setgid qui permettent de passer root.

Voilà, donc l'exploit peut servir de porte d'entrée pour un vers, un virus ou un rootkit - qui devra obligatoirement profiter d'une autre faille au niveau du système d'exploitation pour élever son niveau de privilège du "simple utilisateur" qui tournait le navigateur vers "administrateur".

Bien sûr, désinstaller Java est l'option idéale pour ceux: dont le système n'est pas à jour, qui se loggue en root pour naviguer sur internet, qui ont une règle sudo ALL=(ALL) NOPASSWD, mais à mon avis ça ne les protège pas plus outre mesure.

Sinon ironie à part, mon opinion est clairement qu'un utilisateur Linux dont le poste est à jour et qui n'a pas tout le temps son accès sudo autorisé (attention à l'expiration du mot de passe !) n'a pas grand chose à craindre de ce genre d'exploit sauf peut-être si l'attaquant code un effacement récursif complet du répertoire home… mais bon, les backups sont là pour survivre à ce genre d'épreuves qui forgent le caractère.

J'utilise Getting Things GNOME mais entre mon poste au bureau, mon laptop perso et mon terminal mobile (N900), la synchro manuelle de mes tâches est vraiment pénible.
Passer par Remember The Milk n'arrange rien, la synchro n'étant que partielle.

J'ai donc fait le tour des applications web que je pourrai héberger sur Free.fr (PHP/MySQL donc) dans le but de l'adapter à mes besoins. J'ai choisi GTD-PHP (en comparant à TaskFreak) car son modèle est très proche de GTG: tags et sous-tâches.

Maintenant je dois réaliser une API JSON proche de celle fournie par RTM pour facilier l'adaptation des applications mobiles existantes et la synchro depuis GTG. Des volontaires pour m'accompagner ?

Il me semble que l'interface Hildon du N900/Maemo (à base de GTK+) est libre http://maemo.gitorious.org/hildon et apparemment disponible sur Ubuntu.

À ma connaissance la seule partie non libre du N900 est le code de gestion de la puce GSM pour les communications téléphonique, 3G et SMS...

Le fait que les binaires WebOS soient compatibles sur N900 reposent sur deux choses: la standardisation poussée de l'architecture ARM qui impose les mécanismes de passage de paramètres, la proximité des versions de Linux (appels systèmes), la proximité de la version de la glibc et autres bibliothèques liées dynamiquement.

Au contraire, Google a commencé Android en décidant de faire du Linux mais de l'Unix... Les exécutables et les bibliothèques ne sont pas liées dynamiquement par le "loader" (classique ld-linux et .so) mais statiquement à la compilation à partir d'une table des symboles et de leur emplacement en mémoire.

À ce niveau, ce n'est pas de la pédagogie pour une meilleure productivité mais de l'archéologie ;)

Le logiciel libre n'est pas suffisant mais au moins nécessaire (quelque soit la solution retenue) !

Les commentaires abordent beaucoup le mode de scrutin à un niveau presque philosophique.

Mais sans vouloir révolutionner le scrutin, l'introduction du vote électronique en simplifiant la participation (par internet ou depuis un terminal mobile) pourrait limiter l'abstention (OK dans ce cas, on oublie le recomptage).
Ou bien est-ce un rêve idéaliste ?

Euh, non je ne l'oublie pas. On peut aussi citer "screen" qui apporte bien plus que "nohup".
Mais comme ces utilitaires très pratiques ne sont pas fournis par le Shell...

Prescription pour ce diagnostic: "man bash" ou "man zsh" à haute dose pendant 1 heure. Désolé il n'y a pas encore de générique (man shell) mais de toute façon, c'est gratuit.

Bien sûr que non, ce n'est pas une maladie, c'est un art de vivre !
[J'ai entendu ça appliqué à n'importe quelle drogue licite ou non]
Mais attention à la dépendance induite qui se manifeste au moindre sevrage.