En pratique, c'est du Fortran donc ifort et non icc. Or g95 ou gfortran ne sont pas encore au niveau de ifort, notament si on utilise les bibliothèque OpenMP et MPI du constructeur.
Par ailleurs, mes chercheurs ont tendance a travailler en temps constant. C'est à dire que quel que soit la machine, il s'arrange pour avoir un calcul qui dure toujours le même temps. Donc un programme 20% moins rapide signifie en pratique que le problème étudié sera plus petit.
Exact, c'est pas mal. Il manque le redimensionnement qui est bien pratique avec les appareils qui ont plus de pixel que nécessaire pour un phtot à imprimer sur petit format. Cela permet de faire le zoom au dernier moment (dans sans perte ni occupation de place sur le disque dur).
Dans le logiciel canon, il y avait en plus du cadre rouge, un sous grille en pointillé découpant la photo en 9 partie égale. Pour positionner le cadre et équilibré la photo, c'était bien pratique.
Merci
PS : le logiciel Canon permettait aussi d'imprimer à des formats non standard ce qui m'était très pratique car j'aime bien imprimer sur 100% de la page même si la photo n'est pas au final sur une dimension normalisée.
Il faut que je regardes plus ce digikam. Je me suis toujours arrété au fait qu'il me lance le bazard kde au démarrage (désolé, je n'aime ni le bazard gnome ni celui de kde. J'ai les applications dans la bonne tradition UNIX qui n'ont pas besoin de gconf ou de kdeinit...).
Ce digikam, il est capable de regarder des photos dans un dossier ou il faut absolument lui créer des albums... C'est cela qui est pénible avec lui. On a envie d'ouvrir un dossier et de voir les photos, un peu comme gqview.
Bon, allez, je vais quand même essayer de franchir la première étape suite à son lancement.
J'avais il y a quelques années un imprimante Canon avec un logiciel SUPER sous Windows.
Ce logiciel permettait d'imprimer des photos couleurs et de ne faire que cela. Pas de retouche et autre. Je veux juste un logiciel qui imprime mes photos.
Voila les contraintes et il les réalisais toutes :
- selections de n photos et posibilités de modifier l'ordre.
- mettre 1, 2, 4 ou 8 photos par pages, AVEC ou SANS marge.
- redimentionner, zoomer chaque photo AU DERNIER MOMENT en restant dans le même ratio x/y. Pas de déformation de la photo.
En gros, il faisait une espèce de diaporama multi-page et lorsqu'on était content, on imprimait.
J'utilise Linux depuis plus de 10 ans quasiment à temps plein mais je n'ai jamais réussit à trouver un logiciel corret pour imprimer des photos.
Le seul problème du logiciel Canon, il ne marche que sous Windows et QUE pour les imprimantes Canon. C'est débile comme vérrou.
> Un très bon argument en faveur du multi-plateformes est que cela
> permet de détecter beaucoup plus de bugs et donc d'améliorer a
> robustesse du kernel.
C'est vrai. Dans le cas du PC, il y a aussi une grande variété des matériels.
Si on regarde du coté des UNIX propriétaires, on remarque que le matériel était relativement homogène.
Donc, la manière de développer ainsi que le nombre de développeur permettent a mon sens de modérer tes propos.
> C'est quand même un très vilain hack
Oui, mais dans ce cas, on ne fait pas du x86 ! Le x86 est l'architecture la plus pourri des années 80. Le Z80 et le 6502 était bien mieux.
Le x86 a su dépasser la barrière des 640Ko sans que l'utilisateur soit trop pénalisé. Avec PAE, on franchi aujourd'hui la barrière des 4Go. De toute manière, c'est la plateforme x86 qui est contrainte à mort.
Si tu veux un truc propre, tu pars sur de l'Itanium ! Malheureusement, Intel vend trop de x86 du coup, il doit y avoir 100 fois plus d'ingénieur sur les puces x86 que sur l'Itanium.
Heureusement, l'architecture ARM est passé devant la x86 depuis quelques temps.
Effectivement, dans le classement de l'efficacité des machines, on ne retrouve pas IBM en premier mais NEC avec ses machines vectorielles puis SGI avec ses Altix.
Comme quoi, il faut toujours se méfier de la manière dont est réalisée un classement ou un comparatif.
A mon avis, ce n'est Windows qui ne tourne pas mais surtout les applications. MS ne peut pas mettre un Windows sur le marché si SQL Server, Exchange, Office... ne tournent pas bien, mais aussi les applications principales des éditeurs comme Adobe, Oracle...
Au niveau Linux et des *BSD, les OS tournent mais pas toujours les applications. Il suffit de prendre OpenOffice comme exemple...
MS ayant une stratégie purement commerciale, je la comprends un peu car je ne vois pas ce que lui apporte d'avoir un Windows multi-plateforme à part avoir plus de soucis. En plus, en temps qu'Ingénieur Sytème, je dois dire que la version 64 bits de XP me fait plus ch... qu'autre chose. Par ailleurs, avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM qui devenait bloquante en 32 bits (par exemple, mes serveurs Xen tournent très bien sous Debian 32 bits avec 6 Go de RAM).
Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows. Ici le problème est différent de celui de la machine de bureau ou du petit serveur rack et il n'y a pas une architecture qui domine depuis des années. MS est donc obligé de s'adapter comme tout le monde à l'évolution rapide des architectures embarquées.
Par rappport à la dépêche que j'avais proposé (qui était pas si mal rédigé, snif snif...), le point que j'avais laissé de coté est la partie Itanium.
GCC était complètement largué sur Itanium par rapport au compilateur Intel car l'architecture EPIC oblige le compilateur à faire le boulot de l'optimisation des instructions. En effet, si on regarde l'architecture d'un Itanium par rapport à un x86, c'est beaucoup plus simple et du coup, Intel peut mettre bien plus de cache pour la même surface de silicium.
Cependant, on est en pratique obligé de travailler avec le compilateur Intel... J'espère que l'accélération dù à la version 4.2 va nous permettre de retravailler avec gcc.
Tu dis à peu près la même chose que moi. En effet, OpenMP est plus simple à mettre en oeuvre sur un Quad-Core, mais dans ce cas là, tu n'a pas 100 tâches mais au plus 4 (si tu te débrouilles bien car au dela, tu charge trop la machine et tu perds en global à cause des caches).
Maintenant, il n'y a pas beaucoup de machine SMP à 1000 coeurs (je connais les Altix de SGI par exemple). Ce sont souvent des clusters et donc les programmes sont réalisés avec MPI.
OpenMP est en effet bien plus simple à mettre en oeuvre et permet de gagner facilement du temps de calcul. Comme nous avons tous des machines SMP aujourd'hui, cette bibliothèque va être de plus en plus fondamentale sur le bureau.
Mais pour les gros calculs malheureusement, il faut plus se pencher sur ses algorithmes et prendre le temps de faire du MPI.
Pour les calculs titanesques (future machine pétaflop), il faut trouver une nouvelle manière de programmer. Ce n'est pas moi qui le dis, ce sont des spécialistes que j'ai rencontrer. Personnellement, je n'ai pas accès à des machines ayant plus de 32 coeurs... Je n'ai donc pas idée des réels problèmes qui se posent.
En effet, il n'y a quasiment aucun programme qui pourrait partie de 100% de la puissance d'une machine pétaflop aujourd'hui. Il n'y a donc pas encore de réel intérêt à construire une telle machine.
OpenMP permet de faire du calcul parallèle relativement facilement, c'est plutôt orienté pour les machines SMP comme par exemple les PC bi-processeurs dual-core. En effet, les quadri-coeur x86 ne sont pas encore au point pour le calcul intensif, notament à cause du goulet d'étrangement pour l'accès à la mémoire.
Sur plateforme Itanium, il y a de belles machines SMP, par exemple, les Altix de SGI qui permettent d'avoir en SMP plus de 4000 noeuds ! Heureusement, la gamme Altix permet de commencer plus modestement dans le SMP.
Pour finir, si on veut vraiment faire un programme parallèle sur les GROSSES machines, il vaut mieux se tourner vers la bibliothèque MPI. Très peu de programme OpenMP dépasse les 100 tâches sans perte de performance alors que MPI permet d'aller jusqu'a 1000 tâches. Au dela des 1000 tâches, de nos jours, très peu de programmes sont efficases et il y a un gros boulot d'ingénierie pour trouver des solutions.
En conclusion, pour le bureau et 99% des applications, OpenMP, c'est bon, mangé en ;-)
Je n'aime pas cette idée de compiler son gestionnaire de fenêtre pour le configurer. C'est ingérable pour les postes multi-utilisateurs... même si c'est bien pour l'embarqué.
Bien que le fait de ne pas avoir de cadre prédéfinit dans wmii me gêne, cela fait maintenant 15 jours que je suis dessus et il est parfois plus pratique que ion, notamment au niveau des fenêtres flotantes. J'aime bien aussi sa notion de pile de fenêtre. Comme quasiment toutes mes fenêtres sont des 'xterm', le fait de ne découper l'écran que verticalement ne me gène pas plus que cela.
En plus, la manière de configurer wmii est assez marrante. Cela change des autres getsionaires de fenêtre. J'étais pas fanatique au début mais je trouve cela assez efficase au final.
J'avoue que comme peck, je trouve que ton lien pointe vers un comparatif pas franchement explicite ;-)
Sinon, LibreSource, il peut prendre un trac en entrée pour en faire un LibreSource. Je pose la question à tout hasard pour mes trac mais aussi parce que les sites tournant sous trac pullulent sur le net aujourd'hui. C'est d'ailleurs une des raisons de mon choix vers trac, cela semble un petit outil pérenne et où j'ai pris mes marques très rapidement.
Personnellement, j'utilise trac qui fait moins de choses me semble-t-il mais qui a l'air aussi plus léger. C'est juste du python au dessus d'apache. Par ailleurs, j'ai l'impression que trac est mieux intégré à subversion que LibreSource mais peut être que je me trompe.
Pour les petits projets que nous développons, il est clair qu'avoir un forum, de la messagerie instantanée... c'est bien mais pour les utilisateurs, cela commence à faire pas mal d'outil à maitriser.
Au moins avec trac, les utilisateurs utilisent une bonne partie de la plateforme.
Il est vrai que j'ai d'autres plateformes et que je ne souahite pas non plus que tout tourne autour de trac dans mon laboratoire de recherche...
J'avoue que c'est un des défauts des BSDistes, trop d'humour à toutes les lignes, ceal finit par me saturer et me donner une impression plutôt désagréable de secte.
Le 'camel book' n'était pas du tout comme cela, en tout cas l'édition 2. Au contraire, il y a dans ce livre de l'humour mais bien enrobé dans des phrases bien faites. Du coup, on ne voit pas toujours le second sens du premier coup. C'est beaucoup plus subtil je trouve.
Bref, pour moi, trop de BSD tue le BSD. Je ne sais pas lequel essayer en fin de compte. Surtout que j'ai été vachement deçu qu'OpenBSD ne tourne pas sous Xen.
Comment un système automatique décide pour un système multi-écran ?
Imaginons trois écrans, deux en xinerama pour une personne et l'autre pour une autre personne. Comment faire la configuration ? Etant l'utilisateur B, je refuse que l'utilisateur A puisse modifier la configuration générale.
Bref, des parametrage plus simple, ok, mais ne tombons pas dans le piège de Windows et d'Apple. Une machine UNIX se doit d'être multi-utilisateur dans son principe et l'utilisateur ne doit pas avoir par défaut les droits d'administration.
Si cette dérive est faite, les virus et autres cochonneries envahiront notre plateforme.
Je suis assez d'accord. Je ne comprends rien au python et je ne le trouve pas propre du tout avec ces __MACHIN__
Un truc super en perl c'est qu'une variable scalaire commence par un $. Cela, c'est vachement bien de séparer les variables des mots clefs.
Comme il a été dis, en perl6, ils ont éliminé pas mal de truc pas propre mais il est possible déjà de faire propre en perl5. Il suffit d'utiliser les bons modules.
Enfin, un gros avantages du perl, les programmes que j'ai fait il y a 10 ans en perl5_004 marche toujours tel quel !
Bref, il est de bon ton de critiquer perl de nos jours, surtout sur dlfp, notamment pour pousser vers python. Quand je vois dans une debian le nombre de version de python et les incompatibilités entre elles, personnellement, je n'ai pas envie d'en faire.
La radio n'est pas morte malgré tout ce qui a été prédis. C'est très pratique de ne pas avoir à faire sa programmation et d'écouter autre chose.
A une époque, erreur404 diffusais aussi de la vidéo. C'est pas extraordinaire comme film mais bon, Je vois que sur leur site, il dise que tv404, c'est de nouveau pour bientôt, mais sans date précise.
[^] # Re: Itanium
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 4.
Par ailleurs, mes chercheurs ont tendance a travailler en temps constant. C'est à dire que quel que soit la machine, il s'arrange pour avoir un calcul qui dure toujours le même temps. Donc un programme 20% moins rapide signifie en pratique que le problème étudié sera plus petit.
[^] # Re: Itanium
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 4.
C'est pour cela que sur Itanium, on utilise ICC et non GCC.
[^] # Re: Impression photo
Posté par Sytoka Modon (site web personnel) . En réponse au journal Migrer de Windows Xp à Kubuntu... Évalué à 2.
Dans le logiciel canon, il y avait en plus du cadre rouge, un sous grille en pointillé découpant la photo en 9 partie égale. Pour positionner le cadre et équilibré la photo, c'était bien pratique.
Merci
PS : le logiciel Canon permettait aussi d'imprimer à des formats non standard ce qui m'était très pratique car j'aime bien imprimer sur 100% de la page même si la photo n'est pas au final sur une dimension normalisée.
[^] # Re: Impression photo
Posté par Sytoka Modon (site web personnel) . En réponse au journal Migrer de Windows Xp à Kubuntu... Évalué à 2.
Ce digikam, il est capable de regarder des photos dans un dossier ou il faut absolument lui créer des albums... C'est cela qui est pénible avec lui. On a envie d'ouvrir un dossier et de voir les photos, un peu comme gqview.
Bon, allez, je vais quand même essayer de franchir la première étape suite à son lancement.
# Impression photo
Posté par Sytoka Modon (site web personnel) . En réponse au journal Migrer de Windows Xp à Kubuntu... Évalué à 2.
Ce logiciel permettait d'imprimer des photos couleurs et de ne faire que cela. Pas de retouche et autre. Je veux juste un logiciel qui imprime mes photos.
Voila les contraintes et il les réalisais toutes :
- selections de n photos et posibilités de modifier l'ordre.
- mettre 1, 2, 4 ou 8 photos par pages, AVEC ou SANS marge.
- redimentionner, zoomer chaque photo AU DERNIER MOMENT en restant dans le même ratio x/y. Pas de déformation de la photo.
En gros, il faisait une espèce de diaporama multi-page et lorsqu'on était content, on imprimait.
J'utilise Linux depuis plus de 10 ans quasiment à temps plein mais je n'ai jamais réussit à trouver un logiciel corret pour imprimer des photos.
Le seul problème du logiciel Canon, il ne marche que sous Windows et QUE pour les imprimantes Canon. C'est débile comme vérrou.
[^] # Re: Applications
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vista dernier OS 32 bits de Redmond. Évalué à 3.
> permet de détecter beaucoup plus de bugs et donc d'améliorer a
> robustesse du kernel.
C'est vrai. Dans le cas du PC, il y a aussi une grande variété des matériels.
Si on regarde du coté des UNIX propriétaires, on remarque que le matériel était relativement homogène.
Donc, la manière de développer ainsi que le nombre de développeur permettent a mon sens de modérer tes propos.
> C'est quand même un très vilain hack
Oui, mais dans ce cas, on ne fait pas du x86 ! Le x86 est l'architecture la plus pourri des années 80. Le Z80 et le 6502 était bien mieux.
Le x86 a su dépasser la barrière des 640Ko sans que l'utilisateur soit trop pénalisé. Avec PAE, on franchi aujourd'hui la barrière des 4Go. De toute manière, c'est la plateforme x86 qui est contrainte à mort.
Si tu veux un truc propre, tu pars sur de l'Itanium ! Malheureusement, Intel vend trop de x86 du coup, il doit y avoir 100 fois plus d'ingénieur sur les puces x86 que sur l'Itanium.
Heureusement, l'architecture ARM est passé devant la x86 depuis quelques temps.
[^] # Re: OpenMP
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
Effectivement, dans le classement de l'efficacité des machines, on ne retrouve pas IBM en premier mais NEC avec ses machines vectorielles puis SGI avec ses Altix.
Comme quoi, il faut toujours se méfier de la manière dont est réalisée un classement ou un comparatif.
# Applications
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vista dernier OS 32 bits de Redmond. Évalué à 3.
Au niveau Linux et des *BSD, les OS tournent mais pas toujours les applications. Il suffit de prendre OpenOffice comme exemple...
MS ayant une stratégie purement commerciale, je la comprends un peu car je ne vois pas ce que lui apporte d'avoir un Windows multi-plateforme à part avoir plus de soucis. En plus, en temps qu'Ingénieur Sytème, je dois dire que la version 64 bits de XP me fait plus ch... qu'autre chose. Par ailleurs, avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM qui devenait bloquante en 32 bits (par exemple, mes serveurs Xen tournent très bien sous Debian 32 bits avec 6 Go de RAM).
Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows. Ici le problème est différent de celui de la machine de bureau ou du petit serveur rack et il n'y a pas une architecture qui domine depuis des années. MS est donc obligé de s'adapter comme tout le monde à l'évolution rapide des architectures embarquées.
[^] # Re: OpenMP
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 1.
# Itanium
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 5.
GCC était complètement largué sur Itanium par rapport au compilateur Intel car l'architecture EPIC oblige le compilateur à faire le boulot de l'optimisation des instructions. En effet, si on regarde l'architecture d'un Itanium par rapport à un x86, c'est beaucoup plus simple et du coup, Intel peut mettre bien plus de cache pour la même surface de silicium.
Cependant, on est en pratique obligé de travailler avec le compilateur Intel... J'espère que l'accélération dù à la version 4.2 va nous permettre de retravailler avec gcc.
[^] # Re: OpenMP
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 6.
Maintenant, il n'y a pas beaucoup de machine SMP à 1000 coeurs (je connais les Altix de SGI par exemple). Ce sont souvent des clusters et donc les programmes sont réalisés avec MPI.
OpenMP est en effet bien plus simple à mettre en oeuvre et permet de gagner facilement du temps de calcul. Comme nous avons tous des machines SMP aujourd'hui, cette bibliothèque va être de plus en plus fondamentale sur le bureau.
Mais pour les gros calculs malheureusement, il faut plus se pencher sur ses algorithmes et prendre le temps de faire du MPI.
Pour les calculs titanesques (future machine pétaflop), il faut trouver une nouvelle manière de programmer. Ce n'est pas moi qui le dis, ce sont des spécialistes que j'ai rencontrer. Personnellement, je n'ai pas accès à des machines ayant plus de 32 coeurs... Je n'ai donc pas idée des réels problèmes qui se posent.
En effet, il n'y a quasiment aucun programme qui pourrait partie de 100% de la puissance d'une machine pétaflop aujourd'hui. Il n'y a donc pas encore de réel intérêt à construire une telle machine.
# OpenMP
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 9.
Sur plateforme Itanium, il y a de belles machines SMP, par exemple, les Altix de SGI qui permettent d'avoir en SMP plus de 4000 noeuds ! Heureusement, la gamme Altix permet de commencer plus modestement dans le SMP.
Pour finir, si on veut vraiment faire un programme parallèle sur les GROSSES machines, il vaut mieux se tourner vers la bibliothèque MPI. Très peu de programme OpenMP dépasse les 100 tâches sans perte de performance alors que MPI permet d'aller jusqu'a 1000 tâches. Au dela des 1000 tâches, de nos jours, très peu de programmes sont efficases et il y a un gros boulot d'ingénierie pour trouver des solutions.
En conclusion, pour le bureau et 99% des applications, OpenMP, c'est bon, mangé en ;-)
[^] # Re: xmonad ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Quel remplaçant pour ion3 ?. Évalué à 3.
Bien que le fait de ne pas avoir de cadre prédéfinit dans wmii me gêne, cela fait maintenant 15 jours que je suis dessus et il est parfois plus pratique que ion, notamment au niveau des fenêtres flotantes. J'aime bien aussi sa notion de pile de fenêtre. Comme quasiment toutes mes fenêtres sont des 'xterm', le fait de ne découper l'écran que verticalement ne me gène pas plus que cela.
En plus, la manière de configurer wmii est assez marrante. Cela change des autres getsionaires de fenêtre. J'étais pas fanatique au début mais je trouve cela assez efficase au final.
[^] # Re: Java c'est le mal
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LibreSource 2.2, l'autre forge. Évalué à 2.
Sinon, LibreSource, il peut prendre un trac en entrée pour en faire un LibreSource. Je pose la question à tout hasard pour mes trac mais aussi parce que les sites tournant sous trac pullulent sur le net aujourd'hui. C'est d'ailleurs une des raisons de mon choix vers trac, cela semble un petit outil pérenne et où j'ai pris mes marques très rapidement.
[^] # Re: editeur console/gui
Posté par Sytoka Modon (site web personnel) . En réponse au journal Sortie de Vim 7.1. Évalué à 2.
[^] # Re: Java c'est le mal
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LibreSource 2.2, l'autre forge. Évalué à 4.
Pour les petits projets que nous développons, il est clair qu'avoir un forum, de la messagerie instantanée... c'est bien mais pour les utilisateurs, cela commence à faire pas mal d'outil à maitriser.
Au moins avec trac, les utilisateurs utilisent une bonne partie de la plateforme.
Il est vrai que j'ai d'autres plateformes et que je ne souahite pas non plus que tout tourne autour de trac dans mon laboratoire de recherche...
[^] # Re: En europe
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les logiciels libres violent 235 brevets Microsoft. Évalué à 3.
[^] # Re: en libre, il y a...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Joost : quelle réponse du libre ?. Évalué à 2.
[^] # Re: User-agent
Posté par Sytoka Modon (site web personnel) . En réponse au journal Debian, iceweasel et ma déclaration de revenus. Évalué à 1.
[^] # Re: encore plus déjanté que le précédent,
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Revue de presse : mai 2007. Évalué à 4.
Le 'camel book' n'était pas du tout comme cela, en tout cas l'édition 2. Au contraire, il y a dans ce livre de l'humour mais bien enrobé dans des phrases bien faites. Du coup, on ne voit pas toujours le second sens du premier coup. C'est beaucoup plus subtil je trouve.
Bref, pour moi, trop de BSD tue le BSD. Je ne sais pas lequel essayer en fin de compte. Surtout que j'ai été vachement deçu qu'OpenBSD ne tourne pas sous Xen.
# Multi-écran
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mort du xorg.conf ?. Évalué à 10.
Imaginons trois écrans, deux en xinerama pour une personne et l'autre pour une autre personne. Comment faire la configuration ? Etant l'utilisateur B, je refuse que l'utilisateur A puisse modifier la configuration générale.
Bref, des parametrage plus simple, ok, mais ne tombons pas dans le piège de Windows et d'Apple. Une machine UNIX se doit d'être multi-utilisateur dans son principe et l'utilisateur ne doit pas avoir par défaut les droits d'administration.
Si cette dérive est faite, les virus et autres cochonneries envahiront notre plateforme.
[^] # Re: No more perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Bugzilla a atteint la version 3.0 !. Évalué à 5.
Un truc super en perl c'est qu'une variable scalaire commence par un $. Cela, c'est vachement bien de séparer les variables des mots clefs.
Comme il a été dis, en perl6, ils ont éliminé pas mal de truc pas propre mais il est possible déjà de faire propre en perl5. Il suffit d'utiliser les bons modules.
Enfin, un gros avantages du perl, les programmes que j'ai fait il y a 10 ans en perl5_004 marche toujours tel quel !
Bref, il est de bon ton de critiquer perl de nos jours, surtout sur dlfp, notamment pour pousser vers python. Quand je vois dans une debian le nombre de version de python et les incompatibilités entre elles, personnellement, je n'ai pas envie d'en faire.
[^] # Erreur 404
Posté par Sytoka Modon (site web personnel) . En réponse au journal Joost : quelle réponse du libre ?. Évalué à 2.
A une époque, erreur404 diffusais aussi de la vidéo. C'est pas extraordinaire comme film mais bon, Je vois que sur leur site, il dise que tv404, c'est de nouveau pour bientôt, mais sans date précise.
http://www.erreur404.org
Si quelqu'un a des informations plus fiables, je suis preneur.
PS : c'est aussi du P2P mais sans DRM chez erreur404.
[^] # Re: Rien à voir, quoique
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Bugzilla a atteint la version 3.0 !. Évalué à 1.
http://linuxfr.org/~Nyco/comments,139.html
# Rien à voir, quoique
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Bugzilla a atteint la version 3.0 !. Évalué à 1.
J'arrête Linux demain !
Bravo Nÿco, n'arrête pas linuxfr.