e serais surpris d'apprendre que la starac'/ozone ("nomanomanéï")/et autres tfuneries ne figure pas en tete des échanges de musique en france..
C'est parcque tu télécharge que tu apprécies... c'est un des avantages du p2p, tu dl les nouveautés (c'est pour ça qu'elle sont au tête des échanges), et hop tu écoutes : 2 solutions : A réécouter ou à jeter. Tu sais surement où va finir ce qui est en tête des dl ;-)
Et du même coup du te dis : "ouf, j'ai bien fait de ne pas acheter ce truc"
Pour iRate, j'ai testé pendant 1 semaine. Ben franchement, sauf si t'aime l'electro/techno voilà quoi...
Je vois que dans les messages on a un les derniers "fils" qui s'affichent, avec le nombre de réponse, c'est pratique ça ! Mais faudrait là encore faire ressortir les nouveauté depuis le dernier passage sur cette page... c'est peut être plus facile à cet endroit que sur l'ensemble du site ? Sinon amuse toi bien pour cette nouvelle année universitaire :-) (on se croisera peut-être sur le campus tiens d'ailleur ;-))
Le p2p est sans doute un des principaux responsable, mais moi je dis que c'est très bien ! Le p2p a permis au gens de se rendre compte qu'une partie de l'industrie musicale est inutile : le support physique. Le p2p a permis aux gens de prendre conscience du prix trop élevé des CD Audio par rapport à ce que celà coûte réellement. Le p2p a fait naître un esprit contestataire, en cherchant à se justifier, les utilisateurs du p2p réfléchissent et commencent à sortir la tête du sable : ils en ont marre d'être pris pour des cons et des vaches à lait à qui on lessive le cerveau devant la starac'.
De l'autre côté, les artistes contestent également le système actuel, trouvant les contrats de plus en plus complexes et de plus en plus injuste, ils ont plus l'impression d'être des employé d'une multinationale qui se réserve tous les droits sur leurs créations plutôt que d'être des artistes qui signent un contrat de distribution de leurs contenus.
Il y a évidemment d'autres facteurs que le p2p qui justifie la baisse des ventes des CD, mais le p2p est la principale cible des industrie car elle est le moyen de former et de concrétiser des idées qui naissent dans l'esprit de nombreux consommateurs.
Ah oui j'oubliai, n'oublies pas de faire une présentation de WineX avec Word et un jeu qui tourne, ça va les impressionner et surtout les rassurer... Apparement y'a pleins de journalistes qui étaient au salon Mac pour voir tourner le nouveau VirtualPC donc bon... (d'ailleur ils ont été déçu parcque apparement ça n'avancait pas vite)
Ben, organise une LinuxExpo où tu invites pleins de journalistes en leur offrant pleins de trucs, des boissons, du matos, et puis du fais des show impressionnants avec la transparence dans le dernier X.org, le tout sur écran géant avec son DolbyDigitalDTSdelamortquitue. Oublies pas le chéquiers pour les journalistes dont le magazine coûte moins de 3 euros.
Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Bref, tu finis par l'admettre, il faut souvent éduquer le développeur à certains concepts (multi-utilisateur) et pratiques ($HOME), même si là c'est rapide à détecter/apprendre.
Pour le reste et les prob de sécurité avec /tmp, t'as sûrement raison, t'es plus à même de savoir de quoi tu parles.
Je penses que pour le côté multi-utilisateur, on a fait le tour.
Allez je vais en rajouter une petite couche identique pour le multi-tâche (ton 2ème exemple dans le texte du journal) :
Si l'OS est multi-tache, c'est à l'OS d'être multi-tache
Je comprend où est le problème là encore. Ta phrase est stupide au possible, tu peux remplacer multi-tâche par n'importe quoi :
Si la voiture est rouge, c'est à la voiture d'être rouge. (Ah bah ça c'est sûr :) )
Ta phrase devrait plutôt être :
Si l'OS est multi-tâche, c'est qu'il fournit un mécanisme de multi-tâche. (celà ressemble plus à une définition)
Et là, à plus forte raison que pour le côté multi-utilisteur, si le développeur ne fait rien pour que son appli soit multi-tâche, elle ne le sera pas (sauf si les libs qu'il utilise le sont à son insu bien entendu, mais là encore on remet le problème en dessous). Ce sera une appli mono-tâche qui tournera là encore bien sur un multi-tâche. Là encore il peut être fortement intéressant de "sensibiliser" les développeur à la pratique du multi-tâche, surtout avec système multi-core qui apparaîssent. J'espère que tu es convaincu que il faut pousser le cul des développeurs pour qu'ils évitent de rester sur les acquis, et parcque l'OS ne peut pas tout faire, et que l'environnement/machine évolue.
Perso, je préfère que l'OS n'en fasse pas trop (pour moi l'OS c'est le kernel, et son rôle est principalement de gérer les processus et de faire une première couche d'abstraction avec le matériel pour gérer les entrées/sorties), mais qu'il le fasse bien.
Bah, je me doute que fabriquer une machine à voter celà pollue beaucoup, mais une machine à voter c'est réutilisable, et relativement très sommaire à concevoir, pas besoin de millions de composants...
Qui peut prouver que la démonstration a bien été faite avec ce code source ?
L'avantage, c'est que avec cette méthode, le code est généré automatiquement...
que celui qui a fait la démonstration est honnête ?
Il suffit de lancer un des outils de la méthode B pour vérifier qu'une démonstration est correcte.
que le code compilé l'a été fait sans qu'il n'y ai de backdoor dans le compilateur lui même (cf l'histoire) ou dans les bibliothèques ?
A priori le programme est correct quand toutes les dépendances le sont, cad les bibliothèques aussi (d'ailleur bonjour le boulot, parcque du coup faut tout prouver, et y'a qu'un type de données pour commencer : les entiers :) )
qu'il n'y a pas de détournement électronique/mécanique dans la boite qui pourrait fausser le vote en faisant croire qu'on a appuyé un autre bouton ? qui peut prouver que la boite qu'on a devant nous n'a pas été modifiée depuis toutes ces preuves (pour peu qu'on puisse les obtenir) ?
Ben là... c'est plus du domaine de l'informatique mais du domaine de la sécurité...
Le seul gain d'une boite automatique c'est accélérer le dépouillement.
c'est faciliter les comptages, c'est rigolo, c'est respectueux de l'environnement (pas de milliers de bulletins/enveloppes à faire)
il n'en est pas de même avec le vote électronique où une telle preuve se rapproche plus de la démonstration mathématique.
Ralala, mon prof de fac de méthode B serait heureux de lire celà :) C'est marrant, avec la méthode B, on peut prouver qu'un programme est correct et conforme aux spécifications. Je suis sûr qu'il serait facile d'utiliser cette méthode pour une machine de vote, puisqu'ils ont bien réussi à le faire pour une ligne du meteor à Paris...
C'est pas des anomalies, c'est normal :) FT n'a pas conçu son rezo pour faire passer tout ça, du coup ta ligne est de plus ou moins bonne qualité, et Free n'y peut rien.
Effectivement, la redirection par variable a d'autres intérêt que le multi-utilisateur.
Quoiqu'il en soit, coder en dure un chemin n'est JAMAIS une bonne idée.
Tout à fait, mais là encore, faut éduquer le programmeur, parcque ce genre de pratique se rencontre souvent :-)
Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant et qui s'apercevait que ca marchait pas sur toutes les machines (quoique le /tmp en général on le retrouve... moi le premier y'a 4 ans :-p
Reste à connaître le montant de ces offres, parcque si c'est comme pour le 2048 voilà quoi... L'ART doit donner son avis à l'automne, donc pas d'offres commerciales d'ici là.
C'est le fait d'être obligé d'utiliser une variable et pas un path absolu qui fait que tu es obligé de considérer que c'est du multi-utilisateur. C'est d'ailleur pour celà que sous windows il y a une variable temp, comme ça tous les utilisateurs peuvent avoir un temp différent. Ca évite les conneries à la /tmp.
Pas besoin de faire des sudo ou rémarrer des serveurs X... fô se renseigner un peu...
Euh si je veux 2 sessions graphiques avec 2 bureaux différents, je fais comment ? Je lances pas 2 serveurs X ? En tout cas c'est bien caché...
Moi, je fais Applications->Outils système->Nouvelle connexion ou Applications->Outils système->Run as different user sous Gnome
Désolé j'ai pas celà sous mon Gnome (ca doit venir de fedora), mais dans tous les cas ce n'est vraiment pas pratique, il faut rajouter la ligne à exécuter à la main... Je ne suis même pas sûr que celà fasse parti de gnome, ce n'est pas plutôt le projet gdksu qui est à part ?
Des fois tu me fais halluciné tellement t'es bête. > Bah non, sous windows y'a pas C:\temp.
Mais si. C'est indiqué avec la variable TEMP je crois.
Sous windows c'est C:\windows\system\temp.
sans commentaire.
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.
putain mais t'es vraiment grave.
Là tu demande au développeur de ne pas tenir compte du fait qu'il n'y a pas plusieurs utilsateurs, donc l'application sera MONO-UTILISATEUR parcqu'elle ne s'occupe pas des problèmes liés au fait qu'il y en ai plusieurs.
Mais OUI, elle pourra sûrement tourner sur un OS multi-utilisateur.
Tu le dis toi même "multi-utilisateur compliant" c'est à dire compatible avec les OS multi-utilisateurs. C'est pas pour celà que l'appli sera capable de tenir compte du fait qu'il y a plusieurs utilisateurs.
C'est comme si tu fais un programme mono-thread, alors oui tu pourras dire qu'il est compatible avec les OS multi-thread (encore que) amis ce n'est pas pour celà qu'il sera multi-thread ! Il faut que le développeur utilise explicitement cette possibilité, pareil pour le côté multi-utilisateurs.
Et c'est ce qu'on demande aux développeurs, on leur demande d'ajouter un PLUS à leurs appli, de ne pas se contenter de faire en sorte qu'elle puisse être lancé plusieurs fois. Bref, tirer parti de l'avantage de pouvoir avoir plusieurs utilisateurs en même temps.
Bravo. Gnome est un programme.
Tu as quelle version du programme Gnome ?
T'es vraiment trop con. Voilà tu préfères que je parle de solution logicielle ? Ca va c'est assez vague pour que tu comprennes sans m'enmerder sur les termes que tout le monde comprend ?
* Win 95 est multi-tâches et pas multi-utilisateur.
Mais j'en ai rien à cirer de Win95 ! On parle d'Unix bordel !
C'est l'OS qui est multi-utilisateur et pas un programme !
Clap clap clap.
L'OS est multi-utilisateur si il tient compte du fait qu'il peut y avoir plusieurs utilisateurs.
Le programme est multi-utilisateur si il tient compte du fait qu'il peut y avoir plusieurs utilisateurs.
Je crois que tu as franchement du mal à comprendre qu'il ne suffit pas de se contenter du multi-utilisateur au niveau noyau. A tous les niveau il faut en tenir compte. Parfois celà ne change rien aux fonctionnalités, parfois celà apporte de nouveaux besoins, de nouvelles possibilités. Et c'est ce qu'on demande aux programmeurs :!!!!!!!: Tenir compte du fait qu'il peut y avoir plusieurs sessions graphiques en même temps sur une même machine !!!! (chose relativement nouvelle)
Tu mélanges tout.
Bon, heureusement que depuis 30 ans, Unix ne fait pas ce que tu dis.
heuresement que depuis 30 ans l'informatique a évolué et que tes idées sont dépassés depuis autant de temps.
Il n'y a pas d'appli mono-utilisateur sous Unix
quelques lignes plus haut tu dis que seul l'OS peut être multi-utilisateur et pas les programme, et là tu me dis qu'ils sont tous multi-utilisateur (car pas mono-utilisateur)
t'es vraiment un boulet.
On peut être multi-utilisateur et pas multi-threadé. Ça existe.
J'ai dit le contraire ? tu fabules.
On peut être multi-threadé et pas multi-utilisateur (win 95). etc.
J'ai dit le contraire ? tu fabules.
Met ca une bonne fois pour toute dans la tête :
une appli est mono-utilisateur lorsqu'elle ne tient pas compte du fait qu'il peut y en avoir plusieurs.
une appli ou un OS est multi-utilisateur quand elle en tient compte. Mais l'un n'empêche pas l'autre ! et tu peux très bien utilisé une appli multi-utilisateur sur un OS non conçu pour (l'appli va tout faire), ou l'inverse, une appli mono-utilisateur sur un OS multi-utilisateur, auquel cas l'appli n'en tirera pas parti (poutant elle le font quasiment toute en utilisant HOME), tu peux aussi faire tourner une appli multi-utilisateur sur un OS multi-utilisateur en utilisant un tout autre système ou en utilisant la couche inférieur qui propose des fonctionnalités multi-utilisateur.
Désolé si je me suis emporté, mais tu m'as énervé. Tu peux me moinsser si ça t'amuse.
Un OS multi-utilisateur a besoin d'applis faites spécifiquement pour le multi-utilisateur.
N'importe quoi, un OS n'a besoin de rien du tout pour fonctionner.
Si l'appli n'est pas fait pour le multi-utilisateur alors l'appli ne peut pas être utilisées par plusieurs personnes à la foi.
Euh, personne n'a dit celà... ce qu'on dit (qu'on se tue à te dire), c'est qu'il y a une différence entre pouvoir lancer plusieurs fois une application (que ce soit depuis un autre utilisateur ou non) et tenir compte du fait qu'il peut y avoir plusieurs utilisateurs pour proposer des infos et une ergonomie en conséquence à l'utilisateur (ça c'est une appli multi-utilisateur)
De même, avant de développer une applis, tu ne te dis pas :
- multi-utilisateur ou mono-utilisateur ?
Bah si justement !
Et c'est ce que devrait faire tout bon programmeur.
Dans 99 % les applis pour Unix sont développées sans penser à multi-utilisateur ou mono-utilisateur et qu'on utilise $HOME n'y change rien.
Et bah c'est justement pour celà qu'on tente d'éduquer les développeurs, parcqu'il y a de plus en plus d'application qui se contente de fonctionner parfaitement dans un espace multi-utilisateur mais sans tenir compte du fait qu'il peut y avoir plusieurs utilisateurs qui peuvent vouloir intéragir.
Et pour le $HOME ?
pourquoi c'est une variable ?
pourquoi c'est pas un chemin absolu ?
Oui les développeurs savent que c'est là qu'il faut mettre ses infos et pas ailleur, même si le programmeur est un abruti fini et qu'il a jamais chercher à savoir pourquoi, sans le savoir, son programme va utiliser un concept (la variable) pour retrouver un chemin (le home) pour résoudre un problème (multi-utilisateur). Donc le programme utilise bien un des principes du multi-utilisateurs : l'isolation des données.
Ah vrai dire je commence à en avoir marre de te répéter la même chose de 10000 manièrs différentes.
Sous Windows il y a /tmp, pardon "C:\temp"
Bah non, sous windows y'a pas C:\temp. Tu peux le créer si tu veux par contre.
- $HOME et d'ailleurs tu n'as pas le chois
demande au développeur :
"pourquoi t'as mis ca dans $HOME ?"
"ben parcque c'est le dossier de l'utilisateur !"
"ben pourquoi y'a un dossier pour l'utilisteur ?"
"ben parcqu'il peut y avoir plusieurs utilisateurs !"
tiens c'est marrant tu comprends mieux pourquoi il faut dire aux développeurs de programmer en penssant multi-utlisateurs, pour qu'ils y pensent, même si c'est pas toujours utile.
A part l'emploie de /tmp, vous ramez un peu. On trouve des entreprises qui ont vendu des programmes qui merdaient dans un environnement multi-utilisateur Windows.
On trouve ça sous Unix ? Non.
Un programme comme Gnome qui ne propose pas la possibilité de lancer un programme en tant que autre utilisateur n'est pour moi pas multi-utilisateur. Gnome peut par contre être lancé par plusieurs utilisateur, que ce soit sur le même PC ou sur des machines différentes, mais ce n'est pas celà le côté multi-utlisateurs, ça c'est du multi-tâches et on s'en balance.
Un programme multi-utilisateur, c'est un programme qui tient compte du fait qu'il y a plusieurs utilisateurs !!!
Les applications n'ont pas toutes à être multi-utilisateurs, mais elles doivent tenir compte du fait qu'elle peuvent tourner sur un OS multi utilisateur (et donc utiliser par exemple le $HOME, comme tu le dis c'est courant dans les Unix depuis 30 ans et c'est tant mieux).
Certaines applications doivent par contre être multi-utlisateurs, parcque c'est leur rôle d'en tenir compte, et je pense t'avoir donner suffisament d'exemple (Gnome, KDE, gdm, sudo, etc.)
Ce qui me fait chier, c'est que des raisonnement à la con (généralement pour nier les défauts techniques (vieu de plus) de Windows) s'installent tranquillement ici.
Mais ce n'est pas des raisonnement à la con, ce sont des raisonnements qui tiennent compte du fait que les applications sont :
- multi-plateformes si le développeur y met du siens (que ce soit en python, Java, C# ou autre, le développeur trouvera toujours un moyen de ne faire marcher son programme que sur une seule plateforme s'il fait pas gaffe à 1 ou 2 règles de bon sens de programmation)
- multi-utilisateurs si le développeur veut que son application tire parti du fait que l'OS est multi-utilisateur (sinon l'appli est mono-utilisateur)
- multi-threadé (ca se dit ca ?) si le développeur tient compte du fait que il peut avoir plus d'une UC à la fois. Ce critère va être de plus en plus prépondérant dans le future vu que tout porte à croire que même sur le PC de bureau on aura du multi-core.
Bref, si le développeur n'y met pas du siens, son programme peu n'avoir aucune de ses qualités. C'est pour celà que l'on sensibilise le développeur à ses concepts, pour qu'il en tienne compte le cas échéant.
Si ls n'affiche pas ces infos, ls reste multi-utilisateur.
Mon dieu tu dois faire exprès...
Donc si on suit ton raisonnement, sudo on lui enlève la possibilité de faire -u userquejeveux et il est toujors multi-utlisateur, gdm, on lui enlève la possibilité de lister les utilisateurs, etc.
Si ls affiche celà, c'est parcque c'est utile, et c'est une des fonctionnalités de ls !
Il est inutile qu'il affiche ces infos pour être multi-utilisateurs.
Non mais il est indispensable que le programmeur est pensé multi-utilisateur pour pouvoir afficher ces infos !
non, pour moi c'est dans le même registre, en tout cas c'est fortement lié, l'OS permet techniquement de mettre en place un concept (multi-utilisateur), mais c'est aux couches au dessus d'en tenir compte pour pouvoir justement exploiter cette possibilité.
Je me demande si 007 ne fait une confusion entre multi-utilisateur et multi-tâches (une confusion dans les rôles des couches, pas dans le sens des termes, je te prend pas pour une andouille non plus 007 ;-) )...
y dit qui voit pas le rapport. Libc c'est une bibliothèque de code. Là on parle de processus, d'interaction et de leur dynamique dans un contexte multi-utlisateurs.
Le but d'un OS multi-utlisateur c'est de s'occuper de l'aspect multi-utlisateur d'un point de vue technique, cad du point de vue fonctionnement des processus.
Le but des appli, c'est de s'intégrer dans un environnement au dessus d'un OS, en tenant parfois compte du fonctionnement de l'OS.
Effectivement, dans Gnome, le nombre de ligne est ridicule, d'ailleur c'est un reproche que je fais à Gnome, c'est de ne pas plus tenir compte de cet aspect (gtksu devrait être en standard par exemple)
Où tu vois une logique multi-utilisateur ici ?
Ben l'appli aurait très bien pu essayer de stocker ses fichiers quelques part dans /tmp, pourquoi ne pas essayer dans / d'ailleur, elle est pas censé savoir si elle a les droits root ou pas... bref, une appli qui propose $HOME par défaut est une appli conçu par un développeur qui a tenu du compte du fait qu'il y avait un compte utilisateur qui l'utiliserait et qu'il serait mieux de stocker ses documents avec les autres, c'est à dire dans son Home et pas ailleur parcque il est peut-être pas tout seul sur la machine et qu'il sait que ce répertoire pointe vers un dossier spécialement créé justement à cause du contexte multi-utilisateurs.
[^] # Re: C'est très bien !
Posté par TImaniac (site web personnel) . En réponse au journal P2p sur europe1 en ce moment même. Évalué à 1.
C'est parcque tu télécharge que tu apprécies... c'est un des avantages du p2p, tu dl les nouveautés (c'est pour ça qu'elle sont au tête des échanges), et hop tu écoutes : 2 solutions : A réécouter ou à jeter. Tu sais surement où va finir ce qui est en tête des dl ;-)
Et du même coup du te dis : "ouf, j'ai bien fait de ne pas acheter ce truc"
Pour iRate, j'ai testé pendant 1 semaine. Ben franchement, sauf si t'aime l'electro/techno voilà quoi...
[^] # Re: réponse
Posté par TImaniac (site web personnel) . En réponse au message mettre en avant les changements récents. Évalué à 2.
[^] # C'est très bien !
Posté par TImaniac (site web personnel) . En réponse au journal P2p sur europe1 en ce moment même. Évalué à 4.
De l'autre côté, les artistes contestent également le système actuel, trouvant les contrats de plus en plus complexes et de plus en plus injuste, ils ont plus l'impression d'être des employé d'une multinationale qui se réserve tous les droits sur leurs créations plutôt que d'être des artistes qui signent un contrat de distribution de leurs contenus.
Il y a évidemment d'autres facteurs que le p2p qui justifie la baisse des ventes des CD, mais le p2p est la principale cible des industrie car elle est le moyen de former et de concrétiser des idées qui naissent dans l'esprit de nombreux consommateurs.
[^] # Re: facile
Posté par TImaniac (site web personnel) . En réponse au journal Il a tout pour plaire, et pourtant.... Évalué à 7.
# facile
Posté par TImaniac (site web personnel) . En réponse au journal Il a tout pour plaire, et pourtant.... Évalué à 5.
Et voilà ! C'est pas compliqué !
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Bref, tu finis par l'admettre, il faut souvent éduquer le développeur à certains concepts (multi-utilisateur) et pratiques ($HOME), même si là c'est rapide à détecter/apprendre.
Pour le reste et les prob de sécurité avec /tmp, t'as sûrement raison, t'es plus à même de savoir de quoi tu parles.
Je penses que pour le côté multi-utilisateur, on a fait le tour.
Allez je vais en rajouter une petite couche identique pour le multi-tâche (ton 2ème exemple dans le texte du journal) :
Si l'OS est multi-tache, c'est à l'OS d'être multi-tache
Je comprend où est le problème là encore. Ta phrase est stupide au possible, tu peux remplacer multi-tâche par n'importe quoi :
Si la voiture est rouge, c'est à la voiture d'être rouge. (Ah bah ça c'est sûr :) )
Ta phrase devrait plutôt être :
Si l'OS est multi-tâche, c'est qu'il fournit un mécanisme de multi-tâche. (celà ressemble plus à une définition)
Et là, à plus forte raison que pour le côté multi-utilisteur, si le développeur ne fait rien pour que son appli soit multi-tâche, elle ne le sera pas (sauf si les libs qu'il utilise le sont à son insu bien entendu, mais là encore on remet le problème en dessous). Ce sera une appli mono-tâche qui tournera là encore bien sur un multi-tâche. Là encore il peut être fortement intéressant de "sensibiliser" les développeur à la pratique du multi-tâche, surtout avec système multi-core qui apparaîssent. J'espère que tu es convaincu que il faut pousser le cul des développeurs pour qu'ils évitent de rester sur les acquis, et parcque l'OS ne peut pas tout faire, et que l'environnement/machine évolue.
Perso, je préfère que l'OS n'en fasse pas trop (pour moi l'OS c'est le kernel, et son rôle est principalement de gérer les processus et de faire une première couche d'abstraction avec le matériel pour gérer les entrées/sorties), mais qu'il le fasse bien.
[^] # Re: Ah, le tas d'aneries habituel
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 6.
[^] # Re: Peut être
Posté par TImaniac (site web personnel) . En réponse au journal backdoor dans des machines a voter US ?. Évalué à 2.
[^] # Re: Peut être
Posté par TImaniac (site web personnel) . En réponse au journal backdoor dans des machines a voter US ?. Évalué à 2.
L'avantage, c'est que avec cette méthode, le code est généré automatiquement...
que celui qui a fait la démonstration est honnête ?
Il suffit de lancer un des outils de la méthode B pour vérifier qu'une démonstration est correcte.
que le code compilé l'a été fait sans qu'il n'y ai de backdoor dans le compilateur lui même (cf l'histoire) ou dans les bibliothèques ?
A priori le programme est correct quand toutes les dépendances le sont, cad les bibliothèques aussi (d'ailleur bonjour le boulot, parcque du coup faut tout prouver, et y'a qu'un type de données pour commencer : les entiers :) )
qu'il n'y a pas de détournement électronique/mécanique dans la boite qui pourrait fausser le vote en faisant croire qu'on a appuyé un autre bouton ? qui peut prouver que la boite qu'on a devant nous n'a pas été modifiée depuis toutes ces preuves (pour peu qu'on puisse les obtenir) ?
Ben là... c'est plus du domaine de l'informatique mais du domaine de la sécurité...
Le seul gain d'une boite automatique c'est accélérer le dépouillement.
c'est faciliter les comptages, c'est rigolo, c'est respectueux de l'environnement (pas de milliers de bulletins/enveloppes à faire)
[^] # Re: Peut être
Posté par TImaniac (site web personnel) . En réponse au journal backdoor dans des machines a voter US ?. Évalué à 2.
Ralala, mon prof de fac de méthode B serait heureux de lire celà :) C'est marrant, avec la méthode B, on peut prouver qu'un programme est correct et conforme aux spécifications. Je suis sûr qu'il serait facile d'utiliser cette méthode pour une machine de vote, puisqu'ils ont bien réussi à le faire pour une ligne du meteor à Paris...
[^] # Re: precisions ?
Posté par TImaniac (site web personnel) . En réponse au journal Le tour de France Telecom.... Évalué à 5.
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Bah oué :)
Effectivement, la redirection par variable a d'autres intérêt que le multi-utilisateur.
Quoiqu'il en soit, coder en dure un chemin n'est JAMAIS une bonne idée.
Tout à fait, mais là encore, faut éduquer le programmeur, parcque ce genre de pratique se rencontre souvent :-)
Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant et qui s'apercevait que ca marchait pas sur toutes les machines (quoique le /tmp en général on le retrouve... moi le premier y'a 4 ans :-p
# précisions
Posté par TImaniac (site web personnel) . En réponse au journal Le tour de France Telecom.... Évalué à 2.
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
# amicalement
Posté par TImaniac (site web personnel) . En réponse au journal Linux trop populaire.. Évalué à 9.
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Euh si je veux 2 sessions graphiques avec 2 bureaux différents, je fais comment ? Je lances pas 2 serveurs X ? En tout cas c'est bien caché...
Moi, je fais Applications->Outils système->Nouvelle connexion ou Applications->Outils système->Run as different user sous Gnome
Désolé j'ai pas celà sous mon Gnome (ca doit venir de fedora), mais dans tous les cas ce n'est vraiment pas pratique, il faut rajouter la ligne à exécuter à la main... Je ne suis même pas sûr que celà fasse parti de gnome, ce n'est pas plutôt le projet gdksu qui est à part ?
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 4.
> Bah non, sous windows y'a pas C:\temp.
Mais si. C'est indiqué avec la variable TEMP je crois.
Sous windows c'est C:\windows\system\temp.
sans commentaire.
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.
putain mais t'es vraiment grave.
Là tu demande au développeur de ne pas tenir compte du fait qu'il n'y a pas plusieurs utilsateurs, donc l'application sera MONO-UTILISATEUR parcqu'elle ne s'occupe pas des problèmes liés au fait qu'il y en ai plusieurs.
Mais OUI, elle pourra sûrement tourner sur un OS multi-utilisateur.
Tu le dis toi même "multi-utilisateur compliant" c'est à dire compatible avec les OS multi-utilisateurs. C'est pas pour celà que l'appli sera capable de tenir compte du fait qu'il y a plusieurs utilisateurs.
C'est comme si tu fais un programme mono-thread, alors oui tu pourras dire qu'il est compatible avec les OS multi-thread (encore que) amis ce n'est pas pour celà qu'il sera multi-thread ! Il faut que le développeur utilise explicitement cette possibilité, pareil pour le côté multi-utilisateurs.
Et c'est ce qu'on demande aux développeurs, on leur demande d'ajouter un PLUS à leurs appli, de ne pas se contenter de faire en sorte qu'elle puisse être lancé plusieurs fois. Bref, tirer parti de l'avantage de pouvoir avoir plusieurs utilisateurs en même temps.
Bravo. Gnome est un programme.
Tu as quelle version du programme Gnome ?
T'es vraiment trop con. Voilà tu préfères que je parle de solution logicielle ? Ca va c'est assez vague pour que tu comprennes sans m'enmerder sur les termes que tout le monde comprend ?
* Win 95 est multi-tâches et pas multi-utilisateur.
Mais j'en ai rien à cirer de Win95 ! On parle d'Unix bordel !
C'est l'OS qui est multi-utilisateur et pas un programme !
Clap clap clap.
L'OS est multi-utilisateur si il tient compte du fait qu'il peut y avoir plusieurs utilisateurs.
Le programme est multi-utilisateur si il tient compte du fait qu'il peut y avoir plusieurs utilisateurs.
Je crois que tu as franchement du mal à comprendre qu'il ne suffit pas de se contenter du multi-utilisateur au niveau noyau. A tous les niveau il faut en tenir compte. Parfois celà ne change rien aux fonctionnalités, parfois celà apporte de nouveaux besoins, de nouvelles possibilités. Et c'est ce qu'on demande aux programmeurs :!!!!!!!: Tenir compte du fait qu'il peut y avoir plusieurs sessions graphiques en même temps sur une même machine !!!! (chose relativement nouvelle)
Tu mélanges tout.
Bon, heureusement que depuis 30 ans, Unix ne fait pas ce que tu dis.
heuresement que depuis 30 ans l'informatique a évolué et que tes idées sont dépassés depuis autant de temps.
Il n'y a pas d'appli mono-utilisateur sous Unix
quelques lignes plus haut tu dis que seul l'OS peut être multi-utilisateur et pas les programme, et là tu me dis qu'ils sont tous multi-utilisateur (car pas mono-utilisateur)
t'es vraiment un boulet.
On peut être multi-utilisateur et pas multi-threadé. Ça existe.
J'ai dit le contraire ? tu fabules.
On peut être multi-threadé et pas multi-utilisateur (win 95). etc.
J'ai dit le contraire ? tu fabules.
Met ca une bonne fois pour toute dans la tête :
une appli est mono-utilisateur lorsqu'elle ne tient pas compte du fait qu'il peut y en avoir plusieurs.
une appli ou un OS est multi-utilisateur quand elle en tient compte. Mais l'un n'empêche pas l'autre ! et tu peux très bien utilisé une appli multi-utilisateur sur un OS non conçu pour (l'appli va tout faire), ou l'inverse, une appli mono-utilisateur sur un OS multi-utilisateur, auquel cas l'appli n'en tirera pas parti (poutant elle le font quasiment toute en utilisant HOME), tu peux aussi faire tourner une appli multi-utilisateur sur un OS multi-utilisateur en utilisant un tout autre système ou en utilisant la couche inférieur qui propose des fonctionnalités multi-utilisateur.
Désolé si je me suis emporté, mais tu m'as énervé. Tu peux me moinsser si ça t'amuse.
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 4.
Un OS multi-utilisateur a besoin d'applis faites spécifiquement pour le multi-utilisateur.
N'importe quoi, un OS n'a besoin de rien du tout pour fonctionner.
Si l'appli n'est pas fait pour le multi-utilisateur alors l'appli ne peut pas être utilisées par plusieurs personnes à la foi.
Euh, personne n'a dit celà... ce qu'on dit (qu'on se tue à te dire), c'est qu'il y a une différence entre pouvoir lancer plusieurs fois une application (que ce soit depuis un autre utilisateur ou non) et tenir compte du fait qu'il peut y avoir plusieurs utilisateurs pour proposer des infos et une ergonomie en conséquence à l'utilisateur (ça c'est une appli multi-utilisateur)
Tu saisies la différence ?
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
t'es désespérant...
De même, avant de développer une applis, tu ne te dis pas :
- multi-utilisateur ou mono-utilisateur ?
Bah si justement !
Et c'est ce que devrait faire tout bon programmeur.
Dans 99 % les applis pour Unix sont développées sans penser à multi-utilisateur ou mono-utilisateur et qu'on utilise $HOME n'y change rien.
Et bah c'est justement pour celà qu'on tente d'éduquer les développeurs, parcqu'il y a de plus en plus d'application qui se contente de fonctionner parfaitement dans un espace multi-utilisateur mais sans tenir compte du fait qu'il peut y avoir plusieurs utilisateurs qui peuvent vouloir intéragir.
Et pour le $HOME ?
pourquoi c'est une variable ?
pourquoi c'est pas un chemin absolu ?
Oui les développeurs savent que c'est là qu'il faut mettre ses infos et pas ailleur, même si le programmeur est un abruti fini et qu'il a jamais chercher à savoir pourquoi, sans le savoir, son programme va utiliser un concept (la variable) pour retrouver un chemin (le home) pour résoudre un problème (multi-utilisateur). Donc le programme utilise bien un des principes du multi-utilisateurs : l'isolation des données.
Ah vrai dire je commence à en avoir marre de te répéter la même chose de 10000 manièrs différentes.
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 3.
Bah non, sous windows y'a pas C:\temp. Tu peux le créer si tu veux par contre.
- $HOME et d'ailleurs tu n'as pas le chois
demande au développeur :
"pourquoi t'as mis ca dans $HOME ?"
"ben parcque c'est le dossier de l'utilisateur !"
"ben pourquoi y'a un dossier pour l'utilisteur ?"
"ben parcqu'il peut y avoir plusieurs utilisateurs !"
tiens c'est marrant tu comprends mieux pourquoi il faut dire aux développeurs de programmer en penssant multi-utlisateurs, pour qu'ils y pensent, même si c'est pas toujours utile.
A part l'emploie de /tmp, vous ramez un peu.
On trouve des entreprises qui ont vendu des programmes qui merdaient dans un environnement multi-utilisateur Windows.
On trouve ça sous Unix ? Non.
Un programme comme Gnome qui ne propose pas la possibilité de lancer un programme en tant que autre utilisateur n'est pour moi pas multi-utilisateur. Gnome peut par contre être lancé par plusieurs utilisateur, que ce soit sur le même PC ou sur des machines différentes, mais ce n'est pas celà le côté multi-utlisateurs, ça c'est du multi-tâches et on s'en balance.
Un programme multi-utilisateur, c'est un programme qui tient compte du fait qu'il y a plusieurs utilisateurs !!!
Les applications n'ont pas toutes à être multi-utilisateurs, mais elles doivent tenir compte du fait qu'elle peuvent tourner sur un OS multi utilisateur (et donc utiliser par exemple le $HOME, comme tu le dis c'est courant dans les Unix depuis 30 ans et c'est tant mieux).
Certaines applications doivent par contre être multi-utlisateurs, parcque c'est leur rôle d'en tenir compte, et je pense t'avoir donner suffisament d'exemple (Gnome, KDE, gdm, sudo, etc.)
Ce qui me fait chier, c'est que des raisonnement à la con (généralement pour nier les défauts techniques (vieu de plus) de Windows) s'installent tranquillement ici.
Mais ce n'est pas des raisonnement à la con, ce sont des raisonnements qui tiennent compte du fait que les applications sont :
- multi-plateformes si le développeur y met du siens (que ce soit en python, Java, C# ou autre, le développeur trouvera toujours un moyen de ne faire marcher son programme que sur une seule plateforme s'il fait pas gaffe à 1 ou 2 règles de bon sens de programmation)
- multi-utilisateurs si le développeur veut que son application tire parti du fait que l'OS est multi-utilisateur (sinon l'appli est mono-utilisateur)
- multi-threadé (ca se dit ca ?) si le développeur tient compte du fait que il peut avoir plus d'une UC à la fois. Ce critère va être de plus en plus prépondérant dans le future vu que tout porte à croire que même sur le PC de bureau on aura du multi-core.
Bref, si le développeur n'y met pas du siens, son programme peu n'avoir aucune de ses qualités. C'est pour celà que l'on sensibilise le développeur à ses concepts, pour qu'il en tienne compte le cas échéant.
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 3.
Mon dieu tu dois faire exprès...
Donc si on suit ton raisonnement, sudo on lui enlève la possibilité de faire -u userquejeveux et il est toujors multi-utlisateur, gdm, on lui enlève la possibilité de lister les utilisateurs, etc.
Si ls affiche celà, c'est parcque c'est utile, et c'est une des fonctionnalités de ls !
Il est inutile qu'il affiche ces infos pour être multi-utilisateurs.
Non mais il est indispensable que le programmeur est pensé multi-utilisateur pour pouvoir afficher ces infos !
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Merde :-)
(sauf lorsqu'il tente la résolution du nom associé à un uid)
Bon ben j'ai un petit peu raison quand même ;)
[^] # Re: Pas top l'exemple...
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Je me demande si 007 ne fait une confusion entre multi-utilisateur et multi-tâches (une confusion dans les rôles des couches, pas dans le sens des termes, je te prend pas pour une andouille non plus 007 ;-) )...
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 5.
Le but des appli, c'est de s'intégrer dans un environnement au dessus d'un OS, en tenant parfois compte du fonctionnement de l'OS.
Effectivement, dans Gnome, le nombre de ligne est ridicule, d'ailleur c'est un reproche que je fais à Gnome, c'est de ne pas plus tenir compte de cet aspect (gtksu devrait être en standard par exemple)
Où tu vois une logique multi-utilisateur ici ?
Ben l'appli aurait très bien pu essayer de stocker ses fichiers quelques part dans /tmp, pourquoi ne pas essayer dans / d'ailleur, elle est pas censé savoir si elle a les droits root ou pas... bref, une appli qui propose $HOME par défaut est une appli conçu par un développeur qui a tenu du compte du fait qu'il y avait un compte utilisateur qui l'utiliserait et qu'il serait mieux de stocker ses documents avec les autres, c'est à dire dans son Home et pas ailleur parcque il est peut-être pas tout seul sur la machine et qu'il sait que ce répertoire pointe vers un dossier spécialement créé justement à cause du contexte multi-utilisateurs.