Un oubli (pour moi) qu'on pardonnera sans soucis vu la qualité de la dépêche. Et aussi son volume (pas facile de faire des choix).
AMD a fournit plein de doc de ses cartes graphiques. On n'avais jamais vu autant de doc pour des cartes graphiques (sauf peut-être pour Intel, mais Intel a fini de fournir les doc en début 2008). C'est la première fois dans l'histoire du logiciel libre qu'on peut envisager avoir des drivers libres pour des cartes graphique haut de gamme.
Certes, l'annonce par AMD avait été faite en 2007 et non 2008.
En passant, et comme on le pressentait, c'est aussi la fin (relative pour certains) de Xen. Et on peut faire tourner des guests Xen sur KVM : http://kraxel.fedorapeople.org/xenner/
J'admets, ce n'était pas terrible.
Mais toi ce n'est pas mieux. Ce n'est que "je je je je".
L'intérêt d'un truc libre, ce n'est pas seulement car je vais utiliser tous les possibilités que me donne le libre (audition, modication du code, etc), mais surtout car d'autres vont utiliser ces possibilités même s'ils sont peu nombreux. C'est aussi de savoir qu'on a cette possibilité. C'est une contribution au pôt commun du libre. C'est le propriétaire du code qui donne les droits du libre à tous et c'est très bien. C'est à saluer et non à recevoir avec des "on s'en fout".
> j'avoue que tu n'as pas peur du ridicule
Merci, c'est une qualité. C'est mieux que de pisser dans le sens du vent car on a peur du ridicule.
> Sauf que comme tu le dis, NM a été fait pour le wifi en premier... or, pour le wifi, il faut stocker de la clé... donc, de quoi faire du stockage, c'est déjà là.
Et où tu veux en venir ?
Que les développeurs sont des guignols ?
Je ne sais pas exactement le pourquoi du comment du bug de NM dans l'installeur de Fedora (et toi non plus), mais comme Fedora est principalement dédié aux contributeurs, que Fedora sort tous les 6 mois, il ne faut pas être devin pour comprendre que ce bug est très très très probablement lié à un problème technique ou par manque de moyen (temps ou développeur).
> Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.
Tout ceci est mignon, mais l'installeur de Fedora est texte et graphique. Que ça ne soit pas fait directement dans NM, n'empêche pas qu'il faut une IHM. Et si tu vas par là, je suis sûr qu'à coup de "vi" et "echo bidule > machin" tu peux fixer l'adresse IP avec NM lors de l'installation de Fedora. Tu peux aussi te passer d'installeur et faire des "mke2fs ... ; ifconfig ... ; route ; yum --installroot=... ; etc". Alors, tu ne veux toujours pas d'IHM ?
> Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point
Ben tu ne connais pas grand chose en réseau... Et je ne suis pas une pointure...
Et le cas ou l'utilisateur prend une adresse IP déjà utilisée, tu y penses ? C'est juste un exemple. Les IP fixes c'est seulement pour quelques bécanes bien sélectionnée et quasiment que des serveurs.
De plus, avec DHCP on peut aussi fournir des IP fixe à des bécanes (soit avec l'adresse MAC, soit avec le nom de la bécane).
> Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.
Ben prends une RHEL/Centos. Point.
Tu te trompes de distribution. Point.
En passant, RHEL/Centos c'est Fedora. Point.
RHEL/Centos ce n'est pas une autre distribution, c'est un fork de Fedora avec d'autres objectifs. Donc ce n'est pas le modèle de développement de RHEL contre celui de Fedora, c'est Fedora avec RHEL. Une RHEL sort tous les 2 ans (et maintenant ça va passer à tous les 3 ans), donc une RHEL peut sortir avec 2 ou 3 mois de retard pour éviter qu'il manque bidule ou pour corriger le bug machin. Ça a très peu d'incidence sur RHEL. Par contre, pour Fedora c'est presque catastrophique (ce sont des contributeurs qui glandent durant 3 mois sur une sortie de distribution qui est prévue tous les 6 mois !).
> Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd
Et ?
Tu crois que les développeurs en sont contents ?
Tu ne crois pas qu'ils ont des priorités. Que supporter le branchement à chaud (d'écran, de clavier, de souris (et tout ceci marche)) est beaucoup beaucoup beaucoup plus important que de s'occuper du geek qui s'astique le manche avec son tri-écran ?
> résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.
Un de perdu, dix de retrouvé.
> D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas
Il marche chez moi. En passant, ce n'est pas Xorg 7.2, c'est Xorg 7.4 que j'utilise. Xorg 7.2 est sorti il y a 2 ans il me semble...
> pour casser tous ceux qui le sont un peu moins.
T'es sérieux ?
Tu crois qu'il y a beaucoup de personnes qui utilisent 3 écrans ou 2 cartes graphiques à la fois ?
Franchement...
> les problèmes ne sont ni pris dans le bon ordre
C'est-à-dire ?
Il ne fallait pas faire le support de branchement à chaud ? Il fallait en premier s'occuper des 0,01 % d'utilisateurs qui ont 2 cartes graphiques et 3 écrans ?
> ni de la bonne manière...
Je n'ai pas les compétences pour en juger, je doutes que tu les aies aussi...
> La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.
Ben prend une vieille distribution...
Aujourd'hui le défi du logiciel libre n'est pas de faire l'Unix à papa (qui configure tout nickel à coup de vim. NB : j'en ai fait parti !), mais de faire un OS simple.
Je suis sûr que t'es super content que l'USB marche nickel (ou presque) sous Linux sans que tu aies à configurer quoique ce soit. Ben l'USB sous Linux, pour les développeurs, a été un enfer à réaliser. Le Xorg qui rivalisera avec Windows est un enfer a réaliser. Mais quand il sera là (et il faut y venir !) tu ne pourras plus t'en passer comme tu ne peux plus te passer d'USB qui marche les doigts dans les nez (ce qui n'a pas été le cas durant de nombreuses années...).
Faire simple c'est bien. Mais ce n'est pas toujours possible car les défis, et surtout ceux à venir, sont compliqués. Mais si tu as des solutions simples pour ces problèmes compliqués, n'hésites pas, les développeurs te baisseront les pieds.
> Chapeau bas a Mandriva pour avoir laissé l'intégralité de KDE 3.5 disponible.
Ce n'est pas pareil. Fedora a fait de KDE 4 son bureau KDE. Mandriva fait de KDE 3 son bureau KDE. Sous Fedora tu as l'intégralité de KDE 4 par défaut, sous Mandriva c'est KDE 3.
> En fait, je trouve pour le moins incongru d'avoir développé avec le DHCP en premier, alors que l'utilisation des IP fixes me paraît un cas plus élémentaire.
Oui et non. Avec DHCP tu n'as pas de configuration à stocker. Avec une IP fixe, il faut stocker la configuration, faire une IHM, etc.
Enfin NM a été en premier fait pour le wifi. C'est-à-dire où DHCP est quasiment toujours utilisé. Autre aspect, NM a été fait pour être utilisé sans privilège. C-à-d qu'un non-admin doit pouvoir activer une connexion réseau. Ceci veut dire que ce n'est pas à lui de définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau) mais à un DHCP (géré par un admin qui sait ce qu'il fait).
> merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas...
Je ne connais pas ce problème. Il y a eu des régressions avec Xorg ces derniers temps. Entre autre le multiseat (plusieurs serveurs X11, plusieurs claviers/souris) ne marche plus. Il est prévu pour F12 d'y remettre de l'ordre. D'autres distributions y travaillent.
> J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.
C'est pertinent d'une certaine manière.
C'est seulement du développement. Au début les développeurs se consacrent au noyau (bas niveau, structure, organisation, modifications invasives) et à ce qui est le plus utilisé (pour NM : le wifi et donc dhcp). Puis ils font les finitions (multi-GPU, multi-seat, etc).
Ça serait formidable de tout faire complètement dès le début. Mais ce n'est pas toujours possible. Les développements doivent avancer. Contrairement à Windows, ils se font à la vue de tous (via Fedora ou autre). Linux a encore beaucoup de retard dans certains domaines (NM fait bouger les choses dans le bon sens) et notamment pour Xorg (il n'y a que depuis peu de temps qu'on a le branchement à chaud d'écran par exemple, alors que Windows a ça depuis des lustres et que c'est hyper indispensable sur un portable en entreprise).
Les développeurs ne se disent pas : "et si on ignorait ceux qui veulent des IP statiques". Ils font au mieux pour le long terme et avec des moyens ridicules par rapport à Windows.
Ce que tu critiques ici, c'est seulement le manque de moyen en développement de Linux.
Le développement du logiciel libre n'est pas un long fleuve tranquille. Des fois ça casse de partout, mais il faut faire avancer le logiciel libre. Ce n'est pas avec l'attitude "surtout pas de régression" qu'on va y arriver. Si une évolution importante demande des régressions temporaires, il faut le faire, et ne pas attendre le 36 du mois. Il doit être de l'honneur des utilisateurs du logiciel libre (et notamment des utilisateurs de Fedora) de le comprendre.
> Maintenant la question qui se pose est: Ext4 ou Brtfs ?
Comme le disent d'autres commentaires, ça sera Ext4 ET Btrfs. Comme ça a été Ext2 ET Ext3, comme ça sera et c'est maintenant Ext3 ET Ext4.
De nombreux mois, et très probablement des années, vont passer avant que Btrfs soit au point. Ext4 est déjà au point (ou plus très loins). Btrfs est le remplaçant à venir de Ext4. Ext4 roxe, donc Btrfs sortira (en 1.0) lorsqu'il roxera, qu'il n'y aura pas de régression par rapport à Ext4, qu'il sera aussi fiable et apportera son petit plus par rapport à Ext4. BtrFS a quasiment la garantit d'y arriver car nombre de développeurs Ext vont bosser sur BtrFS. Donc Ext4 va stagner et BtrFS progresser.
Je vais en froisser quelqu'uns, mais Ext* a été (et est toujours) LE système de fichier de Linux. BtrFS sera LE système de fichier de Linux.
En passant, Ext4 est dans F10 (faut ajouter "ext4" lors du boot de l'installation). Je l'utilise, rien à dire sinon que ça marche. Il sera peut-être par défaut pour F11. Il sera très probablement par défaut pour RHEL 6. Novell a abondonné Reiser(FS|4) pour Ext*. Ext4 sera par défaut dans la distribution entreprise de Novell. Ext4 répond aux besoins actuels. Ça donne du temps à BtrFS. Pas pour flémarder, mais pour innover.
> Linux favorisait des systèmes de fichiers où la défragmentation était inutile...
C'est le cas. D'ailleurs on trouve rarement des défragmenteur sous Linux.
Ici c'est de l'optimisation pour des serveurs très stressés ou +5% de performance peut être important. C'est n'est pas pour une optimisation de "desktop".
Ext4 a aussi la défragmentation à chaud.
C'est seulement un bug ou une fonctionnalité non encore réalisée. Il ne faut pas en faire un fromage.
Je ne connais les détails de ce bug, mais pas de quoi s'acharner sur NM.
Peut-être qu'avec F11 le bug sera corrigé et qu'en plus on pourra utiliser le wifi pour installer. Et là ça va être "super NM, patati et patata".
En passant, F10 intègre pour la première fois NM dans l'installeur (et c'est la première distribution à le faire). Certes, il y aura toujours des gens qui vont dire qu'il faut faire parfait dès le début. Mais pourquoi il ne l'ont pas encore fait avec NM ?...
> Sinon concernant les sources de Launchpad, on s'en tape, on s'en branle, on s'en bat les testicules
C'est qui "on" ?
Ce n'est pas moi.
> Vous vous foutez royalement du code de Launchpad ! Et à vrai dire, moi aussi :)
Ben moi aussi je me fous du code de Launchpad !
Ce genre de truc n'intéressera jamais plus de 2 % des développeurs et jamais plus de 0,01 % des utilisateurs.
Et alors ?
Moins de 0,01 % des utilisateurs du noyau Linux ne lisent les sources de Linux. C'est une raison pour dire, comme tu le fais pour Launchpad, qu'on en a rien à foutre que Linux soit libre ou non ?
Ton raisonnement est pervers, il est nombriliste, il manque totalement de recul.
[^] # Re: En effet le vendredi c'est permis
Posté par IsNotGood . En réponse au journal Ubuntu dans le New York Times. Évalué à 4.
En passant, Ubuntu a eu une (et pas deux) idée en 2007 :
http://www.markshuttleworth.com/archives/253
Avec une bonne idée comme ça par an, Linux Ubuntu va tout écraser.
[^] # Re: C'est pas le seul.
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 2.
[^] # Re: C'est pas le seul.
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 4.
[^] # Re: Numero 6
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 5.
[^] # Re: c'est pas la joie
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 6.
La fille de Rachida Dati ?
# Numero 6
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 4.
Je suis un homme LIBRE !!!
Fabuleux.
[^] # Re: Columbo
Posté par IsNotGood . En réponse au journal RIP Patrick MacGoohan. Évalué à 3.
Il me semble que c'est l'acteur qui a fait le plus de Columbo (hors Peter Falk évidemment).
# Re:
Posté par IsNotGood . En réponse au journal Qt LGPL!. Évalué à 2.
# Un oubli
Posté par IsNotGood . En réponse à la dépêche Rétrospective LinuxFR 2008 du logiciel libre. Évalué à 8.
AMD a fournit plein de doc de ses cartes graphiques. On n'avais jamais vu autant de doc pour des cartes graphiques (sauf peut-être pour Intel, mais Intel a fini de fournir les doc en début 2008). C'est la première fois dans l'histoire du logiciel libre qu'on peut envisager avoir des drivers libres pour des cartes graphique haut de gamme.
Certes, l'annonce par AMD avait été faite en 2007 et non 2008.
[^] # Re: Côté « business » : un autre
Posté par IsNotGood . En réponse à la dépêche Rétrospective LinuxFR 2008 du logiciel libre. Évalué à 2.
http://kraxel.fedorapeople.org/xenner/
[^] # Re: Côté « business » : un autre
Posté par IsNotGood . En réponse à la dépêche Rétrospective LinuxFR 2008 du logiciel libre. Évalué à 4.
http://www.redhat.com/about/news/prarchive/2008/qumranet.htm(...)
[^] # Re: SPOILER ALERT
Posté par IsNotGood . En réponse à la dépêche Fedora 11 a un nom, ça sera Leonidas. Évalué à 3.
[] <-
[^] # Re: On voit bien la mentalité de Canonical
Posté par IsNotGood . En réponse au journal Chronique d'une liberation annoncée..... Évalué à 2.
Mais toi ce n'est pas mieux. Ce n'est que "je je je je".
L'intérêt d'un truc libre, ce n'est pas seulement car je vais utiliser tous les possibilités que me donne le libre (audition, modication du code, etc), mais surtout car d'autres vont utiliser ces possibilités même s'ils sont peu nombreux. C'est aussi de savoir qu'on a cette possibilité. C'est une contribution au pôt commun du libre. C'est le propriétaire du code qui donne les droits du libre à tous et c'est très bien. C'est à saluer et non à recevoir avec des "on s'en fout".
> j'avoue que tu n'as pas peur du ridicule
Merci, c'est une qualité. C'est mieux que de pisser dans le sens du vent car on a peur du ridicule.
PS : il n'y a aucun chiffre dans ce commentaire.
[^] # Re: Problèmes réseau
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 1.
Et où tu veux en venir ?
Que les développeurs sont des guignols ?
Je ne sais pas exactement le pourquoi du comment du bug de NM dans l'installeur de Fedora (et toi non plus), mais comme Fedora est principalement dédié aux contributeurs, que Fedora sort tous les 6 mois, il ne faut pas être devin pour comprendre que ce bug est très très très probablement lié à un problème technique ou par manque de moyen (temps ou développeur).
> Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.
Tout ceci est mignon, mais l'installeur de Fedora est texte et graphique. Que ça ne soit pas fait directement dans NM, n'empêche pas qu'il faut une IHM. Et si tu vas par là, je suis sûr qu'à coup de "vi" et "echo bidule > machin" tu peux fixer l'adresse IP avec NM lors de l'installation de Fedora. Tu peux aussi te passer d'installeur et faire des "mke2fs ... ; ifconfig ... ; route ; yum --installroot=... ; etc". Alors, tu ne veux toujours pas d'IHM ?
> Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point
Ben tu ne connais pas grand chose en réseau... Et je ne suis pas une pointure...
Et le cas ou l'utilisateur prend une adresse IP déjà utilisée, tu y penses ? C'est juste un exemple. Les IP fixes c'est seulement pour quelques bécanes bien sélectionnée et quasiment que des serveurs.
De plus, avec DHCP on peut aussi fournir des IP fixe à des bécanes (soit avec l'adresse MAC, soit avec le nom de la bécane).
> Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.
Ben prends une RHEL/Centos. Point.
Tu te trompes de distribution. Point.
En passant, RHEL/Centos c'est Fedora. Point.
RHEL/Centos ce n'est pas une autre distribution, c'est un fork de Fedora avec d'autres objectifs. Donc ce n'est pas le modèle de développement de RHEL contre celui de Fedora, c'est Fedora avec RHEL. Une RHEL sort tous les 2 ans (et maintenant ça va passer à tous les 3 ans), donc une RHEL peut sortir avec 2 ou 3 mois de retard pour éviter qu'il manque bidule ou pour corriger le bug machin. Ça a très peu d'incidence sur RHEL. Par contre, pour Fedora c'est presque catastrophique (ce sont des contributeurs qui glandent durant 3 mois sur une sortie de distribution qui est prévue tous les 6 mois !).
> Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd
Et ?
Tu crois que les développeurs en sont contents ?
Tu ne crois pas qu'ils ont des priorités. Que supporter le branchement à chaud (d'écran, de clavier, de souris (et tout ceci marche)) est beaucoup beaucoup beaucoup plus important que de s'occuper du geek qui s'astique le manche avec son tri-écran ?
> résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.
Un de perdu, dix de retrouvé.
> D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas
Il marche chez moi. En passant, ce n'est pas Xorg 7.2, c'est Xorg 7.4 que j'utilise. Xorg 7.2 est sorti il y a 2 ans il me semble...
> pour casser tous ceux qui le sont un peu moins.
T'es sérieux ?
Tu crois qu'il y a beaucoup de personnes qui utilisent 3 écrans ou 2 cartes graphiques à la fois ?
Franchement...
> les problèmes ne sont ni pris dans le bon ordre
C'est-à-dire ?
Il ne fallait pas faire le support de branchement à chaud ? Il fallait en premier s'occuper des 0,01 % d'utilisateurs qui ont 2 cartes graphiques et 3 écrans ?
> ni de la bonne manière...
Je n'ai pas les compétences pour en juger, je doutes que tu les aies aussi...
> La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.
Ben prend une vieille distribution...
Aujourd'hui le défi du logiciel libre n'est pas de faire l'Unix à papa (qui configure tout nickel à coup de vim. NB : j'en ai fait parti !), mais de faire un OS simple.
Je suis sûr que t'es super content que l'USB marche nickel (ou presque) sous Linux sans que tu aies à configurer quoique ce soit. Ben l'USB sous Linux, pour les développeurs, a été un enfer à réaliser. Le Xorg qui rivalisera avec Windows est un enfer a réaliser. Mais quand il sera là (et il faut y venir !) tu ne pourras plus t'en passer comme tu ne peux plus te passer d'USB qui marche les doigts dans les nez (ce qui n'a pas été le cas durant de nombreuses années...).
Faire simple c'est bien. Mais ce n'est pas toujours possible car les défis, et surtout ceux à venir, sont compliqués. Mais si tu as des solutions simples pour ces problèmes compliqués, n'hésites pas, les développeurs te baisseront les pieds.
[^] # Re: KDE 3.5.10 ?
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 0.
Ce n'est pas pareil. Fedora a fait de KDE 4 son bureau KDE. Mandriva fait de KDE 3 son bureau KDE. Sous Fedora tu as l'intégralité de KDE 4 par défaut, sous Mandriva c'est KDE 3.
[^] # Re: KDE 3.5.10 ?
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 2.
Ooops, depuis F9.
[^] # Re: KDE 3.5.10 ?
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 3.
[^] # Re: Problèmes réseau
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 3.
Oui et non. Avec DHCP tu n'as pas de configuration à stocker. Avec une IP fixe, il faut stocker la configuration, faire une IHM, etc.
Enfin NM a été en premier fait pour le wifi. C'est-à-dire où DHCP est quasiment toujours utilisé. Autre aspect, NM a été fait pour être utilisé sans privilège. C-à-d qu'un non-admin doit pouvoir activer une connexion réseau. Ceci veut dire que ce n'est pas à lui de définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau) mais à un DHCP (géré par un admin qui sait ce qu'il fait).
> merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas...
Je ne connais pas ce problème. Il y a eu des régressions avec Xorg ces derniers temps. Entre autre le multiseat (plusieurs serveurs X11, plusieurs claviers/souris) ne marche plus. Il est prévu pour F12 d'y remettre de l'ordre. D'autres distributions y travaillent.
> J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.
C'est pertinent d'une certaine manière.
C'est seulement du développement. Au début les développeurs se consacrent au noyau (bas niveau, structure, organisation, modifications invasives) et à ce qui est le plus utilisé (pour NM : le wifi et donc dhcp). Puis ils font les finitions (multi-GPU, multi-seat, etc).
Ça serait formidable de tout faire complètement dès le début. Mais ce n'est pas toujours possible. Les développements doivent avancer. Contrairement à Windows, ils se font à la vue de tous (via Fedora ou autre). Linux a encore beaucoup de retard dans certains domaines (NM fait bouger les choses dans le bon sens) et notamment pour Xorg (il n'y a que depuis peu de temps qu'on a le branchement à chaud d'écran par exemple, alors que Windows a ça depuis des lustres et que c'est hyper indispensable sur un portable en entreprise).
Les développeurs ne se disent pas : "et si on ignorait ceux qui veulent des IP statiques". Ils font au mieux pour le long terme et avec des moyens ridicules par rapport à Windows.
Ce que tu critiques ici, c'est seulement le manque de moyen en développement de Linux.
Le développement du logiciel libre n'est pas un long fleuve tranquille. Des fois ça casse de partout, mais il faut faire avancer le logiciel libre. Ce n'est pas avec l'attitude "surtout pas de régression" qu'on va y arriver. Si une évolution importante demande des régressions temporaires, il faut le faire, et ne pas attendre le 36 du mois. Il doit être de l'honneur des utilisateurs du logiciel libre (et notamment des utilisateurs de Fedora) de le comprendre.
[^] # Re: Ext4 ou Brtfs ?
Posté par IsNotGood . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 1.
Ou une autre façon de le dire : Ext4 n'est pas un concurrent de BtrFS, c'est une chance pour BtrFS.
[^] # Re: Ext4 ou Brtfs ?
Posté par IsNotGood . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 2.
Comme le disent d'autres commentaires, ça sera Ext4 ET Btrfs. Comme ça a été Ext2 ET Ext3, comme ça sera et c'est maintenant Ext3 ET Ext4.
De nombreux mois, et très probablement des années, vont passer avant que Btrfs soit au point. Ext4 est déjà au point (ou plus très loins). Btrfs est le remplaçant à venir de Ext4. Ext4 roxe, donc Btrfs sortira (en 1.0) lorsqu'il roxera, qu'il n'y aura pas de régression par rapport à Ext4, qu'il sera aussi fiable et apportera son petit plus par rapport à Ext4. BtrFS a quasiment la garantit d'y arriver car nombre de développeurs Ext vont bosser sur BtrFS. Donc Ext4 va stagner et BtrFS progresser.
Je vais en froisser quelqu'uns, mais Ext* a été (et est toujours) LE système de fichier de Linux. BtrFS sera LE système de fichier de Linux.
En passant, Ext4 est dans F10 (faut ajouter "ext4" lors du boot de l'installation). Je l'utilise, rien à dire sinon que ça marche. Il sera peut-être par défaut pour F11. Il sera très probablement par défaut pour RHEL 6. Novell a abondonné Reiser(FS|4) pour Ext*. Ext4 sera par défaut dans la distribution entreprise de Novell. Ext4 répond aux besoins actuels. Ça donne du temps à BtrFS. Pas pour flémarder, mais pour innover.
[^] # Re: Gestion de la défragmentation lors de l'utilisation en tâche de fo
Posté par IsNotGood . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 2.
C'est le cas. D'ailleurs on trouve rarement des défragmenteur sous Linux.
Ici c'est de l'optimisation pour des serveurs très stressés ou +5% de performance peut être important. C'est n'est pas pour une optimisation de "desktop".
Ext4 a aussi la défragmentation à chaud.
[^] # Re: Problèmes réseau
Posté par IsNotGood . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 3.
C'est seulement un bug ou une fonctionnalité non encore réalisée. Il ne faut pas en faire un fromage.
Je ne connais les détails de ce bug, mais pas de quoi s'acharner sur NM.
Peut-être qu'avec F11 le bug sera corrigé et qu'en plus on pourra utiliser le wifi pour installer. Et là ça va être "super NM, patati et patata".
En passant, F10 intègre pour la première fois NM dans l'installeur (et c'est la première distribution à le faire). Certes, il y aura toujours des gens qui vont dire qu'il faut faire parfait dès le début. Mais pourquoi il ne l'ont pas encore fait avec NM ?...
[^] # Re: Non.
Posté par IsNotGood . En réponse au journal Cherche ISO de Windows 7. Évalué à 10.
J'ai honte de ne pas m'intéresser à ce fleuron de la technologie.
[^] # Re: On voit bien la mentalité de Canonical
Posté par IsNotGood . En réponse au journal Chronique d'une liberation annoncée..... Évalué à 2.
C'est qui "on" ?
Ce n'est pas moi.
> Vous vous foutez royalement du code de Launchpad ! Et à vrai dire, moi aussi :)
Ben moi aussi je me fous du code de Launchpad !
Ce genre de truc n'intéressera jamais plus de 2 % des développeurs et jamais plus de 0,01 % des utilisateurs.
Et alors ?
Moins de 0,01 % des utilisateurs du noyau Linux ne lisent les sources de Linux. C'est une raison pour dire, comme tu le fais pour Launchpad, qu'on en a rien à foutre que Linux soit libre ou non ?
Ton raisonnement est pervers, il est nombriliste, il manque totalement de recul.
[^] # Re: man
Posté par IsNotGood . En réponse au message Précision étrange de dc. Évalué à 2.
dc ne le fait pas. bc non plus.