Anonyme a écrit 62289 commentaires

Je me demande si la transparence du PNG sera prise en compte dans IE9 (sauf erreur, c'est toujours un problème) ...

pour gérer tes photos, je te conseille jBrout ! C'est très pouissant.
- http://jbrout.python-hosting.com/
- http://code.google.com/p/jbrout/

Sauf que c'est absolument pas limité à raconter comment on va. Comme pour un blog, on peut utiliser ca pour parler de sa vie, ou de tout un tas d'autres choses.

au meme moment il faisait +19 degré au groeland!

la carte qui montre le probleme

http://www.univers-nature.com/images/accueil/accueil-image-s(...)

Je ne comprends pas la raison du moinssage.

Je dis (d'une manière différente certes) la même chose que le commentaire du dessous…

Je vois pas le rapport. Si le périphérique X demande qu'on stocke les fichiers de la manière A, il va pas le demander uniquement s'il est relié à Windows (et dans le cas d'un GNUx demander la manière B).

Mauvais argument changer arguments ^^.

Comme proposé par l'auteur du journal on peut utiliser un outil générique comme openssl afin de chiffrer un fichier contenant la liste des mots de passe.

Pour rajouter de nouveaux mots de passe dans ce fichier chiffré, on peut être tenté de créer un fichier temporaire contenant les informations en clair, de l'éditer, de le chiffrer de nouveau, puis de le supprimer.

Il important de remarquer qu'il y a un certain nombre de risques dans cette méthode :
1) les éditeurs de texte créent souvent des fichiers de "swap" et des fichiers de log, qui peuvent fournir une information sinon complète, au moins parcellaire sur le contenu du fichier
Par exemple, pour vim: les fichiers du type .monfichier.swp et le fichier ~/.viminfo. Pour gedit: les fichiers du type monfichier~
Dans le cas de vim, on peut empêcher la création de ces fichiers en invoquant vim de la manière suivante : vim -n -i NONE monfichier

2) L'information en clair peut subsiter sur le disque dur même après effacement par rm. On pourra utiliser la commande suivante : shred --remove monfichier

3) Dernier risque qui me vient à l'esprit, lié à l'ergonomie spartiate de la méthode. Se tromper de mot de passe en chiffrant de nouveau le fichier. Risque toutefois limité, l'outil de chiffrement demande généralement une confirmation du mot de passe.
Ecraser, supprimer d'une quelconque manière à la fois le fichier crypté et le fichier en clair.
Une bonne pratique, valable qu'elle que soit la méthode choisie, est d'avoir un backup du fichier crypté à côté "suffixe .bak" et en plus sur un autre support.

Afin de pallier à la plupart de ces problèmes, il existe des manières plus pratiques de combiner l'utilisation de l'outil de chiffrement avec l'outil d'édition, et qui évitent la création d'un fichier temporaire en clair.
Voir ces liens:
http://www.vim.org/scripts/script.php?script_id=2012
http://vim.wikia.com/wiki/AES256_encryption_in_Vim

je te pertinente ! Ton commentaire montre que tu ne sais pas ce que c'est un automate industriel. D'ou ta reaction sur les les PC.

c'est la le problème, il y a des utilisations adéquate pour le PC et d'autre pour l'automate industriel.

Pour un distributeur automatique l'automate c'est mieux.

un exemple en photo d'un automate qui aurait pu convenir pour notre distributeur de boisson.

http://www.overweed.net/forums/upload/zelio_297.jpg

celui la fait permetrais d'avoir une joli IHM:

http://www.kollewin.com/EX/09-14-20/TELEMECANIQUE_TSX3721101(...)

ça sent bon la simplicité, la maintenance aisée.

que c'est typique de la nouvelle generation d'ingenieur. ils croient que c'est facile a mettre en oeuvre, pas chere, ils ont des pc a la maison. Les connnaissances necessaires pour etudier la machine sont minime, yaka cliquer pour develloper le magnifique logiciel sous windows mobile. c'est vraiment pas chere la licence.

c'est ce qu'apprend mon petit frere en ecole d'ingenieur. ce n'est pas trop de leurs fautes.

Moi :), plein d'experience professionnel, je vois de suite qu'un petit automate de chez telemecanique ou siemens fait amplement l'affaire, meme avec un ecran en couleurs et moulte blinbling.

