raphj a écrit 1745 commentaires

Tu voudrais qu'on dise quoi ? « Les jours français » ?

Ça sonne un peu nul…

peut-être parce que c'est nul et qu'on s'en rend mieux compte en français xD

Ne faites surtout pas de l'open source pour votre produit qui a de la valeur ajoutée, c'est ce que semble dire cet article.

Avec des exemples de produits qui ont décidé de sortie du modèle tout open source, toujours les mêmes : Docker, MongoDB, Elasticsearch.

Si je comprends bien, l'article propose de faire des outils de base / fondements open sources mais de verrouiller le produit final.

Bof, hein. Il y a aussi un tas de projets totalement open source qui marchent. Commercialement. J'ai plus d'exemples qui fonctionnent en tête que les trois toujours cités.

Pour moi, L'open source ne devrait pas se limiter au confort des développeurs, mais s'adresser avant tout aux utilisateurs finaux, parce c'est pour elles et eux qu'on bosse au final.

Alors faites-moi le plaisir de vous inquiéter d'elles et eux en premier, et de nous faire des beaux produits finaux libres. Ce monde est possible.

Créez une communauté qui vous aime bien, proposez une offre SaaS convaincante si vous faites du web, de la customisation pour laquelle vos clients voudront s'adresser à vous en premier, proposez du payant libre… les idées qui fonctionnent ne manquent pas. Vous avez vos chances :-)

Si le code premium reste libre et est débloqué par une licence, pourquoi pas ? Si ça les aide à être indépendants et rentables. C'est beaucoup mieux que la pub ou le pistage.

Mention spéciale si les fonctionnalités Premium restent "superflues". Les autocollants je ne sais pas trop ce que c'est, Signal et Matrix ont tous les deux ça mais je ne les ai pas encore vus à l'action. Pouvoir envoyer des fichiers de 2 Go gratuitement c'est déjà pas mal du tout, payer pour le double ça ne me choque pas, c'est de la bande passante et des ressources serveur. Il y a toujours la solution de couper les fichiers ou passer par des outils tiers de toute façon donc ça ne peut pas être bloquant, c'est juste du confort. Pour les réactions, à voir si ça ne crée pas un déséquilibre entre les gens qui payent et les autres, mais je suppose que ce n'est pas la mort et j'ai l'impression qu'ils ont quand même pensé un peu la chose (les gens qui n'ont pas premium peuvent utiliser une réaction premium si elle est déjà sur le message, c'est significatif). Je suppose que ça peut donner envie aux gens de passer à premium sans les exclure complètement, ce n'est pas trop mal.

Par contre, si le code Premium est proprio, ça peut être la descente aux enfers et une motivation pour Telegram de pousser les utilisateurs vers une version propriétaire, et ça c'est moins ouf. L'article n'en parle pas. Mais toutes ces fonctionnalités semblent être implémentables à coup de vérifications côté serveur. C'est probablement le plus simple et le plus efficace de garder toute la partie cliente libre, et ce serait même possible d'avoir ce code côté serveur libre, si le serveur était libre…

Oui, effectivement, on est d'accord, on dit la même chose :-)
j'étais un peu sarcastique et taquin.

Je me suis déjà pris la tête de cette manière avec Markdown.

(Avec LaTeX aussi, je me suis pris la tête, mais pas de la même manière)

L’avantage c’est que Markdown c’est tellement pauvre pour écrire de la doc qu’il n’y a pas beaucoup de questions à se poser justement ! (/s)

Plus sérieusement, je préfère avoir une syntaxe un peu plus compliquée et ne pas tomber sur des limitations en pleine rédaction de doc. Moi c’est plus ça qui peut me faire sortir du « flow ». De toute façon, on finit par connaitre les éléments de syntaxe après un peu de pratique, mais la limitation, elle, ne s’en va pas. Et je préfère devoir chercher un peu comment faire quelque chose (j’ai l’habitude, j’ai pratiqué LaTeX…) que me rendre compte que ce n’est pas possible et devoir compromettre. Parfois, compromettre donne un meilleur résultat, mais parfois, c’est juste casse-pieds.

Et Markdown, tu finis par devoir connaitre les petites subtilités et limites de chaque implémentation, donc ce n’est pas si simple.

