pasBill pasGates a écrit 16062 commentaires

Faire un programme sous root puis dire "Ooops, mon programme à besoin de root" est franchement marrant.

Non, c'est une realite que tu ne sembles pas concevoir.

- il ne faut pas écriture dans /etc => ça tombe bien, on ne peut pas
- il faut utiliser $DISPLAY => ça tombe bien, c'est obligatoire
- ne pas tripoter la base de registre => ça tombe bien, il n'y en a pas.

1) si t'es root, si tu peux
2) obligatoire ? Quelqu'un va m'arreter si j'utilises "0:0" au lieu de $DISPLAY ? Non, ca sera juste un bug empechant l'utilisation du soft correctement en env. multi-utilisateur
3) La base de registres tu peux la tripoter meme en multi-utilisateur, mais faut toucher uniquement la ou il faut, comme tout
4) Tu fais un soft qui cree un fichier temporaire, toujours le meme, dans /tmp, ben c'est super, sauf le jour ou 3 utilisateurs lancent le meme soft.
5) Ton soft utilise des IPC qu'il ne protege pas correctement(memoire partagee, message queue, semaphore,...), avec des noms se trouvant dans un repertoire public (genre /tmp ), hop 3 users lancent le meme soft, et bam, c'est un gros bordel.
etc...

Au-lieu de prendre du temps à me faire la morale, dit à quoi il faut faire attention pour rendre un programme (je ne parle pas de serveur) multi-utilisateur sous Unix.

La liste est plus haut, et j'ai certainement oublie des trucs

Trouves moi un "HOWTO multi-utilisateur".

Sa non-existence signifie que le probleme n'existe pas ?
J'ai pas vu de "how-to make your software bug free", ca veut dire que sous Linux tous les softs sont bug free ?

Des recommendations MS à une époque* il y en avait plein.
Aider les developpeurs a eviter de faire les conneries sus-mentionnees signifie qu'il y a un probleme dans l'OS ?

Je suis comme toi. Tu connais mal Linux et moi c'est Windows. Mais moi je le reconnais.

Je crois surtout que tu connais mal les 2 systemes.
La difference entre toi et moi c'est que moi j'ai ecrit et supporte depuis 5 ans un soft de taille et complexite non-negilgeable qui tourne sous Linux(ainsi que Solaris/BSD et autres) en plus de mon job chez MS, je connais les problemes qui peuvent survenir dans le developpement d'un soft, et je sais tres bien qu'ils sont identiques sous Linux et Windows.

Remarques, t'es le bienvenu pour me contredire et me lister clairement les differences techniques entre Linux et Windows rendant le dev de softs en env. multi-utilisateurs plus complique sous Windows.
C'est marrant, mais je sens que je vais jamais la voir cette liste.

C'est dingue, c'est a se demander si tu comprends ce que les gens ecrivent.

Il t'explique juste que sous Windows comme sous Unix, faire certaines choses empeche ton soft de tourner en utilisateur simple, d'etre utilise par plusieurs utilisateurs en meme temps, etc...

Pas besoin de faire expres, il suffit de ne pas connaitre le systeme suffisament, d'oublier certaines choses, etc... comme sur tout systeme.

Ca devrait etre possible en theorie en creant les desktops/winstations/... pour chaque utilisateur, l'API pour ca est dispo sur MSDN, mais ca revient a reinventer la roue et refaire ce que TS fait deja.

