C'est vraiment pas clair, mais si comme je le pense tu as collé ton su au milieu des autres commandes dans un même script, c'est normal que « ça n'aille pas plus loin ». su ("Substitute User") est fait pour ouvrir un shell sous une identité donnée, par défaut root. Fais un logout dans ce shell et tu verras que ton script exécutera le reste de tes commandes (mais pas en root, cela va de soi).
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
* Tes données ne soient pas dans le cache ? (utiliser fflush())
* Ton programme « traitement » n'ait pas besoin d'avoir l'intégralité de tes résultats pour t'en fournir le bilan (typiquement le cas de sort) ?
J'ajouterais qu'inclure vi.size() directement dans la boucle n'est pas une bonne idée, car il faut réévaluer la méthode à chaque tour de boucle. Moi je préfère :
unsigned int x,y;
J'ai compilé mon kernel (2.6.11.7) en ne configurant quasi rien
Si tu as la flème de retrouver la config initiale de ton système, tu peux aller la chercher dans le répertoire "/boot". Tu copies ce fichier dans ton /home ou dans /tmp, histoire de laisser l'autre tranquille, tu lance un make xconfig (ou autre, selon tes goûts) et tu recharges la config à partir de ton fichier.
Pas de panique, c'est un incident assez fréquent. En général, le système fait son « checkdisk » tout seul. Il le fait même régulièrement au bout de 20 ou 30 démarrages. Quand le filesystem a été arrêté trop violement et qu'il peut y avoir des ambiguïtés, le système te demande de lancer la commande toi-même dans le cas où il y aurait des précautions spéciales à prendre.
# e2fsck /dev/hda1
pour « ext2 filesystem check », est la commande qui fait les vérifs et les réparations. « hda1 » est la partition à vérifier. Fais auparavant un
# mount
pour voir sur quelle est la partition racine ("/" et tous ses sous-répertoires). Passe le bon descripteur à la commande en fonction de ce que tu vois, à la place de /dev/hda1.
librairie ou bibliothèque c'est quoi la différence ?
Une librairie c'est une boutique qui vend notament des livres, des revues, des ouvrages en tout genres et qui peut accessoirement faire office de débit de tabac.
Une bibliothèque c'est avant tout une collection d'ouvrages. Il se trouve qu'en français, le terme intègre le préfixe biblio qui signifie « livre », et que l'on décline en ludothèque, vidéothèque, logithèque ou autre. C'est plus rare en anglais.
Ici, une bibliothèque est une collection de fonctions, et éventuellement de ressources en tous genres (icônes, objets divers, etc.) réunies dans le même fichier, et ce soit sous forme d'objets partagés (*.so), soit sous forme d'objets statiques (*.o) embarqués dans un fichier d'archive (*.a).
Après, pourquoi ne pas dire librairie dans ce cas la ?
Parce que c'est un contresens ! C'est un piège facile mais que l'on rencontre de plus en plus souvent, simplement parce que la plupart des gens ne maîtrisent pas leur propre langue, et qui n'a par conséquent aucune raison d'être « légalisé ».
Le pire exemple est encore le verbe « supporter » : C'est un terme violent en français qui se traduit par to stand en anglais, et comme ces notions existent dans les deux langues, cela induit des ambigüités. Et en plus, c'est vraiment très laid et désagréable à lire. Donc, s'il y a des gens qui se demandent comment traduire ce terme en français :
S'il s'agit d'apporter son appui à une cause ou une personne, on dit « soutenir ».
S'il s'agit de matériel informatique ou d'une configuration particulière, on peut utiliser « prendre en charge » ou (mieux) « reconnaître ».
S'il s'agit d'aide aux utilisateurs, on parlera d'« assistance » plutôt que de support technique ou autre.
Je ne comprends toujours pas pourquoi on ne peut pas faire un système de paquets générique pour toutes les distributions qui gèrerait les dépendances.
Concurrence (ou compétition, à la limite).
C'est pour les mêmes raisons qu'il existe Gnome et KDE en parallèle. On peut s'estimer heureux qu'il n'en existe que deux, mais en un sens, cela respecte quand même le droit à l'alternative.
Pour avoir bossé en intégration/déploiement (donc côté pas dev), j'ai compris que les utilisateurs (ceux qui compte donc) ont exactement l'avis inverse.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
J'ai comme l'impression que la toute puissance du développeur est de plus en plus néfaste pour l'utilisateur. Je me suis bien trouvé con le jour où j'ai dû expliquer l'intérêt de corba à un utilisateur : il n'en a rien à foutre des avantages de l'intégration multi-langages, de la visionunifiée des objets, et comme la configuration des ORB n'est pas unifiée, ben lui il a que des inconvénients.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.
Ton post est intéressant parce qu'il est inhabituel, mais franchement, je n'ai jamais vu un programmeur douter de l'intérêt des liens dynamiques. Evidement, il y a des cas où le tout statique présente des avantages, mais globalement, quel que soit le nom donné d'ailleurs, les bibliothèques dynamiques s'imposent à peu près partout.
Comme dit plus haut, l'idée générale est de ne pas à avoir à intégrer n fois le même code dans toutes les applications. Non seulement il y a des milliers de binaires en service sur un système, mais ils dépendent tous de routines de plus bas niveau. Si dix applications s'appuient sur dix bibliothèques qui elles-mêmes font appel à dix appels systèmes, tu te retrouves avec 1000 fois le même code. Les bibliothèques dynamiques ne sont pas seulement nécessaires du fait de la multiplication des binaires, mais surtout à cause du caractère exponentiel que présente une édition de liens purement statique, celui-ci étant dù aux dépendances en cascade.
Question 1 : je vois en gros l'interet du link dynamique (vraiment, de loin et en gros), mais les defauts me semble tellement nombreux qu'en fait, non, je vois pas. Les defauts sont notamment qu'on a aucune verif au moment de la compilation/link de la presence/absence des symboles, et que donc faut faire des tests intensif pour etre sur que sur tous les "codepath" de l'apli qu'il n'y'ait pas de relocation error
Non. Avec gcc en tout cas (et donc ld, par conséquent), il faut que tu spécifies à la compilation les bibliothèques impliquées avec l'option "-l", et éventuellement les répertoires dans lesquels elles se trouvent avec "-L". Toutefois, pour rendre la compilation facile, le compilateur peut faire ce travail pour toi envers les bibliothèques standard (stdio et compagnie). Tu peux inhiber ce comportement à l'aide des options « -nostdlib » et « -nodefaultlibs ».
$ man gcc
au chargement du .so, le systeme va voir qu'il connait deja un tata (cui de l'exe) et va donc utiliser ce symbole plutot que cui du so. Donc, notre so, au lieu d'appeler le tata qu'il contient va appeler celui de l'exe.
Non plus, car une fois résolus, les symboles disparaissent (donc en interne) car ils deviennent inutiles, mais surtout ton problème n'a absolument rien à voir avec le caractère dynamique de la gestion des bibliothèques :Si tu compiles un programmes avec une suite de « *.o » purement statiques, tu devras faire face au même problème si deux bibliothèques indépendantes ont décidé d'utiliser le même nom de fonction.
La plupart du temps, le problème ne se pose pas car les noms de symboles ne sont pas limités en longueur (ou en tout cas en tolère un très grand nombre), et les développeurs choisissent en général des noms suffisament explicites pour écarter toute ambigüité. Cependant, dans certains langages tel que le C++, on peut avoir des doubles-emplois. Pour éviter cela, soit les méthodes sont encapsulées dans une classe, dans le cas d'un langage orienté objet, soit les différentes entités sont déclarées au sein d'un namespace ou espace de nommage, que l'on peut décider d'utiliser implicitement au début d'un listing, soit explicitement en utilisant le nom du namespace comme préfixe au symbole que l'on souhaite invoquer.
Mais là encore, c'est totalement indépendant des systèmes de liaison dynamique.
Comme dit plus haut, cela se produit la plupart du temps parce que le logiciel ne peut ouvrir le /dev correspondant, et ce parce qu'un programme l'a déjà fait avant lui. Identifie-le, ferme-le et tout rentrera dans l'ordre.
Il arrive aussi que les droits sur le fichier changent spontanément. Mandriva est assez farceuse sur ce point. Elle fait un chown sur le fichier spécial qui correspond aux ressources que tu utilises, et oublie parfois de les remettre à la bonne place (spécialement si tu fais un halt impératif avant de lacher ta machine). Là encore, il suffit de remettre les bons droits mais je conçois que c'est pénible.
Je vais prendre le contrepied de tout le monde ici mais je dirais que le meilleur moyen d'apprendre, si tu as déjà fait un peu d'objet, et que tu veux en même temps te familiariser avec Unix, est d'abandonner d'emblée tout ce qui ressemble à Windows. KDevelop est un très bon produit, mais cela sert souvent de prothèse aux jeunes programmeurs qui ne savent pas développer sans assitance. D'où le dicton : "Un classique, c'est un livre que tout le monde veut avoir lu et que personne ne veut lire".
Moi je te conseille de tout faire en ligne de commande, non seulement parce qu'au final, tu gagnes en souplesse, en liberté et en puissance, mais aussi parce que tu seras capable de faire du développement tout-terrain, et qu'il ne te faudra pas systématiquement un bi-P4 Xeon 3,6 GHz pour écrire un "Hello world" à l'écran, et surtout parce qu'ainsi tu feras pleinement la différence entre ce qui est nécessaire et ce qui est superflu.
Commence déjà par faire des exercices bateau sur les objets, déclarer des classes, des methodes, etc, ensuite tu pourras choisir la bibliothèque graphique qui te plaît.
Qt est à la mode, mais si tu veux développer "à la VB" directement à partir des outils graphiques, je te recommande "glade". Ce logiciel a ceci d'intéressant que s'il est capable de générer le code correspondant à l'interface que tu as dessinée, il reste indépendant de l'environnement de développement que tu utilises.
Faire du Drag&Drop pour créer l'interface souhaitée et "remplir les trous" est certes très intuitif, et cela permet de comprendre rapidement comment fonctionnent les objets d'une manière grossière, mais c'est quand même prendre le problème à l'envers, et ce n'est pas une méthodologie à suivre pour apprendre.
J'ajouterais que c'est un débutant qui a visiblement lu un minimum les man pages et qui sait ce que sont les ./configure, make, make install et ldconfig. C'est quand même pas courant.
Attention, comme dit plus haut, l'auto-increment pallie une faiblesse de conception, car la requête s'appuie sur une clé artificielle générée juste pour l'occasion, et pas sur la valeur des données elles-mêmes.
En plus, cela place ta requête en échec si une ligne est supprimée, car le pas de une unité entre chaque ligne n'est plus respecté.
De plus, ce n'est valable que si l'on insère les entrées chronologiquement. Si par exemple l'administrateur insère dans la table des informations provenant de deux sources distinctes et successive (qui a dit des fichiers Excel ?), tu es bon pour te taper une renumérotation manuelle de toutes tes entrées. Au pire, tu extrais le contenu de ta table avec un « SELECT ... ORDER BY heure; » vers un fichier, et tu fais un script qui te numérote tes lignes, mais le problème reste entier : Tu es obligé d'exporter le système de garantie de la cohérence de ta base en dehors du SGBD, tu ne peux plus assurer celle-ci en temps réel et, pire que tout, tu ne peux pas empêcher quelqu'un d'insérer des données corrompues entre deux contrôles.
# Sois plus clair.
Posté par Obsidian . En réponse au message pas de su en bash ?. Évalué à 4.
Tu peux utiliser su -c pour lancer ledit shell en mode non-interactif et lui spécifier la commande à exécuter.
Mieux, tu peux utiliser sudo.
# Commençons par le début
Posté par Obsidian . En réponse au message Un pipeline, deux pipelines, trois pipelines.... Évalué à 4.
* Tes données ne soient pas dans le cache ? (utiliser fflush())
* Ton programme « traitement » n'ait pas besoin d'avoir l'intégralité de tes résultats pour t'en fournir le bilan (typiquement le cas de sort) ?
[^] # Re: et le nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 3.
[^] # Re: Faites vos jeux
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à -1.
http://linuxfr.org/2005/04/10/18697.html(...)
[^] # Re: Politique de grand papa
Posté par Obsidian . En réponse au journal [HS] politique : emplois. Évalué à 2.
Chomsky, c'est un diminutif pour chômeur ?
# Des indices ?
Posté par Obsidian . En réponse au message anjuta et les vector. Évalué à 3.
Commençons par le début (dans le contexte actuel) : Maîtrises-tu les templates ?
[^] # Re: petit exemple
Posté par Obsidian . En réponse au message anjuta et les vector. Évalué à 2.
unsigned int x,y;
for (x=0,y=vi.size();x<y;++x) ...
[^] # Re: Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à -1.
[^] # Re: Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 1.
# Bientôt un nouveau nom ?
Posté par Obsidian . En réponse à la dépêche Mandriva annonce l'acquisition des principaux actifs de Lycoris. Évalué à 10.
# La flème mène au coté obscur (... enfin cela dépend).
Posté par Obsidian . En réponse au message Impossible d'inscrire un module. Évalué à 3.
Si tu as la flème de retrouver la config initiale de ton système, tu peux aller la chercher dans le répertoire "/boot". Tu copies ce fichier dans ton /home ou dans /tmp, histoire de laisser l'autre tranquille, tu lance un make xconfig (ou autre, selon tes goûts) et tu recharges la config à partir de ton fichier.
[^] # Re: Filesystem check
Posté par Obsidian . En réponse au message Pb de boot sur RedHat !. Évalué à 2.
A noter toutefois que l'opération peut-être à répéter pour les différentes partitions Linux (celles montées sur /home, /var, etc.).
Cela peut-être une bonne idée de tout vérifier en une fois.
# Filesystem check
Posté par Obsidian . En réponse au message Pb de boot sur RedHat !. Évalué à 3.
# e2fsck /dev/hda1
pour « ext2 filesystem check », est la commande qui fait les vérifs et les réparations. « hda1 » est la partition à vérifier. Fais auparavant un
# mount
pour voir sur quelle est la partition racine ("/" et tous ses sous-répertoires). Passe le bon descripteur à la commande en fonction de ce que tu vois, à la place de /dev/hda1.
[^] # Re: Position des paramètres
Posté par Obsidian . En réponse au message 2 carte reseau.... Évalué à 2.
# Position des paramètres
Posté par Obsidian . En réponse au message 2 carte reseau.... Évalué à 2.
c'est "ifconfig eth1 10.0.0.1 netmask 255.0.0.0 up" qu'il faut écrire.
Après pour les fichiers de conf, il est possible qu'il te faille utiliser la MacAdress pour les différencier ...
[^] # Re: Library or not bibliothèque ?
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
?
s/Or/Hors/ ?
Une librairie c'est une boutique qui vend notament des livres, des revues, des ouvrages en tout genres et qui peut accessoirement faire office de débit de tabac.
Une bibliothèque c'est avant tout une collection d'ouvrages. Il se trouve qu'en français, le terme intègre le préfixe biblio qui signifie « livre », et que l'on décline en ludothèque, vidéothèque, logithèque ou autre. C'est plus rare en anglais.
Ici, une bibliothèque est une collection de fonctions, et éventuellement de ressources en tous genres (icônes, objets divers, etc.) réunies dans le même fichier, et ce soit sous forme d'objets partagés (*.so), soit sous forme d'objets statiques (*.o) embarqués dans un fichier d'archive (*.a).
Parce que c'est un contresens ! C'est un piège facile mais que l'on rencontre de plus en plus souvent, simplement parce que la plupart des gens ne maîtrisent pas leur propre langue, et qui n'a par conséquent aucune raison d'être « légalisé ».
Le pire exemple est encore le verbe « supporter » : C'est un terme violent en français qui se traduit par to stand en anglais, et comme ces notions existent dans les deux langues, cela induit des ambigüités. Et en plus, c'est vraiment très laid et désagréable à lire. Donc, s'il y a des gens qui se demandent comment traduire ce terme en français :
S'il s'agit d'apporter son appui à une cause ou une personne, on dit « soutenir ».
S'il s'agit de matériel informatique ou d'une configuration particulière, on peut utiliser « prendre en charge » ou (mieux) « reconnaître ».
S'il s'agit d'aide aux utilisateurs, on parlera d'« assistance » plutôt que de support technique ou autre.
[^] # Re: En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 2.
Concurrence (ou compétition, à la limite).
C'est pour les mêmes raisons qu'il existe Gnome et KDE en parallèle. On peut s'estimer heureux qu'il n'en existe que deux, mais en un sens, cela respecte quand même le droit à l'alternative.
[^] # Re: En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
Ca, en revanche, c'est vrai. D'ailleurs le seul programme que j'ai écrit pour Windows se passait complètement de bibliothèques. Cela ne veut pas dire pour autant qu'il était entièrement statique, mais qu'il faisait appel à des bibliothèques réputées être toutes fournies par le système. Moralité, un petit exécutable de 164Ko qui pouvait s'exécuter partout sans installation. Il a fait fureur pendant facilement deux ans sur logithèque point fr.
Ceci dit, c'est à ça que servent les installeurs style InstallShield sur Windows ou *.rpm/*.deb sous Gnu/Linux, parce que non seulement ils gèrent les bibliothèques associées, mais aussi tous les fichiers connexes (conf principalement), les dépendances, les mises à jour, et la redoutable base de registre sous Windows.
Faire le procès des bibliothèques partagées, c'est déplacer le problème. Aucun utilisateur ne devrait se trouver avec un *.exe seul sans ses dépendances, à moins de l'avoir piraté (dans ce cas, aucune vergogne), soit parce que le système n'est pas assez souple pour permettre un déploiement facile.
Ca c'est vrai aussi, mais je trouve que là encore le problème est ailleurs. La multiplication des langages de haut niveau et des couches d'abstractions sont autant de causes potentielles de panne et d'incompatibilité, et ce qui ne profite qu'au programmeur au moment du développement se paye au quotidien par une consommation de ressources excessives (le processeur doit traverser toutes les couches au moindre appel).
Ceci dit, là encore, les bibliothèques partagées sont les amies des utilisateurs comme des développeurs. On faisait déjà le procès des grands éditeurs dans les années 90 lorsque l'on a vu les systèmes d'expoitation et les logiciels les plus populaires occuper de plus en plus de place sur le disque (un ami m'a envoyé Windows 1.0 par mail :-) ). Maintenant imagine un peu que tous les logiciels soient statiques : L'équivalent d'un système d'exploitation entier dans chacune de tes applications. Un disque dur de 15To ne suffirait pas, et accessoirement ton OS ne servirait plus à rien. Avec des libs partagées, le code de ladite bibliothèque n'occupe qu'une seule fois sa place non seulement sur le disque, mais également en mémoire (mapping).
En plus, le code partagé se trouve même là où tu ne l'attends pas : Quand une application ouvre une fenêtre, c'est toujours la même et cela te paraît normal : C'est Windows (ou GTK/Qt sous Linux) qui s'occupe de la construire, pas l'application.
# En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 2.
Comme dit plus haut, l'idée générale est de ne pas à avoir à intégrer n fois le même code dans toutes les applications. Non seulement il y a des milliers de binaires en service sur un système, mais ils dépendent tous de routines de plus bas niveau. Si dix applications s'appuient sur dix bibliothèques qui elles-mêmes font appel à dix appels systèmes, tu te retrouves avec 1000 fois le même code. Les bibliothèques dynamiques ne sont pas seulement nécessaires du fait de la multiplication des binaires, mais surtout à cause du caractère exponentiel que présente une édition de liens purement statique, celui-ci étant dù aux dépendances en cascade.
Non. Avec gcc en tout cas (et donc ld, par conséquent), il faut que tu spécifies à la compilation les bibliothèques impliquées avec l'option "-l", et éventuellement les répertoires dans lesquels elles se trouvent avec "-L". Toutefois, pour rendre la compilation facile, le compilateur peut faire ce travail pour toi envers les bibliothèques standard (stdio et compagnie). Tu peux inhiber ce comportement à l'aide des options « -nostdlib » et « -nodefaultlibs ».
$ man gcc
Non plus, car une fois résolus, les symboles disparaissent (donc en interne) car ils deviennent inutiles, mais surtout ton problème n'a absolument rien à voir avec le caractère dynamique de la gestion des bibliothèques :Si tu compiles un programmes avec une suite de « *.o » purement statiques, tu devras faire face au même problème si deux bibliothèques indépendantes ont décidé d'utiliser le même nom de fonction.
La plupart du temps, le problème ne se pose pas car les noms de symboles ne sont pas limités en longueur (ou en tout cas en tolère un très grand nombre), et les développeurs choisissent en général des noms suffisament explicites pour écarter toute ambigüité. Cependant, dans certains langages tel que le C++, on peut avoir des doubles-emplois. Pour éviter cela, soit les méthodes sont encapsulées dans une classe, dans le cas d'un langage orienté objet, soit les différentes entités sont déclarées au sein d'un namespace ou espace de nommage, que l'on peut décider d'utiliser implicitement au début d'un listing, soit explicitement en utilisant le nom du namespace comme préfixe au symbole que l'on souhaite invoquer.
Mais là encore, c'est totalement indépendant des systèmes de liaison dynamique.
# /dev/dsp occupé ou problème de droit.
Posté par Obsidian . En réponse au message Pb d'écoute de radio en ligne. Évalué à 2.
Il arrive aussi que les droits sur le fichier changent spontanément. Mandriva est assez farceuse sur ce point. Elle fait un chown sur le fichier spécial qui correspond aux ressources que tu utilises, et oublie parfois de les remettre à la bonne place (spécialement si tu fais un halt impératif avant de lacher ta machine). Là encore, il suffit de remettre les bons droits mais je conçois que c'est pénible.
# Dive into
Posté par Obsidian . En réponse au message C++ sous linux débutants. Évalué à 3.
Moi je te conseille de tout faire en ligne de commande, non seulement parce qu'au final, tu gagnes en souplesse, en liberté et en puissance, mais aussi parce que tu seras capable de faire du développement tout-terrain, et qu'il ne te faudra pas systématiquement un bi-P4 Xeon 3,6 GHz pour écrire un "Hello world" à l'écran, et surtout parce qu'ainsi tu feras pleinement la différence entre ce qui est nécessaire et ce qui est superflu.
Commence déjà par faire des exercices bateau sur les objets, déclarer des classes, des methodes, etc, ensuite tu pourras choisir la bibliothèque graphique qui te plaît.
Qt est à la mode, mais si tu veux développer "à la VB" directement à partir des outils graphiques, je te recommande "glade". Ce logiciel a ceci d'intéressant que s'il est capable de générer le code correspondant à l'interface que tu as dessinée, il reste indépendant de l'environnement de développement que tu utilises.
Faire du Drag&Drop pour créer l'interface souhaitée et "remplir les trous" est certes très intuitif, et cela permet de comprendre rapidement comment fonctionnent les objets d'une manière grossière, mais c'est quand même prendre le problème à l'envers, et ce n'est pas une méthodologie à suivre pour apprendre.
[^] # Re: merci
Posté par Obsidian . En réponse au message C++ sous linux débutants. Évalué à 2.
# Et bientôt ...
Posté par Obsidian . En réponse au journal Monad, le shell selon Microsoft (MSH). Évalué à 10.
[^] # Re: Les dépendances
Posté par Obsidian . En réponse au message Installer sous linux. Évalué à 2.
[^] # Re: CA MARCHE !
Posté par Obsidian . En réponse au message [MySQL] un GROUP BY un peu spécial. Évalué à 2.
En plus, cela place ta requête en échec si une ligne est supprimée, car le pas de une unité entre chaque ligne n'est plus respecté.
De plus, ce n'est valable que si l'on insère les entrées chronologiquement. Si par exemple l'administrateur insère dans la table des informations provenant de deux sources distinctes et successive (qui a dit des fichiers Excel ?), tu es bon pour te taper une renumérotation manuelle de toutes tes entrées. Au pire, tu extrais le contenu de ta table avec un « SELECT ... ORDER BY heure; » vers un fichier, et tu fais un script qui te numérote tes lignes, mais le problème reste entier : Tu es obligé d'exporter le système de garantie de la cohérence de ta base en dehors du SGBD, tu ne peux plus assurer celle-ci en temps réel et, pire que tout, tu ne peux pas empêcher quelqu'un d'insérer des données corrompues entre deux contrôles.
Pas terrible.