CoinKoin a écrit 698 commentaires

Très bonne comparaison. Une seule différence : les deux serveurs X tournent sur la même machine, il vaudrait donc mieux penser à deux serveurs sshd situés sur la même machine.

Et, ce qui est intéressant, c'est qu'on se rend compte que, dans ce cas, ce n'est pas impossible, s'il existe un protocole de transfert de connexion entre les deux serveurs sshd (je précise qu'à ma connaissance, ça n'existe pas).

De même, à mon avis, ton idée est techniquement réalisable, à condition de modifier X.org en conséquence. A proposer dans une whishlist de l'équipe de X.org, ça m'a l'air intéressant.

En revanche, à l'heure actuelle, non, désolé, je ne crois pas que ce soit faisable.

sauf que si on resonne comme ca, la glibc devrait etre en GPL et non LGPL car la GPL du noyau est contaminante !

Inutile de raisonner si bruyamment ;-) , de toutes façons, rien n'interdit de rajouter des droits à la GPL, y compris celui de s'y lier sans passer sous GPL, et c'est ce qui a été fait pour passer tous les appels-systèmes du noyau sous LGPL.

Et les appels-systèmes du noyau Linux sont eux aussi sous LGPL.

De plus, cette obligation de passer le logiciel sous GPL n'existe que s'il y a intégration entre ton programme et celui sous GPL... Les shells, par exemple, utilisent bien des programmes GPL (à chaque fois que leur utilisateur tape une commande correspondant à un programme GPL), mais ça ne les fait pas passer sous GPL pour autant.

Plus généralement, si ton programme utilise un programme GPL, mais uniquement par l'intermédiaire d'un fork()+execve() (ou d'un simple execve()), il n'est pas tenu de passer sous GPL : il n'y a pas intégration.

Je ne pense pas. Microsoft s'est rendu compte que son image était mauvaise, et une affaire de ce genre les gênerait évidemment beaucoup. Je pense que, s'ils pouvaient trouver un arrangement à l'amiable, ils le préféreraient nettement au procès.

Cela dit, j'ajoute qu'à mon avis, l'hypothèse de départ m'a l'air plus qu'improbable, Microsoft me donnant ces derniers temps plutôt l'impression d'avoir trop de codeurs que pas assez.

-Un barbu, c'est un barbu; deux barbus, c'est des barbouzes!

Lino Ventura, dans "Les barbouzes" .

Ha, l'en-tête (=header), c'est plutôt pour patcher les sources que le noyau, ça, non?

Bah, essaie les deux solutions, tu verras bien ce qui passera... Dis-lui d'abord de regarder dans /boot, si ça ne lui plaît pas, là, il faut que tu télécharges les sources et tout le fouillis, comme l'a expliqué fatnerf.

un sourire niait quand on annonce que firefox bouffe des parts de marché à IE

Le geek niait catégoriquement sa niaiserie. Nierk Nierk Niais-rk.

Mon idée est qu'il faut/vaudrait mieux que chacun aille à l'école pour y apprendre notre belle langue. Ce n'est quand même pas si difficile de se relire un peu et d'essayer de faire un effort pour sur les points pour lesquels au sujet desquels on sait qu'on a des difficultés.

Il a demandé l'emplacement du noyau, pas de ses sources. Je suppose donc que c'est pour appliquer un patch binaire au noyau, auquel cas, les sources sont inutiles.

smarquis, vérifie tes messages : est-ce qu'on te demande l'emplacement du noyau, ou de ses sources?

Dans /boot. Précisément le fichier pointé par le lien /boot/vmlinuz.

NOACPI NOAPIC apm=off

1) Oui, quasiment.
2) Google (en cherchant sur LinuxFr, il y a déjà eu des journaux à ce sujet).
3) Non, je ne crois pas.

Est-ce qu'il reste bien assez de place dans ton buffer?

Est-ce que ta pile est toujours correcte (pas de dépassement de pile), au bout du 17e paquet?

Si tu changes la taille des paquets, ou celle du buffer (si tu peux), est-ce que ça change quelque chose?

