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...
Remettons les choses au clair. Ce n'est pas l'anglais la langue internationale en ce moment mais l'américains qui est un dérivée de l'anglais.
Plein de mots sont différents entre l'anglais et l'américains. Je sais pour avoir eu des anglais à coté de moi que je parle plutôt l'américains (comme un pied) que l'anglais et que cela est valable pour une très grande partie des chercheurs que je cotois. Je ne vois pas pourquoi cela serait différent dans le monde de l'entreprise.
Donc on répète tous ensenmble : << La langue dominante de nos jours est l'américains >>.
> Parrot est significativement plus rapide que Python
Ben c'est déjà pas mal pour un projet communautaire dans sa version 1 dont l'objectif premier n'est pas la production mais d'avoir des implémentations robustes de langage de script qui tourne dessus.
En parallèle, évidement que la machine Parrot va être encore optimisé.
Sinon, je ne vois pas en quoi PyPy est autrement plus ambitieux ? Je suis désolé mais Parrot a une dimension universelle que je ne vois pas du tout dans PyPy. Les deux projets me paraissent sans commune mesure.
Avant, j'allais voir du coté de Perl6 mais il ne m'a fallu plus de 10 mn pour déjà trouver tout cela.
Les mailings lists et les planets de Perl6 et de Parrot étaient bien entrelacé jusqu'a la version 1 de Parrot. C'est un peu logique car les deux se sont mutuellement aidés pour améliorer leur design (et puis ce sont quasiment les mêmes personnes).
Avec Parrot 1.0, Perl 6 est dans sa ligne droite finale pour sortir en fin d'année une remière version utilisable.
Les planets et les mailling list vont se séparer naturellement.
Encore une fois, les personnes de Google savent parfaitement cela. Il n'est pas imaginable que personne chez Google n'ait suivis de près la co-conception par la communauté de Parrot et de Perl. C'est un évènement suffisament rarissime pour avoir un oeil qui suit cela.
Cela n'a rien a voir. Derrière Java il y avait tout le marketing SUN qui voulait nous faire croire qu'il avait tout inventé et que c'était trivial.
Derrière Parrot, il y a une communauté, surtout porté par Perl au début mais dont l'objectif est d'être de plus en plus autonome. D'ailleurs, les sites Web de parrot et de Perl6 sont maintenant distinct.
Encore une fois, il ne s'agit pas d'un petit projet porté par une petite boite mais de Google ! Ce n'est pas un projet avec un objectif à six mois d'après ce que j'ai compris.
Personne n'a dis d'utiliser la version 1 de Parrot pour faire de la production. Non, la version 1 est faite pour que les langages de scripts essayent de faire une implémentation sur Parrot afin de voir en grandeur nature ce que donne Parrot.
Il est assez facile d'avoir des info sur Parrot même si le site web n'est pas son fort. Parrot vient de sortir en version 1.0 Pour une entreprise comme Google et ayant forcément des informaticiens bon (très bon) en Perl, ils ne peuvent pas ne pas être au courant de l'état de Parrot.
En plus, Parrot est au GSoC.
Bref, ma remarque est à lire dans le contexte de Google et non d'une boite lambda.
[^] # 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...
[^] # 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é à -3.
Plein de mots sont différents entre l'anglais et l'américains. Je sais pour avoir eu des anglais à coté de moi que je parle plutôt l'américains (comme un pied) que l'anglais et que cela est valable pour une très grande partie des chercheurs que je cotois. Je ne vois pas pourquoi cela serait différent dans le monde de l'entreprise.
Donc on répète tous ensenmble : << La langue dominante de nos jours est l'américains >>.
[^] # 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é à 2.
Ben c'est déjà pas mal pour un projet communautaire dans sa version 1 dont l'objectif premier n'est pas la production mais d'avoir des implémentations robustes de langage de script qui tourne dessus.
En parallèle, évidement que la machine Parrot va être encore optimisé.
Sinon, je ne vois pas en quoi PyPy est autrement plus ambitieux ? Je suis désolé mais Parrot a une dimension universelle que je ne vois pas du tout dans PyPy. Les deux projets me paraissent sans commune mesure.
[^] # 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é à 3.
http://www.parrot.org
Les objectifs de la version 1_0
http://www.parrot.org/news/vision-for-1_0
La doc de Parrot
http://docs.parrot.org/parrot/latest/html/
Le trac de Parrot
https://trac.parrot.org
Les bug
https://trac.parrot.org/parrot/report
Pour soumettre un bogue
http://docs.parrot.org/parrot/latest/html/docs/submissions.p(...)
Les langages utilisant Parrot
http://www.parrot.org/languages
Le 'planet' de Parrot
http://planet.parrotcode.org/
...
Avant, j'allais voir du coté de Perl6 mais il ne m'a fallu plus de 10 mn pour déjà trouver tout cela.
Les mailings lists et les planets de Perl6 et de Parrot étaient bien entrelacé jusqu'a la version 1 de Parrot. C'est un peu logique car les deux se sont mutuellement aidés pour améliorer leur design (et puis ce sont quasiment les mêmes personnes).
Avec Parrot 1.0, Perl 6 est dans sa ligne droite finale pour sortir en fin d'année une remière version utilisable.
Les planets et les mailling list vont se séparer naturellement.
Encore une fois, les personnes de Google savent parfaitement cela. Il n'est pas imaginable que personne chez Google n'ait suivis de près la co-conception par la communauté de Parrot et de Perl. C'est un évènement suffisament rarissime pour avoir un oeil qui suit cela.
[^] # 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é à 2.
Derrière Parrot, il y a une communauté, surtout porté par Perl au début mais dont l'objectif est d'être de plus en plus autonome. D'ailleurs, les sites Web de parrot et de Perl6 sont maintenant distinct.
Encore une fois, il ne s'agit pas d'un petit projet porté par une petite boite mais de Google ! Ce n'est pas un projet avec un objectif à six mois d'après ce que j'ai compris.
Personne n'a dis d'utiliser la version 1 de Parrot pour faire de la production. Non, la version 1 est faite pour que les langages de scripts essayent de faire une implémentation sur Parrot afin de voir en grandeur nature ce que donne Parrot.
[^] # Re: BIOS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mort au bip. Évalué à 2.
[^] # Re: BIOS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mort au bip. Évalué à 2.
Bref, EFI, j'ai une machine Itanium avec et je ne trouve pas que ce soit mieux que le BIOS.
[^] # 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é à 2.
En plus, Parrot est au GSoC.
Bref, ma remarque est à lire dans le contexte de Google et non d'une boite lambda.