"Après tu peux aussi avoir une application Windows qui ne répondra pas de la bonne façon à un copier-coller"
Oui, c'est hyper courant en ce moment. Ca marchait mieux avant. Très très honnêtement. Après, je ne sais pas si c'est Windows tout seul ou u composant de sécurité qui se met en travers des copier/coller.
Ni l'un, ni l'autre. C'est l'application qui n'en a rien à foutre... :)
Tout à fait d'accord pour nt3.51 (que je n'ai pas pratiqué et jamais vu). Je pense qu'on peut lancer un débat sur quand on est sur un conteneur, quand on est sur une VM et qu'est-ce qu'un hyperviseur :) Bon, pour résumer, je rebondis sais sur le thème de wagaf de l'isolation. Windows depuis NT4 et 2000 a toujours eu de l'isolation. Que Ms ait maintenu des passerelles (ou des viaducs) pour la compatibilité tiend à la volonté de maintenir vivant leur environnement plutôt riche (windows avec ole/com/dcom était impressionnant). C'est vrai que je n'aime pas trop le windows bashing alors que ce qu'a windows n'existe pas dans Android ou linux (encore aujourd'hui, je peux copier un contenu sous linux mais il n'est pas collables dans des applis qui ne sont pasbasées sur les mêmes techno - exemple : copier un fichier de dolphin et coller dans l'explorateur de cinnamon).
C'est vrai que je n'aime pas trop le windows bashing alors que ce qu'a windows n'existe pas dans Android ou linux (encore aujourd'hui, je peux copier un contenu sous linux mais il n'est pas collables dans des applis qui ne sont pasbasées sur les mêmes techno - exemple : copier un fichier de dolphin et coller dans l'explorateur de cinnamon).
Et dire que ça marchait plutôt bien à une époque, mais ça s'est perdu avec l'échec de fd.o. Après tu peux aussi avoir une application Windows qui ne répondra pas de la bonne façon à un copier-coller, c'est "juste" qu'il y a moins de chances qu'un développeur se plante et oublie de tester les cas principaux vu qu'ils sont vachement moins nombreux en l'absence d'une foultitude d'environnements et de variabilité.
Les sous-systèmes Windows, c'est un peu comme une VM, mais avec Windows comme hyperviseur. Pour Wow64, effectivement, on est plus sur de la conteneurisation. C'est un deuxième Windows 32 bits dans le Windows 64bits. Mais dans le fond, on est sur les mêmes principes. Pour rappel, il y a eu des sous-systèmes POSIX et même Linux déjà sous NT4/2000 (et opensource à l'époque) mais qui n'ont jamais décolé (on a préféré le "linux.exe": un lanceur qui contenait un kernel Linux capable d'exécuter des applis a.out en mode texte).
Dans ce cas faut pas se tromper dans l'histoire, le sous-système OS/2 existait déjà dans NT3.1 donc parler de NT4 était faux. Et appeler ça une VM est complètement faux. Au mieux un conteneur, qu'il s'agisse de Wow64 (apparu après NT4/2000) ou des sous-systèmes POSIX et OS/2. Le kernel restait le même. Sinon autant dire que toute application tourne dans une VM vu qu'il y a une isolation entre les processus qui donne l'illusion à chaque appli qu'elle est seule...
La "chute" de l'OS est provoquée par la consommation massive de ressources par une application. Je suppose que même Windows ne plante pas totalement, il a juste un temps de réponse qui devient inacceptable pour l'utilisateur et s'apparente à un plantage. Sous Linux, a priori l'OOM killer va entrer en jeu, mais il provoque en général un gel de l'interface graphique pendant plusieurs secondes. Est-ce un plantage si l'OS est en "pause" ? Excellent sujet de philo pour le prochain bac.
Euh, windows lance déjà les applis dans des VM depuis NT4.
Plait-il ? Les applis DOS peut être avec la NTVDM, mais les applis Win32 n'étaient pas isolées les unes des autres, et ne le sont pas encore vraiment (y'a pas mal de subtilités introduites beaucoup plus récemment que NT4)
Ben l'arduino canal historique, pour le coup, c'est plus simple que le RPi ... je dirais même que l'arduino est à un niveau de simplicité que les utilisateurs de RPi n'ont pas l'habitude de voir...
Maintenant, des "arduino" avec 2Go de ram, ça a un petit côté tricycle à pédale avec crochet pour caravane.
Forcément un uC c'est plus simple qu'une Pi. Mais là on a un linux complet, avec wifi, bluetooth, un GPU… C'est, comme indiqué, un concurrent à la fois de la Pi et de la Pi pico, qui elle concurrence l'Arduino
Comprendront-ils que ce qui a fait la force du Raspberry Pi n'est pas seulement le matériel ou le prix mais surtout la simplicité du logiciel dessus et le support qui va avec ? À suivre...
Son nom devrait rappeler des souvenirs aux moins jeunes d’entre nous, puisque c’était aussi le nom d’une carte de chez ATI (rachetée par AMD) : la Radeon 9700… de 2002.
Exactement ce que je dis : "des bibliothèques sont disponibles pour gérer ça correctement". Mais de base en Python 1.1 c'est un nombre flottant sans decorum. Oui avec decimal on peut le gérer, mais c'est un effort et c'est donc contre-intuitif. J'aurais pu faire ce même exemple avec Java, C, C++, C#, Perl, PHP. Au passage en Python decimal utilise en interne https://www.bytereef.org/mpdecimal/, une implémentation certes rapide, mais je serais curieux de voir sur un mainframe un benchmark entre un programme utilisant mpdecimal et un programme COBOL faisant les mêmes opérations.
Sans avoir été beaucoup plus loin qu'un hello world en COBOL, une fonctionnalité majeure de ce langage qui va se perdre par rapport à l'immense majorité des langages modernes : les nombres à virgule fixe, par opposition aux flottants. En cobol, 1,1 + 2,2 = 3,3. Alors que si je prends Python par exemple : In [1]: 1.1 + 2.2 == 3.3 Out[1]: False
Et ça, ça peut faire très mal. Bien sûr des bibliothèques sont disponibles pour gérer ça correctement, mais c'est tout de même plus difficile que si c'est intégré au langage, sans ce type de filet de sécurité, avec une migration suivant la méthode La Rache, on peut préparer le pop corn...
Oubli majeur : "Suite logique, AMD passe ensuite à l’architecture K8 avec les Athlon 64 (FX), Sempron 64, Turion et autres Opteron. " Tout de même.... AMD a surtout introduit le 64 bits sur les processeurs x86 ! Ils ont imposé à Intel de faire des processeurs 64 bits pour le grand public, alors que leur projet était de faire de l'Itanium le processeur 64 bits réservé aux professionnels, le grand public pouvant se contenter de 32 bits. Sans l'AMD64, difficile d'imaginer ce que serait le marché du processeur grand public aujourd'hui. Aurions-nous des processeurs Itanium bridés ? Du POWER ? De l'ARM ?
je doute très fortement d’un gain notable en ajoutant une boite de vitesse, le rendement d’un moteur électrique est très bon sur une plage monumentale, c’est probablement pas ça le plus gros point noir cependant, il me semble que sur des tesla avec 2 moteurs, ils n’avaient pas le même rapport, et l’un était un peu plus efficace à haute vitesse, et l’autre à basse vitesse, mais sans chiffre exact difficile de savoir si ça fait gagne 10 kWh/100km ou si c’est juste 0.1
cf précédent
selon moi, c’est surtout que le “talon” incompressible d’une thermique est tellement conséquent, que la variation due à la vitesse semble faible. j’explique ma théorie pifométrique avec des chiffres absurdes mais pour imager : en électrique, 0km/h = 0kwh/100km, 50km/h=10kWh/100, 110km/h=15kWh/100, 130km/h=25kwh/100 en thermique, 0km/h=!$@ erreur on a une conso mais pas de déplacement (premier point compliqué) 50km/h=5l/100, 110km/h=5.5l/100, 130km/h=6.5l/100 en thermique, sauf astuces, il est très compliqué de descendre sous les 4l/100 si on suppose que les 4l/100 c’est le “talon”, l’augmentation de la consommation en fonction de la vitesse ressemble fortement à ce qu’on a en électrique talon déduit en thermique : 50km/h=1l/100, 110km/h=1.5l/100, 130km/h=2.5l/100
tout ceci n’est que pure spéculation de ma part (avec chiffres très approximatifs), mais à défaut de mieux, ça me semble au moins un poil “logique” et pas forcément très éloigné de la réalité
Il faut aussi prendre en compte la “cloche” de l’efficacité du moteur thermique. À 50 km/h, quelle que soit la boite de vitesse, les pertes sont supérieures à celles à 70 km/h. À 130 km/h, idem. De mémoire une voiture, qu’elle soit thermique ou électrique, aura un optimal autour de 70 km/h.
Mais l’idée de parler de “talon” de consommation est pas mal. Concrêtement il s’agit de toute l’essence nécessaire pour chauffer les cylindres, passer outre les nombreux frottements, créer des gaz d’échappement chauds, alimenter l’alternateur… Cette consommation ne sert strictement à rien pour avancer, mais elle est là.
Je ne résiste pas… En quoi ntfs-3g ne serait pas natif au final, puisque le code est intégralement écrit pour systèmes UNIX, avec fuse qui est de base dans le noyau Linux ? Par contre, le projet captive NTFS (dont les plus vieux se souviennent, ou pas… 2006, je ne pensais pas que c’était si vieux) n’était pas natif lui, vu qu’il chargeait le pilote windows ntfs.sys sous Linux avec l’aide de morceaux de Wine et de ReactOS… https://www.jankratochvil.net/project/captive/
NT signifiait « New Technology » et représentait les efforts développés par Microsoft pour proposer une base logicielle plus fiable et taillée pour le monde professionnel.
Tout de même : des efforts largement inspirés de VMS, et d’une partie du travail sur OS/2. Dans le cas de NTFS, l’inspiration de Files-11 de VMS est flagrante, avec des ajouts issus du HPFS d’OS/2.
Je crois bien qu’en NTFS, il est possible d’avoir des noms bien plus longs, à condition que les applications utilisent les bonnes API Win32.
En fait depuis Windows 10 1607 il faut changer une clé de registre pour avoir droit à plus de 260 caractères pour le chemin complet d’un fichier. Ce qui est une limite tout de même assez faible si on tient compte de la longueur de certains dossiers pré-définis, une arborescence profonde est vite arrivée…
«La première affichera la version du noyau (6.1.0) et l’autre la version du système (12.0).»
Depuis quelques années, uname -r donne une info différente. uname -v donne la version du noyau, uname -r donne la «release» . Certaines distributions (arch par exemple) ne font pas de différence, mais dans le monde debian les deux sont décorrélés. La release ne changera qu’en cas de mise à jour incompatible du noyau (ce qui est évité autant que possible). Debian bookworm est sortie avec un noyau 6.1.27, pas 6.1.0.
«Avec le cloud public, à l’inverse, les ressources sont mutualisées : le client ne loue que les serveurs dont il a besoin à l’instant « t », et bénéficie ainsi de l’élasticité du cloud.»
Dès le début de la tribune, je m’attendais à ce que ça prenne cette direction, je ne suis pas déçu. Combien d’entreprises ont des pics de charge typiques d’un black friday qui nécessiteront vraiment une solution élastique ? Combien sauront exploiter une telle solution ? Pour être élastique, combien de serveurs chez les cloudeux sont en attente de nouvelles VMs ? Et surtout, surtout… ne parlons pas d’imposer aux gens d’optimiser leur code et leurs choix de technos, chut !
@Trit’ : pas de périphérique non reconnu… c’est un peu flou sur les machines ARM qui n’ont pas de standard de découverte des périphériques, mais si on considère le GPU et le disque comme des périphériques, on est bien à deux périphériques non reconnus.
Sans le disque nvme du Mac non plus si j’ai bien compris… Mais personne n’a donné de définition pour «complètement utilisable», donc… plus c’est gros, mieux ça passe.
Quid des aspects plus techniques ? IPv4 fixe, taille du préfixe IPv6 (si disponible), possibilité de changer le reverse d’une IPv4, d’une IPv6 ? La fibre pourrait changer la situation pour ceux qui souhaitent s’auto-héberger, mais ce n’est jamais clairement expliqué sur les plaquettes commerciales…
26 commentaires
Le 06/11/2025 à 15h13
Le 04/11/2025 à 11h15
Après tu peux aussi avoir une application Windows qui ne répondra pas de la bonne façon à un copier-coller, c'est "juste" qu'il y a moins de chances qu'un développeur se plante et oublie de tester les cas principaux vu qu'ils sont vachement moins nombreux en l'absence d'une foultitude d'environnements et de variabilité.
Le 02/11/2025 à 11h12
Sinon autant dire que toute application tourne dans une VM vu qu'il y a une isolation entre les processus qui donne l'illusion à chaque appli qu'elle est seule...
Le 30/10/2025 à 13h24
Je suppose que même Windows ne plante pas totalement, il a juste un temps de réponse qui devient inacceptable pour l'utilisateur et s'apparente à un plantage. Sous Linux, a priori l'OOM killer va entrer en jeu, mais il provoque en général un gel de l'interface graphique pendant plusieurs secondes. Est-ce un plantage si l'OS est en "pause" ? Excellent sujet de philo pour le prochain bac.
Le 30/10/2025 à 13h19
Le 30/10/2025 à 13h17
Le 29/10/2025 à 15h23
Le 07/10/2025 à 18h06
Mais là on a un linux complet, avec wifi, bluetooth, un GPU… C'est, comme indiqué, un concurrent à la fois de la Pi et de la Pi pico, qui elle concurrence l'Arduino
Le 07/10/2025 à 15h45
Le 21/05/2025 à 09h43
:)
Le 20/05/2025 à 15h52
Le 01/04/2025 à 11h57
Mais de base en Python 1.1 c'est un nombre flottant sans decorum. Oui avec decimal on peut le gérer, mais c'est un effort et c'est donc contre-intuitif.
J'aurais pu faire ce même exemple avec Java, C, C++, C#, Perl, PHP.
Au passage en Python decimal utilise en interne https://www.bytereef.org/mpdecimal/, une implémentation certes rapide, mais je serais curieux de voir sur un mainframe un benchmark entre un programme utilisant mpdecimal et un programme COBOL faisant les mêmes opérations.
Le 01/04/2025 à 11h22
En cobol, 1,1 + 2,2 = 3,3.
Alors que si je prends Python par exemple :
In [1]: 1.1 + 2.2 == 3.3
Out[1]: False
Et ça, ça peut faire très mal. Bien sûr des bibliothèques sont disponibles pour gérer ça correctement, mais c'est tout de même plus difficile que si c'est intégré au langage, sans ce type de filet de sécurité, avec une migration suivant la méthode La Rache, on peut préparer le pop corn...
Modifié le 03/05/2024 à 08h45
Tout de même.... AMD a surtout introduit le 64 bits sur les processeurs x86 ! Ils ont imposé à Intel de faire des processeurs 64 bits pour le grand public, alors que leur projet était de faire de l'Itanium le processeur 64 bits réservé aux professionnels, le grand public pouvant se contenter de 32 bits.
Sans l'AMD64, difficile d'imaginer ce que serait le marché du processeur grand public aujourd'hui. Aurions-nous des processeurs Itanium bridés ? Du POWER ? De l'ARM ?
Le 22/08/2023 à 10h08
Il faut aussi prendre en compte la “cloche” de l’efficacité du moteur thermique.
À 50 km/h, quelle que soit la boite de vitesse, les pertes sont supérieures à celles à 70 km/h.
À 130 km/h, idem.
De mémoire une voiture, qu’elle soit thermique ou électrique, aura un optimal autour de 70 km/h.
Mais l’idée de parler de “talon” de consommation est pas mal. Concrêtement il s’agit de toute l’essence nécessaire pour chauffer les cylindres, passer outre les nombreux frottements, créer des gaz d’échappement chauds, alimenter l’alternateur… Cette consommation ne sert strictement à rien pour avancer, mais elle est là.
Le 06/07/2023 à 17h28
Je ne résiste pas…
En quoi ntfs-3g ne serait pas natif au final, puisque le code est intégralement écrit pour systèmes UNIX, avec fuse qui est de base dans le noyau Linux ?
Par contre, le projet captive NTFS (dont les plus vieux se souviennent, ou pas… 2006, je ne pensais pas que c’était si vieux) n’était pas natif lui, vu qu’il chargeait le pilote windows ntfs.sys sous Linux avec l’aide de morceaux de Wine et de ReactOS… https://www.jankratochvil.net/project/captive/
Le 06/07/2023 à 10h47
Tout de même : des efforts largement inspirés de VMS, et d’une partie du travail sur OS/2. Dans le cas de NTFS, l’inspiration de Files-11 de VMS est flagrante, avec des ajouts issus du HPFS d’OS/2.
Le 06/07/2023 à 10h45
Ni le pilote NTFS3 dans le noyau linux depuis octobre 2021.
Le 06/07/2023 à 10h44
En fait depuis Windows 10 1607 il faut changer une clé de registre pour avoir droit à plus de 260 caractères pour le chemin complet d’un fichier. Ce qui est une limite tout de même assez faible si on tient compte de la longueur de certains dossiers pré-définis, une arborescence profonde est vite arrivée…
Le 15/06/2023 à 18h17
Ha, petite erreur…
Depuis quelques années, uname -r donne une info différente. uname -v donne la version du noyau, uname -r donne la «release» . Certaines distributions (arch par exemple) ne font pas de différence, mais dans le monde debian les deux sont décorrélés. La release ne changera qu’en cas de mise à jour incompatible du noyau (ce qui est évité autant que possible).
Debian bookworm est sortie avec un noyau 6.1.27, pas 6.1.0.
Le 07/11/2022 à 18h03
«Avec le cloud public, à l’inverse, les ressources sont mutualisées : le client ne loue que les serveurs dont il a besoin à l’instant « t », et bénéficie ainsi de l’élasticité du cloud.»
Dès le début de la tribune, je m’attendais à ce que ça prenne cette direction, je ne suis pas déçu.
Combien d’entreprises ont des pics de charge typiques d’un black friday qui nécessiteront vraiment une solution élastique ? Combien sauront exploiter une telle solution ?
Pour être élastique, combien de serveurs chez les cloudeux sont en attente de nouvelles VMs ?
Et surtout, surtout… ne parlons pas d’imposer aux gens d’optimiser leur code et leurs choix de technos, chut !
Le 15/09/2021 à 12h11
Comme dirait la grande Valoche : moi je dis chiche.
Le 06/09/2021 à 07h01
Un commentaire également, merci nextinpact
Le 21/01/2021 à 15h36
@Trit’ : pas de périphérique non reconnu… c’est un peu flou sur les machines ARM qui n’ont pas de standard de découverte des périphériques, mais si on considère le GPU et le disque comme des périphériques, on est bien à deux périphériques non reconnus.
Le 21/01/2021 à 13h32
Sans le disque nvme du Mac non plus si j’ai bien compris… Mais personne n’a donné de définition pour «complètement utilisable», donc… plus c’est gros, mieux ça passe.
Le 26/02/2020 à 08h21
Quid des aspects plus techniques ? IPv4 fixe, taille du préfixe IPv6 (si disponible), possibilité de changer le reverse d’une IPv4, d’une IPv6 ? La fibre pourrait changer la situation pour ceux qui souhaitent s’auto-héberger, mais ce n’est jamais clairement expliqué sur les plaquettes commerciales…