Raz le bol d'obliger les personnes à vouloir prendre mandriva... Comme dis ci-dessus, il y a des procédures avec appel d'offre.
Je rappelle que debian est très bien ancré en europe et en france en particulier. Combien de développeurs debian en Europe et combien de développeurs mandriva ?
Et puis, il y a la Suse...
Bref, pour un ancien qui a bien connu les problèmes avec BULL et Thompson, tu nous gonfles un peu avec Mandriva à chaque fois !
> J'avoue être troublé que certains ne comprennent pas l'avantage de cette fonctionnalité.
Parce que tu es dans un stratégie mono-utilisateur avec une vision bureau graphique et click click click...
J'ai quatre utilisateurs, je fait une file globale ?
Mes programmes tournent et font des copies, ils attendent la file globable ?
Je veux un système multi-utilisateurs, multi-tâches. Le disque n'a pas à gratter, avec le sata, l'ordonencement des ordres, les caches... normalement, c'est à l'OS de se débrouiller pour faire cela. Ici, on veut amener une fonctionalité de l'OS sur le bureau... avec un démon encore de plus.
Si l'OS ou le système de fichier sont mal conçu, modifiont les plutôt que de passer de l'énergie sur un truc réducteur et qui met en évidence la mauvaise conception de l'OS ou des applications graphiques (comme dis dans un post, ionice, cela existe).
Cela me rappelle gnome-vfs et toute cette daube inutilisable en ligne de commande mais uniquement pour les applications du bureau considérer (gnome d'un coté, kde de l'autre avec kio). L'énergie aurait du dès le début se faire sur fuse ou équivalent et donc de faire quelque chose dans la couche base.
Exemple de daube graphique. Sur une debian (je ne sais pas pour les autres), les clefs USB ne se monte pas sur le bureau si l'utilisateur est sur un annuaire de type LDAP et qu'on lui donne le groupe plugdev au lancement de la session avec pam_group. Pourquoi ? parce que tout dépend d'un démon dbus qui est lancé avant l'ouverture de session... (je crois que c'est corrigé sur ubuntu). Bref, tout cela pour dire que ces machins globaux nous compliquent la vie et que le système des droits et ainsi de suite devient de plus en plus nébuleux.
> La suite logique serait de pouvoir définir des règles globales
Il faut aussi arrêter de vouloir transformer un OS multi-utilisateurs multi-tâche multi bureau en OS à variable globale mono-utilisateurs mono-bureau mono-tâche...
Les machines global avec les démons qui tournent de partout, tout cela pour que lorsque je change le paramètre epsilon, tout change d'un coup, je pense que c'est une voie très dangeureuse pour la sécurité du système.
UNIX est assez simple à la base et un des fondamentaux de la programmation est d'éviter les variables globales. Donc lorsque je lis une phrase comme celle ci-dessus, je dis danger, on est en train de partir dans une mauvaise direction et on va avoir des bureaux très sensibles aux virus si on continue dans cette direction.
C'est linux.com et non linux.org, donc c'est du contenu en .com. Le public visé ne me semble pas celui de linuxfr et cela ne me choque pas qu'on n'y aille pas souvent. C'est plus dédié décideur. Il faudrait en parallèle un linux.org (qui existe, je viens d'aller voir).
Il n'empêche que j'ai vu que SystemRescueCD avait sortie une nouvelle version. J'ai donc appris quelque chose d'intéressant en allant la bas.
Moi je dis que s'il faut couper le courant pour changer une ampoule, c'est qu'il y a manifestement un problème de conception (sauf si ampoule cassée).
Une ampoule morte, on doit la prendre et en mettre une autre comme on branche un poste radio sur une prise, sans se poser de question.
Je n'ai jamais eu de soucis avec les baïonnettes alors que les ampoules à vis passent leur temps à se dévisser... Mettre une vis me semble aberrant même si c'est la norme par défaut d'aujourd'hui. Tu te vois visser la prise de ton poste radio dans le mur ? Alors pourquoi nous oblige t'on à faire cela percher sur une chaise les deux bras en l'air ?
A mon sens, un des soucis de ce genre de réseau (PGP/GPG ou SSH) est qu'il est basé sur des clefs ayant la plupart du temps une durée de vie infini. Donc on monte son réseau et puis un jour ... patatras, il y a un article qui dis que les clefs ne sont pas si géniale que cela à terme.
Au final, cela me donne comme pour SSH le sentiment d'un défaut de conception. Les clefs de chiffrement à usage pour le réseau devrait toujours avoir une durée de vie limitée (c'est souvent le cas des certificat X509 que le trouve pour les sites HTTPS, mais pas toujours). La durée de vie limité résout à terme le problème des failles inévitable (cf carte bleu).
La solution de la révocation n'est pas bonne car elle demande au client d'aller voir des listes centralisées, de se mettre à jour et que celui-ci ai effectivement implémenté ce mécanisme de révocation. Bref, c'est bien mais pas assez fiable pour se baser la dessus sur du long terme.
A partir du moment ou les clefs ont une durée de vie limité, il faut dès la conception penser à la mise à jour de ces clefs et assurer la période transitoire à deux clefs. C'est souvent mal fait, même sur les certificats X509. Le CNRS a d'ailleurs été confronté au passage aux certificats CNRS2 il n'y a pas longtemps et nous avons deux ans pour mettre à jour tous nos certificats dans les laboratoires. Malgré cela, pas mal d'applications n'aiment pas le changement de certificat. Par exemple, comment mettre à jour le certificat de mon serveur OCS qui me déploie mes logiciels sachant que celui-ci a soit le nouveau, soit l'ancien certificat mais ne peut pas avoir les deux ! Cela se mors la queue et je n'ai pas trouvé de bonne solution intégrée dans OCS...
Au final, je dirais qu'il y a du travail sur la planche pour que les développeurs de ces applications modifient leurs protocoles pour tenir compte de cet aspect temporel et que le protocole lui-même gère la phase de transition avec une mise à jour automatique des clients vers les nouvelles clefs et que les deux clefs soient équivalentes pour les clients. Pour le moment, un serveur web ou ssh ne peut avoir deux clefs !
Debian l'a bien compris puisque chaque distribution est lié a une et une seule clef. Lorsqu'elle sors une distribution, la clef de la future stable est déjà dans le paquetage keyring pour que la mise à jour de la stable vers la future stable (testing) puisse se faire sans hurlement de la part d'APT. C'est ce genre de mécanisme qui doit être pensé et généralisé, bien sur en s'adaptant à la problémtique !
J'ai motivé ma belle mère a prendre Ordissimo. Pourquoi ? Parce qu'elle débute l'informatique à 76 ans, qu'elle n'habite pas la même ville que moi et que je ne veux pas faire son support, je fais déjà cela toute la journée au boulot et même parfois le soir à la maison ou chez quelques potes ;-)
Donc Ordissimo m'a paru il y a 6 mois la meilleure solution et elle s'en sors pas si mal.
Il faut arrêter d'avoir peur de tout et de stresser sur le minitel 2 à la moindre annonce. Il y a des personnes qui n'y connaissent rien et qui souhaitent juste utiliser l'outil dans un cadre très simplifié. Ce genre de solution a plus de chance de leur convenir que nos distributions préférées. Tant mieux.
Je préfère voir ma belle mère profiter d'internet sur un poste adapté que de la voir bêtifier devant TF1 ;-)
Je pense que tu as parfaitement résumé la chose en une ligne. A l'époque, je me souviens, gcc ne bougeait pas et egcs apportait vraiment du plus a nos programmes. Heureusement, les personnes ont à l'époque réussit à rediscuter et à refusionner pour reformer gcc.
Cela n'a pas été le cas avec XFree ou Sodipodi qui sont toujours là malgré le fork mais ne doivent plus être très utilisé.
On verra avec cette libc. Je pense que la FSF suit cela de près et pour l'instant regarde avant de prendre une décision. Il faut voir si les personnes derrière la eglibc sont capable de faire vivre ce projet sur la durée.
Comme la eglibc a vocation a rester compatible API/ABI avec la glibc, je ne serais pas étonné qu'il y ai fusion à terme des deux projets si l'organisation de la eglibc fonctionne.
Au final, debian se simplifie la vie et remonte ainsi plus facilement ses bogues pour les partager (cf pb du bogue introduit par debian dans openssl). Par ailleurs, debian ne prends pas tant de risque que cela car le retour sur la glibc me semble toujours possible sans chambouller tout le projet.
Bref, cela a bien moins d'impact que lors du passage de la libc6 a la glibc2 qui avait foutu un bordel dans toutes les distributions. D'ailleurs, pour ceux qui se rappelle, lors de se passage à la glibc2, cela avait plusieurs fois chauffées entre la glibc et le noyau linux car linus refusait de faire des bidouilles dans le kernel dont le seul but était de contourner des bogues dans la glibc. Au final, la glibc a du corriger ses bogues...
Plutôt que des laisser la parole, Antoine a décidé de poster en tout sens et de manière peu diplomate. Que de temps en temps, les paroles dérivent car on est exaspérer lors d'une discution , OK. Mais ici notre Antoine devient franchement impolis gratuitement, voir vulgaire.
A mon sens, les termes ne sont pas forcément bien choisis pour cette action. On ferait mieux de parler d'Une Roadmap à usage prédictif pour aider les décideurs... Il faut aussi, en tant que développeur libre, comprendre un peu le contexte des pôles de compétivité, le 7 PCRD (plan de recherche Européen)... Un paquet d'argent transite par ce genre d'instance, il faut faire des dossiers, choisir... tout cela par des experts qui ne le sont pas toujours. On appelle cela le pilotage. C'est pas toujours bien fait mais d'un autre coté, on est bien content d'avoir été choisis lorsque son projet passe.
Les pôles de compétivité, l'Europe... ne peuvent pas soupoudrer l'argent du contribuable au pif. On le voit, les députés sont parfois lamentable (cf Hadopi). Il faut donc préparer le terrain et aider a ce que la direction prise soit le plus proche de celle que l'on souhaite. En gros faire du lobbying même si en France, cela a mauvaise presse.
Donc, soit tu ne fait rien, et tu n'aura rien en terme de subvention, soit tu fait des propositions concrètes qui mènent vers un avenir le plus prévisible possible.
Au final, Antoine peut vouloir d'un logiciel libre fait par des hommes libres sur leur temps libre... Mais ce n'est pas très représentatifs du logiciel libre d'aujourd'hui. C'est plus celui que j'aimais bien qui était encore la dans les années 96.
Mais pour Antoine, cela n'empêchera pas de continuer à faire du logiciel libre dans cette tradition et c'est d'aileurs ce que je fais personnellement à ma petite mesure. Mais plus il y a de projet du 7 PCRD sur le logiciel libre, plus je suis aussi content. Les deux approches sont complémentaires et doivent mutuellement se respecter.
Il n'y a pas à dire, les fichiers XML dans les fichiers de conf bas niveau sont une hérésie... Red-Hat et Novell commence a me gonfler a en mettre de partout ! Encore quelques années et on sera obliger de passer par leur cliclodrome pour gérer nos machines.
Vraiment, pas besoin de XML pour gérer un tel fichier...
Je mets à jour un poste qui sers de référence puis cfengine s'occupe du reste ;-)
Sous Linux, la mise a jour d'un logiciel propriétaire (type logiciel de calcul, par exemple matlab) signifie en pratique (cas debian) de faire la chose suivante :
- mettre à jour le dossier /opt/mon_logiciel_proprio
- mettre à jour /etc/sysprofile.d/mon_logiciel_proprio.bash
Voila. Après, je n'ai pas de logiciels proprio avec des données type base de données justement. Normalement, si c'est bien fait, on devrait avoir en plus à lancer
/opt/mon_logiciel_proprio/mise_a_jour_donnee.sh
La, effectivement, on rentre dans le spécifique et c'est parfois merdique (du fait d'une mauvaise conception du logiciel).
Un des premiers soucis des développeurs devraient être de savoir comment passer de la version n à la version n+1 facilement. Ce genre de réflexion dès le début de la conception permet d'éviter de rendre les mises à jour un enfer. Malheureusement, l'enfer signifie en pratique pas de mise à jour.
Si tu utilises un autre port, tu peux avoir des règles sur ton firewall complètement différente... Donc a mon tour de faire de l'ironie : as-tu déjà utiliser un firewall et un truc un peu mieux que la daube qui est dans XP. Par exemple, avec iptables, tu peux limiter l'accès a un port a deux nouvelles connexions max par minutes. Avec ce genre de règles qui s'écrivent facilement, tu élimines déjà 99% des attaques !
Donc oui, tout mélanger est une bétise.
Enfin, je parlais d'un ver qui cherche a rentrer et non a sortir... Mais je met aussi des règles en sortie sur mes serveurs.
Pour ce qui est de l'export de la base de registre, merci, je connais et heureusement que cela existe. Mais fait une simple action dans la configuration de Windows et dis moi ou cela se trouve dans le registre et cela sera complètement utilisable. Seule une toute petite partie de la base de registre est documenté, la grande majorité des clefs est totalement incompréhensible. Normal, il a été fait le choix de mélanger configuration et données de programme. Pour moi, c'est un défaut majeur dans la conception.
Quand à la problématique des techniciens, ta réponse est complètement à la rue. Tu passes un appel d'offre, la boite qui remporte le marché vient installer le produit et tu n'as pas le pouvoir de dire que tu veux tel ou tel technicien. Tu fait avec le technicien qu'on t'envoi pour la journée.
Pour les RPM, je suis parfaitement d'accord. Je ne suis pas fanatique des logiciels propriétaires même sous Linux car on retrouve les mêmes travers. Les techniciens n'y connaissent rien pour la plupart. Sans interface graphique, ils sont perdus. Si cela ne marchent pas, il dé-installe puis ré-installe... Bref, c'est le mauvais coté qui dérive sur Linux.
Concernant l'AD, je n'ai jamais dis que cela ne marchait pas. Les parts de marchés ne sont pas un témoin de la qualité car dans le cas présent, il y a un problème de MONOPOLE. En situation de monopole, toutes les cartes sont biaisés. Cependant, tout comme le sudo, l'AD a l'avantage de résoudre une problèmatique et il apporte une solution qui est finalement simple à mettre en oeuvre. Derrière les problèmes de conception et de sécurité, il permet a des milliers de postes d'être géré un minimum correctement. C'est donc une réponse pragmatique mais que personnellement je trouve beaucoup trop centralisé.
Et c'est très bien ainsi. Il fallait faire cela lors de la transition vers KDE4, c'était le bon moment.
Je me rappelle qu'il y a eu la même chose entre le noyau Linux et la glibc il y a quelques années. Les mecs du noyau refusait de contourner les bogues de la glibc. Cela avait été chaud. Au final, on a une glibc bien plus propre.
Les fenêtres non redimensionnable des panneaux de configuration de Windows sont effectivement totalement insupportable. Encore hier, j'ai apprécié cette fonctionalité avec msconfig ;-)
Non vraiment, les clickodromes sont conçus par des spécialistes des IHM !
Justement, la configuration en temps réel et à distance d'un serveur comme samba est une abérration. Tout passe comme crosoft dans le 135... Tu filtres comment ?
La conf d'un serveur, c'est quelque chose de statique qui ne doit pas être modifier tous les 4 matins et qui ne doit pas se faire par le même canal que le serveur lui même. Tu te vois modifier la conf apache avec des simples requêtes http ! C'est vraiment vouloir faire la pars belle aux vers, cela me semble d'une conception ultra dangeureuse.
Un fichier de conf doit être lisible pour s'imprimer. Ainsi, il est facile de comprendre pour un spécialiste pourquoi cela ne marche pas. Faire 50 copies d'écran pour comprendre la conf d'un serveur est débile. D'ailleurs sous Windows, si cela ne marche pas, le technicien dé-installe le logiciel, le ré-installe et re-clickque avec son téléphone portable à l'épaule (c'est du vécu). C'est débilifiant comme démarche.
Pour le clustering ou la répartition de charge, il ne faut pas mélanger les problèmes de fonctionnement de serveur et de configuration. Je l'ai dis pour les firewall, qu'un cluster samba échange sur un AUTRE port ce genre d'info et que samba utilise un format binaire pour gérer cela, très bien. Tout ca n'a rien a voir avec de la configuration, c'est du fonctionnement qui se ré-initialise au démarrage.
Mélanger données de fonctionnement et données de configuration, mélanger le service rendus et l'adminstration à distance dans le même canal (port), tout cela pour moi est d'une dangeureusité qui ne mérité pas les bénéfices nul que l'on peut en tirer. C'est quand même pas bien dur aujourd'hui d'ouvrir un canal spécialisé, c'est pas bien dur de faire du stockage temps réel et un fichier à plat pour la configuration... A combien de ligne de code est le cout d'avoir un système unifié ? Quel est le cout d'orthogonaliser les choses pour limiter les risques énormes ?
Bien sur, à faire cela, on se coupe de l'AD de Crosoft et des GPO... et des consoles d'administration. Or l'objectif est de fusionner tout cela. Les gens de samba veulent rentrer dans l'abération de l'AD centralisé de Microsoft.
Je n'ai pas dis que les ACL c'est mal ! Mais comme d'habitude, tu détournes. J'ai dis que le système dans Windows est trop compliqué et que quasiment personne autour de moi ne sais le gérer. As tu vu un utilisateur l'utiliser ?
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Pour Adobe, sous Linux, son installation ne fout pas le bordel dans /etc et sous Windows oui. C'est aussi simple que cela, il y a une philosophie de l'environnement sous UNIX qui demande a ne pas faire le bazard chez le voisin. Et c'est globalement respecté ! Je n'ai donc pas dis que l'OS est complètement merdique, je dis que si un grande majorité de développeur font des trucs merdiques, alors l'OS doit se remettre en cause pour essayer de comprendre pourquoi et modifier son comportement pour éviter cela dans le futur. Depuis les débuts de Windows 2000, c'est mieux mais ce n'est pas encore cela. Et je pense que sous Linux, il y a une tendance dangeureuse à prendre la voie de la complexité inutile, j'ai pris l'exemple de GNOME mais c'est effectivement le cas de samba...
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Je ne suis pas de ce mouvement et je propage/controle mes fichiers de config via cfengine sur mon parc sans soucis. Tout cela est versionner dans subversion. Bref, rien que des outils orthogonaux, simple et robuste. Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
A mon sens, les gens de samba vont mélanger configuration et partage de fichier (et fonction d'impression...) sur le même port. C'est une très mauvaise démarche. Cela me semble à l'opposé de la stratégie UNIX de la simplicité mais surtout de l'orthogonalité. Qu'un cluster samba échange entre-eux des informations de type redondance, RAID... très bien, mais cela n'a rien a voir avec de la configuration (ni le partage effectif d'ailleurs).
A ma connaissane, Microsoft a acheté RDP a Citrix... Donc c'est Citrix le créateur, pas Microsoft. D'ailleurs, Microsoft n'a pas beaucoup fait évolué RDP contrairement à Citrix qui sais gérer des fermes de machines avec équilibrage de charge lors des connexions...
* Trop de droit tue les droits. L'onglet sécurité est trop compliqué bilan quasiment personne ne l'utilise et Microsoft le cache même dans la version familiale et dans la version pro pour un poste n'étant pas dans un domaine.
* Pas d'équivalent des bits suid ou du sudo. Bilan, c'est merdique de déléguer une partie de l'administration du poste.
* Une gestion trop compliqué des comptes ou une ligne de commande merdique sur les postes de base. Bilan, les services tournent sous SYSTEM et non sur un compte spécialisé.
* Une gestion catastrophique des variables d'environnement avec un éditeur plus que pourris... heureusement on n'a de moins en moins besoin de modifier la variable Path par exemple.
* Une gestion très mauvaise de l'installation des logiciels... Aujourd'hui, chaque logiciel embarque son système de mise à jour (qui ne marche que si tu es admin) alors que l'ajout d'un simple fichier dans /etc/apt/sourcelist.d suffirait pour avoir un système de mise à jour décentralisé / centralisé fiable et sécurisé.
* Un système basé sur la prolifération des variables globales via la base de registre. Remarque, GNOME et les fanats des fichiers XML pour les config font prendre le même chemin à nos UNIX. Un exemple : il suffit de comparer la base de registre avant et après l'installation d'un logiciel Adobe pour voir la daube que peut être une base de registre...
*...
Dans ces points, si les développeurs faisaient proprement leur boulot, une partie ne serait pas la (pas exemple Adobe qui pollue la base de registre) mais en pratique, le système doit aider a avoir une pratique la plus claire et la plus simple possible. Le fonctionnement de Windows n'est pas des plus clairs si on n'est pas un spécialiste (sur ce dernier point, Linux suit la même voie lorsqu'on regarde par exemple la débilité de mettre en XML les fichiers de config de HAL... Il y a des exemples amusant sur debian en ce moment avec la configuration du clavier sous X pour ceux qui suivent leur planet !).
[^] # Re: Scandale ! :-)
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Après la Corrèze... Genève. Évalué à 1.
[^] # Re: Encore Ubuntu
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Corrèze, 1er déploiement massif du libre dans les collèges. Évalué à 1.
Je rappelle que debian est très bien ancré en europe et en france en particulier. Combien de développeurs debian en Europe et combien de développeurs mandriva ?
Et puis, il y a la Suse...
Bref, pour un ancien qui a bien connu les problèmes avec BULL et Thompson, tu nous gonfles un peu avec Mandriva à chaque fois !
[^] # Re: Centos
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 4.8. Évalué à 2.
[^] # Re: C'est pas pratique...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 7.
Parce que tu es dans un stratégie mono-utilisateur avec une vision bureau graphique et click click click...
J'ai quatre utilisateurs, je fait une file globale ?
Mes programmes tournent et font des copies, ils attendent la file globable ?
Je veux un système multi-utilisateurs, multi-tâches. Le disque n'a pas à gratter, avec le sata, l'ordonencement des ordres, les caches... normalement, c'est à l'OS de se débrouiller pour faire cela. Ici, on veut amener une fonctionalité de l'OS sur le bureau... avec un démon encore de plus.
Si l'OS ou le système de fichier sont mal conçu, modifiont les plutôt que de passer de l'énergie sur un truc réducteur et qui met en évidence la mauvaise conception de l'OS ou des applications graphiques (comme dis dans un post, ionice, cela existe).
Cela me rappelle gnome-vfs et toute cette daube inutilisable en ligne de commande mais uniquement pour les applications du bureau considérer (gnome d'un coté, kde de l'autre avec kio). L'énergie aurait du dès le début se faire sur fuse ou équivalent et donc de faire quelque chose dans la couche base.
Exemple de daube graphique. Sur une debian (je ne sais pas pour les autres), les clefs USB ne se monte pas sur le bureau si l'utilisateur est sur un annuaire de type LDAP et qu'on lui donne le groupe plugdev au lancement de la session avec pam_group. Pourquoi ? parce que tout dépend d'un démon dbus qui est lancé avant l'ouverture de session... (je crois que c'est corrigé sur ubuntu). Bref, tout cela pour dire que ces machins globaux nous compliquent la vie et que le système des droits et ainsi de suite devient de plus en plus nébuleux.
[^] # Re: Mais pourquoi ? 42
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 1.
Il faut aussi arrêter de vouloir transformer un OS multi-utilisateurs multi-tâche multi bureau en OS à variable globale mono-utilisateurs mono-bureau mono-tâche...
Les machines global avec les démons qui tournent de partout, tout cela pour que lorsque je change le paramètre epsilon, tout change d'un coup, je pense que c'est une voie très dangeureuse pour la sécurité du système.
UNIX est assez simple à la base et un des fondamentaux de la programmation est d'éviter les variables globales. Donc lorsque je lis une phrase comme celle ci-dessus, je dis danger, on est en train de partir dans une mauvaise direction et on va avoir des bureaux très sensibles aux virus si on continue dans cette direction.
[^] # Re: Contenu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Ouverture du nouveau linux.com. Évalué à 4.
Il n'empêche que j'ai vu que SystemRescueCD avait sortie une nouvelle version. J'ai donc appris quelque chose d'intéressant en allant la bas.
[^] # Re: titres
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Revue de presse de l'April pour la semaine 19. Évalué à 3.
Un peu de formatage SVP si vous souhaitez plus de lecteurs. Merci.
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Sytoka Modon (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
[^] # Re: "Aisé"?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2. Évalué à 3.
Je ne suis pas sur que Red-Hat (et Fedora) et Novell patchent moins... J'aimerais avoir des vrais statistiques que ce genre de phrase gratuite.
[^] # Re: Petit bilan pour toutes les personnes fascinées par mes problèmes
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les lampes fluocompactes, c'est mortel.. Évalué à 7.
Il serait temps de remettre les travaux manuels aux collèges et aux lycées !
[^] # Re: à propos des baïonnettes
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les lampes fluocompactes, c'est mortel.. Évalué à 4.
Une ampoule morte, on doit la prendre et en mettre une autre comme on branche un poste radio sur une prise, sans se poser de question.
Je n'ai jamais eu de soucis avec les baïonnettes alors que les ampoules à vis passent leur temps à se dévisser... Mettre une vis me semble aberrant même si c'est la norme par défaut d'aujourd'hui. Tu te vois visser la prise de ton poste radio dans le mur ? Alors pourquoi nous oblige t'on à faire cela percher sur une chaise les deux bras en l'air ?
[^] # Re: Annonce un peu hâtive ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2. Évalué à 10.
Au final, cela me donne comme pour SSH le sentiment d'un défaut de conception. Les clefs de chiffrement à usage pour le réseau devrait toujours avoir une durée de vie limitée (c'est souvent le cas des certificat X509 que le trouve pour les sites HTTPS, mais pas toujours). La durée de vie limité résout à terme le problème des failles inévitable (cf carte bleu).
La solution de la révocation n'est pas bonne car elle demande au client d'aller voir des listes centralisées, de se mettre à jour et que celui-ci ai effectivement implémenté ce mécanisme de révocation. Bref, c'est bien mais pas assez fiable pour se baser la dessus sur du long terme.
A partir du moment ou les clefs ont une durée de vie limité, il faut dès la conception penser à la mise à jour de ces clefs et assurer la période transitoire à deux clefs. C'est souvent mal fait, même sur les certificats X509. Le CNRS a d'ailleurs été confronté au passage aux certificats CNRS2 il n'y a pas longtemps et nous avons deux ans pour mettre à jour tous nos certificats dans les laboratoires. Malgré cela, pas mal d'applications n'aiment pas le changement de certificat. Par exemple, comment mettre à jour le certificat de mon serveur OCS qui me déploie mes logiciels sachant que celui-ci a soit le nouveau, soit l'ancien certificat mais ne peut pas avoir les deux ! Cela se mors la queue et je n'ai pas trouvé de bonne solution intégrée dans OCS...
Au final, je dirais qu'il y a du travail sur la planche pour que les développeurs de ces applications modifient leurs protocoles pour tenir compte de cet aspect temporel et que le protocole lui-même gère la phase de transition avec une mise à jour automatique des clients vers les nouvelles clefs et que les deux clefs soient équivalentes pour les clients. Pour le moment, un serveur web ou ssh ne peut avoir deux clefs !
Debian l'a bien compris puisque chaque distribution est lié a une et une seule clef. Lorsqu'elle sors une distribution, la clef de la future stable est déjà dans le paquetage keyring pour que la mise à jour de la stable vers la future stable (testing) puisse se faire sans hurlement de la part d'APT. C'est ce genre de mécanisme qui doit être pensé et généralisé, bien sur en s'adaptant à la problémtique !
[^] # Re: bravo
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Orange lance un terminal Internet sous GNU/linux !. Évalué à 2.
Donc Ordissimo m'a paru il y a 6 mois la meilleure solution et elle s'en sors pas si mal.
Il faut arrêter d'avoir peur de tout et de stresser sur le minitel 2 à la moindre annonce. Il y a des personnes qui n'y connaissent rien et qui souhaitent juste utiliser l'outil dans un cadre très simplifié. Ce genre de solution a plus de chance de leur convenir que nos distributions préférées. Tant mieux.
Je préfère voir ma belle mère profiter d'internet sur un poste adapté que de la voir bêtifier devant TF1 ;-)
[^] # Re: Est-ce que je suis le seul à penser à egcs?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian remplace la glibc par eglibc. Évalué à 9.
Cela n'a pas été le cas avec XFree ou Sodipodi qui sont toujours là malgré le fork mais ne doivent plus être très utilisé.
On verra avec cette libc. Je pense que la FSF suit cela de près et pour l'instant regarde avant de prendre une décision. Il faut voir si les personnes derrière la eglibc sont capable de faire vivre ce projet sur la durée.
Comme la eglibc a vocation a rester compatible API/ABI avec la glibc, je ne serais pas étonné qu'il y ai fusion à terme des deux projets si l'organisation de la eglibc fonctionne.
Au final, debian se simplifie la vie et remonte ainsi plus facilement ses bogues pour les partager (cf pb du bogue introduit par debian dans openssl). Par ailleurs, debian ne prends pas tant de risque que cela car le retour sur la glibc me semble toujours possible sans chambouller tout le projet.
Bref, cela a bien moins d'impact que lors du passage de la libc6 a la glibc2 qui avait foutu un bordel dans toutes les distributions. D'ailleurs, pour ceux qui se rappelle, lors de se passage à la glibc2, cela avait plusieurs fois chauffées entre la glibc et le noyau linux car linus refusait de faire des bidouilles dans le kernel dont le seul but était de contourner des bogues dans la glibc. Au final, la glibc a du corriger ses bogues...
[^] # Re: Les cons, ça ose tout...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel à participation pour l'élaboration de la roadmap du logiciel libre à l'horizon 2020. Évalué à 3.
A mon sens, les termes ne sont pas forcément bien choisis pour cette action. On ferait mieux de parler d'Une Roadmap à usage prédictif pour aider les décideurs... Il faut aussi, en tant que développeur libre, comprendre un peu le contexte des pôles de compétivité, le 7 PCRD (plan de recherche Européen)... Un paquet d'argent transite par ce genre d'instance, il faut faire des dossiers, choisir... tout cela par des experts qui ne le sont pas toujours. On appelle cela le pilotage. C'est pas toujours bien fait mais d'un autre coté, on est bien content d'avoir été choisis lorsque son projet passe.
Les pôles de compétivité, l'Europe... ne peuvent pas soupoudrer l'argent du contribuable au pif. On le voit, les députés sont parfois lamentable (cf Hadopi). Il faut donc préparer le terrain et aider a ce que la direction prise soit le plus proche de celle que l'on souhaite. En gros faire du lobbying même si en France, cela a mauvaise presse.
Donc, soit tu ne fait rien, et tu n'aura rien en terme de subvention, soit tu fait des propositions concrètes qui mènent vers un avenir le plus prévisible possible.
Au final, Antoine peut vouloir d'un logiciel libre fait par des hommes libres sur leur temps libre... Mais ce n'est pas très représentatifs du logiciel libre d'aujourd'hui. C'est plus celui que j'aimais bien qui était encore la dans les années 96.
Mais pour Antoine, cela n'empêchera pas de continuer à faire du logiciel libre dans cette tradition et c'est d'aileurs ce que je fais personnellement à ma petite mesure. Mais plus il y a de projet du 7 PCRD sur le logiciel libre, plus je suis aussi content. Les deux approches sont complémentaires et doivent mutuellement se respecter.
# XML
Posté par Sytoka Modon (site web personnel) . En réponse au journal Bépo et azerty en même temps !. Évalué à 2.
Vraiment, pas besoin de XML pour gérer un tel fichier...
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 2.
Sous Linux, la mise a jour d'un logiciel propriétaire (type logiciel de calcul, par exemple matlab) signifie en pratique (cas debian) de faire la chose suivante :
- mettre à jour le dossier /opt/mon_logiciel_proprio
- mettre à jour /etc/sysprofile.d/mon_logiciel_proprio.bash
Voila. Après, je n'ai pas de logiciels proprio avec des données type base de données justement. Normalement, si c'est bien fait, on devrait avoir en plus à lancer
/opt/mon_logiciel_proprio/mise_a_jour_donnee.sh
La, effectivement, on rentre dans le spécifique et c'est parfois merdique (du fait d'une mauvaise conception du logiciel).
Un des premiers soucis des développeurs devraient être de savoir comment passer de la version n à la version n+1 facilement. Ce genre de réflexion dès le début de la conception permet d'éviter de rendre les mises à jour un enfer. Malheureusement, l'enfer signifie en pratique pas de mise à jour.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 8.
Donc oui, tout mélanger est une bétise.
Enfin, je parlais d'un ver qui cherche a rentrer et non a sortir... Mais je met aussi des règles en sortie sur mes serveurs.
Pour ce qui est de l'export de la base de registre, merci, je connais et heureusement que cela existe. Mais fait une simple action dans la configuration de Windows et dis moi ou cela se trouve dans le registre et cela sera complètement utilisable. Seule une toute petite partie de la base de registre est documenté, la grande majorité des clefs est totalement incompréhensible. Normal, il a été fait le choix de mélanger configuration et données de programme. Pour moi, c'est un défaut majeur dans la conception.
Quand à la problématique des techniciens, ta réponse est complètement à la rue. Tu passes un appel d'offre, la boite qui remporte le marché vient installer le produit et tu n'as pas le pouvoir de dire que tu veux tel ou tel technicien. Tu fait avec le technicien qu'on t'envoi pour la journée.
Pour les RPM, je suis parfaitement d'accord. Je ne suis pas fanatique des logiciels propriétaires même sous Linux car on retrouve les mêmes travers. Les techniciens n'y connaissent rien pour la plupart. Sans interface graphique, ils sont perdus. Si cela ne marchent pas, il dé-installe puis ré-installe... Bref, c'est le mauvais coté qui dérive sur Linux.
Concernant l'AD, je n'ai jamais dis que cela ne marchait pas. Les parts de marchés ne sont pas un témoin de la qualité car dans le cas présent, il y a un problème de MONOPOLE. En situation de monopole, toutes les cartes sont biaisés. Cependant, tout comme le sudo, l'AD a l'avantage de résoudre une problèmatique et il apporte une solution qui est finalement simple à mettre en oeuvre. Derrière les problèmes de conception et de sécurité, il permet a des milliers de postes d'être géré un minimum correctement. C'est donc une réponse pragmatique mais que personnellement je trouve beaucoup trop centralisé.
[^] # Re: Et aussi
Posté par Sytoka Modon (site web personnel) . En réponse au journal Petit point sur le serveur X. Évalué à 4.
Je me rappelle qu'il y a eu la même chose entre le noyau Linux et la glibc il y a quelques années. Les mecs du noyau refusait de contourner les bogues de la glibc. Cela avait été chaud. Au final, on a une glibc bien plus propre.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 4.
Non vraiment, les clickodromes sont conçus par des spécialistes des IHM !
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 10.
La conf d'un serveur, c'est quelque chose de statique qui ne doit pas être modifier tous les 4 matins et qui ne doit pas se faire par le même canal que le serveur lui même. Tu te vois modifier la conf apache avec des simples requêtes http ! C'est vraiment vouloir faire la pars belle aux vers, cela me semble d'une conception ultra dangeureuse.
Un fichier de conf doit être lisible pour s'imprimer. Ainsi, il est facile de comprendre pour un spécialiste pourquoi cela ne marche pas. Faire 50 copies d'écran pour comprendre la conf d'un serveur est débile. D'ailleurs sous Windows, si cela ne marche pas, le technicien dé-installe le logiciel, le ré-installe et re-clickque avec son téléphone portable à l'épaule (c'est du vécu). C'est débilifiant comme démarche.
Pour le clustering ou la répartition de charge, il ne faut pas mélanger les problèmes de fonctionnement de serveur et de configuration. Je l'ai dis pour les firewall, qu'un cluster samba échange sur un AUTRE port ce genre d'info et que samba utilise un format binaire pour gérer cela, très bien. Tout ca n'a rien a voir avec de la configuration, c'est du fonctionnement qui se ré-initialise au démarrage.
Mélanger données de fonctionnement et données de configuration, mélanger le service rendus et l'adminstration à distance dans le même canal (port), tout cela pour moi est d'une dangeureusité qui ne mérité pas les bénéfices nul que l'on peut en tirer. C'est quand même pas bien dur aujourd'hui d'ouvrir un canal spécialisé, c'est pas bien dur de faire du stockage temps réel et un fichier à plat pour la configuration... A combien de ligne de code est le cout d'avoir un système unifié ? Quel est le cout d'orthogonaliser les choses pour limiter les risques énormes ?
Bien sur, à faire cela, on se coupe de l'AD de Crosoft et des GPO... et des consoles d'administration. Or l'objectif est de fusionner tout cela. Les gens de samba veulent rentrer dans l'abération de l'AD centralisé de Microsoft.
Moi cela ne m'intéresse pas le moins du monde.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 7.
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Pour Adobe, sous Linux, son installation ne fout pas le bordel dans /etc et sous Windows oui. C'est aussi simple que cela, il y a une philosophie de l'environnement sous UNIX qui demande a ne pas faire le bazard chez le voisin. Et c'est globalement respecté ! Je n'ai donc pas dis que l'OS est complètement merdique, je dis que si un grande majorité de développeur font des trucs merdiques, alors l'OS doit se remettre en cause pour essayer de comprendre pourquoi et modifier son comportement pour éviter cela dans le futur. Depuis les débuts de Windows 2000, c'est mieux mais ce n'est pas encore cela. Et je pense que sous Linux, il y a une tendance dangeureuse à prendre la voie de la complexité inutile, j'ai pris l'exemple de GNOME mais c'est effectivement le cas de samba...
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Je ne suis pas de ce mouvement et je propage/controle mes fichiers de config via cfengine sur mon parc sans soucis. Tout cela est versionner dans subversion. Bref, rien que des outils orthogonaux, simple et robuste. Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
A mon sens, les gens de samba vont mélanger configuration et partage de fichier (et fonction d'impression...) sur le même port. C'est une très mauvaise démarche. Cela me semble à l'opposé de la stratégie UNIX de la simplicité mais surtout de l'orthogonalité. Qu'un cluster samba échange entre-eux des informations de type redondance, RAID... très bien, mais cela n'a rien a voir avec de la configuration (ni le partage effectif d'ailleurs).
[^] # Re: Ya quoi de nouveau ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Ulteo sort la version 1.0 de son bureau à distance. Évalué à 2.
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 10.
* Pas d'équivalent des bits suid ou du sudo. Bilan, c'est merdique de déléguer une partie de l'administration du poste.
* Une gestion trop compliqué des comptes ou une ligne de commande merdique sur les postes de base. Bilan, les services tournent sous SYSTEM et non sur un compte spécialisé.
* Une gestion catastrophique des variables d'environnement avec un éditeur plus que pourris... heureusement on n'a de moins en moins besoin de modifier la variable Path par exemple.
* Une gestion très mauvaise de l'installation des logiciels... Aujourd'hui, chaque logiciel embarque son système de mise à jour (qui ne marche que si tu es admin) alors que l'ajout d'un simple fichier dans /etc/apt/sourcelist.d suffirait pour avoir un système de mise à jour décentralisé / centralisé fiable et sécurisé.
* Un système basé sur la prolifération des variables globales via la base de registre. Remarque, GNOME et les fanats des fichiers XML pour les config font prendre le même chemin à nos UNIX. Un exemple : il suffit de comparer la base de registre avant et après l'installation d'un logiciel Adobe pour voir la daube que peut être une base de registre...
*...
Dans ces points, si les développeurs faisaient proprement leur boulot, une partie ne serait pas la (pas exemple Adobe qui pollue la base de registre) mais en pratique, le système doit aider a avoir une pratique la plus claire et la plus simple possible. Le fonctionnement de Windows n'est pas des plus clairs si on n'est pas un spécialiste (sur ce dernier point, Linux suit la même voie lorsqu'on regarde par exemple la débilité de mettre en XML les fichiers de config de HAL... Il y a des exemples amusant sur debian en ce moment avec la configuration du clavier sous X pour ceux qui suivent leur planet !).
[^] # Re: Jamais content
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 2.
S'il y a un admin dans le coin qui sais déplacer un commentaire, il est le bienvenue ;-)