>il est déjà assez court pour une machine domestique
Non, il n'est pas assez court pour une machine domestique:
environ 1-2minute pour Linux au lieu d'environ 10s pour BeOS, ce n'est pas assez court pour Linux a mon avis!
Je me demande s'il est possible de lancer cups apres X?
Je ne suis pas sur que l'initialisation de KDE ou de Gnome en ai besoin..
Je ne pense pas que ce soit un faux probleme:
- pour les particuliers en studio qui veulent dormir la nuit
- pour ceux qui ont un portable ou le suspend-to-disk ne fonctionne pas, un probleme assez répandu, je crois.
Les démarrages sont frequents et leeeennnnttt ce qui est pénible et donne une mauvaise impression de l'OS.
Si je me souviens bien, ma Mandrake 7.2 démarrait par défaut en 2 minutes (boot+démarrage de X et KDE) alors que BeOS mettait 20s pour faire la même chose!
J'avais pu atteindre 1m20 de temps de démarrage de Mdk en virant tous les services inutiles, mais c'etait quand meme assez penible: trouver la doc sur tous les daemons, etc.. pour un resultat tres mitigé.
Je trouve amusant que dans le papier d'IBM, ils proposent d'utiliser make pour résoudre les dépendances, alors que dans un papier de NetBSD qui explique leur systeme de demarrage, les auteurs disent qu'ils ne se sont pas servis de make pour éviter d'avoir a le mettre dans le /bin ce qu'ils considérent comme du "bloat"..
Je crois que Gentoo utilise aussi un systeme de demarrage par dependance, inspiré de celui de NetBSD.
>A moins qu'un langage soit défini par le soft qui l'implémente, ce dont je doute.
Ah? Pourtant j'ai l'impression que pour Perl, Ruby, Python c'est le cas!
Il y a surement des docs qui peuvent servir de définition, mais en général ces docs ne définissent pas tout les "points délicats", là c'est l'interpréteur qui sert de référence..
>De toute façon la taille n'est plus importante : 1 Mo ou 10 Mo, qu'est-ce que cela change, maintent ?
Là, tu exagère quand même beaucoup!
Pour ta punition, tu passeras une semaine avec un modem:
1 Mo a 5ko/sec, ça fait 3-4 min, 10Mo ça fait plus de 30min, une sacrès différence non?
Note que je chipote, mais pour le moment je ne suis pas trop convaincu pour faire du Rebol par rapport a du Python ou du Ruby..
>Si chaque personne qui "adore mandrake" avait décidé d'offrir un peu d'argent pour le boulot des développeurs, Mandrake ne serait pas à essayer des solutions, à vrai dire stupide, pour joindre les deux bouts.
J'ai acheté une boite et je suis aller un an au club (je n'y suis plus), donc je pense que je peux me permettre de critiquer: si Mandrake en est la, c'est a mon avis en grande partie a cause de leur tentative *stupide* de faire de l'e-learning.
Certes les rentrées d'argent sont conditionnée par les clients, mais c'est juste une partie de l'equation,l'autre partie étant comment l'argent est depensé..
Ceci dit, que Mandrake gagne un peu d'argent en utilisant de la pub, pourquoi pas..
Il faut juste faire attention a que la pub ne soit pas trop intrusive, le navigateur Opera est un bon exemple d'un produit ou la pub ne derange pas trop..
>MS reconnait indirectement ses pratiques anti-concurrentielles, vu que sinon, ils auraient été surs de gagner en cas de procès.
Justement si MS a payé c'est pour ne pas avoir à reconnaitre devant un juge leurs pratiques anti-concurrentielle, le réglement est un accord privé dont une partie des termes reste secret: MS ne reconnait rien du tout!
>Un peu de sous qui sort de chez MS et qui va chez les concurents.
Bôf! Pour MS, 26Millions de $ c'est rien du tout et comme ça leur "verrouillage" du boot reste incontesté: pour moi c'est MS le grand vainqueur dans l'histoire!
Non, l'argent doit aller aux actionnaires de BeInc justement et aux avocats, la société ne s'était pas encore dissoute pour pouvoir faire ce dernier procés.
> le gain relativement faible du Jpeg2000 au niveau taille de fichier, n'est vraiment pas un argument suffisant pour l'addopter a l'heure des connexions haut debits
Je ne sais pas: si tu regardes bien les newgroup de photo mmm "artistiques" :-), tu verras qu'un nouveau format de codage des binaires est de plus en plus utilisé: le yencodage qui code sur 8 bits au lieu de 7 bits.
Le format yenc n'est pas supporté par Outlook, pas un standard, apporte des gains relativements faibles et pourtant il est de plus en plus utilisé! ==> apparemment il y a un réel désir/besoin d'avoir des gains même pas très élevé pour transmettre des images..
Pourrais-tu rechercher l'adresse du papier en question sur le codage avec des perfs équivalentes à JP2000, mais sans les brevets?
Je serai intéréssé par le coté technique de la chose.
>Mouais bof. Cela serait comme forcer tous les soft à être libre. Je ne
>serais vraiment pas contre quand on voit comment sont traité les
>utilisateurs de soft proprio...
Amusant: forcé à être libre, je ne sais pas pourquoi, mais je trouve cela plutot contradictoire.
>Ce que je comprend surtout est que tu insinues qu'une boite faisant du libre n'est pas viable. C'est sur que MS ne serait pas viable.
Je suis d'accord avec lui sur ce point, il n'est pas vraiment prouvé qu'une boite faisant du libre puisse être viable.
Je dirais que le meilleur exemple d'une boîte libre viable est cygwin qui a réussi à vivre des années en faisant du libre.
RedHat n'est pas à mon avis un bon exemple: quand on a un trésor en banque grâce à la bétise des spéculateurs boursier, ça aide, c'est comme la blague: "Comment faire pour avoir une petite fortune? Avoir une grosse forture au départ."
Corrigé moi si je me trompe, mais l'intérét de Novell c'est son annuaire, non?
Le NDS: Novell Directory Service, il me semble.
Quelqu'un connait-il à la fois NDS et LDAP pour comparaison?
C'est un peu HS, mais si quelqu'un pouvait avoir un lien (en Français où en Anglais) qui explique clairement LDAP, cela m'arrangerait: tout ces cn,dn,... ça ne me parle pas beaucoup!
On voit bien que c'est tiré d'une norme X500: incapable d'utiliser des noms compréhensible..
> [tom's hardware]nous montre qu'il y a des alternatives à nvidia et ati dans le domaine de la 3d.
Dans le domaine de la 3D, certes, mais dans le domaine de ceux qui veulent:
- pouvoir utiliser les jeux qui tuent sous Windows
- utiliser aussi un PC sous Linux
Il n'y a pas le choix: c'est soit ATI, soit Nvidia.
Et je ne sais même pas si ATI a sorti un driver correcte pour Linux pour leurs carte moderne (9500 et plus)!
Il reste un choix:
- utiliser un driver libre 2D sous Linux, et adieux la programmation OpenGL et les jeux sous Linux: enfin pas tout à fait, il reste le rendu logiciel si on aime les diaporamas..
- polluer son kernel: beurk!
Pas terrible la situation, et j'ai bien peur que cela dure longtemps..
Tu parles du module Text::Iconv de CPAN?
C'est juste 20 lignes pour encapsuler l'appel a la librairie iconv, cela me parait facile a reproduire dans n'importe quel language..
La seule façon de "faire chier NVidia" réellement serait d'acheter des cartes vidéo chez un concurrent qui fournirait les specs de sa carte (ou encore mieux: les specs et un pilote ouvert), mais cela n'existe pas..
Nvidia n'est pas plus (ni pas moins) critiquable qu'ATI et Matrox qui ne fournissent plus leurs specs pour leur carte récente..
Et bien c'est le cas pour les cartes graphiques, si je ne me trompe pas, non?
Je crois que ATI pour ses 9500 et au dela ne fournit plus les specs de la partie 3D, Matrox pareil pour sa Parhelia, Nvidia ne les a jamais fournit..
Bref, jouer sous Linux a des jeux gourmands (je pense au futur Doom3) sans avoir un kernel "tainted", ce n'est pas possible a l'heure actuelle je pense :-(
>Mais Perl6.... Waaaa, s'ils réussissent vraiment à mettre tout ce qu'ils
>ont promis, sans foutre un bordel pas possible (pas évident ;) ), ça
>promet d'être un Python/Ruby-killer !! :D
Amusant, j'ai un avis totalement opposé: je pense que Perl6 va être la mort du Perl: apprendre Perl6, c'est réapprendre un nouveau language aussi compliqué a apprendre que le Perl classique et aussi illisible/inmaintenable!
Ce qui me fait penser que personne ne se bousculera pour passer au Perl6, et lentement Perl perdra de l'importance face a Python/Ruby..
Ceci dit la transition se fera très, très lentement: on programme encore beaucoup en Shell et en C, alors..
Si j'ai bien lu "les nouveautés" de Python 2.3, je dirais que les deux languages se ressemblent encore plus..
Je ne suis pas un expert en Ruby (et encore moins en Python), mais j'ai l'impression que Python a comme avantages:
1) plus d'utilisateurs
2) plus de librairies
3) une meilleure gestion de l'Unicode (enfin je crois)
4) peut-être une meilleure gestion des thread
Python avait comme défauts, je pense une moins bonne conception "objet" du language: la différence entre les type et les classes, les énumérateurs, mais ces "défauts" ont été corrigés dans les version récentes..
Sinon, franchement quand on regarde les 2 languages, ils se ressemblent beaucoup..
Et je dirais même de plus en plus, vu les progrès récents de Python.
Le choix entre les deux est assez dur, je trouve, j'ai fini par pencher pour Ruby à titre perso, mais si j'avais a utiliser Python au boulot par exemple, cela ne me dérangerait pas du tout!
Ceci dit pour le moment je suis coinçé sur du shell et du Perl: ça fait le boulot aussi, mais beurk!!
OASIS et un autre organisme de standardisation (allemand je crois?), j'avais fait un mail aux deuxième pour leur dire que si les deux pouvaient causer ensemble et faire un seul format, ce serait pas mal.
Ils m'avaient répond en me disant qu'ils le savaient déjà, mais d'après le "ton" de la lettre, ils en avaient rien à faire d'OASIS.
Pfff, les "standards" basés sur le format d'OO, je crois qu'il y en aura plusieurs, comme d'habitude!
Je suis surpris: cela ne posera pas de problème pour le mode de formatage "par frame" de KWord d'utiliser le format OOo?
Si c'est le cas, tant mieux! Moins il y aura de format de fichiers différents, mieux c'est!
(petite pique)
Les formats de fichiers pour les documents, c'est comme le format des prises électriques ou les formats de packaging: moins il y en a, mieux c'est!
(/petite pique)
Note qu'avec la license Apache, au moins ce genre de confusion sur l'utilisation dans les produits dérivés ne se posent pas..
En plus, si tu veux developper un outil avec la license BSD qui utilise une librairie LGPL, tu est obligé d'utiliser l'édition de lien dynamique pas l'edition de lien statique..
[^] # Re: Pour un boot plus rapide de Linux
Posté par reno . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Non, il n'est pas assez court pour une machine domestique:
environ 1-2minute pour Linux au lieu d'environ 10s pour BeOS, ce n'est pas assez court pour Linux a mon avis!
Je me demande s'il est possible de lancer cups apres X?
Je ne suis pas sur que l'initialisation de KDE ou de Gnome en ai besoin..
[^] # Re: Pour un boot plus rapide de Linux
Posté par reno . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Tout est relatif!
XP est plus rapide que 2k et Linux a demarrer (ca c'est pas dur!), mais il est beaucoup, beaucoup plus lent que BeOS..
[^] # Re: Pour un boot plus rapide de Linux
Posté par reno . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Une recherche Google ne donne rien..
[^] # Re: Pour un boot plus rapide de Linux
Posté par reno . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 7.
- pour les particuliers en studio qui veulent dormir la nuit
- pour ceux qui ont un portable ou le suspend-to-disk ne fonctionne pas, un probleme assez répandu, je crois.
Les démarrages sont frequents et leeeennnnttt ce qui est pénible et donne une mauvaise impression de l'OS.
Si je me souviens bien, ma Mandrake 7.2 démarrait par défaut en 2 minutes (boot+démarrage de X et KDE) alors que BeOS mettait 20s pour faire la même chose!
J'avais pu atteindre 1m20 de temps de démarrage de Mdk en virant tous les services inutiles, mais c'etait quand meme assez penible: trouver la doc sur tous les daemons, etc.. pour un resultat tres mitigé.
Je trouve amusant que dans le papier d'IBM, ils proposent d'utiliser make pour résoudre les dépendances, alors que dans un papier de NetBSD qui explique leur systeme de demarrage, les auteurs disent qu'ils ne se sont pas servis de make pour éviter d'avoir a le mettre dans le /bin ce qu'ils considérent comme du "bloat"..
Je crois que Gentoo utilise aussi un systeme de demarrage par dependance, inspiré de celui de NetBSD.
[^] # Re: R# une alternative opensource au langage Rebol
Posté par reno . En réponse à la dépêche R# une alternative opensource au langage Rebol. Évalué à 1.
Ah? Pourtant j'ai l'impression que pour Perl, Ruby, Python c'est le cas!
Il y a surement des docs qui peuvent servir de définition, mais en général ces docs ne définissent pas tout les "points délicats", là c'est l'interpréteur qui sert de référence..
[^] # Re: R# une alternative opensource au langage Rebol
Posté par reno . En réponse à la dépêche R# une alternative opensource au langage Rebol. Évalué à 2.
Là, tu exagère quand même beaucoup!
Pour ta punition, tu passeras une semaine avec un modem:
1 Mo a 5ko/sec, ça fait 3-4 min, 10Mo ça fait plus de 30min, une sacrès différence non?
Note que je chipote, mais pour le moment je ne suis pas trop convaincu pour faire du Rebol par rapport a du Python ou du Ruby..
[^] # Re: Espaces publicitaires à vendre
Posté par reno . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 0.
J'ai acheté une boite et je suis aller un an au club (je n'y suis plus), donc je pense que je peux me permettre de critiquer: si Mandrake en est la, c'est a mon avis en grande partie a cause de leur tentative *stupide* de faire de l'e-learning.
Certes les rentrées d'argent sont conditionnée par les clients, mais c'est juste une partie de l'equation,l'autre partie étant comment l'argent est depensé..
Ceci dit, que Mandrake gagne un peu d'argent en utilisant de la pub, pourquoi pas..
Il faut juste faire attention a que la pub ne soit pas trop intrusive, le navigateur Opera est un bon exemple d'un produit ou la pub ne derange pas trop..
[^] # Re: Mais boudioux !
Posté par reno . En réponse à la dépêche Microsoft conclut un accord à l'amiable avec Be. Évalué à 3.
Justement si MS a payé c'est pour ne pas avoir à reconnaitre devant un juge leurs pratiques anti-concurrentielle, le réglement est un accord privé dont une partie des termes reste secret: MS ne reconnait rien du tout!
>Un peu de sous qui sort de chez MS et qui va chez les concurents.
Bôf! Pour MS, 26Millions de $ c'est rien du tout et comme ça leur "verrouillage" du boot reste incontesté: pour moi c'est MS le grand vainqueur dans l'histoire!
[^] # Re: Microsoft conclut un accord à l'amiable avec Be
Posté par reno . En réponse à la dépêche Microsoft conclut un accord à l'amiable avec Be. Évalué à 3.
[^] # Re: JPEG2000 pour tous, c'est ma tournée!
Posté par reno . En réponse à la dépêche JPEG2000 pour tous, c'est ma tournée!. Évalué à 2.
Je ne sais pas: si tu regardes bien les newgroup de photo mmm "artistiques" :-), tu verras qu'un nouveau format de codage des binaires est de plus en plus utilisé: le yencodage qui code sur 8 bits au lieu de 7 bits.
Le format yenc n'est pas supporté par Outlook, pas un standard, apporte des gains relativements faibles et pourtant il est de plus en plus utilisé! ==> apparemment il y a un réel désir/besoin d'avoir des gains même pas très élevé pour transmettre des images..
Pourrais-tu rechercher l'adresse du papier en question sur le codage avec des perfs équivalentes à JP2000, mais sans les brevets?
Je serai intéréssé par le coté technique de la chose.
[^] # Re: L'avocat du diable
Posté par reno . En réponse à la dépêche L'avantage inattendu de l'Open Source. Évalué à 3.
Ah, parce que les utilisateurs avaient le choix?
Jusqu'a une période récente, tu n'avais que des OS peu fiables, que ce soit les PC avec Windows9x ou les Mac avant MacOSX..
[^] # Re: P2P face au droit d'auteur : vers la reconnaissance du droit du public
Posté par reno . En réponse à la dépêche P2P face au droit d'auteur : vers la reconnaissance du droit du public. Évalué à 1.
>serais vraiment pas contre quand on voit comment sont traité les
>utilisateurs de soft proprio...
Amusant: forcé à être libre, je ne sais pas pourquoi, mais je trouve cela plutot contradictoire.
>Ce que je comprend surtout est que tu insinues qu'une boite faisant du libre n'est pas viable. C'est sur que MS ne serait pas viable.
Je suis d'accord avec lui sur ce point, il n'est pas vraiment prouvé qu'une boite faisant du libre puisse être viable.
Je dirais que le meilleur exemple d'une boîte libre viable est cygwin qui a réussi à vivre des années en faisant du libre.
RedHat n'est pas à mon avis un bon exemple: quand on a un trésor en banque grâce à la bétise des spéculateurs boursier, ça aide, c'est comme la blague: "Comment faire pour avoir une petite fortune? Avoir une grosse forture au départ."
# Novell == annuaire d'entreprise,non?
Posté par reno . En réponse à la dépêche Novell va-t-il arrêter Netware ?. Évalué à 2.
Le NDS: Novell Directory Service, il me semble.
Quelqu'un connait-il à la fois NDS et LDAP pour comparaison?
C'est un peu HS, mais si quelqu'un pouvait avoir un lien (en Français où en Anglais) qui explique clairement LDAP, cela m'arrangerait: tout ces cn,dn,... ça ne me parle pas beaucoup!
On voit bien que c'est tiré d'une norme X500: incapable d'utiliser des noms compréhensible..
[^] # Re: Kernel Summit 2003
Posté par reno . En réponse à la dépêche Kernel Summit 2003. Évalué à 4.
Il faut y montrer patte blanche ou chaussette blanche pour y assister ?
;-)
[^] # Re: Situation des cartes graphiques
Posté par reno . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 1.
Dans le domaine de la 3D, certes, mais dans le domaine de ceux qui veulent:
- pouvoir utiliser les jeux qui tuent sous Windows
- utiliser aussi un PC sous Linux
Il n'y a pas le choix: c'est soit ATI, soit Nvidia.
Et je ne sais même pas si ATI a sorti un driver correcte pour Linux pour leurs carte moderne (9500 et plus)!
Il reste un choix:
- utiliser un driver libre 2D sous Linux, et adieux la programmation OpenGL et les jeux sous Linux: enfin pas tout à fait, il reste le rendu logiciel si on aime les diaporamas..
- polluer son kernel: beurk!
Pas terrible la situation, et j'ai bien peur que cela dure longtemps..
[^] # Re: Python 2.3 est sorti
Posté par reno . En réponse à la dépêche Python 2.3 est sorti. Évalué à 1.
C'est juste 20 lignes pour encapsuler l'appel a la librairie iconv, cela me parait facile a reproduire dans n'importe quel language..
Ou alors il y a d'autres choses en Perl?
[^] # Re: Nouveaux drivers Nvidia disponibles
Posté par reno . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 3.
Nvidia n'est pas plus (ni pas moins) critiquable qu'ATI et Matrox qui ne fournissent plus leurs specs pour leur carte récente..
[^] # Re: Python 2.3 est sorti
Posté par reno . En réponse à la dépêche Python 2.3 est sorti. Évalué à 2.
[^] # Re: [HS] Re: Frenglische
Posté par reno . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 1.
cache memory --> mémoire tampon
Vous en pensez quoi?
Cela me paraissait pas mal jusqu'au moment ou j'essaye de traduire "buffer memory" que je traduirai aussi par mémoire tampon..
[^] # Re: Nouveaux drivers Nvidia disponibles
Posté par reno . En réponse à la dépêche Nouveaux pilotes Nvidia disponibles. Évalué à 1.
Je crois que ATI pour ses 9500 et au dela ne fournit plus les specs de la partie 3D, Matrox pareil pour sa Parhelia, Nvidia ne les a jamais fournit..
Bref, jouer sous Linux a des jeux gourmands (je pense au futur Doom3) sans avoir un kernel "tainted", ce n'est pas possible a l'heure actuelle je pense :-(
[^] # Re: Python 2.3 est sorti
Posté par reno . En réponse à la dépêche Python 2.3 est sorti. Évalué à 7.
>ont promis, sans foutre un bordel pas possible (pas évident ;) ), ça
>promet d'être un Python/Ruby-killer !! :D
Amusant, j'ai un avis totalement opposé: je pense que Perl6 va être la mort du Perl: apprendre Perl6, c'est réapprendre un nouveau language aussi compliqué a apprendre que le Perl classique et aussi illisible/inmaintenable!
Ce qui me fait penser que personne ne se bousculera pour passer au Perl6, et lentement Perl perdra de l'importance face a Python/Ruby..
Ceci dit la transition se fera très, très lentement: on programme encore beaucoup en Shell et en C, alors..
[^] # Re: Python 2.3 est sorti
Posté par reno . En réponse à la dépêche Python 2.3 est sorti. Évalué à 6.
Je ne suis pas un expert en Ruby (et encore moins en Python), mais j'ai l'impression que Python a comme avantages:
1) plus d'utilisateurs
2) plus de librairies
3) une meilleure gestion de l'Unicode (enfin je crois)
4) peut-être une meilleure gestion des thread
Python avait comme défauts, je pense une moins bonne conception "objet" du language: la différence entre les type et les classes, les énumérateurs, mais ces "défauts" ont été corrigés dans les version récentes..
Sinon, franchement quand on regarde les 2 languages, ils se ressemblent beaucoup..
Et je dirais même de plus en plus, vu les progrès récents de Python.
Le choix entre les deux est assez dur, je trouve, j'ai fini par pencher pour Ruby à titre perso, mais si j'avais a utiliser Python au boulot par exemple, cela ne me dérangerait pas du tout!
Ceci dit pour le moment je suis coinçé sur du shell et du Perl: ça fait le boulot aussi, mais beurk!!
[^] # Re: Connaissez-vous OOo ?
Posté par reno . En réponse à la dépêche Connaissez-vous OOo ?. Évalué à 1.
OASIS et un autre organisme de standardisation (allemand je crois?), j'avais fait un mail aux deuxième pour leur dire que si les deux pouvaient causer ensemble et faire un seul format, ce serait pas mal.
Ils m'avaient répond en me disant qu'ils le savaient déjà, mais d'après le "ton" de la lettre, ils en avaient rien à faire d'OASIS.
Pfff, les "standards" basés sur le format d'OO, je crois qu'il y en aura plusieurs, comme d'habitude!
[^] # Re: Connaissez-vous OOo ?
Posté par reno . En réponse à la dépêche Connaissez-vous OOo ?. Évalué à 1.
Je suis surpris: cela ne posera pas de problème pour le mode de formatage "par frame" de KWord d'utiliser le format OOo?
Si c'est le cas, tant mieux! Moins il y aura de format de fichiers différents, mieux c'est!
(petite pique)
Les formats de fichiers pour les documents, c'est comme le format des prises électriques ou les formats de packaging: moins il y en a, mieux c'est!
(/petite pique)
[^] # Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par reno . En réponse à la dépêche La LGPL s'applique à Java exactement comme pour C/C++. Évalué à 2.
Note qu'avec la license Apache, au moins ce genre de confusion sur l'utilisation dans les produits dérivés ne se posent pas..
En plus, si tu veux developper un outil avec la license BSD qui utilise une librairie LGPL, tu est obligé d'utiliser l'édition de lien dynamique pas l'edition de lien statique..