Franck Routier a écrit 276 commentaires

  • # ERP intéressant

    Posté par  (Mastodon) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 6. Dernière modification le 21 avril 2021 à 08:44.

    Je ne connaissais pas OpenConcerto. A première vue, il semble complet dans les domaines qu'il couvre : pas de GPAO, mais les autres domaines (finances, gestion commerciales, …) sont couverts, y compris la paie et la gestion de projet.

    L'ensemble à l'air solide. Le modèle économique est 100% conforme à l'esprit du Logiciel Libre, on paie le support, ou l'hébergement Cloud si on en a besoin.

    Par contre le look est clairement marqué années 2000 (voire 90), c'est un peu dommage, mais pas rédhibitoire pour un logiciel de gestion.

    A tester !

  • [^] # Re: Debian

    Posté par  (Mastodon) . En réponse à la dépêche Mise à niveau : LinuxMint vous notifie. Évalué à 2.

    Pour ma part je partage le sentiment de @monseigneur… Ce comportement m'a piégé plus d'une fois, car la mise est jour est programmée au prochain démarrage, au moment où j'allume mon ordi, donc parce que j'en ai besoin.

    Quant aux arguments sur les mises à jour à froid, à cause des risques d'une mise à jour à chaud… en 25 ans d'utilisation de Linux, ça ne m'est jamais arrivé qu'une mise à jour échoue pour cette raison. Pas une fois.

    Bref, je pense aussi que cette case à cocher est un héritage du pire de Windows (j'ai connu des demi-journées entières de travail perdues en entreprise car Windows (7) avait décidé de se mettre à jour, pile à moment où il ne fallait pas.

  • # VSCodium

    Posté par  (Mastodon) . En réponse à la dépêche Revue de presse — décembre 2020. Évalué à 2.

    Cet article sur VSCode / VSCodium est tombé à point : je venais d'installer la version Microsoft du .deb, car ça semble être l'environnement le mieux adapté à du développement en Vue.js…

    Bien sûr, après avoir ajouté à mon apt list un dépôt de M$, je n'ai pas dormi :-) Ca me permet donc de passer à la version libre VSCodium, sans la télémétrie M$.

    Par ailleurs, si quelqu'un connaît des alternatives pour le développement en Vue.js (v3 si possible), je suis preneur :-)

  • [^] # Re: clé

    Posté par  (Mastodon) . En réponse à la dépêche À la découverte de l’écosystème Mooltipass. Évalué à 5. Dernière modification le 03 août 2020 à 13:12.

    Je partage un peu cette interrogation: quels avantages / inconvénients par rapport à une carte OpenPGP comme la Yubikey, combinée avec par exemple le logiciel pass (https://www.passwordstore.org/) ?

    A priori:

    1) avantages :

    • l'appareil contient la base de données. Pas besoin de la dupliquer d'un appareil à l'autre ou de la rendre accessible (avec pass+yubikey, il faut passer par un dépôt git ou copier les fichiers)
    • la saisie directe sur l'appareil évite de mettre en péril son code PIN si le système utilisé n'est pas sûr

    2) inconvénients :

    • l'alimentation nécessaire pour l'appareil est plus importante qu'une Yubikey. Cela interdit a priori l'utilisation du NFC, qui est pratique sur les mobiles
    • l'appareil est moins polyvalent : pas moyen de l'utiliser pour les opérations PGP de signature, déchiffrement, etc…
    • il est aussi plus encombrant

    Nb :
    Avec pass + yubikey, j'utilise un petit dépôt git (autohébergé) pour rendre disponible les fichiers de pass et les synchroniser entre mes différents appareils (mobile, ordinateur portable, etc…). Ca marche bien, mais la mise en place est un peu lourde.

    Nb2: outre le code pin de déverrouilage, la yubikey possède également un "bouton" capacitif qui permet de rendre obligatoire un accès physique à la clé à chaque usage, tout en étant ultra rapide, ce que je trouve à la fois pratique et sécurisant

  • [^] # Re: (HS) Github

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 1.

    Si ton argument c'est, auto-héberger c'est trop compliquer, faut gérer le truc, alors, ben, faut des gens qui le fassent à ta place. Dont tu seras dépendant. C'est un choix, mais pas celui d'un internet décentralisé et libre. C'est celui de "gmail" pour les email, github pour les dépôts, facebook / twitter pour le social, etc…

    Sinon, https://about.gitlab.com/install/

  • [^] # Re: (HS) Github

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.

    La migration sous Gitlab n'a pas l'air si simple, si on en croit le projet PeerTube, qui conserve son support sur Github, et affiche un lien github sur ses pages, tout en aillant une copie du projet sur Framagit.

    Par ailleurs, le fait d'avoir l'intégralité des projets centralisée facilite grandement l'analyse statistique des projets, sans avoir a dupliquer une multitude de dépôts de sources différentes.

    Enfin, tu as raison, évidemment, le code de Github n'est pas libre. Ce qui explique en partie son extrème centralisation (on ne peut pas lancer sa propre instance de Github, contrairement à Gitlab).

    Enfin, je me permets de penser que si, le fait d'appartenir à Microsoft, dont l'historique anti-LL est particulièrement lourd, est un problème. Malgré la communication intense que cette entreprise déploie pour nous convaincre que "Microsoft loves Linux"…

  • # (HS) Github

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.

    Bonjour, et tout d'abord merci et bravo pour ce travail, et félicitation pour le choix de faire évoluer ce logiciel, là où un abandon en rase campagne aurait été si facile !

    Je ne savais même pas qu'il était possible de rajouter des thumbnailers custom à Nautilus…

    Ma remarque est un peu hors sujet, mais pourquoi avoir choisi Github et pas un autre hébergement similaire (Gitlab par exemple, ou d'autre dépôts comme Framagit) ?

    Pourquoi pas Github ?

    Github est aujourd'hui en situation de quasi monopole pour l'hébergement des projets libres. Github collecte énormément de données sur ces projets, leurs technologies, leurs dépendances, etc… Github appartient à Microsoft, qui le rentabilisera d'une façon ou d'une autre.

    Tous ces éléments combinés en font une menace pour l'avenir des logiciels libres. Certains projet sont bloqués sur Github, car leur historique et/ou leur encours de tickets n'est pas facile à migrer sur d'autres plateformes. Mais un "nouveau" (si on peut dire :-)) projet peut, devrait oserais-je dire, opter pour une alternative moins centralisée, monopolistique, aux mains du grand méchant crosoft.

  • # Perdu...

    Posté par  (Mastodon) . En réponse à la dépêche XMPP@home, 9 juin 2020. Évalué à 3.

    Pour ma part, à chaque fois que je me penche sur le sujet XMPP je suis perdu dans les diverses extensions, leurs implémentations, la compatibilité des clients et des serveurs, etc… bref, j'y passe quelques dizaines de minutes, et je finis par capituler, un peu après avoir fait la checklist des options indispensables, souhaitables, etc…

    Vous vous y retrouvez, vous ?

  • [^] # Re: Outils en cas de problème

    Posté par  (Mastodon) . En réponse à la dépêche Gestion de volumes RAID avec LVM. Évalué à 2.

    Une petite discussion en anglais sur les pour et contre du RAID LVM (in english) : https://unix.stackexchange.com/questions/150644/raiding-with-lvm-vs-mdraid-pros-and-cons

    En pratique, il semble que mdadm est utilisé en sous-main par LVM pour gérer le RAID. Mais qu'à l'époque de cet échange (il y a deux ans environs), les outils d'administrations de mdadm n'étaient pas utilisables en direct… ça a peut-être évolué. A tester !

  • # Mer project

    Posté par  (Mastodon) . En réponse à la dépêche Systèmes d’exploitation pour téléphones — partie 1 : premières initiatives ☎😍. Évalué à 3.

    Un petit lien vers le projet Mer, qui est à la base SailfishOS, mais aussi d'implémentations totalement libre comme Nemo par exemple : http://merproject.org/

  • [^] # Re: Mettre à jour les navigateurs ???

    Posté par  (Mastodon) . En réponse à la dépêche Mercure : un nouveau protocole Web pour mettre à jour les navigateurs en temps réel (« push »). Évalué à 3. Dernière modification le 28 novembre 2018 à 17:31.

    A priori, Mercure n'a pas exactement le même objectif que l'API Push. Je cite la FAQ (j'ai juste suivi le lien dans la dépêche) :

    Quelle est la différence entre Mercure et Web Push ?

    L'API Push est principalement conçue pour envoyer des notifications aux appareils mobiles non connectés à l'application. Dans la plupart des implémentations de WebPush, la taille des messages est très limitée. De plus, les messages sont envoyés via les API et les serveurs propriétaires des sociétés créant les navigateurs et les systèmes d'exploitation mobiles.

    Mercure, quant à lui, est conçu pour envoyer des mises à jour en direct aux périphériques actuellement connectés via un site web ou une app mobile. La taille des messages n’est pas limitée, et le message est directement transmis de vos serveurs vers les clients. En bref, utilisez l'API Push pour envoyer des notifications aux utilisateurs hors connexion (qui seront affichées dans les centres de notification de Chrome, d’Android ou iOS) et utilisez Mercure pour recevoir des mises à jour en direct à l’application lorsque l'utilisateur l’utilise.

  • # Piggy back

    Posté par  (Mastodon) . En réponse à la dépêche PiaLab version 1.2, l'accompagnement dans le RGPD. Évalué à 4.

    Un autre petit projet, bien moins ambitieux mais opérationnel pour créer son registre de traitements : LibreRGPD, le code est ici https://gitlab.com/alci/axelor-demo.git

    C'est construit avec l'Axelor Dev Kit, rapide et efficace.

    Licence AGPL

  • [^] # Re: Espionnage russe

    Posté par  (Mastodon) . En réponse au journal Bashing Kaspersky. Évalué à 2.

    Sérieusement ? La simple idée de lister les abominations américaines, et occidentales en général me fatigue. Alors oui, le régime russe est très très imparfait, mais franchement, je ne pense pas que ni les USA, ni les européens, ni leurs alliés conservent la moindre légitimité pour faire la leçon à qui que ce soit… Comment après avoir tant renié nos propres valeurs pourrait-on se poser en juges des Russes, des Chinois ou des autres ?

  • [^] # Re: Pas encore interdit

    Posté par  (Mastodon) . En réponse au journal Bashing Kaspersky. Évalué à 6.

    C'est fou comme les révélations de Snowden n'ont pas provoqué la même réaction !

  • # Mauvaise cible

    Posté par  (Mastodon) . En réponse au sondage Oui j’avoue, ma plus grosse boulette c’est d’avoir :. Évalué à 3.

    Mauvaise cible + loi de murphy = le client vient de terminer 6 mois de tests et paramétrages sur le nouvel environnement, mis en place à l'arrache par un chef de projet bien intentionné.

    Bien sûr les sauvegardes portaient sur "l'ancien nouvel environnement"… Crash d'un SSD en LVM stripping. SSD cryptés, irrécupérables…

    Cool, c'est une bonne occasion de tester des composants rarement mis à l'épreuve : l'assurance RC Pro et les contrats clients… (au final ça s'est pas trop mal terminé, mais quand on découvre que la sauvegarde n'est pas la bonne, on se sent trèèèès seul).

  • [^] # Re: Mais quand est-ce que ça va s'arrêter!

    Posté par  (Mastodon) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 4.

    - soit un effondrement de l'écosystème de l'emplacement géographique de cet empire (changement climatique majeur ou épuisement des ressources et là encore, à l'échelle de la planète, nulle part ou fuir).
    
    Et ça peut durer des centaines d'années avant un effondrement total.
    

    Des centaines d'années, j'aimerais être aussi optimiste que toi… de moins en moins d'insectes (on parle des abeilles parce qu'il y a du business derrière), de moins en moins d'oiseaux (normal, moins d'insectes), des moins en moins de mammifères sauvages, des aléas climatiques croissants, pollution de l'eau, effet cokctail de la chimie sur les hormones (et la reproduction), inégalités, … un jour ou l'autre le pétrole finira par manquer (on s'en préoccupera le jour où ce sera cas, pas avant), … bref, des centaines d'années, ça me semble bien optimiste.

  • [^] # Re: Ahem

    Posté par  (Mastodon) . En réponse à la dépêche FusionDirectory 1.2.1 est sorti. Évalué à 3.

    C'est vrai que la question mérite d'être posée : même après avoir parcouru le site du projet, je reste perplexe… Ca a l'air d'une sorte de surcouche aux annuaires LDAP, pour gérer… ce que gèrent généralement les annuaires LDAP. Une espèce de pré-config peut-être, un peu comme Active Directory est la pré-config LDAP de Windows ??

  • [^] # Re: Au delà du bookmark ...

    Posté par  (Mastodon) . En réponse au journal Un documentaire allemand sur la dépendance à Microsoft (en anglais). Évalué à 9.

    Le reportage parle essentiellement du desktop dans les administrations européennes. Ils parlent de dépendance "artificielle", et évoquent le lobbying, les choix politiques, les contrats cadres avec MS en procédure négociée, etc… Sont présentées les alternatives basée sur Linux, LibreOffice, et les expériences de Munich (avec le retour en arrière qui a suivi et ses raisons), la gendarmerie française, l'armée italienne, …

  • [^] # Re: Pourquoi X86 (Intel)

    Posté par  (Mastodon) . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 3.

    Je ne suis pas un spécialiste du matériel, mais la dernière fois que j'ai monté un serveur pour un client, il est sorti autour de 10000 €, pour un bi-xeon, 128Go de RAM et disques SSD.
    Ce n'est guère moins cher que ce que proposait la Talos Workstation, et du même acabit en terme de puissance. Surtout, le serveur n'est pas libre, il embarque les backdoor Intel, etc…

  • [^] # Re: Pourquoi X86 (Intel)

    Posté par  (Mastodon) . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 1.

    Il me semble qu'OpenPOWER est à l'heure actuelle la meilleure alternative à Intel (cf. https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation par exemple)

    Pourquoi ne pas la mettre plus en avant ?

  • [^] # Re: AZERTY versus ABCDEFG

    Posté par  (Mastodon) . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 10.

    No to mention the fact that the only standard language is US english. Other languages are superfluous and only used by underdevelopped or archaic countries.

  • [^] # Re: Une concentration sur le mobile ?

    Posté par  (Mastodon) . En réponse à la dépêche Ubuntu abandonne Unity, Mir et le mobile !. Évalué à 1.

    Sinon il y a Jolla… (ok, Sailfish n'est pas libre, mais Mir, libhybris, etc… le sont)

  • # Snappy ?

    Posté par  (Mastodon) . En réponse à la dépêche Ubuntu abandonne Unity, Mir et le mobile !. Évalué à 5.

    Je n'ai pas compris le sens du commentaire sur Snappy… Au final, tu n'y parles que de AppImage et FlatPack. Snappy se rapproche beaucoup plus de FlatPack, donc quid de la comparaison ? Un autre truc me chiffonne : les technos développées par Canonical sont spés, mais celle développées par Redhat, c'est bien c'est standard. C'est pas pour troller, mais je trouve ce discours récurrent, et je me demande d'où il vient.

  • [^] # Re: Bullshit !

    Posté par  (Mastodon) . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 1.

    Dans une autre direction, je viens de tomber là-dessus : http://www.cnx-software.com/2017/03/03/system76-starling-pro-arm-server-powered-by-2-cavium-thunderx-64-bit-processors-sells-for-6400-and-up/

    Je ne sais pas si le matériel (les firmware) est entièrement libre ou pas…

  • [^] # Re: Bullshit !

    Posté par  (Mastodon) . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 3.

    Je ne suis pas sûr de te suivre : d'une part le projet n'était pas si irréaliste que ça, d'autre part ses objectifs me semblent très différents des initiatives que tu mets en avant (en passant, merci de me les faire découvrir :-) ).

    Sur l’objectif tout d'abord : il s'agissait de produire une carte mère entièrement libre (tous les firmwares, y compris celui du BMC), et dont les schémas sont disponibles. Par ailleurs, cette carte proposait des mécanismes de type "Trusted computing", mais dont les clés de chiffrement racine étaient maîtrisées par l'utilisateur. Cette carte pour CPU OpenPOWER permettait d'obtenir des performances comparables (égales ou supérieures selon les cas d'utilisation) à celles de serveurs haut de gamme actuels basés sur les CPU Intel (Xeon), avec des capacités mémoire de plusieurs centaines de Go. Cet objectif est clairement réaliste : de telles cartes mères existent chez Tyan ou IBM (http://www.tyan.com/Barebones_TN71-BP012_BSP012T71V14HR-4T-3 par exemple). Mais elles ne sont pas libres, leur firmware n'est pas auditable ni modifiable…

    Sur le côté réaliste du projet et des prix, force est de constater que le projet a échoué. Néanmoins les prix annoncés étaient cohérents : autour de 10000€. Un serveur Intel de ce type coûte plusieurs milliers d'euros, idem sous POWER8, et c'était le prix proposé. Le surcoût "libre" était quasiment nul. Ceci dit, pour pouvoir lancer ce genre de production, il faut un volume suffisant. La cible était de 1000 cartes mères, et 100 environ ont été pré-commandées. La cible n'était pas tant les particuliers (très) fortunés (quoique, certains s'achètent bien des TV HD top moumoute à plusieurs milliers d'euros aussi !) que les entreprises (ayant des enjeux de sécurité fort, dans la défense, les technologies de pointe, le libre (RedHat, …) …) ou les organisations à but non lucratif (FSF, Mozilla, etc…).

    En résumé, il s'agissait de produire un serveur au logiciel entièrement libre, contrôlé par l'utilisateur (clés de chiffrement et de contrôle de l'OS), gérable en datacenter (BMC), avec des performances actuelles. Ça me semble assez différent des projets que tu décris, et personnellement je regrette cet échec.