totof2000 a écrit 9656 commentaires

Non.

Le fait que les menaces augmentent sans que les agressions n'aient lieu peut signifier que les mesures prises pour la sécurité des AS est efficace ....

Les adaptateurs CPL sont de quel type ? USB ou Ethernet ? Ce sont les adaptateurs fournis par Free?

Si c'est le cas tu dois pouvoir trouver les infos sur google.

des éléments ici :

http://soft.zoneo.net/Linux/courant_porteur.php

Non, pas toujours ( il m'arrive de l'oublier lorsque je change de veste). Par contre faudrait un jour que je me présente à un agent de la SNCF lorsque je rentre du travail et que je n'ai plus de train en demandant à la SNCF de me trouver une alternative.

Tiens puisque tu parles de statistiques. Peux-tu me dire si on peut trouver :
- l'évolution du nombre d'agression de conducteurs de train sur l'année pour les 5 dernières années
- l'évolution du nombre de conducteurs à la SNCF sur les 5 dernieres années
- l'évolution du trafic SNCF en banlieue parisienne sur les 5 dernières années....

De là j'aimerais savoir si statistiquement il est plus risqué pour un conducteur de train de se faire aggresser .....

Si ce n'est pas le cas, l'exercice du droit de retrait par les cheminots à St Lazare est abusif.

Je ne fais pas une fixation sur la grève "normale" avec préavis et tout ... Dans ce cas je prends mes dispositions.

Par contre la ou j'ai un problème c'est avec la grève sauvage du style de celle de St Laezare la semaine dernière.

Et puis il faut aussi dire que la prise en charge des usagers en cas d'incident à la SNCF n'est pas exemplaire ...

Il doit y en avoir une ou deux par an

Je dirais plutot "au moins un tous les deux mois". Et sur la ligne que je prends en ce moment il ne se passe quasiment pas une semaine sans qu'il y ait de problème (depuis début septembre).

Les collègues ? Rentrés chez eux depuis bien longtemps (intervention le soir).

Et tu le préviens comment, ton assureur, sans téléphone ?


Comme je le disais : bornes sur les routes .....

Je pense que le problème de Java, c'est son origine : il a été concu à l'origine pour faire de l'embarqué, et a évolué ensuite vers ce qu'on connait aujourd'hui. D'ou le fait qu'il paraisse aussi pauvre.

On tombe bien dans le cas ou la marche n'est pas une alternative.

Rentrer chez soi(durée de 6h), pour retourner au travail le lendemain (durée 6h). et être au taf a 9h30 (soit 9h plus tard) ....

comme quand ta voiture tombe en panne :D Ou qu'un couillon est rentré dedans avec sa grosse caisse, mais n'a pas daigné s'arrêter. Ou que t'es à vélo et qu'un crétin à trouvé très marrant de dégonfler les pneus ou "emprunter" ta roue avant, je ne parle pas du piquage de selle qui est aussi assez fréquent.
.

Pour la voiture en panne : je dispose d'une assurance qui me permet de gérer ce tpe de problème. Certes restera le moyen de prévenir l'assurance, mais en général les routes disposent de bornes depuis lesquelles je pourrai appeler un dépanneur.

Pour le vélo : les distances que je percours en vélo ne sont pas du même ordre que celles que je parcours en transports. A ce moment la la marche reste possible .....

Dans ces cas là tu aborde bien aimablement un autre usager/piéton et tu demandes si tu peux utiliser son téléphone portable, ou tu rendre dans un bar et tu demande au gars derrière le comptoir si tu peux téléphoner (et comme t'as 10€ tu peux proposer de le dédommager)

C'est la seule option possible ... Mais téléphoner pour faire quoi ? Je n'ai pas d'amis (en tout cas pas d'amis joignables ou dispo à ce moment là).

Quant au téléphone, tu y mets vraiment de la mauvaise volonté.

Pourquoi ? Ce n'est pas de la mauvaise volonté mais un concours de circonstances qui s'est déjà produit pour moi.

Non. ule alternative aux transports en commun ne peut être la marche.

Pour mi, la marche reste l'option prioritaire dans mes déplacements. Si j'utilise autre chose, c'est que la marche n'est _PAS_ envisageable.

- je n'ai pas de téléphone portable
- je n'ai pas de carte téléphonique
- pas de téléphone à pièce.

Sinon, il reste la marché à pied, pour la plupart des gens.

Ce n'est pas une alternative.

Lorsque je disas "paquets séparés" :
- un paquet, ou une URL permettant de récuperer les icones telles que tu les a eues chez ton "fournisseur"
- un paquet de ton travail sans les icones, avec éventuellement une doc pour intégrer les icones de ton "fournisseur" ou toute autre icone.
- un paquet intégrant les deux.

En tout cas c'est cmme ça que je ferai.

N'importe quoi .....

