tu sembles dire que les ZFE sont la moins mauvaise solution.
Ce n'est pas si évident…
Par exemple, sur Grenoble, les autoroutes et la rocade ne seront pas dans la ZFE, or la pollution est maximale sur ces axes là !
Autre point, les PME ne vont pas pouvoir avoir une flotte d'utilitaires électriques et une flotte d'utilitaires diesels. Alors que les gros comme SPIE, VINCI… le pourront. Ainsi, la ZFE risque de tuer les PME pour privilégier les gros groupes !
Enfin, pas mal de personne ne pourront pas changer leur voiture. Pas mal de personne vont vouloir habiter à 20 km. Au final, on aura encore plus de déplacement !
Bref, le sujet est loin d'être trivial. Avant de généraliser les ZFE, faisons un test sur quelques agglo pour voir.
À mon sens, plus il y a de vélo, meilleur est la santé des personnes et moins il y a de voiture. Les trottinettes ne sont pas du tout pareil en terme de santé publique.
La ZFE n'est pas gratuite à mettre en place. Faut-il dépenser cet argent sur les pistes cyclables, faire de la prévention, injecter sur le tramway, le RER, rétrécir les routes…
Même le bureau ne dérive plus des variables du script X de lancement… Du coup, on ne peut plus facilement positionner des variables en ajoutant du script Bash bien placé.
Tous les machins à la systemd sont à la fois bien dans un sens et mène dans un autre vers bien trop de variable globale (dbus…) et plus moyen de scripter son système, ce qui faisait la force des UNIX.
Heureusement. C'est la base des processus UNIX. On ne touche pas aux processus voisins ou parent !
Le véritable soucis est que la plupart des applications graphiques actuelles fonctionnent en variable globale. Ce n'est pas une avancée je trouve…
Bilan, c'est impossible de changer de groupe primaire sur une gestionnaire de fichier graphique type Nautilus… On a beaucoup perdu avec cette généralisation des variables globales.
Il n'y a pas 50 solutions… Soit tu distribue en central avec des applications signées, soit tu distribues dans les HOME. Autre commutateur, soit tu mutualises les bibliothèques, soit tu embarques tout.
La mode est de tout embarquer.
Pourquoi ?
Parce que la rétro compatibilité, tout le monde s'en fout de nos jours… Du coup, c'est un vrai bordel, on casse les API à chaque version, on numérote n'importe comment…
Si les langages avaient été au bout de leur concept, elles auraient fait une installation compatible avec les .deb et les .rpm. La bonne question est pourquoi on ne peut facilement transformer un paquet d'un langage en un paquet de distribution ?
Heureusement, le noyau Linux et la glibc sont très stable coté API.
En tout cas un truc qui est toujours aussi pourri qu'avant sous Linux c'est la distribution de logiciels.
Tu as essayé de faire un paquet Debian ?
En gros, tu fais une archive tar compressé avec gzip qui comporte tous tes fichiers et tu mets cela dans une archive ar. Tu fais ton fichier de control dans lequel tu décris ce qu'il y a dans le paquet (ben il faut quand même lui donner un petit nom et une version à ce paquet). Ce fichier, tu le mets aussi dans l'archive ar.
Et c'est tout…
Bref, faire un paquet Debian pas super nickel prend 1h la première fois puis 5 min ensuite et c'est même carrément automatique par CI la semaine suivante. J'ai un script bash de quelques lignes qui fait cela tout bien. Ne pas faire de paquet, c'est juste ne pas être intéressé par la question…
Et d'ailleurs, c'est un des soucis, c'est compliqué de faire du haproxy avec SSH et je n'ai pas encore trouvé comment, avec du logiciel libre, faire un répartiteur de charge SSH avec gestion de la session (envoyer la personne toujours sur le même nœud s'il avait une connexion pas trop ancienne précédemment…).
Si le répartiteur de charge voit tout, c'est pas forcément terrible. S'il ne voit rien, c'est pas terrible du tout.
Clair, les DSI bloquent UDP. C'est déjà galère pour la visio… Les DSI n'aime pas UDP en général ! Au final, on se retrouve souvent à faire des tunnels SSH donc TCP dans TCP pour bosser ;-)
Bref, ce n'est pas gagné… On voit que TCP et le web (80/443) ont tué tous les autres protocoles / ports !
Du code dérivé avec du code BSD devient de facto GPL si tu veux utiliser les modifs, techniquement tu peux pas utiliser la dérivation avec les termes de la licence BSD.
Pas du tout, tu peux très bien continuer à développer le code de la bibliothèque en BSD…
C'est le propre de la licence BSD que de pouvoir modifier le code et mettre le résultat sous la licence que tu veux, GPL ou propriétaire ou rester en BSD.
Bref, je vois pas trop le soucis.
D'ailleurs, dans le noyau Linux, il y a pas mal de code sous double licence afin de pouvoir partager du code entre les différents noyaux libres.
Si tu le penses, tant mieux. Enfin, leur tél a une part de marché non nul… Et Google avec Fuchsia fait aussi un OS sous licence BSD / MIT.
Apple a repris Cups et avait mis beaucoup de bille dans le compilateur LLVM, ce n'est pas pour rien.
Mais bon, chacun fait comme il veut. Perso, je code aussi en MIT / BSD sur certains projets. Je sais très bien que sur certaines bibliothèques de protocole par exemple, cela permet de mieux propager ces protocoles sur tous les OS.
Mais perso, je ne vois pas l’intérêt de refaire un grep ou un tar en BSD alors que la version GNU fonctionne très bien. Il est plus intéressant de voir les projet de faire des alternatives en rust ou en go plus sécurisées que de refaire en C une autre implémentation.
Parce qu'Apple a un noyau proche des BSD et qu'Apple fait tout pour basculer des projets sous BSD ;-) Donc mon avis perso, en bossant sur des remplaçants BSD des outils GNU, on bosse pas mal pour Apple !
Après, chacun est libre de faire ce qu'il veut ;-)
Si tu met un licence GPLv3, tu ne contrevient pas aux souhaits des développeurs initiaux, puisque ce sont eux qui l'ont mises !
Si tu ne met pas de licence, tu tombes sous le droit d'auteur, donc tu es 100% non libre. À mon sens, tu n'es pas bien renseigné. Si tu veux faire du domaine public, il faut mettre la licence WTFL ou du CC0 par exemple, mais surtout pas rien !
Il y a peu de bibliothèque en licence GPL en pratique, car c'est effectivement assez bloquant. En effet, une bonne bibliothèque propage par exemple des bonnes pratiques, des bons protocoles… En réalité, la grande partie des bibliothèques sont sous licence LGPL justement.
Globalement, cela fonctionne très très bien. Je fait et j'utilise du libre depuis plus de 25 ans. Le modèle est franchement bon.
Moi je vois qu'avec la BSD par exemple, Apple pousse à fond avec le compilateur LLVM, le même ne se gêne pas pour faire des systèmes bien fermés avec un contrôle total sur toutes ses machines…
Je préfère 1000 fois GNU/Linux avec son modèle GPL/LGPL/AGPL ;-) Je pense que le libre globalement y gagne bien plus avec ce modèle ! D'ailleurs, parti de rien en 1995, le noyau Linux est largement leader en 2021 sur les ordinateurs du monde entier. Et je pense que ce n'est pas pour rien que Google pousse son OS…
Non, je ne prends pas le problème à l'envers. Comme je l'ai dis, un exécutable GPL est indépendant d'un autre exécutable… Donc vouloir supprimer des exécutable GPL par des exécutables BSD est surtout philosophique (et cela va 100% dans le sens d'Apple).
Je ne parle pas d'ajouter des nouvelles bibliothèques GPL au coeur du système ;-)
Une partie de ton pb viens des import à la con ;-)
Historiquement, dans le CPAN de Perl, on mettait tous comme licence GPL V2 ou plus et Perl équivalent… (Artistic donc).
Mais les autres langages vont chercher à droite et à gauche et n'ont pas été capable de faire un CPAN ! Bilan, c'est le bordel !
Le soucis, c'est justement l'organisation de ces langages qui est bordélique et ne propose pas une licence à mettre sur tous les modules partagés. Moi je fais surtout des scripts en Perl et je dors tranquillou ;-)
Apple veut se débarrasser de la GPL… Donc oui, elle ajoute une contrainte qui évite d'avoir des grosses boites qui intègre du code sans forcément donner en retour.
Dans le cas de NVidia, il s'agit de code noyau et NVidia ne joue pas le jeux depuis des années. Voir ce que Linus leur avait fait comme geste.
En parlant de binaire, je pensais à programme… Je le prenais comme synonyme. Donc les bibliothèques et les programmes, ce sont deux choses différentes au sens de la GPL (voir LGPL / AGPL).
Je ne pense pas que cela pose tant de problème que cela. Il y a surtout une volonté de virer toute trace de licence héréditaire de la part des grosses boites. Je suis très méfiant vis-à-vis d'elles !
Oui, libre au sens GPL. Tu sais très bien qu'un code BSD peut-être intégré dans un code propriétaire sans rien demandé à personne… C'est pour cela d'ailleurs qu'Apple fait tout pour pousser LLVM et les licences BSD ;-)
Si tu codes sous BSD et te linke avec une bibliothèque GPL, tu dois te mettre sous GPL. Normal, elle a été faite faite pour ça ! Si on veut que tout le monde se linke et rester dans la philosophie GPL, on se met sous LPGL.
D'ailleurs, pendant des années, la bibliothèque Qt était GPL pour forcer les entreprises à prendre une licence.
Il y a le code noyau et le code utilisateur… Les deux sont bien distincts. Et la GPL concerne un code utilisateur. Un binaire GPL n'a aucune influence sur un autre binaire GPL. Ainsi le tar GNU n'a pas d'influence sur le grep et ainsi de suite.
La GPL est une licence héréditaire dont l'idée géniale est que si tu te link dessus (.so), alors ton code doit être libre (ce qui ne veut pas dire gratuit et disponible sur le web, juste disponible).
Donc cela me fait rire ces peurs sur la GPL ;-)
En pratique, Apple & Co (Google) aimerait bien virer la GPL car elle les fait bien chiée !
J'utilise polkit pour autoriser les utilisateurs à modifier le réseau via network-manager, ainsi qu'à monter des systèmes de fichier.
Effectivement, pour network-manager, on finit par donner les droits sur toutes les cartes réseau car sur un parc, cela deviens trop bouffe temps de vouloir faire plus fin… Il arrive un moment où il faut juste que cela marche pour l'utilisateur de son portable !
Avec RunAs, tu fournis toujours le mot de passe du compte cible et non ton mot de passe. C'est un équivalent du su.
La plupart des utilisateurs sont toujours admin de leur poste donc Windows est meilleure qu'avant et leur demande leur mot de passe pour exécuter des actions sensibles. Mais à la base, les comptes sont admins…
Donc pour moi, pas grand chose de changé, c'est juste plus sécurisé, mais toujours sans sudo possible.
Pour les logos, voir les évolutions des logos Coca-Cola / Pepsi-Cola pour se rendre compte que faire évoluer son logo n'apporte pas toujours beaucoup de chose. Mais cela occupe les services com et permet d'avoir des promotions !
Je suis bien content que le logo Debian ne change pas ;-)
On est obligé d'élever de temps en temps ses droits. À ma connaissance, il y a plusieurs méthodes :
- sudo
- su (+ mot de passe root - bof bof)
- polkit
- suid
- daemon en tout sens
Si on élimine la solution su qui est ce que sais faire Windows, on se retrouve au final avec deux usines à gaz, sudo ou polkit. Je trouve souvent que la configuration de sudo plus clair et elle privilégie des commandes qu'on peut faire indépendamment. Polkit, c'est un peu une grosse boite noire…
Les binaires suid, cela marche bien aussi depuis des années ! C'est un peu pour tous les utilisateurs, un peu moins fin que sudo au final.
Enfin, des daemons dans tous les sens… C'est aussi ce que propose Windows. On finit par avoir 50 services sur une machine alors qu'on souhaite juste éditer un fichier sous /etc… Je suis sceptique devant la prolifération de daemon.
D'ailleurs, pourquoi Tree Style Tab ne vire pas la barre du haut ?
Autre question, pourquoi ne pas mettre les onglets en latéral sur les PC. Avec les écran 16:9 ou 16:10, c'est hyper plus pratique. Voila qui serait une BELLE innovation qui pourrait faire le buz !
Oui l'archivage est une grosse problématique et le html, c'est le zouk… par exemple, tout n'est pas dans le même fichier. La visualisation évolue pas mal avec les navigateurs… voir avec le même navigateur au cour du temps.
Un PDF généré il y a 25 ans se lit et s'imprime toujours pareil de nos jours.
[^] # Re: Mon avis
Posté par Sytoka Modon (site web personnel) . En réponse au journal [HS] Parlons ZFE. Évalué à 8. Dernière modification le 15 juin 2021 à 15:43.
Ce n'est pas si évident…
Par exemple, sur Grenoble, les autoroutes et la rocade ne seront pas dans la ZFE, or la pollution est maximale sur ces axes là !
Autre point, les PME ne vont pas pouvoir avoir une flotte d'utilitaires électriques et une flotte d'utilitaires diesels. Alors que les gros comme SPIE, VINCI… le pourront. Ainsi, la ZFE risque de tuer les PME pour privilégier les gros groupes !
Enfin, pas mal de personne ne pourront pas changer leur voiture. Pas mal de personne vont vouloir habiter à 20 km. Au final, on aura encore plus de déplacement !
Bref, le sujet est loin d'être trivial. Avant de généraliser les ZFE, faisons un test sur quelques agglo pour voir.
À mon sens, plus il y a de vélo, meilleur est la santé des personnes et moins il y a de voiture. Les trottinettes ne sont pas du tout pareil en terme de santé publique.
La ZFE n'est pas gratuite à mettre en place. Faut-il dépenser cet argent sur les pistes cyclables, faire de la prévention, injecter sur le tramway, le RER, rétrécir les routes…
[^] # Re: Mon petit avis sur la question
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux et libre : retour 20 ans en arrière ?. Évalué à 4.
Même le bureau ne dérive plus des variables du script X de lancement… Du coup, on ne peut plus facilement positionner des variables en ajoutant du script Bash bien placé.
Tous les machins à la systemd sont à la fois bien dans un sens et mène dans un autre vers bien trop de variable globale (dbus…) et plus moyen de scripter son système, ce qui faisait la force des UNIX.
[^] # Re: Mon petit avis sur la question
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux et libre : retour 20 ans en arrière ?. Évalué à 4.
Heureusement. C'est la base des processus UNIX. On ne touche pas aux processus voisins ou parent !
Le véritable soucis est que la plupart des applications graphiques actuelles fonctionnent en variable globale. Ce n'est pas une avancée je trouve…
Bilan, c'est impossible de changer de groupe primaire sur une gestionnaire de fichier graphique type Nautilus… On a beaucoup perdu avec cette généralisation des variables globales.
[^] # Re: Contradiction
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux et libre : retour 20 ans en arrière ?. Évalué à 5.
Il n'y a pas 50 solutions… Soit tu distribue en central avec des applications signées, soit tu distribues dans les HOME. Autre commutateur, soit tu mutualises les bibliothèques, soit tu embarques tout.
La mode est de tout embarquer.
Pourquoi ?
Parce que la rétro compatibilité, tout le monde s'en fout de nos jours… Du coup, c'est un vrai bordel, on casse les API à chaque version, on numérote n'importe comment…
Si les langages avaient été au bout de leur concept, elles auraient fait une installation compatible avec les .deb et les .rpm. La bonne question est pourquoi on ne peut facilement transformer un paquet d'un langage en un paquet de distribution ?
Heureusement, le noyau Linux et la glibc sont très stable coté API.
[^] # Re: Contradiction
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux et libre : retour 20 ans en arrière ?. Évalué à 9. Dernière modification le 14 juin 2021 à 08:10.
Tu as essayé de faire un paquet Debian ?
En gros, tu fais une archive tar compressé avec gzip qui comporte tous tes fichiers et tu mets cela dans une archive ar. Tu fais ton fichier de control dans lequel tu décris ce qu'il y a dans le paquet (ben il faut quand même lui donner un petit nom et une version à ce paquet). Ce fichier, tu le mets aussi dans l'archive ar.
Et c'est tout…
Bref, faire un paquet Debian pas super nickel prend 1h la première fois puis 5 min ensuite et c'est même carrément automatique par CI la semaine suivante. J'ai un script bash de quelques lignes qui fait cela tout bien. Ne pas faire de paquet, c'est juste ne pas être intéressé par la question…
[^] # Re: Chiffrement
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 3. Dernière modification le 30 mai 2021 à 08:57.
Et d'ailleurs, c'est un des soucis, c'est compliqué de faire du haproxy avec SSH et je n'ai pas encore trouvé comment, avec du logiciel libre, faire un répartiteur de charge SSH avec gestion de la session (envoyer la personne toujours sur le même nœud s'il avait une connexion pas trop ancienne précédemment…).
Si le répartiteur de charge voit tout, c'est pas forcément terrible. S'il ne voit rien, c'est pas terrible du tout.
Bref, sujet complexe.
[^] # Re: Belle rédaction
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 9.
Clair, les DSI bloquent UDP. C'est déjà galère pour la visio… Les DSI n'aime pas UDP en général ! Au final, on se retrouve souvent à faire des tunnels SSH donc TCP dans TCP pour bosser ;-)
Bref, ce n'est pas gagné… On voit que TCP et le web (80/443) ont tué tous les autres protocoles / ports !
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 2.
Pas du tout, tu peux très bien continuer à développer le code de la bibliothèque en BSD…
C'est le propre de la licence BSD que de pouvoir modifier le code et mettre le résultat sous la licence que tu veux, GPL ou propriétaire ou rester en BSD.
Bref, je vois pas trop le soucis.
D'ailleurs, dans le noyau Linux, il y a pas mal de code sous double licence afin de pouvoir partager du code entre les différents noyaux libres.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 3.
Si tu le penses, tant mieux. Enfin, leur tél a une part de marché non nul… Et Google avec Fuchsia fait aussi un OS sous licence BSD / MIT.
Apple a repris Cups et avait mis beaucoup de bille dans le compilateur LLVM, ce n'est pas pour rien.
Mais bon, chacun fait comme il veut. Perso, je code aussi en MIT / BSD sur certains projets. Je sais très bien que sur certaines bibliothèques de protocole par exemple, cela permet de mieux propager ces protocoles sur tous les OS.
Mais perso, je ne vois pas l’intérêt de refaire un grep ou un tar en BSD alors que la version GNU fonctionne très bien. Il est plus intéressant de voir les projet de faire des alternatives en rust ou en go plus sécurisées que de refaire en C une autre implémentation.
A+
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 4.
Parce qu'Apple a un noyau proche des BSD et qu'Apple fait tout pour basculer des projets sous BSD ;-) Donc mon avis perso, en bossant sur des remplaçants BSD des outils GNU, on bosse pas mal pour Apple !
Après, chacun est libre de faire ce qu'il veut ;-)
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 3.
Si tu met un licence GPLv3, tu ne contrevient pas aux souhaits des développeurs initiaux, puisque ce sont eux qui l'ont mises !
Si tu ne met pas de licence, tu tombes sous le droit d'auteur, donc tu es 100% non libre. À mon sens, tu n'es pas bien renseigné. Si tu veux faire du domaine public, il faut mettre la licence WTFL ou du CC0 par exemple, mais surtout pas rien !
Il y a peu de bibliothèque en licence GPL en pratique, car c'est effectivement assez bloquant. En effet, une bonne bibliothèque propage par exemple des bonnes pratiques, des bons protocoles… En réalité, la grande partie des bibliothèques sont sous licence LGPL justement.
Globalement, cela fonctionne très très bien. Je fait et j'utilise du libre depuis plus de 25 ans. Le modèle est franchement bon.
Moi je vois qu'avec la BSD par exemple, Apple pousse à fond avec le compilateur LLVM, le même ne se gêne pas pour faire des systèmes bien fermés avec un contrôle total sur toutes ses machines…
Je préfère 1000 fois GNU/Linux avec son modèle GPL/LGPL/AGPL ;-) Je pense que le libre globalement y gagne bien plus avec ce modèle ! D'ailleurs, parti de rien en 1995, le noyau Linux est largement leader en 2021 sur les ordinateurs du monde entier. Et je pense que ce n'est pas pour rien que Google pousse son OS…
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 1.
Non, je ne prends pas le problème à l'envers. Comme je l'ai dis, un exécutable GPL est indépendant d'un autre exécutable… Donc vouloir supprimer des exécutable GPL par des exécutables BSD est surtout philosophique (et cela va 100% dans le sens d'Apple).
Je ne parle pas d'ajouter des nouvelles bibliothèques GPL au coeur du système ;-)
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 9.
Le mot contamination viens de Microsoft qui voulait tuer le logiciel libre…
Encore une fois, je préfère le mot hérédité. Tu hérites d'un code qui propose de fournir le code source. C'est plutôt positif comme approche.
La GPL propage la transparence dans le code, je trouve cela très bien ;-)
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 4.
Une partie de ton pb viens des import à la con ;-)
Historiquement, dans le CPAN de Perl, on mettait tous comme licence GPL V2 ou plus et Perl équivalent… (Artistic donc).
Mais les autres langages vont chercher à droite et à gauche et n'ont pas été capable de faire un CPAN ! Bilan, c'est le bordel !
Le soucis, c'est justement l'organisation de ces langages qui est bordélique et ne propose pas une licence à mettre sur tous les modules partagés. Moi je fais surtout des scripts en Perl et je dors tranquillou ;-)
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à -1. Dernière modification le 25 mai 2021 à 16:18.
Apple veut se débarrasser de la GPL… Donc oui, elle ajoute une contrainte qui évite d'avoir des grosses boites qui intègre du code sans forcément donner en retour.
Dans le cas de NVidia, il s'agit de code noyau et NVidia ne joue pas le jeux depuis des années. Voir ce que Linus leur avait fait comme geste.
En parlant de binaire, je pensais à programme… Je le prenais comme synonyme. Donc les bibliothèques et les programmes, ce sont deux choses différentes au sens de la GPL (voir LGPL / AGPL).
Je ne pense pas que cela pose tant de problème que cela. Il y a surtout une volonté de virer toute trace de licence héréditaire de la part des grosses boites. Je suis très méfiant vis-à-vis d'elles !
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 4.
Oui, libre au sens GPL. Tu sais très bien qu'un code BSD peut-être intégré dans un code propriétaire sans rien demandé à personne… C'est pour cela d'ailleurs qu'Apple fait tout pour pousser LLVM et les licences BSD ;-)
Si tu codes sous BSD et te linke avec une bibliothèque GPL, tu dois te mettre sous GPL. Normal, elle a été faite faite pour ça ! Si on veut que tout le monde se linke et rester dans la philosophie GPL, on se met sous LPGL.
D'ailleurs, pendant des années, la bibliothèque Qt était GPL pour forcer les entreprises à prendre une licence.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 2.
Il y a le code noyau et le code utilisateur… Les deux sont bien distincts. Et la GPL concerne un code utilisateur. Un binaire GPL n'a aucune influence sur un autre binaire GPL. Ainsi le tar GNU n'a pas d'influence sur le grep et ainsi de suite.
La GPL est une licence héréditaire dont l'idée géniale est que si tu te link dessus (.so), alors ton code doit être libre (ce qui ne veut pas dire gratuit et disponible sur le web, juste disponible).
Donc cela me fait rire ces peurs sur la GPL ;-)
En pratique, Apple & Co (Google) aimerait bien virer la GPL car elle les fait bien chiée !
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 10.
La GPLv3 est compatible BSD… De mémoire, ce sont les BSD qui ne veulent pas de v3 et non l'inverse.
# Obsolète
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 13.0. Évalué à 9.
Attention, ce ne sont pas les outils GNU qui sont obsolètes, ce sont les version que FreeBSD utilisait…
D'ailleurs, on voit bien que l'objectif est de virer tous les outils GPL petits à petits.
[^] # Re: polkit
Posté par Sytoka Modon (site web personnel) . En réponse au lien Les vrais sysadmins n'utilisent pas sudo - redhat.com. Évalué à 3.
J'utilise polkit pour autoriser les utilisateurs à modifier le réseau via network-manager, ainsi qu'à monter des systèmes de fichier.
Effectivement, pour network-manager, on finit par donner les droits sur toutes les cartes réseau car sur un parc, cela deviens trop bouffe temps de vouloir faire plus fin… Il arrive un moment où il faut juste que cela marche pour l'utilisateur de son portable !
[^] # Re: polkit
Posté par Sytoka Modon (site web personnel) . En réponse au lien Les vrais sysadmins n'utilisent pas sudo - redhat.com. Évalué à 2.
Avec RunAs, tu fournis toujours le mot de passe du compte cible et non ton mot de passe. C'est un équivalent du su.
La plupart des utilisateurs sont toujours admin de leur poste donc Windows est meilleure qu'avant et leur demande leur mot de passe pour exécuter des actions sensibles. Mais à la base, les comptes sont admins…
Donc pour moi, pas grand chose de changé, c'est juste plus sécurisé, mais toujours sans sudo possible.
[^] # Re: Très sympa le nouveau logo :) Mais...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rétrospective de l'adoption du nouveau logo de Fedora. Évalué à 6.
Pour les logos, voir les évolutions des logos Coca-Cola / Pepsi-Cola pour se rendre compte que faire évoluer son logo n'apporte pas toujours beaucoup de chose. Mais cela occupe les services com et permet d'avoir des promotions !
Je suis bien content que le logo Debian ne change pas ;-)
# polkit
Posté par Sytoka Modon (site web personnel) . En réponse au lien Les vrais sysadmins n'utilisent pas sudo - redhat.com. Évalué à 2.
On est obligé d'élever de temps en temps ses droits. À ma connaissance, il y a plusieurs méthodes :
- sudo
- su (+ mot de passe root - bof bof)
- polkit
- suid
- daemon en tout sens
Si on élimine la solution su qui est ce que sais faire Windows, on se retrouve au final avec deux usines à gaz, sudo ou polkit. Je trouve souvent que la configuration de sudo plus clair et elle privilégie des commandes qu'on peut faire indépendamment. Polkit, c'est un peu une grosse boite noire…
Les binaires suid, cela marche bien aussi depuis des années ! C'est un peu pour tous les utilisateurs, un peu moins fin que sudo au final.
Enfin, des daemons dans tous les sens… C'est aussi ce que propose Windows. On finit par avoir 50 services sur une machine alors qu'on souhaite juste éditer un fichier sous /etc… Je suis sceptique devant la prolifération de daemon.
J'ai certainement oublié autre chose ;-)
[^] # Re: Userchrome.css
Posté par Sytoka Modon (site web personnel) . En réponse au journal nouvelle interface pour Firefox 89. Évalué à 8.
D'ailleurs, pourquoi Tree Style Tab ne vire pas la barre du haut ?
Autre question, pourquoi ne pas mettre les onglets en latéral sur les PC. Avec les écran 16:9 ou 16:10, c'est hyper plus pratique. Voila qui serait une BELLE innovation qui pourrait faire le buz !
[^] # Re: Transport
Posté par Sytoka Modon (site web personnel) . En réponse au journal De l'affichage des documents. Évalué à 5.
Oui l'archivage est une grosse problématique et le html, c'est le zouk… par exemple, tout n'est pas dans le même fichier. La visualisation évolue pas mal avec les navigateurs… voir avec le même navigateur au cour du temps.
Un PDF généré il y a 25 ans se lit et s'imprime toujours pareil de nos jours.