L'entreprise finnoise Tuxera, qui est à l'origine du driver libre ntfs-3g, propose un driver pour exFAT... sous licence propriétaire, en raison des accords (payants) qu'elle a dû passer avec Microsoft pour pouvoir publier ce driver. Déjà que les développeurs du noyau devaient il y a quelques mois à peine trouver des contournements intelligents aux brevets portant sur FAT [3], il est difficile d'envisager que les systèmes libres puissent un jour lire des données exFAT.
Pour info sur la LKM, il y a plus d'1 an, il y avait un patch [1] qui permettait de lire les partitions exFAT...
Et l'April met ça dans sa revue de presse sans checker un minimun la véracité de la chose...
Ils sont pas censés défendre le logiciel libre et essayer de la faire respecter par les fournisseurs de box.
Parce que là ça décrédibilise un max l'open source :
- libriste : he boss, on ne peut pas mettre des morceaux de la busybox (GPL) dans notre soft proprio
- boss : pourquoi ?
- libriste : ben parce que c'est du code GPL
- boss : pas de risque tout me monde s'en fou, regardes free & co
En général, les dev ne se font pas chier à coder un vrai système cryptographique à clé publique/privée, il se contente d'une solution simple.
C'est étrange comme les messages ressemble à u-boot [1]...
Or u-boot est sous GPL, il suffit de demander les sources pour en avoir l'algo utilisé.
Sinon je connais plusieurs boites qui ont utilisés un système à clé publique/privée. Le plus gros problème étant que souvent ce code n'est pas dans l'asic donc :
- on peut le dumper si on devient root [2]
- il n'est pas toujours possible de mettre des protections hardware pour empêcher de le reflaser de manière soft (eeprom avec WP/NOR avec secteurs de verrouillé).
- on peut les reflaser de manière hard.
echo toto & echo titi & echo tata ne l'est pas. Le résultat peut être :
toto
titi
tata
ou bien
tata
titi
toto
[...]
Quand a ajouter une limite à partir duquel "&" est bloquant c'est encore pire.
On fait quoi pour les scripts qui lance une série de programmes qui ne rende jamais la main ...
En tout cas il ne connait pas le concept de fonction macro pour eviter de dupliquer du code : toutes les fonctions dans math.c sont un copier/coller (indentation identique) à une chaine près...
L'accélération Xv est arrivée avec le drm des r600/r700 dans le kernel 2.6.31. Ça marche nickel pour lire pleins de films.
Donc on en est au niveau du driver "open source" [1] nv. C'est formidable...
[1] bon d'accord il est peut etre offusqué mais il marche.
Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données.
Donc on est obligé de maintenir une connection tcp pour chaque client. J'espère que les serveurs seront costaud pour tenir la charge.
A mon avis, GCC, parceque lorsqu'une optimisation rend le code plus lent, ce n'est guère pertinent.
Ben le pb, c'est que gcc a tendance a inline a fond en -O3 et qui est nefaste pour les caches.
C'est facile de descendre les perfs avec des `-g` en parallèle à des `-O2`.
Tu as des sources ?
Au dernière nouvelle -g n'ajoute que des symboles de debug, et ne modifie pas les optimisation.
Par contre ubuntu on tendance a compiler avec -fstack-protector qui n'est pas transparent.
Surtout que si tu veux etre en mode radin, il y a moyen d'imprimer des cartes depuis geoportail...voir même de faire un script qui reconstitue la carte
PS : depuis quelque temps il y a même les cartes marine sous geoportail...
Quand ton ordi "dort" comme ça, seule la RAM est raffraîchie, tout le reste est éteint.
Et non :
- la carte reseau qui attend une trame spéciale consome un peu
- l'usb peut consommer un peu (pour reveiller ton pc avec un clavier usb)
- ...
Pour la plupart des périphériques embarqués, c'est un mode de basse consommation pour le CPU, mais il est toujours un petit peu actif.
Encore faux.
Les périphériques embarqués peuvent soit avoir des modes basse conso ou le cpu est encore actif (équivalant des c state sur x86) ou alors ils peuvent être complétement éteints et la ram est en self refresh (+un block qui est chargé de rallumer le cpu sur un evenement (rtc, gpio, ...))
A noter que nvidia n'est pas obligé de maintenir le driver nv. Il pourrait laisser les gens n'utilisant pas le driver proprio se demerder avec vesa (comme certaine puces ATI).
Par contre le support de ces cartes c'est dégradé dans *debian*. J'ai du attendre des mois avant qu'ils integrent la version du legacy 96xx compatible avec les kernel récent...
# ...
Posté par M . En réponse au journal Le système de fichiers exFAT, dans la lignée des autres FAT, une menace pour la compatibilité des appareils mobiles avec les systèmes libres. Évalué à 4.
Pour info sur la LKM, il y a plus d'1 an, il y avait un patch [1] qui permettait de lire les partitions exFAT...
[1] http://marc.info/?l=linux-kernel&w=2&r=1&s=exFAT(...)
[^] # Re: Gestion des flux rss
Posté par M . En réponse au journal Chrome disponible sous linux. Évalué à 3.
Idem pour un lecteur mail.
# orange ouvre les logiciels libres de sa livebox
Posté par M . En réponse à la dépêche Revue de presse de l'April pour la semaine 48. Évalué à 3.
Et l'April met ça dans sa revue de presse sans checker un minimun la véracité de la chose...
Ils sont pas censés défendre le logiciel libre et essayer de la faire respecter par les fournisseurs de box.
Parce que là ça décrédibilise un max l'open source :
- libriste : he boss, on ne peut pas mettre des morceaux de la busybox (GPL) dans notre soft proprio
- boss : pourquoi ?
- libriste : ben parce que c'est du code GPL
- boss : pas de risque tout me monde s'en fou, regardes free & co
[^] # Re: De toutes façons...
Posté par M . En réponse au journal Orange publie le code source de la Livebox ... ou presque. Évalué à 4.
C'est étrange comme les messages ressemble à u-boot [1]...
Or u-boot est sous GPL, il suffit de demander les sources pour en avoir l'algo utilisé.
Sinon je connais plusieurs boites qui ont utilisés un système à clé publique/privée. Le plus gros problème étant que souvent ce code n'est pas dans l'asic donc :
- on peut le dumper si on devient root [2]
- il n'est pas toujours possible de mettre des protections hardware pour empêcher de le reflaser de manière soft (eeprom avec WP/NOR avec secteurs de verrouillé).
- on peut les reflaser de manière hard.
[1] http://www.google.fr/search?hl=fr&q=%22Using+default+env(...)
[2] la personne du blog livebox-mini semble y être parvenu, donc elle pourrait le faire
# not a 0day
Posté par M . En réponse au journal 0day sur FreeBSD !. Évalué à 4.
[^] # Re: Exemple d'utilisation
Posté par M . En réponse au journal executions de commandes shell en parallele: par. Évalué à 4.
#! /bin/sh
LIMIT=4
para()
{
while [ $(jobs | wc -l) -ge $LIMIT ]
do
sleep 1
done
echo "starting $1"
$@ &
return 0;
}
para sleep 10
para sleep 100
para sleep 1
para sleep 10
para sleep 1
para sleep 10
para sleep 1
para sleep 10
echo "end..."
wait
[^] # Re: Exemple d'utilisation
Posté par M . En réponse au journal executions de commandes shell en parallele: par. Évalué à 3.
echo toto
echo titi
echo tata
est déterministe
echo toto & echo titi & echo tata ne l'est pas. Le résultat peut être :
toto
titi
tata
ou bien
tata
titi
toto
[...]
Quand a ajouter une limite à partir duquel "&" est bloquant c'est encore pire.
On fait quoi pour les scripts qui lance une série de programmes qui ne rende jamais la main ...
[^] # Re: roudme
Posté par M . En réponse au journal Changer le mode d'arrondi IEEE754 avec roundme. Évalué à 3.
[^] # Re: C'est le moment où on regrette de pas avoir attendu une chouille !
Posté par M . En réponse à la dépêche Open Graphics lance la production de l'OGD1. Évalué à 1.
Donc on en est au niveau du driver "open source" [1] nv. C'est formidable...
[1] bon d'accord il est peut etre offusqué mais il marche.
[^] # Re: Push
Posté par M . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 4.
Donc on est obligé de maintenir une connection tcp pour chaque client. J'espère que les serveurs seront costaud pour tenir la charge.
[^] # Re: Un serveur qui fait du push
Posté par M . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 3.
[^] # Re: Un serveur qui fait du push
Posté par M . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.
[^] # Re: Mais wine marche !
Posté par M . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 3.
Le seul pb, c'est pour les jeux dos utilisant vm86 et des jeux qui font des trucs un peu louche.
Du coup on se demande pourquoi autant de machine n'ont pas un mmap_min_addr non null...
[^] # Re: Vérification à faire avec Ubuntu
Posté par M . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 3.
[^] # Re: SIP is dead ?
Posté par M . En réponse à la dépêche Skype envisage une libération partielle du client Linux. Évalué à 2.
[^] # Re: Question
Posté par M . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 2.
Ben le pb, c'est que gcc a tendance a inline a fond en -O3 et qui est nefaste pour les caches.
[^] # Re: A chaud.
Posté par M . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 5.
Tu as des sources ?
Au dernière nouvelle -g n'ajoute que des symboles de debug, et ne modifie pas les optimisation.
Par contre ubuntu on tendance a compiler avec -fstack-protector qui n'est pas transparent.
[^] # Re: Se passer des cartes papier
Posté par M . En réponse au journal OpenStreetMap dans le Monde. Évalué à 2.
PS : depuis quelque temps il y a même les cartes marine sous geoportail...
[^] # Re: Petite question...
Posté par M . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 4.
Et non :
- la carte reseau qui attend une trame spéciale consome un peu
- l'usb peut consommer un peu (pour reveiller ton pc avec un clavier usb)
- ...
Pour la plupart des périphériques embarqués, c'est un mode de basse consommation pour le CPU, mais il est toujours un petit peu actif.
Encore faux.
Les périphériques embarqués peuvent soit avoir des modes basse conso ou le cpu est encore actif (équivalant des c state sur x86) ou alors ils peuvent être complétement éteints et la ram est en self refresh (+un block qui est chargé de rallumer le cpu sur un evenement (rtc, gpio, ...))
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par M . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 1.
# .
Posté par M . En réponse au journal Nespresso attaque Chacun son café. Évalué à 3.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par M . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 3.
Par contre le support de ces cartes c'est dégradé dans *debian*. J'ai du attendre des mois avant qu'ils integrent la version du legacy 96xx compatible avec les kernel récent...
[^] # Re: Précision
Posté par M . En réponse à la dépêche Sparse repasse à l'attaque. Évalué à 6.
Notament Stanse aurait trouvé des bugs dans le kernel : http://lwn.net/Articles/356785/
[^] # Re: Le noyau mais le système ?
Posté par M . En réponse au journal HTC Hero : Le noyau est disponible. Évalué à 4.
[^] # Re: Pourquoi deux pilotes?
Posté par M . En réponse au journal Vidéo AMD/ATI : le futur ne manque pas d'avenir. Évalué à 5.
Pas sur leur dernier chip GMA500 : http://kubuntuforums.net/forums/index.php?topic=3105729.5;wa(...)
Que leurs puces sont moins performantes donc plus simples à piloter?
Je pense que ca doit pas mal y jouer.