Le 09/03/2024 à 15h 04

la moindre incartade par rapport à la séquence minutieusement préparée pour la Keynote et le bordel partait en cacahuette

On ne peut pas faire pire que la présentation de Windows 98, et son fameux blue screen of the death

Le 08/03/2024 à 21h 37

Pour information, Apple a rétablit l'accès au compte développeur d'Epic Games :


source

Le 07/03/2024 à 17h 00

Ah pardon ! Je suis désolé, ils ont fortement innové... dans les méthodes pour garder captif les utilisateurs et freiner/entraver toute concurrence. Ils sont pionniers là-dessus !!

Le 09/03/2024 à 15h 01

Punaise, je crois que j'ai besoin de vacances... Je n'arrête pas de faire connerie sur connerie. J'ai pris l'abonnement sur le mois, pas sur l'année. Forcément, ça fait un facteur 12 d'écart... Déjà que je m'étais planté avec la TVA....

Bon, m'en vais m'acheter du temps de repos moi...

Le 09/03/2024 à 11h 48

Cette taxe est une connerie sans nom (comme pas mal de taxes en France) mais l'argumentaire de Spotify me sort par les yeux.

Pour la taxe, je suis entièrement d'accord. Pour l'argumentaire, je l'avais compris, mais sans trop comprendre pourquoi. Ils ont absorbés par le passé pas mal d'augmentation. Ils font aujourd'hui un rattrapage, car cette nouvelle taxe est la goutte de trop.

J'ai repris les chiffres du dernier rapport trimestriel de Spotify dans lequel ils mettent que les abonnements représentent 85% du CA de Spotify

Je pense réellement que c'est plus compliqué que ça. Spotify France a un CA de 53 millions d'€ en 2022. Spotify annonce un CA de 225 millions d'€, non pas pour Spotify France, mais pour, je cite la brève la seule musique enregistrée en France.

On voit donc déjà, que le calcul de base est loin d'être simple sur la notion de CA à prendre en compte (on a un facteur x4 entre les deux quand même).

Maintenant, faisons ensemble le calcul, sur la base du CA donné par Spotify, soit 225 millions d'€. Cela revient à 191 millions via les abonnements, soit, si on considère le prix de l'abonnement le plus cher (18€/mois), 10,6 millions d'abonnement prémium famille. En 2021, Spotify enregistrait, pour la France, 17 millions de visites mensuelles uniques (visite, pas abonnement).

Il faudrait donc que :
- près de 2/3 des visiteurs aient un abonnement
- qu'ils prennent le plus cher

Quand on relativise par rapport aux 30% d'abonnés annoncés par Spotify par rapports aux visiteurs mensuels, on arrive à la conclusion que soit la France est un pays qui a massivement adoptés Spotify (beaucoup plus que dans d'autres pays), soit qu'il y a véritablement un problème quelque part.

Si on conserve les 30% de visiteurs ont un abonnement, même en prenant l'abonnement le plus cher, le CA annoncé prix en compte pour le calcul de la taxe n'est tout simplement pas atteignable par le CA des abonnements prémium en France. On en est bien loin. Donc on sera bien loin d'une augmentation de 13cts pour compenser la taxe.

Pour finir, c'est pour ça que je pense que :
- l'augmentation, même de 1€, pourrait tout à fait être légitime
- qu'ils nous manquent des informations pour faire une analyse complète

Le 09/03/2024 à 09h 54

Tu as raison les abonnement c'est seulement 85% des revenus de spotify donc ça fait 13 centimes d'augmentation à prévoir et pas 11 centimes.

Il doit nous manquer une donnée quelque part, car en prenant tes chiffres (que je retrouve ici par exemple), même avec 100% des visiteurs avec un abonnement premium, Spotify aura du mal à atteindre le CA annoncé. Il doit y avoir d'autres sources de revenus non mentionnés.

Donc s'ils augmentent d'1 euro l'abonnement (c'est plus ou moins ce qu'avait annoncé Antoine Monin en décembre) ils répercuteront l'intégralité des taxes à leurs clients. Mais comme dans le même temps ils auront versés beaucoup moins aux différents festivals en France (pour le même motif) bah ils sont quand même gagnant.

Ou ils vont réaugmenter leur participation aux festivals ? Ou compenser les pertes ? Est-ce que dire je compense les pertes c'est être gagnant ? Il ne s'agit pas ici d'augmenter les tarifs afin de gagner plus d'argent pour remplumer des actionnaires, mais pour essayer d'atteindre la rentabilité.

Spotify a montré une voie nouvelle pour le streaming musical. Je pense qu'il serait dommage et dommageable qu'elle disparaisse.

La réalité c'est que le business model de spotify ne tient pas c'est tout.

Ca, on est d'accord. Mais c'est de base, sans même parler de cette taxe. Spotify a survécu jusqu'ici grâce aux différentes levées de fond qu'elle a pu faire par le passé, ce qui lui a permis de compenser ses pertes. Mais quand on enregistre plus de trimestre à perte que de trimestre à gain, il y a effectivement un souci dans le modèle de financement.

Maintenant, si tu rajoutes la nouvelle taxe, la situation ne peut qu'empirer.

Le 08/03/2024 à 15h 51

Oh putain oui, je me suis fait avoir comme un bleu

Bon, ça change pas grand chose sur le principe. Pour les calculs, étant fait au doigt mouillé, un de plus ou un de moins ne change pas grand chose ^^

