jyes a écrit 907 commentaires

Vu ce que tu décris, j’ai l‘impression qu’un ls dans /gnu/store/ répondra encore mieux à ton besoin que dir dans C:\Program Files. Et ça règle le problème de la duplication des bibliothèques. Personnellement, j‘aime bien trouver toute la documentation dans /usr/share/doc et toutes les configurations dans /etc/ mais quitte à changer ces habitudes pour pouvoir lister les logiciels comme des dossiers, la solution de Guix et Nix est autrement plus élégante que le fourre-tout des Program Files. Et tu n’as pas besoin de changer d‘OS pour en profiter.

pas de perte de charge

Je ne m’amuserais pas à faire cette hypothèse avec une véritable bonde et sa petite grille pour éviter que le savon s’y glisse. Tu remarqueras que ta solution est la même que la mienne avec k = 2, un cas particulier donc. Cette simplification a quand même l’avantage considérable de donner une valeur facile à déterminer au coefficient et je t’accorde donc tout à fait que c’est une première approximation pertinente.

Ça fait partie des choses à montrer

C’est fait, à cette hauteur v = 0. Inutile de résoudre des équations différentielles quand la solution se trouve sans. Je n’enseigne pas en prépa, mais suis souvent assez surpris par la propension des élèves à se casser les dents sur des problèmes de maths en essayent d’utiliser tout leur cours, plutôt que de se concentrer sur les solutions simples.

Ce qui conditionne le temps de remplissage de la baignoire, c’est le débit au robinet, qui peut être considéré constant pour une ouverture de robinet donnée (la pression dans le réseau d’eau ne varie pas). À l’inverse, plus il y a d’eau dans la baignoire, plus la pression est élevée au niveau de la bonde (tu sens la pression dans tes oreilles si tu plonges la tête au fond de la baignoire).

Ensuite un modèle simple mais assez juste dans le cas de la vidange d’une baignoire, c’est que le débit de vidange est proportionnel à la racine carrée de la pression au fond de la baignoire, donc moins il y a d’eau, plus le débit est faible. La baignoire se vide donc à une vitesse beaucoup plus élevée quand elle est pleine que quand elle est presque vide.

Des équations !

Soit S la surface de la baignoire vue du dessus, la vitesse de remplissage est alors constante, proportionnelle au débit du robinet Q :

Mais la vitesse de vidange, elle varie avec la hauteur d’eau h :

avec g l‘accélération de la pesanteur (9,81 m/s) et k un coefficient sans unité et à peu près constant dans un problème comme celui-ci mais sa valeur dépend beaucoup de la géométrie et du diamètre de la bonde.

La variation de la hauteur d’eau dans la baignoire est donc régie par l’équation différentielle suivante si le robinet et la bonde sont tous deux ouverts :

\displaystyle{v = \frac{\mathrm{d} h}{\mathrm{d} t} = \frac{Q_{rob}}{S} - \sqrt{\frac{k g h}}}

Si l’on regarde la solution de

on trouve

qui est donc la hauteur pour laquelle s’équilibrent les vitesses de remplissage et de vidange. La baignoire ne se videra donc jamais complètement, mais ne débordera pas non plus si cette hauteur est inférieure à celle du bord de la baignoire par rapport à son fond.

Au delà de considérations écologiques qui rendent l’exercice problématique, ma réponse ne permet pas d’aller plus loin. En effet, le modèle de vidange que j’ai présenté tend vers une vitesse nulle quand la baignoire est presque vide, donc selon ce modèle elle ne se vide jamais. En effet, pour une baignoire presque vide mon modèle à k constant est inadapté, il n’est donc pas possible de l’utiliser pour comparer sa solution temporelle aux douze minutes données en énoncé. On pourrait déduire k de ces douze minutes si l’on considère que la baignoire est vide lorsqu’il reste moins d’un demi centimètre d’eau par exemple. Mais comme ici on parlait de mathématiques, on ne va pas commencer à adopter un raisonnement de physicien qui s’attaque à un problème réel.

Je serais curieux de voir ce que cela donne dans la vie réelle.

