goulou a écrit 42 commentaires

Moi qui étais content : les Blue Mountains, c'est un très joli endroit en Australie! Je trouvais ça sympa comme nom! :-(

LLVM gère désormais la prédiction de branche et __builtin_expect sous forme de métadonnées dans la représentation intermédiaire.

Ça semble un peu élémentaire comme fonctionalité non ?

Je ne sais quoi penser : d'après le sujet suivant, justement, les processeurs sont devenus tellement bons dans ce domaine que ça n'est plus nécessaire... Ou alors c'est pour les architectures qui en ont encore besoin?

http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_13

Il est indiqué qu'il existe une vingtaine de pods à l'heure actuelle : cela comprend-il les pods perso?

Corollaire : j'ai cru comprends que n'importe qui peut lancer "son" pod et y héberger son compte et celui de ses amis. Comment se passe l'intégration avec les "20" pods qui ont l'air plus ou moins officiel?

Pour finir : qu'en est-il des comptes dupliqués? J'entends par là : que se passe-t-il si je décide de m'inscrire, sous le même nom, sur 2 pods différents? (ou plutôt : que se passe-t-il si quelqu'un s'inscrit sur un pod différent du mien mais sous le même nom?)
Est-ce que je dois créer dès maintenant des comptes bidons "MonPseudo@pod.example.com" sur chaque pods pour éviter les collisions??
Idem dans le cadre des migrations de compte : si alice@pod1.example.com migre sur pod2.example.com (quand ce sera possible), elle changera litéralement de nom?

Merci par avance pour vos réponses!

Bonjour,

Vous parlez d'une application pour Android : c'est à mon sens une très très bonne chose, et j'aimerais savoir si quelque chose est prévu pour iPhone/iPad : dans un premier temps, que donne l'interface Web (d'ailleurs, que donne-t-elle sous Android?), et est-ce que vous prévoyez une appli par la suite? Peut-être que quelques captures d'écran supplémentaires dans la galerie seraient une bonne chose.

Merci beaucoup en tous cas pour ce développement prometteur : mon réseau 1-Wire est en attente depuis l'année dernière, notamment parce que quand j'ai voulu me lancer dedans, j'ai commencé à voir votre projet qui ne paraissait pas assez mur à l'époque... (et les autres me tentaient moyen...) Je pense que je vais pouvoir ressortir le fer à souder cet automne!! :-)

C'est là tout le problème selon moi des langages qui laissent la porte ouverte à ce genre de subtilité : en lisant le code rapidement, on laisse passer des erreurs à cause d'un simple signe mal placé...

Et dans le cas ou plop vaut 3, rassurez moi, il y a une erreur de syntaxe à la ligne suivante ou ça passe comme une lettre à la poste??

Peut-être que s'il a suffisamment de poids, Google pourra se passer d'accord et lancer
son langage.

On a bien vu ce que ça a donné avec Microsoft et Internet Explorer... Je pense qu'il n'y a pas grand monde qui puisse souhaiter la même chose avec Google et Chrome!

Merci à toi et à eclipse pour ces précisions que j'avais ommises sur systemd (et notamment pour le lien vers la news sur la dépendance externe)

J'ajouterai : est-ce que cette gestion prends en charge le protocole CardDav (en tant que client) ? Ce protocole est disponible sur les smartphones depuis un moment (1 ou 2 ans pour iOS) et permet la synchro des contacts (tout comme CalDav permet la synchro des agendas, les deux étant basés sur du WebDav)).

• intégration du multi‐poste avec systemd ;

Ca peut paraître comme une "petite" fonctionnalité, mais je trouve ce truc énorme...
Surtout, ça sera une (quasi) première : jettez un oeil à la page http://fedoraproject.org/wiki/Features/Multiseat pour comprendre la finalité, et la simplicité potentielle d'utilisation de la solution. Je pense que systemd est un grand pas en avant dans la mise en oeuvre, ce qui explique pourquoi ce type de fonctionnalité a toujours un peu titubé et demandé des efforts à l'utilisateur. Lorsque ça marchera, ça devrait être d'une simplicité à toute épreuve...
J'imagine déjà le gain de temps, de place, d'argent pour les structures comme les bibliothèques ou les points d'accès Internet. je suis vraiment impatient que cette fonctionnalité arrive!

Très bon projet, je me permet néanmoins une remarque d'un point de vue de la sécurité : il est très dangereux de passer des arguments tels que des mots de passe (ou, dans le cas présent, une clef secrète) via la ligne de commande.
En effet, deux scénarios d'attaques sont alors facilement envisageables :
-quelqu'un qui a accès à l'historique (bash_history étant la manière la plus simple) connaitra alors toutes les clefs
-si c'est un script ou un cron qui l'exécute, il suffit d'avoir accès au script en question ou au crontab de l'utilisateur (assez facile)
-autre scénario, presque encore plus facile : réaliser un petit programme qui se charge de scruter la liste des process actifs, en permanence (équivalent de "ps aux" mais exécuté en continu, très rapidement). Dès qu'il trouve "winadminpassword" dans la liste, bingo, la clef est derrière!

