AuFS est maintenu, mais ne sera à priori jamais mergé. Étant donné que la plupart de ses cas d’utilisations sont couverts par OverlayFS (mais pas tous, bien que je ne connaisse pas les détails), il y a des chances pour qu’AuFS disparaisse à l’avenir (que ça soit de docker, des différents systèmes live, etc.).
Je me demandais quels étaient vos avis sur l’arrivée d’un client de messagerie texte/voix/vidéo dans Firefox: Hello.
Je sais que vos objectifs respectifs (SàT, Movim, Jappix) sont de faire bien plus que du chat, mais je me demande quel est votre positionnement par rapport au fait que les 500 millions d’utilisateurs de Firefox vont avoir accès à de la messagerie instantanée p2p chiffrée en end-to-end.
N’est-ce pas une formidable opportunité pour faire du XMPP over WebRTC (à la BOSH ?) ? Est-ce qu’il n’y a pas un risque que Firefox Hello supplante les messageries instantanées basiques (l’espoir fait vivre) ?
Posté par Aissen .
En réponse au journal 3D pour VM.
Évalué à 4.
Tu l’as bien compris, l’état de l’art en open source c’est bien virgil3d. Pour voir ce qui se fait en proprio, il faut regarder du côté de VMWare Fusion (https://labs.vmware.com/academic/publications/gpu-virtualization pour le papier expliquant l’archi) ou de Parallels.
Effectivement, ma tentative de lancer une réflexion sur vie privée vs liberté avec Mozilla Location Services a été publiée le 30/10 et n’a pas vraiment pu "décanter" avant de dépasser "la note fatidique des 25".
Je ne suis pas sûr qu’alendroi était si sarcastique (on ne sait jamais sur Internet, n’oubliez pas vos smileys avec votre sarcasme)
Cela dit je suis d’accord que la co-maintenance pourrait fortement aider les mainteneurs de paquets en général. À voir si quelqu’un veut filer un coup de main, et si la collaboration peut marcher.
Le système même d’API keys ne fonctionne pas à partir du moment où les applications sont distribuées dans la nature (c’est à dire ne tournent pas sur un serveur).
J’ai pourtant essayé d’expliquer le système dans le journal:
Le principe est simple: on envoie la liste des points d’accès wifi qu’on voit et leur puissance à un serveur, qui va ensuite nous renvoyer notre position. Les mobiles qui demandent ces données participent aussi à les remonter une fois le GPS verrouillé: c’est du donnant-donnant.
Je retente:
Le principe est simple: le mobile envoie la liste des points d’accès wifi qu’il voit et leur puissance au service distant de geolocalisation; le service cherche les adresses MAC de points d’accès dans sa base de données, et s’il connait un ou plusieurs de ces points d’accès, renvoie une position triangulée au mobile.
Un fois que le mobile a son GPS verrouillé, il envoie sa position GPS avec la liste des points d’accès au service. C’est comme ça que le service remplit sa base de données d’associations entre points d’accès et coordonnées.
$ man terminology
-s=vh-, --split=vh-
Terminology can start with splits opened as described below. The arguments are a string with the following characters:
-s v splits terminal vertically
-s h splits horizontally
- defines a placeholder for a shell or a command when used with
--exec/-e
Examples:
______
| | |
$ terminology -s v |__|__|
______
|_____|
$ terminology -s h |_____|
______
|__| |
$ terminology -s vh |__|__|
______
| |__|
$ terminology -s v-h |__|__|
______
$ terminology -s vh--h |__|__|
hv--v |__|__|
Type: STR.
$ terminology --help |&grep -A2 split
-S=SPLIT, --split=SPLIT
Split the terminal window. 'v' for vertical and 'h'
for horizontal. Can be used multiple times. eg -S
vhvv or --split hv More description available on the
man page.
Type: STR.
Elle a eu sa période systemd puis est revenue aux scripts à la BSD pour de multiples raisons qui ne sont pas le sujet de ce journal
Vendredi est dans deux jours, il est encore temps de faire un journal ou une dépêche prête à péter tous les records. Plus sérieusement, ça pourrait être très intéressant ce genre de feedback, vu que systemd semble avoir beaucoup d’attrait auprès des mainteneurs de distros de part la charge de travail qu’il semble leur enlever; qu’en est-il pour 0linux ?
C’est justement le sujet du papier pointé par mon deuxième commentaire, qui montre comment implémenter ça de manière à résister à des analyses statistiques et de manière invisible sur les photos du die.
À partir d’Ivy Bridge(Core 3ème génération), les processeurs Intel incluent l’instruction RDRAND. Elle est incroyablement performante (500Mo/s), dans la mesure où elle peut s’exécuter en assez peu de cycles. Elle est utilisable en userspace. Elle repose sur un transistor mit dans un état "metastable", qui dérive à chaque coup de clock aléatoirement vers un 1 ou un 0. Ça seed ensuite un PRNG basé sur un hash/CBC. Je te laisse lire les différents papiers (d’Intel et d’universitaires) et brevets sur le sujet: https://sites.google.com/site/intelrdrand/references
Si tu lis le lien wikipedia plus haut, tu verras aussi qu’il est possible que le générateur d’Intel soit backdooré par la NSA (ou pas), mais c’est impossible à prouver. Des scientifiques on même prouvé qu’on pouvait truquer un générateur aléatoire hardware "propre" de manière à résister à une analyse de die, mais j’ai plus la référence.
Ben avec tous les jeux linux qui sortent chaque semaine sur Steam et le Humble Store, ils doivent avoir un sacré backlog à rattraper. Faut les comprendre !
Il est dans le document, page 207. La dépêche ne cite qu’un extrait de ceux qui ont contribué au libre. Je viens d’ailleurs de voir qu’un fondateur de Talend, Cédric Carbone, un ETL Open Source, présent dans le document de Krim, a été oublié dans la dépêche.
La liste est sympa, mais ce qui est intéressant aussi, c’est le fond du rapport. Daniel Glazman en parle d’ailleurs sur son blog.
Morceaux choisis:
le tropisme persistant en faveur des Grands Groupes est une vraie réalité.
…
Le problème est la formation à l’entrepreneuriat, lamentable voire absente. Il faut inciter les développeurs à se lancer, leur montrer la voie, leur faire créer de la valeur et de l'emploi
…
il faut arrêter de considérer que les SSII font de la technologie… Elles vendent de la viande et rares sont celles qui ne livrent pas de la merde.
Après le sujet est assez vaste, et on peut regretter que ce rapport soit assez léger sur certains points (et à côté de la plaque sur d’autres, comme le « Github français »). Néanmoins, il a le mérite de lancer le débat. D’ailleurs Daniel Glazman pourrait écrire un second rapport, avec plus de propositions pour faire bouger les choses.
Opensource, mais la situation n’est pas vraiment comparable:
- il n’est pas upstream
- ça n’utilise pas les infrastructures du kernel (ttm/gem, dma-buf, drm core, etc.)
- c’est juste la partie gpu donc pas de display, modesetting in-kernel, etc.
- il n’y a(vait) pas d’implémentation libre de la partie userspace. Lima n’est pas encore prêt ou intégré aux distributions (ni même à mesa, mais pour d’autres raisons).
C’est pour ça que je n’en ai pas parlé. D’autres drivers ARM sont dans la même situation, mais on ne peut pas comparer avec NVIDIA qui pourrait venir à utiliser nouveau pour le Tegra ou AMD qui pourrait utiliser radeon pour catalyst.
[^] # Re: OverlayFS intégré
Posté par Aissen . En réponse à la dépêche Sortie du noyau Linux 3.18. Évalué à 4.
AuFS est maintenu, mais ne sera à priori jamais mergé. Étant donné que la plupart de ses cas d’utilisations sont couverts par OverlayFS (mais pas tous, bien que je ne connaisse pas les détails), il y a des chances pour qu’AuFS disparaisse à l’avenir (que ça soit de docker, des différents systèmes live, etc.).
# Firefox Hello ?
Posté par Aissen . En réponse au journal De l'autre côté. Évalué à 3.
Je me demandais quels étaient vos avis sur l’arrivée d’un client de messagerie texte/voix/vidéo dans Firefox: Hello.
Je sais que vos objectifs respectifs (SàT, Movim, Jappix) sont de faire bien plus que du chat, mais je me demande quel est votre positionnement par rapport au fait que les 500 millions d’utilisateurs de Firefox vont avoir accès à de la messagerie instantanée p2p chiffrée en end-to-end.
N’est-ce pas une formidable opportunité pour faire du XMPP over WebRTC (à la BOSH ?) ? Est-ce qu’il n’y a pas un risque que Firefox Hello supplante les messageries instantanées basiques (l’espoir fait vivre) ?
# État de l’art
Posté par Aissen . En réponse au journal 3D pour VM. Évalué à 4.
Tu l’as bien compris, l’état de l’art en open source c’est bien virgil3d. Pour voir ce qui se fait en proprio, il faut regarder du côté de VMWare Fusion (https://labs.vmware.com/academic/publications/gpu-virtualization pour le papier expliquant l’archi) ou de Parallels.
[^] # Re: Dépêche publiée trop tôt ?
Posté par Aissen . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés de novembre 2014. Évalué à 4.
Effectivement, ma tentative de lancer une réflexion sur vie privée vs liberté avec Mozilla Location Services a été publiée le 30/10 et n’a pas vraiment pu "décanter" avant de dépasser "la note fatidique des 25".
[^] # Re: Enlightenment 0.17
Posté par Aissen . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 2.
Je ne suis pas sûr qu’alendroi était si sarcastique (on ne sait jamais sur Internet, n’oubliez pas vos smileys avec votre sarcasme)
Cela dit je suis d’accord que la co-maintenance pourrait fortement aider les mainteneurs de paquets en général. À voir si quelqu’un veut filer un coup de main, et si la collaboration peut marcher.
[^] # Re: Enlightenment 0.17
Posté par Aissen . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 8.
On en est juste à E19.1 ;-)
https://tracker.debian.org/pkg/e17
http://enlightenment.org/p.php?p=download&l=en
[^] # Re: Incompatible GPLv3?
Posté par Aissen . En réponse au journal Mozilla location services: quand il faut choisir entre liberté et vie privée. Évalué à 2.
Le seul rapport avec OAuth c’est qu’il y a un secret qui est "caché" dans l’application.
[^] # Re: Incompatible GPLv3?
Posté par Aissen . En réponse au journal Mozilla location services: quand il faut choisir entre liberté et vie privée. Évalué à 2.
Sans même parler de GPLv3, il est possible d’extraire des API keys de n’importe quelle application cliente; Twitter l’a apprit à ses dépends:
http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/
https://gist.github.com/rhenium/3878505
Le système même d’API keys ne fonctionne pas à partir du moment où les applications sont distribuées dans la nature (c’est à dire ne tournent pas sur un serveur).
[^] # Re: Comment ça marche
Posté par Aissen . En réponse au journal Mozilla location services: quand il faut choisir entre liberté et vie privée. Évalué à 6.
J’ai pourtant essayé d’expliquer le système dans le journal:
Je retente:
[^] # Re: split
Posté par Aissen . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 5.
Et là je vois le problème, la manpage est fausse:
Je vais essayer de remonter le problème upstream.
[^] # Re: split
Posté par Aissen . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 3.
[^] # Re: Evince ?
Posté par Aissen . En réponse au journal PDF d'un site de l'administration illisible. Évalué à 7.
<troll>Oui, ils ont fait beaucoup de travail pour rattraper Okular.</troll>
# Retour sur systemd
Posté par Aissen . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 2.
Vendredi est dans deux jours, il est encore temps de faire un journal ou une dépêche prête à péter tous les records. Plus sérieusement, ça pourrait être très intéressant ce genre de feedback, vu que systemd semble avoir beaucoup d’attrait auprès des mainteneurs de distros de part la charge de travail qu’il semble leur enlever; qu’en est-il pour 0linux ?
PS: http://0.tuxfamily.org/doku.php/communaute/papier_peints <--- le doku wiki semble down
[^] # Re: Apparemment, tout ne serait pas terminé...
Posté par Aissen . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 4.
Un outil bien pratique pour tester les différentes vulnérabilités shellshock:
https://github.com/hannob/bashcheck
[^] # Re: Apparemment, tout ne serait pas terminé...
Posté par Aissen . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 4.
La source originale, avec plus de détails:
http://lcamtuf.blogspot.co.nz/2014/09/bash-bug-apply-unofficial-patch-now.html
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 2.
C’est justement le sujet du papier pointé par mon deuxième commentaire, qui montre comment implémenter ça de manière à résister à des analyses statistiques et de manière invisible sur les photos du die.
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 3.
Le papier en question "Stealthy Dopant-Level Hardware Trojans" :
https://web.archive.org/web/20140531085714/http://people.umass.edu/gbecker/BeckerChes13.pdf (il est sur ACM apparemment sinon)
La présentation de conférence: http://www.chesworkshop.org/ches2013/presentations/CHES2013_Session4_3.pdf
[^] # Re: un vrai générateur de nombres aléatoires
Posté par Aissen . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 2. Dernière modification le 06 août 2014 à 01:56.
À partir d’Ivy Bridge(Core 3ème génération), les processeurs Intel incluent l’instruction RDRAND. Elle est incroyablement performante (500Mo/s), dans la mesure où elle peut s’exécuter en assez peu de cycles. Elle est utilisable en userspace. Elle repose sur un transistor mit dans un état "metastable", qui dérive à chaque coup de clock aléatoirement vers un 1 ou un 0. Ça seed ensuite un PRNG basé sur un hash/CBC. Je te laisse lire les différents papiers (d’Intel et d’universitaires) et brevets sur le sujet:
https://sites.google.com/site/intelrdrand/references
Si tu lis le lien wikipedia plus haut, tu verras aussi qu’il est possible que le générateur d’Intel soit backdooré par la NSA (ou pas), mais c’est impossible à prouver. Des scientifiques on même prouvé qu’on pouvait truquer un générateur aléatoire hardware "propre" de manière à résister à une analyse de die, mais j’ai plus la référence.
[^] # Re: jeuxlinux
Posté par Aissen . En réponse au journal Nuclear Throne. Évalué à 3.
Ben avec tous les jeux linux qui sortent chaque semaine sur Steam et le Humble Store, ils doivent avoir un sacré backlog à rattraper. Faut les comprendre !
[^] # Re: Corrigé
Posté par Aissen . En réponse à l’entrée du suivi Autoriser l’inclusion du site dans une iframe - 2ème partie. Évalué à 3 (+0/-0).
Merci pour cette incroyable réactivité !
# Régression ?
Posté par Aissen . En réponse à l’entrée du suivi Autoriser l’inclusion du site dans une iframe. Évalué à 2 (+0/-0).
Le header aurait été remit aujourd’hui ? Il y a une raison derrière ça ?
[^] # Re: Louis Pouzin
Posté par Aissen . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 5.
Il est dans le document, page 207. La dépêche ne cite qu’un extrait de ceux qui ont contribué au libre. Je viens d’ailleurs de voir qu’un fondateur de Talend, Cédric Carbone, un ETL Open Source, présent dans le document de Krim, a été oublié dans la dépêche.
# Sur le fond du rapport
Posté par Aissen . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 10.
La liste est sympa, mais ce qui est intéressant aussi, c’est le fond du rapport. Daniel Glazman en parle d’ailleurs sur son blog.
Morceaux choisis:
…
…
Après le sujet est assez vaste, et on peut regretter que ce rapport soit assez léger sur certains points (et à côté de la plaque sur d’autres, comme le « Github français »). Néanmoins, il a le mérite de lancer le débat. D’ailleurs Daniel Glazman pourrait écrire un second rapport, avec plus de propositions pour faire bouger les choses.
[^] # Re: Je n'avais rien à dire
Posté par Aissen . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 7.
Tant qu’on y est, Jayce, l’auteur de MultiDeskOS a aussi été oublié. Ainsi que Marc-Eric Gervais, le créateur d’I2BP!
[^] # Re: Pareil chez NVIDIA Tegra
Posté par Aissen . En réponse au journal AMD et plus d'open source. Évalué à 8.
Opensource, mais la situation n’est pas vraiment comparable:
- il n’est pas upstream
- ça n’utilise pas les infrastructures du kernel (ttm/gem, dma-buf, drm core, etc.)
- c’est juste la partie gpu donc pas de display, modesetting in-kernel, etc.
- il n’y a(vait) pas d’implémentation libre de la partie userspace. Lima n’est pas encore prêt ou intégré aux distributions (ni même à mesa, mais pour d’autres raisons).
C’est pour ça que je n’en ai pas parlé. D’autres drivers ARM sont dans la même situation, mais on ne peut pas comparer avec NVIDIA qui pourrait venir à utiliser nouveau pour le Tegra ou AMD qui pourrait utiliser radeon pour catalyst.