Discussion :

[Francis Walter]

Fedora 21 annoncé pour octobre prochain
l’OS introduira un niveau de sécurité identique pour toutes les applications

Après la version 20 publiée en décembre dernier, le comité de pilotage de Fedora a enfin validé les modifications qui seront apportées à la version 21. La nouvelle version devrait voir le jour dans le courant du mois d’octobre prochain.

Fedora 21 apporte des fonctionnalités plus ou moins impressionnantes. Elles touchent particulièrement les mesures de sécurité disponibles sur Fedora et les renforcent. On peut noter :

• un système de chiffrement unique pour toutes les applications de Fedora. Pour ce faire, la bibliothèque SSL sera modifiée afin d’avoir un niveau de sécurité identique pour toutes les applications qui s’exécutent sur Fedora.
• un contrôle d’accès PC/SC pour empêcher les processus non autorisés :
  
  • d’accéder aux données disponibles sur une carte à puce ;
  • d’effacer des données disponibles sur une carte à puce ;
  • de communiquer avec la carte à puce.
  
  
• une mise à jour de la pile Python 3.3 qui passera à Python 3.4 ;
• le retrait de python-setuptools-devel, tous les paquets qui l’utilisent devront désormais utiliser python-setuptools
• la mise à jour de Ruby 2.0.0 à Ruby 2.1 apportant de fortes augmentations de la vitesse, l'efficacité et la fiabilité de mémoire.
• Le support d’OpenCL afin de soutenir le développement de logiciels OpenCL. On notera que Mesa sera activé par défaut avec l’introduction de plusieurs autres paquets supportant OpenCL.

Source : Fedora 21 Change Set

Et vous ?

Que pensez-vous des nouvelles fonctionnalités ?

Auriez-vous aimé voir d'autres changements ? Lesquels ?

[mangobango]

Euh, "mesa sera activé par défaut"? C'est déjà activé par défaut. Est-ce alors des optimizations OpenCL pour Mesa qui seront activées? Ou le state tracker Clover qui sera distribué aussi? Après lecture de la news d'origine, c'est cette dernière proposition qui est la bonne. Il y aura aussi POCL et peut être Beignet. De quoi booster un peu l'adoption d'OpenCL! Mais ça fait un trèèèèèès long cycle de développement pour une Fedora!

Daniel

[Mr_Exal]

Auriez-vous aimé avoir autres changements ? Lesquels ?

Que ma carte réseau soit prise en charge (Qualcomm killer truc :/ )

[xyassinex]

une meilleure gestion de la fat32 ne sera pas de refus.
parce que jusque là, ça me prend "des années" pour copié quelque gigaoctect sur une clé usb, "15 min/giga et des fois pire" ça va tres vite sur une ntfs, mais voilà, ya des lecteurs qui supportent pas la ntfs: mini chaine, demodulateur, et autres... merci

[LittleWhite]

N'est ce pas plutôt à cause de la vitesse du périphérique en lui même (l'USB est lent, très lent) ? Car en soit, le FAT32 est bien géré.

[Mr_Exal]

N'est ce pas plutôt à cause de la vitesse du périphérique en lui même (l'USB est lent, très lent) ? Car en soit, le FAT32 est bien géré.

Ou même des limites de transfert en fat32 ?

[LittleWhite]

Je connais la limite des 4 Go. Mais une limite de vitesse, j'ai un peu de mal à concevoir. Pouvez-vous me l'expliquer.

[Mr_Exal]

Je connais la limite des 4 Go. Mais une limite de vitesse, j'ai un peu de mal à concevoir. Pouvez-vous me l'expliquer.

C'était une supposition et non une affirmation d'où le point d'interrogation.

[LittleWhite]

Oui, mais alors, expliquez comment une telle hypothèse vous ai venu ?
Non, je pense que le FAT32, en terme de performances, ok, peut être un peu inférieur en cas de disque fragmenté, que le NTFS, mais pas de quoi piquer une crise ni faire un drame. Là, je pense juste que l'utilisateur se plaint du long temps de transfert vers une clé USB, qui est oui, toujours méga long, même en USB2. Mais ça, ce n'est pas lié au système de fichier (surtout que le système de fichier sur une clé doit être simple, au possible), mais à la lenteur des communications USB (< 3)

[xyassinex]

Salut:
J'essaye d'être un peu plus clair, mais voilà que je n'ai pas des connaissances si poussé de ce côté là. Quand je parler de la gestion de la FAT32, je n'ai pas mis en cause les performance de la clé usb en juste cause que celà était constater sur plusieurs clé et disque dur usb. que seul leur system de fichier se diffèrent. non plus la fragmentation possible, car là si c'est le cas, le temps d'écriture ne serais pas assi long. je n'ai pas éxagérer en disant (15min/gigaoctect) parce que c'est vraiment le cas, et ça vient aussi de mon autre ordinateur avec fedora 20 x64 installer!

Voici les résultats faire par test de performances de l'utulitaire Disques sur le même disque dur monter sur SATA: (histoire d'écarté USB d'ếtre en cause)

Systeme de fichier: EXT4
Taille de l'échantillon: 10.0 Mio
Vitesse moyenne de lecture : 61.8Mo/s
Vitesse moyenne d'écriture: 28.4Mo/s
Moyenne des temps d'accès: 8.71 ms

Systeme de fichier: NTFS
Taille de l'échantillon: 10.0 Mio
Vitesse moyenne de lecture : 61.7Mo/s
Vitesse moyenne d'écriture: 30.5Mo/s
Moyenne des temps d'accès: 9.15 ms

Systeme de fichier : FAT32
Taille de l'échantillon: 10.0 Mio
Vitesse moyenne de lecture : 61.6Mo/s
Vitesse moyenne d'écriture: 29.8Mo/s
Moyenne des temps d'accès: 9.42 ms

Vous pouver constater là une légère baisse de performances, mais là n'ai pas le probleme. c'est en cour de copie de gros fichers que l'opération se fait presque à la même vitesse de ~10 à ~35 Mo/s (à cause d'utulisation des disques par d'autre processus) sur les trois system de fichier sauf que sur la FAT32, ça prends beaucoup plus de temps non pas à cause de la vitesse qui elle rest presque la même, mais à cause des pauses/reprises de copie tres fréquentes. pour bien expliqué, c'est que je peu voire la barre de progression qui monte à une vitesse donné et puis, il y a des arrếts qui affichent 0 Mo/s, ça dur des sec/min et puis une reprise.
J'ai remis les même test sur mon deuxieme ordinateur, les resultats sont presque les mêmes. (je n'avais pas ça quand j'utulisé windows)
En cherchant un peu sur google, j'ai trouvé quelque gens qui on la meme chose et des réponse qui ciblent la mauvaise gestion de la fat par fedora, et c'est ce que j'approuve aussi! voilà, j'éspere étais un peu plus claire.
Merci pour votre attention.

[Mr_Exal]

Oui, mais alors, expliquez comment une telle hypothèse vous ai venu ?
Non, je pense que le FAT32, en terme de performances, ok, peut être un peu inférieur en cas de disque fragmenté, que le NTFS, mais pas de quoi piquer une crise ni faire un drame. Là, je pense juste que l'utilisateur se plaint du long temps de transfert vers une clé USB, qui est oui, toujours méga long, même en USB2. Mais ça, ce n'est pas lié au système de fichier (surtout que le système de fichier sur une clé doit être simple, au possible), mais à la lenteur des communications USB (< 3)

J'ai pas trouvé les débits de transfert moyen en fat32 (ça dépend de l'interface de toute façon).