TImaniac a écrit 6420 commentaires

Donner les droits uniquement sur synaptic par exemple revient au même pour ce qui est d'installer des applications.
nan nan nan nan. Si tu donne droit d'utiliser synaptic autrement qu'en root synaptic il va pas s'amuser avec la base rpm du home de l'utilisateur, il va râler.

Sous windows, comment il fait le monsieur lambda pour installer le soft lorsque l'installeur lui demande les droit admin et qu'il ne les a pas ? Ben il peut pas.
C'est qu'il y a sûrement une bonne raison !
Et puis il peut faire comme sous nux : il va chercher un binaire dans un .zip :-p

Et puis arrête de faire exprès de pas comprendre, je parle pas de la théorie et de ce qu'on peut ou peut pas faire, je parle de vécu, de ce qui se passe dans la vrai vie : met une tripotté d'utilisateurs devant des machines Linux et Windows avec seulement les droits utilisateur, et demande leur d'installer des softs qu'ils trouvent sur le net.

un truc du genre %users ALL=(ALL) ALL
tu tiens vraiment à faire une connerie dans le genre ?

peut on le faire avec Office ?
Aucune idée.

Mais la question n'est pas là, je répond à la base a ton affirmation [...] Et ca, c'est faux.
RAaaaaaah j'ai dis qu'il fallait replacer dans le contexte, cad dans la pratique, dans la vie de tous les jours !

Et dans la vie de tous les jours l'utilisateur lambda ne sait même pas qu'il peut ajouter une base rpm dans son compte, ne saura même pas poquoi les dépendances ne sont pas résolues, de toute façon il s'en fou l'utilisateur lambda il utilse apt-get/yum/urpmi qui lui demanderont d'être root !
Dans la vie de tous les jours un utilisateur lambda sous windows sans les droits root pourra installer un grand nombre d'application, peut être pas toutes mais une majorité, parcque contrairement à ce que tu veux bien me faire dire, l'installeur demande les droits d'amin QUAND C NECESSAIRE (ou que l'installeur est mal foutu)

Maintenant, dans quel cas as-tu le plus de risque d'endommager ton système ?
Forcement, parcque sous linux c'est tellement pas user-friendly que de toute façon l'utilisateur il vient te voir parcqu'il n'arrive à rien installer. AU moins y'a pas de risque.

Ben tu écrases gentiment la partition contenant Windows 2000 et tu lances l'install de Mandrake qui se chargera de s'installer là où tu lui indiqueras et qui te mettra un zoli menu au démarrage de l'ordinateur pour te permettre de choisir l'OS sur lequel tu souhaites booter.

C'est du joli n'importe quoi que tu nous racontes là : le client final il s'en fou royalement de savoir comment son distributeur développe/sous-traite ses produits. D'ailleur pourquoi au sein de MS il n'y a aurait pas non plus des unités de développement spécifiques et/ou de sous-traitance ?
Ce qui intéresse le client c'est le produit final tel qui lui est livré, et les possibilités de mise-à-jour qui lui sont proposés par son fournisseur. Que y'en est un qui soit développeur/éditeur et l'autre qui soit plutôt un "intégrateur" ne change strictement rien à leur position vis-à-vis du client.
Que MS ai des avantages parcqu'il maîtrise tout le produit et notamment son développement est possible, mais celà n'enlève rien à la valeur d'une telle comparaison.

Leur étude aurait été mieux fabriquée s'ils avaient rajouté un prestataire entre microsoft et le client final
Tu oublies que MS est aussi prestataire, et se situe au même niveau que Red Hat pour ce qui est du support du produit livré : ils proposent les mêmes types de services.
Alors je ne vois strictement aucun intérêt au fait de rajouter un prestataire intermédiaire, si ce n'est ajouter de la confusion.