Ça dépend de ce que tu vis dans ta vie réelle. Pour le calcul scientifique cette approche vectorielle est susceptible d’améliorer énormément les performances par rapport à tous les traitements spécifiques des fins de boucles nécessaires avec les registres de taille fixe (et toutes les heuristiques pour tenter de deviner quand le temps perdu dans ces traitements risque de contrebalancer le gain potentiel du traitement vectoriel, qui change évidemment chaque fois qu’on vise une machine un tout petit peu différente). De plus, ça veut dire que presque tous les traitements peuvent profiter des opérations vectorielles, pas seulement ceux sur un type de données, le code ainsi vectorisé s‘approche alors beaucoup d’un code réellement parallèle. Pour tout le (assez peu de) code que j’écris, je n’aurais rien à faire de matrices 2×2 (éventuellement je me servirais de 3×3 mais pas assez pour gagner quoi que ce soit si des opérations de base existaient pour elles), par contre la vectorisation change tout.

Ici on a un modèle très simple qui a un comportement contre-intuitif et on transfère sans preuve ce comportement à l'économie réelle.

C’est bizarrement formulé, une analyse phénoménologique de l’économie réelle montre bien une concentration des richesses, et ce que fait l’article c’est proposer un modèle simple et suffisant pour expliquer le phénomène. L’aspect contre-intuitif, c’est juste que même en déséquilibrant les échanges à la faveur des plus pauvres, les richesses continuent à se concentrer chez ceux qui ont commencé plus riches. Encore une fois, une analyse empirique de l’économie réelle ne contredit pas ce point non plus.

Le taux d’incidence est calculé par rapport à la population totale, pas par rapport aux nombres de cas testés, donc non, moins de tests induit mécaniquement une baisse (ou un maintien si tous les gens en moins qui se font tester auraient effectivement été négatifs, mais faut avoir du bol).

Les tests PCR payants qui semble tellement contre productif.

Au contraire ! C’est une méthode extrêmement efficace pour faire baisser la mesure du taux d’incidence, et c’est bien de faire baisser cette mesure. Tant pis si le taux d’incidence lui même ne descend pas, les graphiques que les média montreront aux gens seront beaucoup moins effrayants ! C’est une technique déjà bien éprouvée pour faire baisser le taux de chômage, il n’y a pas de raison que ça ne marche pas face à une pandémie.

Attention, il a utilisé l'option -m qui compresse un peu plus.

Ça explique encore moins que l’image que j’ai obtenue soit encore plus petite que la sienne ! Chez moi encore, l’option “-m” sauve encore un octet de plus !

$ zopflipng avatar.png avatar.zop.png 
Optimizing avatar.png
Input size: 7907 (7K)
Result size: 7550 (7K). Percentage of original: 95.485%
Result is smaller

$ zopflipng -m avatar.png avatar.zopm.png 
Optimizing avatar.png
Input size: 7907 (7K)
Result size: 7549 (7K). Percentage of original: 95.472%
Result is smaller

C’est peut-être dû à des versions différentes de zopfli, non ? Par exemple, sur ma Debian Buster, avec le même fichier

$ zopflipng avatar.png avatar.zop.png
Optimizing avatar.png
Input size: 7907 (7K)
Result size: 7550 (7K). Percentage of original: 95.485%
Result is smaller

Ces onzes octets de différence avec ton résultat ne sont pas grand chose et doivent pouvoir d’une version à l’autre de cet outil de compression.

Le même ministère de la recherche qui publie ce plan fait basculer l’un après l‘autre tous les labos de recherche en ZRR ¹, et pousse ses universités à mutliplier les SATT ². En même temps, on n’est plus à une injonction contradictoire près dans la recherche publique. En pratique, tous les chercheurs que je connais qui diffusent des codes libres le font à l’insu des services en charge la propriété intellectuelle de leur employeur voire en contradiction directe avec le règlement de leur université (qu’ils n’ont pas pris le temps de lire, à raison s‘ils veulent produire quelque-chose).

Je ne comprends pas ton commentaire parce-que je suis d’accord avec tout sauf la conclusion. Si le code (libre) constitue les données qui alimentent ce moteur de recherche, alors les résultats qu’il retourne sont couverts par la même licence. Donc le code ne peut pas être réapproprié par l’utilisateur de ce service, contrairement à ce qu’annonce GitHub. C’est même plus compliqué car avec leur IA au milieu qui fait une sorte d’interpolation entre différentes codes existants, avec des licences variées, le résultat est même probablement couvert par plusieurs licences incompatibles et ne peut donc même pas être utilisé du tout.

Le fait que le code n’est qu’une donnée est justement ce qui risque de faire du résultat un travail dérivé. Si tu prends deux images que tu superposes (en mélangeant chaque pixel avec 50% de l’une et 50% de l’autre) tu obtiens une œuvre dérivée de ces deux images. Si tu prends beaucoup d‘images et que tu remplaces le mélange à 50-50 par une fonction beaucoup plus élaborée jusqu’à ce qu’il ne soit plus si facile de deviner les images d’origines, tu as toujours une œuvre dérivée, même si tu te caches en appelant ta fonction de mélange une intelligence artificielle.