5000 inscriptions, dont 1500 venant d'un certain "google indexation bot". Il n'arrête pas de cliquer sur tous les liens qu'il rencontre, et il a l'air expert en plein de choses...

Hé oui, seulement 14,08%...

Links, lynx et le telnet en port 80 ont encore de beaux jours devant eux.

Ne pas formater la partition windows, et la remonter comme partition de swap.

Ça donne un arrière-goût de roulette russe à la manip... :-)

Essaie "init 6". D'accord, c'est lourd, mais ça marche parfois, avec les problèmes matériels...

Mandrake suppose que ton ordi est compatible i386 pour booter, ensuite, uname -m donne l'archi.

La désignation IA32, elle, regroupe les processeurs x86 32 bits (ce qui doit correspondre à vue de nez à {i386} - {x86/64} ).

Non, elle est équivalente aux processeurs x86 (ou i386, ça n'a plus d'importance maintenant): tous les processeurs x86_64 doivent fonctionner dans un mode de compatibilité.

Euh, ça, d'accord, les processeurs x86_64 doivent fonctionner dans un mode de compatibilité, mais faire rentrer les processeurs du 8086 au 80286 (qui sont des processeurs 16 bits) dans la catégorie IA32, ça me semble quand même abusif.

Heu, oui, d'accord, mais

1) il faut que les logiciels s'adaptent à ce montage (sinon, ils sont bogués), et je doute que tous continuent de fonctionner correctement, et

2) Linux, qui n'est jamais qu'un système de type UNIX, est conçu pour être multi-utilisateur... Imagine le serveur central d'une entreprise, sur lequel l'administrateur effectue cette manip'...

Modulo une petite modif', ça peut devenir bien plus drôle...

Pensez-vous :

[ ] que les sondés sur Linuxfr sont très intelligents
[ ] que les sondés sur Linuxfr sont moyens
[ ] que la qualité des sondés sur Linuxfr baisse
[ ] que les sondés sont de plus en plus débiles
[ ] que Pierre Tramo devrait être élu président

Donc pour en revenir a l'open source, si il faut dumper le kernel ou Alsa pour décoder 128Ko de ton fichier musical protéger, je pense que cela limitera déjà pas mal le nombre de pirate potentiel, apres il faut que d'un point de vue conception le systéme soit assez robuste pour qu'un script de 15 ligne ne puisse pas venir automatisé la tache.

Oui, mais si le logiciel est libre, il suffit d'aller voir le code source, de supprimer les appels aux fonctions gênantes (du genre :

{
drm_respecte=tester_drms();
- if (drm_respecte==1){
+ if(1){
faire_tâche();
}
else {
taper_sur_utilisateur();
}
return;
}

), et le tour est joué...

Le plus rigolo, c'est qu'aucune norme ne précise que procfs doit être monté sur /proc...

Formellement, rien n'interdit de monter les $HOMEs des utilisateurs dans /proc et procfs dans /home.

Maintenant, je doute que l'administrateur qui ose faire ça se fasse particulièrement apprécier de ses utilisateurs...

Précision :

x86 désigne tous les processeurs 8086 et compatibles.

i386 désigne tous les processeurs compatibles avec le processeur 80386, c'est un sous-ensemble du précédent.

i586 désigne tous les processeurs compatibles avec le 586 (pentium), c'est encore un sous-ensemble du précédent.

Et, si je me souviens bien, la classe i686 commence au Pentium III.

x86/64 désigne les processeurs x86 capables d'exécuter les instructions étendues sur 64 bits, comme l'AMD64 Opteron.

La désignation IA32, elle, regroupe les processeurs x86 32 bits (ce qui doit correspondre à vue de nez à {i386} - {x86/64} ).

Attention, pour finir, il y a un piège : IA64, elle, ne concerne pas les processeurs x86/64, mais les processeurs Itanium d'intel, non compatibles avec les précédents.

Ca permet de se demander comment on peut serieusement sortir un logiciel aussi moche, les toolbars bleu, quel revolution!

Ben quoi, c'est quand même plus esthétique que Pine, tu ne trouves pas?

Ah, bien sûr, si tu leur en demandes plus... Il faut patienter jusqu'à Longhorn :-D .