jor c'est une généralité,
jor on ne peut pas ajouter un paquet avec la bonne signature mais qui contient des conneries,
jor je suis obligé de signer un rpm,
jor rpm va m'interdire d'installer un rpm non signé,
jor uon peut faire confiance à tous les repositories,
etc.

et donc ?

Monsieur tout le monde il a Windows XP, et donc il a le basculement rapide d'utilisateur et peut donc se loguer en admin et faire tout ce qu'il veut.

Attention, je n'ai pas voulu dire que l'un ou l'autre avait besoin de plus de droits, je suis aller dans le sens du discours du monsieur et on se basait sur ce qui se faisait dans la pratique, et non ce qui devait être fait dans la théorie.
Et je constates que de manière générale un utilisateur Linux passe systématiquement en root pour installer un soft, alors que sous Windows il ne passera en root que si y'a pas d'autres possibilités.
D'une manière générale sous Windows le problème ne vient pas des fonctionnalités qui demande à être root (celà est de moins en moins courant, et du même niveau que sous nux), mais du fait que par défaut le premier utilisateur est admin (sous XP). Sans doute pour que celà soit plus user-friendly, la notion de compte étant érangère au newbie. Heuresement dans d'autres versions comme win2000 ou winserver2003 ce n'est pas la même politique.

Tiens, je peut meme installer OpenOffice par exemple dans mon Home, sans droit root. On peut faire pareil avec MSOffice ?
Elle est idiote ta comparaison, installe OpenOffice sous Windows te permettrait mieux de vérifier la politique de l'OS.

une ligne dans le sudoers et c'est bon
Et tu mets quoi dans cette ligne ???!?

Donc on est bien d 'accord y'a moyen :)
sinon je suppose que comme la plupart des composants de Windows tu trouveras le bon exécutable par ici : "C:\Windows\System32" et tu pourras alors faire "exécuter en tant que..."
ou bien si tu es un geek fan de la ligne de commande tu feras "exécuter en tant que..." sur cmd.exe et tu feras mumuse avec ipconfig et autre netsh.

Bref, quand on veut on peut.

t'inkiète pas un administrateur lui il sait le faire :)
bouton droit de la souris sur l'exécutable (en l'occurence celui de l'interface rezo) : "exécuter en tant que..." et là tu choisis le compte que tu veux.

j'ai dis "quand il en a besoin"
Comprendre pas à chaque fois.
Donc on n'est pas d'accord.
Ubuntu semble bien pensé de ce point de vu et c'est tant mieux, mais c'est loin d'être une généralité.

Je comprends vraiment pas ton raisonnement, si je propose à l'utilisateur :
nudesex.jpg.sh
ou
nudesex.jpg.rpm
le système de MIME n'apportera aucune garantie, chaque fichier déclare bien une extension compatible avec son format MIME.

En même temps sous Nux mon manager de rpm va s'ouvrir automatiquement quand je vais cliquer sur un lien amenant à un rpm, ce rpm n'a pas les droits d'exécution et il peut faire des dégâts.
A mon avis les manager de rpm devrait revoir leur rôle parcqu'à force de demander le mdp du root à tout bout de champs sans proposer d'installer le rpm en local...

Suffit de demander à Windows de se connecter automatiquement au démarrage et d'autoriser l'utilisation de la connection par les utilisateurs non root.

Ben je surf trankilou sur ma fedora là, et même si je sais qu'il est possible d'installer un rpm sans avoir les droits root, pour le commun des mortels quand il cliques sur un rpm y'a le manager qui se met en marche et qui demande au gentil utilisateur de rentrer le mdp root. T'as envie de tester un soft, t'as pas vraiment envie de te faire chier à créer ta base de rpm à toi.
Sous Windows un installeur demande explicitement les droits root quand il en a besoin, d'où ma remarque.

Alors avant de dire que je dis n'importe quoi, remets toi dans le contexte de la discussion : on parle de ce que l'utilisateur a tendance à faire, pas de ce qu'il doit faire.