Donc je comprends bien les critiques émises sur cette page, le code que retourne copilot ne me paraît pas si simple à se réapproprier (surtout au vu des résultats évidemment repompés qu’il retourne aujourd’hui, mais même une fois ces problèmes réglés, en IA, les données d’alimentation font parties de l’algorithme et des résultats).

Donc

Rien n'empêche aujourd'hui qqun d'indexer tout le contenu publique de github ou d'autres forges avec une moteur NLP

Oui, mais

et de proposer le même service.

pas si sûr. Je pense surtout que comme c’est porté par une très grosse boîte et que c’est de l’IA à laquelle les juristes et politiques ne comprennent pas grand chose, la loi sera éventuellement adaptée pour protéger GitHub/Microsoft, mais la même chose, faite par quelqu‘un d’autre n’aurait pas les mêmes chances.

Je ne passerai au bépo que quand on aura un accès direct aux symboles (seulement les plus utiles) pour les jurons : 💀🎇🕷🕭❗🕱🔥🎆☁⛈🗰❕🗲☠🌩🗱‼

Attention, toutes les commandes présentées ici le sont depuis un hôte Debian, il peut y avoir des variations subtiles sur une autre distro.

Pour créer le conteneur :

lxc-create -n moncontenur -t debian -- -r buster

Chez moi, j’utilise une partition /var/lib/lxc formatée en BTRFS, par défaut la racine du conteneur /var/lib/lxc/monconteneur/rootfs est créée dans un sous-volume, ce qui facilite les instantanés en cas de grosse tuile.

Tu peux éditer le fichier /var/lib/lxc/monconteneur/config, le miens ressemble à ça pour mon conteneur YunoHost :

# Template used to create this container: /usr/share/lxc/templates/lxc-debian
# Parameters passed to the template: -r stretch # Oui, mais le conteneur a été mis à jour depuis.
# Template script checksum (SHA-1): 5a35ad98c578f5487dc5712a1c7d38af399be813
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

##lxc.net.0.type = empty
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = bridge0 # Attention, le pont doit être configuré sur l’hôte pour que cela fonctionne, sinon il faudra utiliser une autre méthode de partage du réseau. Il faut aussi régler le réseau dans le conteneur, via le fichier /etc/network/interfaces ou NetworkManager.
lxc.net.0.name = eth0
lxc.net.0.ipv4 = [Mettre ici l’adresse IPv4 souhaitée ou rien si le DHCP du réseau s’en occupe] # Pareil pour IPv6 d‘ailleurs, mais chez moi les réglages réseau dans le conteneur s’en occupent.
lxc.net.0.hwaddr = [Choisir ici une adresse MAC]
lxc.net.0.veth.pair = veth01

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1 # Important au cas où un paquet YunoHost décide de créer un conteneur dans le conteneur, je n’en ai pas d’exemple mais ça pourrait arriver. Une partie est peut-être redondante avec la ligne lxc.include = /usr/share/lxc/config/nesting.conf plus haut.
lxc.rootfs.path = dir:/var/lib/lxc/monconteneur/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.tty.max = 4
lxc.uts.name = monconteneur
lxc.arch = armhf # À adapter évidemment, mais normalement ces lignes sont de toutes façons générées automatiquement par la commande lxc-create.
lxc.pty.max = 1024

# Mount points
lxc.mount.entry = /mnt/userdata/mail var/mail none bind 0 0 # Là c’est au choix, mais j’enregistre les données des utilisateurs en dehors du conteneur.
lxc.mount.entry = /mnt/userdata/home home     none bind 0 0

# Auto-start
lxc.start.auto = 1
lxc.start.delay = 120

Ensuite, tu le démarres et t‘y connectes si tu veux :

lxc-start -n monconteneur
lxc-attach -n moncontenur

puis Ctrl-D pour sortir.

À partir de là, tu as un conteneur LXC avec une Debian à la vanille, reste à installer YunoHost :

echo deb http://forge.yunohost.org/debian/ buster stable > /var/lib/lxc/monconteneur/rootfs/etc/apt/sources.list.d/yunohost.list
lxc-attach -n moncontenur
apt update
apt upgrade
apt install curl
curl https://install.yunohost.org | bash # On peut aussi télécharger le script et regarder ce qu’il fait avant de le lancer aveuglément.