Et moi j'aimerais bien que tu m'expliques (c'est vraiment une question, hein) comment ne pas utiliser TSE ou Citrix (le coût des licenses de l'un et de l'autre etant trop chers[1]) pour avoir une dizaine d'utilisateurs (environs) faisant tourner chacun une appli (la même, a priori) sur un serveur Windows en même temps en déportant l'affichage sur le poste du client.


Ben tu peux pas, c'est comme si tu voulais avoir 10 sessions X distantes sous Unix sans utiliser X Windows.
TSE c'est la partie de l'OS qui fait ce que tu demandes, faut pas esperer avoir cette feature sans utiliser le composant de l'OS qui l'implemente.

NT4 TS, Win2000, Win2003 permettent d'avoir plusieurs utilisateurs a distance logges en meme temps via TS chacun avec leur session.

Sous Windows t'as pas le choix, tu ne peux exporter que la session courante (de toute façon il n'en existe pas d'autres) c'est donc bien une _limitation_ .

TSE n'est qu'une surcouche de surcouche de surcouche de surcouche de Msdos[2] qui permet de faire semblant d'avoir plusieurs sessions.

Moi je te propose d'aller te documenter sur Windows avant de dire des aneries grosses comme une maison.

qu'il s'extasie que sous Windows on peut mettre à jour ntfs ou le réseau car c'est un driver alors qu'avec Linux c'est possible depuis la version 2.0 (1995, époque de Win95)

Mais c'est super, tu continues a nous pondre des delires sur mes paroles.
J'ai dit que c'etait genial ? J'ai dit que Linux ne pouvait pas le faire ?

T'as fume quoi pour deblaterrer autant de conneries a la minute ?

C'est surtout toi qui devrait faire qqe recherches...

Allez je t'aide, dans le poste du dessus j'ai dit qu'on supportait ce soft qu'on a ecrit en 98 encore aujour'hui, tu crois qu'on fait ca sur un GameBoy en cross-compilation vers Linux ?

Il y a bien evidemment des trucs pour lesquels il faut modifier le noyau, aucun noyau n'est parfait et supporte tout des la 1ere version, cependant meme ce changement ne requiert aucune modif/recompile des drivers(a condition qu'ils ne fasses pas de cochonerries non documentees auquel cas il faut les corriger).

1) J'ai encore 2 Linux chez moi, un 2.2 et un 2.4

2) Mon commentaire parlait des entrailles du kernel, que je n'ai pas fouille depuis les pre-2.4, il parle pas du systeme entier. Si tu veux on peut faire un sondage du nombre de gens qui connaissent les structures interne du kernel ici, tu verras t'auras probablement pas besoin de plus d'une main ou deux.

Mais comme toujours, faut trouver une variation de mes commentaires qui satisfasse tes idees.

J'ai Linux chez moi depuis 1995 sans interruption, dont 2 ans uniquement sur Linux aux environs de 1997-1999, j'ai aussi developpe un soft qui fait pas loin de 100'000 lignes de C++ portable(multithread/reseau/filesystem) pour Linux/Solaris/NT/Irix/BSD(on supporte plus Irix) avec un pote en 1998 qu'on supporte encore aujourd'hui. Oui t'as devine, il est pas GPL ce soft.

Bref, Linux j'ai pas attendu les belles GUI et la mode pour m'y mettre, ni d'etre chez MS pour m'y interesser.

On s'en fout de la détection des stack overflow de Windows 2000 ...

Faut croire que non vu que nicO a repris cet exemple precis.

Dans une news sur Linux, on comprend tous, forcement: « contrairement à Linux » même si tu le dit pas.

Si vous etes des paranos voyant des attaques contre Linux partout c'est franchement pas mon probleme, allez vous faire soigner, me demandez pas de me taire.

Et ensuite tu profite que quelqu'un s'énerve, pour mettre en avant un détail technique ou Windows serait supérieur à Linux.

Mais il faut arreter le delire mon cher, j'ai pas compare a un seul moment Linux dans cette histoire, je n'ai fait qu'expliquer a 007 que non, Windows ne fonctionnait pas comme il pensait.

Mais on s'en fout. On es un peu con, car on préfère Linux malgré qu'il soit beaucoup moins bien que Windows. Des tas de très grosse boite font aussi la même erreur, je comprend que ça te fasse râler. Et puis on a une sale manie aussi, on aime bien avoir quelque chose d'un peu plus consistent que du blabla comme preuve: Les sources.