L'inconvenient:
Trouver un automaticien (un informaticien ferais amplement l'affaire)
Trouver un fournisseur en produit industriel, ce qui n'est pas evident quand on a en tete les boutiques rue Mongallet, voire la fnac
Ouvrir un compte
Le prix, mais qui descend assez vite avec le volume de commande.
Convaincre La direction que c'est le meilleur choix. Alors que personne n'a jamais vue un automate fonctionner. C'est souvent associer a tord a un PC, donc c'est pareil, alors pourquoi ne pas prendre du windows ?

sniff

pareil.

Cé vré sa, fo lé remonté sé programmateurs !

[citation demandée]

lors du reportage envoyé special sur Dyson, le journaliste a interroger plusieurs dirigeant des concurrent.

le gars de chez hoover a dit : notre seul regret est de ne pas avoir acheté les brevets Dyson pour entérré l'idée.

faut dire que Dyson leur avait proposé la vente de ses brevets. :) on ne peut pas etre visionnaire partout :D
le reportage date d'il y a 3 ou 4 ans

Oops!
En lisant avec plus d'attention le lien ci-dessus, je remarque que la licence Apache est justement un contre exemple.

Pour l'inclusion de code dans le noyau linux, la condition nécessaire et suffisante concernant la licence est d'être compatible avec la GPLv2. Cela correspond donc à un vaste éventail de licences (au hasard : Apache, BSD, CeCILL, LGPL etc.)

Voir une liste détaillée sur :
http://www.gnu.org/licenses/license-list.html#GPLCompatibleL(...)

bonjour

je ne suis pas un commercant, mais mon épouse travail dans le commerce, au sein du département comptabilité d'une grosse PME de vente par corresspondance. Chef compable pour faire court.

cette société n'a JAMAIS eu le moindre frais pour avoir déposer des chèques qui sont sans provision. ils reçoivent juste le chèque de la banque, avec comme consigne démerdez vous. une dizaine par mois.

Mon pere ayant loué des appartement a deja recu des chèques sans provisions. Il n'a JAMAIS eu de frais sur le depot de ces chèques.

tu confond émission et dépôt comme le montre ton dernier paragraphe. Et oui, ce n'est pas pareil.

http://droit-finances.commentcamarche.net/forum/affich-42643(...)

http://www.amazon.fr/Les-Cheques-pour-Nuls/dp/2754002774/ref(...)

A+

alors je sais pas ou tu as vu que les banques font payer des frais de rejet au commercant ! mais pas en France. Le chèque impayé est simplement retourné au commercent gratuitement. Et c'est lui qui doit se demmerder pour recuperer l'argent.

donc c'est trés casse couille pour le commercant de recevoir des cheques impayé de la banques. Il faut téléphoner a l'emeteur, trouver son adresse lui demander des sous. C'est la seule raison que cela disparaisse.

Les banques ne font rien pour que tu sois payé et je dirais meme encourage le développement des chèque sans provisions.

le seule avantage de la banque postal c'est une banque national, changeant de résidence tous les 2 ans, je peux dire que les autres banques ( CA, écureuil) te font resilier tout tes comptes pour en ouvrir de nouveau. La banque postal il transfere simplement les comptes sur le nouveau lieu de résidence.

un virement ce n'est pas gratuit sauf a avoir le compte dans la meme banque que le proprio

On peut développer avec QuickTime ?

ben un stagiaire par definition ne sais rien faire, c'est pour cela qu'il fait un stage pour apprendre :). Sinon tu veux un ingenieur pas payé

J'ai lu en diagonale tellement c'est biaisé comme avi mais tu peux expliquer « l'aventure Vorbis » ?

Ha parce que RoR c'est pas le monde du Libre mais Python si ? C'est quoi cette mauvaise fois ?

Ça arrange pas Google de faire avancer RoR, ils s'en passent c'est tout.

C'est des connards tout le monde le sait, pourquoi on s'indigne ?

Bon, bah, Arora c'est sans vidéo :/

Désolé, votre système ne possède apparemment aucun des lecteurs supportés. Veuillez installer un des lecteurs supportés.

Toujours en e17-0.0001.

On essaie de finaliser les bibliothèques pour une alpha, peut-être en juillet. Il y a beaucoup de boulot encore, en particulier pour la documentation qui est trop sommaire. Les bibliothèques sont assez stables et l'API ne devrait pas changer. Les ports (Windows XP ou CE, Opensolaris, BSD et Mac OS X) sont encore à améliorer (quoique j'ai réussi à faire tourner sans problème e17 sous Opensolaris).

Pour ce qui est des applications, il y en a vraiment très très peu. Mais bon, 3 développeurs core, des développeurs qui bossent pour ces trois là mais dont le travail est orienté en fonction des desiderata des ces 3 devs), une petite dizaine de contributeurs majeurs.

Compare avec les centaines de développeurs pour QT/KDE ou GTK/Gnome. C'est normal que ça n'avance pas à grand pas.

Par contre, nous ne sommes pas contre les rapports d'erreurs, les patchs, les contributions, les applications, etc...

On essaie de faire de la pub, de se faire connaître un peu, etc... On sera aux RMLL cette année par exemple. Avec un peu de chance, ça attirera des gens motivés.