Pinaraf a écrit 3674 commentaires

Ouais mais windows a un environnement ?
Windows a un système de portefeuille de mots de passe ? Windows a un look'n'feel commun pour toutes les applications ? (même pour les applications fournies avec windows, c'est faux : regarde windows media player et l'explorateur)

Ces évolutions sont bien sûr disponibles pour les autres distributions (ou vont l'être).
Ou le sont déjà depuis la sortie de kubuntu 5.04, suse 9.3 ou encore fedora core 4...
Chez mandriva c'est pour les utiliateurs de cooker ou les membres du club uniquement alors que chez les autres distribs intégrant KDE 3.4 c'est pour tout le monde généralement

Le problème c'est que les bases existantes ne sont pas forcément des plus fiables ni des plus complètes.
Il faudrait utiliser le maximum de bases existantes comme celle d'ubuntu.
En gros, on pourrait créer notre base de donnée et y importer les informations de la base d'ubuntu (mais combien d'utilisateurs d'ubuntu utilisent la fonctionnalité pour signaler la compatibilité de leur matériel ?), et importer aussi les informations de la base de linuxcompatible (mais sa qualité est ... moyenne)

En fait, aucune base existante ne me paraît satisfaisante :/

Ça peut être difficile, mais c'est tout à fait faisable !
Personnellement, je ne vois aucun problème lourd à la réalisation, dans un langage portable, d'un tel outil.
Il faudrait bien sûr s'arranger pour que l'outil tourne sur windows et linux.
Je pense que le réaliser en python serait pas mal (c'est 100% libre, portable, suffisamment de librairies fournies de base pour avoir toutes les fonctionnalités requises...). Puis bon, je suis un fan de python :)
Il faudrait avoir un site web assez complet avec un système pour ajouter le matériel, avec suffisamment de détails pour bien comprendre ce qui est nécessaire pour faire tourner le matériel. Ce n'est pas parce qu'une carte wifi marche du premier coup sur mandrake 10.0 qu'elle marchera du premier coup sur ubuntu 5.04 (mais sur la 5.10 elle marchera tout de suite : le driver est inclus :)). Lors de l'ajout de matériel, il faudrait préciser la ligne donnée par lspci (ou un autre outil) concernant ce matériel...

Le "seul" problème que je vois directement c'est la portabilité sous windows : existe-t-il un lspci, avec des résultats comparables à ceux sous linux ?

Si des gens sont prêts à me suivre dans la réalisation d'un tel outil, qu'ils me suivent ! #compatux @ irc.freenode.net
Je ne fais rien tant que je suis pas sûr de recevoir de l'aide (windows ... je n'ai plus ça chez moi depuis plus d'un an) pour la réalisation du projet.

Je me pose de plus en plus souvent la question de l'utilité sous linux et MacOS d'une suite mozilla complète, de même que de l'utilité de firefox/thunderbird !
En effet, sur Linux comme sur MacOS, les applications d'un environnement de bureau (le bureau standard de mac, KDE ou GNOME sous linux) sont extrêmement bien intégrées au reste de l'environnement, pas une ne dépareille, elles communiquent entre elles quand c'est utile... Cette communication est très importante dans le cas d'applications liées à internet : communication entre le lecteur de mail et le programme de chat par exemple.
Une application comme firefox ou pire seamonkey est un vrai martien en terme d'intégration dans un vrai environnement (KDE, GNOME, MacOS), et encore plus quand son look est différent de celui des autres applis (environnement KDE (gtk-qt est incapable de réaliser tout le nécessaire, par exemple pour les écrans de configuration) ou MacOS (?))
Tous les environnements de bureau fournissent leur navigateur web (Konqueror, Epiphany, Safari). Ces navigateurs sont intégrés à l'environnement et l'exploitent (stockage des mots de passes pour Konqueror par exemple).
Mais comment un logiciel "générique" comme opera ou firefox ou seamonkey peut exploiter ces technologies à 100% ? Cela me semble impossible, particulièrement quand on considère le fait que tout ne soit pas dans le même langage de programmation.
Firefox ne pourra jamais être une vraie application KDE ni une application GNOME totalement intégrée. Le port d'une plateforme à une autre est source de problèmes pour l'intégration !
L'avenir appartient plutôt à des applications comme Konqueror, Epiphany, Safari... qui elles sont intégrées à l'environnement !

Par contre, sous windows ou n'importe quel autre système sans environnement de bureau (WindowMaker, Fluxbox...) firefox, seamonkey... sont très utiles, je suis d'accord.

Non c'est pas les paquets eux mêmes.
En fait la base de données des paquets en XML était très pratique, mais DOM est coûteux : au moins 2 fois la taille du document en mémoire vive, au niveau CPU c'est pas mal non plus...
Par contre, en sqlite elle est bien plus puissante. De plus faire des requêtes particulières sur la base de données est très simple. Mais les paquets restent en XML

N'hésitez pas à passer sur #fnux @ irc.freenode.net pour plus d'informations

Je pense qu'il est inutile de nous demander notre avis.
Je trouve en effet qu'un toolkit doit tirer profit des capacités du langage de programmation dans lequel il est conçu, et donc proposer une API qui y soit adaptée.
Prenons par exemple Qt : je le trouve parfaitement adapté au C++, mais par contre ses bindings python (pyqt) ne sont pas adaptés au langage python : le système de connexion signal/slot n'est pas, et de loin, le plus adapté au langage python dans l'état actuel des choses. Pourquoi faire un QObject.connect (source, signal, cible, slot) alors qu'on pourrait en python faire un cible.slot.append(source.signal) ou un truc comme ça ?

Bref, je ne pense pas que linuxfr soit le meilleur endroit pour trouver l'API de ton toolkit : il y a trop peu de personnes connaissant le Lisaac pour aider à faire une API adaptée...

Je crois que j'ai compris !
Base en fait c'est le composant base de données d'OOo, c'est pour ça qu'il faut tellement de choses en plus !

Ok, je sors (en plus il drache, c'est nickel)

J'ai simplement suggéré le fait qu'un ssh lancé 24h/24 ne soit pas forcément utile. Si il reste en France il pourrait par exemple ne le lancer que pendant les heures "normales" (exit les périodes de dodo), et de plus les planificateurs de tâches permettent de lancer ssh quand c'est nécessaire, en planifiant à l'avance donc.
Mais c'est vrai ça ne supprimera pas les attaques.

Pourquoi laisses-tu continuellement ton sshd ouvert ?
N'est-ce pas mieux de le lancer uniquement quand tu sais qu'il sera nécessaire (vu qu'en plus il semblerait que ce soit toi qui l'utiliseras...) ?

Mais c'est qui le plus fort ? L'éléphant ou l'hippopotame ?

Windows fonctionnera, mais sans interface graphique...
Est-ce-que ce mode là existe sur windows 2000/XP ? Toujours est-il que sur win 98 il est disponible.

Pour information, EXA est désormais dans le CVS d'X.org et sera donc intégré à la version 6.9/7.0 (les deux sortiront en même temps)
Les drivers sont en train d'être portés, cf le blog de Zack Rusin : http://www.kdedevelopers.org/node/view/1223(...)

Tu sais les changements qu'il y a dans LitePC ?
Tu ne te retrouves pas avec un windows normal derrière. Ce n'est plus le même logiciel qui se charge d'afficher le bureau par exemple.

À partir d'une certaine SP, windows 2000 propose l'outil "configurer les programmes par défaut".

et ?
KDE est """"équivalent"""" à certaines parties de windows.
windows c'est un noyau, une interface graphique...

- Afficher l'aide ?
- Permettre la personnalisation du navigateur ?
- Être utilisable comme composant dans toutes les autres applications

Regarde l'usage de khtml dans KDE... C'est pareil que IE dans windows

Comment lances-tu la commande "deltree c:\" depuis linux ?
Wine ? Dosemu ? Dosbox ?

Ils sont pas si cons les gens qui ont pensé à ça...
D'accord, ça marche pas en pratique, mais l'idée n'est pas si mauvaise.
Ils pourraient faire plus tordu, genre mettre des images difficiles à lire au lieu des boutons.

Mais derrière ça, y'a du code Javascript je suppose ? Il peut donc être intercepté lui aussi non ? (avec une faille du navigateur par exemple, ou un virus qui attaque IE)


Que faire pour vraiment augmenter la sécurité ? Leur idée ne marche pas (et est inaccessible aux handicapés par exemple). Le système habituel est dangereux aussi.

Les drivers n'implémentent pas l'extension... J'ai dit : "seuls les drivers NVidia l'acceptent sans trop broncher" !
Les drivers ATI font plus la gueule : ils accélèrent pas, ils plantouillent...

Seuls les drivers NVidia ont les options RenderAccel (je crois hein) et AllowGLXWithComposite !

Et j'en connais un qui lacherait peut être son LG3D ;)
Tssss...
Je suis partout, je suis nulle part (c'est ça la combine à Nanard, enfin bref)

LG3D est à mes yeux bien plus intéressant que metisse ! Metisse est un gestionnaire de fenêtres en 3D uniquement, alors que LG3D (Looking Glass pour ceux qui connaissent pas l'abbréviation) cible plus un environnement complet en 3D, avec applications en 3D notamment.
Puis LG3D est vraiment sympa au niveau code... Ça doit être l'effet Java :p


PS : vivement gcjx, qui sera intégré à gcc 4.1. Il supportera enfin les generics de Java 5, et on pourra alors s'attaquer au support des classes nécessaires à LG3D dans gcj. Enfin nous aurons moyen d'utiliser LG3D sans la machine virtuelle propriétaire de Sun derrière :)

Mais qu'est-ce qu'un MEP ?

L'extension Composite d'NVidia ???
C'est quoi cette blague ?
Composite est une extension standard de X.org, pas un truc propre à un driver ! Par contre, seuls les drivers propriétaires de NVidia la supportent sans trop broncher.

Bon, on va prendre effroyablement simple (toujours en python):
def truc (arg):
  if arg.
==> il propose quoi ton super EDI de la mort ? surtout si c'est dans le cas d'une librairie que tu développes !

Il me semble que tu n'as pas compris mon exemple.
vba ne gère pas ce genre de chose, par contre je ne connais pas asp.net
Reprenons mon exemple pour une petite explication :
import imp
plugins = {"truc": None, "muche": None}
for plugin in plugins.keys():
  plugins[plugin] = imp.load_source("", "%s.py" % plugin)
J'espère que tu connais des bases de python.
Le module imp sert à pouvoir jouer avec import de façon beaucoup plus libre : en effet, tu n'as pas à savoir ce que tu veux importer. Ça te permet par exemple de créer sans te fouler un système de plugins (qui sont alors sous forme de modules python)
Ici j'ai décidé de stocker ces plugins dans un dictionnaire nommé plugins. Les clés sont les noms des modules, et les valeurs les modules eux même.
Ensuite, j'importe chacun de ces modules pour l'insérer dans le dictionnaire.
Et maintenant, plugins["truc"] a quelles fonctions et propriétés disponibles à ton avis ?

Même moi je ne le sais pas si j'ai pas l'accès au fichier truc.py. Mais comment un EDI pourrait gérer ça ? Tu veux qu'il interprète le code ligne par ligne ? Tu tombes dans le risque que j'ai évoqué précédemment : un code buggué qui serait exécuté. Tu veux qu'il "comprenne" le code ? Il doit donc connaître tous les modules python standards, ainsi que leur utilité... Charmant programme en perspective !

J'ai sur ma machine un bot IRC développé en utilisant notamment ces facultés. Si tu souhaites en savoir plus, contacte moi sur #testbot2@freenode.net (nick : PieD). Je me ferai un plaisir de t'expliquer plus en détail (ou à n'importe qui d'ailleurs) ce genre de joie pythonesque :)