mickabouille a écrit 1321 commentaires

Il me semble donc abusif (comme semblerait l'indiquer le début de l'article) de l'identifier au syllogisme, qui n'en est qu'un aspect (même si, dans le corps de l'article sont reprises toutes les figures du sophisme.)

La notion de syllogisme est indépendante de (au mieux, au pire je dirais "opposée à") celle de sophisme.

Un syllogisme est au contraire un A => B or A donc B.

La confusion est dûe au fait que les sophistes utilisaient beacoup de "faux syllogismes", par exemple le A => B or B donc A (fausse contraposition).

Encore une loi idiote : "Security through obscurity..."
Sauf qu'on se dirige vers là en informatique aussi, où il devient périlleux d'indiquer à un webmaster où à un éditeur un bug dans un produit/page web.

C'est pas en interdisant la parution de ces lieux sur des photos qu'on empêchera aux gens de savoir où ils sont.

Quand à une photographie détaillée, je suis persuadé que les ex pays de l'est en ont des milliers... en vente libre un peu partout.

J'espère qu'il passeront à une numérotation avant la dix millième divinité...

>Si GNUStep ne peut être dévelopé qu'en Objective C,
et en java ( http://www.gnustep.it/jigs/ ), de façon officielle ( http://www.gnustep.org/resources/documentation/User/GNUstep/(...) )

Il y a un pilote natif pour ta carte : bcm43xx, dont la page principale est là : http://bcm43xx.berlios.de/

Il se trouve qu'en plus, ce pilote est déjà inclus avec le noyau 2.6.17. Hélas, il n'y a pas de version récente qui fonctionne avec des noyaux plus récents. Et pour ce que j'en sais, le 4306 fonctionne très bien avec ce pilote (au contraire de mon 4318, qui a un problème au niveau de la puissance du signal).

En gros, il suffit donc de changer de noyau, ce que je pense toute les distribs permettent. Plus ou moins facilement. Enfin bref. Il faut être un peut débrouillard, et je pense que quelqu'un qui triture ndiswrapper doit l'être assez pour compiler un noyau, alors installer un paquet pré-compilé...

Tu auras quand même besoin de ton pilote windows (pour en extraire le firmware). Il y a des aides spécifiques à la distribution là http://bcm43xx.berlios.de/?go=Documentation

Voilà, sinon, si tu tiens à ndiswrapper, je ne sais pas....

>qui ne sont au final que des Desktops.

Ben non c'étaient pas des destop, mais des écritures d'api, un peu comme gnustep quoi.
Après que ça puisse devenir un desktop, je ne le nie pas...
Enfin bon, de toutes façon, ils ne sont pas allés très loin.

Ah et comme l'a montré un dev noyau, si les desktops ne passer pas leur temps à stat'er plusieurs fois les même fichier et ne chargeait pas la totalité des polices au démarrage, ça irait un peu plus vite :D

Tout dépend de la logique interne au disque. Si elle décide de cacher tout ce qu'il y a autour de la dernière lecture, ça peut effectivement aider.

>il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.
Ce n'est pas le bon calcul, celui-ci se base sur le débit en séquentiel, alors qu'il faut le faire plutôt sur le temps d'accès. Quand est-ce que le débit pur d'un disque est utile? Quand tu fais une lecture d'un gros fichier, pas quand tu lis des fichiers de config.

Dans le cas de KDE, même si les fichiers sont physiquement proches, il ne va pas les lire à la suite les uns des autres. Lles autres tâches vont ajouter leurs propres accès à la file des opérations disques (réessaie le lancemen de kde, cette fois après avoir lancé une copie-pas deplacement, hein, copie- d'un fichier d'un Go entre deux emplacements sur un même disque dur). Peut ere même qu'elle en profitera pour écraser le cache disque par la même occasion...

La moitié? Pas plutôt entre 2/3 et 4/5?

Au contraire de l'analyse effectuée ici, je ne pense pas que celle du dev kde soit très pertinente. Pourquoi?
il compare le démarrage de kde depuis le disque au démarrage de kde depuis le cache!
Il a juste découvert que quand des données étaient en cache, on y accédait plus vite. C'est tout.

Après c'est vrai que c'est dû au seeks, mais aucun rapport avec la fragmentation puisque précisément, comme *il* l'explique, ce sont des seeks entre fichiers, pas entre fragments du même fichier.

Et le fait de positionner les fichiers lu l'un après l'autre pour accélérer la chose ne fonctionne que si le noyau gère ça (réordonnancement des opérations par le hardware plus souvent que par le noyau, parce qu'il se connait mieux que le noyau), et c'est encore en developpement.

Le truc en plus de la cddl c'est *précisément* l'incompatibilité avec la gpl. Il y a même une vidéo ou un des mecs de sun l'explique clairement (d'ailleurs, on ne les a plus jamais pris après qu'elle se soit répandue).

Non la license est valide, mais cette clause n'existe pas tout simplement. Tu peux donc prendre le texte, supprimer cette part, et la relire pour éviter tout parasitage...

Il est sûrement fourni un binaire linux/x86, pas un linux tout court. Il faut donc en écrire un pour qu'il puisse tourner sur les... mips/hitachi/arm/m68k.

Non de toute façons, il suffit de ne pas regarder du tout le code fourni, mais soit de le faire lire par quelqu'un d'autre pour trouver le format, soit de trouver le format quelque part.
L'algo en lui même n'est ni brevetable, ni soumis au copyright.

À côté de ça, ils ont tout fait pour bien expliquer de quoi il s'agit : non seulement ils disent que c'est une snapshot, mais je trouve quand même que le nom de code est... parlant quand même.
Si après ça il y en a qui trouvent intelligent d'installer un truc qui s'appelle krash sans être sûrs d'eux...

T'inquiète, la référence à la légalité était, je pense, une blague qui a fait un flop (cf. brevet de MS sur la vfat)

>ca demande un espace disque disponible equivalent a la partition que tu veux defragmenter
Non, plutôt au contenu, si ta partition n'est qu'à 10% pleine, tu n'a pas besoin de tant d'espace : )
Par contre, c'est vrai qu'à 10%, tu n'a probablement que très peu de fragmentation (à moins que la fat32 soit plus pourrie que je le pense).

Le tar -c{x,j}f ne nous sauvera pas ici parce que le fichier tar est créé puis compressé (ça demande donc encore plus d'espace que le tar-rage simple). Peut êter avec un |

tar -cvf - /path/to/disk |gzip -c >/endroit/avec/assez/d_espace

Bien sûr tout dépend du type de fichiers concerné, ça ne fera pas vraiment de différence sur des mp3/videos par exemple.

Par contre, juste une réflexion : quel est l'usage du disque externe. Je parle au niveau transfert : beacoup de petits fichiers, de gros fichiers peu souvent? Es-tu certain de la nécessité de défragmenter?
Autre point : est-ce un disque usb? Dans ce cas (même usb2), il est peu probable que la défragmentation change beacoup de choses pour la vitesse de transfert ou même les latences.

Enfin je suis curieux du comportement du pilote vfat. Est-ce qu'il reprend le comportement de windows à l'écriture ou est-ce qu'il essaie de faire un peu mieux (ou est-ce carrément une limitation de la façon dont les données sont disposées sur le disque, qui rendrait la fat impossible à améliorer?)

>(après je sais on peux faker son adresse mac)
un simple ifconfig sous linux (j'imagine que ça doit être a peine plus dur sous windows)

Le problème par contre c'est que même pour l'adresse "hard" de la carte, il se trouve que l'unicité n'est pas garantie. Il existe des périphériques qui ont, à la sortie d'usine, la mêùe adresse mac...

Cela dit, sur le principe, j'ai irne contre l'esprit d'ouverture.

Personnellement, je ne dépenserais pas les quelques centaines d'euros nécessaires rien que pour avoir le plaisir de les mettre face au problème... (il faut qu'un utilisateur demande communication des sources pour qu'ils soient dans l'illégalité).

Est-ce qu'il y a des pilots binaires pas libres ou est-ce que tout est libre la dedans?

alors là l'utilisateur moyen, il se dira "zut l'écran il est pété, ça fait *** vu le prix qu'il a couté". Et hop l'écran à la poubelle!

Et donc la famille doit *se* défendre ou *le* défendre? Je ne m'y connais pas beacoup en droit c'est pour ça peut être que la question a l'air naïve... mais comment fonctionne un procès quand l'accusé n'est pas... l'accusé?

Oui Geforce 2. Cela dit, les suivantes devaient ressembler pas mal quand même parec que ce mec là a réussit à en tirer un pilote 3d accéléré pour des Geforce 4 pour haiku :
http://web.inter.nl.net/users/be-hold/BeOS/NVdriver/index.ht(...)

Il n'en est donc que meilleur encore que je pensais ; )

> Pour ceux que cela intéresse, cherchez le thread nommé "cdrtools" sur les trois derniers mois des
> archives de la liste de diffusion debian-devel).

Ne faites surtout pas ça, ce thread est illisible, un post sur deux est de Joerg Schilling (orth.?)
Quoiqu'il advienne, quand ce type intervient, je ne suis jamais capable de lire plus de 5 posts d'affilée.

Il pouvait tout bêtement obtenir des droits de commit sur le premier projet. À mon avis, personne ne l'aurait embêté, et il se peut même qu'il aurait fini par être le responsable. Alors que là, il risque carrément de dégouter le mainteneur, qui ne contribuera peut être plus du tout, alors que même avec peu d'activité, il aurait pu bénéficier de son expérience et du travail qui se trouve probablement sur une branche privée sur un ordi perso.

Au lieu de quoi il prétend que le projet est mort depuis 2 ans (dernier commit il y a 6 mois, ok c'est pas brillant mais c'est pas pareil que 2 ans), ne regarde pas la ML (sinon, il connaitrait peut être le nom du responsable...)