Au début moi aussi j'étais un peu réservé, puis je suis allé lire la proposition de norme et j'ai simulé la frappe de quelques trucs sur mon clavier, et honnêtement au final je la trouve vraiment bien.
Déjà je suis pas sûr mais je pense qu'elle adresse plus de symboles que fr-oss. Ensuite le choix de la disposition pour l'azerty semble en effet présenter de nombreux changements dont on pourrait se passer au niveau du layout basique (surtout que le clavier .fr mac et PC ne sont pas si différents que ça, et en tous cas moins qu'avec ce nouveau layout—de plus il faudra voire si Apple cède à la norme, c'est bien le genre de boite à dire "nan on continue avec notre merde on est trop hype pour utiliser une norme, fût-elle meilleure") mais en fait la logique utilisée pour le placement est stylée, et à s'imaginer utiliser ce layout je pense que ça sera potentiellement mieux qu'avant—même si j'ai quelques réserves sur certaines touches pour coder, mais comme ils expliquent ça peut pas être opti pour tout le monde.
Bref si on veut profiter d'améliorations, il va falloir logiquement rompre avec (quelques) habitudes !
La démarche utilisée est sérieuse en tous cas :
La conception de la nouvelle disposition AZERTY s’est appuyée sur une méthode d’optimisation combinatoire permettant d'explorer de manière systématique toutes les configurations possibles des caractères sur le clavier, tout en considérant simultanément quatre objectifs de conception : vitesse de saisie, similarité avec la disposition précédente (à laquelle les utilisateurs sont habitués), groupement de caractères similaires (p. ex. '[' et ']'), et ergonomie. […]
L’approche choisie s’appuie sur les dernières avancées de la recherche en optimisation combinatoire – et plus précisément la programmation linéaire en nombre entiers – et en conception de claviers. Trois problèmes ont été résolus : 1) la définition du problème d’affectation d’un caractère à un emplacement, 2) la collection de données représentatives et le développement d modèles pour les quatre objectifs de conception, et 3) la conception d'un solveur efficace pour le problème adressé.
Ouai mais attention à la terminologie. Le "cache" c'est juste une copie des blocs du disque en RAM, mais il ne va pas servir directement pour constituer les objets du noyau décrivant les partitions—ce dont je parle justement; il y a un petit parseur de la table de partition (en vrai un parseur par format de table, principalement MS-DOS et GPT sur PC, mais il existe des tas de format de table de partition), et ce que je dis c'est qu'il faut que ce parseur soit redéclenché après modif de la table sur le disque (et j'aurais du mal à croire en outre que ce parseur bypass le cache, donc on s'en bas probablement complètement les couilles que le cache disque soit flushé ou pas à ce moment).
Bref l'invalidation nécessaire n'a en soit pas un rapport extrême avec le cache disque, je crois. C'est ptet ça qui a induit les moinsseurs en erreur.
En outre je raconte toussa de mémoire car j'ai dans une vie antérieure contribué à GNU Parted. Mais c'était il y a > 10 ans, et je peux avoir une mauvaise mémoire à ce sujet et/ou le comportement a pu changer entre temps.
je fait un dd if=/dev/zero of=/dev/sda tout va bien, sauf …. les partitions sont toujours présente. si j'utilise fdisk, je fait ce que je veux, je sauvegarde, j'ai bien l'information qu'il a ecris sur le ssd et …. rien, pas de nouvelle partition, toujours les anciennes qui résiste a un dd, mkfs fonctionne mais 'dans le vide'. même le id de la partition est comme gravé sur le ssd
hm, si mes souvenirs sont bons les partitions sont dans un coin de la RAM du noyal suite au parsing initial, qui peut probablement être redéclenché par des ioctl. Ptet que dans les noyaux modernes il invalide et tente de reparser à la volé automatiquement en cas de modif des tables physiques, mais franchement je pense pas (quasiment aucun intérêt à faire ça, et plus complexe à réaliser). Bref le fait que le comportement parte en couille quand tu fais ça ne m'étonne à priori pas—à confirmer bien sûr, mais c'est facile à vérifier…
Les 12 highs ne sont pas des RCE, mais effectivement c'est un peu arbitraire de 1/ compter des CVE 2/ uniquement les RCE.
D'un autre côté même si les autres risques peuvent être important, surtout dans un browser, le risque en cas de RCE est assez extrême - et entre 72 et 2 il y a de la marge.
Si on veut compter autre chose que les RCE (toujours en précisant que c'est pas totalement significatif pour évaluer la sécu, ça donne juste une idée dans un domaine), on peut par exemple trouver :
MS fait un travail intéressant et livre des contres-mesures innovantes, mais Edge a par exemple 74 CVE RCE publiées en 2016, contre 2 pour Chrome (et même si c'était un point bas, ça fait depuis 2013 qu'ils sont en dessous de 10)
Pour compléter la vision, malheureusement Firefox a des chiffres élevés, et Pwn2Own ne l'a même pas aligné en 2016, car trop facile à attaquer selon eux…
le design de l'UEFI n'est pas de la responsabilité de Microsoft
Formellement partiellement vrai selon le sens qu'on veut donner à cette phrase (MS n'étant qu'un des membres promoteur du Forum UEFI), mais dans tous les cas techniquement l'UEFI sent le MS à plein nez: FAT32, PE, UUIDs de partout pour aucune raison (faire râler les gens qui font du reverse pcq c'est pas pratique, ptet?), etc. Le tout résultant dans des binaires ultimement bloatés. Ça me trouerait le cul que y a pas un mec de MS qui a joué un rôle prépondérant dans le design, et au pire MS a énormément influencé le design ne serait-ce qu'indirectement (mais je dis ça par pure précaution pcq j'ai la flemme de ressortir ma copie de la spec pour vérifier, je crois bien que c'était en fait très directement).
(À la réflexion, le coup des UUIDs de partout c'est ptet pcq c'est trop horrible de tenter de linker dynamiquement des bibliothèques de classes dans un système basé sur de PE, du coup ils font un espèce de workaround horrible et résultat les gens sensés vomissent de partout)
Si Avencall ferme les dépôts communautaires, je comprends très bien la nécessité d'un fork "hostile". En passant, j'ai pas cherché longtemps mais j'ai pas trouvé les sources sur www.xivo.solutions, alors qu'ils proposent une iso (une 2016.03, j'imagine que c'est une vielle) - on pourrait s'amuser à leur demander les sources des logiciels tiers sous Copyleft d'ailleurs.
Bref, c'est juste une impression mais Avencall semble vouloir basculer (voire avoir déjà basculé) vers un modèle de logiciel développé derrière des portes closes - ou au pire de logiciel propriétaire. (Ceci étant dit à ses tous débuts XiVO n'était libre, si mes souvenirs sont bons.)
Pour finir, j'aimerais noter qu'Avencall s'est montré très hostile par le passé à la potentielle continuation d'un projet libre démarré chez eux, après son annulation. J'espère qu'ils embêteront moins Wazo…
Techniquement, on pourrait arguer qu'énoncer un fait que le cannabis est moins dangereux que l'alcool (si c'est bien vrai) ne constituerait pas en soit une présentation sous un jour favorable, surtout vu que l'alcool est ultra dangereux, c'est pas très dur de faire moins, ça n'équivaut pas à prétendre que c'est bénéfique…
D'ailleurs le modèle fork/exec pour spawner des nouveaux process est "moisi" entre autre à cause de ça. Enfin bon c'est moins grave maintenant que la RAM est assimilable à +oo même sur des ordis pas trop cher, et que l'overcommit de Linux a un comportement décent.
Comment tu peux consommer trop d'espace pour un malloc avec des mapping de gros fichiers? Je veux dire, techniquement c'est possible très indirectement (par des ressources RAM consommées indirectement pour la gestion des dits mapping), et en combinant avec pleins d'autres allocations sur le système. Mais invoquer des mapping de fichier en soit et comme unique cause, c'est très curieux…
EDIT: à la réflexion tu parles surement de consommer tout l'espace virtuel en 32 bits? le 32 bits c'est tellement satan que j'y pense plus du tout apparemment :p
Les contrats n'impliquent pas intrinsèquement un comportement non-défini (au sens du C avec apparition de démons naseaux) lorsqu'ils sont violés.
Si l'on prend le cas d'une fonction mathématique (cad "pure" en info) on pourrait dire que le contrat est que les paramètres sont dans le domaine de définition. Ça n'implique pas en soit l'apparition de démons naseaux si l'appelant est en dehors, et il est tout à fait convenable (et même préférable) de réagir par exemple en levant une exception dans une implémentation.
Bah indique moi où sont les bonnes parties alors, pcq perso c'était insufisant pour > 50% des fonctions Win32 que j'appelais. Après il y a probablement certains dev qui ne se rendent meme pas compte qu'une spec est incomplete, et sont satisfaits au premier test qui fonctionne par hasard. C'est pas ma conception de l'informatique, et pour être tout à franc je considère que ca devrait être la conception de personne.
Je crois que PAE reste activé en 32 bits, et a un interet pour d'autres features associée au changement de format de la page table, comme le bit NX. Ceci étant dit MS bride les Windows 32 bits clients à 4 GB de ram max, PAE ou pas PAE (et en pratique il se peut que moins de 4 GB soit exploitable)
D'un autre côté la NSA est vaguement moins censée défoncer les infrastructures sur son sol (en théorie) alors qu'elle n'a aucune limite en terre étrangère. Bref, dans tous les cas on est dans la merde.
[^] # Re: cohérence de la démarche
Posté par Guillaume Knispel . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 3.
Y a des propositions de cartes alternatives quelque part ?
[^] # Re: fr-oss
Posté par Guillaume Knispel . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 5.
Au début moi aussi j'étais un peu réservé, puis je suis allé lire la proposition de norme et j'ai simulé la frappe de quelques trucs sur mon clavier, et honnêtement au final je la trouve vraiment bien.
Déjà je suis pas sûr mais je pense qu'elle adresse plus de symboles que fr-oss. Ensuite le choix de la disposition pour l'azerty semble en effet présenter de nombreux changements dont on pourrait se passer au niveau du layout basique (surtout que le clavier .fr mac et PC ne sont pas si différents que ça, et en tous cas moins qu'avec ce nouveau layout—de plus il faudra voire si Apple cède à la norme, c'est bien le genre de boite à dire "nan on continue avec notre merde on est trop hype pour utiliser une norme, fût-elle meilleure") mais en fait la logique utilisée pour le placement est stylée, et à s'imaginer utiliser ce layout je pense que ça sera potentiellement mieux qu'avant—même si j'ai quelques réserves sur certaines touches pour coder, mais comme ils expliquent ça peut pas être opti pour tout le monde.
Bref si on veut profiter d'améliorations, il va falloir logiquement rompre avec (quelques) habitudes !
La démarche utilisée est sérieuse en tous cas :
[^] # Re: une expérience
Posté par Guillaume Knispel . En réponse au journal Endurance des SSD. Évalué à 4.
Ouai mais attention à la terminologie. Le "cache" c'est juste une copie des blocs du disque en RAM, mais il ne va pas servir directement pour constituer les objets du noyau décrivant les partitions—ce dont je parle justement; il y a un petit parseur de la table de partition (en vrai un parseur par format de table, principalement MS-DOS et GPT sur PC, mais il existe des tas de format de table de partition), et ce que je dis c'est qu'il faut que ce parseur soit redéclenché après modif de la table sur le disque (et j'aurais du mal à croire en outre que ce parseur bypass le cache, donc on s'en bas probablement complètement les couilles que le cache disque soit flushé ou pas à ce moment).
Bref l'invalidation nécessaire n'a en soit pas un rapport extrême avec le cache disque, je crois. C'est ptet ça qui a induit les moinsseurs en erreur.
En outre je raconte toussa de mémoire car j'ai dans une vie antérieure contribué à GNU Parted. Mais c'était il y a > 10 ans, et je peux avoir une mauvaise mémoire à ce sujet et/ou le comportement a pu changer entre temps.
[^] # Re: Ah Linux et la sécurité...
Posté par Guillaume Knispel . En réponse au journal grsecurity abandonne le gratuit. Évalué à 2.
J'avais simplement regardé https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 si mes souvenirs sont bons, mais ptet que ce site est pas 100% fiable.
De plus faut noter que même dans ce tableau 2016 était un point bas, et qu'il y a de la variance.
[^] # Re: une expérience
Posté par Guillaume Knispel . En réponse au journal Endurance des SSD. Évalué à 4.
hm, si mes souvenirs sont bons les partitions sont dans un coin de la RAM du noyal suite au parsing initial, qui peut probablement être redéclenché par des ioctl. Ptet que dans les noyaux modernes il invalide et tente de reparser à la volé automatiquement en cas de modif des tables physiques, mais franchement je pense pas (quasiment aucun intérêt à faire ça, et plus complexe à réaliser). Bref le fait que le comportement parte en couille quand tu fais ça ne m'étonne à priori pas—à confirmer bien sûr, mais c'est facile à vérifier…
[^] # Re: Ah Linux et la sécurité...
Posté par Guillaume Knispel . En réponse au journal grsecurity abandonne le gratuit. Évalué à 3.
Les 12 highs ne sont pas des RCE, mais effectivement c'est un peu arbitraire de 1/ compter des CVE 2/ uniquement les RCE.
D'un autre côté même si les autres risques peuvent être important, surtout dans un browser, le risque en cas de RCE est assez extrême - et entre 72 et 2 il y a de la marge.
Si on veut compter autre chose que les RCE (toujours en précisant que c'est pas totalement significatif pour évaluer la sécu, ça donne juste une idée dans un domaine), on peut par exemple trouver :
Edge 95 high+ en 2016 https://www.cvedetails.com/vulnerability-list.php?vendor_id=26&product_id=32367&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=0&year=2016&month=0&cweid=0&order=1&trc=135&sha=e68935cd110d35fb4002780d5d498d128d115899
vs Chrome 33 high+ en 2016 https://www.cvedetails.com/vulnerability-list.php?vendor_id=1224&product_id=15031&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=0&year=2016&month=0&cweid=0&order=1&trc=172&sha=448a464ff2459f363534f95111ef4340dfe64ae0
[^] # Re: La sécurité
Posté par Guillaume Knispel . En réponse au journal grsecurity abandonne le gratuit. Évalué à 2.
Dans une certaine vision du concept de la sécurité, peut-être, disons qu'ils sont pas nombreux sur ce créneaux…
[^] # Re: Ah Linux et la sécurité...
Posté par Guillaume Knispel . En réponse au journal grsecurity abandonne le gratuit. Évalué à 3.
MS fait un travail intéressant et livre des contres-mesures innovantes, mais Edge a par exemple 74 CVE RCE publiées en 2016, contre 2 pour Chrome (et même si c'était un point bas, ça fait depuis 2013 qu'ils sont en dessous de 10)
Pour compléter la vision, malheureusement Firefox a des chiffres élevés, et Pwn2Own ne l'a même pas aligné en 2016, car trop facile à attaquer selon eux…
[^] # Re: Libre, pas libre, c'est douteux
Posté par Guillaume Knispel . En réponse au journal grsecurity abandonne le gratuit. Évalué à 2.
RedHat est du genre à faire exactement ce genre de chose. Ça serait hypocrite qu'ils les attaquent en justice…
[^] # Re: La valeur de Linux est de 0 (pour toi).
Posté par Guillaume Knispel . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 6.
Histoire de pinailler sur un point:
Formellement partiellement vrai selon le sens qu'on veut donner à cette phrase (MS n'étant qu'un des membres promoteur du Forum UEFI), mais dans tous les cas techniquement l'UEFI sent le MS à plein nez: FAT32, PE, UUIDs de partout pour aucune raison (faire râler les gens qui font du reverse pcq c'est pas pratique, ptet?), etc. Le tout résultant dans des binaires ultimement bloatés. Ça me trouerait le cul que y a pas un mec de MS qui a joué un rôle prépondérant dans le design, et au pire MS a énormément influencé le design ne serait-ce qu'indirectement (mais je dis ça par pure précaution pcq j'ai la flemme de ressortir ma copie de la spec pour vérifier, je crois bien que c'était en fait très directement).
(À la réflexion, le coup des UUIDs de partout c'est ptet pcq c'est trop horrible de tenter de linker dynamiquement des bibliothèques de classes dans un système basé sur de PE, du coup ils font un espèce de workaround horrible et résultat les gens sensés vomissent de partout)
[^] # Re: XiVO pas de changement ! mais un renforcement de son positionnement d'éditeur
Posté par Guillaume Knispel . En réponse à la dépêche Wazo, le fork de XiVO, prend son envol. Évalué à 5.
Ouai c'est sympa comme expression pour jouer au business loto, mais ca veut dire quoi concrètement ? Que vous vous êtes faché avec Sylvain ? :p
[^] # Re: Pourquoi un fork hostile ?
Posté par Guillaume Knispel . En réponse à la dépêche Wazo, le fork de XiVO, prend son envol. Évalué à 4.
update: apparemment les sources de XiVO sont toujours dispos, du moins en tant que paquet Debian source: http://mirror.xivo.solutions/debian/pool/main/
[^] # Re: Pourquoi un fork hostile ?
Posté par Guillaume Knispel . En réponse à la dépêche Wazo, le fork de XiVO, prend son envol. Évalué à 4.
Si Avencall ferme les dépôts communautaires, je comprends très bien la nécessité d'un fork "hostile". En passant, j'ai pas cherché longtemps mais j'ai pas trouvé les sources sur www.xivo.solutions, alors qu'ils proposent une iso (une 2016.03, j'imagine que c'est une vielle) - on pourrait s'amuser à leur demander les sources des logiciels tiers sous Copyleft d'ailleurs.
Bref, c'est juste une impression mais Avencall semble vouloir basculer (voire avoir déjà basculé) vers un modèle de logiciel développé derrière des portes closes - ou au pire de logiciel propriétaire. (Ceci étant dit à ses tous débuts XiVO n'était libre, si mes souvenirs sont bons.)
Pour finir, j'aimerais noter qu'Avencall s'est montré très hostile par le passé à la potentielle continuation d'un projet libre démarré chez eux, après son annulation. J'espère qu'ils embêteront moins Wazo…
[^] # Re: Merci la quadrature
Posté par Guillaume Knispel . En réponse au journal Désolé, la Quadrature, mais tu fais fausse route. Évalué à 5.
Techniquement, on pourrait arguer qu'énoncer un fait que le cannabis est moins dangereux que l'alcool (si c'est bien vrai) ne constituerait pas en soit une présentation sous un jour favorable, surtout vu que l'alcool est ultra dangereux, c'est pas très dur de faire moins, ça n'équivaut pas à prétendre que c'est bénéfique…
# Raspberry Pi libre???
Posté par Guillaume Knispel . En réponse au journal Liberasys : visualisation des consommations électriques pour Lorient. Évalué à 3.
hmrf ! Le layout est pas publié, critère indispensable pour considérer ça comme de l'openhardware / hardware "libre"…
[^] # Re: undefined behaviour
Posté par Guillaume Knispel . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
D'ailleurs le modèle fork/exec pour spawner des nouveaux process est "moisi" entre autre à cause de ça. Enfin bon c'est moins grave maintenant que la RAM est assimilable à +oo même sur des ordis pas trop cher, et que l'overcommit de Linux a un comportement décent.
[^] # Re: undefined behaviour
Posté par Guillaume Knispel . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 4.
Comment tu peux consommer trop d'espace pour un malloc avec des mapping de gros fichiers? Je veux dire, techniquement c'est possible très indirectement (par des ressources RAM consommées indirectement pour la gestion des dits mapping), et en combinant avec pleins d'autres allocations sur le système. Mais invoquer des mapping de fichier en soit et comme unique cause, c'est très curieux…
EDIT: à la réflexion tu parles surement de consommer tout l'espace virtuel en 32 bits? le 32 bits c'est tellement satan que j'y pense plus du tout apparemment :p
# t'as besoin d'un dico
Posté par Guillaume Knispel . En réponse au journal [Bookrmark] How to troll systemd in one blog post. Évalué à -4.
et confondre un argumentaire technique trivialement convainquant avec du trolling, ça relève de quoi exactement ? d'ineptie technique ?
# contrats
Posté par Guillaume Knispel . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 2.
Les contrats n'impliquent pas intrinsèquement un comportement non-défini (au sens du C avec apparition de démons naseaux) lorsqu'ils sont violés.
Si l'on prend le cas d'une fonction mathématique (cad "pure" en info) on pourrait dire que le contrat est que les paramètres sont dans le domaine de définition. Ça n'implique pas en soit l'apparition de démons naseaux si l'appelant est en dehors, et il est tout à fait convenable (et même préférable) de réagir par exemple en levant une exception dans une implémentation.
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . En réponse au journal x86 ou x86_64 ?. Évalué à 3.
Hm ? A priori cest justement ce que permet CONFIG_HIGHMEM, non ?
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Je sais plus si il a une distinction avec l'highmem ou pas mais si tu passes ton temps à mapper et unmapper c'est plus lent.
[^] # Re: Video only
Posté par Guillaume Knispel . En réponse au journal Microsoft Windows Subsystem For Linux. Évalué à 2.
Bah indique moi où sont les bonnes parties alors, pcq perso c'était insufisant pour > 50% des fonctions Win32 que j'appelais. Après il y a probablement certains dev qui ne se rendent meme pas compte qu'une spec est incomplete, et sont satisfaits au premier test qui fonctionne par hasard. C'est pas ma conception de l'informatique, et pour être tout à franc je considère que ca devrait être la conception de personne.
[^] # Re: Se tenir au courant ?
Posté par Guillaume Knispel . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Le noyeau doit pouvoir lire et écrire à des endroits arbitraires de l'espace d'adressage des processus userspace.
[^] # Re: Correction
Posté par Guillaume Knispel . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Je crois que PAE reste activé en 32 bits, et a un interet pour d'autres features associée au changement de format de la page table, comme le bit NX. Ceci étant dit MS bride les Windows 32 bits clients à 4 GB de ram max, PAE ou pas PAE (et en pratique il se peut que moins de 4 GB soit exploitable)
[^] # Re: Pendant ce temps la en Russie...
Posté par Guillaume Knispel . En réponse au journal Safe Harbor est mort, vive Safe Harbor !. Évalué à 4. Dernière modification le 12 juillet 2016 à 22:20.
D'un autre côté la NSA est vaguement moins censée défoncer les infrastructures sur son sol (en théorie) alors qu'elle n'a aucune limite en terre étrangère. Bref, dans tous les cas on est dans la merde.