Et tadaaaaaa ! Une fois que tu as finis d‘installer YunoHost, tu peux même désactiver la connexion en SSH dessus puisque ton conteneur est accessible depuis l’hôte. Enfin, de toute façon à partir de là, on fait ce qu’on veut, on est chez soi, et puis y’a toujours les instantanés BTRFS qu’on peut faire à tout moment pour garder un filet de sécurité.

Note: toutes ces commandes ont été retranscrites de mémoire, il ne faut pas les recopier aveuglément mais elles devraient bien décrire la démarche générale.

Plus d’infos sur https://yunohost.org/fr/install/hardware:vps_debian.

Yunohost a son propre format de paquets pour l'installation des applications

Oui, mais ces paquets gèrent leurs dépendances en supposant qu’ils tournent sur une Debian. Par exemple Nextcloud créé un métapaquet Debian “nextcloud-ynh-deps” qui tire ses dépendances depuis les dépôts Debian. Bien que le format de paquet de Yunohost ne soit pas spécifique à Debian par construction, les paquets eux-mêmes le sont, c’est pourquoi j’écrivais que « refaire la même chose sur Arch en partant de YunoHost […] serait un nouveau projet à part entière ».

Et hors de question de virtualiser.

Pourquoi ? Même moi qui l’utilise sur Debian, je l’utilise dans un conteneur LXC avec une autre Debian. Qu’est-ce qui t’empêche d’adopter une telle solution ?

Je suis encore d’accord, ils perdent un avantage compétitif et du point de vue du bizness plan ça ma paraît une mauvais stratégie, mais visiblement NumWorks pense qu’il leur reste encore assez d’atouts. Ils ont peut-être raison, leur calculatrice a l’air très bien pour un prix de vente raisonnable. Maintenant, c’est sûr qu’elle perd tout intérêt à mes yeux dans sa nouvelle mouture privatrice, en même temps, je n’avais pas acheté une mouture précédente non plus, donc je ne suis de toute façon pas le marché visé. Pour mes calculs, je lance la CLI d’Octave directement sur mon ordi, puisque j’ai quasiment toujours mon ordi sous la main et allumé pour mon travail.

Je suis d’accord, mais en pratique pour la fabricant, il est important de répondre à ce (mauvais) besoin est important sous peine de se priver d’une part très importante du marché. L’article du forum tiplanet.org cité dans le journal est très complet et montre bien que c’est cet aspect du problème qui est à l’origine des regrettables changements de licence et tivoïsation.

les interfaces admin/user existent sous forme de paquets

Oui, la distribution YunoHost est une Debian tout ce qu’il y a de plus classique avec un dépôt en plus qui ne contient que les paquets de YunoHost (dont moulinette et ssowat).

je tiens fermement à mes serveurs sous Arch

Ça, ça va être plus difficile, YunoHost est vraiment lié à Debian. En caricaturant vraiment YunoHost c’est avant tout un gestionnaire d’installation et des recettes toutes prêtes et mutualisées pour installer et administrer des services usuels (mais non disponibles de base) sur une Debian. Il y aurait beaucoup de boulot pour refaire la même chose sur Arch en partant de YunoHost, et ce serait un nouveau projet à part entière.

Effectivement, quand bien même le processus de sélection d’un·e DPL n’introduirait pas de biais, on retrouverait ceux de la population des DD éligibles. Cependant, les études de sociologie qui s’intéressent à ce genre de choses montrent que sans volonté de lutter contre (ou avec une velléité trop légère) les biais sont renforcés à chaque étape sélective. Une belle illustration, qui ne touche pas Debian mais s’intéresse bien à une sélection qui se dit sur la compétence est une étude sur les concours de sélection aux grandes écoles d’ingénieurs, le tableau en page 6 de la version PDF est éloquent. En plus, ça fera plaisir au troll auquel je répondais de voir des sociologues s’intéresser à la diversité sur des critères plus variés que la couleur de peau, l’orientation sexuelle ou le genre (même si évidemment, ces critères doivent être étudiés et les discriminations associées combattues).

on [doit] choisir des gens en fonction de leurs compétences

Et ça ne te pose aucun problème de considérer que pour être compétent à un poste à responsabilité il faut être homme, blanc et hétéro ?

