Re: (vendredi] windows server sous virtualbox
Bonjour, Le vendredi 04 octobre 2013 à 7:59, Stéphane GARGOLY a écrit : virtualbox + windows server 2012 c'est stable ? Bien, pour peu que tu utilises Wheezy (stable), à priori, il ne devrait pas avoir de problème. ;-) Attention, le terme « stable » est ambigu ! Dans Debian, « stable » ne veut pas dire que les logiciels vont tous fonctionner éternellement sans panne, ça veut dire que les versions des logiciels ne vont pas évoluer pendant la durée de vie de la branche. Ce qui n'empêche pas le système d'être également stable (dans le sens où il fonctionne sans panne) selon les logiciels utilisés¹. S'agissant du reste (là où tu répondais à la question VirtualBox / Windows), j'approuve ! ¹ Comme on est vendredi, je me permets : - Amarok 2 sous KDE 4 en est un bon contre-exemple ! - Un système où l'utilisateur utilise VI sera plus stable qu'un système où l'utilisateur utilise Emacs ! - (écrivez votre propre troll ici) Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20131004082429.ga13...@sebian.nob900.homeip.net
Re: [hs] Cible et lien symbolique : comportement différent ?
Le vendredi 04 octobre 2013 à 0:29, Alexandre Hoïde a écrit :
Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).
Je viens de tester, URxvt interprète :
- toutes les lignes qui correspondent à son nom de ressource interne
(« URxvt »),
- toutes les lignes dont le nom de ressource correspond au nom du fichier
par lequel il a été appelé.
Test rapide :
ln -s /usr/bin/urxvt /tmp/toto
/tmp/toto
Toutes les lignes du fichier Xresources correspondant à « toto » seront
interprétées.
Ça te permet de faire une gestion de « profils » à pas cher !
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20131004083508.gb13...@sebian.nob900.homeip.net
Re: [hs][résolu] Cible et lien symbolique : comportement différent ?
On Fri, Oct 04, 2013 at 10:35:08AM +0200, Sébastien NOBILI wrote: Je viens de tester, URxvt interprète : - toutes les lignes qui correspondent à son nom de ressource interne (« URxvt »), - toutes les lignes dont le nom de ressource correspond au nom du fichier par lequel il a été appelé. Ah oui ! Bravo pour l'esprit de déduction et merci Seb. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20131004100722.ga4...@gmail.com
Re: [hs] Cible et lien symbolique : comportement différent ?
On 04/10/2013 00:29, Alexandre Hoïde wrote:
Salut à vous de la liste,
Un petit truc m'échappe et, à vot' bon coeur, j'aimerais mieux comprendre.
J'ai :
/usr/bin/x-terminal-emulator@ \
- /etc/alternatives/x-terminal-emulator@ \
- /usr/bin/urxvt*
Donc, si je ne m'abuse, lancer urxvt à l'aide des liens symboliques ou
directement du fichier /usr/bin/urxvt devrait être strictement équivalent,
non ?! Or, j'ai un petit ~/.Xresources :
!--
URxvt*.transparent: true
URxvt*.shading: 100
URxvt.scrollBar:false
URxvt*internalborder: 6
urxvt*foreground: #f2f2f2
urxvt*background: #101010
!--
Où l'on voit que le nom de la ressource est mal orthographié sur les
deux dernières entrées (urxvt au lieu de URxvt).
Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).
En corrigeant mon .Xresources s/ur/UR tout rentre dans l'ordre... mais cet
ordre est soudain devenu obscur à mes yeux.
PS Expérience faite sur une Sid à jour avec Awesome. Les liens symboliques ont
été générés par «update-alternatives --config x-terminal-emulator».
Bonjour
A titre informatif, un programme peut accéder par la pile Linux (en C
par args[0]) à la commande par lequel il est lancé. Autrement dit le
programme sait s'il a été lancé par un alias, un lien symbolique ou
directement. Reste à savoir pourquoi urxvt se comporte différemment
suivant que la ligne de commande contient urxvt ou x-terminal-emulator.
Je n'ai aucune compétence sur ce point.
Cordialement
Philippe Deleval
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/524e9690.9040...@wanadoo.fr
Re: [hs] Cible et lien symbolique : comportement différent ?
Philippe Deleval wrote:
On 04/10/2013 00:29, Alexandre Hoïde wrote:
Salut à vous de la liste,
Un petit truc m'échappe et, à vot' bon coeur, j'aimerais mieux
comprendre.
J'ai :
/usr/bin/x-terminal-emulator@ \
- /etc/alternatives/x-terminal-emulator@ \
- /usr/bin/urxvt*
Donc, si je ne m'abuse, lancer urxvt à l'aide des liens symboliques ou
directement du fichier /usr/bin/urxvt devrait être strictement
équivalent,
non ?! Or, j'ai un petit ~/.Xresources :
!--
URxvt*.transparent: true
URxvt*.shading: 100
URxvt.scrollBar:false
URxvt*internalborder: 6
urxvt*foreground: #f2f2f2
urxvt*background: #101010
!--
Où l'on voit que le nom de la ressource est mal orthographié sur les
deux dernières entrées (urxvt au lieu de URxvt).
Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières
lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).
En corrigeant mon .Xresources s/ur/UR tout rentre dans l'ordre... mais
cet
ordre est soudain devenu obscur à mes yeux.
PS Expérience faite sur une Sid à jour avec Awesome. Les liens
symboliques ont
été générés par «update-alternatives --config x-terminal-emulator».
Bonjour
A titre informatif, un programme peut accéder par la pile Linux (en C
par args[0]) à la commande par lequel il est lancé. Autrement dit le
programme sait s'il a été lancé par un alias, un lien symbolique ou
directement.
Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai
pu constater que cela ne fonctionnait pas... et je pense que c'est à la
discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où
toute la ligne de commande, arguments compris, se trouvait dans argv[0]
et un autre qui omettait le nom de la commande et dont argv[0] contenait
directement le premier argument !
Cordialement,
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/524e9d7b.5030...@systella.fr
Re: [hs] Cible et lien symbolique : comportement différent ?
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote: Philippe Deleval wrote: A titre informatif, un programme peut accéder par la pile Linux (en C par args[0]) à la commande par lequel il est lancé. Autrement dit le programme sait s'il a été lancé par un alias, un lien symbolique ou directement. Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai pu constater que cela ne fonctionnait pas... et je pense que c'est à la discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où toute la ligne de commande, arguments compris, se trouvait dans argv[0] et un autre qui omettait le nom de la commande et dont argv[0] contenait directement le premier argument ! Oui, dans mon désir que la transparence référentielle s'impose sur terre comme aux cieux, j'avais omis d'intégrer ces détails impurs à ma réflexion. Merci à vous deux pour ces précisions. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20131004131839.ga3...@gmail.com
Re: [hs] Cible et lien symbolique : comportement différent ?
[Je réponds au précédent mais j’ai perdu le courriel…] Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit : On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote: […] Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai pu constater que cela ne fonctionnait pas... et je pense que c'est à la discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où toute la ligne de commande, arguments compris, se trouvait dans argv[0] et un autre qui omettait le nom de la commande et dont argv[0] contenait directement le premier argument ! C’est un standard du langage C¹. Mauvais compilateur/libc, changer compilateur/libc. ¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du PDF). -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/1447101.Bu91WtKv2U@earendil
Re: [hs] Cible et lien symbolique : comportement différent ?
Le vendredi 4 octobre 2013 15:58:10 Sylvain L. Sauvage a écrit : […] C’est un standard du langage C¹. Mauvais compilateur/libc, changer compilateur/libc. ¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du PDF). Oh, et si quatorze ans, ça vous paraît trop jeune comme standard, c’est comme ça depuis au moins l’ANSI C (1988) : http://flash-gordon.me.uk/ansi.c.txt (même section, mêmes mots). -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/86310122.jGYc6ENvrQ@earendil
Re: [hs] Cible et lien symbolique : comportement différent ?
Sylvain L. Sauvage wrote: [Je réponds au précédent mais j’ai perdu le courriel…] Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit : On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote: […] Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai pu constater que cela ne fonctionnait pas... et je pense que c'est à la discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où toute la ligne de commande, arguments compris, se trouvait dans argv[0] et un autre qui omettait le nom de la commande et dont argv[0] contenait directement le premier argument ! C’est un standard du langage C¹. Mauvais compilateur/libc, changer compilateur/libc. ¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du PDF). Le compilo est un gcc récent avec un linux embarqué sur je ne sais plus quelle architecture. Et la libc était une eglibc des familles. D'un autre côté, je suis assez d'accord avec toi, c'est une très mauvaise libc :-P Entre-nous, c'est le shell qui empile ça grçace à un appel de la libc avant l'appel au main() (dans le cas du C). Si le shell décide de tout mettre dans argv[0] parce que ça lui fait plaisir, je ne vois pas trop ce que le compilo pourrait faire... Cordialement, JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/524ecac1.8070...@systella.fr
Re: [hs] Cible et lien symbolique : comportement différent ?
Le 04/10/2013 16:03, BERTRAND Joël a écrit : Sylvain L. Sauvage wrote: [Je réponds au précédent mais j’ai perdu le courriel…] Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit : On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote: […] Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai pu constater que cela ne fonctionnait pas... et je pense que c'est à la discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où toute la ligne de commande, arguments compris, se trouvait dans argv[0] et un autre qui omettait le nom de la commande et dont argv[0] contenait directement le premier argument ! C’est un standard du langage C¹. Mauvais compilateur/libc, changer compilateur/libc. ¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du PDF). Le compilo est un gcc récent avec un linux embarqué sur je ne sais plus quelle architecture. Et la libc était une eglibc des familles. D'un autre côté, je suis assez d'accord avec toi, c'est une très mauvaise libc :-P Entre-nous, c'est le shell qui empile ça grçace à un appel de la libc avant l'appel au main() (dans le cas du C). Si le shell décide de tout mettre dans argv[0] parce que ça lui fait plaisir, je ne vois pas trop ce que le compilo pourrait faire... Cordialement, JKB Tu dois donc avoir un C free-standing, plutôt qu'un C hosted. Dans ce cas il n'y a de fait pas de libc, mais une lib qui n'implémente que partiellement les fonctionalités de la libc. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/524ee8eb.5070...@rail.eu.org
Virtalbox windows server 2012
Bonjour, En bts Informatique, j'attaque la partie windows server 2012. Etant sous Debian mon formateur me propose de faire tourner windows server 2012 sous Virtual box. Cela vous semble faisable ? Quelle puissance est necessaire pour faire tourner corectement l'ensemble ? J'ai un AMD Athlon(tm) II X3 455 Processor 800.000 MH avec 8 Go de RAM -- Frédéric F1sxo -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20131003135342.ga17...@zulian.fr
Problème redémarrage MySql
Bonsoir, il existe vraisemblablement un problème de redémarrage de mysql sur Debian Squeeze Wheezy, ça fait plusieurs fois que je n'arrive pas à redémarrer sous différentes configurations, et je n'ai trouvé aucune réponse adéquate pour résoudre cet inconvénient sur Internet : Reloading MySQL database server: mysqld/usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/var/run/ mysqld/mysqld.sock' (2)' Check that mysqld is running and that the socket: '/var/run/mysqld/ mysqld.sock' exists! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/3a964685-2ee8-46b1-bea0-c8f9466b9...@worldonline.fr
Re: Problème redémarrage MySql
Bonsoir, As-tu la socket mysqld.sock dans le répertoire /var/run/mysqld ? Vérifie les droits sur cette socket (ils doivent être en rwx pour tout le monde, propriétaire mysql, groupe mysql). Si le fichier n'existe pas applique ceci: killall mysqld (tu fera attention car la commande tue tout les processus qui utilise mysqld) Puis /etc/init.d/mysqld restart Aussi vérifie si tu n'as rien changé dans le fichier de configuration /etc/mysql/my.cnf concernant la variable socket et le port d'écoute (tu as des exemples dans /usr/share/doc/mysql.). Si tu as effectué des modifications, regarde aussi si les modifications ont été répercutées sur le fichier /etc/mysql/debian.cnf. En espérant que ça te débloque un peu ... Le 4 oct. 2013 21:29, Philippe Gras ph.g...@worldonline.fr a écrit : Bonsoir, il existe vraisemblablement un problème de redémarrage de mysql sur Debian Squeeze Wheezy, ça fait plusieurs fois que je n'arrive pas à redémarrer sous différentes configurations, et je n'ai trouvé aucune réponse adéquate pour résoudre cet inconvénient sur Internet : Reloading MySQL database server: mysqld/usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/**FrenchListshttp://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-REQUEST@**lists.debian.orgdebian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/**3A964685-2EE8-46B1-BEA0-** c8f9466b9...@worldonline.frhttp://lists.debian.org/3a964685-2ee8-46b1-bea0-c8f9466b9...@worldonline.fr