et encore, les solutions de remplacement existent.

non.

Quand je me retrouve à la gare avec une carte navigo, 10 euros en poche, sans carte bleue et que je dois rentrer chez moi, je fais comment ?

C'est ce qui me semble le plus judicieux, mais à faire comme ça :

- un package contanant tion code sans les icones.
- un package contenant les icones
- un package contenant les deux.

A la limite si tu peux, sépare bien dans ton code les icones du reste (dossier bien spécifique).

Au pire des cas, tu peux peut-être t'arranger pour que tes icones ne soient pas "intégrés" dans les exécutables mais que les exécutables aillent lire tes icones dans un endroit précis. L'avantage serait de ne pas trop lier les icones au code et de pouvoir les remplacer en cas de besoin.

Exemple..."Apocalyps now" et les Valkyries de Wagner..."2001 l'odyssé de l'espace" et Strauss. Qui ne pense pas à ces films en entendant les morceaux utilisés dans les BO ?

Moi ....

Une tete de cochon ...

les logiciels libres, ils les utilisent et se plaignent quand ça ne marche pas (sans fournir un patch)

s/les logiciels libres, ils les utilisent et se plaignent quand ça ne marche pas (sans fournir un patch)/les logiciels libres ils ne les utilisent pas en se palignant que ça marche pas (avant même les avoir utilisés)/

Je suis pour la lutte contre la contrefaçon logicielle !!! Des que les utilisateurs verront ce que ça coute réellement, ils passeront au libre.

Tout est trop bien réglé (pré-réglé, même, je suis conscient que ce système est très fermé aux utilisateurs finalement, les choix étant faits à sa place tout en étant réfléchis je trouve),

Qu'est-ce que ce doit être ennuyeux !!!

Sérieusement : je n'aime pas passer des heures à configurer un système. Cependant force est de constater que la couche propriétaire Apple est une vraie plaie. Ils utilisent une sous-couche libre (cups, etc ...) mais j'ai tentéé cet été de partager ne imprimante Mac sur une machine virtuelle Windows (parallel me semble-t-il), et c'est une horreur ....
Je préfère mon bon vieux fichier de conf classique, j'ai juste à faire un VI dessus. La j'ai été obligé de jouer avec la couche de définition des users et au final j'ai jamais réussi ....


Alors bien sûr, j'utilise un iPod, et je pourrais l'utiliser avec Amarok ou d'autres lecteurs, mais encore une fois il manquerait la simplicité d'utilisation d'iTunes, son système de bibliothèques partagées, etc.

Du coté obscur tu es passé ..... Plus facile, plus attrayant ..... plus beau il parait.

il manquera toujours cette uniformité et cette facilité d'utilisation qui rend tout le système simple, beau, facile à administrer et tout.

CA Y EST !!!! IL EST IRRECUPERABLE !!!

mouais ... Bof .... Dans une boucle c'est pas toujours la meilleure idée ... Et je suis pas sur que les compilateurs sachent gérer l'optimisation à ce niveau ...

q^(oo)^p
Pas besoin de se pencher la tête pour celui-la ...

Et si Canonical avait libéré tout Launchpad, 100% du code, s'ils avaient aussi offert les codes de leurs serveurs, mis à disposition du publique la cartographie complète de leur architecture réseau, diffusé en temps réel les comptes de l'entreprise au cent près et installé une webcam dans le slip de Mark Shuttleworth.



La camera elle est pas assez bien placée : nous on veut savoir ce qu'il a dans les tripes !!!!

Bon finalement je n'ai pas si mauvaise mémoire que ça :

http://www.easysw.com/~mike/serial/serial.html#3_1

Il y a moyen de récupérer l'état des lignes d'un port série de manière standardisée.

Ma question : LIRC utilise-t-il cette interface ? Je n'ai pas encore déroulé le code source pour vérifier .... Si c'est le cas il doit être facile de porter LIRC (au moins la partie utilisant le port série) sur autre archi ...

Bon, j'ai mauvaise mémoire :(

A priori, pour une interface série, seules les communications "standard" sont plus ou moins normalisées (accès aux ports via /dev/ttySx ou équivalent sur d'autres systèmes), mais pour ce que fait LIRC il n'y a aps l'air d'avoir quelque chose.

Bon pas grave..... Je reste convaincu cependant qu'une bonne partie des "drivers" auraient pu être déplacé hors de l'espace kernel pour favoriser la portabilité .... Mais ça n'engage que moi et je peux me tromper.
Loin de moi l'idée de critiquer de façon négative le projet LIRC, je trouve que c'est un projet assez bien fait, cependant je suis un peu frustré du fait qu'il nesoit pas portable plus facilement.

Je reviendrai certainement vous voir si j'ai besoin de plus d'infos sur les parties "Driver linux" que je ne comprend pas.