… qu'ils ne l'aient pas fait avant. Depuis toutes ces années…

Donc si je comprends bien, en attendant, on pourra compiler Rust avec GCC, juste qu'il n'y aura pas de vérification sur cet aspect. Mais que ça devrait être ok si on a déjà compilé ce code avec rustc, n'est-ce pas ?

Et donc on pourrait théoriquement utiliser GCC en production, mais seulement si rustc est utilisé pour faire une passe de borrow checking sur les codes qu'on compile avec.

Tu peux développer ? Qu'est-ce qui est plus difficile à configurer sur Firefox que sur les autres navigateurs, et en quoi ?

Est-ce que ça contre-balance la quantité de chose qu'on peut configurer sur Firefox et pas ailleurs ? (je parlais plus de configurabilité que de facilité de configuration, mais je trouve que c'est quand même plutôt facile aussi)

Oui, mea culpa, tu dois avoir raison.

Je pense qu'il utilise la liste publique de suffixes plus quelques noms connus comme localhost + si ça a une forme d'adresse IP.

Si le suffixe n'est pas dans la liste, il va faire la recherche mais afficher un message « Vouliez-vous vous rendre sur http://blablabla.suffixepourri/ ? »

Là où je ne suis pas sûr, c'est s'il tente une résolution de nom quand même avant de lancer la recherche, la flemme de vérifier… mais ça serait peu logique de proposer d'y aller si ça ne résout de toute façon pas.

Chez moi, taper « linuxfr.org » ne fait pas une recherche. C'est bizarre. Par contre effectivement, si tu tapes un nom de domaine qui ne résout pas et que l'URL n'est pas complète (avec un schéma), Firefox va lancer une recherche par défaut.

Mais tout ce que tu décris est désactivable, comme le disent les autres commentaires. Par exemple, la recherche dans la barre d'adresse peut se désactiver dans about:config avec le paramètre keyword.enabled.

Pour la restauration de session, essaie de voir si tu as la case "Ouvrir les fenêtres et onglets précédents". Essaie peut-être aussi de mettre le paramètre browser.startup.couldRestoreSession.count à 0 (je n'ai pas testé). Ce paramètre a l'air d'être là pour restaurer la session en cas de crash ou d'extinction anormale. Chez moi il est mis à 2 et ce n'est pas la valeur par défaut (je n'ai pas changé moi-même à ma connaissance).

À noter que restaurer les onglets n'est pas si gourmand en ressources parce que Firefox ne les charge que si tu les affiches, mais je comprends l'argument de la vie privée.

Ce journal est un peu surprenant, Firefox est justement super dans le fait que si le comportement par défaut ne te plait pas, il y a tout un tas de choses qui sont paramétrables, je crois que c'est une de ses caractéristiques qui le distingue des autres navigateurs justement - il est excellent pour ça :-)

Alors même s'il y a des choses qui pourraient être exposés dans la boite de préférence, elles ont le mérite d'être là et trouvables relativement facilement surtout si elles nous importent au point de se donner la peine d’écrire un journal coup de gueule.

Nope, c'est le comportement par défaut. Tu as dû désactiver quelque chose :-P

(ou alors ça tient à la manière de quitter Firefox)

À ma connaissance rien n'interdit cela

Je trouve l'idée du contournement intéressante, mais si on parle d'un code sous licence copyleft avec des contributions extérieures sans cession de droits d'auteur / affectation de copyright, tu ne peux pas le faire.

Malheureusement, l'absence d'affectation de copyright et la licence copyleft, ce sont deux ingrédients que je trouve souhaitables.

Ou alors ils vont ajouter une puce qui bloque le téléphone après quelques années

S'ils font ça, ils risquent de se prendre des amendes. Il n'y a qu'à voir ce qu'Apple a pris pour simplement un ralentissement dont le but affiché était de permettre le téléphone de tenir la charge sur une batterie potentiellement usée. À voir si c'est rentable malgré les amendes mais j'espère qu'elles seraient pensées pour que ça ne soit pas le cas.

Mais oui, j'y ai pensé aussi… j'espère qu'on se trompe.

