pasBill pasGates a écrit 16195 commentaires

Ben demande à un développeur de faire une appli pour Unix et lui disant bien que c'est pour une système avec un seul utilisateur. Tu vas voir, l'applis sera multi-utilisateur compliant. Marrant ça.

Ah ben oui tiens, vu qu'on la lui demande pour un systeme mono-utilisateur, il va utiliser les IPC pour les communications inter-process, il va utiliser un nom de fichier fixe et il va pas mettre de permissions dessus vu que c'est mono-utilisateur, oh le joli trou de securite(ou crash/DoS, c'est au choix) !!!!

Developpeur Unix depuis 7 ans t'as dit, c'est bien ca ?

C'est l'OS qui est multi-utilisateur et pas un programme !

Alors un programme qui utilise un nom fixe pour son fichier d'IPC(plutot qu'un nom d'user) afin d'avoir toutes les instances du process pour cet utilisateur communiquant entre elles tu l'appelles comment ?

Parce que si seul l'OS est sense s'en occuper, ce que je decris la devrait marcher(plusieurs utilisateurs lancent le soft et ca marche), hors non, ca ne marche pas, sauf si le _programme_ tient compte du fait que plusieurs utilisateurs peuvent lancer le soft en meme temps.

Il n'y a pas d'appli mono-utilisateur sous Unix (sauf serveur, et encore...).

Si, toutes celles ecrivant dans des fichiers fixes dans des repertoires accessibles a tous.

Sous Linux tant que personne se loggue, c'est mono-utilisateur et parfaitement multi-tache.

Faux, meme sans que personne se logge plusieurs utilisateurs ont des softs tournant sur un Linux, typiquement Apache qui tourne en nobody et d'autres process en root, meme chose pour les autres daemons.

Ben comme tout probleme informatique, une fois qu'on t'a explique comment ca marche(comment un float est stocke dans ce cas ci), tu trouves ca hyper logique, alors que pendant les 2-3 jours precedents tu t'es tire les cheveux en te demandant si les extra-terrestres jouaient avec ta machine.

C'est ca le cote marrant de l'informatique, expliquer a tes collegues sur quelle connerie triviale tu as perdu 2 jours :+)

Ben tu as fait une petite liste, et cette liste montre bien que oui, les applications doivent faire leur part du boulot pour etre utilisables en multi-utilisateur, on ne peut pas ecrire n'importe quoi et etre sur que ca va tourner en environnement multi-utilisateur(ce qui serait une preuve que l'OS rend le multi-utilisateur 100% transparent aux applications). C'est exactement ce que je voulais montrer.

Donc s'il y a des problèmes avec le multi-utilisateur c'est la faute aux développeurs d'applis, si les virus prolifèrent c'est de la faute aux utilisateurs, etc...

Si il y a un bug dans une applications, c'est la faute au developpeur de l'appli.
Si l'utilisateur lance un soft qui formatte son disque, c'est sa faute, l'OS va pas interdire a un utilisateur de lancer un soft et il n'a aucun moyen de savoir a l'avance ce que ce soft va faire, il n'y a aucune difference entre un executable OpenOffice et un soft qui fait rm -rf / au niveau de l'OS, Linux/Windows/Solaris/AIX/... meme chose.


De tel propos sur un site Windows me laissent totalement indifférent. À la limite, ça me fait rire. Mais ici ... (et ce n'est pas le première fois) : http://linuxfr.org/2004/09/01/17138.html(...(...))

Je sens que je me repete mais.... apprends a lire.

Si l'OS est multi-utilisateur, c'est à l'OS d'être multi-utilisateur et pas à l'applis (c'est tellement con à dire...).

Ben montres nous un exemple d'OS "de masse"(c'est a dire pas un truc de recherche utilise par 3 personnes dans le monde) qui encapsule cela completement(= impossible a l'appli de faire une connerie empechant l'utilisation en multi-user), je sens que je vais attendre longtemps...

Va prendre dir, cd, notepad, etc... sous Windows meme chose.