Qu'est ce que tu veux que ca me fasse ? Tu m'as deja vu demander a qq'un de rester sous Windows plutot que passer a Linux ? Non, c'est encore ton imagination qui te fait croire que j'ai un probleme avec ca.

Et bien j'aurais été très content de pouvoir recompiler le noyau ou le pilote pour les faire fonctionner. Mais avec du logiciel propriétaire ça n'est pas possible.

Ben essaye de prendre un driver pour MacOS 9 et le recompiler sous Linux, tu verras c'est pas facile. Pourtant c'est ce que tu demandes ici, des drivers qui marchent pour 2 OS completement differents.

T'as certainement fait qqe chose de completement faux dans tes manips mon cher

1) La stack IP est presente par defaut, pas besoin de l'installer
2) Il n'y a pas besoin de rebooter pour changer d'addresse IP

Je vais pas tout te filer sur un plateau d'argent non plus. Tu reflechis et cherches 30s et tu trouveras. Si ca t'interesse vraiment tu trouveras tres tres facilement, sinon ben ca vaut pas la peine que j'aille prendre tous ces liens pour toi.

Lui si il m'a compris, il a bien compris que je parlais de la stabilite de l'API Windows, et *lui* a ajoute que sous Linux ce n'etait pas forcement aussi stable, ce avec quoi je suis d'accord, mais je ne l'ai dit nulle part, c'est toi qui pour je ne sais quelle raison t'entete a mettre des mots dans la bouche. Je n'ai fait que dire "Non, sous Windows il n'y a pas besoin de le faire" en reponse a tes posts, j'ai jamais dit "Sous Linux il faut le faire"

Tu prends Windows 2000, il n'a rien pour detecter les stack overflows.

Tu installes VS.NET 2003, tu compiles ton soft avec le flag /GS, et oh miracle, ton soft aura le code pour detecter un stack overflow.

Le kernel n'a rien a voir avec la detection d'un stack overflow, pourtant tu n'as pas modifie un seul byte du kernel.

Tu peux avoir 2 drivers compiles pour ca, et le kernel ainsi que tous les autres drivers qui ne le font pas, c'est totalement independant du systeme, ca ne depend que du code genere par le compilateur pour le binaire.

Encore une preuve que le FUD de pb pg marche super bien.
Vous comparer ce qui n'est pas comparable.

Quel FUD ? J'ai dit que c'etait different sous Linux ?

T'en as pas marre d'inventer des conneries ?

Mais comment je fais ?
- JE N'AI PAS LES SOURCES
- TOUT EST PROPRIO SOUS WINDOWS
- PERSONNE À PART MS PEUT PATCHER WINDOWS

Ben tu vois c'est pas si dur, tu viens de reconnaitre qu'il n'est pas necessaire de recompiler ce noyau pour que tes drivers fonctionnent vu que c'est pas possible et que ca marche quand meme

Pour Linux tu transformes un "on peut compiler Linux ..." en un "Il faut compiler Linux..."

Montres moi ou j'ai dit ca

Sinon, tu joues le jeu et tu me donnes un acces CVS ou Source Safe ou je_sais_pas_quoi avec les sources de windows.
Idéalement il faut aussi les log comme ça on verrait des trucs :
- fix for driver bidule
- add support for firewire
- etc

Inutile, t'as qu'a regarder le contenu des patchs qu'on sort, tu verras que les fichiers pour ATM, TCP/IP, etc... ne sont jamais presents en meme temps que les fichiers du kernel.
Bref, il n'y a aucune dependance de ces drivers vis a vis de la version du kernel

Tu dis que le noyau n'a jamais besoin de patch ou d'être compilé, alors démontre le.
Trouves une pages sur www.microsoft.com qui indique les fichiers mise à jours, dis quel est le fichier lié au noyau et on regarde l'historique du noyau.

Tu delires, j'ai pas dit qu'il n'avait jamais besoin d'etre patche, il est evident que pour corriger des bugs dans le kernel il faut le recompiler.