Euh, si tu te limites aux mêmes tâches sous Windows que sous Linux, cad que tu ne joue pas (tu ne peux pas), ben je vois vraiment pas en quoi t'as besoin d'être root sous Windows, c'est tout à fait tenable. Et même pour les jeux, celà devient de plus en plus rare d'avoir besoin des droits root.

J'ai même tendance à dire le contraire : sous Nux faut les droits root pour installer le moindre programme, alors que sous Windows ce n'est pas du tout le cas.

Par contre je ne suis pas sûr qu'ils aient fini de tout implémenter dans Mono, apparement il y a du boulot de fait, si je regardes les morceaux de code proposé sur le blog du "spécialiste" dans l'équipe Mono :
http://pages.infinit.net/ctech/poupou.html(...)
(avec un nom comme ça il doit sûrement parler français et être à même de répondre à tes questions :-), sinon tu peux toujours poster sur la mailing list mono-devel)

Il y a aussi tout un système de certification numérique pour ne pas utiliser n'importe quoi comme code, enfin celà a l'air assez dense et indigeste à comprendre :)

Bon courage !

Idée générale :
Le code (ton moteur) qui utilise du code d'une provenance inconnu (internet en l'occurence), doit se prémunir lui même de faire des conneries (tu ne peux pas partir du principe que le code inconnu s'est mis lui même les bonnes permissions, logique).

Il y a tout un système de permission et droits d'accès (accès au fichiers, à certains composants, etc.) dans la techno .NET/Mono, appelé "Code Access Security" (CAS).
Tu trouveras un excellent article traitant du sujet à cette adresse :
http://www.codeproject.com/dotnet/UB_CAS_NET.asp(...)

"Ensuite, comment fait-on pour importer une classe en C# ?"
Je ne suis pas sûr de bien comprendre la question, mais tu peux utiliser une classe (ou tout du moins une instance de cette classe) à distance, télécharger un objet et l'utiliser en local, télécharger un assembly (unité d'encapsulation, en gros un .dll qui regroupes plusieurs classes) et l'utiliser.

"Enfin, Peut on limiter les privilèges des différentes classes ?"
Oui, cf lien plus haut.

t, tu as dit dans ton commentaire que sun choisissait qui rentrait ce qui est faux... c'est tout.
Je pensais pas qu'il y avait besoin de préciser la suite :
" When Sun executes the agreement, a copy will be faxed back to you."
Et il se passe quoi s'ils te répondent pas ?
N'ont-ils pas là le pouvoir le décider qui a le droit de fiare partie du commité ?

Alors oui, j'en conviens, il faut signer un accord pour faire partie de ce genre de consortium, ca me paraît évident, mais dans le cas JCP ben je trouve pas celà très "indépendant".

De plus le jour où Sun décide que non après tout le JCP celà ne lui convient plus il se passe quoi ?
Et puis Java & Co restent des marques de Sun, bref Sun fait ce qu'il veut sur son produit si celà lui chante, et enmerde qui il veut (genre MS qui implémente une version non conforme de la JVM, je ne juge pas sur la pertinence mais je constate cette possibilité qu'a Sun que l'ECMA ne permet pas)
au fait C# et les bases de .NET sont à l'ECMA ET à l'ISO, bref, c'est des vrais standards reconnus.

Plus sérieusement en dehors de ce débat sur l' "indépendance" de la techno et de sa normalisation, la questiond e la maturité ne se pose pas, elle est évidente : Java a 15 ans (à la louche) et Mono est en produciton depuis 6 mois.
Seulement quand on voit la maturité qu'à atteind Mono en si peut de temps comparé aux autres projets Java LIBRES (Kaffe, gcj), je me dis qu'il n'y a pas du tout la même réactivité des 2 côtés.

