karteum59 a écrit 868 commentaires

C'est pas normal qu'un langage doive s'appuyer sur un autre pour fonctionner

Il y a quelques années, j'aurais sûrement dit ça aussi. Aujourd'hui je ne serais plus aussi catégorique : d'une manière générale générer du code peut paraître "crade" mais c'est une manière pragmatique de s'appuyer sur des outils/compilateurs stables et qui font consensus et doivent continuer de faire fonctionner du code existant tout en exposant une syntaxe plus sympathique ou plus puissante ou pour faire de la metaprogrammation (e.g. les gars de Trolltech disaient depuis longtemps "code generators are good"). Après, je suis d'accord que le préprocesseur C est limité alors que d'autres solutions sont sûrement plus puissantes (e.g. Python/jinja pour de la metaprogrammation, voir aussi ici). Certains ont d'ailleurs fait ça avec d'autres langages récents qui ne requiert pas de préprocesseur., e.g. générer du Go

Oui, justement, c'est inutile de recoder la gestion du hardware pour ça, juste ajouter des api utilisateurs.

Ce que tu dis là est exactement ce que fait le projet Wine (qui à ma connaissance collabore pas mal avec ReactOS, il ne faut pas les voir comme concurrents mais complémentaires). En revanche, ReactOS pourra normalement utiliser les drivers (binaires) Windows, ce qui peut être bien pratique pour faire fonctionner du matériel qui n'est supporté que sous cet OS.

