Pour trouver un système mieux fait, il faudrait regarder du côté d'Android où le runtime "java made in google" est vraiment partagé par toutes les applis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.
La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.
La maintenance à long terme demande:
d'avoir des libs à jour et qui fonctionnent ;
un seul système de build (et pas un par distrib).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Pour montrer que flatpak ne consomme pas trop de runtime et de disque, l'auteur explique que sur sa machine il a seulement 18 runtimes pour un total de 8.7 GB.
Le runtime Java, que beaucoup considèrent comme bloated, embarqué dans Newton Adventure fait 51 mo. Dans 8.7 GB, on pourrait ainsi avoir presque 175 versions du JRE non dédupliqués…
En voulant démonter la critique initiale de Flatpak, il montre au contraire que c'est bien bien bien bloated :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
C'est que font les brouteurs web :-)
Mais c'est assez bloated. Il faudrait un brouteur jeu !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
des mises à jour fréquentes et obligatoires pour les jeux en ligne ;
le besoin d'un accès "direct mais pas trop" aux piles graphiques, audio et inputs.
Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?
Ce qui s'en rapproche le plus aujourd'hui:
le brouteur avec les API canvas/webgl/webaudio/gamepad : la sécurité est bonne, mais il est difficile de jouer hors ligne ou même de faire des jeux avec des gigots de ressources, les perfs ne sont pas au top ;
libretro : le hors ligne et les gros jeux sont possibles, les perfs sont top, mais il n'y a aucune sécurité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
LDAP est quand même super bloated pour gérer des users { login, password, group } dans 99% des cas (chiffre Dave Newton Institute Of Identity & Access Management).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C'est valable pour les protocoles présumés mieux fait. En l'absence de régulation, les gros ont tout intérêt à la jouer perso (cf XMPP qui s'est fait forker la tronche sans pitié).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mine is better
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Nothing better than C. Évalué à 3.
J'aime bien cet article pour ne plus craindre le grand méchant GC : https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
Une autre approche de la gestion de la mémoire semiautomatique: https://ziglang.org/documentation/master/#Memory
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Arf
Posté par devnewton 🍺 (site web personnel) . En réponse au lien On Flatpak disk usage and deduplication. Évalué à 3. Dernière modification le 26 novembre 2021 à 10:06.
Pour trouver un système mieux fait, il faudrait regarder du côté d'Android où le runtime "java made in google" est vraiment partagé par toutes les applis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
Peut être que l'approche "empaquetage" est mauvaise alors.
En tout cas la conséquence, c'est que tout fini dans /opt ou sur docker…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4.
Sauf jouer sur iPad, faut aimer avoir très mal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 2. Dernière modification le 25 novembre 2021 à 14:15.
Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.
La maintenance à long terme demande:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Developers: Let distros do their job
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Arf
Posté par devnewton 🍺 (site web personnel) . En réponse au lien On Flatpak disk usage and deduplication. Évalué à 10.
Pour montrer que flatpak ne consomme pas trop de runtime et de disque, l'auteur explique que sur sa machine il a seulement 18 runtimes pour un total de 8.7 GB.
Le runtime Java, que beaucoup considèrent comme bloated, embarqué dans Newton Adventure fait 51 mo. Dans 8.7 GB, on pourrait ainsi avoir presque 175 versions du JRE non dédupliqués…
En voulant démonter la critique initiale de Flatpak, il montre au contraire que c'est bien bien bien bloated :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4. Dernière modification le 24 novembre 2021 à 19:11.
C'est que font les brouteurs web :-)
Mais c'est assez bloated. Il faudrait un brouteur jeu !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4. Dernière modification le 24 novembre 2021 à 14:39.
Les consoles sans même un BIOS, ça ne court pas les rues. Peut être la PC Engine et encore uniquement pour les jeux sur hucards?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4.
Faire le test, c'est prendre le risque de se rendre compte que ça bugge :-)
https://linuxfr.org/nodes/118350/comments/1788497
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour les jeux
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
Mais pas Newton Adventure :( Cf https://linuxfr.org/nodes/118350/comments/1788497
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Pour les jeux
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4.
Les jeux ont une problématique spécifique:
Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?
Ce qui s'en rapproche le plus aujourd'hui:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par devnewton 🍺 (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4.
Est-ce que Flatpak est tombé en marche depuis https://linuxfr.org/nodes/118350/comments/1788497 ? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par devnewton 🍺 (site web personnel) . En réponse au journal la rouille et la comtesse. Évalué à 7.
Les gardes fours, c'est pour éviter les voleurs de pizza?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par devnewton 🍺 (site web personnel) . En réponse au journal la rouille et la comtesse. Évalué à 3.
Bof, il faut se préoccuper de la mémoire 42 plus que dans un langage à ramasse miette :-)
Gnii? VM != GC
Pas sûr que Rust soit plus sécurisé que Java :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Config du serveur et des schémas LDAP dans un fichier vs dans le LDAP
Posté par devnewton 🍺 (site web personnel) . En réponse au lien OpenLDAP 2.6 est sorti. Évalué à 3.
Heureusement on a une solution moderne et plus sécurisé: OpenID Connect !
Plus qu'à trouver une implémentation KISS parce qu'Open Identity Platform ou Keycloak sont aussi bien bloated :(
Arg on ne s'en sort jamais !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Config du serveur et des schémas LDAP dans un fichier vs dans le LDAP
Posté par devnewton 🍺 (site web personnel) . En réponse au lien OpenLDAP 2.6 est sorti. Évalué à 2.
LDAP est quand même super bloated pour gérer des users { login, password, group } dans 99% des cas (chiffre Dave Newton Institute Of Identity & Access Management).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: comme pour les messageries instantanées...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Pourquoi Bloctel et les lois contre le démarchage téléphonique ne servent plus à rien. Évalué à 8. Dernière modification le 18 novembre 2021 à 11:48.
Un grand père esclavagiste?
Le mien a laissé une page blanche comme testament, ses héritiers étaient déçus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ce serait d'autant plus mieux bien que ça faciliterait le boulot de la modération des dépêches
Posté par devnewton 🍺 (site web personnel) . En réponse à l’entrée du suivi Héberger les images des news (et éventuellement journal). Évalué à 3 (+0/-0).
Pour les journaux, est-ce qu'il serait possible d'accepter les data uris (avec limitation de taille)?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: img.linuxfr.org
Posté par devnewton 🍺 (site web personnel) . En réponse à l’entrée du suivi Héberger les images des news (et éventuellement journal). Évalué à 3 (+0/-0).
Régulièrement les images disparaissent :( Le cache n'est pas "pour toujours" on dirait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: comme pour les messageries instantanées...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Pourquoi Bloctel et les lois contre le démarchage téléphonique ne servent plus à rien. Évalué à 4. Dernière modification le 18 novembre 2021 à 10:50.
En théorie peut être. En pratique, essayons: comment je t'appelle ou je t'envoie un message via SIP ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Perf
Posté par devnewton 🍺 (site web personnel) . En réponse au journal la rouille et la comtesse. Évalué à 8.
Tu peux lui répondre: oui mais moi avec $lang_qui_compile_vite je travaille vraiment !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: comme pour les messageries instantanées...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Pourquoi Bloctel et les lois contre le démarchage téléphonique ne servent plus à rien. Évalué à 5. Dernière modification le 18 novembre 2021 à 01:58.
C'est valable pour les protocoles présumés mieux fait. En l'absence de régulation, les gros ont tout intérêt à la jouer perso (cf XMPP qui s'est fait forker la tronche sans pitié).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: comme pour les messageries instantanées...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Pourquoi Bloctel et les lois contre le démarchage téléphonique ne servent plus à rien. Évalué à 10. Dernière modification le 17 novembre 2021 à 18:19.
Le contexte est plus important que le mot:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: comme pour les messageries instantanées...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Pourquoi Bloctel et les lois contre le démarchage téléphonique ne servent plus à rien. Évalué à 4.
Mais Ploum va réiventer l'email ! https://ploum.net/the-monstrosity-email-has-become/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.