Pour ce qui est de l'environnement de développement il faut bien reconnaître que Eclipse n'a pas d'égal dans le monde Mono (Visual Studio posant évidement trop de limitation en matière de libertés). Mais tout le mérite revient à IBM, et non à l'adoption de Java par le LL face à sa maturité.

est ce que les gens de NHibernate vont participer à l'élaboration de l'outil de mappingO/R de microsoft ?
Je captes pas là, c'est quoi le rapport ?
Des solutions de mapping O/R il en existe des dizaines, NHibernate est sans doute la plus répendue (grâce à la renommée de la version Java), mais je ne vois pas en quoi ils doivent s'impliquer dans une solution de MS, à la limite je trouve celà pas plus mal qu'ils gardent leur indépendance "technologique".

Enfin bref, évitons les trolls, et concluons :
- les 2 parties font des efforts côté ouverture.
- ECMA/ISO est un meilleur gage de normalisation que le JCP (qui comme son nom l'indique a été créé par et pour Sun)
- Java est beaucoup plus mature
- Mono n'a pas d'appli industrielles pour faire des démonstrations

Par contre question communauté du LL, Mono a l'air d'être beaucoup plus adopté, en tout cas si je me réfère au site GnomeFiles :
http://www.gnomefiles.org/(...)
Regardes dans les best rated le nombre d'appli Mono (7 sur 20) et le nombre d'appli Java...

Sinon un truc pour nous réconcillier :
IKVM.
un mariage audacieux entre Mono et Gnu ClassPath :)

"Participation as a Member requires you or your organization to sign the Java Specification Participation Agreement (JSPA). The JSPA is a one-year, renewable agreement between you and Sun Microsystems, Inc."

Tout est dit.

Et puis bon, quand je vois l'implémentation des generics dans java 1.5, je me dis qu'ils doivent vraiment pas avoir beaucoup de poids les autres membres, parcque franchement laisser passer cette solution est vraiment déplorable et dénué de bon sens.

Le JCP peut effectivement prendre des décisions qui ne vont pas forcement dans le sens de Sun, c'est arrivé, mais celà ne démontre aucunement l'indépendance du consortium vis-à-vis de Sun. On croirait que tu oublies que la porte n'est pas ouverte à tout le monde, et que c'est Sun qui décide qui y a droit de citer.
C'est un peu comme si tu faisais un parlement mais avec uns députés filtrés et non élus.
Je préfère perso largement un consortium parfaitement indépendant qui m'assure que tout ce qu'il normalise est LIBREMENT implémentable et sans DISCRIMINATION.

ffmpeg regroupe un ensemble d'implémentation d'encodeur/décodeur de vidéo au format MPEG (notamment MPEG4 et donc DivX).

ffmpeg est souvent utilisé sous Linux pour justement lire les DivX.
Pour installer les codecs ffmpeg, télécharge tous les codecs qui se trouvent ici :
http://www1.mplayerhq.hu/MPlayer/releases/codecs/essential-20050115(...)

et décompresse les dans le dossier /usr/lib/win32 (créé le dossier s'il n'existe pas).

Après tu devrais pouvoir lire à peu près tout ete n'importe quoi comme format vidéo avec ton lecteur préféré :)

Non non c'est pas un bug, c'est une vrai feature, c'est même une des forces de .NET/Mono, c'est cette capacité de versionning (et sa granularité). Tu te doutes bien que'entre différentes applications tu risques de retrouver des noms de classes en communs, des def plus ou moins identiques mais parfois dans un contexte totalement différent. C'est pourquoi le CLR assigne des numéros permettant d'indetifier un assembly, une classe une méthode, plutôt que de se contenter de son nom.
(celà ne veut pas du tout dire que tu es obligé de signer numériquement tes assembies avec sn.exe)

Mettre ce code dans une dll commune (avec les defs) ne fonctionne pas: "Cannot find type PluginInterface" a la compilation.
T'as du te planter quelque part.
En général chez moi tout ce qui est partagé par les plugins (donc les defs et sans doute ton PluginInterface) sont dans une dll séparée, dans un namespace, comme ceci :

