web123 a écrit 84 commentaires

Y a deux choses à distinguer. Les programmes fournis pas Mdk et les programmes developpé par Mdk (drakconf, etc...). Il me semble que Mdk ne fait que du GPL (sauf la wmf).

Ben moi. D'ailleur j'ai cru que mobilix traitait de gros PDA qui étaient tombés dans une potion magique à la naissance et qui consommait 3 sangliers par jours.

6 mois, çà semble une durée suffisante pour redresser la barre. Il faut espérer que l'image de Mandrake n'a pas pris un coup et que les boîte ne soient pas rétissantes à acheter du Mdk.

çà laisse aussi le temps au gouvernement de faire un contract pour aider une boîte informatique française et ne pas être dépendant d'un OS géré par une boîte étrangère. Je ne parle pas d'une aide mais d'un contrat gagnant-gagnant.

Je répondais à :
- "que les options de debug avec gcc"
Mais tu as évidement raison. Surtout si le programme utilise un truc comme dmalloc avec toutes les actions d'activées.

On ne le dit pas assez :
- "C'est dans les applications et dans leur exploitation au quotidien que doivent être portés les efforts pour obtenir une bonne sécurité."

Il y a aussi un commentaire très intéressant sur systrace :
- "La restriction des appels systèmes par application (cf systrace) nous semble une bonne chose utilisable par tous les administrateurs Unix. L'escalade des privilèges (qui ont été ajoutés à systrace) est plus dangereuse"

Non.
les infos de debug sont mise à la fin de l'executable. l'executable est chargé à la demande. Si tu utilises que 10 ko d'un exe de 10 Mo, il n'y a que 10 ko de chargé/lue. En utilisation normal, les infos de debug ne sont jamais chargées/lues.
La librairie C fait plus d'un Mo et il n'y a que les portions utilisées/demandées qui sont chargées.

l'option -g2 ne change pas l'exécutable elle ajoute des info. Par contre, utilisée avec -O2 par exemple il peut avoir quelques effets indésirables lors d'un debuguage. Exemple :
void toto(void) {
int i ;
int j ;
for(i = 1; i++ ; i < 10) { j = i ; }
printf("toto\n") ;
}

L'optimisateur peut décider de ne pas faire la boucle for() car elle ne fait rien (elle change la valeur de j qui n'est jamais utilisée. Y a encore une quinzaine d'autre cas qui rendent le comportement en debug bizarre.

> Au fait dans combien de langues Windows est-il disponible ?
Je veut pas dire de bien de MS mais c'est un domaine où windows a toujours été bien positionné (surtout si on compare avec les unix commerciaux).

Faut rapeller que cette solution n'est pas standard. Çà ne marche qu'avec gcc. D'ailleur tout les compilos fournissent cette "feature" non standard. Le C++ permet de le faire de façon standard.

gdm lance X avec comme client un autre gdm. Sinon, la fenêtre de login, c'est quoi ?

> L'appel de fonction C++ ne marchant pas depuis un programme compilé par un compilateur uniquement C.

J'ai regardé le binding qt :
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/(...)

On peut réaliser des appels de fonction généré par un compilateur c++ depuis un compilateur C. C'est un peu moche, mais si çà marche :
exemple :

-- toto.c -- : (compilé avec un compilateur c++)

#include <toto.hh> // du c++ qui ne peut pas passer avec un compilo C
extern "C" {
#include <toto.h> // du C
}
t_toto * new_toto(void){
return (t_toto *) new toto(); // c'est du c++
}

-- toto.hh --
class toto{
public:
toto() ;
};

-- toto.h --
typedef struct { int dummy; } t_toto; # Argh...


Pour l'utilisation :
-- test.c --
include "toto.h"
void test(void){
t_toto * titi ;
titi = toto() ;
}

C'est moche car on fait croire au compilateur C que la fonction toto() a été compilée avec un compilateur C. Alors que ce n'est pas le cas. En c++, il y a la surchage, "int toto(int)" est différent de "int toto(long)" et peuvent cohabiter. L'édition de lien C va moins loin et ne peut distinguer "int toto(int)" et "int toto(long)". les deux fonctions ne peuvent cohabiter.

Mais çà marche.

Sinon en regardant le binding, c'est pas très existant. Entre autre les 1, 2, 3 ajoutés à la fin des noms de fonction car la surcharge n'est pas permise, les types qui sont totalement opaque, voir ici par exemple (çà doit être un enfer pour le debuggage) :
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebindings/qtc(...)

Pour un développeur C, il est plus intéressant d'apprendre le C++ que d'utiliser çà.

> et ca je pense que ca marche en pure C non ?
ben non.

[web123@gloup tmp]$ cat main.c
#include <stdio.h>
static int dummy_init(void) {
printf("dummy here\n");
}
static int _test_dummy = dummy_init();
int main(int argc, char** argv) {
printf("main here\n");
return 0;
}
[web123@gloup tmp]$ g++ main.c
[web123@one tmp]$ ./a.out
dummy here
main here
[web123@gloup tmp]$ gcc main.c
main.c:5: initializer element is not constant
[web123@gloup tmp]$