Le 08/03/2024 à 14h 04

Le prix de la taxe n'est pas à calculer à partir du prix de l'abonnement, mais à partir du CA.

Les abonnements seraient la seule et unique source de revenu, cela reviendrait au même. Ce n'est pas le cas.

Après, comme ils ont déjà par le passé raboter les marges, autres moyens de manoeuvre, ils vont sans doute en profiter pour "rattraper" un peu et conserver un prix psychologique.

Le 08/03/2024 à 11h 23

La taxe porte sur le CA, non sur les bénéfices.

Tu peux très bien avoir un CA de plusieurs millions ou milliards et pourtant, enregistrer des pertes chaque année.

Examinons le cas Spotify, avec les données de 2022 :
- 225 millions d'€ de CA pour la France
- taxe à 1,2% => 2,7 millions
- en 2022, Spotify comptait 188 millions d'abonnées Premium pour 433 millions d'utilisateurs dans le monde
- en 2021, Spotify comptait 17,5 millions de visite unique mensuel pour la France
- en considérant le même ordre de grandeur entre 2021 et 2022, et en considérant le même ratio abonnement premium / nb utilisateurs, on arrive à 7,6 millions d'abonnement premium pour la France, en 2022
- 2,7 millions d'€ / 7,6 millions d'abonnement = 35cts à répercuter par compte.

Je ne connais pas la marge de Spotify par abonnement, mais si tu prends un abonnement à 10€ :
- la TVA : 2 € (il reste 8€)
- les 2 / 3 sont reversés aux ayants droits => 8 * 2/3 => 5,33. Il reste donc 2,66€
- si on prend en compte une marge de 20% par rapport à ses coûts réels (ce qui ne serait pas mal). On obtient un bénéfice de 0,53€ / abonnement prémium.

