Il existe donc réellement des personnes qui utilisent des makefiles avec Java ?
Personnellement je ne me rappelle plus la dernière fois ou j’ai utilisé autre chose que Maven, Gradle ou très rarement Ant. Et oui, ce couplage à des toolings lourdingues peut clairement être listé dans les inconvénients de Java.
Ensuite ça n’est pas la question. Elle n’est pas de « chercher la solution la plus simple pour répondre au besoin » mais précisément de « vérifier si Java est vraiment une usine à gaz pour ce genre de cas ».
Je confirme, la classe date de Java 6 mais est peu utilisée. D’une part parce qu’elle est d’assez bas niveau et donc peu pratique pour des projets un peu complexe, d’autre part parce que c’est une API en com.sun.* que beaucoup de gens (y compris des outils automatiques !) confondent avec une API en sun.*, ces dernières ne devant pas être utilisées parce que privées (et supprimées des dernières versions de Java). Les API en com.sun.* sont pourtant standard (on les retrouve dans toutes les implémentations de Java, mêmes celles historiquement IBM) et sont simplement déconseillées dans quelques usages précis.
J’ai fait aussi un test rapide avec des outils plus « industriels » pour ce genre d’application (un microserveur minimaliste), comme vert.x. On a un peu moins de code un peu plus clair, et des performances sensiblement identiques (même la consommation RAM, ce qui m’a surpris). C’est aussi un facteur qui explique le manque d’intérêt pour HttpServer.
Je n’ai pas lancé le benchmark PHP, parce que j’ai complètement la flemme d’installer PHP juste pour ça sur le nouveau serveur, et de configurer un nouvel endpoint qui réponde en HTTP(non S) juste pour ça. Je sais juste que la version actuelle est « très largement suffisante en conditions réelles ».
D’ailleurs, j’ai dit une connerie, elle ne fait pas 3 lignes mais 2 – il n’y a bas de balise fermante :
Et c’est lancé avec un proxy socket Unix vers PHP-FPM.
La métrique du nombre de lignes était là parce que l’une des critiques très souvent faites à Java est que c’est un langage verbeux. Ça s’entends bien sûr en tant que « lignes correctement formatées », pas des one-liners idiots.
Pas de quoi, on la retrouve encore très souvent (y compris dans des prétendus « papiers de recherche sur l’état de l’art de la performance de la JVM », qui perdent d’un coup pas mal de crédibilité).
Cf les commentaires de l'article sur Zeste de Savoir : tout dépend de ce que tu appelles beaucoup plus efficace. En consommation RAM, plutôt oui. En débit en sortie ou en complexité de code, pas tant que ça (si, y'a une implémentation en C/C++ qui est beaucoup plus rapide mais beaucoup plus complexe).
Tu saurais dire quel processeur tu as, et l'occupation CPU que tu obtiens pendant le test ? Ça m'étonne de voir une telle différence alors que les deux programmes tournent sur des JVM.
Il faudrait regarder la consommation CPU et mémoire du serveur Python.
Sur les implémentations mono-thread, Java est à la louche 1.5x à 2x plus lent que les implémentations compilées. Par contre, les implémentations peuvent être multi-thread par défaut, ce qui fait très vite monter les performances mesurées si on ne fait pas gaffe.
Certes, mais les années 90, c’est plus « il y a 25 ans » que « il y a 15 ans », et le web a énormément changé entre ces deux dates. L’optimisation à mort du web dans les années 90, clairement oui. Au milieu des années 2000, c’était déjà beaucoup moins le cas.
Dans le cas particulier de Qwant : deux images en PNG transparent mais qui sont des photos, donc qui prennent un max de place. Plus le classique des sites modernes :
Le framework JS à charger au premier appel
Les polices
Énormément de CSS (205 ko, 33 ko compressés)
Un document chargé très lourd par rapport à ce que ça affiche (je peux difficilement appeler ça « une page HTML » vu que le gros du contenu est du JS embarqué).
… et un mauvais souvenir de ce qu’était le web il y a 15 ans, aussi. En 2003, pendant mes études, j’avais suivi un cours de dev web avec un projet, dont l’une des contraintes était « le site doit être utilisable via un modem 56 k » (on en trouvait encore). Ben c’était difficile, parce que la moindre animation explose les « 10 à 30 ko » dont tu parles – le gif est un format inefficace en réalité. Mais on avait plus l’habitude d’attendre plusieurs secondes le temps que toute la page se charge.
Parce que ça n'est pas une interface, c'est juste une blague. Il y a une erreur de traduction (volontaire ?) dans le titre du lien, qui devrait être : « Si OpenSSL était une interface graphique ».
Et l'auteur a repris un thème d'une époque où on trouvait souvent ce genre d'interface surchargée à mort, avec un dégueulis de contrôles en vrac dans un tas d'onglets.
Certes, mais ça n'a pas tellement de rapport. Un bug peut être techniquement possible à corriger sans que ça soit facile à faire, ou que la difficulté vienne du langage.
D'ailleurs la discussion que tu lies montre bien que les problèmes principaux viennent soit de comportements qui ont besoin de lire l'intégralité du fichier (ce qui ne nécessite pas de l'avoir en mémoire pour fonctionner d'ailleurs), soit des API internes qui ne permettent pas la lecture par "pages".
Si jedit est incapable d’ouvrir un fichier énorme, c’est une limitation de Jedit, pas de Java. Java est évidemment capable de lire seulement une partie d’un fichier au besoin, notamment à l’aide de ce genre de méthode qui est disponible depuis la toute première version.
Par ailleurs, je sais pas à quoi ressemble le connecteur lightning mais je gage qui est mieux que celui de l'USB-C, qui aurait pu, tant qu'à faciliter la manipulation, être cylindrique, ou au moins carré, bref. C'est perfectible.
Un connecteur cylindrique ou carré, c’est très encombrant dans toutes les dimensions, ce qui est un handicap quand on cherche en permanence à avoir des objets les plus fins possibles. Alors qu’un connecteur plat, tu peux l’allonger pour mettre tous les contacts nécessaires sans sacrifier toutes les dimensions.
C’est d’ailleurs ce problème qui a fait que Lenovo a abandonné son connecteur d’alimentation historique universel à toutes ses gammes de PC portables, qui était rond, pour un format rectangulaire plat.
Ca demande un peu plus de maintenance régulière mais je ne serre pas les meules comme quand on fait un "apt-get dist-upgrade". Parce qu'on en fait pas.
Ça c’est un argument que je vois régulièrement de la part des amateurs d’Arch et que je ne comprends pas – ou plus exactement que je ne comprends plus.
En ce qui me concerne, je n’ai jamais eu de problème à la mise à jour de version d’une Debian depuis plus d’une décennie – y compris la mise à jour de Raspberry Pi OS, qui n’est pas officiellement supportée mais très bien décrite, il y a juste une pré-installation à faire et c’est deux paquets à installer et une config à modifier.
Pour Ubuntu, ça a merdé à une époque, mais ça fait plus de 5 ans que les mises à jour se passent sans aucun souci, qu’elles soient de version mineure en version mineure ou de LTS en LTS, desktop comme serveur.
Alors je ne sais pas : est-ce que j’ai de la chance ? Est-ce que c’est des restes de méfiance de vieux problèmes maintenant résolus – comme j’ai eu des problèmes avec une Arch toute cassée il y a plus de 10 ans maintenant ? Je m’interroge.
Déjà, merci pour ces ressources sur la colorimétrie dans le libre, elles sont rares et précieuses.
Comme le dit le titre, je voudrais surtout répondre à cet argument, qui est hélas trop courant (dans le libre et ailleurs) :
Même s’il arrive de lire des critiques à l’encontre des ces logiciels, celles-ci ne sont pas fondées car chacun d’eux (les logiciels libres) est capable de produire du contenu à la hauteur des exigences actuelles du métier.
Pour moi il n’y a pas de lien de causalité entre « l’outil peut produire un résultat conforme à l’état de l’art » et « les critiques de l’outil ne sont pas fondées ». On peut tout à fait critiquer un outil même s’il permet d’obtenir un résultat tout à fait conforme à ce qu’on est en droit d’attendre d’un outil professionnel.
En particulier, dans le cadre d’un métier, la qualité d’utilisation de l’outil compte au moins autant que le résultat obtenu. S’il est possible d’obtenir avec un logiciel libre un bon résultat mais au prix de trois fois plus de complexité et d’étapes intermédiaires que dans un logiciel concurrent, alors le logiciel libre n’est pas intéressant hors du contexte militant. Idem s’il y a des problèmes de compatibilités avec les formats habituels – et que ces formats sont indispensables pour travailler avec le reste de la chaine – imprimeurs par exemple, dans le cas des logiciels cités.
Ça ne signifie absolument pas que le logiciel libre doit absolument copier l’ergonomie et les processus des logiciels en place. Par exemple, Darktable a un fonctionnement radicalement différent de son principal « concurrent propriétaire », Lightroom, et pourtant permet d’obtenir des très bons résultats très efficacement si on prends la peine d’en apprendre et d’en respecter le fonctionnement.
Comme exemple contraire, je donnerais Scribus : même après plusieurs tutos différents et diverses manipulations je n’arrivais pas à faire le genre de documents que je voulais, de dépit je me suis tourné vers Affinity Publisher qui m’a permis de finaliser mon document en un quart du temps que j’ai passé sur Scribus – pourtant Affinity Publisher a encore de grosses lacunes ergonomiques.
Les offices des brevets sont censés vérifier que les brevets soumis sont applicables. Mais ils sont aussi rémunérés par les demandes de brevets.
C'est donc très vite rentable d'accepter à peu près n'importe quoi et d'attendre une décision de justice pour invalider les brevets qui n'auraient jamais du être acceptés. Ça explique pourquoi l'office Australien a accepté, le 2 août 2001, le brevet AU2001100012 pour un Circular transportation facilitation device qui n'est autre que la roue.
[^] # Re: Version Rust
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Il existe donc réellement des personnes qui utilisent des makefiles avec Java ?
Personnellement je ne me rappelle plus la dernière fois ou j’ai utilisé autre chose que Maven, Gradle ou très rarement Ant. Et oui, ce couplage à des toolings lourdingues peut clairement être listé dans les inconvénients de Java.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pourquoi une redirection?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 6.
Pour commencer, j’utilise Nginx et pas Apache.
Ensuite ça n’est pas la question. Elle n’est pas de « chercher la solution la plus simple pour répondre au besoin » mais précisément de « vérifier si Java est vraiment une usine à gaz pour ce genre de cas ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Record
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Peut-être, mais pour moi ça sort de ce qu'est censé être un Record.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java pur ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Je confirme, la classe date de Java 6 mais est peu utilisée. D’une part parce qu’elle est d’assez bas niveau et donc peu pratique pour des projets un peu complexe, d’autre part parce que c’est une API en
com.sun.*que beaucoup de gens (y compris des outils automatiques !) confondent avec une API ensun.*, ces dernières ne devant pas être utilisées parce que privées (et supprimées des dernières versions de Java). Les API encom.sun.*sont pourtant standard (on les retrouve dans toutes les implémentations de Java, mêmes celles historiquement IBM) et sont simplement déconseillées dans quelques usages précis.J’ai fait aussi un test rapide avec des outils plus « industriels » pour ce genre d’application (un microserveur minimaliste), comme vert.x. On a un peu moins de code un peu plus clair, et des performances sensiblement identiques (même la consommation RAM, ce qui m’a surpris). C’est aussi un facteur qui explique le manque d’intérêt pour
HttpServer.La connaissance libre : https://zestedesavoir.com
[^] # Re: PHP ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Je n’ai pas lancé le benchmark PHP, parce que j’ai complètement la flemme d’installer PHP juste pour ça sur le nouveau serveur, et de configurer un nouvel endpoint qui réponde en HTTP(non S) juste pour ça. Je sais juste que la version actuelle est « très largement suffisante en conditions réelles ».
D’ailleurs, j’ai dit une connerie, elle ne fait pas 3 lignes mais 2 – il n’y a bas de balise fermante :
Et c’est lancé avec un proxy socket Unix vers PHP-FPM.
La métrique du nombre de lignes était là parce que l’une des critiques très souvent faites à Java est que c’est un langage verbeux. Ça s’entends bien sûr en tant que « lignes correctement formatées », pas des one-liners idiots.
La connaissance libre : https://zestedesavoir.com
[^] # Re: native-image
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Pas de quoi, on la retrouve encore très souvent (y compris dans des prétendus « papiers de recherche sur l’état de l’art de la performance de la JVM », qui perdent d’un coup pas mal de crédibilité).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Rust et C
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Cf les commentaires de l'article sur Zeste de Savoir : tout dépend de ce que tu appelles beaucoup plus efficace. En consommation RAM, plutôt oui. En débit en sortie ou en complexité de code, pas tant que ça (si, y'a une implémentation en C/C++ qui est beaucoup plus rapide mais beaucoup plus complexe).
La connaissance libre : https://zestedesavoir.com
[^] # Re: native-image
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4. Dernière modification le 13 juin 2022 à 14:19.
L'option
-server(s'il s'agit bien d'elle) ne sert plus à rien sur les JVM HotSpot et dérivées 64 bits, la JVM "server" est la seule qui existe encore.Et j'ai la flemme d'installer PHP sur le nouveau serveur et d'autoriser une connexion en HTTP simple pour faire le test.
La connaissance libre : https://zestedesavoir.com
[^] # Re: En groovy (sans optimisations)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4.
Personnellement je dois explicitement définir l'exécuteur pour que mon code devienne multithread. C'est une ligne à ajouter, mais sans elle le code est monothread (GC exclus).
La connaissance libre : https://zestedesavoir.com
[^] # Re: En groovy (sans optimisations)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Tu saurais dire quel processeur tu as, et l'occupation CPU que tu obtiens pendant le test ? Ça m'étonne de voir une telle différence alors que les deux programmes tournent sur des JVM.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est beaucoup ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Il faudrait regarder la consommation CPU et mémoire du serveur Python.
Sur les implémentations mono-thread, Java est à la louche 1.5x à 2x plus lent que les implémentations compilées. Par contre, les implémentations peuvent être multi-thread par défaut, ce qui fait très vite monter les performances mesurées si on ne fait pas gaffe.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Tristitude ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Comment s’appelle ce design web ?. Évalué à 3. Dernière modification le 13 juin 2022 à 12:17.
Certes, mais les années 90, c’est plus « il y a 25 ans » que « il y a 15 ans », et le web a énormément changé entre ces deux dates. L’optimisation à mort du web dans les années 90, clairement oui. Au milieu des années 2000, c’était déjà beaucoup moins le cas.
La connaissance libre : https://zestedesavoir.com
[^] # Re: HTTPS
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4.
Oui, cette phrase est surtout là pour montrer que HTTPS est consommateur – contrairement à ce qu’on peut lire parfois sur le sujet.
Il n’y a pas de tests sur le serveur public en HTTP parce qu’il est configuré pour forcer la redirection vers HTTPS.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pourquoi une redirection?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Une redirection parce que c’est le plus simple, ça évite toute forme de traitement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Tristitude ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Comment s’appelle ce design web ?. Évalué à 7. Dernière modification le 13 juin 2022 à 10:00.
Dans le cas particulier de Qwant : deux images en PNG transparent mais qui sont des photos, donc qui prennent un max de place. Plus le classique des sites modernes :
… et un mauvais souvenir de ce qu’était le web il y a 15 ans, aussi. En 2003, pendant mes études, j’avais suivi un cours de dev web avec un projet, dont l’une des contraintes était « le site doit être utilisable via un modem 56 k » (on en trouvait encore). Ben c’était difficile, parce que la moindre animation explose les « 10 à 30 ko » dont tu parles – le gif est un format inefficace en réalité. Mais on avait plus l’habitude d’attendre plusieurs secondes le temps que toute la page se charge.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pourquoi MacOS 9 comme thème pour l'interface ???
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Enfin une interface graphique pour OpenSSL. Évalué à 9.
Parce que ça n'est pas une interface, c'est juste une blague. Il y a une erreur de traduction (volontaire ?) dans le titre du lien, qui devrait être : « Si OpenSSL était une interface graphique ».
Et l'auteur a repris un thème d'une époque où on trouvait souvent ce genre d'interface surchargée à mort, avec un dégueulis de contrôles en vrac dans un tas d'onglets.
La connaissance libre : https://zestedesavoir.com
[^] # Re: USB-D
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal L'Union européenne va imposer l'USB-C !. Évalué à 2.
Ha ? La transition doit être en cours alors, celui du boulot a moins d'un an et a encore le connecteur rectangulaire. Mais je ne suis pas surpris.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Editeur
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Adieu Atom :(. Évalué à 5.
Certes, mais ça n'a pas tellement de rapport. Un bug peut être techniquement possible à corriger sans que ça soit facile à faire, ou que la difficulté vienne du langage.
D'ailleurs la discussion que tu lies montre bien que les problèmes principaux viennent soit de comportements qui ont besoin de lire l'intégralité du fichier (ce qui ne nécessite pas de l'avoir en mémoire pour fonctionner d'ailleurs), soit des API internes qui ne permettent pas la lecture par "pages".
La connaissance libre : https://zestedesavoir.com
[^] # Re: Editeur
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Adieu Atom :(. Évalué à 9.
Si jedit est incapable d’ouvrir un fichier énorme, c’est une limitation de Jedit, pas de Java. Java est évidemment capable de lire seulement une partie d’un fichier au besoin, notamment à l’aide de ce genre de méthode qui est disponible depuis la toute première version.
La connaissance libre : https://zestedesavoir.com
[^] # Re: USB-D
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal L'Union européenne va imposer l'USB-C !. Évalué à 4.
Un connecteur cylindrique ou carré, c’est très encombrant dans toutes les dimensions, ce qui est un handicap quand on cherche en permanence à avoir des objets les plus fins possibles. Alors qu’un connecteur plat, tu peux l’allonger pour mettre tous les contacts nécessaires sans sacrifier toutes les dimensions.
C’est d’ailleurs ce problème qui a fait que Lenovo a abandonné son connecteur d’alimentation historique universel à toutes ses gammes de PC portables, qui était rond, pour un format rectangulaire plat.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Arch <3
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Quelques mots sur Arch. Évalué à 10.
Ça c’est un argument que je vois régulièrement de la part des amateurs d’Arch et que je ne comprends pas – ou plus exactement que je ne comprends plus.
En ce qui me concerne, je n’ai jamais eu de problème à la mise à jour de version d’une Debian depuis plus d’une décennie – y compris la mise à jour de Raspberry Pi OS, qui n’est pas officiellement supportée mais très bien décrite, il y a juste une pré-installation à faire et c’est deux paquets à installer et une config à modifier.
Pour Ubuntu, ça a merdé à une époque, mais ça fait plus de 5 ans que les mises à jour se passent sans aucun souci, qu’elles soient de version mineure en version mineure ou de LTS en LTS, desktop comme serveur.
Alors je ne sais pas : est-ce que j’ai de la chance ? Est-ce que c’est des restes de méfiance de vieux problèmes maintenant résolus – comme j’ai eu des problèmes avec une Arch toute cassée il y a plus de 10 ans maintenant ? Je m’interroge.
La connaissance libre : https://zestedesavoir.com
[^] # Les drapeaux ne sont pas des langues
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Stallman en boîte. Évalué à 6.
J’en profite pour rappeler que les drapeaux ne représentent pas correctement les langues (en anglais). Cf aussi par ici (en anglais aussi) ou ce résumé en français.
La connaissance libre : https://zestedesavoir.com
# Ça n’est pas parce qu’on peut faire quelque chose des outils qu’ils ne sont pas exempts de critique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal PAO, graphisme et colorimétrie dans le libre. Évalué à 10.
Déjà, merci pour ces ressources sur la colorimétrie dans le libre, elles sont rares et précieuses.
Comme le dit le titre, je voudrais surtout répondre à cet argument, qui est hélas trop courant (dans le libre et ailleurs) :
Pour moi il n’y a pas de lien de causalité entre « l’outil peut produire un résultat conforme à l’état de l’art » et « les critiques de l’outil ne sont pas fondées ». On peut tout à fait critiquer un outil même s’il permet d’obtenir un résultat tout à fait conforme à ce qu’on est en droit d’attendre d’un outil professionnel.
En particulier, dans le cadre d’un métier, la qualité d’utilisation de l’outil compte au moins autant que le résultat obtenu. S’il est possible d’obtenir avec un logiciel libre un bon résultat mais au prix de trois fois plus de complexité et d’étapes intermédiaires que dans un logiciel concurrent, alors le logiciel libre n’est pas intéressant hors du contexte militant. Idem s’il y a des problèmes de compatibilités avec les formats habituels – et que ces formats sont indispensables pour travailler avec le reste de la chaine – imprimeurs par exemple, dans le cas des logiciels cités.
Ça ne signifie absolument pas que le logiciel libre doit absolument copier l’ergonomie et les processus des logiciels en place. Par exemple, Darktable a un fonctionnement radicalement différent de son principal « concurrent propriétaire », Lightroom, et pourtant permet d’obtenir des très bons résultats très efficacement si on prends la peine d’en apprendre et d’en respecter le fonctionnement.
Comme exemple contraire, je donnerais Scribus : même après plusieurs tutos différents et diverses manipulations je n’arrivais pas à faire le genre de documents que je voulais, de dépit je me suis tourné vers Affinity Publisher qui m’a permis de finaliser mon document en un quart du temps que j’ai passé sur Scribus – pourtant Affinity Publisher a encore de grosses lacunes ergonomiques.
La connaissance libre : https://zestedesavoir.com
# Encore un office des brevets qui n'a pas fait son boulot
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien GNOME vs Patent troll, 1-0, balle au centre . Évalué à 10.
Les offices des brevets sont censés vérifier que les brevets soumis sont applicables. Mais ils sont aussi rémunérés par les demandes de brevets.
C'est donc très vite rentable d'accepter à peu près n'importe quoi et d'attendre une décision de justice pour invalider les brevets qui n'auraient jamais du être acceptés. Ça explique pourquoi l'office Australien a accepté, le 2 août 2001, le brevet AU2001100012 pour un Circular transportation facilitation device qui n'est autre que la roue.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Erreur de cible
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Or, how suspending Russian accounts deleted project history and pull requests. Évalué à 2.
Il va falloir de plus grandes tranchées.
La connaissance libre : https://zestedesavoir.com