groumly a écrit 3212 commentaires

Tant qu'on a pas de panne de micro dans la pièce du fond, tout va bien.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Je suis pas sur que tout le monde s'attendait aux performances annoncées.
'fin ils mettent la tannée a quasiment tout le haut de gamme x86, y compris les Xeon qui a eux seuls coutent 2 fois le prix de la machine entière, et prétendent pouvoir tenir la chandelle a une 3090 (qui a elle seule consomme quasiment de quoi organiser une petite free party, comme a la belle époque, fée peter mec!).

J'ai comme qui dirait des doutes sur les perfs du GPU, mais Apple a pas un historique a mentir sur les benchmarks, donc on verra bien.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Euh, et puis un peu le monstre qu’a l’air d’être le m1 ultra aussi quand même.
Les premiers benchmarks le mettent dans le haut du panier comparé à du haut de gamme x86, avec une consommation 4 à 5 fois moindre.

Et je sais que c’est rigolo de se moquer d’Apple pour les ports, mais l’iMac a un port sd depuis 2010, donc bon.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Qui se sent morveux, se mouche.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Dernier commentaire de ma part sur le sujet, parce qu’on commence à tourner en rond, je recopie juste ce que j’ai écrit plus haut:

La question est surtout est ce que ton code est correct? Parce qu’aller très vite pour donner la mauvaise réponse, c’est facile, je peux le faire moi aussi: 42, temps constant, je suis le plus rapide de la planète.
Ok, j’exagère un peu. Plus sérieusement, un lookup qui foire dans une hash map pour des raisons d’encodage de la clé, c’est quand même super ballot. Idem pour une recherche dans un index full text, ou un sed qui rate une substitution.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Unicode dit que l’existence de 2 formes pour é est un artefact d’encodage, inévitable vu le domaine, mais que les 2 encodages représentent exactement la même chose. Un peu comme un int casté en bool va traiter 1 et 2 comme étant la même chose (true).

Le but d’unicode, c’est précisément de découpler la représentation binaire du texte de sa semantique, pour que le code puisse opérer au niveau semantique. D’ailleurs, je dit texte, mais c’est même pas vrai, c’est juste un raccourci, Unicode gère plus que du texte, c’est le but.
Tout comme le but de if (myInt) est de découpler la représentation binaire de la semantique, et dans ce context 1 et 2 sont égaux.

Donc je te renvoie au commentaire au dessus.
Si tu traites un flux d’octets, oui, la normalisation est incorrecte et n’a pas de sens.
Si tu traites une chaîne Unicode, le standard dit que les 2 formes de é sont équivalentes et représentent la même chose, et ton code est cassé s’il ne fait pas ça. Je te rassure, il y’a énormément de code cassé sur ce sujet, Unicode est très loin d’être simple à gérer. Ce qui est justement ce qui me fait hurler quand je lit les commentaires d’uso.

Juste parce que tu peux traiter la String comme un flux d’octets et t’en sortir dans 98% des cas ne veut pas dire que c’est correct. Le problème du C, c’est précisément de dire « un octet et un char sont la même chose, d’ailleurs on a même pas de type pour représenter un octet, utilisé juste un char ». Ça marchait bien en 77 vu les contraintes, mais le monde a un peu évolué depuis.

passer en ascii standard (voir 7 bits) est une normalisation

comment tu normalises 😒 en ascii?

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Euh ouais, mais non la. La normalisation gère des situations sémantiquement identiques, pas de glyphes qui se ressemble suffisamment dans certaines polices.
L’exemple de base, c’est un e compose avec un accent vs un é.

Passer du cyrillique à un alphabet latin ne fait partie d’aucune normalisation, c’est comparer des choux et des carottes. Unicode fournit une liste de caractères sujet à confusion, si t’as besoin de vérifier ce genre de choses: http://www.unicode.org/Public/security/revision-05/intentional.txt

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

c'est que cela soit utilisé comme argument détracteur de Debian

Va falloir penser a prendre tes pilules, parce que t'es en plein délire la.

J'ai dit qu'avoir son soft intégré upstream dans une distro impliquait que la distro va applique des patches qui ne vont pas forcement plaire a l'auteur, ce qui peut être un problème pour l'auteur.
Si tu lit ca comme un argument detracteur de Debian, faut consulter, parce que ton syndrome de persecution est un peu trop prononcé.

alors que le principe même de Debian c'est de ne pas accepter un quelconque truc propriétaire (que cela soit un nom, une image, ou un bout de code).

Ca les a pas dérangé d'inclure thunderbird et firefox au debut pourtant. On va peut être arrêter de prendre ses vessies pour des lanternes.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