Corrige moi si je dis une connerie car je ne connais pas très bien KDE.
Pour le binding des language il me semble que c'est dcop qui fait le gros du boulot et evite d'avoir les problème de linkage C++ C (l'appel de fonction C++ depuis du C). dcop est un serveur et perl, par exemple, se connect à ce serveur et demande l'ouverture d'un fenêtre, ajouter un menu, etc...

C'est comme çà que çà fonctionne ?

J'avais oublié qu'on pouvait faire du C avec un compilateur C++. L'appel de fonction C++ ne marchant pas depuis un programme compilé par un compilateur uniquement C. De même les objet statiques peuvent exécuter du code avant la fonction main() ce qui n'est pas possible en "pure" C.

Çà ne peut pas marcher car il faut relancer X11. Pour relancer X11, il faut tuer gdm qui a récupéré ton login. A moins de stocker des infos temporaires dans un fichier ou de les envoyer au gdm père. Afin, pour les terminaux c'est encore plus problématique (même si c'est sous GNU/Linux). gdm n'étant pas le père du serveur. Le process gdm doit alors "dire" à l'autre machine de relancer X11.

> ils sont "automatiquement" generes pas un script
Tu as un lien pour information.

> un binding C++->C
?!
Convertir du c++ en C je le conçois facilement. Par contre le binding d'une librairie vraiment orienté objet...
Tu as un exemple ?

> Faux.
Désolé.
Même les librairies en language C posent problèmes :
http://www.gerbil.org/~yacc/gnome-language-bindings/gnome-language-(...)

J'image que c'est plus difficile pour le C++. Surtout que celà ne fesait pas parti des objectifs initiaux de KDE.

> Il y a même un outil en ligne de commande, dcop
A ma connaissance il n'y a pas d'outil en ligne de commande. Sinon y a bonobo qui permet le "contrôle à distance" et il existe des bindings pour perl et python (au moins).

Je recommence.
Prenons un exemple.
J'installe 100 poste sous linux. Je ne veux pas pour des raisons évidente que les utilisateur est le compte root. En tant qu'admin, je ne veux pas être dérangé pour un changement de résolution (virtualdesktop).
En effet, certain poste mon être pour des personnes qui ont une vue moyen et veulent du 800x600 en 17 pouce, d'autre aime le 1600x1200, etc...
La solution de ne pas lancé gdm au boot n'est pas bonne. On ne peut demander à des utilisateur moyen qui sont habitués à du tout graphique de se logguer en mode texte puis lancer X11.

J'ai quoi comme solution ? mettre Xconfigure avec le suid bit. L'utilisateur le lance dans un console qui sa session et se logue à nouveau. Je lui donne un moyen de "niquer" la conf.

C'est un des problème d'X11. la taille du bureau virtuel est fixé par l'administrateur et non par l'utilisateur.

Pour évaluer cette fonctionnalité, il ne faut pas penser à son PC perso. Quand t'es en entreprise, on te file un PC sous windows et tu peux changer de résolution sans demander un compte admin, sans déranger l'admin, sans changer la configuration de celui qui bosse aussi parfois sur ce PC. Certains supportes le 1600x1200, d'autre n'y vois rien, etc...
Pour mon PC "à la maison" c'est vrai que j'en ai à foutre.

Je ne domande pas de remplacer le fameux <ctrl><alt><+> ou <-> !

> Si, en définissant plusieurs Layout dans le fichier de config, ensuite tu utilise l'option -layout pour choisir celui que tu veut...

Çà marche aussi si xdm est lancé ?
Non.

> .net/c# va accèlerer le dvpt de Gnome
Gnome c'est un framework. Gnome permet d'avoir des bindings (écrire des applis gnome avec d'autre language que le C). C# sera un binding suplémentaire. Les librairies de base de gnome (gconf, gnome-vfs, bonobo, gnome-xml, etc...) ne seront probablement jamais écritent en C#.

> j'ai l'impression que c'est pas bientôt fini -_-.
Çà avance bien :
http://www.linuxworldexpo.com/linuxworldny03/V33/press.cvn?id=11&am(...)

> la possibilité de faire cohabiter harmonieusement les composants des diffèrents bureaux

Les composant GNOME et KDE peuvent être utilisé pour d'autre projet. Par contre, il y a une incompatibilité en KDE et GNOME. KDE c'est uniquement C++ alors que GNOME est multi-language. KDE peut facilement récupérer les lib GNOME mais l'inverse n'est pas possible. Du moins si l'objectif de GNOME est de rester indépendant du language.

> ça risque de troller pas mal...
Et tu as pris trop de risque là :-)

> Finalement MDI se rends compte qu'utiliser un langage orienté objet avait quelques avantages par rapport au C

L'utilisation de C sous GNOME est pour permettre les bindings. Et il en existe plein sous GNOME/GTK (php, perl, python, java, bientôt C#, etc...). Les bindings sont beaucoup plus difficile à réalisé avec des librairies C++ (parfois impossible pour certain language).

Plus important que le desktop, GNOME et KDE permet de faire de bonne appli :
- galeon
- evolution
- kmail
- kdevelopper
- gnucash
- etc...

Si tu utilises une de ces applis, tu utilise GNOME ou KDE (même sous fluxbox).

> dans un genre de "base de registre"
Ben c'est une bonne idée cette "base de registre". Çà évite les 3 000 fichiers de configurations avec des formats différents. Depuis qu'il y a gconf-editor, on a un outil générique d'édition. Çà facilite énormément d'écriture d'application qui doivent stocker des données de configuration, etc...
Enfin çà offre un moyen pour que plusieurs applis accèdent en lecture/écriture a des données de configuration sans tout "niquer".

> exactement comme la base de registre Windows
Techniquement, çà n'a rien à voir. C'est basé sur xml et il y a plusieurs fichiers (voir par exemple /etc/gconf/ .
Enfin, les données par utilisateur sont stockés dans $HOME/.gconf/ .
çà n'a définitivement rien à voir. Ou alors mysql c'est "exactement comme la base de registre Windows" car çà stocke des données.

> cette option n'encombre pas le gnome-panel...
essais "gnome-theme-properties" et ajoute un bouton du ton gnome-panel.