namespace MonAppli.Core.PluginSystem {
public interface...
public attributes...
}

(le plus souvent c'est même dans le coeur de mon appli, dans MonAppli.Core.dll)

et pour développer un plugin, un développeur odit juste référencer ta dll avec mcs :
mcs -t:library -r:MonAppli.Core.dll

bien sûr dans son code il doit écrire quelquechose comme :
using MonAppli.Core.PluginSystem;

pour "importer" les defs.

mmmh je crois savoir d'où vient ton problème.

Visiblement tu compiles ton plugin avec le source de l'attribute, puis tu recompiles le programme qui cherche les plugins avec ce même source... je me trompes ?
Donc du coup chacun a sa version de la définition, et malgrès le partage de source, le CLR (Common Langage Runtime, autrement dit l'environnement d'exécution, plus comunément appelé machine virtuelle, qui se lance avec la commande mono) voit 2 versions différentes (ils ont chacuns un numéro de version, etc.)

Ce qu'il faut faire dans ton cas précis :

compiler dans une dll tout ce qui doit être "partagé", autrement dit ce qui doit être connu des plugins et du gestionnaire de plugin, cad en gros les def d'attributes, les interfaces, les classes manipulables par les plugins, etc.
mcs -

ensuite tu compiles un plugin comme ceci :
mcs -target:library monPlugin.cs -r:MonAppliQuiContientLesDefs.dll

les def d'attributs sont dans MonAppliQuiContientLesDefs.dll.
Tu peux également y mettres ton gestionnaire de plugin, celui qui les charges, mais tu peux aussi mettre ton gestionnaire à part. Il se compilera alors de la même façon :
mcs -target:library monGestionnaire.cs -r:MonAppliQuiContientLesDefs.dll

ou dans une application :
mcs monAppli.cs -r:MonAppliQuiContientLesDefs.dll

en espérant que ca marche mieux maintenant :-)

Si ca marche toujours pas tu peux me mailer si tu veux.

Effectivement tu n'as pas bien compris le schmurck :)
Premièrement c'est normale le is null, tu fais ton test dans une boucle foreach, et tu peux très bien trouvé tout pleins d'autres attributes uqi ne sont pas les tiens.

En tout cas chez moi j'ai essayé ton attribute dans une dll, et j'ai testé avec ca :
Assembly asm = Assembly.LoadFrom("plugin.dll");
Attribute[] attributes = Attribute.GetCustomAttributes(asm);

foreach(Attribute attribute in attributes)
{
if (attribute is AssemblyDependencies)
{
Console.WriteLine("trouvé !");
AssemblyDependencies ds = (AssemblyDependencies)attribute;
foreach(string s in ds.Dependencies.Keys) Console.WriteLine(s+" : "+ds.Dependencies[s]);
}
}

et ma fois ca marche nickel, j'obtiens ca en résultat :
trouvé !
aa : 1.0.0.0
ee : 1.0.0.0

Sinon plutôt que de faire un attribute avec un nombre variable d'argument, tu peux aussi en mettre que 2, nom+version, et proposer à l'utilisateur de mettre plusieurs fois l'attribut s'il veut multiplié les dependances.

Ah oui aussi je sais pas trop ce que tu veux faire, mais la gestion des dépendances d'habitudes c'est un obulot réservé au CLR, et tu n'as absolument rien à faire pour les gérer mais bon :)

Gaim semble le mieux correspondre à tes besoins : il est multi-protocoles (yahoo, msn, aim, jabber, etc.), et tourne sous Linux et Windows.

Par contre pour la visio laisse tomber direct, y'a rien qui soit compatible avec les ténors du marché (MSN, etc.)
Pour faire de la visio il y a gnomemeeting, mais pas de support MSN donc, mais support netmetting.