Si c'est à deux, et si c'est simplement pour éviter de se marcher sur les pieds, tu peux essayer d'activer les mandatory locks sur ton système de fichiers.
Ainsi, si le logiciel de lecture a le bon goût de poser un verrou sur ton fichier, celui-ci sera en lecture seule pour les autres, voire inaccessible, le temps de la session.
C'est probablement très bête mais ton combiné clavier-souris sans fil a-t-il déjà fonctionné (notamment sur un autre O.S. si tu en es équipé) ?
Parce que le plus chiant avec les sans-fil, c'est de faire communiquer le récepteur et les périphs. J'avais déjà eu le problème chez une collègue avec une solution Logitech, je crois bien. Systématiquement, le clavier ou la souris, mais pas les deux.
Pour le reste, si ton engin fonctionne en USB, à moins d'avoir un clavier TRES spécial, il ne devrait pas avoir besoin de pilote particulier.
Je voulais dire par là que lancer un "Set-Cookie" avec un identifiant et un hash mixé à une clé secrète, c'est quand même à la portée de tout le monde. Ce n'était pas une démonstration de performance.
Le truc, c'est que c'est tellement courant qu'en principe, quand on en arrive là, on utilise la première technologie web venue. En l'occurence, c'était moins lourd de réécrire le peu dont j'avais besoin plutôt que d'assimiler et d'inclure dans le projet un module dédié.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
Je suis intéressé par votre proposition d'alternatives à Java/ Tomcat pour une application de gestion commerciale.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
Ca ne change rien. Mon commentaire n'était pas un pamphlet contre les mainframes, bien au contraire. Les applications qui y ont été développées, spécialement sur minis tels que les AS/400, ont perduré justement parce qu'elles étaient stables, rapides et efficaces. C'est pourquoi, jusqu'au début des années 2000, on a remplacé les terminaux par des PC émulant un 3270 ou assimilé pour perpétuer le service, plutôt que de réécrire l'application en local.
Il n'empêche que je ne placerai pas l'âge de gloire des mainframes à la fin des années 80. A cette époque, les terminaux proprios commençaient réellement à disparaître au profit des ordinateurs de bureaux et, parallèlement, le grand public avait déjà commencé (depuis le début des mêmes années 80) à goûter à la micro-informatique personnelle.
Je ne vois pas où il y a réécriture de l'histoire là-dedans.
Il y a une vingtaine d'année IBM était au faîte de sa puissance
J'aime bien ce goût raffiné pour le cynisme subtil : la liaison discrète du mot "faîte" vers le Wiktionnaire. Cela donne une idée du niveau de culture présumé que l'on attribue aux moules gallo-linuxéistes (qui, au passage, ne sauraient pas non plus se servir d'un dictionnaire).
Ensuite, il y a vingt ans, nous étions fin 1987. Ce n'était plus l'heure de gloire des mainframes mais au contraire celle de l'ascension en force des ordinateurs personnels 8 et 16 bits, avant même que, avec la chute progressive du prix du PC et l'explosion des réseaux locaux, on ne repasse justement à une architecture centralisée avec des serveurs.
Justement, ceux-ci ne remplissent plus que rarement leur rôle premier en entreprise. Si nous utilisons encore des batteries de serveurs accessibles avec des thin clients, pour la plupart des compagnies aujourd'hui, un serveur, c'est un dépôt de fichiers, généralement en SMB, sous Windows, avec une politique de licence d'accès client (CAL) aussi onéreuse que scandaleuse. Bref : les inconvénients de l'infrastructure sans les avantages (et sans le plaisir que pouvait apporter le métier à l'époque).
Sortir du moule propriétaire et mesurer une économie de 3 millions d'euros par an, c'est évidemment remarquable. Maintenant, est-ce que Tomcat-Java est un choix aussi évident qu'il en a l'air ? l'avenir nous le dira. Je ne pense pas qu'une technologie aussi lourde et aussi évolutive à la fois puisse être pérenne pendant vingt ans sans intervention. D'une manière générale, Java c'est bien, mais c'est un langage plus conçu pour les programmeurs que pour ses utilisateurs, à mon goût.
Gageons que cet article sera le guide de ce qu'il faut faire pour fermer cette (sombre) page de l'informatique.
Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.
J'ajouterais qu'il reste largement moins contraingnant de ne PAS faire de logiciel propriétaire, aussi bien pour l'auteur que pour ses utilisateurs. De telles contraintes se rencontrent en général dans trois cas :
1) L'application est développée par un éditeur professionnel pour le compte d'un client précis, par contrat, avec protection par dongle, etc. Cela se chiffre en général en dizaines de milliers d'euros au minimum.
2) L'application a une utilité mais le code est vraiment trop sale pour être publié en l'état.
3) Dans 95% des cas, l'application est développée par un programmeur débutant ou par quelqu'un dont ce n'est pas intrinsèquement le métier ou la vocation. On a réussi à écrire en entier un petit produit, on est fier de son travail et on ne veut surtout pas se faire piller. Le problème restant que, bien souvent, il n'y a en fait rien à piller.
Si en plus, il faut signer des accords de non-divulgation et mettre en place des choses très contraignantes du côté de l'utilisateur, celui-ci ne l'utilisera jamais. L'application sera alors utilisé par son concepteur, par deux ou trois proches et c'est tout. Elle va ensuite tomber dans l'oubli parce que le développeur exclusif n'aura plus le temps de s'en occuper, et enfin devenir obsolète. Bilan : de l'amertume et du temps perdu pour tout le monde.
Enfin, sache qu'il n'est pour ainsi dire plus possible du tout de faire de l'argent avec une application écrite dans son garage. Sans avoir vu l'application elle-même, je suis prêt à parier qu'elle existe déjà en cherchant un peu. Ensuite, non seulement on trouve une floppée d'outils en ligne sur le Net, mais les gens piratent à tour de bras. Paradoxe : ce sont les libristes, ceux qui à priori paient le moins souvent pour un logiciel, qui sont le plus attachés au respect d'une licence. Je pense que la majorité des personnes ici présentes n'ont pas le moindre winzip pirate sur leur disque.
Penser alors "faire éventuellement de l'argent" en vendant l'application si l'envie vous en prend, c'est être très naïf. On baigne dans un océan numérique à mille lieues de ce qui existait il y a encore quinze ans, où l'on apprenait l'existence d'applications utiles par le bouche à oreille et où l'on patientait deux semaines pour rencontrer "la personne qui l'avait" pour lui filer une disquette et attendre qu'elle nous la rende chargée de sa précieuse cargaison, comme un gamin à la veille de Noël.
Un logiciel, c'est comme un enfant : on le protège au tout début mais après il faut le laisser vivre sa vie et rencontrer du monde si l'on veut qu'il se développe correctement !:-)
Donc, le meilleur conseil que je puisse te donner : fais deux branches, une entièrement libre, l'autre éventuellement propriétaire (en commençant par la libre). Accepte le fait que le contenu de ta première branche soit public et le reste ad vitam æternam. Place-le sous licence GPL et laisse les gens modifier le code s'il le souhaite.
Si les gens ne sont pas pris en otage et peuvent avoir confiance en l'application qu'ils utilisent, alors le logiciel deviendra populaire, et les gens qui gagnent un salaire raisonnable pourront alors s'offrir le luxe d'acquérir une version propriétaire, full-featured, avec un minimum de documentation et d'assistance en cas de problème. A prévoir nécessairement si tu vends ton produit, si ta philosophie est "raque, démerde-toi tout seul et surtout n'essaie pas de voir comment j'ai fait", il est clair que tu as perdu d'avance.
A priori pas sur un serveur Samba, mais, pour autant que je me souvienne, les licences pour serveurs Windows sont vendues en te concédant un nombre ridicule de connexions forfaitaires, après quoi il te faut acheter de nouvelles licences de connexion, attribuées soit à un utilisateur (une seule personne peut se connecter de partout), soit à une machine (n'importe qui peut se connecter, mais seulement depuis une machine donnée).
C'est parce que ton expression régulière est incomplète. Essaie à la place d'utiliser la commande que je t'ai indiqué dans mon commentaire ci-dessous. A défaut, si tu tiens à utiliser awk, reprends l'expression que j'ai écrite en gras.
Au fond, je suis sûr que c'est un créatif refoulé, qui aurait voulu être un artiste pour pouvoir faire son numéro ! :-) Quelqu'un sait qui a écrit la musique qui accompagne « Developers » ?
Le mien fonctionne très bien en version 2.2.11 et offrait déjà cette possibilité dans les versions inférieures. Il faut juste éventuellement ajuster la taille de ton image à quelque chose qui corresponde aux icônes Windows classiques (32x32) et éventuellement baisser la résolution pour que l'image passe bien partout, mais ce n'est pas du tout obligatoire. Je viens d'essayer à l'instant et nos serveurs Windows s'en accomodent fort bien.
Tout ce qu'il faut faire est sauver l'image avec l'extension *.ico .
Tes parents confondent probablement l'installation d'un système indépendant avec la cohabitation de plusieurs programmes au sein d'un même système d'exploitation. Et cela n'a rien à voir.
Comme on te l'a dit au dessus, lorsque ton PC démarre, il n'a connaissance ni de Windows ni de Linux à priori. L'un des deux systèmes d'exploitation va se charger.
Ce qui peut arriver, en revanche, "avec la carte graphique" notamment, ce sont des petits défauts de reset à chaud ou à froid. Lorsqu'un système met ta carte dans un état particulier et oublie de faire le ménage après usage, il se peut que l'autre système ait du mal à s'y retrouver si tu es passé de l'un à l'autre sans éteindre ton PC.
En pratique, ces phénomènes sont très rares (il y a quand même toujours une ligne de reset générale dans un ordinateur) et complètement anodins. S'il se produisent, éteindre ton ordinateur suffit à remettre les choses en ordre. Par la suite, mettre à jour le pilote associé fait généralement disparaître le problème.
# Et les locks ?
Posté par Obsidian . En réponse au message Gestionnaire de version simple. Évalué à 2.
Ainsi, si le logiciel de lecture a le bon goût de poser un verrou sur ton fichier, celui-ci sera en lecture seule pour les autres, voire inaccessible, le temps de la session.
# Substitute
Posté par Obsidian . En réponse au message Suppression de meta-caractère avec sed. Évalué à 2.
# Truc bête
Posté par Obsidian . En réponse au message SOS clavier/souris sans-fil Sangha(slim-line) sucks. Évalué à 2.
Parce que le plus chiant avec les sans-fil, c'est de faire communiquer le récepteur et les périphs. J'avais déjà eu le problème chez une collègue avec une solution Logitech, je crois bien. Systématiquement, le clavier ou la souris, mais pas les deux.
Pour le reste, si ton engin fonctionne en USB, à moins d'avoir un clavier TRES spécial, il ne devrait pas avoir besoin de pilote particulier.
[^] # Re: Tous les jours ...
Posté par Obsidian . En réponse au sondage Vous lisez LinuxFr.org :. Évalué à 2.
[^] # Re: zi va
Posté par Obsidian . En réponse au message fingerprinting & linux. Évalué à 3.
L'orthographe ? /o\
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 2.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 2.
Le truc, c'est que c'est tellement courant qu'en principe, quand on en arrive là, on utilise la première technologie web venue. En l'occurence, c'était moins lourd de réécrire le peu dont j'avais besoin plutôt que d'assimiler et d'inclure dans le projet un module dédié.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
A voir au cas par cas, donc.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 3.
Il n'empêche que je ne placerai pas l'âge de gloire des mainframes à la fin des années 80. A cette époque, les terminaux proprios commençaient réellement à disparaître au profit des ordinateurs de bureaux et, parallèlement, le grand public avait déjà commencé (depuis le début des mêmes années 80) à goûter à la micro-informatique personnelle.
Je ne vois pas où il y a réécriture de l'histoire là-dedans.
# Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 6.
J'aime bien ce goût raffiné pour le cynisme subtil : la liaison discrète du mot "faîte" vers le Wiktionnaire. Cela donne une idée du niveau de culture présumé que l'on attribue aux moules gallo-linuxéistes (qui, au passage, ne sauraient pas non plus se servir d'un dictionnaire).
Ensuite, il y a vingt ans, nous étions fin 1987. Ce n'était plus l'heure de gloire des mainframes mais au contraire celle de l'ascension en force des ordinateurs personnels 8 et 16 bits, avant même que, avec la chute progressive du prix du PC et l'explosion des réseaux locaux, on ne repasse justement à une architecture centralisée avec des serveurs.
Justement, ceux-ci ne remplissent plus que rarement leur rôle premier en entreprise. Si nous utilisons encore des batteries de serveurs accessibles avec des thin clients, pour la plupart des compagnies aujourd'hui, un serveur, c'est un dépôt de fichiers, généralement en SMB, sous Windows, avec une politique de licence d'accès client (CAL) aussi onéreuse que scandaleuse. Bref : les inconvénients de l'infrastructure sans les avantages (et sans le plaisir que pouvait apporter le métier à l'époque).
Sortir du moule propriétaire et mesurer une économie de 3 millions d'euros par an, c'est évidemment remarquable. Maintenant, est-ce que Tomcat-Java est un choix aussi évident qu'il en a l'air ? l'avenir nous le dira. Je ne pense pas qu'une technologie aussi lourde et aussi évolutive à la fois puisse être pérenne pendant vingt ans sans intervention. D'une manière générale, Java c'est bien, mais c'est un langage plus conçu pour les programmeurs que pour ses utilisateurs, à mon goût.
Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.
[^] # Re: Re:
Posté par Obsidian . En réponse au message protection d'un logiciel. Évalué à 2.
1) L'application est développée par un éditeur professionnel pour le compte d'un client précis, par contrat, avec protection par dongle, etc. Cela se chiffre en général en dizaines de milliers d'euros au minimum.
2) L'application a une utilité mais le code est vraiment trop sale pour être publié en l'état.
3) Dans 95% des cas, l'application est développée par un programmeur débutant ou par quelqu'un dont ce n'est pas intrinsèquement le métier ou la vocation. On a réussi à écrire en entier un petit produit, on est fier de son travail et on ne veut surtout pas se faire piller. Le problème restant que, bien souvent, il n'y a en fait rien à piller.
Si en plus, il faut signer des accords de non-divulgation et mettre en place des choses très contraignantes du côté de l'utilisateur, celui-ci ne l'utilisera jamais. L'application sera alors utilisé par son concepteur, par deux ou trois proches et c'est tout. Elle va ensuite tomber dans l'oubli parce que le développeur exclusif n'aura plus le temps de s'en occuper, et enfin devenir obsolète. Bilan : de l'amertume et du temps perdu pour tout le monde.
Enfin, sache qu'il n'est pour ainsi dire plus possible du tout de faire de l'argent avec une application écrite dans son garage. Sans avoir vu l'application elle-même, je suis prêt à parier qu'elle existe déjà en cherchant un peu. Ensuite, non seulement on trouve une floppée d'outils en ligne sur le Net, mais les gens piratent à tour de bras. Paradoxe : ce sont les libristes, ceux qui à priori paient le moins souvent pour un logiciel, qui sont le plus attachés au respect d'une licence. Je pense que la majorité des personnes ici présentes n'ont pas le moindre winzip pirate sur leur disque.
Penser alors "faire éventuellement de l'argent" en vendant l'application si l'envie vous en prend, c'est être très naïf. On baigne dans un océan numérique à mille lieues de ce qui existait il y a encore quinze ans, où l'on apprenait l'existence d'applications utiles par le bouche à oreille et où l'on patientait deux semaines pour rencontrer "la personne qui l'avait" pour lui filer une disquette et attendre qu'elle nous la rende chargée de sa précieuse cargaison, comme un gamin à la veille de Noël.
Un logiciel, c'est comme un enfant : on le protège au tout début mais après il faut le laisser vivre sa vie et rencontrer du monde si l'on veut qu'il se développe correctement !:-)
Donc, le meilleur conseil que je puisse te donner : fais deux branches, une entièrement libre, l'autre éventuellement propriétaire (en commençant par la libre). Accepte le fait que le contenu de ta première branche soit public et le reste ad vitam æternam. Place-le sous licence GPL et laisse les gens modifier le code s'il le souhaite.
Si les gens ne sont pas pris en otage et peuvent avoir confiance en l'application qu'ils utilisent, alors le logiciel deviendra populaire, et les gens qui gagnent un salaire raisonnable pourront alors s'offrir le luxe d'acquérir une version propriétaire, full-featured, avec un minimum de documentation et d'assistance en cas de problème. A prévoir nécessairement si tu vends ton produit, si ta philosophie est "raque, démerde-toi tout seul et surtout n'essaie pas de voir comment j'ai fait", il est clair que tu as perdu d'avance.
Voila, j'espère que je t'ai éclairé un peu.
[^] # Re: Voir ici :
Posté par Obsidian . En réponse au message Problème. Évalué à 1.
http://fr.wikipedia.org/wiki/Probl%C3%A8me_du_voyageur_de_co(...)
# Voir ici :
Posté par Obsidian . En réponse au message Problème. Évalué à 1.
[^] # Re: ...
Posté par Obsidian . En réponse au message Problème. Évalué à 5.
# Possible.
Posté par Obsidian . En réponse au message Samba nombre de connexion simultanée. Évalué à 3.
http://en.wikipedia.org/wiki/Client_Access_License
Possible qu'il y ait un paramètre dans la config de Samba qui limite également le nombre de connexions simultanées. C'est fragile, le SMB :-)
[^] # Re: Exemple du fichier d'entrée
Posté par Obsidian . En réponse au message retrouver la vraie IP avec AWK ou autres. Évalué à 2.
# Je propose :
Posté par Obsidian . En réponse au message retrouver la vraie IP avec AWK ou autres. Évalué à 2.
En considérant bien sûr qu'il n'y a pas de zéro non-significatif à gauche de chaque nombre ...
[^] # Re: DEVELOPERS ! DEVELOPERS ! DEVELOPERS ! (DEVELOPERS !)
Posté par Obsidian . En réponse au journal Le 2 octobre, "Steve Ballmer vient à Paris pour évangéliser les députés et Sciences Po". Évalué à 4.
http://www.youtube.com/watch?v=dbCmnRztK1Y
http://www.youtube.com/watch?v=ftsByyqazF0
Au fond, je suis sûr que c'est un créatif refoulé, qui aurait voulu être un artiste pour pouvoir faire son numéro ! :-) Quelqu'un sait qui a écrit la musique qui accompagne « Developers » ?
[^] # Re: Capture d'ecran
Posté par Obsidian . En réponse au journal [Mouling + Mavie] Vos pires geekeries. Évalué à 2.
http://www.bashfr.org/?5171
[^] # Re: Rhaa
Posté par Obsidian . En réponse au journal Martine ou la vraie vie. Évalué à 3.
[^] # Re: Rhaa
Posté par Obsidian . En réponse au journal Martine ou la vraie vie. Évalué à 2.
[^] # Re: bind(0)
Posté par Obsidian . En réponse au message Obtenir le numero d'un port réseau libre. Évalué à 2.
Vois plutôt du coté des IPC SysV (mémoire partagée, sémaphore et file de messages), et utilise plutôt les sockets Unix ...
[^] # Re: Hum....
Posté par Obsidian . En réponse au journal Martine ou la vraie vie. Évalué à 2.
Ah, oui ! Très fin ! :-)
# Si, GIMP le fait.
Posté par Obsidian . En réponse au message créateur d'icônes. Évalué à 2.
Quelle version du GIMP utilises-tu ?
Le mien fonctionne très bien en version 2.2.11 et offrait déjà cette possibilité dans les versions inférieures. Il faut juste éventuellement ajuster la taille de ton image à quelque chose qui corresponde aux icônes Windows classiques (32x32) et éventuellement baisser la résolution pour que l'image passe bien partout, mais ce n'est pas du tout obligatoire. Je viens d'essayer à l'instant et nos serveurs Windows s'en accomodent fort bien.
Tout ce qu'il faut faire est sauver l'image avec l'extension *.ico .
# Non, en principe, non.
Posté par Obsidian . En réponse au message Partitionnement. Évalué à 3.
Comme on te l'a dit au dessus, lorsque ton PC démarre, il n'a connaissance ni de Windows ni de Linux à priori. L'un des deux systèmes d'exploitation va se charger.
Ce qui peut arriver, en revanche, "avec la carte graphique" notamment, ce sont des petits défauts de reset à chaud ou à froid. Lorsqu'un système met ta carte dans un état particulier et oublie de faire le ménage après usage, il se peut que l'autre système ait du mal à s'y retrouver si tu es passé de l'un à l'autre sans éteindre ton PC.
En pratique, ces phénomènes sont très rares (il y a quand même toujours une ligne de reset générale dans un ordinateur) et complètement anodins. S'il se produisent, éteindre ton ordinateur suffit à remettre les choses en ordre. Par la suite, mettre à jour le pilote associé fait généralement disparaître le problème.