Sinon, la proportion d’hommes blancs hétéros à de tels postes devrait justement te faire constater que la sélection n’est pas que sur la compétence, les profils retenus étant bien trop homogènes sur des critères a priori décorrélés (et je ne fais que répondre ici à ton propos, qui ignore complètement l’importance de la représentativité et d’autres points indépendants de la compétence qui plaident en faveur d’une amélioration de la diversité).

Faut pas non plus croire tous ce qu’on lit sur les forums en ligne, entre mon orthographe erronée du nom de Bernoulli et mon équation inhomogène (il manque la masse volumique ρ dans v²/R = ρ⁻¹ ∂p/∂n dans mon explication) heureusement pour moi que ce n'est « pas le domaine de compétence de la plupart des personnes sur LinuxFr » ;-)

Chromium, c’est Chrome sans le code proprivateur de Google, mais pas nettoyé de toute Googlerie. Il utilise toujours les serveurs de Google pour détecter les portails captifs (ça fait quand même un traçage chaque fois que tu démarres le navigateur), il intègre des services Google (de synchro ou de protection contre le phishing par exemple) etc. Pour dégoogliser la version de Chromium dans Debian il y a eu un gros travail, et ungoogled-chromium tente d’aller encore plus loin. Pour te donner une idée des difficultés, il a eu assez récemment ce journal sur un sujet proche.

Bernouilli. Apparemment l'effet est bien réel

Non seulement l’effet est bien réel, mais c’est lui qui explique l’accélération du fluide à l’extrados du fait de la baisse de pression. le principe de Bernouilli, c’est une conservation de l’énergie de le long d’une ligne de courant, soit p + ½ρv² = constante sur chaque face de l’aile, donc si p diminue, v augmente. D’ailleurs comme indiqué dans ton lien « l’air passant au dessus de l’aile arrive avant celui passant en dessous » à cause de cet effet. Bernouilli joue donc un rôle fondamental, mais pour la démonstration il faut considérer qu’il induit une accélération du fluide du fait de la baisse de pression, et non l’inverse car l’accélération du fluide n’est absolument pas liée à la longueur de l’aile.

Ensuite, ton lien utilise un vocabulaire gênant en opposant effet Coandă à Bernouilli alors que dans cet exemple les deux sont à peu près interchangeable. Par exemple, dans mon précédent commentaire, je parlais de modèle d’écoulement potentiel, ce que certains par abus de langage appellent Bernouilli généralisé car justement dans un écoulement potentiel on peut généraliser la conservation de l’énergie à tout l’écoulement et pas seulement le long d‘une ligne de courant. Mais même sans faire cet abus de langage, selon la manière dont on démontre Bernouilli, à partie de Navier-Stokes en projection sur les directions principales de l’écoulement par exemple, on peut obtenir une deuxième équation de Bernouilli qui relie la courbure d’une ligne de courant au gradient de pression (v²/R = ∂p/∂n) qui est justement l’origine de la portance que je décrivais. Au final, dire que Bernouilli est un effet « trop faible pour faire voler un avion » est donc faux. Cet effet est prépondérant, par contre, il ne faut pas considérer que la vitesse se déduit directement du profil de l’aile pour utiliser Bernouilli, il faut bien résoudre un système couplé vitesse/pression.

Pour une fois que je peux écrire sur LinuxFr à propos d’un sujet où je connais quelque-chose, j’en profite.

L’explication est juste, sauf

L'écoulement de l'air sur le dessus et le dessous se fait à la même vitesse, mais le dessus étant plus long à parcourir que le dessous, l'aile est aspirée vers le haut.

qui est une erreur courante (bien que je ne comprends pas trop d’où elle sort) mais la longueur du trajet parcouru n’intervient nullement dans la portance. C’est la courbure des lignes de courant qui induit la portance. À l’extrados, le rayon de courbure implique une baisse de la pression (qui se calcule analytiquement avec un modèle d’écoulement potentiel par exemple et implique bien une vitesse d’écoulement plus importante), et à l’intrados une surpression (mais moindre, donc la portance résultante provient surtout de la dépression à l’extrados). Une autre manière de regarder le même problème est que la courbure de l’aile oriente l’écoulement de fluide vers le bas (par rapport à l’avion) et que pour lui faire gagner cette quantité de mouvement vers le bas, il faut lui imposer un force vers le bas dont la réaction (force du fluide sur l’aile) porte l’avion vers le haut.

Voilà c’était hors sujet mais je ne pouvais pas laisser cette erreur sans correction sur un site aussi exigent que MécafluxFr.

Commentaire supprimé car inutile, je n’avais pas vu celui de Bruno.