Ainsi, la plupart des logiciels qui demandent un mot de passe ou une clef en entrée optent pour deux possibilités (pas forcément contradictoires) :
-lecture depuis un fichier : c'est la solution privilégiée pour l'exécution depuis un cron ou un script : le crontab est accessible potentiellement par tout le monde, mais pas le fichier "secret" qui ne contient que le mot de passe.
-lecture depuis l'entrée standard : cela impose certes un mode interactif, mais c'est la solution privilégiée lorsque l'on exécute le script manuellement.

Et pour le reste, "keep up the good work"!

ceci empêche d’utiliser n’importe quel système de virtualisation, tels que KVM ou VirtualBox.

Je ne comprends pas cette phrase : je ne vois pas en quoi ça empêche d'utiliser VirtualBox ou KVM, je dirais plutôt que cette approche est différente de celle de KVM et VirtualBox, qui tous deux virtualisent l'intégralité du système, alors que Xen nécessite une modification des noyaux des OS invités et hébergeur.

Quant au mot "empêche", c'est de toute manière généralement le cas : les fonctions de "nested virtualization" (virtualisation imbriquée) sont assez peu testée, et rarement conseillées.

Je suis à titre personnel un partisan d'OpenOffice/LibreOffice, mais je ne peux que regretter son interface graphique, trop vieillotte et qui l'empêche d'être adoptée par le commun des mortels. Je viens de découvrir la maquette dont l'image figure en lien dans l'article, et je dois dire que si LibreOffice devenait comme ça, ce simple "effet" cosmétique la ferait à mon avis adopter par de très très nombreuses personnes...
J'espère que les efforts de la communauté iront dans ce sens dans les prochaines version!

Je ne sais pas ce qui en particulier atterrit dans F14 (puisque je les ai au fur et à mesure par le dépot rawvirt), mais pas mal d'améliorations sur la couche réseau pour qemu+kvm (vhostnet : http://fedoraproject.org/wiki/Features/VHostNet ), beaucoup de corrections de bogues tant du coté de libvirt que de virt-manager, et une meilleure gestion des pools de disques et des réseaux dans virt-manager (gestion des réseau initiée depuis F13 d'ailleurs).

Tu trouveras quelque détails ici :
http://fedoraproject.org/wiki/Releases/14/FeatureList
Cela peut paraître en effet assez peu, surtout pour l'utilisateur final. Je pense que cette release est assez orienté développeurs.
D'un autre coté, l'intérêt des release régulières à dates quasi-fixes (comme Ubuntu mais pas comme Debian), c'est de proposer aux utilisateurs une distribution complète, fonctionnant "out-of-the box", et avec l'état de l'art des gros paquets (je pense à Gnome, KDE, etc...). Cela permet d'uniformiser un peu les versions que l'on va trouver d'un ordinateur à l'autre.
Personnellement, j'utilise beaucoup toutes les fonctionnalités de virtualisation, et j'attendais depuis un bon moment cette F14 : pour Spice, mais aussi pour quelques nouvelles fonctionnalités de qemu, virt-manager, etc... (jusque là j'ajoutais le dépot "rawvirt" pour en profiter).

Il semblerait que ce soit prévu, mais pas dans un futur proche (cela implique d'ajouter un driver totalement virtuel au sein d'un OS existant, ce qui est relativement différent de l'ajout d'un driver + un device virtuel via qemu).
Je pense que c'est relativement faisable néanmoins, mais le besoin n'est probablement pas aussi fort que celui d'un connexion broker opensource que Spice tente de combler!

Le problème n'est pas le débit, mais le "round-trip" : une application développée en faisant attention à ne pas faire d'aller-retour entre le serveur X et l'appli client s'exécutera très bien, même sur une ligne ADSL. Ce n'est malheureusement pas le cas de nombreuses applications (Firefox en est un exemple flagrant...). Je te conseille d'essayer la technologie NX en désactivant toutes les optimisations, sauf la suppression du round-trip, et tu seras surpris!! (J'ai déjà ouvert un bureau gnome à distance avec un ping de 250ms, sans avoir à préparer un café pour patienter...)
Spice est bien différent, dans le sens où il est fait pour cela : il compresse (éventuellement) les images, et envoie les requètes lorsque nécessaire au client (qui, dans un futur proche, utilisera les fonctionnalités avancées de sa carte graphique pour effectuer le rendu plus rapidement). Donc Spice fonctionne très (très) bien sur de l'ADSL/250ms (testé et approuvé par moi-même).

-non, cela fait partie des RFE, mais n'a pas la priorité des développeurs (c'est en effet pas évident à faire...)
-Pour l'instant il faut un client spécial pour avoir l'accélération (package spice-client), mais à noter que l'interface QXL (carte vidéo émulée) est compatible avec les deux flux (Spice et standard), ainsi dans Virt-manager tu peux voir l'écran et interagir avec, mais sans l'accélération QXL, l'audio, etc... Le développement d'un widget GTK pour integration dans virt-manager est prévue.