J'ai cliqué en pensant qu'on parlait d'une implémentation de zéro en Zig. En fait, le moteur lui-même est V8 (écrit en C++).

Si je comprends bien, Cosmic fournit des API/bibliothèques accessibles depuis JavaScript elles écrites en Zig. Le message que j'en tire c'est que Zig est capable de s'interfacer avec C++ suffisamment bien pour ce cas d'usage.

Si je comprends bien, c'est parce que les gens ont maintenant plus l'habitude d'acheter du reconditionné.

On pourrait penser que c'est parce que les gens tiennent moins à avoir le tout dernier modèle tout neuf tout brillant et/ou qu'une conscience environnemental les pousse à la réutilisation. Et que le phénomène est (de plus en plus) significatif.

Ce serait une excellente nouvelle !

J'espère que les fabricants vont s'adapter et tourner leur business model et leur comm' vers la réparation et la durabilité et, rêvons un peu, tenir plus compte de l'aspect environnemental dans la production des appareils puisque le signal est : "l'environnement n'est plus un bonus / une option".

Beaucoup plus de gens ont l'air sensibles ou en tout cas familier avec les questions environnementales qu'il y a quelques années. Socialement, aujourd'hui on est peut-être plus facilement moins bien vu si on s'en fout, alors qu'il y a quelques années, c'était peut-être plutôt les gens sensibles à ces questions qui étaient un peu marginaux, rabats-joie, etc.

D'ailleurs, peut-être que l'environnement n'est pas la seule raison et que parmi les gens qui achètent reconditionné, il y en a qui le font pour limiter le travail qui est fait dans de mauvaises conditions, du coup continuons à rêver et peut-être que ça poussera un peu les fabriquant à respecter plus les humains dans leur production.

Ou peut-être que c'est surtout parce que le reconditionné est maintenant suffisamment bon dans la tête de ces gens et que la raison principale est que c'est moins cher, et dans ce cas… les implications sont un peu différentes.

Ou toutes ces choses.

C'est difficile de comprendre ce que tu sous-entends sans avoir le contexte. Je n'ai pas suivi PC INpact / Next INpact. Tout ce que je sais, c'est que les gens ici semblent apprécier Next INpact, et effectivement les quelques articles liés qu'on voit passer ici semblent être de qualité. Ton message est par conséquent plus que cryptique pour moi.

En particulier:

ils ont joué avec une certaine arrogance

Qu'est-ce que ça veut dire précisément ?

j'ai vraiment du mal depuis

Pourquoi ?

Parfois, le loup revient régulièrement pour de vrai.

Ouais, non. Je pratique. Tu peux tomber sur des cons. Ça arrive. Je suis déjà tombé sur des spécimens impressionnants. Mais en général, si tu vas à leur rencontre spontanément, ça se passe bien. En particulier si l'automate est en panne. La plupart des contrôleurs, comme la plupart des humains, souhaitent que tout se passe au mieux.

Après, bien sûr, quelqu'un qui a une attitude de connard risque d'obtenir un service adapté. Rien de spécifique à la SNCF, les humains ça fonctionne un peu comme ça.

Je pense qu'on s'est rencontrés aux JDLL. Merci d'être passé à notre stand :-)

Merci pour ce retour d'expérience. C'est toujours intéressant de savoir que l'outil sur lequel on bosse est utile, et quels problèmes on peut rencontrer avec. On prend note !

Pour la génération PDF multi page, en effet ce n'est pas une fonctionnalité de base et l'extension qui servait à ça n'est plus maintenue. Une manière classique de faire est de créer une nouvelle page et d'utiliser la macro include pour inclure les différentes pages dedans, avec des sauts de pages entre (ce qui peut se faire avec la propriété CSS break-after).

Ça peut aussi, comme tu le mentionnes (tu sais déjà mais je développe pour les lecteurs et les lectrices du site), se scripter en Velocity, qui est effectivement un langage de template assez puissant et avec lequel on peut accéder à l'API publique d'XWiki et faire pas mal de choses. Ou en Groovy. Ça permet d'utiliser des boucles pour ne pas avoir à de payer l'inclusion manuelle de dizaines de pages si effectivement il y en a beaucoup. Ou d'automatiser, par exemple, la création de pages, ce qui peut se faire en quelques lignes :

