> Gnome & KDE ne peuvent pas être présent sur un CD (la galette est trop petite).
Pas de problème avec ça. De plus l'installeur permet d'ajouter Gnome depuis le réseau.
> Dual, n'a rien à voir avec KDE ou Gnome, c'est pour les images sur clef USB ...
C'est la seul image CD pour Free...
> Donc si tu pars d'un CD KDE
Pas le choix si je ne veux pas de proprio et ne veut pas télécharger un DVD.
> Je vois pas trop ce que tu veux dire avec "la fenêtre descend".
Elle descend, elle va vers le bas de l'écran et tellement loins qu'elle disparait de l'écran.
> Free = personne avancée, sachant ce qu'elle fait.
La Free doit être pour ceux qui ne veulent pas de proprio ! C'est tout, il ne doit pas y avoir d'autres différences avec la One.
> Bref, c'est dommage de faire un test à l'aveuglette en choisissant la version la "moins" intuitive sans s'impliquer.
J'ai pris la version la plus libre et à l'avenir je le ferais encore.
En passant, ma distribution préférée n'a que du libre et ce n'est pas une "sous-distribution".
> Les conclusions ne peuvent pas être bonnes.
Oubliez mon test. Pas de problème. Ce que j'ai fait n'est pas représentatif.
Petite précision.
J'ai cherché à savoir ce qui était utilisé pour la virtualisation chez Mandriva car j'ai eu des problèmes en testant cette RC sous KVM.
Si j'éssaie de faire une synthèse, j'ai un problème réseau et Xorg. On peut dire que c'est grave (surtout le réseau) et que ça ne l'est pas vraiment vu le nombre de semaines qui reste avant la sortie et car c'est une bête installation sous KVM pour faire un test à l'arrache. Tester pour les développeurs est facile dans ce cas. Enfin, il ne faut pas écarter un problème avec la configuration de Fedora que j'ai. Je refais un essai en utilisant "safe setting" (lors du boot de l'installation), ça a corrigé le problème de menu.
Pour Fedora Rawhide et Ubuntu Alpha, j'ai aussi des problèmes d'affichage mais pas très génant. Pas de problème pour F10. Donc peut-être un problème Xorg 1.6.
Le mieux est qu'un Mandrivien fasse un essai, ce n'est pas contraignant sous KVM
> Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.
Ou, plus intéressant, c'est l'utilisation de Xen userland avec KVM (sans noyau kernel-xen). Je crois que c'est un objectif de Fedora qui fournit toujours Xen mais pas kernel-xen.
Donc kernel-xen pour 2009 Spring et virt-manageur ne sont pas "garantis en ce qui concerne les problèmes de sécurité" (dixit Mandriva).
Par contre Xen oui...
Libvirt est "garantis..." mais virt-manager ne l'est pas.
Où la cohérence ?
> Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.
C'est une explication possible.
En passant, on parle d'une Realese Candidat, pas de la première Alpha.
Super, un 2.6.18 qui n'est pas dans main.
Dis que je n'y comprend rien à l'organisation de Mandriva. Pas de problème.
Mais je n'ai pas trouvé le moindre kernel-xen dans la branche cooker/devel. Alors qu'il y a Xen dans main. Mais je suis sûr que tu vas trouver ça très logique de fournir Xen et ne pas pouvoir l'utiliser.
> Effectivement virt-manager est dans contrib : et alors ?
Donc main et contrib c'est la même chose.
Dommage qu'ils ne les fusionnent pas alors...
Et plus con encore qu'ils aient fait deux foix la même chose.
> C'est vraiment critiquer pour critiquer
J'avais un moment oublié que les mandriviens n'accèptaient pas les critiques.
Sauf peut-être la récurrente "la version précédente était mauvaise, mais la nouvelle est très bonne". Sûr qu'on va encore y avoir droit dans 6 ou 12 mois.
Je me demande si ce document est bien à jour...
La 2009 spring fournit toujours Xen (je doute qu'il y ait un support Xen dans le noyau).
Il est indiqué le passage à virt-manager, mais il n'y est pas dans la rc1. Il y a virtualbox. Notons qu'il y a libvirt. Mais libvirt "tout nu", c'est un peu dure d'utilisation. Par contre il y a virualbox...
A ce demander si c'est une release candidat.
Sûr qu'on doit trouver virt-manager dans contrib. Mais c'est virtualbox qu'il y a dans main. Il est moins suprenant que j'ai eu des problèmes lors de mon test puisqu'il a été fait avec kvm.
Je viens de faire un minimini-test sur une machine virtuelle. J'ai utilisé la Free et non la one. J'ai bien le droit de ne pas vouloir de proprio !
Bizarre, il n'y a pas d'image pour Gnome, il y a "dual". Pourquoi des "saveurs" différentes entre Free et One ?
A l'installation j'ai demandé d'ajouter Gnome, il n'y était pas à l'arrivé.
A l'installation la carte réseau a été correctement configurée (il me semble). Plus loin l'installeur dit que je dois configurer une carte réseau puisque j'ai demandé d'ajouter Gnome et qu'il n'est pas sur l'ISO... L'installeur échoue. Peut-être que la carte n'était pas configurée contrairement à ce que j'ai dit, mais quoiqu'il en soit au final je n'ai de réseau.
Premier login (sous KDE, pas de Gnome malheureusement), le menu est vide !
Je lance FF de la barre de tâche et ça part en couille. La fenêtre de FF s'affiche, mais elle ... descent doucement jusqu'à ne plus être visible.
Bref, ça m'a pris 0,001 seconde pour décider de détruire la machine virtuelle où j'ai fait l'installation.
NB: La dernier Ubuntu et Fedora (ainsi que leur version de développement) s'installent sans problème sur une machine virtuelle ici.
Je n'en conclus pas grand chose, c'est en développement.
> D'ailleurs il me semble que les dev RedHat ont dit penser à ce genre de code quand Mandriva a sorti les détails sur bootspeed.
Adam Willamson a dit qu'il fallait y penser. En effet, il y a eu des benchs et la dernier cooker boote plus vite que rawhide (la futur F11). Mais ceci ne prend pas en compte le temps de login.
Il n'est pas acquis que le principe de bootspeed soit adopté par Fedora.
Au premier abord je suis contre. Néanmoins dans les cas d'éléments externes qui ralentissent le boot (par exemple dhcp), c'est à considérer sérieusement.
> tu as une source pour ça ? J'en ai jamais entendu parler...
J'ai vu un truc passer. Ça disait que Fedora abandonnait les anciens scripts de boot et qu'il fallait autre chose à Mandriva. Upstart a été suggéré.
Par exemple : http://lists.mandriva.com/maintainers/2007-09/msg00393.php http://wiki.mandriva.com/en/uploads/6/61/Specs_2009spring.pd(...)
2.5.5.1. initscript improvements
Fedora has replaced rc.sysinit by upstart, starting with Fedora 9. This mean initscripts will probably no longer be maintained by Redhat soon. We should check upstart and see if it fits our needs (and doesn’t duplicate with prcsys).
It could also be useful to start some services / programs after one specific event (desktop started, etc..) to make sure CPU is not overloaded at startup.
> C' est il me semble un peu la même tambouille (pas technique, seul le résultat) que upstart
Techniquement on peut y trouver des ressemblances. Le but d'upstart est plus générique, on peut lancer des services après gdm, on peut aussi ne pas le faire (je crois qu'actuellement personne ne le fait).
Comme Mandriva va passer à upstart, il faudra refaire bootspeed pour utiliser upstart.
Perso je préfère que mon système ait fini de booter une fois que GDM a fini de se charger.
Ici le Windows touch ne me plait pas du tout.
> tien d' ailleurs Redhat travaille au remplacement de upstart
A ma connaissance non. Red Hat utilise upstart. Du moins Fedora actuellement et RHEL pour la version 6.
Par contre, avant l'arrivée d'upstart, Red Hat réfléchissait à remplacer init. Les idées de Red Hat étaient très proches de upstart, upstart a été pris.
> pstart c' est génial pour les workstations, et encore, ça se discute. Par contre pour les serveurs et les stations avec de nombreux softs ISV ça pu sévère.
???
Je ne vois pas pourquoi ça pu sur serveur.
C'est évidement moins utile puisque les serveurs ne sont pas booté tous les matins.
> softs ISV
Passer à upstart n'est pas grand chose. Les ISV devront certifier à nouveau leur programme pour RHEL6, ils en profiterons pour faire les adaptions nécessaires à upstart. J'ignore s'il faut faire des modifications...
> Blagues à part, la cooker en ce moment c' est de la bombe. La 2009.1 pourrait bien être la meilleure distribution jamais sortie par mandrake/lycoris/connectiva/mandriva !!
Il me semble avoir déjà lu ça...
> Si ça avait été un kernel non-rc, ça aurait raler parceque c' était pas le kernel le plus récent, et si c' est un rc, ça rale aussi :p
La remarque de 6arts est pertinente surtout quand on nous met autant de baratin sur la stabilité. Ce qui me surprend, est que personne ne dit que Mandriva veut utiliser le même noyau que Fedora et Ubuntu au-lieu de bosser tout seul dans son coin. Mandriva profite des tests de Fedora et Ubuntu (et vice versa). Ce n'est pas con même sur l'aspect stabilité.
Es-ce qu'OpenSuse utilise aussi un 2.6.29 ?
> pays dont les élites politiques et économiques ne comprennent plus rien ni à la jeunesse, ni à la technologie, ni à la culture.
Ça ressemble furieusement à la définition de la droite.
Et en plus la notre est décompléxée (c'était sur l'étiquette en 2007).
Comment s'étonner alors ?
> C'est l'OS qui fait ça si on lui demande, sachant qu'on a un écran LCD.
Pourquoi lui demanderait ça ?
Et c'est l'écran qui fait le lissage lorsqu'il y a écart entre la sortie de la carte et l'écran.
Par exemple si la carte envoie du 1024x768 alors que l'écran est du 1280x960, l'écran fait le lissage (et souvent c'est pourri ; aussi bien sous Vista que n'importe quoi).
> Donc ça apparaîtera sur un screenshot
Non.
> si on zoom
Le zoom peut effectivement être fait par l'OS, sauf dans le cas de vidéo. Pour la vidéo c'est alors généralement la carte graphique qui le fait.
Les zooms et lissage on peut les trouver à plein d'endroit. Alors de quoi en parle ?
Par exemple, il faut un lissage (pas de zoom) pour les polices vectorielles. Après l'écran (s'il y a différence entre la résolution qu'il affiche et celle qui reçoit) peut faire un zoom. Si on ne veut pas que le zoom soit pourrit, il faut un lissage. Les cartes graphiques peuvent faire du lissage et le font pour la vidéo. Le résultat est généralement très bon.
En passant, mplayer fait zoom avec la carte graphique ou peut aussi le faire lui même. On peut spécifier l'algorithme à utiliser.
Quoiqu'il en soit avec un zoom il y a toujours dégradation si l'image zoomée est "parfaite".
Un pixel noir suivi d'un blanc (ce qui est exactement ce qu'on veut dans l'image d'origine) devient un pixer noir suivi d'un gris suivi d'un blanc. Si le pixel du milieu est rend noir ou blanc, on rend la déformation évidente (partie noir trop grosse ou gros mince). C'est un classique problème d'échantillonnage (aussi bien pour le lissage que pour le zoom). C'était seulement ça que voulait dire ce journal pourri ?
Non. Et c'est peut-être même l'inverse.
Le "multisiège" n'est pas une priorité durant cette période de boulversement de Linux et Xorg. Il n'est pas complètement oublié, il y a quelles rares configurations qui marchent.
La période est rude pour certains utilisateurs. Mais les choses avancent et ça va se calmer.
Dans ce l'OS ne voit rien, c'est fait par l'écran. Donc une copie d'écran n'aura pas ce défaut.
De plus, je ne vois pas en quoi c'est spécifique à Vista. Le lissage sous GNU/Linux est pire.
Ce journal est sans intérêt. Si je n'ai rien compris, comme pratiquement tout le monde ici, il est complètement pourri. Les "private joke" ne sont bons qu'en privé.
# Utilisation de la fonction back
Posté par IsNotGood . En réponse au journal Templeet, rapide, mais même pas web 1.0. Évalué à 1.
# Utilisation de la fonction back
Posté par IsNotGood . En réponse au journal Templeet, rapide, mais même pas web 1.0. Évalué à 1.
[^] # Re: on dirait IsNotGood
Posté par IsNotGood . En réponse au journal La perle du jour : Alfresco vs Sharepoint. Évalué à 3.
La réponse à la question est non.
[^] # Re: on dirait IsNotGood
Posté par IsNotGood . En réponse au journal La perle du jour : Alfresco vs Sharepoint. Évalué à 2.
[^] # Re: on dirait IsNotGood
Posté par IsNotGood . En réponse au journal La perle du jour : Alfresco vs Sharepoint. Évalué à 9.
[^] # Re: une RC avec un kernel non stable
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 3.
Non, trop gros à télécharger.
> Gnome & KDE ne peuvent pas être présent sur un CD (la galette est trop petite).
Pas de problème avec ça. De plus l'installeur permet d'ajouter Gnome depuis le réseau.
> Dual, n'a rien à voir avec KDE ou Gnome, c'est pour les images sur clef USB ...
C'est la seul image CD pour Free...
> Donc si tu pars d'un CD KDE
Pas le choix si je ne veux pas de proprio et ne veut pas télécharger un DVD.
> Je vois pas trop ce que tu veux dire avec "la fenêtre descend".
Elle descend, elle va vers le bas de l'écran et tellement loins qu'elle disparait de l'écran.
> Free = personne avancée, sachant ce qu'elle fait.
La Free doit être pour ceux qui ne veulent pas de proprio ! C'est tout, il ne doit pas y avoir d'autres différences avec la One.
> Bref, c'est dommage de faire un test à l'aveuglette en choisissant la version la "moins" intuitive sans s'impliquer.
J'ai pris la version la plus libre et à l'avenir je le ferais encore.
En passant, ma distribution préférée n'a que du libre et ce n'est pas une "sous-distribution".
> Les conclusions ne peuvent pas être bonnes.
Oubliez mon test. Pas de problème. Ce que j'ai fait n'est pas représentatif.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
J'ai cherché à savoir ce qui était utilisé pour la virtualisation chez Mandriva car j'ai eu des problèmes en testant cette RC sous KVM.
Si j'éssaie de faire une synthèse, j'ai un problème réseau et Xorg. On peut dire que c'est grave (surtout le réseau) et que ça ne l'est pas vraiment vu le nombre de semaines qui reste avant la sortie et car c'est une bête installation sous KVM pour faire un test à l'arrache. Tester pour les développeurs est facile dans ce cas. Enfin, il ne faut pas écarter un problème avec la configuration de Fedora que j'ai. Je refais un essai en utilisant "safe setting" (lors du boot de l'installation), ça a corrigé le problème de menu.
Pour Fedora Rawhide et Ubuntu Alpha, j'ai aussi des problèmes d'affichage mais pas très génant. Pas de problème pour F10. Donc peut-être un problème Xorg 1.6.
Le mieux est qu'un Mandrivien fasse un essai, ce n'est pas contraignant sous KVM
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 3.
Ou, plus intéressant, c'est l'utilisation de Xen userland avec KVM (sans noyau kernel-xen). Je crois que c'est un objectif de Fedora qui fournit toujours Xen mais pas kernel-xen.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
D'accord.
> Tu trouveras une définition sur http://wiki.mandriva.com/fr/Source
Donc kernel-xen pour 2009 Spring et virt-manageur ne sont pas "garantis en ce qui concerne les problèmes de sécurité" (dixit Mandriva).
Par contre Xen oui...
Libvirt est "garantis..." mais virt-manager ne l'est pas.
Où la cohérence ?
> Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.
C'est une explication possible.
En passant, on parle d'une Realese Candidat, pas de la première Alpha.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
Mais ça ne change pas grand chose :-)
Ce que tu pointes n'est pas ce à quoi je pense et j'ai la flemme de chercher.
Qu'importe, Fedora y pense.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 1.
Super, un 2.6.18 qui n'est pas dans main.
Dis que je n'y comprend rien à l'organisation de Mandriva. Pas de problème.
Mais je n'ai pas trouvé le moindre kernel-xen dans la branche cooker/devel. Alors qu'il y a Xen dans main. Mais je suis sûr que tu vas trouver ça très logique de fournir Xen et ne pas pouvoir l'utiliser.
> Effectivement virt-manager est dans contrib : et alors ?
Donc main et contrib c'est la même chose.
Dommage qu'ils ne les fusionnent pas alors...
Et plus con encore qu'ils aient fait deux foix la même chose.
> C'est vraiment critiquer pour critiquer
J'avais un moment oublié que les mandriviens n'accèptaient pas les critiques.
Sauf peut-être la récurrente "la version précédente était mauvaise, mais la nouvelle est très bonne". Sûr qu'on va encore y avoir droit dans 6 ou 12 mois.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
Je me demande si ce document est bien à jour...
La 2009 spring fournit toujours Xen (je doute qu'il y ait un support Xen dans le noyau).
Il est indiqué le passage à virt-manager, mais il n'y est pas dans la rc1. Il y a virtualbox. Notons qu'il y a libvirt. Mais libvirt "tout nu", c'est un peu dure d'utilisation. Par contre il y a virualbox...
A ce demander si c'est une release candidat.
Sûr qu'on doit trouver virt-manager dans contrib. Mais c'est virtualbox qu'il y a dans main. Il est moins suprenant que j'ai eu des problèmes lors de mon test puisqu'il a été fait avec kvm.
[^] # Re: une RC avec un kernel non stable
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
Il y a "et vice versa".
> J' espère que tu la testera en profondeur
Je viens de faire un minimini-test sur une machine virtuelle.
J'ai utilisé la Free et non la one. J'ai bien le droit de ne pas vouloir de proprio !
Bizarre, il n'y a pas d'image pour Gnome, il y a "dual". Pourquoi des "saveurs" différentes entre Free et One ?
A l'installation j'ai demandé d'ajouter Gnome, il n'y était pas à l'arrivé.
A l'installation la carte réseau a été correctement configurée (il me semble). Plus loin l'installeur dit que je dois configurer une carte réseau puisque j'ai demandé d'ajouter Gnome et qu'il n'est pas sur l'ISO... L'installeur échoue. Peut-être que la carte n'était pas configurée contrairement à ce que j'ai dit, mais quoiqu'il en soit au final je n'ai de réseau.
Premier login (sous KDE, pas de Gnome malheureusement), le menu est vide !
Je lance FF de la barre de tâche et ça part en couille. La fenêtre de FF s'affiche, mais elle ... descent doucement jusqu'à ne plus être visible.
Bref, ça m'a pris 0,001 seconde pour décider de détruire la machine virtuelle où j'ai fait l'installation.
NB: La dernier Ubuntu et Fedora (ainsi que leur version de développement) s'installent sans problème sur une machine virtuelle ici.
Je n'en conclus pas grand chose, c'est en développement.
[^] # Re: une RC avec un kernel non stable
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
T'as raison. Désolé.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
Adam Willamson a dit qu'il fallait y penser. En effet, il y a eu des benchs et la dernier cooker boote plus vite que rawhide (la futur F11). Mais ceci ne prend pas en compte le temps de login.
Il n'est pas acquis que le principe de bootspeed soit adopté par Fedora.
Au premier abord je suis contre. Néanmoins dans les cas d'éléments externes qui ralentissent le boot (par exemple dhcp), c'est à considérer sérieusement.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 3.
J'ai vu un truc passer. Ça disait que Fedora abandonnait les anciens scripts de boot et qu'il fallait autre chose à Mandriva. Upstart a été suggéré.
Par exemple :
http://lists.mandriva.com/maintainers/2007-09/msg00393.php
http://wiki.mandriva.com/en/uploads/6/61/Specs_2009spring.pd(...)
2.5.5.1. initscript improvements
Fedora has replaced rc.sysinit by upstart, starting with Fedora 9. This mean initscripts will probably no longer be maintained by Redhat soon. We should check upstart and see if it fits our needs (and doesn’t duplicate with prcsys).
It could also be useful to start some services / programs after one specific event (desktop started, etc..) to make sure CPU is not overloaded at startup.
Ce n'est pas définitif.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
Techniquement on peut y trouver des ressemblances. Le but d'upstart est plus générique, on peut lancer des services après gdm, on peut aussi ne pas le faire (je crois qu'actuellement personne ne le fait).
Comme Mandriva va passer à upstart, il faudra refaire bootspeed pour utiliser upstart.
Perso je préfère que mon système ait fini de booter une fois que GDM a fini de se charger.
Ici le Windows touch ne me plait pas du tout.
[^] # Re: Speedboot
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à 2.
A ma connaissance non. Red Hat utilise upstart. Du moins Fedora actuellement et RHEL pour la version 6.
Par contre, avant l'arrivée d'upstart, Red Hat réfléchissait à remplacer init. Les idées de Red Hat étaient très proches de upstart, upstart a été pris.
> pstart c' est génial pour les workstations, et encore, ça se discute. Par contre pour les serveurs et les stations avec de nombreux softs ISV ça pu sévère.
???
Je ne vois pas pourquoi ça pu sur serveur.
C'est évidement moins utile puisque les serveurs ne sont pas booté tous les matins.
> softs ISV
Passer à upstart n'est pas grand chose. Les ISV devront certifier à nouveau leur programme pour RHEL6, ils en profiterons pour faire les adaptions nécessaires à upstart. J'ignore s'il faut faire des modifications...
[^] # Re: une RC avec un kernel non stable
Posté par IsNotGood . En réponse à la dépêche Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation.... Évalué à -1.
Il me semble avoir déjà lu ça...
> Si ça avait été un kernel non-rc, ça aurait raler parceque c' était pas le kernel le plus récent, et si c' est un rc, ça rale aussi :p
La remarque de 6arts est pertinente surtout quand on nous met autant de baratin sur la stabilité. Ce qui me surprend, est que personne ne dit que Mandriva veut utiliser le même noyau que Fedora et Ubuntu au-lieu de bosser tout seul dans son coin. Mandriva profite des tests de Fedora et Ubuntu (et vice versa). Ce n'est pas con même sur l'aspect stabilité.
Es-ce qu'OpenSuse utilise aussi un 2.6.29 ?
# Re:
Posté par IsNotGood . En réponse au journal HADOPI est un signe de plus d’un pays dont les élites politiques et économiques ne comprennent plus rien ni à la jeunesse, ni à la technologie, ni à la culture. Évalué à 1.
Ça ressemble furieusement à la définition de la droite.
Et en plus la notre est décompléxée (c'était sur l'étiquette en 2007).
Comment s'étonner alors ?
[^] # Re: un petit exemple ?
Posté par IsNotGood . En réponse au journal Luttons contre les screenshot fait sous Vista. Évalué à -3.
Pourquoi lui demanderait ça ?
Et c'est l'écran qui fait le lissage lorsqu'il y a écart entre la sortie de la carte et l'écran.
Par exemple si la carte envoie du 1024x768 alors que l'écran est du 1280x960, l'écran fait le lissage (et souvent c'est pourri ; aussi bien sous Vista que n'importe quoi).
> Donc ça apparaîtera sur un screenshot
Non.
> si on zoom
Le zoom peut effectivement être fait par l'OS, sauf dans le cas de vidéo. Pour la vidéo c'est alors généralement la carte graphique qui le fait.
Les zooms et lissage on peut les trouver à plein d'endroit. Alors de quoi en parle ?
Par exemple, il faut un lissage (pas de zoom) pour les polices vectorielles. Après l'écran (s'il y a différence entre la résolution qu'il affiche et celle qui reçoit) peut faire un zoom. Si on ne veut pas que le zoom soit pourrit, il faut un lissage. Les cartes graphiques peuvent faire du lissage et le font pour la vidéo. Le résultat est généralement très bon.
En passant, mplayer fait zoom avec la carte graphique ou peut aussi le faire lui même. On peut spécifier l'algorithme à utiliser.
Quoiqu'il en soit avec un zoom il y a toujours dégradation si l'image zoomée est "parfaite".
Un pixel noir suivi d'un blanc (ce qui est exactement ce qu'on veut dans l'image d'origine) devient un pixer noir suivi d'un gris suivi d'un blanc. Si le pixel du milieu est rend noir ou blanc, on rend la déformation évidente (partie noir trop grosse ou gros mince). C'est un classique problème d'échantillonnage (aussi bien pour le lissage que pour le zoom). C'était seulement ça que voulait dire ce journal pourri ?
[^] # Re: un petit exemple ?
Posté par IsNotGood . En réponse au journal Luttons contre les screenshot fait sous Vista. Évalué à 4.
Sous linux c'est pire pour la simple raison que Linux ne peut pas utiliser certaines méthodes de lissage (elles sont brevetés) reconnues meilleures.
> http://moipetit.free.fr/test/Linux_vs_OS_X.png
Polices de caractère différentes. Pas grand chose à voir avec le lissage.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par IsNotGood . En réponse à la dépêche Le serveur X 1.6 est disponible. Évalué à 1.
Non. Et c'est peut-être même l'inverse.
Le "multisiège" n'est pas une priorité durant cette période de boulversement de Linux et Xorg. Il n'est pas complètement oublié, il y a quelles rares configurations qui marchent.
La période est rude pour certains utilisateurs. Mais les choses avancent et ça va se calmer.
[^] # Re: Ouinnn
Posté par IsNotGood . En réponse au journal qemu 0.10 is out \o/. Évalué à 2.
Non.
[^] # Re: un petit exemple ?
Posté par IsNotGood . En réponse au journal Luttons contre les screenshot fait sous Vista. Évalué à -2.
De plus, je ne vois pas en quoi c'est spécifique à Vista. Le lissage sous GNU/Linux est pire.
Ce journal est sans intérêt. Si je n'ai rien compris, comme pratiquement tout le monde ici, il est complètement pourri. Les "private joke" ne sont bons qu'en privé.