Sauf que 75% des paquets source sont importés depuis debian tels quels (cf. la présentation de Zack à l'UDS-P), et il n'y a évidemment pas les ressources chez ubuntu pour les maintenir sans debian. Après, ubuntu peut continuer à vivre sans ça (car dans les paquets restant il y a ce qu'il faut pour Unity et Kubuntu), mais ça réduirait considérablement le nombre de paquets disponibles.
La vraie perte de fonctionnalité, c'est pour l'auto-montage des périphériques amovibles : c'était géré tant bien que mal par hal, mais ne l'est plus dans udisks (mais puisqu'on vous dit qu'hal c'était tout pourri et qu'udisks c'est mieux !)...
... donc utilisation d'udev (yay pour les *BSD \o/).
Donc c'est "juste" thunar-volman qui ne sert plus à rien sur !Linux.
Bien entendu, mais je pense que la façon de faire de la méthode crado (« le squashfs est une grosse archive, décompresse-le, tripatouille-le et recompresse-le ») est plus facile/visible à utiliser quand on n'est pas un pro de casper, squashfs & co...
Pas dur de faire un journal qui dénonce quand on ne sait pas utiliser un moteur de recherche.
On est encore vendredi, tu peux encore écrire un journal qui dénonce à propos des gens qui écrivent des journaux qui dénoncent sans se renseigner avant...
comme je t'ai dit : je ne vais pas donner des "morceaux" d'oxy (code, base de données, accès shell, autres) à n'importe qui...
C'est vrai que pour que quelqu'un puisse contribuer à du code, il est nécessaire qu'il ait un accès root sur les serveurs de prod, et qu'il tape directement les requêtes à la main dans la db...
Api (comme il a été dit), serveur de dév, {d,}vcs, dump partiel de la db, trac, toussa... toutes ces choses ne sont évidemment connues que des gens qui appliquent à la lettre la définition de 'libre' de la FSF...
Tous les autres (enfin, il ne reste personne, Cortex^Wla FSF domine le monde, c'est bien connu) utilisent forcément notepad.exe en root sur les serveurs de prod [*].
[*] bon, avec "cpold" comme vcs à la limite, mais c'est bien parce qu'on est vendredi
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Oui, mais ce n'est pas vraiment adapté aux SSD (qui ont généralement des pages de 2K ou plus)... C'est pour ça que j'ai dit "vaguement compatible", car ils ont choisi de les montrer comme des périphériques de type bloc car certains OS ne connaissent pas autre chose et comme ça, la diffusion des SSD se fait mieux, même si ça oblige à avoir des FTL qui font des trucs de psychopathes derrière ton dos.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Il y en a beaucoup, mais ça reste dénombrable : 512 pour les petites capacités, puis 2k, 4k ou 16k selon le type de Flash (MLC ou SLC), la capacité et le fabricant (comment ça c'est le bordel ?). Mais c'est vrai qu'avec l'interface bloc il n'y a aucun moyen de remonter des infos comme ça ("youhou, j'utilise des pages de 2k et des erase blocks de 128k"), et je suis pas sûr que ça va mieux marcher si on fait des suppositions hasardeuses ("bon allez, on considère qu'ils ont tous des pages de 4k")...
D'un autre côté, si on pousse un peu le raisonnement, on s'en fout un peu : considérer les SSD d'après les caractéristiques de la mémoire Flash utilisée est une simplification un peu rapide et risquée, étant donné que tout passe par la FTL, qui est fermée, non documentée, et qui fait ce que bon lui semble (rien que les premières générations de SSD qui ont des perfs immondes lors d'IO en parallèle alors qu'ils sont composés de plusieurs puces Flash, donc en théorie plusieurs accès concurrents possibles...).
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ?
Je ne veux pas prendre leur défense, mais sur le coup, _personne_ ne sait ce que font les FTL (bon, ok, les gens qui les codent, et c'est tout). On peut avoir plusieurs indications en lisant les brevets déposés (beurk, indigestes) ou les quelques articles ou papiers qui parlent des FTL (BAST, FAST, STAFF, DFTL, SuperBlock...), mais une nouvelle fois, rien n'indique qu'ils sont implantés...
Entre 512 et 4K, la majorité c'est 2K. Sur un SSD/Clef USB/.. c'est normalement la taille d'un secteur. Ou au moins, la taille d'un secteur est une valeur qui sera bonne.
Il me semble que la plupart des SSD remontent des valeurs débiles du genre 512 octets/secteur pour garder une vague compatibilité avec les disques durs... donc la valeur ne sera pas super adaptée au SSD...
Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
Tu peux faire des hypothèses et tirer des conclusions de certains tests, jusqu'à la prochaine révision de la FTL qui t'obligera à tout refaire. Ou pire, les déductions ne seront valables que pour ce SSD-ci et pas celui d'un autre fabricant :(...
Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.
On peut rajouter une lecture de l'état du scheduler ou le taux de remplissage du disque.
Je parlais surtout de l'état de la nand en dessous : si tu dois te farcir un copy+erase+write (de l'ordre de la ms) ou juste un write (de l'ordre du 1/10e de ms).
// The goal is to measure the worst case latency of write, this is the most demanding task
// of an SSD.
Certains SSD sont très sensibles à leur état : les performances peuvent énormément se dégrader s'il a été rempli ou non (et la manière dont il a été rempli peut influer aussi : écritures aléatoires ou écritures séquentielles).
Donc les résultats obtenus avec ce bench ne seront pas forcément reproductibles sur les disques en question, et pas non plus le pire cas (c'est entre autre expliqué dans ce papier "Understanding Flash IO patterns" : http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_102.pdf ).
Et sinon, j'ai quand même un doute sur le code, vu que le cache du kernel n'est pas désactivé, et l'ordonnanceur des IO n'est pas forcé à 'noop', donc je suppose qu'il peut un peu réorganiser les IO dans l'ordre qu'il veut, ce qui doit influencer les résultats, non ?
Un utilisateur a bien résumé ce qui se passe : Xubuntu est devenu (x)Ubuntu.
> Nom d'un chien mais pourquoi dénaturer ainsi Xubuntu ? Personnellement je m'en fiche car j'utilise une Ubuntu classique et j'aime Gnome....mais j'imagine l'amertume des supporteurs d'XFCE !
C'est un choix du "papa" de xubuntu (Jani), sans tenir vraiment compte de l'avis du second développeur et des réponses sur la liste de développement. :(
> 1) Xarchiver est viré au profit de l'outil standard Gnome (File-roller)
Je n'utilise pas vraiment de gui pour extraire les archives, donc de ce côté-là je peux pas dire. Il y avait aussi squeeze (http://squeeze.xfce.org/), mais son développeur considère qu'il n'est pas encore prêt...
> 2) Gxine est viré au profit de l'outil standard Gnome (Totem)
> 4) xfce4-taskmanager est viré au profit de l'outil standard Gnome (System monitor)
> 5) Ajout de tous les jeux de Gnome-games (17 jeux !)
Ces 3 là sont des décisions unilatérales de Jani, en consultant après coup (genre : « j'ai ajouté totem et gnome-games dans xubuntu, ça ne vous dérange pas ? »
> 3) Xfburn est viré au profit de Brasero
Le paquet xfburn d'ubuntu est buggué, et le programme ne semble pas vraiment maintenu. Le seul problème avec brasero c'est sa dépendance sur libgnome* et libtotem-plparser... Il avait aussi été proposé de ne pas inclure d'application de gravure, tout simplement.
> Est-ce un moyen détourné de la part de Canonical de réduire la charge de travail que représente cette variante de la distro principale ?
Aucun employé Canonical ne travaille sur xubuntu directement. La charge principale pour eux c'est la génération des isos, rien de plus...
Mais si on en croit ce message (https://lists.ubuntu.com/archives/xubuntu-devel/2007-October/004507.html), Jani ne va pas participer au cycle suivant, donc il y a une chance de tout redresser ^^"
[^] # Re: Debian is dying, tué par ubuntu
Posté par mr_pouit (site web personnel) . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 3.
Sauf que 75% des paquets source sont importés depuis debian tels quels (cf. la présentation de Zack à l'UDS-P), et il n'y a évidemment pas les ressources chez ubuntu pour les maintenir sans debian. Après, ubuntu peut continuer à vivre sans ça (car dans les paquets restant il y a ce qu'il faut pour Unity et Kubuntu), mais ça réduirait considérablement le nombre de paquets disponibles.
[^] # Re: Xfce, mais pas pour BSD
Posté par mr_pouit (site web personnel) . En réponse au journal Xfce 4.8 est là !. Évalué à 1.
... donc utilisation d'udev (yay pour les *BSD \o/).
Donc c'est "juste" thunar-volman qui ne sert plus à rien sur !Linux.
[^] # Re: Bravo...
Posté par mr_pouit (site web personnel) . En réponse au journal Adaptation d'Ubuntu : comme Windows…. Évalué à 1.
[^] # Re: Avec le bon nombre de caractères de remplacement
Posté par mr_pouit (site web personnel) . En réponse au journal Ayez les cou**** d'assumer votre grossièreté. Évalué à 4.
# Bravo...
Posté par mr_pouit (site web personnel) . En réponse au journal Adaptation d'Ubuntu : comme Windows…. Évalué à 10.
http://bazaar.launchpad.net/~cjwatson/ubuntu-cdimage/mainlin(...)
Pas dur de faire un journal qui dénonce quand on ne sait pas utiliser un moteur de recherche.
On est encore vendredi, tu peux encore écrire un journal qui dénonce à propos des gens qui écrivent des journaux qui dénoncent sans se renseigner avant...
[^] # Re: uzbl et surf
Posté par mr_pouit (site web personnel) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 0.
[^] # Re: "la preuve"
Posté par mr_pouit (site web personnel) . En réponse au journal Pourquoi il ne faut pas adhérer à Oxyradio. Évalué à 2.
C'est vrai que pour que quelqu'un puisse contribuer à du code, il est nécessaire qu'il ait un accès root sur les serveurs de prod, et qu'il tape directement les requêtes à la main dans la db...
Api (comme il a été dit), serveur de dév, {d,}vcs, dump partiel de la db, trac, toussa... toutes ces choses ne sont évidemment connues que des gens qui appliquent à la lettre la définition de 'libre' de la FSF...
Tous les autres (enfin, il ne reste personne, Cortex^Wla FSF domine le monde, c'est bien connu) utilisent forcément notepad.exe en root sur les serveurs de prod [*].
[*] bon, avec "cpold" comme vcs à la limite, mais c'est bien parce qu'on est vendredi
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par mr_pouit (site web personnel) . En réponse au journal Unified Flash File System. Évalué à 2.
Oui, mais ce n'est pas vraiment adapté aux SSD (qui ont généralement des pages de 2K ou plus)... C'est pour ça que j'ai dit "vaguement compatible", car ils ont choisi de les montrer comme des périphériques de type bloc car certains OS ne connaissent pas autre chose et comme ça, la diffusion des SSD se fait mieux, même si ça oblige à avoir des FTL qui font des trucs de psychopathes derrière ton dos.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Il y en a beaucoup, mais ça reste dénombrable : 512 pour les petites capacités, puis 2k, 4k ou 16k selon le type de Flash (MLC ou SLC), la capacité et le fabricant (comment ça c'est le bordel ?). Mais c'est vrai qu'avec l'interface bloc il n'y a aucun moyen de remonter des infos comme ça ("youhou, j'utilise des pages de 2k et des erase blocks de 128k"), et je suis pas sûr que ça va mieux marcher si on fait des suppositions hasardeuses ("bon allez, on considère qu'ils ont tous des pages de 4k")...
D'un autre côté, si on pousse un peu le raisonnement, on s'en fout un peu : considérer les SSD d'après les caractéristiques de la mémoire Flash utilisée est une simplification un peu rapide et risquée, étant donné que tout passe par la FTL, qui est fermée, non documentée, et qui fait ce que bon lui semble (rien que les premières générations de SSD qui ont des perfs immondes lors d'IO en parallèle alors qu'ils sont composés de plusieurs puces Flash, donc en théorie plusieurs accès concurrents possibles...).
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ?
Je ne veux pas prendre leur défense, mais sur le coup, _personne_ ne sait ce que font les FTL (bon, ok, les gens qui les codent, et c'est tout). On peut avoir plusieurs indications en lisant les brevets déposés (beurk, indigestes) ou les quelques articles ou papiers qui parlent des FTL (BAST, FAST, STAFF, DFTL, SuperBlock...), mais une nouvelle fois, rien n'indique qu'ils sont implantés...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par mr_pouit (site web personnel) . En réponse au journal Unified Flash File System. Évalué à 1.
Il me semble que la plupart des SSD remontent des valeurs débiles du genre 512 octets/secteur pour garder une vague compatibilité avec les disques durs... donc la valeur ne sera pas super adaptée au SSD...
Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
Tu peux faire des hypothèses et tirer des conclusions de certains tests, jusqu'à la prochaine révision de la FTL qui t'obligera à tout refaire. Ou pire, les déductions ne seront valables que pour ce SSD-ci et pas celui d'un autre fabricant :(...
Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.
Certains fabricants de Flash "inventent" des trucs (genre http://download.micron.com/pdf/technotes/nand/tn2941_idm_cop(...) ) pour essayer d'éviter ça...
[^] # Re: État du SSD ?
Posté par mr_pouit (site web personnel) . En réponse au journal [SSD] Mesure de la latence d'écriture aléatoire sur disque. Évalué à 1.
Je parlais surtout de l'état de la nand en dessous : si tu dois te farcir un copy+erase+write (de l'ordre de la ms) ou juste un write (de l'ordre du 1/10e de ms).
# État du SSD ?
Posté par mr_pouit (site web personnel) . En réponse au journal [SSD] Mesure de la latence d'écriture aléatoire sur disque. Évalué à 3.
// of an SSD.
Certains SSD sont très sensibles à leur état : les performances peuvent énormément se dégrader s'il a été rempli ou non (et la manière dont il a été rempli peut influer aussi : écritures aléatoires ou écritures séquentielles).
Donc les résultats obtenus avec ce bench ne seront pas forcément reproductibles sur les disques en question, et pas non plus le pire cas (c'est entre autre expliqué dans ce papier "Understanding Flash IO patterns" : http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_102.pdf ).
Et sinon, j'ai quand même un doute sur le code, vu que le cache du kernel n'est pas désactivé, et l'ordonnanceur des IO n'est pas forcé à 'noop', donc je suppose qu'il peut un peu réorganiser les IO dans l'ordre qu'il veut, ce qui doit influencer les résultats, non ?
# (x)ubuntu
Posté par mr_pouit (site web personnel) . En réponse au journal De l'utilité de Xubuntu. Évalué à 4.
> Nom d'un chien mais pourquoi dénaturer ainsi Xubuntu ? Personnellement je m'en fiche car j'utilise une Ubuntu classique et j'aime Gnome....mais j'imagine l'amertume des supporteurs d'XFCE !
C'est un choix du "papa" de xubuntu (Jani), sans tenir vraiment compte de l'avis du second développeur et des réponses sur la liste de développement. :(
> 1) Xarchiver est viré au profit de l'outil standard Gnome (File-roller)
Je n'utilise pas vraiment de gui pour extraire les archives, donc de ce côté-là je peux pas dire. Il y avait aussi squeeze (http://squeeze.xfce.org/), mais son développeur considère qu'il n'est pas encore prêt...
> 2) Gxine est viré au profit de l'outil standard Gnome (Totem)
> 4) xfce4-taskmanager est viré au profit de l'outil standard Gnome (System monitor)
> 5) Ajout de tous les jeux de Gnome-games (17 jeux !)
Ces 3 là sont des décisions unilatérales de Jani, en consultant après coup (genre : « j'ai ajouté totem et gnome-games dans xubuntu, ça ne vous dérange pas ? »
> 3) Xfburn est viré au profit de Brasero
Le paquet xfburn d'ubuntu est buggué, et le programme ne semble pas vraiment maintenu. Le seul problème avec brasero c'est sa dépendance sur libgnome* et libtotem-plparser... Il avait aussi été proposé de ne pas inclure d'application de gravure, tout simplement.
> Est-ce un moyen détourné de la part de Canonical de réduire la charge de travail que représente cette variante de la distro principale ?
Aucun employé Canonical ne travaille sur xubuntu directement. La charge principale pour eux c'est la génération des isos, rien de plus...
Mais si on en croit ce message (https://lists.ubuntu.com/archives/xubuntu-devel/2007-October/004507.html), Jani ne va pas participer au cycle suivant, donc il y a une chance de tout redresser ^^"