{{velocity}}
#set($xdoc = $xwiki.getDocument("Nom.De.La.Nouvelle.Page"))
$xdoc.setContent("Nouveau contenu")
$xdoc.save()
{{/velocity}}

Tout ceci étant dit, j'ai partagé ton article dans le chat de l'équipe, on me souffle à l'oreille que tu pourrais être intéressé par nos derniers développements en matière d'export PDF. On te recontacte.

Concernant le déplacement de pages, ça se fait aisément avec la fonction de renommage. Mais effectivement, si l'application stocke des métadonnées dans la page (Pour celles et ceux qui ne connaissant pas, dans XWiki, on peut définir des classes, et il est possible d'attacher des objets qui sont des instances de ces classes à des pages XWiki), ça va tout casser, un peut comme vous casseriez une application de bureau en déplaçant ses fichiers de configurations.

J'imagine qu'une des solutions possibles pour avoir le contenu ailleurs serait là aussi d'utiliser la macro include sur la page où on veut voir le contenu, ou de le scripter en Velocity / Groovy. Mais on est d'accord, parfois, c'est tout aussi voir plus simple de le faire manuellement, surtout quand c'est une opération one-shot qui ne concerne pas un volume énorme de données.

En tout cas il ne faut pas hésiter à nous faire d'autres retours ou nous poser des questions. On a aussi un canal #xwiki public sur Matrix (en anglais).

Sur ton lien, je lis:

Some uses of apt do not install new packages which makes it less suitable for KDE neon.

Je pense qu'on parle de "apt upgrade" versus "apt full-upgrade" et c'est ce qu'on peut trouver sur internet ?
Dans ce cas, apt full-upgrade est ok aussi je suppose.

Sinon, PackageKit c'est une abstraction des différents gestionnaires de paquets, pour pouvoir fournir aux outils graphiques / en lignes de commandes une interface unifiée pour gérer les logiciels. Ça a l'air d'abstraire aussi certaines situations problématiques, comme vouloir faire une opération quand il y en a déjà une en cours : PackageKit sait mettre les opérations en file d'attente. C'est ce qu'utilisent maintenant les gestionnaires de mise à jour des distributions, ou leurs logithèques spécifiques. À charge de la distribution de fournir des méta données correctes pour PackageKit.

En soit ce n'est pas "mieux" d'utiliser pkcon que les gestionnaires de paquets eux-mêmes. Je ne crois pas qu'il y ait un intérêt particulier à utiliser pkcon, surtout si tu sais déjà utiliser le gestionnaire de paquet de la distribution : ça fait une couche d'abstraction de moins à déboguer en cas de problème.

Bref, pour moi, pkcon a surtout un intérêt potentiel pour moi, développeur d'un script ou d'une application qui ne veut pas prendre en charge tous les gestionnaires de paquets de la planète.