C’est pas si compliqué que ça.
Soit tu travaille des byte streams sans te poser la question des encodages et de la semantique des bytes, et Swift te donne cette possibilité, C aussi d’ailleurs.

Soit tu travailles sur des chaînes de caractères et t’es un peu obligé de prendre en compte la normalisation Unicode si tu veux émettre du code correct. Swift te donne cette possibilité. C aussi d’ailleurs, mais tu vas avoir beaucoup plus de boulot à faire.

C’est surtout ça qui m’ennuie dans ton commentaire, considérer qu’une String est juste un tableau d’octets. C’était vaguement vrai en 1977, mais ça fait plus de 20 ans que ça n’est plus le cas.

La question est surtout est ce que ton code est correct? Parce qu’aller très vite pour donner la mauvaise réponse, c’est facile, je peux le faire moi aussi: 42, temps constant, je suis le plus rapide de la planète.
Ok, j’exagère un peu. Plus sérieusement, un lookup qui foire dans une hash map pour des raisons d’encodage de la clé, c’est quand même super ballot. Idem pour une recherche dans un index full text, ou un sed qui rate une substitution.

T’imputes aussi une perte de performance à cette normalisation sans avoir la moindre idée du coût réel de cette normalisation.

Est ce que Swift est « plus lent » que du C? Oui, très probablement.
Dans quelle proportion est il plus lent? Ça depend du contexte.
Est ce que cette lenteur est causée par la normalisation? Probablement pas, en tout cas certainement pas au niveau que tu penses.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Je comprends très bien que c’est censé être une feature.
Mais c’est juste absolument délirant comme feature.

Les dates sont déjà assez difficiles à gérer tel quel, rajouter des trucs genre « une date invalide est considérée comme valide via des pirouettes intellectuelles » ne va vraiment pas aider.
C’est du même niveau que de dire « bah, les divisions par 0, c’est pas pratique de gérer les erreurs, alors on va dire qu’une division par 0, ça fait 0 ».

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance.

Potentiellement est utilisé de façon assez créative dans cette phrase. Et ya pas que le process de code review que ce patch a bypassé, après, je dit ça, je dit rien.

Je comprends bien que t’as juste envie me prouver que j’ai tort, mais que ça te plaise ou non, ça illustre parfaitement mon point. Debian à patché un soft (critique ou pas, c’est pas la question) à la truelle en ayant visiblement aucune idée de comment valider que le soft qu’ils livraient faisaient toujours ce qu’il était censé faire.

Ça donne pas forcément envie d’avoir son soft intégré upstream à leur distro, parce que si ça arrive sur un truc aussi gros et central qu’openssl, va savoir ce qu’il se passe sur des paquets moins populaires.

Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla.

Ben écoutes, c’est pas trop mal documenté.
Mozilla autorise l’utilisation de la marque firefox sous réserve que le source n’est pas modifié de façon non triviale, ou s’ils ont approuvé les patches eux même.

Thunderbird était déjà patché par Debian, et Debian savait très bien qu’ils allaient devoir patcher Firefox pour backporter au moins les patches de sécu. Et visiblement, ils avaient pas prévu de demander à Mozilla leur avis sur les backports.

Ce qui, oh, comme par hasard, me parait plutôt bien correspondre au concept de « patches non voulus ».

https://lwn.net/Articles/118268/, https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian ou encore https://glandium.org/blog/?p=97

Après, comme j’ai dit plus haut, t’es clairement la juste pour me contredire, je suppose que t’as pas supporté que je dise que C est largement cantonné à l’embarqué et bas niveau, donc je vais passer sous silence tes autre remarques qui n’ont pas grand chose à voir avec la choucroute, et je vais me retirer de ce fil, pas grand chose de productif n’en sortira.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.

Ok, mais ca aide pas avec les versions majeures. Tout le monde n'a pas forcement envie de se taper des gros changements comme ca. GTK3 n'est pas source compatible avec les version précédentes. GTK4 non plus.
Qt a l'air de se débrouiller un peu mieux sur la compat source. Quelqu'un qui distribue une appli

Je comprends bien la philosophie sous jacente qui pousse a faire des changements qui petent tout.
Devnewton demande pourquoi est ce qu'on pourrait vouloir embarquer un framework en statique, je lui dit pourquoi certains sont intéressés par du tout statique.

J'ai pas d'exemple de patch non voulu sur GTK/Qt que je ne suis pas plus que ca, mais il me semble qu'OpenSSL a trouvé a redire sur un certain patch de Debian.
Iceweasel est né d'une dispute entre Mozilla et Debian au sujet des patches de Debian dans firefox.