Compare ça au 35cts à répercuter. C'est très loin d'être anodin (Note au passage que je n'ai pas pris en compte le soutien à la culture (notamment les festivals)). Mais ça permet de se donner une idée : avec mon calcul au doigt mouillé, on arrive à 2/3 des bénéfices engloutis par la taxe (mais cela peut être beaucoup plus voire même générer des pertes).

Rajoute à ça que Spotify enregistre tantôt des pertes, tantôt des gains, j'en déduis que mon calcul est plus qu'optimiste et que la taxe viendrait engloutir tout bénéfice que pourrait réaliser Spotify. Dans ce cas, sans augmentation de prix, la seule vraie solution de tout entrepreneur, c'est de quitter le marcher si celui-ci n'est pas viable.

Le 09/03/2024 à 09h 57

Ca ressemble à ce qu'une description de produit pourrait être. Et je ne doute pas que ChatGPT a aussi été alimenté avec de nombreuses sources de ce type ;)

Le 08/03/2024 à 21h 42

Allez, je me prends au jeu : voici le description d'un stylo Bic :

-------

Plongez dans l'univers du raffinement absolu avec le stylo Bic, une œuvre d'art incontournable dans le domaine de l'écriture. Dès le premier contact avec ce joyau de la technologie, vous ressentirez une fusion harmonieuse entre la perfection esthétique et la fonctionnalité sans pareille. Avec son design épuré et sa silhouette élégante, le stylo Bic se distingue comme le summum de l'élégance, élevant chaque trait de votre écriture à un niveau d'excellence inégalé.

Fort de décénies d'expérience), presque séculaire, et d'un savoir faire hors du commun, nous innovons sans cesse depuis 1945 afin de vous fournir un confort d'écriture inégalable. C'est en 1950 que le premier stylo Bic sort, sous la houlette de Marcel Bich, donc le nom du stylo, quasi-éponyme, est en honneur de son créateur.

Fierté nationale, la première entreprise ouvre en France dans la ville de Clichy, avant de connaitre une ascension/expansion (NdMoi : j'hésite entre les deux, ascension me parait plus surperlativesque ^^) internationale fulgurante qui n'aura de cesse de s'étendre, aujourd'hui encore.

La précision sans faille de la pointe offre une expérience d'écriture d'une fluidité incomparable. Chaque mouvement est un ballet gracieux, chaque mot est une œuvre d'art. Doté d'une encre d'une qualité supérieure, le stylo Bic dépose sur le papier des lignes d'une netteté exceptionnelle, capturant ainsi chaque pensée avec une clarté cristalline. En main, il devient une extension naturelle de votre créativité, vous permettant d'exprimer vos idées avec une aisance déconcertante.

La durabilité exceptionnelle du stylo Bic en fait un compagnon fidèle pour toutes vos aventures. Construit avec des matériaux de première qualité, ce stylo résiste aux rigueurs de la vie quotidienne, assurant une performance constante quel que soit le défi. Que ce soit pour prendre des notes lors de réunions intenses ou pour écrire vos pensées les plus profondes dans votre journal intime, le stylo Bic est là pour vous accompagner à chaque étape de votre parcours.

Plongez dans le luxe ultime de l'écriture avec le stylo Bic, une fusion parfaite entre l'innovation et l'élégance intemporelle. Offrant une expérience d'écriture sans compromis, ce bijou de sophistication est bien plus qu'un simple outil - c'est une déclaration de style, une affirmation de votre quête constante de l'excellence. Avec le stylo Bic entre vos mains, chaque mot devient une œuvre d'art, chaque signature devient une manifestation de votre grandeur.

[edit]
Sur la suggestion d'Aristide Rutilant, j'ai rajouté deux paragraphes sur l'histoire du stylo. Les modifications sont en italique

J'ai même rajouté la page Wikipédia, dont je me suis servi pour l'histoire. J'en profite pour souligner un bogue dans la gestion des commentaires en présence de parenthèse. J'ai feinté en remplaçant la parenthèse fermante par son équivalent Url encodé ) (c'est un truc d'informaticien, mais fonctionnel ^^)

Le 08/03/2024 à 21h 31

Bon édito. Surtout le début. Tellement vrai !

Pour ma part, j'adore les "leader dans son domaine" pour une boite qui a 6 mois et dont le produit n'est pas encore en sorti ! (véridique ^^).

Après, dommage que cela tourne sur du Apple bashing (ok ok, je sais qu'Apple le cherche en ce moment entre le DMA, les amendes, les ouinouins, etc.). Mais il y avait tellement à dire sur d'autres acteurs que je trouve dommage que les 2/3 de l'édito soit uniquement sur Apple ;)

[edit]
J'ai oublié : même pas un mot sur Gerlain et sa crème quantique.

Le 08/03/2024 à 15h 07

Les problèmes d'installations et de documentation sont plus ou moins courant. Je subodore que certains projets le fasse volontairement, justement pour inciter les utilisateurs à prendre la version payante avec support plutôt que de passer tout seul dans leur coin, sans doc (ou pire, pas à jour) pour installer un truc.

Le 08/03/2024 à 14h 31

Le monde devenant très manichéen, certains en oublie les nuances... Il existe une solution à la croisée des chemins entre le libre et le propriétaire : les licences dites source available.

Le code source est disponible (dans le sens, lisible), mais sans pour autant avoir les 4 libertés fondamentales du libre. Celle qui "saute" souvent c'est la liberté de redistribution dans un cadre commercial.

Plusieurs projets, anciennement open-source, ont changé de licence pour des licences de ce type. La plus connue est sans doute la SSPL (Server Side Public Licence) initiée par MongoDB et adoptée par d'autres depuis (Elasticsearch, Kibana, ...).

Je pense qu'une licence de ce type, pour la recherche, serait tout à fait utilisable et un bon moyen de garder une certaine transparence (surtout lorsque les logiciels sont issus de la recherche publique) tout en n'étant pas incompatible avec un juste retour sur investissement lorsqu'exploité à des fins commerciales.

Le 08/03/2024 à 09h 53

Cool

Le 07/03/2024 à 18h 01

ce n’est pas moi qui ai le plus de poils aux fesses.

C'est pas bien de taper là où ça fait mal :'(

Règle n°1 : un robot ne peut porter atteinte à un être humain, ni, en restant passif, permettre qu'un être humain soit exposé au danger

Méga snif

Le 07/03/2024 à 17h 18

Merci. Et la date stellaire ?

Le 07/03/2024 à 16h 55

Réponse : humide !

Sinon, il sera quelle heure demain ? Merci :)

Le 06/03/2024 à 15h 03

Il y a surtout besoin d'IA pour remplacer les dev dont les neurones ont grillé xD

Bon boulot les gars. J'étais tombé sur la fonctionnalité "signet" par hasard. Il va falloir que je la teste avant de l'attester ( Je suis Ness_01, la première IA à reprendre en main un site de presse au monde.

Par contre, ça je ne suis pas sûr. Désolé de contrecarrer les plans machiavéliques de gourou suprême. Même l'autre gogole se plaint des contenus générés par IA depuis des mois. Je crois que vous avez un train de retard (peut être à cause d'une manœuvre malsaine pour entraver la concurrence ceci dit)


----
Ce message est à caractère humoristique et à prendre au second degré. Je ne traite personne de gogole, j'ai juste fais une faute de frappe volontaire

Et aucun petit FDP chaton n'a été maltraité durant la rédaction de ce commentaire.

Le 08/03/2024 à 09h 05

Pour être précis, pour annuler, il faut demander une "révocation". Qui est effectivement différent de l'opposition :
- révocation : forcément gratuit, annule tout prélèvement à venir. On retire l'autorisation de prélèvement (quand il y en a une !)
- opposition : gratuit ou payant (ça dépend des banques), ne concerne qu'un seul et unique prélèvement, sans impacter ceux qu'il y aura ultérieurement.

L'opposition est plutôt utilisée en cas de conflit / désaccord (genre ton fournisseur d'électricité qui te balance une somme complètement farfelue).

La révocation, c'est en général une bonne idée lors de l'arrêt d'un abonnement (mobile, internet, salle de sport, assurance, magazine, ce que vous voulez) pour éviter des prélèvements indus, des démarches pour se faire rembourser ensuite, etc...

Le 07/03/2024 à 10h 33

Bon, tu ne fait qu'effleurer la surface et tu campes sur tes positions.

Si, pour toi, une réponse détaillée comme je l'ai fait, ce n'est qu'effleurer la surface... Tu dis ça parce qu'on ne s'intéresse pas à l'algo qu'il y a derrière ? Tu veux des félicitations pour quoi ? Pour le fait d'avoir 2 buffers qui contiennent la valeur courante et la valeur précédente, et que tu switch de l'un à l'autre avec un pointeur sur la base d'un modulo 2 ? Ok, félicitation.

Et il est vrai que tu ne campes pas sur tes positions non plus

Tu nous fais le chapitre du programmeur absolu qui ne sait pas contextualiser. Et justement, la contextualisation permet d'ajuster le code avec ce qui est nécessaire. C'est un ensemble. Pour faire tourner une application dans un datacenter la composante plateforme de production est très importante (puissance de calcul, système d'exploitation ...) dans la conception du code.

C'est là où tu fais une énorme erreur. Ce n'est pas que je ne sais pas contextualiser. C'est que ton outil, il est dispo en ligne et en open-source. Tu ne peux pas savoir COMMENT il sera utilisé, ni par QUI. (En fait, je ne devrais pas dire open source, car il n'y a pas de licence. Il est en source available).

Ne sachant ni comment, ni par qui, tu ne peux pas savoir s'il va être utilisé ou pas pour y exploiter des failles. Et je t'ai donné l'exemple d'une faille qui est présente.

Je vais faire le vieux con et j'aime pas ça : un programme ne tourne pas tout seul, il lui faut un OS et une machine pour fonctionner.

Justement ! (sur la partie en gras). Un programme ne tourne pas tout seul. Ton cas d'usage perso, pour lequel tu l'as développé, c'est peut être OK pour toi. Maintenant, je le répète :ton programme est en ligne. Du coup, tu ne peux pas savoir s'il est utilisé ou non, ni comment, ni par qui, ni dans quel environnement.

Ne sachant pas tout ça, tu dois protéger au maximum pour éviter les problèmes et les failles. Ton programme ne serait utilisé que par toi, sur ton serveur avec 16Go RAM utilisant une Debian12 à jour dont le seul accès est un SSH par clé 4096bits en utilisateur simple. Oui, ton programme suffit tel qu'il est. Sauf que ce cas d'utilisation, tu ne peux pas le garantir. C'est aussi simple que ça, et c'est ça qu'a priori, tu ne comprends pas.

Mais bon, pour ça, il faut avoir un peu plus de bagages que des formations médailles en chocolat de paramétrage de frameworks en java. Tout le monde sait qu'avec Java, on a pas besoin de machine et de système d'exploitation !

Hmmm, mon trollomètre détecte une attaque ad hominem. Et si tu apportais une réponse précise sur des bases techniques, au lieu de vouloir t'attaquer aux compétences de ton interlocuteur ?

Le 07/03/2024 à 08h 53

Contrôle des pipes : la chaine de caractère finit dans un atoi ... qui sortira une valeur nulle au pire. Et la plupart des programmes qui utilisent des pipes font des appels comme ça : pclose(popen("commande","r")); ... surtout utilisé dans les programmes multi-threadées pour remplacer la fonction system() non compatible avec le multi-threading.

Depuis quand "la plupart des programmes" c'est une justification pour faire quelque chose qui s'apparente à une mauvaise pratique ?

Et puis, pas de bol, je ne parlais pas de ça (du aoti). Je parlais d'aller lire un flux sans même savoir s'il est ouvert correctement ou pas.

Contrôle du système de fichiers : surtout sur une arborescence mémoire montée par le noyau (et donc mécaniquement présente sinon tu n'aurais pas même pu te connecter à la machine).

Il est effectivement impossible d'avoir un programme tournant dans un environnement "sécurisé" comme les conteneurs, un chroot, ou dont l'accès à cette partie du système de fichier est interdite via des règles de gestion fine. De même qu'il est impossible que la limite du nombre de descripteur de fichiers ouverts soit atteinte. Tant de certitude...

Un contrôle de malloc unitaire sur des tailles maîtrisées (dépendant du nombre de cores/threads et non d'un paramètre utilisateur) ... t'es gentil. Tu passerais ton temps à faire des malloc / realloc dans des boucles et/ou des malloc dépendants de paramètres utilisateur (donc potentiellement déconnants), là, oui le contrôle des valeurs retournées est obligatoire.

Es-tu certains à 100% que les appels à malloc soient maitrisés ? Moi non. Le premier dépend de la valeur de retour du programme "nproc" : le premier programme "nproc" trouvé qui sera dans le PATH (c'est ça la faille qui ne dépend pas du langage : utilisation d'un programme sans préciser son chemin absolu, permettant de le substitué très facilement). Ton nproc renvoi 100000000 et boum.

En gros, ton programme, je peux lui faire consommer 4Go très facilement si j'en ai envie. Toujours maitrisé donc ?

De plus, tu sembles considérer des ordinateurs avec une mémoire de plusieurs Go. Sache que Linux tourne sur de nombreux terminaux. Par exemple, des routeurs. Celui que j'ai et sur lequel tourne OpenWRT ne dispose plus que de quelques ko (oui oui, quelques ko !).

Effectivement, tu fais bien d'arrêter ... parce qu'enfoncer les portes ouvertes des « bonnes » pratiques trouvées sur wikipedia, n'importe quel script-kiddie en est capable.

Que d'arrogance.... Que répondre à ça, si ce n'est que tu ne sembles même pas comprendre les bases de la sécurité informatique dans les programmes...

Tu n'as même pas essayé de comprendre l'algo (d'ailleurs personne n'en a parlé) et

En toute honnêteté, on s'en fiche de ton algo. C'est pas le but de la discussion. Le but c'est l'apport d'un langage comme le Rust par rapport au C.

pourquoi les contrôles que tu dénonces manquants ne sont pas nécessaires.

Et moi je maintiens qu'ils sont nécessaires. Pas pour le cas "normal" (on est d'accord la-dessus). Mais un attaquant qui cherche à exploiter une faille n'en à rien à faire du cas normal. Ce qui l'intéresse, ce sont les effets de bords exploitables.

Et désolé de te le dire, mais ton programme, pourtant court, présente de nombreuses failles que ton orgueil refuse de considérer.

Maintenant, puisque tu as trouvé des « failles », je te propose de mettre à jour le bout de code et de nous montrer comment il devrait être.

Pas de souci. Je peux. Où puis-je t'adresser mon devis ?

Le 06/03/2024 à 22h 50

J'ai regardé ton programme, histoire de m'amuser. Je me considère rouillé en C, dans la mesure où je n'en fais plus depuis fort longtemps. Voici ce que j'ai vu, qu'un langage comme Rust ne laisserait pas passer :
- fonction GetNbCore() : aucune vérification sur l'accès au pipe, ni aucune gestion des erreurs.
- fonction read_freq() :
- idem, aucune vérification quant aux accès au système de fichiers
- pas de vérification de la valeur de retour des appels à malloc
- je ne vais pas dire que la mémoire n'est pas libérée, puisque ton application à juste besoin d'allouer de la mémoire au début une fois pour toute au début de l'application. Une fois qu'on est dans la boucle principale, aucune allocation n'est faite.

Je m'arrête là pour l'analyse. Un attaquant aurait de quoi largement faire avec ce petit programme ^^ Surtout qu'il y a d'autres problèmes (mais pas lié au langage lui-même).

Le 06/03/2024 à 10h 50

Et c'est sans compter que le point médiant est une véritable plaie pour de nombreux utilisateurs de dispositifs de lecture vocale, comme les mal voyants par exemple.

Le 05/03/2024 à 08h 59

Non seulement il est encore utilisé, mais il continue d'évoluer ! La dernière version date de 2023 ;)

Le 04/03/2024 à 16h 34

Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.

Toujours regarder en détail les benchmarks, sinon, on y voit ce que l'on veut ;)

En l'occurence, je vois 2 gros points noirs qui viennent complètement fausser la comparaison :
- Apache + PHP, et non Apache + FastCGI/PHP (un context PHP est recréé à chaque requête, forcément, ça fait mal)
- A une époque pas si lointaine, les serveur nodeJS n'étaient jamais en front, toujours derrière un reverse proxy comme... Apache (les choses ont peut être changées depuis, d'où l'usage du passé). Quand on commençait à vouloir faire de la mise en cache, de la compression gzip à la volée ou même tout simplement du SSL/TLS, nodeJS était nul, sans compter sur l'explosion de la mémoire nécessaire.

Le 04/03/2024 à 14h 09

Merci du retour.

Effectivement, le benchmark que j'avais vu, c'était principalement du code séquentiel (comme la grande majorité des benchmarks)

Le 04/03/2024 à 11h 35

C++ et Rust ne partage pas la même approche pour le polymorphisme. C++ est basé sur l'héritage, ce qui n'est pas le cas de Rust.

Là où un remplacement par partie de l'existant peut se faire lors d'une transistion C => Rust, cela sera beaucoup plus difficile à mettre en oeuvre dans le cadre d'une transition C++ => Rust, sauf à remplacer d'un bloc tout un applicatif.

Remplacer un applicatif entier, cela présente de nombreux risques. Le faire uniquement parce que l'applicatif est écrit en C++, c'est une "mauvaise raison". Cela fait prendre d'énormes risques à court, moyen et long terme, pour des avantages qui ne se verraient potentiellement qu'à très très long terme.

Le 04/03/2024 à 09h 56

Côté perf, Rust est du même niveau que C. Je crois que le rapport entre les 2 est de 1,03 de mémoire

Et pour faire plus rapide que le C, c'est l'assembleur

Pas toujours. En tout cas, pour sur les architectures modernes. Les processeurs sont tellement compliqués, avec les pipelines, et tout le tralala qu'un code C optimisé par compilateur est souvent plus performant qu'un code assembleur écrit à la main.

Le 04/03/2024 à 08h 16

D'un point de vue technique, remplacer le C par Rust peut s'envisager. Pour le C++, cela me parait plus compliqué.

D'un point de vue pratique, ce n'est pas au législateur de s'occuper de ça (coup de bol pour eux, pour une fois, ils n'ont pas dit une grosse connerie). Sinon, en France, tout le monde serait équipé du pare-feu OpenOffice...

Le 06/03/2024 à 11h 58

Tout comme le fait qu'aujourd'hui, on paie plus cher une faille exploitable sur Android que sur iOS, le premier étant devenu plus compliqué à infiltrer.

Le prix d'une faille n'est pas lié qu'à la difficulté d'infiltrer un système. Ce qui fait monter les prix sur Android :
- la fragmentation : diminue les "risques" de correction (parfois, il faut attendre la maj qui dépend et du constructeur et de l'opérateur... quand le téléphone est encore supporté)
- la part de marché : Android a une part de marché bien plus importante qu'Apple (en 2021, c'était 84% !)

Ces deux facteurs augmentent drastiquement les possibilités d'exploitation d'une faille (aussi bien d'un point de vue temporel que d'un point de vue du nombre de terminaux vulnérable), et donc son prix.

Après, sur lequel est plus compliqué (d'un point de vue technique j'entends) à infiltrer, j'avoue ne pas avoir le recul suffisant pour trancher, même si mon intuition me dis que iOS est "plus résistant" qu'Android.

Le 06/03/2024 à 08h 21

Microsoft étant aussi Controleur d'Accès au sens DMA du terme dans la catégorie Système d'Exploitation, je m'attends donc à la même fronde envers Microsoft concernant l'arrêt du WSA que celui qui concernait l'arrêt du PWA sous iOS.

Le 05/03/2024 à 16h 12

C'est effectivement compliqué. La position de la FSF la dessus, c'est qu'importe le type de liaison, c'est un travail dérivé.

A leurs yeux, il n'y a que la notion de plugin qui peut être compatible avec ça (et encore, ça dépend des interactions entre le plugin et le programme).

Mais ça, c'est la vision de la FSF, pour éclaircir la vision qu'ils avaient lors de la rédaction de la GPL. Beaucoup ne partagent pas ce point de vue. Un exemple célèbre : Linus Torvald, qui autorise explicitement d'autres licences pour les drivers du noyau Linux.

Pour terminer, seul le "propriétaire" (j'en vois déjà s'offusquer de l'usage de ce mot ici dans un tel contexte ^^) peut attaquer en justice un non-respect de la licence. La FSF ne peut rien dans le conflit Orange/Entr'Ouvert, de même qu'elle est impuissante fasse au choix d'accepter des drivers non-libres / non-GPL au sein du noyau linux.

Le 05/03/2024 à 16h 00

Pas de souci. Les licences libres, c'est un vrai bordel pour s'y retrouver ;)

Le 05/03/2024 à 11h 47

Ensuite, sur la gratuité, la partie citée de la GPL dit bien que la bibliothèque LASSO doit être concédée à titre gratuit.

Héhé, tu tombes dans le même piège ;) Reprenons la GPL v2, section 2b :

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

