Salut.

C'est encore avec beaucoup de retard, après une fin d'année 2012 très compliquée pour moi, que je vous livre ces dernières mesures...

Voici les résultats comparatifs de Fedora 18 vs Fedora 17.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :

• Installation de Fedora 18 version 32 bits avec le noyau Fedora 3.6.10-4.fc18.i686.PAE.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 18 et exécuté sous Fedora 18 (noyau Fedora 3.6.10-4.fc18.i686.PAE).
• 10 séries de tests avec UnixBench compilé sous Fedora 17 et exécuté sous Fedora 17 (noyau Fedora 3.3.4-5.fc17.i686).

Voici les résultats obtenus :

Fedora 18 version 32 bits :

Série 1 : 755.2
Série 2 : 747.9
Série 3 : 757.8
Série 4 : 771.8
Série 5 : 764.7
Série 6 : 759.2
Série 7 : 764.8
Série 8 : 759.0
Série 9 : 766.7
Série 10 : 748.7

Moyenne : 759.6

Fedora 17 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 17 :
Série 1 : 720.6
Série 2 : 720.1
Série 3 : 717.1
Série 4 : 728.1
Série 5 : 735.0
Série 6 : 736.3
Série 7 : 727.2
Série 8 : 719.6
Série 9 : 738.5
Série 10 : 719.7

Moyenne : 726.2

Résultats :

Pour Fedora 18, on obtient un indice moyen de 759.6 pour UnixBench.
Pour Fedora 17, j'avais obtenu un indice moyen de 726.2 pour UnixBench.


On a donc un gain moyen de près de 4.6 % de Fedora 18 32 bits par rapport à Fedora 17 32 bits...
On assiste encore une fois à une légère amélioration des performances avec cette nouvelle version de Fedora comme montré sur la figure suivante :

Conclusion :

Au moment de ces tests, le noyau Fedora 18 (basé sur le noyau vanilla 3.6.10) propose un gain de 4.6 % par rapport au noyau Fedora 17 (basé sur le noyau vanilla 3.3.4), ce qui le ramène au niveau de Fedora 7 (soit au début de mes tests !).


++

Original post of Eddy33.Votez pour ce billet sur Planet Libre.

 

Dans un de mes derniers articles, je vous parlais d'Ubuntu Touch.

Ce matin Jono Bacon, Community Manager d'Ubuntu, a publié un article à propos d'Ubuntu Touch, dans lequel il donne quelques informations sur le futur OS pour mobiles et sur son développement.

On y apprend notamment que la version 1.0 est prévue pour Octobre 2013, soit au moment de la sortie de la version 13.10 d'Ubuntu, ce qui laisse présager une intégration d'Ubuntu Touch dans la version desktop d'Ubuntu. Le système pourrait ainsi être déployé chez les utilisateurs sur des mobiles au cours du premier semestre 2014.

Au niveau du développement, Jono Bacon donne un aperçu des équipes en place :

• 15 équipes d'ingénieurs
• 5 équipes de design
• 5 "services teams"

Tout ceci totalisant plus de 150 personnes.

Il précise enfin que le développement avance à bon train, malgré la taille du projet, les fuseaux horaires différents entre chaque équipes et les problèmes que celles-ci on pu rencontrer en route.

Tout ceci aurait pu n'être qu'un discours pipeau et enjoleur de Community Manager, mais Jono Bacon annonce tout de même qu'à l'heure actuelle Ubuntu Touch n'est pas utilisable comme principal OS sur un mobile, puisque certaines fonctions ne sont pas ou très peu implémentées, et que cela reste des versions en cours de développement.

 

On s'aperçoit donc que le développement d'Ubuntu Touch suit son cours, il reste encore 6 mois aux équipes pour finaliser une version 1.0 qui soit utilisable par Mme. Michu.

J'attend donc avec encore plus d'impatience une version stable à installer sur un smartphone pour pouvoir la tester, ou au moins un portage d'Ubuntu Touch vers un modèle de smartphone que j'ai en stock à la maison pour pouvoir jouer un peu avec!

Source Image

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Ça faisait un petit moment que je n’avais pas fait un petit plat indien inédit. C’est résolu cette semaine avec cette recette de poulet à la coriandre (aux coriandres ?? en poudre et en feuilles) et à l’amande, dont les saveurs sont délicates et délicieuses. Doux et fondant, c’est un plat de fête en Inde et je comprends pourquoi. A essayer de toute urgence.

Ingrédients :

• 1 poulet ou 8 morceaux de poulet
• 2 oignons
• 4 gousses d’ail
• 2 piments verts
• 5 cm de gingembre
• 6 càs d’huile d’arachide ou de ghee
• 2 feuilles de laurier
• 1,5 càs de coriandre en poudre
• 1 càs de cumin en poudre
• 1/4 de càc de piment en poudre (optionnel)
• 1/4 de càc de curcuma en poudre
• 1/4 de càc de paprika
• 2 càc de sel
• 1 càc de poivre noir moulu
• 4 càs de coriandre en feuille hachées
• 50 g de poudre d’amande
• 170 ml de crème fraîche épaisse