Après, pkcon va peut-être devenir plus agréable à utiliser avec le temps (je n'ai pas essayé). Avec cette gestion de file d'attente, ça pourrait être cool, et ça permettrait moins de blocages avec les outils graphiques s'interfaçant déjà avec PackageKit et ça pourrait permettre de se payer des erreurs du style "oh, je n'ai pas réussi à récupérer les mises à jour parce que le gestionnaire de paquet est déjà occupé".

Ça ressemble beaucoup à Phosh que je vois comme la version mobile de Gnome actuellement. C'est très clairement des technos et des applis Gnome, sauf le shell. Ça a l'air un peu plus polish mais très très ressemblant. C'est ce que j'utilise actuellement sur le PinePhone. Étonnant qu'il n'y ait pas de mention du projet, on pourrait s'attendre à des collaborations entre les deux projets voire une fusion.

Un travail sur la compatibilité mobile de Gnome directement est probablement une bonne nouvelle. Il y a encore plein de problème de "responsive" qui ont l'air "facilement" corrigeable dans les appli Gnome (et pareil voire pire chez KDE).

Oulah, perso je trouve que ça devrait être le comportement par défaut le lazy loading des images. Ça casserait probablement le web de le faire du coup ce n'est pas trop possible.

L'idée n'est pas du tout idiote : on ne charge une image que si elle est susceptible d'être affichée. C'est surtout pour économiser les ressources. Alors oui, en se creusant un peu la tête, ça peut donner l'indication au serveur qu'on est effectivement en train de lire cette partie de la page…

mais ça ?

En réalité, ce mécanisme [le lazy loading] est un moyen de mettre en avant certains contenus de manière à ce que l’utilisateur soit incité à cliquer dessus, sans attendre le téléchargement complet de la page

… Wat? je ne vois pas le rapport. Comment un truc qui permet de charger quelque chose au besoin permet de mettre en avant quoi que ce soit ? Ça me parait très peu informé effectivement, ou alors j'ai louper un gros truc.

Ça ne me parait pas souhaitable de bloquer le lazy loading. Il faut surtout bloquer les trackers. Ça ne me parait pas souhaitable de bloquer le lazy loading.

L'autre page parait plutôt censée par contre.

Tout a fait. Malgré sa communication sur la vie privée, DDG ne mérite pas une confiance absolue (ni globalement personne), et mérite maintenant un peu plus de méfiance.

Mozilla fait également des choses discutables avec Firefox et mérite également une surveillance.

Que ceux qui vantent DDG pour "échapper" à des gros méchants soient conscient que c'est du blabla-washing : ça fait joli à afficher mais au final vous donnez quand même des sous aux "méchants", et parfois même de la vie privée

Après il ne faut pas exagérer non plus, on n'est pas au niveau de Google, Microsoft ou Facebook. Au moins du fait de la taille de la boite et son influence sur le monde, qui est incomparable à celle des GAFAM. À ce jour, il me semble que c'est le moteur de recherche où on est le moins pisté, et encore une fois, le problème spécifique dont on discute ne touche pas le moteur de recherche mais un produit à la périphérie. Je pense vraiment que le discours sur la vie privée de DuckDuckGo est principalement correct, et a au moins pour effet, espérons-le, de sensibiliser. On n'est d'ailleurs pas en train de parler d'un traqueur imposé par DDG, mais d'un traqueur "tiers" (intentionnellement) pas bloqué par DDG.

Si le blabla sur la vie privée n'est pas un contrat, il reste à montrer qu'il y a du pistage. Il y a bien eu cette histoire de favicon, mais meh. Il y a aussi les liens affiliées dans les recherches, mais ils ne s'en cachent pas.

De toute façon il ne faut pas prendre le blabla marketing comme une garantie, mais tout juste comme un signal sur les valeurs que veut afficher l'entreprise. C'est clair.

En attendant une meilleure solution… actuellement, s'il faut tout classer de manière binaire avec un peu d'exigence, en matière de moteur de recherche, tout est à zéro malheureusement.

Les pubs pour Brave sont toujours aussi peu subtiles et honnêtes… mais bref, passons.

J'utilise Duck Duck Go mais je ne suis pas super content que ça se base sur Bing. Sans parler du fait que ce serait cool d'avoir un moteur de recherche web mondial ne dépendant pas d'un GAFAM, forcément des contrats comme ça avec Microsoft devaient arriver.

Mais pour moi, Duck Duck Go est un moteur de recherche. Il ne me viendrait pas à l'idée d'utiliser leur navigateur rebrandé ou leur extensions (c'est de ça dont il est sujet ici, hein, pas du moteur de recherche ! Pourquoi l'article est-il si peu clair sur le sujet ? Quelle proportion d'utilisateurs du moteur de recherche utilise réellement le navigateur de DDG ? J'aurais laissé le bénéfice du doute sans la mention de Brave, DDG mérite un petit scandale sur ce sujet, mais là je considère que c'est du FUD payé par Brave), et j'utilise un minimum ses fonctionnalités, en particulier ses bangs. DDG n'a pas besoin de savoir ce que je fais sur les autres sites / moteurs de recherches.

En fait, je déconseillerais même d'utiliser le navigateur d'un moteur de recherche (avec un modèle économique de ce style). C'est hors sujet et suspect et voilà un élément de plus pour valider cette position.

Pour le moment, il me semble qu'une des manières la plus efficaces de protéger sa vie privée c'est le combo Firefox (ou Tor Browser ? je ne connais pas) + uBlock Origin (entre autres). (et d'ailleurs, Brave se base sur Chromium qui n'est pas idéal. Il manque des fonctionnalités à Chromium pour un blocage de trackers réellement efficace : https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox). Et, oui, idéalement il faut changer quelques paramètres de Firefox pour ça parce que par défaut, c'est un peu léger.

En fait, il arrive que le scanner de codes barres soit dans l'appareil Android lui-même. Cet appareil a la forme et d'ailleurs (toutes) les fonctionnalités d'un téléphone, mais est généralement présenté comme un ordinateur mobile. On peut y mettre une carte SIM et téléphoner ou envoyer des SMS. C'est par exemple certainement le cas du Honeywell EDA52 mentionné dans le journal. J'ai eu l'occasion de travailler sur le modèle précédent (l'EDA51), ainsi que sur un téléphone Zebra. C'est vraiment de l'Android tout ce qu'il y a de plus classique, avec un lecteur de codes barres intégré et des boutons latéraux pour déclencher le lecteur de codes barres. Ce lecteur prend en charge plusieurs formats de codes barres, y compris les QR Codes. La batterie est assez impressionnante, ça tient longtemps, et la construction est solide, on sent que le matériel est de bonne qualité (dans les deux cas).

Et en effet, selon les marques ils ont des API différentes qui fonctionnent essentiellement de la même manière. Un SDK n'est pas forcément nécessaire, en fait ça peut fonctionner entièrement à base d'Intents Android. Une application Android du constructeur tourne en tâche de fond et traite ces intents. On a des intents qui permettent d'allumer le lecteur de codes barres, commencer à flasher, recevoir le résultat, l'éteindre, pousser des réglages, gérer des profils de réglage. Par défaut, et parce que c'est plus facile à prendre en main au début et que ça permet de faire marcher le scan dans une page web classique, le scanner du téléphone se comporte comme un clavier et envoie le code barres sous forme d'entrée clavier. Mais c'est moyennent fiable. C'est probablement mieux de désactiver ça parce qu'il y a peu de contrôle là dessus, c'est vaguement bugué, on ne sait pas forcément quand la saisie se termine même s'il y a généralement la possibilité de définir un préfixe et/ou un suffixe / de demander ou pas d'envoyer un évènement "touche entrée", etc.

Les appareils Zebra répondent à l'API DataWedge de Zebra alors que le Honeywell EDA52 répond à sa propre API, qui ressemble pas mal. Pour caricaturer, c'est quasi les mêmes intents avec les mêmes données, mais avec des noms et des propriétés différentes. Il est possible de piloter les deux types de d'appareils à partir de la même activité Android, et d'envoyer les deux types d'intent quitte à ce que l'un des deux soit envoyé dans le cosmos à chaque fois. Ça marche, je l'ai fait, mais je veux bien croire que ça ne passe pas à l'échelle s'il faut prendre en charge plusieurs modèles et je confirme que la documentation est un peu inégale et que c'est beaucoup d'essais-erreurs, et les intents Android j'ai trouvé ça pénible à déboguer (peut être à cause de mon manque d'expérience), donc une bibliothèque pour unifier tout ça est la bienvenue. Ça permet effectivement certainement de ne pas s'enfermer chez un fournisseur en particulier.

Alors pourquoi Android ? Parce que ça permet de répondre à des cas d'usage où l'appareil doit être transportable et autonome (mobile, quoi) et de faire appel à des prestataires / d'embaucher des développeurs / développeuses mobiles sans compétences / connaissances particulières, sans avoir besoin de réapprendre tout un système spécifique. Ça permet aussi aux constructeurs de ne pas tout redévelopper de zéro. Et ça permet de proposer une application mobile qui tournera sur un téléphone classique sans lecteur de codes barres avec une solution de repli qui s'appuie sur l'appareil photo du téléphone.

Et donc oui, je pense que c'est relativement répandu. On parle bien d'un "ordinateur" mobile complet, pas seulement un lecteur de codes barres qui a besoin d'être connecté à un ordinateur. Un modèle coûte probablement autour de 1000 €, ou un peu moins mais avec du support à acheter pour recevoir des mises à jour.