Apres, tu me crois, tu me crois pas. C'est toi qui voit. Linus Torvarlds a l'air d'être du meme avis que moi, et tu serais mal venu de lui expliquer qu'il est ignorant a propos des problemes de link statique vs dynamique, les chaines de compilation ou comment les distributions fonctionnent.

https://youtu.be/Pzl1B7nB9Kc

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Ça dépend du contexte.
Sous Windows/macOS, la plupart utilisent les framework systèmes, qui sont compatible binaire dans toutes les directions, et ça just marche.
Ceux qui font du cross plateform avec qt ou quoi ou qu’est-ce vont de toutes façons devoir embarquer leur dépendance et les déposer quelque part a eux sur le système (sous macOS, typiquement dans l’app bundle, donc privé à l’appli, je sais pas trop où en sont les choses sous Windows de nos jours).

Sur ces plateformes, ça va, ça se gère sans trop de migraines. Mais après t’as Linux.
Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Si t’arrives a être intégré upstream, ça aide, mais après tu te tapes des patches qui te plaisent pas forcemment, tu contrôles pas quelle version est distribué, ce genre de choses qui peuvent être un gros problème en fonction du projet.

Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent ».
Et du coup, l’intérêt du link statique de go devient beaucoup plus apparent.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Ca montre surtout que les mecs de php sont des bras cassés, ce qui est pas franchement nouveau. Ils l’ont pas abandonné parce que personne en voulait, ils l’ont arrêté parce qu’ils n’ont pas réussi à l’implémenter, en grande partie parce qu’ils n’ont pas assez de gens sur les projets qui comprennent le problème.

Ça te surprend vraiment venant d’un langage qui considère que la date 0000-00-00 est équivalente à 1999-11-30, et ferme ça comme « not a bug, working as designed »?

Pour le « personne ne voulait vraiment la feature », je te renvoie à https://wiki.php.net/ideas/php6/unicode

Unicode still remains one of the top requested features in PHP.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

C’est moi, ou tu viens de sortir php dans une discussion sur les bons langages de programmation?

Après, je sais pas à quoi tu fais référence exactement que les mecs de php aient prit une décision à la con et n’ait pas réussi à fournir une implémentation correcte, ça serait pas la première fois (les mecs ont prit l’habitude de releaser avec des tests unitaires qui passent pas, alors on est plus à ça près), et que les mecs qui utilisent php ne comprennent rien à ce qu’il se passe non plus, ca serait pas la première fois non plus.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Je suis d’accord, la normalisation a rien à faire dans un langage de programmation, c’est pour ça qu’elle est définie au niveau d’unicode lui même.
Swift se contente d’implémenter la spec.

https://unicode.org/reports/tr15/

ce qui oblige à connaître l’encodage du texte comparé, ce que le == n’indique pas du tout — nécessairement il admet implicitement un encodage, mais lequel ?

Comment diable veut tu espérer comparer des chaînes si tu ne connais pas leur encodage? En l’occurrence, l’encodage est capturé à la source, quand tu construit la chaîne.

Les opérations d’égalité et autres manipulations se font ensuite de normalisée, vu que tout le monde est sur le même pied, via String. Tu peux recevoir une chaîne en UTF8, une autre en utf32 et une troisième en iso 8859-15, et les concatener ensemble, String sait comment faire vu que string connaît et comprend chacun des encodages. Ta chaîne sera correcte sémantiquement et techniquement, au niveau du buffer qui back la struct.

L’égalité par défaut va marcher au niveau sémantique, si tu veux comparer les char *, tu peux aussi, cf le code au dessus.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Plusieurs choses. Déjà c’est du Swift, pas du go. Les mecs de go ont pas de voyelles sur leur clavier non plus.

Ensuite, oui, == est souvent plus cher en Swift qu’un ==, mais pas pour les raisons que tu cites. C’est une égalité de valeur, pas de référence. Swift utilise === pour l’égalité de références.

Pour finir, la normalisation n’est pas appliquée à chaque égalité, mais a la constructiom, quand tu vas devoir itérer ta chaîne pour les raisons au dessus. J’ai pas les détails de l’implémentation, mais l’essentiel de ce que tu vois ici est appliqué de façon paresseuse. Tu le payes (presque) pas tant que tu l’utilises pas. Encore que, je suppute que utf8CString est simplement le buffer qui back la chaîne, ce qui me fait penser que même la normalisation est appliquée de façon paresseuse en fait.

