T’as pas l’air d’accepter les arguments rationnels, donc je t’en donne un émotionnel.
Trump a passé des mois à vendre l’hydroxychloriquine. Il en a même prit « préventivement », en tout cas parait il.
Quand il est tombé malade, qu’est-ce qu’il lui ont donné? A peu près tout, sauf de l’hydroxychloroquine. Pareil pour tous ses potes à qui il a refilé la chtouille.
Croit moi que s’il en avait prit, et que ça l’avait sorti de l’hôpital en 4 jours, on en aurait entendu parler, et pas qu’un peu.
Je n’ai connu le personnage que via linuxfr, et de ce que je me rappelle de ses débuts ici, c’est pas franchement étonnant. Son blog est inaccessible depuis un iPad cela dit, donc j’ai pas pu lire la source.
Mes condoléances aux proches, à la famille et à weboob.
Ça dépend. Tout le monde ne fait pas l’inference à la caml. Java, swift, kotlin aussi il me semble font de l’inference au call site, mais exigent de déclarer les types d’entree/retour.
Ca permet de supprimer l’essentiel de la lourdeur d’un typage fort old school, tout en conservant une bonne lisibilité du code.
Pour moi, pas besoin de sortir le bazooka pour tuer une mouche
je pense pas que se poser la question 2 secondes de ce qu’une fonction prend en entrée et retourne en sortie soit sortir un bazooka. Qu’on écrive un poc ou le système de navigation de new horizons, ça change pas grand chose.
y’a des arguments pour le duck typing, mais « j’ai la flemme de savoir ce que la fonction que j’écris est censé faire » n’en fait pas partie.
Du coup, le typage a un rôle bien moins important.
Foutaises. Le typage te dit « ton code est cassé », au moment ou tu l’écris, pas plus tard, quand tu le fais tourner. C’est toujours important d’éviter des erreurs, et le plus tôt le mieux.
D'ailleurs, cite moi des langages interprétés qui font vraiment de l'inférence
??
Le typage, c’est un truc de language compilé, pas interprété… y’a rien à inférer au runtime.
Sinon, je dirait swift, dans le sens où il support les shebang lines, mais je mettrais pas ma main à couper que c’est interprété.
Perso, quand je m'oriente sur des petits projets, des POC ou des scripts en one shot, j'aime bien passé par de l’interprété car ça me permet de faire vite.
Rajouter des infos de typage, c'est justement contre-productif dans ce cadre.
Pas vraiment, a mon avis. Si t'as des erreurs de types, ton code ne tournera pas comme tu le veux. Si t'es super chanceux, ca marchera peut etre. Ou pas. Qu'il fasse une seule ligne ou 2000 ne change pas grand chose a ca.
Apres, l'inference de type, c'est pas fait pour les chiens, ca supprime l'immense majorité de la lourdeur du typage fort, tout en conservant le typage fort. Et meme java le fait maintenant, c'est dire a quel point c'est mainstream comme feature :)
90% est probablement le bon ordre de grandeur, donc oui, ça accélère beaucoup les choses. Ce changement a méchamment cassé du code très utilisé en production (jsonkit notamment), ils l’ont pas prit à la légère.
Weak reste très courant, et est problématique, vu qu’il faut implémenter le reverse lookup, à la fois au retain et au release.
Je voulais préciser que les performances de retain/release chez apple (et d’une bonne partie du runtime objc) sont pleines de fast/slow paths.
Pour en rajouter une couche, le retain/release chez Apple, c’est tout un art.
Les chiffres qu’il donne sont pour le « happy path » il me semble, à savoir un retain count suffisamment bas, sans weak references.
Dans ce scénario, le retain count est stocke directement dans le pointer, un retain release devient donc une opération très simple de compare and swap.
Bien sur, cette optimisation n’est efficace que dans le cas de base, à savoir un retain count qui rentre dans les qq bits alloués dans le pointeur, sans weak references.
Note qu’ils font le même genre de tours de magies avec NSNumber, ou la valeur est stockée directement dans les pointeurs.
C’est bon de garder ça à l’esprit quand la team runtime chez Apple se vante de leurs performances. Ça reste très impressionnant quand même, et ça marche très bien la plupart du temps, mais il faut se rappeler que tu peux facilement rentrer dans le slow path, qui va clairement pas tourner en 15 nanosecondes.
C’est pas grâce aux caches, mais grace à un modèle mémoire différent qui leur permet de faire des opérations atomiques beaucoup plus rapidement. Le prix à payer est que des bugs multithreadés cause par un mauvais code vont se manifester, la ou la version x86 l’aurait empêché. https://twitter.com/catfish_man/status/1326269594818891776?s=21
C’est sur, mais d’un autre côté, c’est pas nouveau, ça fait des années que la ram est soudée, en tout cas pour leurs laptops. Le stockage se rajoute facilement avec de l’usb c.
Pour les desktops, c’est un peu plus discutable, c’est sur. Encore que les quantités de ram offertes ont pas évolué tant que ça ces dernières années, et sortie des cas pro très spécifique, je pense que le compromis n’en est pas vraiment un.
Pour être tout à fait franc, mon laptop à bientôt 5 ans, je pourrais pas te dire si j’ai 8 ou 16gb de ram, et j’ai jamais eu de problèmes de ram, malgré xcode, moultes simulateurs, moultes instances d’intellij et beaucoup d’applis diverses et variées qui tournent en parallèle.
Par contre, le throttling du cpu me pique tres souvent, plusieurs fois par jour. Et voyageant pas mal (bon, pas ces jours ci, forcément), la batterie est très importante.
Donc la pour le coup, le x86 va pas me manquer. Sans parler des problèmes de fat frameworks x86 vs arm pour le development cross platform iOS/macOS (Mais ca c’est un problème super spécifique).
La compilation est fortement cpu bound, pas mal I/O bound aussi (dans un contexte très particulier, à savoir énormément de toutes petites i/o).
Et ça se parallélise très bien, surtout sur de très gros projets comme ff.
Donc oui, c’est un bon test de la puissance pure du cpu et du coup des i/o.
après, c’est un peu dommage de tester x86 vs x86, plutôt que le sujet du moment, x86 vs m1.
Les tests que j’ai vu la dessus que ce soit en ligne ou sur notre projet pro, indiquent que le m1 met la tannée au machines x86.
Pour que la durée marche, il faut être d’accord sur la date à laquelle la durée commence, non?
Dit autrement « t’as cette ip pour 24 heures » ne veut pas dire grand chose si tu ne sais pas quand les 24 heures commencent.
J’ai remarqué quelque chose de similaire sur iOS récemment. Ça me fait penser que le problème pourrait être dans un framework populaire, genre react ou que sais je.
Ah bon?
On peut pas lancer une compilation d’un même projet avec la même version de clang/swiftc et voir combien de temps ça prend?
On peut pas lancer l’encodage de la même vidéo avec les mêmes encodeurs, et voir comment de temps ça prend?
On peut pas lancer le même programme en mode émulation, et voire combien de temps ça prend?
Ou un rendu 3D, ou des animations dans Uikit et mesurer les fps, ou quoi que ce soit qui utilise le cpu et mesurer si ça va aussi vite, moins vite ou plus vite?
Tu nous dit que c’est littéralement impossible de mesurer les performances d’un mac commun face à un pc spécifique, et déterminer lequel va le plus vite, lequel consomme le moins, quel autre compromis performance on peut trouver?
L’os est le même, le runtime est le même. Les optimisations sont différentes, mais dans un cas, ils connaissent la plateforme depuis 15ans, dans l’autre ils l’ont créée y’a 10 ans, je suis convaincu que s’il y a une optimisation hard à trouver, ils l’ont trouvée d’un côté ou de l’autre.
C’est sur, l’implémentation concrète est techniquement différente, mais j’ai vraiment du mal à voir comment tu contrôle pour ca, vu qu’on tente de comparer à travers des archi différentes, évidemment que l’implémentation est différente.
Le reste de tes questions c'est pas le sujet et de toute façon c'est déjà tout décidé par Apple, peu importe que les raisons soient dans l'intérêt de leur clientèle ou non.
Parce que les performances du cpu, c’est pas decide par apple non plus?
Donc, en fait, autant ne pas savoir, vu qu’Apple avait un but en tête avant de se lancer dans un projet aussi trivial que designer ses propres cpu. J’ai du mal à comprendre la logique je t’avoue.
Une vraie culture de scientifique assoiffé de connaissances, ma foi. Hacker du mois!
Pour moi un "ordinateur de bureau" c'est pas un mini-PC avec des composants de tablette ou de laptop conçus pour du nomade, c'est un ordi avec un processeur de gamme desktop optimisé pour la performance et non la consommation.
la vache, pour quelqu’un qui a posté pas moins de 4 messages pour se plaindre du manque de rigueur sur les benchs, tu manques vachement de rigueur avec ton vocabulaire.
“un desktop est un ordi avec un cpu de gamme desktop, optimisé pour la performance”. Ok, donc déjà la définition fait référence à la définition, et en plus ça contredit la définition déjà acceptée qui est “ordinateur conçu pour être utilisé sur un bureau, fixe”.
Un raspberry pi est un ordinateur de bureau, ne t’en déplaise.
D’un autre côté, savoir si le cpu serait 10% plus rapide avec un software different, ou dans un boîtier différent, on s’est cogne un peu, vu que ce serait pas en vente sur le marché de toutes façons.
La question c’est grosse modo: comment est ce que ce cpu arm se place face aux machines actuelles? Que ça soit du au hard ou au soft importe peu au final (surtout que bon, c’est largement le même soft, hein, macOS reste macOS, on va pas enculer les mouches).
Est ce que c’est suffisamment proche pour qu’on y perde pas grand chose au final? Quelle marge de manœuvre a Apple pour rattraper le retard? Qu’est ce qu’on gagne d’autre (batteries/bruit des putains de ventilos)?
C’est une question pertinente, mais j’ai pas de réponse. Je l’ai lu plusieurs dans des sources reputables, genre le nyt, mais j’ai pas de chiffres à te donner, non.
L’argument se tient toujours cela dit, vu la flambée de cas que la France se tape en ce moment, et la saison, je trouve ça dur de justifier de garder les bars ouverts, et ça serait criminel de pas faire quelque chose pour réduire la propagation.
Pour en rajouter une couche: l’augmentation des cas en France fait super peur. Je chiais dans mon benne en août (californie) parce qu’on tapait dans les 10k cas par jour, la vous vous tapez plus du double.
C’est grosso modo au niveau des us, ou la stratégie est « ça se trouves, si tu fermes les yeux, Covid disparaît, on peut pas savoir ».
Le fait est que ce gouvernement préfère traiter la crise en instaurant du contrôle social au lieu d'investir dans le service public hospitalier.
Ouais, mais d’un autre côté, on sait maintenant que Covid peut avoir des conséquences à long terme sur la santé, même si tu en guéri, et on a une meilleur idée de comment ça se transmet, typiquement les restos et les bars en intérieurs sont une calamité, particulièrement les bars pleins de gens bourrés qui se gueulent dans les oreilles.
Ça me parait pas délirant de vouloir limiter le nombre de contaminations en priorité.
Clairement, il faut de la capacité dans les hôpitaux aussi, mais éviter que les gens le choppent et le transmette me parait tout aussi important, a plus forte raison avec l’hiver qui arrive et donc beaucoup plus de monde qui reste en intérieur.
Ta réponse c'est qu'en fait il n'y a aucun problème parce qu'on peut s'en sortir pour 500 balles
Non, ma réponse c’est que tu racontes n’importe quoi. Personne ne te force à publier des applis pour une plateforme propriétaire. T’as du dépenser au moins 500 à 1000 euros pour developer sous android aussi. C’est la même chose chez Apple. Scoop: le matos Apple peut servir à autre chose que developer, et la plupart des devs iOS auraient acheté un mac de toutes façons, donc, non, c’est vraiment pas un problème. Y’a que des chouinasseurs dans ton genre pour s’offusquer de ça.
Leur matos ne te convient pas, l’achète pas, et passe ton chemin, mais je vois vraiment pas l’intérêt d’écrire la connerie que t’as écrite au dessus.
[^] # Re: On nous ment\^Winsulte.
Posté par groumly . En réponse au journal Réaction envers ce Hold-Up !. Évalué à 7. Dernière modification le 22 décembre 2020 à 16:49.
T’as pas l’air d’accepter les arguments rationnels, donc je t’en donne un émotionnel.
Trump a passé des mois à vendre l’hydroxychloriquine. Il en a même prit « préventivement », en tout cas parait il.
Quand il est tombé malade, qu’est-ce qu’il lui ont donné? A peu près tout, sauf de l’hydroxychloroquine. Pareil pour tous ses potes à qui il a refilé la chtouille.
Croit moi que s’il en avait prit, et que ça l’avait sorti de l’hôpital en 4 jours, on en aurait entendu parler, et pas qu’un peu.
[^] # Re: quand on lit ces notes...
Posté par groumly . En réponse au journal pankkake bronsonisé. Évalué à 7.
Je n’ai connu le personnage que via linuxfr, et de ce que je me rappelle de ses débuts ici, c’est pas franchement étonnant. Son blog est inaccessible depuis un iPad cela dit, donc j’ai pas pu lire la source.
Mes condoléances aux proches, à la famille et à weboob.
[^] # Re: Des bonnes idées
Posté par groumly . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
Ça dépend. Tout le monde ne fait pas l’inference à la caml. Java, swift, kotlin aussi il me semble font de l’inference au call site, mais exigent de déclarer les types d’entree/retour.
Ca permet de supprimer l’essentiel de la lourdeur d’un typage fort old school, tout en conservant une bonne lisibilité du code.
[^] # Re: Des bonnes idées
Posté par groumly . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
je pense pas que se poser la question 2 secondes de ce qu’une fonction prend en entrée et retourne en sortie soit sortir un bazooka. Qu’on écrive un poc ou le système de navigation de new horizons, ça change pas grand chose.
y’a des arguments pour le duck typing, mais « j’ai la flemme de savoir ce que la fonction que j’écris est censé faire » n’en fait pas partie.
[^] # Re: Des bonnes idées
Posté par groumly . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
Oui, alors ca, c’est très discutable.
Foutaises. Le typage te dit « ton code est cassé », au moment ou tu l’écris, pas plus tard, quand tu le fais tourner. C’est toujours important d’éviter des erreurs, et le plus tôt le mieux.
??
Le typage, c’est un truc de language compilé, pas interprété… y’a rien à inférer au runtime.
Sinon, je dirait swift, dans le sens où il support les shebang lines, mais je mettrais pas ma main à couper que c’est interprété.
[^] # Re: Des bonnes idées
Posté par groumly . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3.
Pas vraiment, a mon avis. Si t'as des erreurs de types, ton code ne tournera pas comme tu le veux. Si t'es super chanceux, ca marchera peut etre. Ou pas. Qu'il fasse une seule ligne ou 2000 ne change pas grand chose a ca.
Apres, l'inference de type, c'est pas fait pour les chiens, ca supprime l'immense majorité de la lourdeur du typage fort, tout en conservant le typage fort. Et meme java le fait maintenant, c'est dire a quel point c'est mainstream comme feature :)
[^] # Re: NSObject sur M1
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 3.
90% est probablement le bon ordre de grandeur, donc oui, ça accélère beaucoup les choses. Ce changement a méchamment cassé du code très utilisé en production (jsonkit notamment), ils l’ont pas prit à la légère.
Weak reste très courant, et est problématique, vu qu’il faut implémenter le reverse lookup, à la fois au retain et au release.
Je voulais préciser que les performances de retain/release chez apple (et d’une bonne partie du runtime objc) sont pleines de fast/slow paths.
[^] # Re: NSObject sur M1
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 4.
Pour en rajouter une couche, le retain/release chez Apple, c’est tout un art.
Les chiffres qu’il donne sont pour le « happy path » il me semble, à savoir un retain count suffisamment bas, sans weak references.
Dans ce scénario, le retain count est stocke directement dans le pointer, un retain release devient donc une opération très simple de compare and swap.
Bien sur, cette optimisation n’est efficace que dans le cas de base, à savoir un retain count qui rentre dans les qq bits alloués dans le pointeur, sans weak references.
Note qu’ils font le même genre de tours de magies avec NSNumber, ou la valeur est stockée directement dans les pointeurs.
C’est bon de garder ça à l’esprit quand la team runtime chez Apple se vante de leurs performances. Ça reste très impressionnant quand même, et ça marche très bien la plupart du temps, mais il faut se rappeler que tu peux facilement rentrer dans le slow path, qui va clairement pas tourner en 15 nanosecondes.
[^] # Re: Pertinence ?
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 2.
ok, mais d’un point de vue évolution, ça change pas grand chose. C’était a ca que je répondais.
😳 la vache, tu fais quoi avec ta machine pour remplir 16Gb?
[^] # Re: NSObject sur M1
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 6.
C’est pas grâce aux caches, mais grace à un modèle mémoire différent qui leur permet de faire des opérations atomiques beaucoup plus rapidement. Le prix à payer est que des bugs multithreadés cause par un mauvais code vont se manifester, la ou la version x86 l’aurait empêché.
https://twitter.com/catfish_man/status/1326269594818891776?s=21
[^] # Re: Pertinence ?
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 4.
C’est sur, mais d’un autre côté, c’est pas nouveau, ça fait des années que la ram est soudée, en tout cas pour leurs laptops. Le stockage se rajoute facilement avec de l’usb c.
Pour les desktops, c’est un peu plus discutable, c’est sur. Encore que les quantités de ram offertes ont pas évolué tant que ça ces dernières années, et sortie des cas pro très spécifique, je pense que le compromis n’en est pas vraiment un.
Pour être tout à fait franc, mon laptop à bientôt 5 ans, je pourrais pas te dire si j’ai 8 ou 16gb de ram, et j’ai jamais eu de problèmes de ram, malgré xcode, moultes simulateurs, moultes instances d’intellij et beaucoup d’applis diverses et variées qui tournent en parallèle.
Par contre, le throttling du cpu me pique tres souvent, plusieurs fois par jour. Et voyageant pas mal (bon, pas ces jours ci, forcément), la batterie est très importante.
Donc la pour le coup, le x86 va pas me manquer. Sans parler des problèmes de fat frameworks x86 vs arm pour le development cross platform iOS/macOS (Mais ca c’est un problème super spécifique).
[^] # Re: Pertinence ?
Posté par groumly . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 4.
La compilation est fortement cpu bound, pas mal I/O bound aussi (dans un contexte très particulier, à savoir énormément de toutes petites i/o).
Et ça se parallélise très bien, surtout sur de très gros projets comme ff.
Donc oui, c’est un bon test de la puissance pure du cpu et du coup des i/o.
après, c’est un peu dommage de tester x86 vs x86, plutôt que le sujet du moment, x86 vs m1.
Les tests que j’ai vu la dessus que ce soit en ligne ou sur notre projet pro, indiquent que le m1 met la tannée au machines x86.
[^] # Re: Eh oui...
Posté par groumly . En réponse au journal DHCP et heure système. Évalué à 2.
Pour que la durée marche, il faut être d’accord sur la date à laquelle la durée commence, non?
Dit autrement « t’as cette ip pour 24 heures » ne veut pas dire grand chose si tu ne sais pas quand les 24 heures commencent.
[^] # Re: Snap a bannir
Posté par groumly . En réponse au journal Ubuntu, Snap, les performances de chromium se dégradent. Évalué à 10.
Peut on utiliser 1000 fois 1000 logiciels? Tu veux un chewing gum?
[^] # Re: .
Posté par groumly . En réponse au journal Warp : les performances de Firefox s’améliorent. Évalué à 3.
J’ai remarqué quelque chose de similaire sur iOS récemment. Ça me fait penser que le problème pourrait être dans un framework populaire, genre react ou que sais je.
[^] # Re: le commentaire que Martoni me force à écrire
Posté par groumly . En réponse au journal Un RISC-V sous Linux pour $12.50. Évalué à 1.
Ah, donc la définition des mots, c’est une opinion personnelle maintenant?
[^] # Re: le commentaire que Martoni me force à écrire
Posté par groumly . En réponse au journal Un RISC-V sous Linux pour $12.50. Évalué à 3.
Mmmh. Pas sur.
[^] # Re: quel forceur ce Martoni
Posté par groumly . En réponse au journal Le retour du RiscPC ?. Évalué à 7.
Ah bon?
On peut pas lancer une compilation d’un même projet avec la même version de clang/swiftc et voir combien de temps ça prend?
On peut pas lancer l’encodage de la même vidéo avec les mêmes encodeurs, et voir comment de temps ça prend?
On peut pas lancer le même programme en mode émulation, et voire combien de temps ça prend?
Ou un rendu 3D, ou des animations dans Uikit et mesurer les fps, ou quoi que ce soit qui utilise le cpu et mesurer si ça va aussi vite, moins vite ou plus vite?
Tu nous dit que c’est littéralement impossible de mesurer les performances d’un mac commun face à un pc spécifique, et déterminer lequel va le plus vite, lequel consomme le moins, quel autre compromis performance on peut trouver?
L’os est le même, le runtime est le même. Les optimisations sont différentes, mais dans un cas, ils connaissent la plateforme depuis 15ans, dans l’autre ils l’ont créée y’a 10 ans, je suis convaincu que s’il y a une optimisation hard à trouver, ils l’ont trouvée d’un côté ou de l’autre.
C’est sur, l’implémentation concrète est techniquement différente, mais j’ai vraiment du mal à voir comment tu contrôle pour ca, vu qu’on tente de comparer à travers des archi différentes, évidemment que l’implémentation est différente.
Parce que les performances du cpu, c’est pas decide par apple non plus?
Donc, en fait, autant ne pas savoir, vu qu’Apple avait un but en tête avant de se lancer dans un projet aussi trivial que designer ses propres cpu. J’ai du mal à comprendre la logique je t’avoue.
Une vraie culture de scientifique assoiffé de connaissances, ma foi. Hacker du mois!
[^] # Re: quel forceur ce Martoni
Posté par groumly . En réponse au journal Le retour du RiscPC ?. Évalué à 8.
la vache, pour quelqu’un qui a posté pas moins de 4 messages pour se plaindre du manque de rigueur sur les benchs, tu manques vachement de rigueur avec ton vocabulaire.
“un desktop est un ordi avec un cpu de gamme desktop, optimisé pour la performance”. Ok, donc déjà la définition fait référence à la définition, et en plus ça contredit la définition déjà acceptée qui est “ordinateur conçu pour être utilisé sur un bureau, fixe”.
Un raspberry pi est un ordinateur de bureau, ne t’en déplaise.
https://fr.wikipedia.org/wiki/Ordinateur_de_bureau?wprov=sfti1
[^] # Re: quel forceur ce Martoni
Posté par groumly . En réponse au journal Le retour du RiscPC ?. Évalué à 6.
D’un autre côté, savoir si le cpu serait 10% plus rapide avec un software different, ou dans un boîtier différent, on s’est cogne un peu, vu que ce serait pas en vente sur le marché de toutes façons.
La question c’est grosse modo: comment est ce que ce cpu arm se place face aux machines actuelles? Que ça soit du au hard ou au soft importe peu au final (surtout que bon, c’est largement le même soft, hein, macOS reste macOS, on va pas enculer les mouches).
Est ce que c’est suffisamment proche pour qu’on y perde pas grand chose au final? Quelle marge de manœuvre a Apple pour rattraper le retard? Qu’est ce qu’on gagne d’autre (batteries/bruit des putains de ventilos)?
[^] # Re: Appliquer les règles de politesse habituelles?
Posté par groumly . En réponse au journal Comment et quoi répondre aux invitations Zoom et Microsoft Team → vs Jitsi Meet. Évalué à 3.
ils le mettent clairement pas avant, mais il est dispo et marche bien. Testé moi meme sur safari.
[^] # Re: Il est temps de mettre ces gens face à leurs responsabilités
Posté par groumly . En réponse au journal H.S. En France petite leçon de démocratie (de séparation des pouvoir, surtout). Évalué à 3.
C’est une question pertinente, mais j’ai pas de réponse. Je l’ai lu plusieurs dans des sources reputables, genre le nyt, mais j’ai pas de chiffres à te donner, non.
L’argument se tient toujours cela dit, vu la flambée de cas que la France se tape en ce moment, et la saison, je trouve ça dur de justifier de garder les bars ouverts, et ça serait criminel de pas faire quelque chose pour réduire la propagation.
[^] # Re: Il est temps de mettre ces gens face à leurs responsabilités
Posté par groumly . En réponse au journal H.S. En France petite leçon de démocratie (de séparation des pouvoir, surtout). Évalué à 6.
Pour en rajouter une couche: l’augmentation des cas en France fait super peur. Je chiais dans mon benne en août (californie) parce qu’on tapait dans les 10k cas par jour, la vous vous tapez plus du double.
C’est grosso modo au niveau des us, ou la stratégie est « ça se trouves, si tu fermes les yeux, Covid disparaît, on peut pas savoir ».
[^] # Re: Il est temps de mettre ces gens face à leurs responsabilités
Posté par groumly . En réponse au journal H.S. En France petite leçon de démocratie (de séparation des pouvoir, surtout). Évalué à 10.
Ouais, mais d’un autre côté, on sait maintenant que Covid peut avoir des conséquences à long terme sur la santé, même si tu en guéri, et on a une meilleur idée de comment ça se transmet, typiquement les restos et les bars en intérieurs sont une calamité, particulièrement les bars pleins de gens bourrés qui se gueulent dans les oreilles.
Ça me parait pas délirant de vouloir limiter le nombre de contaminations en priorité.
Clairement, il faut de la capacité dans les hôpitaux aussi, mais éviter que les gens le choppent et le transmette me parait tout aussi important, a plus forte raison avec l’hiver qui arrive et donc beaucoup plus de monde qui reste en intérieur.
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à -6.
Non, ma réponse c’est que tu racontes n’importe quoi. Personne ne te force à publier des applis pour une plateforme propriétaire. T’as du dépenser au moins 500 à 1000 euros pour developer sous android aussi. C’est la même chose chez Apple. Scoop: le matos Apple peut servir à autre chose que developer, et la plupart des devs iOS auraient acheté un mac de toutes façons, donc, non, c’est vraiment pas un problème. Y’a que des chouinasseurs dans ton genre pour s’offusquer de ça.
Leur matos ne te convient pas, l’achète pas, et passe ton chemin, mais je vois vraiment pas l’intérêt d’écrire la connerie que t’as écrite au dessus.