Sache que je perçois bien l'ironie de ton message, mais moi, ça m'énerve au plus haut point ce gâchis, que je qualifies volontiers de corruption.
Ces mêmes ordures (oui, c'est le bon mot) qui veulent réduire les droits des travailleurs licenciés ou dont le contrat n'a pas été renouvelé, sont 100 fois moins utiles à la sociétés que ceux qu'ils écrasent, et touchent mille fois plus.
Ces parasites ne méritent que mon mépris. Et, vraiment, France-travail, ça me rappelle Vichy. Il suffirait d'ajouter le culte du paternel président, et on a la totale: France, travail, patriarche, ou dit autrement: travail, famille, patrie.
J'ai peur à ma France, celle dont le fronton des mairies continue malgré tout d'afficher des valeurs auxquelles j'adhère… pour combien de temps?
Posté par freem .
En réponse au journal Xz (liblzma) compromis.
Évalué à 10 (+10/-2).
Dernière modification le 30 mars 2024 à 01:33.
particulièrement si vous êtes avec un debian ou dérivée. Debian a une version corrigée "5.6.1+really5.4.5-1", Arch Linux une version 5.6.1-2.
Euh…. non? Pas Debian stable, en tout cas, celle qui est recommandée pour les utilisateurs normaux ou les power users qui ne veulent plus se prendre trop la tête:
Donc, même si j'utilise pas systemd, et que je considère ce truc over-engineered, non, c'est faux, il n'est pas affecté, au moins dans la lib 0.
Ensuite, de toute façon:
i A --\ xz-utils
[...]
--\ Dépend (2)
--- libc6 (>= 2.34)
--\ liblzma5 (>= 5.4.0)
i A 5.4.1-0.2
Alors, si le sujet était Debian testing ou Debian unstable, merci de le préciser. Parce que je suis prêt à parier une tournée dans mon pub préféré que la majorité des debianneux utilisent la stable. Justement pour éviter ce genre de problèmes, en fait.
Ceci dit, merci pour l'info, ça me conforte… dans mon choix de ne pas utiliser de distro bleeding edge. Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)
Ceci dit, je suis surpris que Debian ne construise pas ses paquets à partir du repo, justement, je trouve ça très surprenant, compte tenu du fait que de nombreux paquets ont leurs propres patchs, que ce soit pour dé-veroller (chromium, et plein d'autres qui téléphonnent à la maison) ou pour améliorer l'intégration.
Le lien fournit par la réponse au sujet d'Ubuntu confirme d'ailleurs mon intuition première: Debian Unstable. C'est la porte d'entrée, hein, les trucs la dedans ne sont pas considérés fiables, et cette histoire montre pourquoi, du coup.
Ca ne serait acceptable pour moi que si et seulement si ça inclue un accès gratuit pour les citoyens a la version limitée/lente, un peu dans le modèle des autoroutes vs routes.
Et bien sûr, la limitation doit ne jamais s'appliquer aux sites gouvernementaux ou permettant l'accès aux comptes bancaires, entres autres éléments critiques.
Maintenant, pour implémenter ça, bonne chance, quand on voit le niveau de connerie naturelle qui est habituellement déployé par les politiciens français en matière de technologie… Parce que hein, ils ont pas fait les grandes écoles pour rien, ces gens la.
Il faut dire aussi que la religion chrétienne n'est pas super amatrice de la sexualité avec le fondement. Pourtant, ça éviterais l'usage de préservative, eux aussi pas très catholiques selon certains intégristes.
Je faisais ça… quand j'étais au lycées, parce que je n'avais pas d'ordi portable (et puis ça serait sûrement pas passé à l'époque).
Ca se fait, c'est sûr, mais c'est pénible. Par contre il y a une étape qui se fait très bien sur papier, et je dirais même mieux que sur PC: les divers diagrammes qui décrivent les grosses lignes de l'architecture. Peut-être qu'il existe des logiciels vachement adaptés pour ça, mais j'ai pas encore trouvé perso. J'ai bien testé bouml, dia ou même des scripts basés sur graphviz (c'est ce qui marche le mieux pour moi en logiciels, jusqu'a présent, et c'est pratique a versionner) mais rien à faire: une feuille, un gomme, un critérium, ça marche juste mieux.
C’est vraiment mon avis de béotien en développement logiciel que je donne là mais je trouve dommage de fermer le développement par principe. Je veux dire, c’est pas parce que tu acceptes les contributions que tu t’engages à toutes les considérer, à t’investir pour chacune.
Perso, je pense qu'il vaut mieux que les projets soient clairs sur leur politique de ce point de vue, justement pour éviter:
Alors c’est sûr qu’à un moment les contributeurs vont se dire : « Mais qu’il aille bien se faire foutre ce projet si on se casse le cul, qu’on propose des patches, et qu’on a même pas une réponse ! »
Si le projet est clair sur la politique et les objectifs, moins de frustration pour ceux qui s'en servent et ont besoin de le modifier.
La seule raison que je vois de, typiquement, garder privé les rapports de bug, c’est chercher à les dérober à la vue des utilisateurs potentiels.
Pour moi, les contributions de patch et de rapport de bug sont très, très différentes. Un rapport de bug, bien que déjà utile (enfin, ça dépend, on voit nombre de rapports de "bug" sur github ou le rapporteur a juste la flemme de lire la doc… et ne parlons pas des feature requests complètement à l'ouest…), ce n'est qu'une description d'un comportement erroné. C'est relativement rapide a faire, comparé à un patch.
La bibliothèque Fortran ForColormap permet de convertir une valeur réelle en valeurs RVB que vous pouvez utiliser avec n’importe quelle bibliothèque graphique
Donc, ça s'adresse aux développeurs fortrans qui font des applications graphiques. De cette ligne, je suppose que fortran utilise un système de couleurs propre, voire en propose plusieurs. Cet outil semble fait pour pouvoir intégrer ces divers systèmes à l'usage de gtk ou qt.
J'ai bon? (je n'ai lu que la 1ère page et je ne connais pas fortran)
Y'en a effectivement mais c'est tellement specifique au web qu'il y a pleins de logiciels qui ne le supporte pas
La question de la capacité des dev a faire la maintenance se pose, alors, parce que bon… soit on intègre tous les formats un par un, à la main, et la ça pique le coût de maintenance, forcément.
Ou alors on réfléchit 2s, et on utilise une lib dont c'est le job. Il y en existe quelques unes, moi j'en connais 2:
libimlib2 utilisée par un tas de visualiseur d'images, justement;
libfreeimage2 que j'ai découverte récemment grâce a TrenchBroom;
Je ne sais pas si le format JXL est supporté par elles, mais ça semblerait un bon point de pénétration, d'autant que FreeImage2 supporte un mécanisme de plugins.
En fait, webp n'est spécifique au web que dans les esprits, pour moi.
Quelle serait la raison pour que ça soit spécifique?
Qu'on me dise que DDS est spécifique aux jeux vidéo, ça, ok, c'est littéralement conçu de manière a ce que ça soit sous-optimal pour des applications graphiques qui n'ont pas autant de besoins d'upload vers la mémoire graphique (ça serait trop gros, c'est optimisé non pas pour l'espace mais pour être géré par les GPU a un coût minimal).
De fait, il y la même chose supposée ici. Enfin, on y pose la question, on n'y affirme rien, ce qui est légèrement différent du cas auquel ce message répond.
Ma fois, ce n'est pas nouveau que leur site est merdique, et je doute qu'en moyenne leur infra soit tellement mieux (la dernière fois que j'ai eu un rdv avec l'un des employés, j'ai eu un sacré ressenti que je ne voudrais pas savoir, de peur d'en avoir des cauchemars, on sentait la qualitay exsuder).
S'ils mettaient plus d'argent dans la technique et, soyons fous, le service lui-même au lieu de renommer (pour un nom qui m'évoque le régime de Pétain en plus… travaille, famille, patrie…) peut-être que ça ne serait pas arrivé, ou au moins avec des conséquences moins volumineuses.
Ah tiens, sur leur site:
Suite à une cyberattaque dont nous avons été victimes avec Cap emploi, des informations personnelles vous concernant sont susceptibles d'être divulguées. Vos informations bancaires ne sont pas concernées. Nous sommes désolés de cet incident et nous vous invitons à rester vigilants.
Donc, ça serait lié à un de leurs partenaires, en plus? Intéressant, je me demande combien des millions de victimes ont accepté que leurs données soient transmises à un partenaire commercial? (il va falloir que je lise plus en détail cette histoire)
Je pense que j'ai mal exprimé un truc. Si j'ai pris le temps de répondre, c'est déjà que je trouve la chose intéressante (j'ai pertinenté le lien de mémoire, mais je ne peux que prouver avoir voté).
Pour moi, ce site a un gros bon point: il inclue pas mal de vulgarisation sur un sujet qui semble peu connu globalement. Par exemple, pour goap, qui est je pense une avancée majeure (de 20 ans d'âge), je ne l'ai vu implémenté dans aucun jeu libre dont j'aie lu le code pour l'instant (plusieurs FPS, quelques jeux de stratégie).
Le "bof" que j'aurai clairement du lire, et relire au moins 7 fois, est… oui, je pense: mesquin.
Forcément, un titre pareil ne donne pas envie d'être poli.
Je te demande pardon.
La raison c'est que je ne voulais aucune dépendance
Mais la STL est une dépendance, régulièrement non appréciée pour diverses raisons plus ou moins valides (temps de compilation, taille du binaire notamment liée à l'obligation de supporter les exceptions ou de se passer totalement de mécanismes d'erreur, debug pénible à cause des 150 couches de template, etc)
Oui, parce que l'inférence de type c'est bien.
Discutable pour moi, mais bon.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
Vu que je suis en train de bosser sur un outil pour gpgoap, justement, ça serait envisageable.
Pour les autres je vais avoir la flemme par contre, d'autant que behaviortree.cpp dispose déjà d'un tel outil.
J'ai envie de dire, prends donc un fichier avec plein de contrastes abruptes et d'autres nuancés, prends le raw, convertis le dans les divers fichiers et testes.
A la fois webp, qui me scotche déjà, et à priori JXL ont un mode de compaction lossless, avec, justement, 0 perte de donnée. Dans ce mode, ils marchent mieux en moyenne que le traditionnel jpeg, déjà.
…l'engouement de JPEG-XL. On a déjà pas mal de formats d'images modernes. Qu'apporte-t-il ?
Il apporte une meilleure volumétrie, ce qui veut dire dire moins de données à transférer via le réseau ou a stocker sur disque.
Ainsi qu'une meilleure parallélisation, ce qui veut dire que tu peux charger ou compresser plus vite. C'est utile pour un jeu par exemple, dont chaque texture est souvent un assemblage de plusieurs images, mais pour faire du montage photo, ça doit être agréable aussi d'aller plus vite.
Sans avoir de pertes supplémentaires, voire en en ayant moins.
Récemment, j'ai recompacté la totalité des cartes portées (par quelqu'un d'autre, et dont je dispose) de tremulous vers unvanquished (des jeux libres) pour l'expérience, et le gain de volume en convertissant des images vers webp, une fois tout recompacté, à été de l'ordre de 20%.
Les cartes en question on été portées à la main, sans chercher a les optimiser (ce n'est pas moi, mais je connais la personne), du coup les images originelles ont été conservée dans leur format initial, et compresser juste les tga, utilisés pour les textures, m'a fait gagner 10% de place, une fois repackagé.
Les 10% restants sont des fichiers qui ne sont plus nécessaires au fonctionnement des serveurs d'unv, qui devaient auparavant être fournis au client malgré tout.
A l'heure actuelle, mon dossier "pakpath" qui stocke les données venue du net pèse 3 giga. 20% de 3 gigs, c'est pas rien, c'est un quasi-CD-rom, et je parle de webp, à priori JXL fait mieux que webp)
Alors, je comprend que, du point de vue de l'utilisateur qui a 3 ou 4 milliers de photos, on s'en fout. Mais du point de vue de ceux qui bossent avec l'outil informatique ou l'utilise pour autre chose que les photos de vacance, ça peut vite être significatif. Je veux dire zut, le gain de compression entre png "naïf" et webp est, en pratique, d'environ 10% sur mon cas d'usage, et JXL ferais mieux en moyenne?
Pour moi, cette lib n'a que peu d'intérêt, parce que:
C++20 obligatoire. Pas mal de codebases n'autorisent pas C++20 (pour différentes raisons. Par exemple, daemon-engine est limité à C++14 par la dépendance a google NaCl, mais on peu aussi citer recast-navigation qui se limite
a C++11, pour leurs propres raisons).
STL utilisée, et pour de mauvaises raisons en plus. La STL, c'est gros, c'est lent à compiler, c'est chiant a debugguer, le contrôle sur la mémoire est pénible. Certains par exemple y préférerons EASTL.
la maintenance va être compliquée. Ce code utilise auto pour tout et n'importe quoi. Il y a des shared_ptr qui devraient vraiment être des unique_ptr, également.
aucun outil. C'est bien d'avoir les briques de base, mais debugguer une IA n'est pas simple. Tant qu'a avoir des dépendances sur la STL, un outil pour charger les données depuis un stockage externe n'aurais pas été de trop. Ces données pouvant ensuite être chargées dans un programme permettant une visualisation, par exemple.
Bref, je n'ai pas en tête de lib pour remplacer tout, notamment utility et les FSM, mais à choisir: GPGOAP ou behaviortree.cpp qui dispose aussi, de mémoire, d'un outil visuel pour manipuler les BT, me semblent mieux indiqués.
A noter que je n'ai pas analysé le code de behaviortree.cpp, mais celui de GPGOAP, si.
Bien que GPGOAP ait la limitation de représenter un "worldstate" sur 64 bits seulement, en réalité 64 états c'est beaucoup.
Augmenter la taille serait simple, il suffirait d'utiliser un long double, par exemple (128 bits).
Sinon, normalement le code des IAs de F.E.A.R. est disponible, par l'auteur du concept même de goap.
Pour ce qui est des outils avec GPGOAP, il est très simple de construire un pseudo fichier de conf qui soit convertible aisément en langage dot (graphviz) pour générer un graph des actions. La lib fournit également des outils pour aider le debug.
Puis pourquoi deb? Pour moi c'est le pire système de packaging qui soit
il serait intéressant de savoir pourquoi.
Parce que perso, et il n'y a pas que moi qui le pense, le format .deb est plutôt bien ficelé, contrairement à, disons, rpm, si j'en crois l'auteur de mon lien.
Et de mon point de vue de développeur, le format .deb et les possibilités qu'il a sont complets malgré une très élégante simplicité. Je regrette juste les script pre/post-inst/rm, mais je vois pas comment faire pour automatiquement mettre à jour le menu de boot, par exemple, lors d'une install/MàJ.
Posté par freem .
En réponse au journal Ma version rêvée de Debian.
Évalué à 2.
Dernière modification le 04 janvier 2024 à 01:29.
Non, ça n'est pas logique. Enfin, si, mais pas tout le temps, et pas ici.
La gestion des dépendances, qui vérifie la stabilité du bouzin, elle est faite par dpkg, peu importe l'outil que tu utilises.
En fait, c'est dpkg qui fait tout le sale boulot, et c'est pour ça qu'il y a eu quelques coups de gueule pour la migration usr-merge, justement (je laisserai le lecteur intéressé faire ses recherches, possible même qu'on en ait parlé ici, je ne zone plus trop sur linuxfr, moi).
Ce qui va changer, et c'est le seul élément qui me vienne à l'esprit, c'est qu'apt-get ne sait pas se souvenir qu'un paquet à été installé automatiquement ou manuellement, donc pour le ménage, il faut utiliser debfoster, de mémoire.
En tout cas, la dernière que j'ai farfouillé dans /var/lib/apt.*, c'était le seul point que j'aie vu.
(ça ne m’étonnerait pas que ça fasse quinze ans) mais certaines accusations ont la vie dure…
Tout à fait. Mais ça ne m'empêchera pas de répéter régulièrement qu'elles sont fausses, quand je sais de première main que c'est le cas.
A ceci près que l'immense avantage d'une mailing list sur github ou gitlab, c'est que l'on n'est pas forcé d'aller voir dans sa boîte mail pour choper un code quotidien afin de se connecter.
En fait, j'en ai eu tellement marre de ça récemment que j'ai supprimé mon compte. Je ne peux plus contribuer? Pas si grave, en vrai, ce que je ne peux plus faire, c'est rapporter des bugs ou faire des push request, je suis toujours capable, bien entendu, de faire le code, et je peux même upload sur des forges saines d'esprit si besoin est.
J'ai d'ailleurs appris ainsi que github remplace les identités supprimées par "ghost", et je soupçonne qu'ils conservent des stats, puisque le compte de ghost a des "badges" qui sont peut-être proche de ceux que j'avais. Bon, je l'avoue: je m'en contre-fout des badges. J'aurai préféré à la place qu'ils implémentent des fonctionnalités utiles… je sais pas, moi, par exemple un truc pour m'identifier via ma clé ssh publique, sans me pourrir ma boîte mail, par exemple?
J'ai vu au moins un projet qui s'est barré de github pour la même raison, le mainteneur en a eu marre de cette connerie de "double authentification" forcée.
Comme quoi, tout le monde ne suit pas le mouvement. Par contre, le mainteneur à malheureusement préféré savannah, qui est la forge la plus pourrie que je connaisse. Oui, j'ai essayé, j'y avais même un compte, fut un temps.
Ceci dit, il n'a manifestement jamais montré le bout de son nez, et sa soumission a été rejetée. Parce que tout projet qui y va doit être libre, et donc les licences sont vérifiées. En soit, c'est plutôt bon, mais perso, lire un truc comme ça:
3) The following files are missing a copyright notice:
credits.md
quick-start.sh
README.md
release_notes.md
cat6/README.md
labs/README.md
man6/README.md
sounds/README.md
ca me ferait juste fuir de n'importe quelle forge. Mettre le copyright sur le readme, franchement… bref, je suis très bien sur codeberg, moi.
Ou alors on peut se souvenir qu'en théorie, la rubrique "liens" devrais respecter la ligne éditoriale?
La rubrique « liens » est destinée à recevoir les euh… liens vers des contenus en rapport avec la ligne éditoriale de LinuxFr.org.
A ma connaissance, la politique en dehors des problématique de propriété intellectuelle n'en fais pas partie. Mais bon, peu importe (j'ai pas votéW noté de toute façon).
Posté par freem .
En réponse au journal Ma version rêvée de Debian.
Évalué à 4.
Dernière modification le 12 décembre 2023 à 22:14.
Je crois me souvenir d'une époque où l'on disait qu'il ne fallait pas installer un truc avec aptitude si tu en avais installé d'autres avec apt ou apt-get (souvenir flou) et je n'ai jamais vraiment compris la logique.
Oula, c'est vieux, ça!
Personnellement, depuis que j'utilise debian (environ 15 ans) j'ai toujours mixé aptitude et apt (anciennement apt-get) pour faire les choses, et je n'ai jamais eu le moindre problème. Pas un seul. J'insiste. Lourdement. Parce que c'est vrai!
Ceci dit, j'utilise majoritairement aptitude, qui est incomparable. C'est d'ailleurs l'outil qui m'empêche de bouger de debian, parce qu'avoir une interface ncurses pour installer des paquets, c'est juste logique: c'est utilisable via ssh, et c'est plus efficace qu'enchaîner des commandes.
Ouais je sais que je renforce le mème "BTW I use Arch" mais franchement sa réputation de complexité est exagérée, je la trouve finalement plus simple à maintenir qu'une Debian ! KISS.
Bon, qui se dévoue pour faire un vrai site de comparaison? Pas moi en tout cas, j'ai trop la flemme :D (y compris pour déterminer ce qu'il faut comparer et comment)
il faut bien avouer que Hadley Wickham a tendance à devenir le Lennart Poetterirng de R.
ben, du coup, il faudrait plutôt mettre son travail par défaut sur toutes les distro, non?
Mais bon sérieux… ce pauvre Lennart n'a fait que filer le source des logiciels qu'il utilise ou écrit pour une boîte, je trouve ça méchamment dégueulasse de le considérer comme un type qui planifie la fin du libre ou je ne sais quelles autres âneries.
Je n'utilise pas son travail (systemd, pulseaudio, etc) pour des raisons à moi, mais je lui suis redevable parce qu'il augmente l'intérêt économique de linux, ce qui crée un petit effet boule de neige, et est donc en ma faveur.
C’est une force incroyable (et qui se basse sur le travail des centaines de packageurs Debian).
Juste des centaines? Mince, vu le boulot, j'aurais imaginé des milliers moi…
Le contre-coup de cela c’est que si un logiciel, aussi populaire soit-il, n’intéresse aucune développeur Debian, alors il ne sera pas dans Debian. Ça arrive assez régulièrement. Y’a pas ce problème avec AUR
Ben, debian est assez centralisée je pense, c'est une belle (magnifique, même) cathédrale libre.
Par contre, il est aussi à noter, je crois, qu'il est possible de publier des dépôts debian pour ses propres paquets, c'est ce que faisais Opera (jusqu’à la 12, je sais pas après), ce que fait nvidia, et ce que fait vivaldi, ce que fait wine!
Dans le cas de vivaldi et opera, franchement, ils pourraient juste éjecter FF et chromium de debian, vu que "le web" et "stabilité" sont antinomique mais bon, avoir des utilisateurs est aussi important pour changer le monde.
On pourrait me dire que tous ces paquets (sauf wine) sont non-libre, mais bon, debian à une section pour le non-libre de toute façon (autrement dit, pas de zélotes, jalous, zélés. C'est l'origine du mot zélote apparemment.)
Je ne connais pas les process d'arch, alors je ne peux pas juger entièrement, mais dans l'ensemble, arch me semble plus orientée travail communautaire que Debian, qui est plutôt du genre a encourager le travail rigoureux et long (ce qui en fait une distro fiable sur le long terme, donc pour construire un système informatique pérenne). Je pense que arch est pertinente pour les gens qui aiment la tech, et encore, juste une portion d'eux (je me considère comme aimant la tech, mais pas arch :))
PS: le correcteur orthographique sur vivaldi est vraiment pourri. Mais bon, linuxfr a le sien, ça aide, multiplier les couches est une bonne solution pour éviter les bugs… sauf quand ça les encourage. Bref, j'en sais rien.
Étonnamment, les gens refusent de le faire mais vont ailleurs et ne font que ça…
Le problème, c'est que modifier un paquet Debian requiert une chiée de paquets à installer (debuild & consort) et le process est loin d'être simple.
Moi-même, j'ai plusieurs paquets recompilés pour exclure des dépendances stupides fonctionnalités que je n'utilise pas, genre dbus, systemd, wayland, et j'en oublie.
Le résultat final est un système allégé de plusieurs pourcents de paquets, et donc, il est plus simple de lire les release notes, vu qu'il y en a moins.
Non, je n'ai rien contre wayland, dont l'architecture me semble plus sensée que celle de Xorg, mais ça n'empêche pas que j'utilise Xorg parce que:
1. ça juste marche;
2. j'y ai tous les logiciels dont j'ai besoin;
3. il y a de la doc;
4. il y a de vraies lib de dev officielles, contrairement à wayland qui génère des trucs basés sur un fichier xml, et quand j'avais regardé, le résultat était plutôt… disons juste que, moi, j'aurai honte de produire ça.
Par contre, l'architecture logicielle de wayland, du peu que j'en sais, me semble largement meilleure que celle de Xorg (et ce défaut me semble être un défaut d'implémentation, pas de standard) vu qu'elle respecte la séparation des privilèges.
Bref, je sujet, c'est la recompilation de paquets debian pour soi-même, et clairement sur ce point, Debian est franchement pourrie.
Entre la chiée d'outils dont on n'est jamais sûr lesquels sont vraiment utiles, ou quel est leur rôle, la fâcheuse habitude de tout activer par défaut (y compris dbus sur sdl, qui était désactivé par défaut upstream je crois, et qui a généré d'énormes problèmes de performances. Bon, d'un autre côté, il faut ne pas regarder de trop près le code pour avoir confiance en la SDL…), les dépendances de ces outils qui semblent au final tirer tout ce qui existe dans debian (mettons du perl, du python, du autotools, et 2-3 autres tech, histoire que ça soit une grosse galère à gérer, c'est plus fun!).
Le processus pour compiler un paquet custom pour soi-même est également pollué par toutes les règles de Debian dont l'objectif est de partager des paquets de qualité.
La réalité, c'est qu'il est 20 fois plus simple d'écrire un script qui génère un paquet binaire à partir de l'exécutable qu'un paquet source. Il serait bon que cet élément soit clairement affiché quelque part, et moins découragé (sauf que bien sûr, le but de Debian est de partager les efforts, et d'avoir un maximum de logiciels libre, donc faire apparaître comme compliqué la création d'un dépôt Debian avec des paquets non source me semble pas déconnant comme stratégie, sauf que ça impacte aussi les logiciels libres moins connus).
J'ai personnellement écrit un script qui génère des paquets .deb pour une boîte dans le passé (donc, on compilait, puis on lançait cet outil pour générer un .deb, que l'on pouvais ensuite répartir et installer sur les systèmes distants), à partir d'une recette minimaliste et des binaires. A cause du faible niveau d'expertise de mes collègues, j'ai du lui donner une interface simple, et une documentation qui tienne la route, sur plusieurs degrés (utilisateur et mainteneur, concrètement, je savais sûrement que je n'allais pas passer ma vie a bosser pour cet empaffé).
Comparé à ça, tous les systèmes de paquets me semblent franchement complexes, et c'est normal: ils gèrent bien plus de cas! C'est incomparable, gérer un parc de moins de 300 machines produites par nous et réparties aléatoirement sur le territoire français ou gérer un parc de plusieurs millions de machines dont aucune n'est identique?
Bon, ok, donc, les paquets source c'est compliqué, très bien, et ça sera jamais simple de toute façon (entre la quantité de langages de prog et de compilos pour chacun…), mais j'aimerai que Debian fournisse un paquet qui permette de construire des paquets binaires sans se prendre autant la tête.
Au fond, ce n'est pas si compliqué, un paquet binaire: il faut juste définir quels paquets doivent être installés, les scripts d'installation et de suppression, que je considère comme étant plutôt une erreur d'architecture logicielle de Debian (leur rôle est surtout d'activer le démarrage automatique des services, désolé, mais je m'en passerai bien) et tout fonctionne assez simplement.
Concrètement, un .deb, c'est une tarball qui contiens 3 fichiers:
un fichier qui décrit la version du format
une archive qui contiens les données à installer
une archive qui contiens les méta-données, c'est à dire la description du paquet (ou sa traduction), la place requise, les dépendances, etc.
Pour le point 2, il me paraît utile de préciser que cette archive ne contiens qu'un seul fichier qui a besoin d'être écrit par l'utilisateur, et le format est dérivé du stockage des mails, donc, c'est du du texte pur, très simple à manipuler, il est possible (je l'ai fait) de se bricoler des scripts awk qui gèrent ça très facilement (je ne sais pas garder d'info d'une ligne à l'autre via sed).
Merde, j'ai encore écrit un pavé qui n'intéressera pas grand monde… Désolé pour ça (en admettant que des gens lisent ça)
Et c’est bien là tout le problème : ce ne sont pas plus les clients ou les employés d’Elon MUSK qui choisissent ce que Tesla va produire. C’est Elon Musk.
Ben tiens. Et il sert à quoi le service marketing alors? Les commerciaux, ces gens qui vendent du rêve et dont le travail consiste à créer le besoin, et qui déclenchent ensuite la R&D pour y répondre, ils ne sont pas salariés?
Et les ingés de la R&D, ils ont le pistolet sur la tempe peut-être?
Pour ce qui est des consommateurs, désolé mais si, ils ont demandé, après un éventuel bourrage de crâne soit par le marketing, soit par leur cercle de connaissances, à avoir un truc qui impressionne.
Le tort est partagé, très clairement, et je doute qu'il y aurait production de masse s'il n'y avait pas achat.
Mr. Musk ne peut pas être derrière chacun de ses employés, dans le meilleur des cas il peut juste donner les grandes lignes.
[^] # Re: trop occupés à changer de nom et de logo je suppose
Posté par freem . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 3 (+3/-2). Dernière modification le 30 mars 2024 à 01:38.
Sache que je perçois bien l'ironie de ton message, mais moi, ça m'énerve au plus haut point ce gâchis, que je qualifies volontiers de corruption.
Ces mêmes ordures (oui, c'est le bon mot) qui veulent réduire les droits des travailleurs licenciés ou dont le contrat n'a pas été renouvelé, sont 100 fois moins utiles à la sociétés que ceux qu'ils écrasent, et touchent mille fois plus.
Ces parasites ne méritent que mon mépris. Et, vraiment, France-travail, ça me rappelle Vichy. Il suffirait d'ajouter le culte du paternel président, et on a la totale: France, travail, patriarche, ou dit autrement: travail, famille, patrie.
J'ai peur à ma France, celle dont le fronton des mairies continue malgré tout d'afficher des valeurs auxquelles j'adhère… pour combien de temps?
# Debian?!?
Posté par freem . En réponse au journal Xz (liblzma) compromis. Évalué à 10 (+10/-2). Dernière modification le 30 mars 2024 à 01:33.
Euh…. non? Pas Debian stable, en tout cas, celle qui est recommandée pour les utilisateurs normaux ou les power users qui ne veulent plus se prendre trop la tête:
Donc, même si j'utilise pas systemd, et que je considère ce truc over-engineered, non, c'est faux, il n'est pas affecté, au moins dans la lib 0.
Ensuite, de toute façon:
Alors, si le sujet était Debian testing ou Debian unstable, merci de le préciser. Parce que je suis prêt à parier une tournée dans mon pub préféré que la majorité des debianneux utilisent la stable. Justement pour éviter ce genre de problèmes, en fait.
Ceci dit, merci pour l'info, ça me conforte… dans mon choix de ne pas utiliser de distro bleeding edge. Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)
Ceci dit, je suis surpris que Debian ne construise pas ses paquets à partir du repo, justement, je trouve ça très surprenant, compte tenu du fait que de nombreux paquets ont leurs propres patchs, que ce soit pour dé-veroller (chromium, et plein d'autres qui téléphonnent à la maison) ou pour améliorer l'intégration.
Le lien fournit par la réponse au sujet d'Ubuntu confirme d'ailleurs mon intuition première: Debian Unstable. C'est la porte d'entrée, hein, les trucs la dedans ne sont pas considérés fiables, et cette histoire montre pourquoi, du coup.
[^] # Re: Magré toutes ces âneries, il y a du vrai
Posté par freem . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 2 (+0/-0).
Ca ne serait acceptable pour moi que si et seulement si ça inclue un accès gratuit pour les citoyens a la version limitée/lente, un peu dans le modèle des autoroutes vs routes.
Et bien sûr, la limitation doit ne jamais s'appliquer aux sites gouvernementaux ou permettant l'accès aux comptes bancaires, entres autres éléments critiques.
Maintenant, pour implémenter ça, bonne chance, quand on voit le niveau de connerie naturelle qui est habituellement déployé par les politiciens français en matière de technologie… Parce que hein, ils ont pas fait les grandes écoles pour rien, ces gens la.
[^] # Re: Vatican II
Posté par freem . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 2 (+0/-0).
Il faut dire aussi que la religion chrétienne n'est pas super amatrice de la sexualité avec le fondement. Pourtant, ça éviterais l'usage de préservative, eux aussi pas très catholiques selon certains intégristes.
[^] # Re: Code sur papier
Posté par freem . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 3 (+1/-0).
Je faisais ça… quand j'étais au lycées, parce que je n'avais pas d'ordi portable (et puis ça serait sûrement pas passé à l'époque).
Ca se fait, c'est sûr, mais c'est pénible. Par contre il y a une étape qui se fait très bien sur papier, et je dirais même mieux que sur PC: les divers diagrammes qui décrivent les grosses lignes de l'architecture. Peut-être qu'il existe des logiciels vachement adaptés pour ça, mais j'ai pas encore trouvé perso. J'ai bien testé bouml, dia ou même des scripts basés sur graphviz (c'est ce qui marche le mieux pour moi en logiciels, jusqu'a présent, et c'est pratique a versionner) mais rien à faire: une feuille, un gomme, un critérium, ça marche juste mieux.
[^] # Re: Wut?
Posté par freem . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 2 (+0/-0).
Perso, je pense qu'il vaut mieux que les projets soient clairs sur leur politique de ce point de vue, justement pour éviter:
Si le projet est clair sur la politique et les objectifs, moins de frustration pour ceux qui s'en servent et ont besoin de le modifier.
Pour moi, les contributions de patch et de rapport de bug sont très, très différentes. Un rapport de bug, bien que déjà utile (enfin, ça dépend, on voit nombre de rapports de "bug" sur github ou le rapporteur a juste la flemme de lire la doc… et ne parlons pas des feature requests complètement à l'ouest…), ce n'est qu'une description d'un comportement erroné. C'est relativement rapide a faire, comparé à un patch.
[^] # Re: Si l'auteur connu pour sa modestie pouvait nous en dire plus...
Posté par freem . En réponse au lien ForColormap 0.9 est sorti. Évalué à 2 (+0/-0).
Donc, ça s'adresse aux développeurs fortrans qui font des applications graphiques. De cette ligne, je suppose que fortran utilise un système de couleurs propre, voire en propose plusieurs. Cet outil semble fait pour pouvoir intégrer ces divers systèmes à l'usage de gtk ou qt.
J'ai bon? (je n'ai lu que la 1ère page et je ne connais pas fortran)
[^] # Re: L'avis de Google...
Posté par freem . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 3 (+1/-0).
La question de la capacité des dev a faire la maintenance se pose, alors, parce que bon… soit on intègre tous les formats un par un, à la main, et la ça pique le coût de maintenance, forcément.
Ou alors on réfléchit 2s, et on utilise une lib dont c'est le job. Il y en existe quelques unes, moi j'en connais 2:
Je ne sais pas si le format JXL est supporté par elles, mais ça semblerait un bon point de pénétration, d'autant que FreeImage2 supporte un mécanisme de plugins.
En fait, webp n'est spécifique au web que dans les esprits, pour moi.
Quelle serait la raison pour que ça soit spécifique?
Qu'on me dise que DDS est spécifique aux jeux vidéo, ça, ok, c'est littéralement conçu de manière a ce que ça soit sous-optimal pour des applications graphiques qui n'ont pas autant de besoins d'upload vers la mémoire graphique (ça serait trop gros, c'est optimisé non pas pour l'espace mais pour être géré par les GPU a un coût minimal).
De fait, il y la même chose supposée ici. Enfin, on y pose la question, on n'y affirme rien, ce qui est légèrement différent du cas auquel ce message répond.
# trop occupés à changer de nom et de logo je suppose
Posté par freem . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 4 (+3/-1). Dernière modification le 14 mars 2024 à 15:50.
Ma fois, ce n'est pas nouveau que leur site est merdique, et je doute qu'en moyenne leur infra soit tellement mieux (la dernière fois que j'ai eu un rdv avec l'un des employés, j'ai eu un sacré ressenti que je ne voudrais pas savoir, de peur d'en avoir des cauchemars, on sentait la qualitay exsuder).
S'ils mettaient plus d'argent dans la technique et, soyons fous, le service lui-même au lieu de renommer (pour un nom qui m'évoque le régime de Pétain en plus… travaille, famille, patrie…) peut-être que ça ne serait pas arrivé, ou au moins avec des conséquences moins volumineuses.
Ah tiens, sur leur site:
Donc, ça serait lié à un de leurs partenaires, en plus? Intéressant, je me demande combien des millions de victimes ont accepté que leurs données soient transmises à un partenaire commercial? (il va falloir que je lise plus en détail cette histoire)
[^] # Re: La question que je me pose...
Posté par freem . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 3 (+1/-0).
Non, parce que les numéros de sécu ne sont pas uniques, les collisions sont plus que possibles.
[^] # Re: Bof
Posté par freem . En réponse au lien AI Toolkit, donnez un cerveau à vos NPCs, une librairie C++ header-only. Évalué à 2. Dernière modification le 03 mars 2024 à 17:59.
Je pense que j'ai mal exprimé un truc. Si j'ai pris le temps de répondre, c'est déjà que je trouve la chose intéressante (j'ai pertinenté le lien de mémoire, mais je ne peux que prouver avoir voté).
Pour moi, ce site a un gros bon point: il inclue pas mal de vulgarisation sur un sujet qui semble peu connu globalement. Par exemple, pour goap, qui est je pense une avancée majeure (de 20 ans d'âge), je ne l'ai vu implémenté dans aucun jeu libre dont j'aie lu le code pour l'instant (plusieurs FPS, quelques jeux de stratégie).
Le "bof" que j'aurai clairement du lire, et relire au moins 7 fois, est… oui, je pense: mesquin.
Forcément, un titre pareil ne donne pas envie d'être poli.
Je te demande pardon.
Mais la STL est une dépendance, régulièrement non appréciée pour diverses raisons plus ou moins valides (temps de compilation, taille du binaire notamment liée à l'obligation de supporter les exceptions ou de se passer totalement de mécanismes d'erreur, debug pénible à cause des 150 couches de template, etc)
Discutable pour moi, mais bon.
Vu que je suis en train de bosser sur un outil pour gpgoap, justement, ça serait envisageable.
Pour les autres je vais avoir la flemme par contre, d'autant que behaviortree.cpp dispose déjà d'un tel outil.
[^] # Re: Je ne comprends pas...
Posté par freem . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 5 (+3/-0).
J'ai envie de dire, prends donc un fichier avec plein de contrastes abruptes et d'autres nuancés, prends le raw, convertis le dans les divers fichiers et testes.
A la fois webp, qui me scotche déjà, et à priori JXL ont un mode de compaction lossless, avec, justement, 0 perte de donnée. Dans ce mode, ils marchent mieux en moyenne que le traditionnel jpeg, déjà.
[^] # Re: Je ne comprends pas...
Posté par freem . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0).
Il apporte une meilleure volumétrie, ce qui veut dire dire moins de données à transférer via le réseau ou a stocker sur disque.
Ainsi qu'une meilleure parallélisation, ce qui veut dire que tu peux charger ou compresser plus vite. C'est utile pour un jeu par exemple, dont chaque texture est souvent un assemblage de plusieurs images, mais pour faire du montage photo, ça doit être agréable aussi d'aller plus vite.
Sans avoir de pertes supplémentaires, voire en en ayant moins.
Récemment, j'ai recompacté la totalité des cartes portées (par quelqu'un d'autre, et dont je dispose) de tremulous vers unvanquished (des jeux libres) pour l'expérience, et le gain de volume en convertissant des images vers webp, une fois tout recompacté, à été de l'ordre de 20%.
Les cartes en question on été portées à la main, sans chercher a les optimiser (ce n'est pas moi, mais je connais la personne), du coup les images originelles ont été conservée dans leur format initial, et compresser juste les tga, utilisés pour les textures, m'a fait gagner 10% de place, une fois repackagé.
Les 10% restants sont des fichiers qui ne sont plus nécessaires au fonctionnement des serveurs d'unv, qui devaient auparavant être fournis au client malgré tout.
A l'heure actuelle, mon dossier "pakpath" qui stocke les données venue du net pèse 3 giga. 20% de 3 gigs, c'est pas rien, c'est un quasi-CD-rom, et je parle de webp, à priori JXL fait mieux que webp)
Alors, je comprend que, du point de vue de l'utilisateur qui a 3 ou 4 milliers de photos, on s'en fout. Mais du point de vue de ceux qui bossent avec l'outil informatique ou l'utilise pour autre chose que les photos de vacance, ça peut vite être significatif. Je veux dire zut, le gain de compression entre png "naïf" et webp est, en pratique, d'environ 10% sur mon cas d'usage, et JXL ferais mieux en moyenne?
# Bof
Posté par freem . En réponse au lien AI Toolkit, donnez un cerveau à vos NPCs, une librairie C++ header-only. Évalué à -1.
Vu que le sujet m'intéresse, j'ai jeté un oeil.
Pour moi, cette lib n'a que peu d'intérêt, parce que:
Bref, je n'ai pas en tête de lib pour remplacer tout, notamment utility et les FSM, mais à choisir: GPGOAP ou behaviortree.cpp qui dispose aussi, de mémoire, d'un outil visuel pour manipuler les BT, me semblent mieux indiqués.
A noter que je n'ai pas analysé le code de behaviortree.cpp, mais celui de GPGOAP, si.
Bien que GPGOAP ait la limitation de représenter un "worldstate" sur 64 bits seulement, en réalité 64 états c'est beaucoup.
Augmenter la taille serait simple, il suffirait d'utiliser un long double, par exemple (128 bits).
Sinon, normalement le code des IAs de F.E.A.R. est disponible, par l'auteur du concept même de goap.
Pour ce qui est des outils avec GPGOAP, il est très simple de construire un pseudo fichier de conf qui soit convertible aisément en langage dot (graphviz) pour générer un graph des actions. La lib fournit également des outils pour aider le debug.
[^] # Re: Merci 'nal et moules
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 3.
il serait intéressant de savoir pourquoi.
Parce que perso, et il n'y a pas que moi qui le pense, le format .deb est plutôt bien ficelé, contrairement à, disons, rpm, si j'en crois l'auteur de mon lien.
Et de mon point de vue de développeur, le format .deb et les possibilités qu'il a sont complets malgré une très élégante simplicité. Je regrette juste les script pre/post-inst/rm, mais je vois pas comment faire pour automatiquement mettre à jour le menu de boot, par exemple, lors d'une install/MàJ.
[^] # Re: Arch ?
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 2. Dernière modification le 04 janvier 2024 à 01:29.
Non, ça n'est pas logique. Enfin, si, mais pas tout le temps, et pas ici.
La gestion des dépendances, qui vérifie la stabilité du bouzin, elle est faite par dpkg, peu importe l'outil que tu utilises.
En fait, c'est dpkg qui fait tout le sale boulot, et c'est pour ça qu'il y a eu quelques coups de gueule pour la migration usr-merge, justement (je laisserai le lecteur intéressé faire ses recherches, possible même qu'on en ait parlé ici, je ne zone plus trop sur linuxfr, moi).
Ce qui va changer, et c'est le seul élément qui me vienne à l'esprit, c'est qu'apt-get ne sait pas se souvenir qu'un paquet à été installé automatiquement ou manuellement, donc pour le ménage, il faut utiliser debfoster, de mémoire.
En tout cas, la dernière que j'ai farfouillé dans
/var/lib/apt.*, c'était le seul point que j'aie vu.Tout à fait. Mais ça ne m'empêchera pas de répéter régulièrement qu'elles sont fausses, quand je sais de première main que c'est le cas.
[^] # Re: backup
Posté par freem . En réponse au lien Pypy passe à Git + Github. Évalué à 2.
A ceci près que l'immense avantage d'une mailing list sur github ou gitlab, c'est que l'on n'est pas forcé d'aller voir dans sa boîte mail pour choper un code quotidien afin de se connecter.
En fait, j'en ai eu tellement marre de ça récemment que j'ai supprimé mon compte. Je ne peux plus contribuer? Pas si grave, en vrai, ce que je ne peux plus faire, c'est rapporter des bugs ou faire des push request, je suis toujours capable, bien entendu, de faire le code, et je peux même upload sur des forges saines d'esprit si besoin est.
J'ai d'ailleurs appris ainsi que github remplace les identités supprimées par "ghost", et je soupçonne qu'ils conservent des stats, puisque le compte de ghost a des "badges" qui sont peut-être proche de ceux que j'avais. Bon, je l'avoue: je m'en contre-fout des badges. J'aurai préféré à la place qu'ils implémentent des fonctionnalités utiles… je sais pas, moi, par exemple un truc pour m'identifier via ma clé ssh publique, sans me pourrir ma boîte mail, par exemple?
J'ai vu au moins un projet qui s'est barré de github pour la même raison, le mainteneur en a eu marre de cette connerie de "double authentification" forcée.
Comme quoi, tout le monde ne suit pas le mouvement. Par contre, le mainteneur à malheureusement préféré savannah, qui est la forge la plus pourrie que je connaisse. Oui, j'ai essayé, j'y avais même un compte, fut un temps.
Ceci dit, il n'a manifestement jamais montré le bout de son nez, et sa soumission a été rejetée. Parce que tout projet qui y va doit être libre, et donc les licences sont vérifiées. En soit, c'est plutôt bon, mais perso, lire un truc comme ça:
ca me ferait juste fuir de n'importe quelle forge. Mettre le copyright sur le readme, franchement… bref, je suis très bien sur codeberg, moi.
[^] # Re: Après
Posté par freem . En réponse au lien France : députés et sénateurs parviennent à un accord sur le projet de loi immigration - LaLibre.be. Évalué à 4.
Ou alors on peut se souvenir qu'en théorie, la rubrique "liens" devrais respecter la ligne éditoriale?
A ma connaissance, la politique en dehors des problématique de propriété intellectuelle n'en fais pas partie. Mais bon, peu importe (j'ai pas votéW noté de toute façon).
[^] # Re: Arch ?
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 4. Dernière modification le 12 décembre 2023 à 22:14.
Oula, c'est vieux, ça!
Personnellement, depuis que j'utilise debian (environ 15 ans) j'ai toujours mixé aptitude et apt (anciennement apt-get) pour faire les choses, et je n'ai jamais eu le moindre problème. Pas un seul. J'insiste. Lourdement. Parce que c'est vrai!
Ceci dit, j'utilise majoritairement aptitude, qui est incomparable. C'est d'ailleurs l'outil qui m'empêche de bouger de debian, parce qu'avoir une interface ncurses pour installer des paquets, c'est juste logique: c'est utilisable via ssh, et c'est plus efficace qu'enchaîner des commandes.
Bon, qui se dévoue pour faire un vrai site de comparaison? Pas moi en tout cas, j'ai trop la flemme :D (y compris pour déterminer ce qu'il faut comparer et comment)
[^] # Re: Arch ?
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 2.
ben, du coup, il faudrait plutôt mettre son travail par défaut sur toutes les distro, non?
Mais bon sérieux… ce pauvre Lennart n'a fait que filer le source des logiciels qu'il utilise ou écrit pour une boîte, je trouve ça méchamment dégueulasse de le considérer comme un type qui planifie la fin du libre ou je ne sais quelles autres âneries.
Je n'utilise pas son travail (systemd, pulseaudio, etc) pour des raisons à moi, mais je lui suis redevable parce qu'il augmente l'intérêt économique de linux, ce qui crée un petit effet boule de neige, et est donc en ma faveur.
[^] # Re: Arch ?
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 2.
Juste des centaines? Mince, vu le boulot, j'aurais imaginé des milliers moi…
Ben, debian est assez centralisée je pense, c'est une belle (magnifique, même) cathédrale libre.
Par contre, il est aussi à noter, je crois, qu'il est possible de publier des dépôts debian pour ses propres paquets, c'est ce que faisais Opera (jusqu’à la 12, je sais pas après), ce que fait nvidia, et ce que fait vivaldi, ce que fait wine!
Dans le cas de vivaldi et opera, franchement, ils pourraient juste éjecter FF et chromium de debian, vu que "le web" et "stabilité" sont antinomique mais bon, avoir des utilisateurs est aussi important pour changer le monde.
On pourrait me dire que tous ces paquets (sauf wine) sont non-libre, mais bon, debian à une section pour le non-libre de toute façon (autrement dit, pas de zélotes, jalous, zélés. C'est l'origine du mot zélote apparemment.)
Je ne connais pas les process d'arch, alors je ne peux pas juger entièrement, mais dans l'ensemble, arch me semble plus orientée travail communautaire que Debian, qui est plutôt du genre a encourager le travail rigoureux et long (ce qui en fait une distro fiable sur le long terme, donc pour construire un système informatique pérenne). Je pense que arch est pertinente pour les gens qui aiment la tech, et encore, juste une portion d'eux (je me considère comme aimant la tech, mais pas arch :))
PS: le correcteur orthographique sur vivaldi est vraiment pourri. Mais bon, linuxfr a le sien, ça aide, multiplier les couches est une bonne solution pour éviter les bugs… sauf quand ça les encourage. Bref, j'en sais rien.
[^] # Re: Arch ?
Posté par freem . En réponse au journal Ma version rêvée de Debian. Évalué à 6.
Le problème, c'est que modifier un paquet Debian requiert une chiée de paquets à installer (debuild & consort) et le process est loin d'être simple.
Moi-même, j'ai plusieurs paquets recompilés pour exclure des
dépendances stupidesfonctionnalités que je n'utilise pas, genre dbus, systemd, wayland, et j'en oublie.Le résultat final est un système allégé de plusieurs pourcents de paquets, et donc, il est plus simple de lire les release notes, vu qu'il y en a moins.
Non, je n'ai rien contre wayland, dont l'architecture me semble plus sensée que celle de Xorg, mais ça n'empêche pas que j'utilise Xorg parce que:
1. ça juste marche;
2. j'y ai tous les logiciels dont j'ai besoin;
3. il y a de la doc;
4. il y a de vraies lib de dev officielles, contrairement à wayland qui génère des trucs basés sur un fichier xml, et quand j'avais regardé, le résultat était plutôt… disons juste que, moi, j'aurai honte de produire ça.
Par contre, l'architecture logicielle de wayland, du peu que j'en sais, me semble largement meilleure que celle de Xorg (et ce défaut me semble être un défaut d'implémentation, pas de standard) vu qu'elle respecte la séparation des privilèges.
Bref, je sujet, c'est la recompilation de paquets debian pour soi-même, et clairement sur ce point, Debian est franchement pourrie.
Entre la chiée d'outils dont on n'est jamais sûr lesquels sont vraiment utiles, ou quel est leur rôle, la fâcheuse habitude de tout activer par défaut (y compris dbus sur sdl, qui était désactivé par défaut upstream je crois, et qui a généré d'énormes problèmes de performances. Bon, d'un autre côté, il faut ne pas regarder de trop près le code pour avoir confiance en la SDL…), les dépendances de ces outils qui semblent au final tirer tout ce qui existe dans debian (mettons du perl, du python, du autotools, et 2-3 autres tech, histoire que ça soit une grosse galère à gérer, c'est plus fun!).
Le processus pour compiler un paquet custom pour soi-même est également pollué par toutes les règles de Debian dont l'objectif est de partager des paquets de qualité.
La réalité, c'est qu'il est 20 fois plus simple d'écrire un script qui génère un paquet binaire à partir de l'exécutable qu'un paquet source. Il serait bon que cet élément soit clairement affiché quelque part, et moins découragé (sauf que bien sûr, le but de Debian est de partager les efforts, et d'avoir un maximum de logiciels libre, donc faire apparaître comme compliqué la création d'un dépôt Debian avec des paquets non source me semble pas déconnant comme stratégie, sauf que ça impacte aussi les logiciels libres moins connus).
J'ai personnellement écrit un script qui génère des paquets
.debpour une boîte dans le passé (donc, on compilait, puis on lançait cet outil pour générer un .deb, que l'on pouvais ensuite répartir et installer sur les systèmes distants), à partir d'une recette minimaliste et des binaires. A cause du faible niveau d'expertise de mes collègues, j'ai du lui donner une interface simple, et une documentation qui tienne la route, sur plusieurs degrés (utilisateur et mainteneur, concrètement, je savais sûrement que je n'allais pas passer ma vie a bosser pour cet empaffé).Comparé à ça, tous les systèmes de paquets me semblent franchement complexes, et c'est normal: ils gèrent bien plus de cas! C'est incomparable, gérer un parc de moins de 300 machines produites par nous et réparties aléatoirement sur le territoire français ou gérer un parc de plusieurs millions de machines dont aucune n'est identique?
Bon, ok, donc, les paquets source c'est compliqué, très bien, et ça sera jamais simple de toute façon (entre la quantité de langages de prog et de compilos pour chacun…), mais j'aimerai que Debian fournisse un paquet qui permette de construire des paquets binaires sans se prendre autant la tête.
Au fond, ce n'est pas si compliqué, un paquet binaire: il faut juste définir quels paquets doivent être installés, les scripts d'installation et de suppression, que je considère comme étant plutôt une erreur d'architecture logicielle de Debian (leur rôle est surtout d'activer le démarrage automatique des services, désolé, mais je m'en passerai bien) et tout fonctionne assez simplement.
Concrètement, un .deb, c'est une tarball qui contiens 3 fichiers:
Pour le point 2, il me paraît utile de préciser que cette archive ne contiens qu'un seul fichier qui a besoin d'être écrit par l'utilisateur, et le format est dérivé du stockage des mails, donc, c'est du du texte pur, très simple à manipuler, il est possible (je l'ai fait) de se bricoler des scripts awk qui gèrent ça très facilement (je ne sais pas garder d'info d'une ligne à l'autre via sed).
Merde, j'ai encore écrit un pavé qui n'intéressera pas grand monde… Désolé pour ça (en admettant que des gens lisent ça)
[^] # Re: Un contrat pour toute relation?
Posté par freem . En réponse au lien Macron s'oppose à l'Europe qui voudrait que le viol soit caractérisé par l’absence de consentement . Évalué à 1.
Il faut garder à l'esprit que le mariage est (ou au moins a été) un outil pour acquérir la citoyenneté et est donc monnayable.
[^] # Re: celles liées à vos investissements
Posté par freem . En réponse au lien Les 1 % les plus riches émettent autant de gaz à effet de serre que les 66 % les plus pauvres. Évalué à 3. Dernière modification le 22 novembre 2023 à 08:27.
Ben tiens. Et il sert à quoi le service marketing alors? Les commerciaux, ces gens qui vendent du rêve et dont le travail consiste à créer le besoin, et qui déclenchent ensuite la R&D pour y répondre, ils ne sont pas salariés?
Et les ingés de la R&D, ils ont le pistolet sur la tempe peut-être?
Pour ce qui est des consommateurs, désolé mais si, ils ont demandé, après un éventuel bourrage de crâne soit par le marketing, soit par leur cercle de connaissances, à avoir un truc qui impressionne.
Le tort est partagé, très clairement, et je doute qu'il y aurait production de masse s'il n'y avait pas achat.
Mr. Musk ne peut pas être derrière chacun de ses employés, dans le meilleur des cas il peut juste donner les grandes lignes.
[^] # Re: absolument pas stable.
Posté par freem . En réponse au lien The First Stable Release of a Memory Safe sudo Implementation. Évalué à 3.
Non, ce n'est pas un drop-in, sinon il devrais tout implémenter, hors: