Certes. Ce sujet est abordé sur le forum du site de Virtualbox, où ils expliquent que ça serait bien mais que c'est complexe, surtout pour DirectX. Je ne dis pas le contraire. N'empêche que ça serait très intéressant.

Surtout que la concurrence commence à le faire (VMWare mais pas seulement). Du coup ça serait dommage que VirtualBox, qui est par ailleurs un très bon logiciel que pour mon usage je préfère largement à VMWare (et pas uniquement parce qu'il est libre), prenne trop de retard sur ce sujet par rapport à la concurrence.

On peut donc espérer voir arriver un jour un tel support.
Ça pourrait même être déjà le cas pour OpenGL sous Linux (que VMWare ne supporte d'ailleurs pas sauf via VMGL).

[ Répondre ]

Il n'y a toujours pas de support de l'accélération 3D. Dommage. Pas possible de jouer à de vieux jeux Windows non supportés sous Wine.
Évidemment, autant le support de l'accélération OpenGL est "relativement" aisé à intégrer (il y a déjà des travaux sur lesquels se baser comme VMGL, http://www.cs.toronto.edu/~andreslc/xen-gl/ ), autant le support de DirectX risque d'être plus chaud, même si un tel driver devrait pouvoir se baser sur Wine.

Ça serait déjà sympa qu'ils intégrent l'accélération OpenGL, au moins sous un Linux virtualisé. Ça permettrait de tester des distribs avec les effets graphiques activés. J'ai cru comprendre qu'ils avaient commencé à intégrer cela mais que cela n'était pas très stable et désactivé par défaut.

[ Répondre ]

Le paramètre overscan des drivers nvidia est inopérant sous Linux pour le moment. Peut-être un jour. Depuis le temps que c'est demandé ça arrivera peut-être un jour (on y croit!).

En attendant, pour regarder des vidéos, tu peux utiliser le lecteur smplayer en jouant sur les touches w et e ou le menu Video -> Pan&Scan -> Zoom - / Zoom +.
Chez moi une fois la vidéo en plein écran, j'appuie deux fois sur 'w' pour avoir l'image en entier.
C'est une fonctionnalité spécifique à Smplayer absente de mplayer.

Évidemment c'est limité aux vidéos.

[ Répondre ]

Hugin? (http://hugin.sourceforge.net/ )

[ Répondre ]

Le port 443 est celui réservé pour les connexions sécurisées https. Donc il se peut que ton serveur web écoute sur ce port en plus du port 80.

[ Répondre ]

Tout à fait. Avoir une image sur plus de 8 bits est intéressant si tu comptes retraiter l'image.

J'ai un réflex et le format raw de l'appareil permet des traitements tout simplement impossibles avec le jpeg. En particulier avec une image en raw il est possible dans une certaine mesure de récupérer des détails dans des zones cramées (surexposées) là ou dans la version jpeg il n'y a que du blanc. Et pourtant le raw de mon appareil c'est pas du 16 bits mais seulement du 12 bits.

[ Répondre ]

J'ai pas lu l'article, mais si je me réfère à la citation, rien ne dit qu'il désapprouve cette tendance. Pour lui c'est peut-être une bonne chose...


Oh, mais ça serait bien déjà le weekend! Allez hop!
---> [ ]

[ Répondre ]

Au moment du "développement" en jpeg il est conseillé d'appliquer un profil de couleur adapté à ton appareil.

Pour plus d'infos tu peux commencer par consulter cette page.
http://ufraw.sourceforge.net/Colors.html

[ Répondre ]

Effectivement c'est pas si novateur car de nombreux projets industriels visant la production de carburant à partir d'algues sont déjà lancés ou sur le point de l'être.

cf. le site "Les énergies de la mer": http://feeds.feedburner.com/LesEnergiesDeLaMer

Ce site rescense les actus de projets ayant pour but de tirer de l'énergie de la mer, à savoir éoliennes off shore, "éoliennes" sous marines mais également la production de carburant à partir d'algues.

Pas besoin d'une source de CO² d'ailleurs (même si ça permet d'augmenter le rendement). De l'eau et du soleil suffisent pour cultiver des algues avec de bien meilleurs rendements pour la production d'huile que la culture de végétaux terrestres.

Une technologie d'avenir assurément. Quand à savoir si ça va résoudre tous nos problèmes énergétiques, ça reste à voir.

[ Répondre ]

Et bien c'est l'UFC qui fait appel:
http://www.pcinpact.com/actu/news/44394-vente-liee-UFC-Darty(...)

[ Répondre ]

Il me semble que son argument tenait à ce que la loi actuelle n'a pas besoin d'être modifiée. En l'occurrence le jugement lui donne raison non?

[ Répondre ]

Voici un lien:
https://linuxfr.org/~MrLapinot/26625.html#931463

[ Répondre ]

Aucune idée pour la Laguna. Ceci dit j'ai déjà vu des specs où la différence entre la boite manuelle et automatique (de quel type?) était de quelques dixièmes de littres pour un cycle urbain (au lieu de la grosse différence de 2L pour la Laguna).

Je me souviens plus quelles étaient les voitures en question mais c'était des modèles récents. J'imagine qu'un petit tour sur les sites internet de quelques constructeurs suffirait pour trouver les chiffres.

[ Répondre ]

Comme le dit le commentaire précédent le tiens, ces données constructeurs correspondent à une mesure effectuée dans des conditions particulières avec une conduite adaptée pour consommer le moins possible. Généralement la consommation réelle constatée par les utilisateurs est supérieure aux chiffres annoncés (la consommation pouvant varier énormément en fonction du type de conduite et du type de trajets effectués).
Finalement le seul vrai intérêt de ces chiffres est de comparer plusieurs voitures, vu que les conditions de mesure sont sensées être les mêmes.

Dans ces conditions "optimale" une boite auto consomme un peu plus. Sauf que un conducteur lambda muni d'une boite manuelle ne va pas forcément connaître suffisamment bien le moteur pour savoir passer les vitesses au moment optimal pour la consommation, alors qu'une boite auto si.

Dans ces conditions je ne serai pas surpris qu'en situations réelles une boite auto consomme statistiquement moins qu'une boite manuelle.

[ Répondre ]

VirtualBox, sous licence GPL, est aussi efficace que Vmware et je trouve plus simple, au moins pour une utilisation basique (il y a une GUI plutôt bien faite). Bon après mes besoins sont assez basiques et je sais pas ce que vaut VirtualBox pour gérer une trentaire de machines.

[ Répondre ]

D'autant plus que d'autres progrès sont à l'horizon dans ce domaine. En particulier sur le rendement énergétique. Il est à la louche autour de 10% pour le panneau de base commercialisé; bref pas terrible. Mais il existe des prototypes qui ont un rendement atteignant 40% et certains espèrent pouvoir dépasser 50%.

Évidemment le passage du prototype au produit commercialisable n'est pas évident et rapide, mais on peut tout de même penser que les panneaux solaires vont devenir de plus en plus intéressants à moyen terme.

[ Répondre ]

La procédure d'obtention du certificat n'est certe pas satisfaisante. Disons que c'est un premier pas. Il est fort possible que cela évolue (via la future carte d'identité électronique?)

D'autre part même en l'état la signature permet au moins d'être certain que ta déclaration va pas être modifiée après coup.

[ Répondre ]

Si tu es connecté en SSL, tu reçois les pages web (des formulaires tout ce qu'il y a de plus classique) sur une connexion sûre. Tu es également certain qu'ils n'ont pas été modifiés.

Non! Il y a juste authentification mutuelle puis chiffrement du canal de communication. Rien ne te garantie que personne n'a réussi à modifier le site en douce. La page en elle même qui t'es envoyée n'est pas signée.

Franchement, si tu envoies des données (là encore via des formulaires web classiques) sur une connexion authentifiée, c'est que bien toi qui est à l'autre bout. Signer la déclaration ou envoyer la déclaration sur un canal authentifié, je vois la différence théorique, mais en pratique le résultat est le même : tu as la garantie que c'est bien toi (au sens de toi = le possesseur de la clef privée) qui a fait la déclaration. Le fait de considérer la "déclaration" comme un document unique, signé une fois, ou comme la procédure qui consiste à "déclarer" (envoyer petit à petit) les différents élément, sur un canal authentifier, ce sont deux points de vue équivalents, AMHA.

L'authentification est une procédure interactive qui ne peut être vérifiée après coup. La signature elle peut être vérifiée plus tard par n'importe qui a connaissance de la clé publique ad hoc. Elle ne peut être répudiée sauf si tu prouve que tu t'es fait volé ta clé privée. Elle a une valeur juridique. Cette signature est une preuve que tu as fait ta déclaration. Une authentification mutuelle + chiffrement ne permet pas cela.

Authentification et signature (de document) numérique sont deux actions très différentes même si elles utilisent des outils similaires.

Pour moi, c'est au serveur de générer ce pdf et de le signer, garantissant ainsi son authenticité. Certes, ça rajoute de la charge serveur.

Le PDF contient essentiellement ta signature et constitue donc une preuve. Je ne voit pas pourquoi ça serait au serveur de la fournir et encore moins pourquoi il devrait le signer. C'est toi qui certifie l'exactitude des infos (et donc signe), pas le serveur.

Simplement s'il y a moyen de faire plus simple, autant faire plus simple. Pourquoi ne pas se passer de l'applet. Tous les navigateurs qui la supporte supportent aussi l'authentification SSL mutuelle, non ?

En quoi la solution java est-elle complexe? Tu as juste besoin du plugin Java sous ton navigateur. Et OpenSSL tout seul c'est bien pour l'authentification mais à mon avis une signature numérique est indispensable, ce qui suppose des développements supplémentaires. On pourrait imaginer une extension Firefox, mais du coup ça fonctionnerait pas sous IE (pas grave), ni sous Konqueror, Opera, etc.

Pour moi la solution de l'applet Java me semble encore la meilleure solution.

[ Répondre ]

Effectivement!

MrLapinot propose d'installer Openssl, qui est certes portable mais qu'il faut tout de même installer et intégrer au navigateur. Je crois qu'il serait bon qu'il se renseigne lui-même un peu sur le fonctionnement de cette applet :)

Bien sûr que le protocole ssl permet l'authentification mutuelle. Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer. D'autre part l'applet Java ne sert pas qu'à ça:
- le formulaire fait partie intégrante de l'applet et l'applet est signée donc tu es certain que l'appli n'a pas été modifiée par des tiers
- elle sert à signer numériquement ta déclaration et non ssl c'est pas fait pour ça! Je sais que certains protocoles d'authentification peuvent faire usage de schémas de signature, mais c'est pas ce "type" de signature qu'on veut.
- elle génère un pdf de ta signature

Bref la signature n'est qu'une des fonctionnalités de cette applet.

De plus avec l'applet, rien à installer côté client. Ca fonctionne quel que soit le navigateur et l'OS (à quelques exceptions près). C'est quoi le plus simple? Il y en a qui ont peut-être des soucis avec cette applet mais ces problèmes seront certainement prochainement corrigés. Pour ma part ça a fonctionné comme un charme (façon de parler quand on parle d'impôts!).

Le seul truc critiquable c'est la manière dont on te fournit le certificat puisqu'il suffit d'avoir accès à la feuille de déclaration de l'année précédente pour avoir toutes les données nécessaires. Mais l'utilisation d'OpenSSL n'y changerait rien!

Oh, et un "couple de certificats (publique/privé)" n'a aucun sens. Un certificat est par définition publique, et contient une clé publique. La clé privée correspondante n'en fait pas partie.

[ Répondre ]

Il faudrait plus qu'un simple formulaire. L'idée ici n'est pas seulement d'assurer la confidentialité (faisable avec du https basique), mais surtout de signer ta déclaration, ce qui implique que tu disposes de ton côté d'un certificat ad hoc (fournit par l'administration) et de sa clé privée associée.

L'applet java (elle-même signée pour éviter l'exécution de code frauduleux) sert à remplir ta déclaration, mais se charge également de la signer numériquement.
Le choix de Java me semble pertinent. En plus c'est multiplateforme même s'il reste quelques soucis comme l'indique ce journal.

[ Répondre ]