karteum59 a écrit 885 commentaires

OK, donc si je résume

• Un problème de communication

OK ça je peux le comprendre…

• Faire chier les demandeurs avec l'équivalent (voir pire car pas toujours du monde près de chez toi alors que les autres CA font à distance) de ce qu'il faut d'un certificat EV (validation étendue) pour ensuite te filer un certificat DV (de base), ça cloche quelque part

Bof, peut-être, mais ça n'explique pas en quoi CAcert est catastrophique ou en quoi "la porte est blindée et la fenêtre est ouverte" ni pourquoi ils se sont fait virer de Debian et n'ont pas réussi à se faire intégrer dans les CAs de Mozilla/Chromium/… Je jugerais au contraire plutôt ça positivement non ? (et qui peut le plus peut le moins…)

• Refuser un audit de sécurité par tes pairs, pour avoir autre chose que "promis on fait de la sécu, ayez confiance", ça ne donne pas confiance (ni aux utilisateurs ni aux navigateurs web)

Il y a vraiment eu refus, ou bien déficit de financement ?

• Avoir un certificat signée par une CA pas dans les principaux navigateurs revient à avoir un certificat auto-signé (d'une pourquoi alors se faire chier à faire signer le certificat, et de deux tu peux lire ce que les gens pensent de l'auto-signé dans les commentaires des journaux de l'auteur du journal)

Oui mais en même temps ma question de départ c'était : "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?" et non "en quoi cacert est-il moins bien que X pour l'utilisateur" ? tu le répètes à plein de reprises "personne dans les navigateur (ni Debian, tu parles d'une honte, être viré de Debian très au fait des libertés, faut le faire quand même dans le niveau de confiance bas…) n'a confiance en eux (…)" mais sans expliquer pourquoi, et encore plus loin à ma question "en quoi Let's Encrypt est-il mieux que cacert ?": tu réponds la même chose "c'est supporté par les navigateurs". OK mais pourquoi cette différence de traitement ? pourquoi est-ce que "personne n'a confiance en eux" ? (Let's Encrypt est supporté par la fondation Mozilla donc évidemment supporté par le navigateur eponyme, mais je ne vois pas ça comme un avantage technique mais comme une conséquence "politique" logique ! Du coup encore une fois ma question concerne plutôt : quels sont les détails techniques/de communication / politiques qui ont entrainé la marginalisation de cacert ?)

Jusque là je n'ai relevé que deux points factuels/techniques

• A ma connaissance ils sont super à la bourre techniquement (SHA-256, CT Certificate Transparency etc…)
• Refuser un audit de sécurité par tes pairs,(…)

=> est-ce que ça résume toute l'histoire ou est-ce que j'ai loupé des trucs ?

Puisqu'on parle de CA : désolé de relancer le débat avec une question de débutant alors que c'est peut-être évident pour plein de monde, mais quelqu'un peut-il réexpliquer ce qui cloche avec cacert et pourquoi ils n'arrivent pas à se faire accepter parmi les CA installées avec les navigateurs habituels ? En particulier, je lis des choses comme

Autorité de certification commerciale : il faut fournir quelque chose comme un de relevé de compte en banque (un truc que n'importe qui peut falsifier) et une adresse électronique et un numéro de téléphone où être rappelé. Aucun contact direct.
CAcert : il faut rencontrer en personne trois ou quatre accréditeurs CAcert qui vérifieront tes papiers d'identité et la correspondance de la photo avec ton visage.

Oui, alors la porte est blindé, mais la fenêtre est ouverte 1 mètre plus loin. C'est beau la sécurité!

=> Lapin compris en quoi "la fenêtre est ouverte 1 mètre plus loin"… (à mon niveau, ce que j'ai vu au FOSDEM c'est que effectivement ils vérifiaient sérieusement l'identité des gens).

Question subsidiaire: en quoi Let's Encrypt est-il mieux que cacert ?

de la bande des 700 mHz (Hertz c'est Hz le symbole :p )

Si tu es à cheval sur les unités, j'aurais plutôt écrit "MHz" (car "mHz", je l'interpréterais comme "millihertz" ;op)

il y a toujours des bonnes raisons pour faire de l'obsolescence programmée ! :-)

Hélas, la FAQ du CSA vers laquelle tu pointes dit effectivement explicitement…

Va-t-il falloir encore changer d’équipements de réception de la TNT dans les prochaines années ? (on parle de DVB-T2 ?)
La norme de diffusion DVB-T2 est appelée à terme à remplacer la norme DVB-T actuellement utilisée en TNT, et la norme de codage HEVC doit succéder à la norme MPEG-4. Leur mise en œuvre permettrait de diffuser de manière plus efficace les programmes, et donc d’augmenter la qualité des services, par exemple en proposant une offre en ultra haute définition à destination des écrans dits 4K… Pour recevoir des programmes utilisant ces normes, il sera nécessaire de disposer d’équipements de réception compatibles, (téléviseur ou adaptateur TNT, récepteur satellite).

Bon, pour faire plus simple : il y a toujours une part d'irréversibilité et de pertes dans tout processus industriel (que ce soit dans la conversion des types d'énergie, dans le changement de compositions chimiques, etc.). Pour cette raison, il est impossible de "revenir en arrière" (lorsqu'un objet est usagé, on peut par exemple éventuellement récupérer ou recycler quelques éléments qui le constituent, mais généralement de manière d'autant plus limitée que l'objet est complexe. Et l'énergie dépensée pour sa fabrication ou son utilisation est également elle aussi perdue - au sens de non récupérable, diffuse). Bref, oublie le mot "entropie" si ça rend les choses confuses pour toi, mais garde juste à l'esprit que nous évoluons dans un monde fini ("l'économie circulaire" restera à mon sens une lubie), donc n'importe quoi que nous fabriquons/consommons de manière superflue aujourd'hui se fait nécessairement au détriment de quelque chose d'autre (potentiellement plus utile/important) dans le futur.

Il y a des bonnes raisons toute de même. La bande des 700 mhz est plus utile pour internet que pour la télé !

Je suis d'accord que le 700 MHz est plus utile aux télécoms. En fait quitte à tout chambouler à nouveau on aurait carrément pu allouer la totalité des bandes TV VHF/UHF aux télécoms (le service de radiodiffusion marche très bien avec juste du satellite, car contrairement aux télécoms il n'y a pas d'uplink et pas de problématique de capacité…). De mémoire c'était d'ailleurs la position d'un certain nombre de pays dans les discussions sur les plans de fréquences. Las, l'audiovisuel a toujours un poids politique non négligeable…

Et puis désolé mais, en high tech, un changement tous les dix ans, c'est pas non plus insurmontable.

Sauf que ça ne va pas durer… Je n'ai rien contre un peu de "progrès", tant qu'on ne jette pas ce qui fonctionne encore ! On ferait bien d'économiser un peu nos ressources pour des choses plus importantes. J'aime bien rappeler cette citation de Nicholas Georgescu-Roegen, qui s'applique évidemment à tout objet et pas seulement aux voitures !

« Chaque fois que nous produisons une voiture, nous détruisons irrévocablement une quantité de basse entropie qui, autrement pourrait être utilisée pour fabriquer une charrue ou une bêche. Autrement dit, chaque fois que nous produisons une voiture, nous le faisons au prix d'une baisse du nombre de vies humaines à venir. Il se peut que le développement économique fondé sur l'abondance industrielle soit un bienfait pour nous et pour ceux qui pourront en bénéficier dans un proche avenir : il n'en est pas moins opposé à l'intérêt de l'espèce humaine dans son ensemble, si du moins son intérêt est de durer autant que le permet sa dot de basse entropie. »

Toutes ces boards sont intéressantes du moment qu'on n’utilise pas une interface graphique

…et tant qu'on se satisfait du "jetable". Bien peu de fabricants de tablettes/dongles basés sur Allwinner (et Rockchip/AmLogic/ActionSemi/…) livrent les sources du kernel/bootloader. Et même dans les rares cas où ils le font, la taille de la communauté n'est généralement pas capable d'assurer le suivi. Le gros point fort du RPi n'est pas son rapport puissance/prix, mais sont rapport caractéristiques/prix (et dans "caractéristiques", j'inclus la taille de la communauté, et le support à long terme !)

des fichiers nommes dwtdct.cpp, ca aide pas.

ça aurait pu avoir du sens si c'était du code implémentant la DCT et la DWT, mais j'ai pas trop l'impression que ce soit le cas… :)

Mais au moins les "gros" fabricants respectent la GPL, donc il est généralement possible de remplacer l'OS par Cyanogenmod.

15€ pour un téléphone android ? C'est chaud… (30€ j'ai déjà vu en revanche). Par contre, ce genre de "smartphone" de merde ne sont évidemment jamais mis à jour par leurs fabricant (qui préfèrent vendre des nouveaux téléphones, et tant pis pour les failles du type stagefright…), et tu peux oublier cyanogenmod vu l'attitude de Mediatek envers la GPL. Personnellement j'ai opté pour un Nexus 5 d'occasion (trouvé à 100€ - caméra frontale HS mais je m'en fiche car je ne prends pas de selfie, et je peux toujours installer cyanogenmod/omnirom, et ce smartphone est suffisamment répandu pour espérer avoir un peu de support à long terme par la communauté).

Plus généralement, c'est peut-être triste à dire, mais j'évite désormais les "petits" fabricants / téléphones vendus à faible volume, pas parce qu'ils font forcément des "mauvais" produits en soi (certains smartphones à base de MTK sont même très attrayants), mais parce que le fait qu'un téléphone soit répandu signifie une plus grande communauté (donc un meilleur support à long terme) et une plus grande facilité à trouver des pièces détachées pour réparer le produit.

Nan mais attend, en plus Notepad++ c'est écrit en C++ non ?
Franchement, faudrait fusiller tous les extrémistes !

--> []

Aux dernières nouvelles, il me semble que Seamonkey est toujours un projet Mozilla, et est toujours maintenu. Pourtant je pense qu'il est bien moins connu et utilisé que Thunderbird, donc je ne saisis pas trop la logique consistant à se débarrasser de Thunderbird "parce que c'est dépassé / ce n'est plus la priorité de la Fondation" tout en gardant Seamonkey (qui intègre un client mail similaire à Thunderbird)… L'avenir de Seamonkey est-il lui aussi menacé ?

Le client dit 'lourd', c'est celui qui met des heures à se synchroniser à la première utilisation

Avec un client "lourd", tu peux aussi choisir de l'IMAP normal plutôt que du "disconnected IMAP", donc ce n'est pas un inconvénient, c'est une fonctionnalité (évidemment absente des webmails) qui a ses avantages et ses inconvénients (tels que le temps de synchro initiale), mais qui est souvent le mode par défaut des clients "lourds" car il est tellement pratique (te permet de voir tes mails instantanément et lorsque tu es offline).

N.B. si ton client mail se traine, tu peux aussi utiliser un outil plus performant.

Quel mini-jack ? (le RPi Zero n'en a pas, justement…)

OK pour la vidéo, mais j'ai pas saisi comment ils faisaient pour récupérer l'audio vu qu'elle n'est disponible que sur le mini-HDMI ? (en fait je ne vois pas trop l'intérêt d'avoir mis une broche pour le video composite, et aucune pour le son alors que généralement on veut les deux ou aucun…)

Avec du SATA et autour de 100€, il y a le E9 mini PC à base de i.mx6

Certains te diront qu'avec la prise USB tu peux mettre ce que tu veux, mais du coup un RPI2 est tout aussi intéressante pour un prix équivalent.

Bof, ça ne coûte plus si cher que ça…

Sur d'autres cartes, le support de l'acceleration hardware NAT/QoS/routage n'est pas implementé (et peu susceptible de l'être) dans OpenWRT, bien que le hardware le supporte (avec le SDK/BSP du fabricant de chipset). Or cette fonction est nécessaire si on souhaite vraiment atteindre les débits du type gigabit/s. Qu'en est-il pour ce routeur ?

c'est à musl-libc qu'il faut envoyer ces patches évidemment

1°/ Musl-libc n'a pas vocation à reproduire tout le bloat et extensions "propriétaires" de la glibc.
2°/ Ton approche signifie que musl doit reproduire 100% des extensions propriétaires de la glibc, alors que peut-être 20% sont utilisées (et nécessiteraient d'être backportées) dans systemd
3°/ Personne ne demande à Lennard de coder lui-même lesdites fonctionnalités, juste de ne pas bloquer les contributions de ceux qui souhaitent que ça marche ailleurs que sur Linux/Redhat/glibc/sa_machine. Si Linus avait eu le même comportement, je ne suis pas sûr que Linux marcherait sur ARM/MIPS/Alpha/…/Amiga/… (et pourtant, le support de ARM était un joyeux bazar avant l'avènement du DT)

Rappelons, comme je le disais ici, que

Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…).

(N.B. quand je dis "refuser de résoudre le problème", je ne blame pas le fait qu'il ne s'investisse pas personnellement dans un problème qui ne le concerne/motive pas, mais surtout qu'il refuse les patchs qui sont destinés à résoudre le problème). Pour du Linux embarqué e.g. OpenWRT (mais pas seulement, cf. Alpine), uclibc et musl sont particulièrement appropriées, et Busybox fonctionne essentiellement dans ce type d'environnement donc cette décision ne me semble pas surprenante.

Oui je connais bien tout ça, mais ça n'empêche pas.
(…)
Pour lancer Linux on n'a pas besoin de modifier son BIOS, sur un téléphone c'est pareil.

Donc non, manifestement tu ne connais pas très bien tout ça et tu n'as pas non plus lu mon post plus haut. Donc je répète : « contrairement au monde du PC, dans le monde ARM/MIPS il n'existe pas "one kernel to rule them all". La faute à l'absence de mécanisme d'introspection/abstraction (jouée par le BIOS/ACPI/UEFI dans le monde PC) qui fait que chaque SoC et chaque carte-mère est une machine à part nécessitant un kernel dédié. La situation évolue doucement avec le device-tree (qu'il est parfois possible d'extraire du firmware du fabricant), mais ça reste pas évident de recompiler son kernel avec les bons patches, et de l'installer (avec le DT, etc.). Bref, il n'existe aucun moyen de booter un linux ARM "générique" sur un device ARM/MIPS ».

(pour peu qu'il y ait un bootloader sympa qui accepte de booter une image non signée évidemment)

J'ai un vieux téléphone à base de chipset Mediatek d'un ODM taiwanais. Je n'ai pas les sources pour le kernel, et la description de la machine ne se basait certainement pas sur un device-tree mais sur des fichiers mach-*.c (dont je n'ai pas les sources). Je n'ai pas non plus de moyen d'extraire les drivers pour les différentes parties du SoC (pas seulement GPU, mais tout ce qui touche aux différentes clocks, à la gestion de l'énergie, etc.). Donc je n'ai aucun moyen de recompiler et booter mon propre kernel. Pourtant j'ai un bootloader "sympa".

Les blobs binaires, les modules kernel particuliers, ça se récupère d'une image existante, c'est toujours possible

Les blobs binaires, peut-être (comme le DT par exemple. Les modules (*.ko) ne te seront pas d'une grande utilité vu que les API noyau sont non stables. Le reste (ce qui est compilé en dur dans le kernel, que ce soit les drivers ou la description de la machine lorsqu'elle est faite dans des fichiers mach-* au lieu du DT) me semble également irrécupérable…

Ce que je voulais dire c'est que si on fait le même effort que les premiers qui ont sué à faire tourner X11 sur leur Matrox sous Linux avec le son sur une SoundBlaster en prime, tout cela sans l'aide d'aucun constructeur, on fera aussi tourner une Debian en natif sur un téléphone.

Si tu espères faire du reverse-engineering à l'aveugle, je pense que tu n'as pas idée du niveau de complexité à l'intérieur d'un SoC moderne !

c'est pas parce que c'est un smartphone qu'il est impossible d'y faire tourner une Debian

Si, déjà répondu plus haut
(J'aurais d'ailleurs pu ajouter à mon précédent post : absence de drivers Xorg/opengl/… pour les GPU mobiles. La Shield tablet sous Tegra K1 étant (étrangement ?) une exception)

Evidemment, tu peux faire tourner Debian dans un chroot+VNC (en supposant que ton kernel Android soit compilé avec les options qui te conviennent), mais de là à en faire ton système natif avec une gestion de l'énergie et du GPU convenable…

Je sais qu'on peut installer assez facilement Debian dans un chroot sur un smartphone. Par contre jusque là je n'ai pas trouvé de truc à ma portée pour remplacer le système

Plusieurs raisons à cela:

• contrairement au monde du PC, dans le monde ARM/MIPS il n'existe pas "one kernel to rule them all". La faute à l'absence de mécanisme d'introspection/abstraction (jouée par le BIOS/ACPI/UEFI dans le monde PC) qui fait que chaque SoC et chaque carte-mère est une machine à part nécessitant un kernel dédié. La situation évolue doucement avec le device-tree qu'il est parfois possible d'extraire du firmware du fabricant, mais ça reste pas évident de recompiler son kernel avec les bons patches, et de l'installer (avec le DT, etc.). Bref, il n'existe aucun moyen de booter un linux ARM "générique" sur un device ARM/MIPS.
• un certain nombre de fabricants de SoC sont non-coopératifs et ne livrent pas les sources du kernel, ce qui est illégal (et totalement bloquant compte tenu de l'idéologie que les API stables sont inutiles, manque total de pragmatisme vis à vis des pratiques des ODMs dans des pays qui ne sont pas tout à fait des états de droits et se contrefichent de la GPL…). On se souvient tous du petit coup de gueule de Linus envers NViDIA (qui a néanmoins significativement amélioré les choses depuis. Ma shield tablet à base de K1 est parfaitement supportée sous Ubuntu 14.10, avec l'accélération opengl 4.4 et opencl !). Le coup de gueule aurait à mon sens été encore plus fort en désignant d'autres fabricants de puces ou de terminaux (qui ne sont - je le crains - pas près de changer leur comportement)

Pourquoi financer un constructeur peu pro-linux ?

et aussi peu soucieux de l'environnement (réparabilité notée 1/10 - la pire note - sur ifixit, et ce quel que soit le modèle)

Intéressant, mais très centré sur du ARM. Or qui dit ARM dit qu'on ne peut pas avoir "one kernel to rule them all". C'est malheureux d'autant que certaines puces ARM commencent à devenir vraiment sympathiques (j'ai sous la main une nvidia shield tablet / tegra K1 que j'ai basculé sous Ubuntu, et ça marche franchement pas mal pour une petite machine payée 200€ d'occasion à l'époque, et qui tient >10h sur batterie avec un support OpenGL4/Cuda/OpenCL qui tient la route) mais c'est un vrai souci sur le support à long terme pour ceux qui (comme moi) ne veulent pas jeter leur machine au bout de 3 ans.
(d'un autre côté je n'ai pas de machine x86 récentes type BayTrail mais j'ai cru comprendre que le support de Linux était assez aléatoire et son installation sur un EFI 32 bits pas super simple non plus, donc s'il faut bidouiller autant que sur ARM et que la pérennité n'est pas garantie, l'avantage du x86 n'est plus aussi évident…)