J'ignore dans quelle mesure il aurait été possible que ReactOS parte d'une base de code Linux et le modifie pour intégrer/supporter l'API noyau/driver de Windows (ce qui aurait peut-être accéléré le développement initial), mais cela dit 1°/ peut-être que ReactOS intègre déjà du code de Linux/BSD (e.g. pour le support de ext4 discuté ici), 2°/ peut-être que les développeurs souhaitent juste se faire plaisir sans avoir l'objectif de conquérir le monde… (un peu comme Linux au début, d'ailleurs :)

Après, en ce qui me concerne, quand je dois choisir un langage je me pose aussi (entre autres) les questions suivantes :

• le langage permet-il de compiler vers autre chose que du x86/glibc ? (au hasard, un routeur MIPS sous OpenWRT/musl un peu contraint en stockage et RAM. En l'occurence, gros point négatif sur Go concernant cet aspect ! Si Swift se base sur LLVM, peut-être que ce sera mieux ?)
• le langage a t-il un bibliothèque standard digne de ce nom, et des bindings satisfaisants pour les bibliothèques que j'utilise ? (notamment QT5)

Je n'ai pas l'impression que OCaml satisfasse ces deux critères (mais corrigez-moi au besoin).

Le fait qu'ils soit amené a devenir le langage de prédilection pour l'univers Apple va forcément créer un grand nombre de développeur qui seront à l'aise avec celui ci et qui voudront un jour ou l'autre surement faire des choses utilisable dans d'autre environnement que MacOS/iOS.

Bof, l'existence de Mono a t-elle entrainé l'usage massif de c# sous d'autres environnements que Microsoft ? (peut-être que la comparaison est foireuse, mais c'est la première réflexion que m'amène ta remarque)

(cela dit pas de méprise: je suis très content que Swift existe et soit désormais ouvert et fonctionne sous Linux ! :)

Pour un peu moins de doigt mouillé

Mouais, admettons…
Cela dit il y a un troisième critère qui n'est pas mesuré et qu'il faudrait mettre sur un 3ème axe : la courbe d'apprentissage du langage ! (par exemple, Haskell (que je ne connais pas) a l'air fabuleux sur le papier mais le peu que j'ai regardé m'a fait peur car je me demande combien de temps (ou quel bagage théorique) il faut passer dessus avant d'arriver à être un minimum productif). Je pense que Go est clairement le prochain sur ma to-do list (sauf si Swift arrive à me convaincre :)

La plupart (je devrais presque dire la totalité) des fabricants Chinois (chipsets et OEMs, bref tout ce que tu trouves sur Alibaba/Taobao) avec qui j'ai eu l'honneur de travailler s'assoient littéralement sur la GPL (et pourtant j'étais en position de client, commandant plusieurs milliers d'unités ! J'ai eu aussi des cas intermédiaires où on me demandait de signer un NDA pour avoir les sources "very confidential" de u-boot et du kernel… Le même constructeur m'a pourtant envoyé les schematics de sa carte sans NDA alors que je lui demandais juste les mappings des GPIOs, on n'est pas à une contradiction près :).

Il est vain d'essayer d'expliquer/convaincre (encore que la jeune génération d'ingénieurs chinois soit sensiblement plus ouverte que la précédente, donc peut-être que patience et longueur de temps feront plus que force ni que rage…), et il est aussi illusoire de gagner un procès en Chine sur ce sujet. Je peux me tromper mais je me dis qu'un moyen de (peut-être) faire pression serait de faire évoluer la législation relative à la certification CE (obligatoire pour l'import en zone euro, et pour laquelle ils doivent passer des tests, notamment CEM, et fournir des documents - y compris user-manual si je me souviens bien) afin qu'elle inclue l'obligation de prouver que le constructeur se conforme à la GPL et donc publie les sources nécessaires (en supposant bien sûr qu'il n'y ait pas de fraude avec "China Export", dissimulation des symboles GPL, etc.).

Pour cela… j'avoue ne pas trop savoir où commencer pour tenter de sensibiliser la commission au souci (qui au delà de la gène pour les libristes et de l'impact environnemental de produits "jetables", est aussi une distorsion de concurrence EU/Chine). J'en ai vaguement touché quelques mots récemment à des connaissances à l'ETSI (on verra ce qui en ressortira) mais je pense que c'est au niveau de la commission qu'il faudrait faire passer le message…

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

Refus. Ils ont commencé, Mozilla était semblait être ok pour faire gratos (et Debian l'avait gratos), et ils ont retiré la demande.

OK, mais ça semble étrange quand même… Il n'y avait vraiment aucune autre contrepartie demandée par Mozilla qui rendait le truc impossible ? On a des liens où ils expliquent le pourquoi de leur refus ?

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 plaisantes? Tu ne vois pas le lien entre les deux?

cacert est moins bien que les autres pour l'utilisateur précisément parce qu'ils ne sont pas inclus dans les navigateurs. On est bien d'accord et il n'y a pas débat là dessus. Mais ce n'était pas ma question.
Je le répète : ma question était "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?". J'ai compris qu'ils avaient refusé un audit. OK donc poursuivons : pourquoi ont-ils refusé un audit ? Est-ce que c'est uniquement parce que "ils sont à la bourre techniquement" ?

tu le répètes à plein de reprises (…) "n'a confiance en eux (…)" mais sans expliquer pourquoi,

ben si. J'ai pris le temps d'expliquer, mais la réponse semble ne pas te convenir.

Tu as expliqué qu'ils étaient à la bourre techniquement et avaient refusé un audit, et qu'ils communicaient mal. OK. ça n'explique pas pour autant pourquoi ils ont refusé un audit (c'est quoi les contreparties / leurs arguments pour justifier leur refus ?). La dette technique est-elle si large pour qu'ils refusent un audit ? est-ce ce point qui fait que "personne n'a confiance en eux" ? pourquoi d'après toi "ils refusent d'être dans les navigateurs" ?

OK mais pourquoi cette différence de traitement ?

Aucune différence de traitement.
(par exemple, si un CA n'éprouve pas le besoin d'être dans les navigateurs, c'est quand même gênant non? Est-ce la faute des navigateurs?)

Donc pour toi, l'équipe cacert "n'éprouve pas le besoin d'être dans les navigateurs" ? C'est vraiment une situation choisie par l'équipe cacert ? (oui j'avoue que j'ai du mal à croire ça, m'enfin…)

quels sont les détails techniques/de communication / politiques qui ont entrainé la marginalisation de cacert ?

La, il faut que tu lises toute la prose sur CACert, mais le résumé t'a été donné.

"toute la prose" == précisément, si tu as des liens…

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

Tu as loupé tout ce qui est écrit dans le commentaire auquel tu réponds, pour en extraire que 2 trucs dont 1 hyper mineur. Euh… Si tu ne veux pas l’analyser car ne répond pas comme tu voudrais entendre, ça ne changera pas les faits.

Eh non, si on enlève ce qui relève de ton avis, je n'ai rien trouvé d'autre qui explique pourquoi cacert refuse un audit / "ne souhaite pas" être inclus dans les navigateurs / "personne n'a confiance en eux". Donc ça se résume en 1°/ ils sont à la bourre techniquement, 2°/ ils refusent un audit, 3°/ ils communiquent mal. C'est peut-être suffisant pour ne pas avoir confiance en eux à ce stade, mais est-ce vraiment insoluble, pour peu qu'on prenne le temps de comprendre où ça coince ?

Bon, désolé, je croyais que la question était sérieuse, j'avais répondu sérieusement et me suis trompé de niveau de discussion et j'ai donc perdu mon temps à être sérieux, je repasse en mode rigolo (faut vraiment pas être sérieux ici, on te fait comprendre que ça sert à rien)

Eh bien si, la question était sérieuse. J'ai un compte cacert (créé au FOSDEM) que je n'ai à ce jour jamais utilisé (précisément parce que "ça ne sert à rien" tant que ça n'est pas supporté par les navigateurs). Je trouve que vérifier sérieusement l'identité physique des gens est quelque chose de plutôt positif pour un CA, mais je n'ai pas d'avis au delà de ça (mais libre à toi de ne plus répondre et rester "en mode rigolo" comme tu dis…)

Est-ce qu'il faut un noyau spécial ? Des modifs dans l'userspace ? En gros, est-ce qu'on est limité à une distro spécifique fournie et maintenue par le constructeur ?

D'après ce que je comprends ils ont sollicité free-electrons et souhaitent au moins être sérieux sur le respect de la GPL (contrairement à beaucoup d'autres produits basés sur des chipsets du même constructeur). Pour rappel parler de "une Debian standard" dans un contexte ARM (i.e. non x86) nécessite de distinguer kernel et userland

• le userland (sauf exceptions / programmes qui tapent dans le hardware depuis le userland, e.g. xorg) est à peu près toujours compatible avec tous les SoCs ayant le même jeu d'instruction. Donc un rootfs Debian ARM64 fonctionnera a priori sur toutes les cartes ARM64. C'est ce qui permet aussi de faire tourner Debian dans un chroot sur Android.
• mais avant tout, il faut un bootloader et un kernel. Le bootloader est spécifique au SoC et à la carte-mère (mais on ne le change pas tous les jours). Concernant le kernel
  • sur le boot / introspection : soit le constructeur / fabricant de SoC est sympathique et se base sur un kernel moderne et sur un device-tree (ou une variante. Allwinner utilise un système à lui appelé FEX), soit le kernel devra inclure un support spécifique à ta carte-mère (donc au produit, e.g. board-file.c) qui ne sera pas inclus dans l'arbre officiel Linus et devra donc être maintenu à part sur le long terme. Le dernier numéro Open Silicium explique très bien ce sujet.
  • sur les drivers et autres trucs spécifiques au support du SoCs : soit le constructeur travaille avec la communauté pour contribuer au noyau standard, soit les sources du kernel pour ce SoC seront sur un dépôt à part (et seront donc à maintenir sur le long terme). J'avais cru comprendre que Allwinner s'améliorait et travaillait désormais de plus en plus avec la communauté, mais le site linux-sunxi dit très clairement "Allwinner does not actively participate in or support this community. In fact, it is violating the GPLv2 license in several ways and has so far not shown willingness to resolve this" donc c'est probablement la communauté linux-sunxi qui est à remercier en premier lieu et sur laquelle il faut compter.
  • (N.B. évidemment, je suis parti du principe que les sources du kernel/bootloader sont disponibles - ce qui devrait être le cas ici. Mais malheureusement trop souvent les produits pas chers sont en provenance d'un grand pays où ils s'assoient sur la GPL, et dans ce cas tu n'as pas les sources du kernel ni du bootloader. C'est à peu près ce qui se passe pour la plupart des smartphones/tablettes/routeurs à bas coût à base de chipset Mediatek/Allwinner/AmLogic/Rockchip/Action-semi/… Et dans ce cas, pas de recompilation du kernel possible)

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…