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 !).
Il y a maintenant quelques années, il y avait un comparatif en une gentoo et une debian, la debian étant alors compilé pour du 486 (maintenant, c'est du 586 il me semble). Grosso modo, la debian allait plus vite en moyenne...
Sur debian, seuls quelques paquets sont optimisés pour l'architecture, pour 90% des logiciels, cela ne change rien (et je suis gentils sur le 90%).
Je crois que mplayer détecte maintenant tout seul le type de processeur et optimise de lui même le code à charger... Il n'y a même plus besoin d'avoir plusieurs versions.
Bref, comme dans un code de calcul, on connait plus ou moins les goulots d'étranglement sur un poste de travail. Cabler l'AES dans le microprocesseur plus ajouter du traitement du signal vidéo pour le H264 vont à mon avis éliminer une bonne partie des ralentissements du poste de madame michu.
Lorsque tu fait des grosses modifs comme cela, tu ne les mets pas obligatoire au début puis tu les rends pas défaut lorsqu'il y a du recul dessus.
Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.
Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...
Sauf que tes propos sont légèrement péjoratif envers GNU et debian et non simplement explicatif, par exemple ton bout de phrase : <<sauf la FSF et les autres gnuistes integristes>>.
On partage ou ne partage pas la philosophie derrière GNU. Debian est effecivement une distribution qui, de ce point de vu, a toujours eu une forte personnalité et qui n'intègre dans la branche main que des choses qu'elle considère comme 'libre' selon sa propre définition.
Dis autrement, Debian a beaucoup participé à la notion même << de logiciel libre >>.
Non pas vraiment. C'est une debian donc c'est un noyau FreeBSD dans l'environnement debian basé sur GNU. Donc, ce sera normalement les mêmes paquets que sur les autres debian sauf quelques paquets spécifique pour cette architecture (pf à la place d'iptables)... Il ne s'agit donc pas de reprendre les ports FreeBSD pour relooker à la sauce apt-get, mais bien de compiler l'ensemble des paquets déjà existant dans debian sur le noyau FreeBSD. Evidement, les patch spécifique réalisé par les équipes des BSD pour que cela marche chez eux seront repris.
On peut dire que c'est une autre version de BSD mais pas complètement car la philosophie des versions debian est de s'intégrer dans l'environnement debian et il n'y a donc d'objectif de ré-écrire sous licence BSD des programmmes qui marchent déjà très bien sous licence GPL. C'est juste un exemple.
Bref, l'environnement debian va être une formidable architecture de test pour les projets logiciels car on a sous la main pas mal d'architecture matérielle et plusieurs OS sous la main. Lorsqu'un logiciel marchera sous tout cela, on peut être sur qu'un sacré paquet de bogues auront déjà été trouvé.
C'est pour bien dire que c'est le noyau de FreeBSD et non tout FreeBSD. Le premier coup, cela m'a surpris mais je pense que c'est ce qu'il y avait de meiux à faire. Sinon, on aurait cru avoir les mêmes ports que FreeBSD mais sous forme apt-get alors qu'en pratique, ce n'est pas du tout cela.
En effet, ce portage du noyau FreeBSD utilise au maximum les paquetages déjà existant chez Debian, d'ou le GNU. Evidement, il y aura des paquetages spécial pour cette architecture comme pf à la place d'iptables... Normalement, le nombre de paquetage différent va être réduit au minimum.
Au final, cette Debian a noyau FreeBSD ne devrait pas ressembler tant que cela à FreeBSD. Il y a des chances que les autres BSD ressemble plus à FreeBSD. L'environnement de la debian sera le même que sur les autres debian et sera donc complètement basé sur les composants GNU.
Sauf que le bind dans le chroot n'est pas mis a jour aussi facilement que les binaires de la distribution... Bref, j'ai vu des bind en chroot qui n'étaient clairement plus mis à jour.
Si chroot, bien penser à la procédure de mise à jour de tout ce qui est dans le chroot.
Je ne suis pas spécialiste des BSD mais par exemple avec Debian, on peut avoir le paquet machin avec à coté machin-dbg, machin-doc, machin-dev, libmachin et libmachin-dev. Selon la manière dont est saucissonné un paquet, on arrive à des chiffres assez différent.
Le nombre de paquetage d'une distribution est donc juste une indication mais il ne faut pas toujours prendre cette valeur pour une référence absolue.
Ceci dis, je ne suis pas surpris que NetBSD est moins de paquetage que FreeBSD.
A terme, on aura un système BSD qui se gère comme une debian avec le même installateur... On pourra avoir une machine virtuelle BSD comme on a des LINUX.
C'est tout simplement génial d'avoir plusieurs noyaux pour un même environnement. Je ne suis pas du tout sur que cela reste anecdotique. Il est possible que cette version BSD prenne une place importante dans le paysage.
Il faut voir le nombre d'outil qui gravite autour de debian et qui vont à terme marcher pareil sur ce noyau.
Bon, étant enthousiasmé, j'avoue ne pas être objectif.
> Ah, et quelle implémentation robuste y a-t-il à l'heure actuelle ?
Aucune puisque justement, la version 1 indique qu'a partir de maintenant, on peut essayer de faire du robuste !
Quand a PyPy, si tu penses réellement que ce que tu annonces pour lui le rend plus ambitieux que de concevoir une machine virtuelle à pile qui soit générique pour tous les langages de script, libre à toi. Il ne faut pas cependant que le Python te voile l'objectivité.
Parrot a été imaginé pour faire tourner tant Perl que Python, que Tcl...
C'est la première machine virtuelle conçu collaborativement et spécifiquement pour les langages de script. Alors non, je n'accepte pas ton déni : "Yet Another Virtual Machine". C'est vraiment du n'importe quoi.
Si vous arrêtiez de déformer mes propos et si vous lisiez un peu mieux ce que j'écris, vous verriez que
-1- je n'agresse pas les gens
-2- je n'ai jamais dis que l'américain est une langue séparée de l'anglais
Donc reprenons. Au québec, les personnes ne parlent pas le francais de la métropole. Tu peux appeller cela le québecois ou le français du québec ou ce que tu veux. Donc je dis qu'ils ne parlent pas le francais de la métropole qui est le francais majoritaire. Donc le québecois est une variante du francais de métropole que pour simplifier et parce que nous sommes en métropole, nous appelons par simplification 'francais' tout court.
C'est pareil pour l'américain qui est une variante de l'anglais. Sauf que l'américain est majoritaire et que c'est ce que nous parlons globalement dans les échanges internationnaux. Les commentaires des codes sont principalement en américain, variante de l'anglais car celui-ci est le mieux parlé de par le monde.
Après, que vous ayez tous des noeuds parce que je dis que les commentaires sont en américain et pas en anglais, c'est votre problème. Cela commence à faire pas mal de fois que j'explique ma position dans ce post et que vous détournez le sujet pour essayer de monter les gens les uns contre les autres. Cela ne m'interesse pas.
Aujourd'hui, c'est l'américain, variante de l'anglais, qui est majoritairement parlé que vous le vouliez ou non. Les commentaires de mes codes, je l'ai fait en américain et non en anglais car pour moi, l'anglais tout court, c'est l'anglais de la grande bretagne et je ne le maîtrise pas.
Alors si tu veux, tu fait tes commentaires en anglais variante nord-américaine... Moi, je préfère appeller un chat un chat et dire que je les fait en américain directement. En pratique, nous faisons la même chose.
Je n'ai pas parlé de politique dans mon post et je n'ai aucun problème pour en parler sur linuxfr lorsque je le désire. Donc s'il te plait, n'insinue pas des choses et prends en la responsabilité si tu souhaites mettre le débat sur ce sujet là.
Moi, je dis juste que la majorité des gens pensent parler anglais alors qu'ils parlent américain. C'est tout. Si tu penses que dire cela, c'est faire de la politique, nous n'avons pas la même vision de la politique. Je fais juste une constatation.
Après on peut faire de la linguistique et parlé de frontière... Tu as toujours des cas particuliers qui sont à cheval.
Enfin, nous sommes d'accord sur un point : "Donc la variante commune est l'anglais nord-américain, qui a le bon goût d'être compris par la majorité des anglophones". En effet, c'est actuellement le dialecte international qui est parlé sur le continent nord américain. Heureusement que les anglais de souche comprennent ce dialecte (puisque même une grande partie des francais aussi ;-) ).
J'ai déjà fait des sites web en anglais et en 'anglais nord américain', il y a pas mal de mot qui change au niveau des menus... et dans le texte. Si tu es capable de basculer de l'un vers l'autre, tant mieux pour toi. Moi personnellement, je n'y arrive pas et je pense que nous sommes une grande majorité dans ce cas.
La question ne se pose pas. Lorsque le Français était la langue internationale, c'était le Français de métropole.
Par ailleurs, dans la cadre du francais, le francais de métropole est majoritaire. Le québécois, le belge... sont donc des variantes.
En ce qui concerne la langue que nous utilisons pour dialoguer à l'intertationale, c'est un charabia qui a plus une base proche de l'américain que de l'anglais. L'américain est un dérivée de l'anglais mais il est devenu majoritaire de nos jours.
Quand un anglais entend notre chariabia, il saute en l'air.
Bref, pour ces bonnes et mauvaises raisons, il est à mon sens préférable de dire que l'américain est la langue dominante et non l'anglais. Si le québécois le devient un jour, cela ne me dérange pas qu'on dise le québecois plutôt que le français. Mais bon, je pense que la future langue internationnale sera l'espagnol... Cela pourrait être le chinois mais c'est trop compliqué pour vraiment se généraliser et même en chine, il y a plusieurs chinois...
[^] # 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 ;-)
[^] # Re: Gains de performance
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 8.
Sur debian, seuls quelques paquets sont optimisés pour l'architecture, pour 90% des logiciels, cela ne change rien (et je suis gentils sur le 90%).
Je crois que mplayer détecte maintenant tout seul le type de processeur et optimise de lui même le code à charger... Il n'y a même plus besoin d'avoir plusieurs versions.
Bref, comme dans un code de calcul, on connait plus ou moins les goulots d'étranglement sur un poste de travail. Cabler l'AES dans le microprocesseur plus ajouter du traitement du signal vidéo pour le H264 vont à mon avis éliminer une bonne partie des ralentissements du poste de madame michu.
# 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é à 9.
Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.
Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Oracle achète Sun. Évalué à 6.
[^] # Re: Falcon ou InnoDB ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Oracle achète Sun. Évalué à 10.
Abandonner Linux est à mon avis sucidaire pour eux.
Pour Btrfs, j'ai pas d'avis tranché... C'est vrai que passer le code de ZFS en GPL (ou BSD) pourrait être plus simple...
[^] # Re: Cooool, on vient d'inventer un nouveau troll totalement inutile.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Night of the living BSDeads. Évalué à 3.
On partage ou ne partage pas la philosophie derrière GNU. Debian est effecivement une distribution qui, de ce point de vu, a toujours eu une forte personnalité et qui n'intègre dans la branche main que des choses qu'elle considère comme 'libre' selon sa propre définition.
Dis autrement, Debian a beaucoup participé à la notion même << de logiciel libre >>.
[^] # Re: C'est d'autant plus vrai que ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Night of the living BSDeads. Évalué à 7.
Non pas vraiment. C'est une debian donc c'est un noyau FreeBSD dans l'environnement debian basé sur GNU. Donc, ce sera normalement les mêmes paquets que sur les autres debian sauf quelques paquets spécifique pour cette architecture (pf à la place d'iptables)... Il ne s'agit donc pas de reprendre les ports FreeBSD pour relooker à la sauce apt-get, mais bien de compiler l'ensemble des paquets déjà existant dans debian sur le noyau FreeBSD. Evidement, les patch spécifique réalisé par les équipes des BSD pour que cela marche chez eux seront repris.
On peut dire que c'est une autre version de BSD mais pas complètement car la philosophie des versions debian est de s'intégrer dans l'environnement debian et il n'y a donc d'objectif de ré-écrire sous licence BSD des programmmes qui marchent déjà très bien sous licence GPL. C'est juste un exemple.
Bref, l'environnement debian va être une formidable architecture de test pour les projets logiciels car on a sous la main pas mal d'architecture matérielle et plusieurs OS sous la main. Lorsqu'un logiciel marchera sous tout cela, on peut être sur qu'un sacré paquet de bogues auront déjà été trouvé.
[^] # Re: Architecture vs paquet
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 2.
En effet, ce portage du noyau FreeBSD utilise au maximum les paquetages déjà existant chez Debian, d'ou le GNU. Evidement, il y aura des paquetages spécial pour cette architecture comme pf à la place d'iptables... Normalement, le nombre de paquetage différent va être réduit au minimum.
Au final, cette Debian a noyau FreeBSD ne devrait pas ressembler tant que cela à FreeBSD. Il y a des chances que les autres BSD ressemble plus à FreeBSD. L'environnement de la debian sera le même que sur les autres debian et sera donc complètement basé sur les composants GNU.
[^] # Re: Parce que
Posté par Sytoka Modon (site web personnel) . En réponse au message Pourquoi chrooter bind ?. Évalué à 6.
Si chroot, bien penser à la procédure de mise à jour de tout ce qui est dans le chroot.
[^] # Re: Intérêt ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 3.
Le nombre de paquetage d'une distribution est donc juste une indication mais il ne faut pas toujours prendre cette valeur pour une référence absolue.
Ceci dis, je ne suis pas surpris que NetBSD est moins de paquetage que FreeBSD.
[^] # Re: Intérêt ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 8.
C'est tout simplement génial d'avoir plusieurs noyaux pour un même environnement. Je ne suis pas du tout sur que cela reste anecdotique. Il est possible que cette version BSD prenne une place importante dans le paysage.
Il faut voir le nombre d'outil qui gravite autour de debian et qui vont à terme marcher pareil sur ce noyau.
Bon, étant enthousiasmé, j'avoue ne pas être objectif.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 1.
Aucune puisque justement, la version 1 indique qu'a partir de maintenant, on peut essayer de faire du robuste !
Quand a PyPy, si tu penses réellement que ce que tu annonces pour lui le rend plus ambitieux que de concevoir une machine virtuelle à pile qui soit générique pour tous les langages de script, libre à toi. Il ne faut pas cependant que le Python te voile l'objectivité.
Parrot a été imaginé pour faire tourner tant Perl que Python, que Tcl...
C'est la première machine virtuelle conçu collaborativement et spécifiquement pour les langages de script. Alors non, je n'accepte pas ton déni : "Yet Another Virtual Machine". C'est vraiment du n'importe quoi.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 0.
-1- je n'agresse pas les gens
-2- je n'ai jamais dis que l'américain est une langue séparée de l'anglais
Donc reprenons. Au québec, les personnes ne parlent pas le francais de la métropole. Tu peux appeller cela le québecois ou le français du québec ou ce que tu veux. Donc je dis qu'ils ne parlent pas le francais de la métropole qui est le francais majoritaire. Donc le québecois est une variante du francais de métropole que pour simplifier et parce que nous sommes en métropole, nous appelons par simplification 'francais' tout court.
C'est pareil pour l'américain qui est une variante de l'anglais. Sauf que l'américain est majoritaire et que c'est ce que nous parlons globalement dans les échanges internationnaux. Les commentaires des codes sont principalement en américain, variante de l'anglais car celui-ci est le mieux parlé de par le monde.
Après, que vous ayez tous des noeuds parce que je dis que les commentaires sont en américain et pas en anglais, c'est votre problème. Cela commence à faire pas mal de fois que j'explique ma position dans ce post et que vous détournez le sujet pour essayer de monter les gens les uns contre les autres. Cela ne m'interesse pas.
Aujourd'hui, c'est l'américain, variante de l'anglais, qui est majoritairement parlé que vous le vouliez ou non. Les commentaires de mes codes, je l'ai fait en américain et non en anglais car pour moi, l'anglais tout court, c'est l'anglais de la grande bretagne et je ne le maîtrise pas.
Alors si tu veux, tu fait tes commentaires en anglais variante nord-américaine... Moi, je préfère appeller un chat un chat et dire que je les fait en américain directement. En pratique, nous faisons la même chose.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à -1.
Moi, je dis juste que la majorité des gens pensent parler anglais alors qu'ils parlent américain. C'est tout. Si tu penses que dire cela, c'est faire de la politique, nous n'avons pas la même vision de la politique. Je fais juste une constatation.
Après on peut faire de la linguistique et parlé de frontière... Tu as toujours des cas particuliers qui sont à cheval.
Enfin, nous sommes d'accord sur un point : "Donc la variante commune est l'anglais nord-américain, qui a le bon goût d'être compris par la majorité des anglophones". En effet, c'est actuellement le dialecte international qui est parlé sur le continent nord américain. Heureusement que les anglais de souche comprennent ce dialecte (puisque même une grande partie des francais aussi ;-) ).
J'ai déjà fait des sites web en anglais et en 'anglais nord américain', il y a pas mal de mot qui change au niveau des menus... et dans le texte. Si tu es capable de basculer de l'un vers l'autre, tant mieux pour toi. Moi personnellement, je n'y arrive pas et je pense que nous sommes une grande majorité dans ce cas.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 1.
Par ailleurs, dans la cadre du francais, le francais de métropole est majoritaire. Le québécois, le belge... sont donc des variantes.
En ce qui concerne la langue que nous utilisons pour dialoguer à l'intertationale, c'est un charabia qui a plus une base proche de l'américain que de l'anglais. L'américain est un dérivée de l'anglais mais il est devenu majoritaire de nos jours.
Quand un anglais entend notre chariabia, il saute en l'air.
Bref, pour ces bonnes et mauvaises raisons, il est à mon sens préférable de dire que l'américain est la langue dominante et non l'anglais. Si le québécois le devient un jour, cela ne me dérange pas qu'on dise le québecois plutôt que le français. Mais bon, je pense que la future langue internationnale sera l'espagnol... Cela pourrait être le chinois mais c'est trop compliqué pour vraiment se généraliser et même en chine, il y a plusieurs chinois...