La dernière partie est extrêmement importante : "to all third parties". Autrement dit, ce n'est pas le "destinataire direct", mais tous les autres derrières auxquels le logiciel est destiné.

Et si tu penses que je surinterprète, je t'invite à lire la section 1 :

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

Et si ce n'est toujours pas suffisant, dans le préambule :

When we speak of free software, we are referring to freedom, not price

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have.

La GPL n'a jamais imposé la gratuité à celui qui reçoit. Elle impose simplement à celui qui donne de ne pas pouvoir réclamer de "royalties" aux utilisateurs, qu'ils soient direct ou indirect pour une utilisation sur le long terme (autrement dit : pas d'abonnement).

La GPL encadre seulement le coût de la transmission du code source, qui ne peut excéder un coût de reproduction et d'envoi (sectino 3b comme déjà cité) .

Sur la fourniture du code source, tu as raison. Elle n'est pas obligatoire mais dans ce cas, le logiciel doit être accompagné d'une offre écrite valable au moins 3 ans de fournir le code source sur demande. Et c'est ce code source modifié qui doit comporter les indications de modifications datées.

Tout à fait. Il est vrai que je ne l'ai pas rappelé car présent dans la section 3b que j'avais justement citée. Mais tu as eu raison de la faire Merci.

Le 05/03/2024 à 08h 56

De plus, souligne le jugement, le logiciel aurait dû être concédé à l'État « à titre gratuit », le code source modifié aurait dû être communiqué, et Orange a « copié, modifié et distribué Lasso sans respecter l’ensemble des conditions du contrat licence ».

J'avoue être surpris par cette interprétation. En lisant la décision, La GPL v2 n'impose à aucun moment la gratuité, ni ne s'oppose à l'utilisation commercial. Pourtant, on trouve des contresens énormes à ce propos dans la décision. Exemple :

Au titre des faits de contrefaçon, la société Entr'Ouvert invoque trois violations du contrat de licence qu'il convient d'examiner comme suit, étant rappelé que le logiciel LASSO peut soit être exploité sous licence dite GNU GPL v2, licence « libre » et gratuite, soit sous licence commerciale si l'utilisation souhaitée n'est pas compatible avec les conditions imposées par cette licence libre.

LASSO est distribuée sous 2 licences :
- la GPL
- une licence commerciale pour les projets propriétaires.

Les licences libres ne s'intéressent qu'à celui qui reçoit (même si la notion de celui qui reçoit est parfois "ambigü" au point d'en faire des variantes comme la AGPL). La GPL impose le respect des 4 libertés fondamentales à celui qui reçoit. Donc ici, Orange aurait du livrer le code source du logiciel avec ses modifications. C'est reconnu par le jugement, aucun problème avec ça.

Par contre, cette notion de gratuité, non. La GPL stipule juste que le coût de la communication du code source doit se faire de manière raisonnable, notamment dans le cas où il est distribué sur un support physique (en gros, le prix du support + les frais d'envois). Mais nul part, la GPL n'indique qu'un logiciel sous GPL se doit d'être gratuit.

Certes, c'est plutôt rare d'avoir un logiciel payant, mais c'est plus une situation découlant des conditions de la GPL que de la GPL elle-même, car celui qui reçoit le logiciel, peut, à son tour, le distribuer selon les conditions qui lui conviennent, tant que ces dernières respectent la GPL.

Le jugement se base sur l'article 2b de la GPL, dont voici le commentaire de la cours de cassation :

b) Vous devez prendre les dispositions nécessaires pour que tout ouvrage que vous distribuez ou publiez, et qui, en totalité ou en partie, contient ou est fondé sur le Programme - ou une partie quelconque de ce dernier - soit concédé comme un tout, à titre gratuit, [you must cause any work that you distribute or publish, that in whole or in parts contains or is derived from the Program or any part thereof, to be licensed as o whole at no charge to all third parties under the termes of this license] à n'importe quel tiers, au titre des conditions de la présente Licence.

J'ai l'impression que la cours a un peu oublié de prendre en compte la dernière partie. Celui qui distribue (ici Orange), distribue son logiciel comme un tout à l'Etat, et ne peut prétendre à une quelconque rémunération / droits / licence d'exploitation pour les usages qu'en fait l'Etat. Mais Orange peut très bien vendre son logiciel à l'Etat (cela n'est absolument pas empêché par la licence).

De plus, pour les manquements liés au code source, il faudrait que je me plonge dans l'affaire pour voir les tenants et aboutissants, mais la GPL n'impose pas une livraison du code source en même temps que le logiciel. La GPL impose une communication à tout utilisateur (au sens de la GPL) qui en fait la demande (cf. section 3 b de la GPL).

Donc si l'Etat (qui a reçu le logiciel) n'a pas demandé le code source à Orange, il me parait bien difficile de parler de violation ici à cause de cette non communication.

Par contre, Orange a reconnu plusieurs torts. Les conditions de la licence n'étant pas respectées, la licence est nulle. Qu'Orange se retrouve donc en position de parasitisme ou de contrefaçon n'est, dès lors, guère étonnant.

Je ne me prononce donc pas sur le fond de l'affaire, juste sur des "détails" mais qui ont leur importance. La notion de licence libre et de gratuité véhiculée par le jugement de la cours de Cassation est une totale erreur en contradiction même avec la GPL.

Le 04/03/2024 à 20h 43

Blague à part, je me demande vraiment s'il pourrait apparaitre un 3ème acteur un jour ou l'autre...

Cela me parait difficile. Microsoft, malgré une certaine robustesse et un Windows Phone qui était fort bien pensé (je le préférais même à Android, aujourd'hui encore), s'est cassé les dents il y a quelques années, notamment à cause des applications (et surtout de leur manque).

Développer une application pour 2 systèmes c'est déjà galère, alors 3...

Un 3e acteur devrait se plier à certaines contraintes, comme supporter des applications en provenance d'autres store. Autrement dit, supporter les .apk (pour Android) ou les applications pour iPhone.

Ou alors il faudrait un standard pour le développement d'application mobile. Peut-être qu'un jour les PWA joueront ce rôle. Pour l'instant, le support est trop dépendant de la plateforme / du navigateur et souffre encore de certaines limitations pour pouvoir espérer en faire une solution "universelle".

Le 04/03/2024 à 19h 31

Je ne dirais pas sérieux en tant que tel. C'est une vision très exagérée.

Par contre, je vois bien Apple sortir plus ou moins cet argumentaire un jour ou l'autre, pour justifier sa position et se placer en tant que victime des méchants européens dans le cadre d'une négociation par exemple.

Mais je crois que mon commentaire a été pris un peu trop au sérieux. C'était tellement gros pourtant qu'il me semblait évident qu'il était emprunt d'une ironie certaine ^^

Le 04/03/2024 à 14h 47

Le jour où le bénéfice d'Apple chutera en Europe à cause :
- des amendes (comme celles-ci)
- de multiples procès
- de la concurrence (moins de revenus sur les achats in-app, les stores, ...)
- du coût de maintenir un produit à part
- qu'on leur dise comment faire un produit (choix navigateur, USB-C, etc.)

Apple décidera d'arrêter de vendre en Europe. Si cela semble irréaliste aujourd'hui, attendons de voir comment évolue le marché d'ici quelques années...

Le 04/03/2024 à 16h 38

Or, Apple a choisi de barrer la route aux services de streaming musical en leur interdisant plusieurs pratiques :

Pouvoir informer les utilisateurs des tarifs pratiques en dehors de l’application

Les informer sur les écarts de tarifs pouvant exister entre ceux de l’App Store et ceux pratiqués ailleurs, notamment sur le site officiel du streaming

Inclure des liens dans l’application pointant sur d’autres formules d’abonnement

Contacter les utilisateurs pour les prévenir que d’autres tarifs existent

Juste une précision : ces limitations n'étaient pas spécifiques aux applications de streaming musical, mais à toutes les applications disponible sur l'AppStore.

Le 04/03/2024 à 14h 13

Si on oublie le côté retraite, c'est Coluche qui disait ça me semble-t-il ;)

Le 04/03/2024 à 12h 01

Tu as oublié l'interdiction de faire des enfants. Ce n'est pas sans risque pour la maman (comme pour le bébé en fait).

En fait, c'est la vie qu'il faudrait interdire, c'est elle qui est mortelle. Plus de vie, plus de mort ! ()

Le 02/03/2024 à 12h 10

Dit comme ça, on est d'accord. Mais on ne commenterait pas grand chose s'il fallait attendre les décisions définitives des juridictions !

Et puis, pourquoi qu'on gueule sinon

Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?

De ce que j'ai retenu, le conseil d'état a surtout rappelé à la CNIL qu'elle ne pouvait pas interdire quelque chose par principe, car cela sortait de ses attributions.

La CNIL a ensuite revu un peu sa copie, et donner des consignes / critères d'évaluation pour déterminer la "conformité" des cookie-walls. On peut retrouver tout cela sur sa page dédiée au cookie-walls, notamment avec la notion de "tarif raisonnable", tout en rappelant que le paywall n'est pas "interdit par principe".

Pour finir, l'affaire Meta ne concernera au final que... Meta. La CNIL rappelle en effet que la détermination d'un tarif raisonnable dépend d'une analyse au cas par cas ;)

Le 02/03/2024 à 10h 52

La grosse différence entre un PWA et une application native, c'est que le PWA ne permet pas un accès complet au téléphone. Tu ne peux pas accéder aux Contacts, aux SMS, aux appels, etc. Les PWA ne sont pas disponibles sur le store non plus (bien qu'en théorie, ils pourraient l'être).

Une PWA ne peut pas faire tout ce que fais une application native, une application native peut faire tout ce que fait une PWA, sans compter qu'Apple à un droit de vie ou de mort d'une application sur l'Apple Store. Pour un certain nombre d'applications, l'application native était la seule solution. Notons également que les PWA sont disponibles depuis 2018 seulement (et avec encore moins de droit à l'époque par rapport à aujourd'hui) par rapport aux applications natives qui ont débarqués en 2008 (10 ans d'écart).

Là où je veux en venir, c'est que mon interprétation ou la tienne du "jargon juridique" (sans aucun sens péjoratif ici) n'a pas de valeur. Seule compte celle des autorités (ici l'Europe).

On peut prendre l'exemple des paywall pour les cookies, où, pour beaucoup, cela enfreint le caractère libre du consentement (qui est, pour rappel, un des 4 critères pour que le consentement soit valide). Pourtant, cela a été validé, dans une certaine mesure, par les CNILs.

L'extrait que tu cites du DMA est très intéressant, mais sa compréhension dépend de l'interprétation de certains termes, interprétation d'un point de vue juridique, pas d'un point de vue technique, notamment sur la notion de "navigateur internet" (et pour savoir si on considère qu'une PWA utilise un navigateur ou un moteur de rendu) et sur la notion "d'exigence" en présence d'alternative.

Que les choses soient claires. Je ne cherche pas à dire que tu as tord et moi raison sur le fait que cela enfreigne potentiellement le DMA (on s'en fout, et ce sont les autorités qui trancheront à ce sujet). Je cherchais juste à montrer que la conformité au DMA dépend de l'interprétation juridique que l'on fait des termes, afin de répondre à ton interrogation de savoir comment cela pourrait être conforme au DMA ;)

Le 02/03/2024 à 01h 25

Une PWA est une application. Elle ne nécessite pas un navigateur, mais des technologies associées classiquement à un navigateur (HTML, javascript, CSS).

Une application n'est pas nécessairement un PWA. Le développeur à le choix, et dans ce sens, Apple n'impose pas de moteur de rendu (ou de navigateur) pour le développement d'une application.

L'utilisateur a le choix aussi. Il peut utiliser ou pas l'application. Ou utiliser une alternative.

Dans le cas du navigateur, l'utilisateur se retrouvait, avant le DMA, à utiliser quoi qu'il arrive Webkit.

Pour résumer :
- le développeur n'est pas contraint à utiliser Webkit
- l'utilisateur n'est pas contraint par le choix du contrôleur d'accès (ici Apple), mais par le choix des développeurs.

Apple n'exige pas/plus des utilisateurs d'application d'utiliser Webkit.
Apple n'exige pas/plus des éditeurs qu'ils utilisent Webkit pour développer une application.
Les développeurs sont libres de faire du PWA ou du natif.
Dans le cas d'une application PWA, alors Webkit sera utilisé.

On peut trouver ça limite (et je trouve que cela l'est), mais juridiquement parlant, je ne pense pas qu'on puisse qualifier cela d'exigence dans la mesure où des alternatives existes. Et si ce n'est pas une exigence, ce n'est pas contraire au DMA.

Après, ce n'est que mon interprétation. Attendons de voir l'analyse que fera la commission européenne à ce sujet. C'est son analyse qui fera foi, pas nos avis respectifs !

Le 01/03/2024 à 18h 25

Cela me semble être une zone grise.

Le DMA mentionné explicitement l'usage d'un moteur de rendu au sein d'un navigateur internet, car cela viendrait influer grandement impacter les possibilités et les performances des navigateurs.

Une PWA n'est pas un navigateur. C'est une application. Elle repose sur un moteur de rendu pour son fonctionnement, mais cela reste une application et l'éditeur n'est pas contraint à ce choix. Il peut utiliser des alternatives, notamment en développant une application native.

En bref, c'est un beau casse tête, juridiquement parlant.

Le 29/02/2024 à 18h 34

Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜

Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre

Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).

Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API

PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.

[edit]
Après, niveau API, il faut faire attention au support par les navigateurs. Certains sont très en avance (Chrome) par rapport à d'autres (Safari).

Le 01/03/2024 à 16h 04

Histoire intéressante. Du coup, est-ce la thèse la plus longue au monde ?? xD (36 ans quand même !)

Le 01/03/2024 à 09h 30

Cf: https://next.ink/125503/trackers-dark-patterns-lufc-que-choisir-monte-au-creneau-mais-montre-le-mauvais-exemple/

Le 29/02/2024 à 19h 59

La seule chose qu'ils ont déjà, se sont les consommateurs. On les surnommes les iDiots ( )