Maintenant va prendre des applis comme OpenOffice, KDE, ... sous Linux et tu vas te rendre compte que non, c'est pas 100% transparent pour les applications.

coco, t'es gentil mais je développe sous Unix depuis 7 ans.

Ben vu ta methode pour creer des fichiers temporaires, il y a pas de quoi etre fier. Tu parlais de gens incompetents car ils utilisent 0:0 au lieu de $DISPLAY, je consideres pas ca plus complique pourtant.

Oui, transposer pour Windows c'est :
- "si ça sucks, gueuler après les utilisateurs".

Tu continues a sortir tes conneries sur Windows ,et tu n'as toujours pas donner _un seul_ exemple ou Linux et Windows sont differents.

http://www.redhat.com/archives/linux-security/1998-March/msg00002.h(...))
Chercher tmp-file :
http://www.redhat.com/archives/linux-security/1998-March/thread.htm(...))

Maintenant j'en suis convaincu, tu ne sais pas lire le francais.
Ca a quel rapport avec le probleme dont on parle a part que ca parle de fichiers temporaires ?

Je sais, et c'est effrayant.
Tout le monde pense Windows.
Le style Unix qui a largement fait ces preuves est mort.

Je crois surtout que tu ne sais vraiment pas de quoi tu parles, mais ca devient une habitude.

Il y a TSE dans XP, et si tu t'es deja connecte a distance sur un XP tu l'as utilise, mais il est limite a 1 connexion.

Sans déconner ? T'as autre chose comme remarque pertinante ?
Tu bosses sûrement sous root.
Tu testes tes développements sous root.
J'ai une distribution pour toi => Lindows.

Pourquoi le développeur va fixer DISPLAY ? STP, réponds à cette question.
Quel développeur ici, fixe DISPLAY ? Et pourquoi ?


Mais c'est super ce que tu nous racontes.
Donc les developpeurs sous Linux ne font jamais de conneries ? Vous avez de la chance sur ce systeme, a se demander pourquoi il y a tant de correctifs.
Le developpeur il le fera parce qu'il ne maitrise pas ce cote la du dev Unix ou fait une connerie par distraction, comme tout bug. Je sais pas si t'es au courant, mais les gens ne mettent pas des bugs dans leurs softs volontairement, ils le font par ignorance, distraction ou autre.

C'est un _vrai_ problème et j'ai déjà vu des recherches pour corriger ça. Mais rien de concret actuellement

Des recherches ? Recherches pour quoi ? La solution est hyper-simple et connue pourtant, tout comme pour DISPLAY & root. Simplement tu consideres toi que DISPLAY/root c'est evident et pas ce probleme, alors que pour d'autres c'est l'inverse, et pour d'autres encore tous ces problemes sont compliques.

Ben là tu es dans le cas d'un serveur, d'un partage de resource etc...

Il y en a plein et ca n'a rien a avoir avec un serveur, tu peux utiliser les IPC pour transferer des donnees entre plusieurs processus sur la machine(c'est d'ailleurs leur boulot principal), et ces processus ne sont pas forcement des trucs genre Apache ou sendmail, ca peut etre une appli desktop.

Et tu trouves normale de développer sous root ?
Et tu fais des prog avec $DISPLAY codé en dure dedans uniquement pour saboter un programme qui sinon serait naturellement multi-utilisateur ?
etc...
Sans déconner ?

C'est a se demander si tu sais lire le francais.
Je ne fais que donner des exemples de problemes possibles et s'etant deja produits, et ta logique extra-terrestre comprend que je suis ces pratiques, va donc comprendre...

Comme tu le sais que je ne connais pas les dernières versions de Windows, et donc tu va m'envoyer bouller.

Ben a toi de voir

Mais tu vas affirmer ici que Win 9x ou Win Nt a un modèle multi-utilisateur égale à Unix.

Fais-le, j'aurais aucune difficulter pour te contredire.

Mais ca on s'en fout, on parle de systemes d'aujourd'hui, pas de systemes datant de 10 ans.

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 ?