Et oui, les mecs du runtime ont passé beaucoup de temps à peaufiner leur api string pour éviter que ça soit « bloated », c’est pour ça qu’on s’est tapé un changement d’api à mi chemin. Ça tourne sur des montres, donc bon, ils s’en sortent pas trop mal quand même.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo,

C’est assez particulier comme vision quand même.

Une bonne voiture ne se définit que par la capacité des conducteurs de refaire l’injection.
Un bon avion ne se définit que par la capacité des pilotes de refaire l’avionique.
Un bon cpu ne se définit que par la capacité de refaire les transistors.
Un bon immeuble ne se définit que par la capacité des architectes de couler le béton.
Un bon ballon de foot ne se définit que par la capacité du footballeur de refaire le ballon.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Est ce que t’as vraiment envie que tu compilateur ne puisse pas interpréter du texte correctement, et te balance une erreur de compilation qui n’existe pas a cause d’un manque de normalisation Unicode?

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

yep, leur code est cassé:

$ printf "\u00e9" > grep-simple.txt
$ printf "\u0065\u0301" > grep-double.txt
$ cat grep-simple.txt 
é%                                                                                                                                                                                                 $ cat grep-double.txt 
é%                                                                       
$ grep é grep-simple.txt 
é
$ grep é grep-double.txt
$ grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

En l'occurence, c'est le grep de macOS, je suppose qu'il vient d'un des BSD avec peu de changements.

Rien de tout ca dans un langage a runtime bloaté, évidemment:

import Foundation

guard CommandLine.arguments.count > 1 else {
    exit(0)
}

let input = CommandLine.arguments[1]
let single = "\u{00e9}"
let double = "\u{0065}\u{0301}"

print("They are equal: \(input == single) \(input == double)")
print("Or are they? \(input.utf8CString == single.utf8CString) \(input.utf8CString == double.utf8CString)")
print("The string sizes: \(single.count), \(single.count), \(input.count)")
print("The byte sizes: \(Data(single.utf8).count), \(Data(double.utf8).count), \(Data(input.utf8).count)")

Me sort:

They are equal: true true
Or are they? true false
The string sizes: 1, 1, 1
The byte sizes: 2, 3, 2 (ou 2, 3, 3 en fonction de l'input)

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Yep, c’est soit du code cassé, soit y’a une normalisation Unicode qui se passe quelque part.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

mais me faire imposer un compilateur trop gros, avec une lib standard tout aussi bloated, ça me donne pas très envie.

https://linuxfr.org/nodes/127047/comments/1884890 pour la source.

eux utilise les function de la lib standard, je crois pas être le seul à avoir des arguments un peu bidon, limite malhonnête.

Tant que tu te contentes de copier des buffers sans te poser la question de ce qu'il ya dedans, ca va probablement marcher.
Maintenant, demandes toi comment ca marche pour sed ou grep.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Tu ne peux PAS connaître la taille d’un texte sans l’avoir parcouru au moins une fois.

Le mot clé ici est "au moins". Le probleme du C, c'est que tu doit parcourir la chaine a chaque fois. Et encore, avec des résultats variables en fonction de ton encodage.

Et c'est pas entièrement vrai. C'est vrai pour une chaine allouée de façon dynamique (un input stream, ou que sais je encore).
Le truc, c'est que dans ces cas, tu as du parcourir la chaine en premier lieu pour la construire, donc tu as deja la taille disponible plutot facilement. Idem pour la plupart des operations de manipulations de chaines: soit la nouvelle taille se calcule de façon trivial en temps constant (substring, concatenation, etc), soit tu as 99% de chances de t'être tape un scan de la chaine pour ta manipulation, et tu as donc ta nouvelle taille.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.

j'oubliais celle la:

Bah oui, tu a dit qu'il n'y a aucun moyen de calculer a temps constant de calculer la longueur d'une string, c'est factuellement faux, bien que la technique ne marche pas tout le temps.

Tu joues au plus con la, tu pinailles, et t'as quand meme tord au final.
J'ai dit "une chaine", pas "une literal identifiée comme telle par le compilateur". Ce genre de raccourcis de comprehension va te poser des problemes en c, vu la precision du langage de la spec.
T'avais tres bien compris le sens de ma remarque. Tu noteras aussi que calculer la taille d'une chaine compile time constant, c'est pas particulièrement utile.

Effectivement j'ai pas parler de l'offset de 1, mais les 2 manières permettes de connaitre la longueur d'une string, chacune à leur avantages dans certaines conditions.

Nope, nope, nope.
Ta methode te permet de connaitre la longueur d'une chaine ascii, et uniquement une chaine ascii. "Une string" n'est pas une chaine ascii.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.