Tu dis qu'il est inutile de patcher/compiler le noyau pour un driver. OK, donc n'importe quelle driver soit marcher sur toute les versions de Windows.

Non, un driver qui depend de features presentes uniquement dans XP ne va evidemment pas marcher sur Win2000.
Si tu prenais la peine de t'informer avant de raconter n'importe quoi, tu irais lire le DDK de Windows et tu verrais que les drivers utilisent un API tres clairement defini et fige. Tant que ces drivers ne font pas de cochonneries(= trucs non documentes), ils continueront a tourner quel que soit le kernel. Evidemment si ils touchent a des trucs non-documentes et qu'on change ca, ils vont claquer.

Trouve moi un truc ou une doc qui montre que tous les drivers marchent pour toutes les versions de Windows.

Tous c'est impossible car certains font des trucs non documentes et donc vont casser.

La preuve est tres simple : tu regardes les patchs, et tu remarqueras que les fichiers du kernel ne viennent avec _aucun_ driver. Bref, il n'y a aucune dependance binaire entre le kernel et les drivers vu que tu peux installer ces patchs du kernel et tes drivers continueront a tourner. De meme pour les drivers, tu peux les installer sur Win2000/SP2/3/4 , et les drivers ne sont jamais livres avec un kernel, ils viennent tous seuls.

T'es dans un boîte proprio, c'est à toi de faire la démontration. Ou alors tu me donnes accès au CVS de Windows.

Elle est faite, la reponse est dans le contenu de nos patchs.

Je m'énerve sur le FUD de pb pg qui avance des choses fausses :
- intérêt de patch ou recompiler le noyau windows
- avec linux il faut recompiler le noyau pour installer un driver
- pas de compatibilité binaire car c'est un OS libre
- Les dev Linux sont pas cool avec les utilisateurs de pwc qu'ils laissent tomber.
- etc...


1) Tu m'as toujours pas montre un seul driver qui demandait de patcher le noyau Windows, pourtant j'ai fait des demandes repetees
2) J'ai jamais dit ca
3) Jamais dit ca non plus
4) J'ai critique l'auteur de pwc ? Non, pourtant c'est un dev Linux. Mais bien sur, des que j'emets une critique et que le mot Linux est a moins de 100m, tu prends ca pour une critique de l'ensemble Linux

Bref, tu t'enfonces encore plus.

Pour bien te montrer que j'en est rien à foutre que Windows soit mieux ici ou là, les "ntfs.sys", "ipv6 install", le changement à chaud de driver, de pile tcp/ip etc, me laisse totalement indifférent

Bien sur ca te laisse totalement indifferent, c'est pour ca que tu nous a pondu une liste de 10 trucs differents(et tu t'es ramasse sur chacun d'eux) soi-disant demandant une recompilation du noyau, t'avais surement rien d'autre a faire a ce moment la et tu t'es dit que ca serait drole de faire une liste fantaisiste.

mais ça m'amuse de faire croire à PB PG qu'il m'impression.

T'as pas idee a quel point c'est important pour moi d'impressionner qq'un qui est borne, grossier et qui ne sait pas de quoi il parle.

Tu devrais te recycler dans la speologie, t'as des qualites indeniables pour ce qui est de t'enfoncer.

C'est marrant, t'as pris Win95 et 98 comme exemples, t'as oublie que Win2k/XP existaient (et faut il le rappeler la lignee NT c'est un _OS different_ de Win9x, tout comme Linux et Solaris sont differents) ?

Avec Win2K/XP, les questions 1 & 2 repondent NON

Arretes de t'enfoncer, ca en devient est risible.

Si tu passes en 64 bits d'adressage memoire, t'ajoute ipv6, nouvelle gestion de la vm, utilisation des instructions K7 avec SSE2 au-lieu de i386, ajout de SeWindows (l'équivalent d'SeLinux), activation des informations de debug, controle de débordement de la stack, NTFS V10 qui support le zerocopy depuis le réseau via l'appel système sendfile(), etc...

Tu continues a t'enfoncer.