1. Couper le poulet et le débiter en morceaux si ce n’est pas le cas. Retirer la peau.
2. Hacher finement l’oignon, l’ail, le gingembre, les piments.
3. Faire chauffer l’huile dans une cocotte. Une fois qu’elle est chaude, y faire revenir le mélange à base d’oignon et les feuilles de laurier jusqu’à ce que ça commence à dorer. Remuer souvent.
4. Ajouter alors le poulet et laisser cuire environ 10 minutes. L’ensemble doit être coloré.
5. Ajouter la coriandre en poudre, le cumin, le curcuma, le paprika, le piment, le sel et le poivre. Bien remuer et laisser cuire 3 minutes.
6. Mouiller alors avec 10 cl d’eau et cuire 5 minutes jusqu’à obtention d’une belle sauce épaisse.
7. Rajouter 15 cl d’eau, porter à ébullition et laisser cuire à couvert à feu doux pendant 20 minutes.
8. Ajouter ensuite les 3/4 de la coriandre hachée et bien remuer. A ce stade, vous pouvez laisser mijoter tout doucement pour ne faire la dernière étape qu’au moment de servir.
9. Avant de servir, mélanger la poudre d’amande et la crème fraîche, puis ajouter ce mélange dans la cocotte et bien amalgamer la sauce.
10. Servir avec un riz blanc basmati.

Le poulet à la coriandre et à l’amande est un billet du Michtoblog Si vous aimez la cuisine, visitez l'index des recettes classées. Si vous préférez Ubuntu, c'est sur cette page. Pour Firefox, c'est sur cette autre page. Et les archives du blog sont ici.

Original post of agatzebluz.Votez pour ce billet sur Planet Libre.

C’est dit dans le man, xauth est un programme gérant les autorisations de connexion au serveur X11. Il est désigné comme le remplaçant de xhost, qui était bien permissif et bien connu pour les détournements de X11.

xauth utilise un fichier qui contient une liste de display names associés à des nombres en hexadécimal qui représentent le magic cookie. Ce fichier est soit sous ~/.Xauthority, soit, lorsque l’utilisateur courant utilise un gestionnaire de fenêtre,  sous l’arborescence de run du gestionnaire. Par exemple, pour Gnome, le fichier est sous /var/run/gdm3/auth-for-bux-*/ et se nomme database.

Le principe est simple : les applications clientes requêtant le serveur X11 lisent et fournissent ce magic cookie, et si la valeur est conforme à celle que le serveur X11 a en mémoire, alors le client est autorisé à ouvrir une fenêtre sur le serveur X11. Vu que le .Xauthority a des permissions en 600, il est théoriquement impossible pour quelqu’un d’autre de lire et d’utiliser ce magic cookie.

Pour voir le contenu du .Xauthority, on peut le cat ou tout simplement utiliser xauth pour nous afficher ce qu’il a dans le ventre :

[bux@lab~]# xauth list
lab/unix:10    MIT-MAGIC-COOKIE-1 1b3f3b17eae0702b9d1972054d857159

[bux@lab~]# xauth info
Authority file:    /var/run/gdm3/auth-for-bux-03kwJ9/database
File new:          no
File locked:       no
Number of entries: 1
Changes honored:   yes
Current input:     (argv):1

En local, pour l’utilisateur, il n’y a donc pas de problème. Là où il faut jouer, c’est lorsque l’utilisateur choisit de solliciter le X11 d’un poste distant, ou bien que l’utilisateur passe root en local en jouant avec su. En effet, il faut alors propager ce magic cookie afin qu’il puisse toujours utiliser le X11.

2 méthodes pour cela. Toutes les 2 partent du même point : il faut récupérer le magic cookie.

La première méthode concerne le cas de figure où, par exemple, l’utilisateur souhaite juste utiliser le X11 d’une machine distante. Pour ce faire, il lui faut extraire les données d’autorisation et les propager à l’hôte distant. Fait simplement, ça donne ça :

[bux@lab~]# xauth extract - lab/unix:10 | ssh remotelab xauth merge -

Comme le Xauthority est en 600, seul l’utilisateur en question ou root peut utiliser merge.

La seconde méthode est plus dans l’optique d’un su – de l’utilisateur qui souhaiterait du coup continuer à utiliser les services du X11 de l’hôte sur lequel il est connecté. Le merge fonctionne aussi, mais comme on sait déjà le faire, on va plutôt jouer avec add :

[bux@lab~]# xauth add lab/unix:10 MIT-MAGIC-COOKIE-1 1b3f3b17eae0702b9d1972054d857159

Après le add, et vu qu’on est toujours sur le même host, et qu’on a juste su – , il suffit alors d’exporter le DISPLAY conformément à ce qu’il y a dans le Xauthority :

[root@lab~]# export DISPLAY= localhost:10

And voilà…

[Photo par Jeroen Bennink]

Original post of K-Tux.Votez pour ce billet sur Planet Libre.

Pour fêter la sortie de Debian Wheezy je me permet de vous partager mon petit script de post-installation.

Vous allez me dire c’est pas très propre etc etc… Donc n’hésiter pas à utiliser les commentaires pour vos suggestions, bugs…

Téléchargement

Le script permet :

• installation de ntp fail2ban htop rkhunter tree most ccze mc iftop smartmontools hdparm safe-rm molly-guard lm-sensors iotop apt-listbugs ;
• ajout d’un bashrc permettant la colorisation du terminal, ajoutant la colorisation des logs via cless et ctail ;
• ajout des dépôt non-free et contrib ;
• possibilité d’installer webmin, virtualbox…
• et bien d’autres…

The post Script post-installation Debian Wheezy appeared first on TheLinuxFr.

Original post of TheLinuxFr.Votez pour ce billet sur Planet Libre.