Tu veux ajouter IPv6, effectivement tu ne changes pas le noyau, IPv6 c'est un driver(tcpip6.sys), tout comme IPv4 l'est. Tu vas sur XP, tu tapes dans une ligne de commande : ipv6 install, la stack IPv6 est installee, pas besoin de reboot.
Je vais meme t'apprendre un truc magique, tu peux enlever la stack IPv4 en tapant : net stop tcpip dans une ligne de commande(a condition qu'aucun driver n'ait de handle sur le driver bien entendu), pas besoin de recompilation, pas besoin de reboot non plus.

Tu veux updater NTFS, effectivement tu ne touches pas au noyau, NTFS c'est un driver, il s'appelle ntfs.sys d'ailleurs.

Les 64bits, c'est un passage de plateforme, rien a voir.

K7 ou SSE2 je vois pas le rapport, si t'updates le noyau pour les supporter, t'as pas besoin de toucher les drivers. Si tu veux que ton driver en tire partie, pas besoin de toucher le noyau, juste le driver

Activation des infos de debug non plus, il y a tout un systeme de tracing, et si tu veux plus, il y a la version debug du noyau dispo dans ce qu'on appelle la version "checked" de Windows.

Controle des debordements de la stack non plus, si tu les veux dans le driver, faut evidemment recompiler le driver, pas le noyau

etc...

Le jour ou tu comprendras que rebooter != changer le noyau et que driver != noyau, t'auras fait un grand pas dans ta comprehension de l'informatique

Tu ferais mieux de t'arreter maintenant, t'as eu l'air assez idiot deja.

Quand sur un site dédié à Linux tu réponds à un posts qui parle de Linux ( http://linuxfr.org/comments/464879,1.html(...(...)) ) dans une news sur Linux,
si tu ne veux pas aborder Linux, pitié mon ami dit le !

Je te cites, du post que tu as linke :
NB, le 2) n'est pas possible avec un OS proprio. Alors arrêtons de considérer Linux comme intégriste alors qu'il est beaucoup plus "coolant" que tous les OS proprios et ce pour 0 ¤.

Non seulement tu ne sais pas lire ce que j'ecris, mais en plus t'es meme pas capable de relire ce que tu as ecris ?

Faut retourner a la maternelle mon cher, il y a du travail en perspective.

Pour certains drivers aussi.

Comment ose-tu dire ça sérieusement ?

Ben c'est tres simple, j'utilises Windows et j'ai des yeux et un cerveau

Dans quel cas, je doit rebooter ?
=> lorsque je change de noyau
Pourquoi changer de noyau
=> car il a changé !
Comment a-t-il changé
=> avec un patch !

Je vais t'apprendre un truc gigantesque : Quand tu ajoutes le support ATM a Windows, tu ne changes pas le noyau, tu charges un driver, un fichier separe, comme un module sous Linux.
Si tu veux modifier ATM, tu ne modifies pas le noyau, tu modifies le driver. Il n'y a _pas besoin_ de toucher au noyau

Par exemple, Windows n'a pas ATM et tu ajoutes un driver qui uilise ATM.
=> faut patch/recompiler

Non c'est faux, tu charges le driver ATM, tu ne touches pas au noyau.

Drivers pour gros disque dure. Quand il a fallu dépasser l'énorme valeur 8 Go pour Windows :-)
=> Nouveau noyau

Non, nouveau driver IDE

Non, tu es d'une mauvaise fois infini.

Je dirais plutot que c'est toi qui est un ane qui ne comprend rien a Windows et ne sait pas du tout comment il fonctionne.

Reviens quand Windows ne demandera pas de rebooter lorsque t'installes un drivers, change de couleur de fond d'écran, etc...

C'est bon je suis de retour.

T'es franchement pathetique, rien de ce que tu ne dis ne tient debout.

Et ? Ou m'as tu vu dire le contraire ?

Je parles de devoir recompiler le noyau, il n'y a jamais besoin de recompiler le noyau pour faite tourner un driver.