Apprendre le C - Page 3

./58 > ben quand je dis ssh je parle du protocole, pas spécialement du client hein ; évidemment que tu peux utiliser putty (il doit probablement reconnaître les séquences ansi non ? le contraire m'étonnerait). Mais bon putty n'est rien d'autre qu'un « terminal pour windows », donc... ah non, quand vous parliez de terminal windows vous vouliez spécifiquement dire terminal intégré à l'OS je suppose, donc putty c'est différent puisque c'est un logiciel tiers, certes.
Enfin tout ça ne change rien au fait que si tu veux exécuter des commandes à distance dans un terminal depuis n'importe quel OS vers n'importe quel autre OS, ben c'est pratique que les séquences d'échappement du terminal soient standardisées et indépendantes de l'OS, il me semble... par contre il est tout aussi évident que si tu veux faire un truc en ligne de commande non destiné à une utilisation via le réseau (ce qui semble être le cas ici) tu peux te permettre d'utiliser les spécificités de l'OS ; mais le terminal lui-même ne sert pas qu'à ça.

Sally
: ah non, quand vous parliez de terminal windows vous vouliez spécifiquement dire terminal intégré à l'OS je suppose, donc putty c'est différent puisque c'est un logiciel tiers, certes.

Enfin tout ça ne change rien au fait que si tu veux exécuter des commandes à distance dans un terminal depuis n'importe quel OS vers n'importe quel autre OS

à mon avis l'erreur est ici, je sais pas si ça semble naturel de penser directement au terminal pour un unixien, mais je trouverais plus normal d'utiliser sous Windows une application spécialement prévue pour ça, surement pas une solution "bricolage" à base de terminal :/

ben de toute façon les terminaux texte sont (je pense) de moins en moins utilisés (pas que sous windows) (genre mon frère a récupéré une imprimante réseau qui a une interface web pour la contacter ; il y a quelque temps — peut-être assez longtemps, déjà ^^ — on aurait plutôt fait une interface terminal ansi, je pense), mais après tout dépend de quand date ton serveur, tu peux vouloir communiquer avec un vieux truc aussi ^^. Et sinon il me semblait que la question était « pourquoi un terminal devrait-il respecter la norme ANSI », donc je suis d'accord qu'on peut ne pas vouloir du tout utiliser un terminal en mode texte, mais pour répondre à la question j'étais bien obligé de supposer qu'on utilisait le terminal . Parce que si tu ne t'en sers pas, c'est évident que le terminal n'a besoin de rien supporter du tout, il pourrait même ne rien afficher ^^
(maintenant peut-être que j'avais mal compris la question, ou mélangé plusieurs posts...)

Sally :
Et sinon il me semblait que la question était « pourquoi un terminal devrait-il respecter la norme ANSI », donc je suis d'accord qu'on peut ne pas vouloir du tout utiliser un terminal en mode texte, mais pour répondre à la question j'étais bien obligé de supposer qu'on utilisait le terminal . Parce que si tu ne t'en sers pas, c'est évident que le terminal n'a besoin de rien supporter du tout, il pourrait même ne rien afficher ^^

Pour le coup on est d'accord, mais comme les défenseurs du terminal ici semblaient dire qu'il fallait que celui de Windows respecte telle ou telle norme "pour pouvoir communiquer avec d'autres OS", j'imagine que supprimer carrément le terminal de Windows ne leur semblerait pas une bonne solution

Zephyr
: (btw on s'éloigne pas mal du sujet, la question n'est pas "un monopole est-il une bonne chose ?", je pense que la réponse est évidente, mais "Windows est-il supposé se plier aux normes imposées par Unix ?"; pour moi la phrase seule suffit à répondre clairement "non, il n'y a aucune raison".)

Ben si, ça pourrait être simplement de fournir une compatibilité avec ce système. C'est tout à son avantage.

Déjà répondu au post #59; sans cette compatibilité qui n'est rien d'autre qu'une solution de facilité pour des développeurs qui ont envie de "porter leur application mais pas trop", peut-être qu'une petite part d'entre eux fera l'effort de se plier aux contraintes du système qui va supporter leurs programmes. Je préfere avoir une nouvelle application bien conçue et bien integrée à mon système que 10 bouses recompilées à la va-vite et utilisant une technologie qui n'est pas du tout naturelle dans l'environnement que j'utilise (le terminal).

Au risque de me répéter je suis pratiquement sur que le terminal de windows (NT/2000/XP) sait interpreter les codes ANSIs

bref

ps: http://www.ss64.com/nt/cmd.html

voila c'est dit, donc cmd.exe SUPPORTE les commandes ansi

de base il ne les supporte pas (en tout cas pas chez moi), et dans tous les cas ça n'annule pas la question pour autant ^^

De toute manière la couleur dans un terminal texte caymal©

Zephyr
: Déjà répondu au post #59; sans cette compatibilité qui n'est rien d'autre qu'une solution de facilité pour des développeurs qui ont envie de "porter leur application mais pas trop"

Oui, et tu trouves ça critiquable ?
C'est quand même plus pratique si ça évite d'avoir à porter une foule de programmes...

Sasume
: Oui, et tu trouves ça critiquable ?

Bah oui, comme je l'ai déjà dit si qqun doit faire des efforts, c'est le développeur (en l'occurence, faire le nécessaire pour que son application soit adaptée au système sur lequel il veut qu'elle tourne); si c'est pour bacler n'importe quoi c'est pas la peine :/

edit : cf. le post de Pollux

./ 70 > Je trouve ça idiot.
C'est plus simple que les développeurs du système fassent leur possible pour faciliter le portage de logiciels.
De toute façon, le système est développé par des ... développeurs. Donc on pourrait très bien utiliser ton propre argument contre eux aussi ("si qqun doit faire des efforts, c'est le développeur (en l'occurence, faire le nécessaire pour que son système soit adapté aux applications qu'il veut faire tourner), si c'est pour bacler n'importe quoi c'est pas la peine :/").

Bref, l'intelligence est de demander à quelques développeurs d'adapter le système, plutôt que de demander à beaucoup de développeurs d'adapter leurs applications.

Sasume :
./ 70 > Je trouve ça idiot.
C'est plus simple que les développeurs du système fassent leur possible pour faciliter le portage de logiciels.
De toute façon, le système est développé par des ... développeurs. Donc on pourrait très bien utiliser ton propre argument contre eux aussi ("si qqun doit faire des efforts, c'est le développeur (en l'occurence, faire le nécessaire pour que son système soit adapté aux applications qu'il veut faire tourner), si c'est pour bacler n'importe quoi c'est pas la peine :/").
Bref, l'intelligence est de demander à quelques développeurs d'adapter le système, plutôt que de demander à beaucoup de développeurs d'adapter leurs applications.

Non (ou alors tu n'as tjrs pas lu/compris les posts 59 et 65) : le résultat n'est pas du tout le même... Dans un cas tu as cmd.com de Windows qui devient compatible avec les terminaux Unix, et tout un tas de programmes pas du tout conçus pour Windows qui débarquent dessus (mais qui sont en ligne de commande, c'est à dire anti-windows au possible), dans l'autre la seule solution pour les développeur est de rendre leur application réellement utilisable sous Windows avec une interface graphique. Non seulement le résultat n'a rien à voir, mais je préfere nettement la deuxième solution (enfin à ce niveau c'est même plus une simple question de préference, je n'en ai personellement rien à secouer d'avoir des tonnes d'applications en ligne de commandes sous Windows, je veux quelque chose qui soit adapté au système que j'utilise).

Sally> cmd.exe n'est pas un terminal, c'est juste un shell qui utilise le terminal intégré de windows comme n'importe quelle application en ligne de commande si elle est appelée à partir de l'explorateur...

Zephyr :
de base il ne les supporte pas (en tout cas pas chez moi), et dans tous les cas ça n'annule pas la question pour autant ^^

ah oui tiens, par contre ça marche pour les programmes compilés avec cygwin ^^

ah ok (ça semble plus logique effectivement que d'avoir carrément codé un terminal dans le shell )

./74> Je trouve ça vraiment dommage ce genre de mentalité.
Ça prend du temps à coder, les programmes. C'est quand même bien pratique pour le système de pouvoir accueillir toute une logithèque plutôt que d'imposer de tout réécrire.

Sasume :
./74> Je trouve ça vraiment dommage ce genre de mentalité.

Bah oui enfin tu sais je pense exactement la même chose dans l'autre sens... Oui effectivement les programmes c'est long à coder, et c'est certainement pas une raison pour les bacler.

Mais je ne parle pas de les bacler.
Je parle de travailler sur la compatibilité.
Je parle de répartir la charge de travail de façon la plus juste.
Et c'est facile de dire "bacler", mais développer prend du temps et a un coût. C'est du luxe d'exiger un système tel que tu le décris. Il faut aussi être capable de prendre sur soi et accepter de ne pas avoir la perfection.

Sasume :
Mais je ne parle pas de les bacler. Je parle de travailler sur la compatibilité.

Être compatible c'est plus que "tourner de façon bancale" pour moi, et ça me fait doucement sourire quand une application se vante d'être "compatible Windows" et qu'elle tourne en console...

Et c'est facile de dire "bacler", mais développer prend du temps et a un coût. C'est du luxe d'exiger un système tel que tu le décris. Il faut aussi être capable de prendre sur soi et accepter de ne pas avoir la perfection.

Bah là je ne suis pas d'accord, sous Windows les applications sont supposées avoir une interface graphique, la console n'est pas du tout un mode de fonctionnement "normal"; on est très loin de la limite de la perfection. Et je ne vois pas en quoi ça serait "prendre sur soi" que de s'attendre à trouver des logiciels réalisés correctement pour son système, et non pas correctement pour un autre et portés à la va-vite sur le sien.

Quelle est l'utilitée de faire une application en mode GUI alors que le mode console suffit largement ?

utilisabilité

./81 > les deux ne visent pas le même public ? (autrement dit : « suffit », ça dépend pour qui)

et également pour de simples raisons de préferences, car contrairement à ce que tu penses peut-être, dans le vrai monde des gens qui font autre chose que coder, beaucoup de personnes avec des gouts très curieux préferent ça à ça (mais quelle idée étrange, vraiment... )

ouais, enfin, meme le codeur prefere souvent les outils graphiques (une bonne ide vs. emacs) meme si y'a tjrs des irreductibles...

D'accord avec #76...

Même sans parler Unix, Windows est loin de POSIX - une norme de portabilité plus ou moins minimale - contrairement à la quasi-totalité des autres OS, y compris des OS non Unix (le VMS des VAX est à ma connaissance POSIX; etc.). Il s'en faut de beaucoup.

Il existe un adage depuis longtemps, formulé à peu près comme suit: "Ceux qui ne font pas de l'Unix sont condamnés à le réinventer, en moins bien". Sauf exception (par exemple VMS, avec une sécurité supérieure, un système de permissions puissant et quelques autres features intéressantes), ça reste vrai depuis 35 ans.

La supériorité technique des Unix sur les Windows n'a aucune contestation _sérieuse_ possible, tant en termes de compatibilité qu'en termes de performance, de portabilité, et tout simplement de fonctionnalités.
Pour la portabilité: Windows est limité à IA32/IA64/x86-64; Linux supporte environ 25 architectures allant du très petit au très gros, et ça ne compte pas les architectures sans MMU supportées par µcLinux, et probablement quelques autres architectures qui ne sont supportées que par un des Unix.
Pour les fonctionnalités, trois exemples:
* impossible d'implémenter un mmap 100% compatible avec celui des Unix, car les API Win32 ne le supportent pas. Je suis tombé sur ce problème de portabilité pendant l'été 2005, même si j'utilisais encore Windows la quasi-totalité du temps. Même si je sais le faire, faire à la main un vecteur de chaînes de caractères en C pur, et un certain nombre de structures de données qui vont avec, alors que ce n'est absolument pas nécessaire avec un très simple mmap, n'était pas une option. Enfin bon, j'ai par la suite refait le programme en Perl, qui n'a pas (du point de vue de l'utilisateur...) ces problèmes;
* certaines API réseau pas forcément très avancées (sockets bruts), sont impossibles sous Windows XP SP2.
* Linux est un kernel monolithique (je ne dis pas que c'est mal, car je ne pense pas que ce soit si mal que ça, pour des raisons de performance...), mais Windows a carrément un kernel "montagne". Dans Vista, à moins qu'ils aient encore changé d'avis, ils ont enlevé la partie graphique du kernel. Il faut dire que personne d'autre ne fait comme ça, et que générait des exploits surpuissants (exécution de code arbitraire avec les privilèges kernel...) à chaque fois qu'il y avait une faille de sécurité dedans (par exemple, les metafiles).

Même Microsoft a arrêté (au moins à l'époque de leur campagne anti-ouvert "Get The Facts") d'essayer de faire croire le contraire. Voir le commentaire d'Eric S. Raymonds sur le sujet.
Ca reprend un peu avec Vista... mais bon, Vista réussit à faire encore beaucoup plus lourd que ses prédécesseurs (même sans utiliser Aero...), sans même apporter la sécurité (voir les histoires de failles et de rootkits sous Vista...). De l'autre côté, il y a XGL et AIGLX: désolé Microsoft, mais c'est grossièrement faux que le logiciel libre est moche et mal fini...

nan, mais la mentalite de microsoft est/etait d'avoir fait un OS et tout tourner la dessus, on se fout un peu du reste du monde car on sait qu'on a un truc globalement superieur aux autres concurrents (sans trop de trolls, je parle de grand public).
En ce sens, c pas completement con, ils font des trucs pour eux, basta surtout si ca leur demande des efforts supplementaires pour faire qqch de compatible.

mais clairement... flemme de reprendre point par point le post #85 puisqu'il est en grande partie hors sujet, mais faut arrêter de placer "norme posix" et "windows" dans la même phrase; non seulement faudrait que vous compreniez que c'est leur droit de s'en contrefoutre totalement (¹), mais en plus à part quelques unixiens ça ne doit pas manquer à grand monde, et ça garantit une certaine qualité et homogéneïté dans les logiciels (et *ça* c'est important quand on veut utiliser son ordinateur et pas passer son temps à comprendre comment faire marcher tel ou tel outil obscur)

¹ : c'est quand même dingue de voir que tous ces fanatiques du "libre" sont finalement ceux qui veulent imposer leurs standards dans des trucs où ils n'ont pas à mettre leur nez, tout en accusant Microsoft de le faire sur leurs propres produits...

euh, autant j'étais à peu près d'accord avec toi jusque là sur les interfaces et le fait que c'est une bonne chose que le terminal par défaut de windows soit merdique, autant le fait que windows soit incompatible en interne avec des normes style posix (gestion des sockets différentes par exemple) n'apporte rien à l'utilisateur final, et complique significativement le portage du moteur (pas de l'interface) d'un certain nb de programmes sans que ça apporte quoi que ce soit :/ macos, sur ce point, est clairement supérieur ^^

mais évidemment je parle en termes d'intérêt pour les développeurs et utilisateurs de logiciel : pour microsoft, l'intérêt est très différent, il vaut mieux que ça soit difficile de porter des programmes dans le sens windows->mac/unix pour garder leur monopole alors qu'inversement, apple a intérêt à faciliter la portabilité pour avoir un maximum de programmes, d'où leur position différente...

> mais faut arrêter de placer "norme posix" et "windows" dans la même phrase;
Pas d'accord. Voir ce que Pollux a écrit.
> non seulement faudrait que vous compreniez que c'est leur droit de s'en contrefoutre totalement
Ca, je suis parfaitement d'accord. J'ai parfaitement compris, mais tu n'as manifestement pas compris que j'ai compris.

C'est juste que ça n'apporte rien, mais fait chier les développeurs et donc les utilisateurs. C'est clair, quand même ? Ca rend plus difficile la création et la portabilité de logiciel alternatif... donc ça facilite la continuation du monopole du propriétaire. Enfin, beaucoup d'utilisateurs de Windows s'en contrefoutent, ils utilisent leurs machines n'importe comment, et piratent à tour de bras. Formidable mentalité.

> c'est quand même dingue de voir que tous ces fanatiques du "libre"
D'une, attaque personnelle... et fausse dans mon cas. Tu ne me connais pas assez sur ces sujets pour savoir ce que je pense du fanatisme du libre, justement. Non, comme la grande majorité des utilisateurs de GNU/Linux, je n'utilise pas un GNU/Linux extrémistement libre, du type Ututo (la distribution supportée par la FSF), et j'incite les autres à faire pareil. Sur ma machine tournent divers logiciels propriétaires, à commencer par le driver pour la carte vidéo, car les drivers libres sont extrêmement mauvais. Et ce n'est pas le support de la dernière feature en date qui me manque: ma machine a bientôt trois ans et demi...
De deux, "libre" avec des guillemets est mal vu, même si je suis d'accord que les guillemets sont parfois parfaitement justifiés...

> sont finalement ceux qui veulent imposer leurs standards
"leurs" standards... grossièrement n'importe quoi ! Les standards Unix et POSIX existaient bien avant...
Quant à "imposer" les standards... je ne sais pas si on peut le mettre au même niveau que ce que Microsoft impose.
> dans des trucs où ils n'ont pas à mettre leur nez,
Bien péremptoire, cette affirmation...
> tout en accusant Microsoft de le faire sur leurs propres produits...
Depuis quand les unixiens essaient d'imposer des standards propriétaires fermés (WMA, DirectX, etc.) au détriment des standards déjà établis (MP3, OpenGL) ?

> euh, autant j'étais à peu près d'accord avec toi jusque là sur les interfaces et le fait que c'est une bonne chose que le terminal par défaut de windows soit merdique,
Merdique à ce point-là, je ne suis pas vraiment d'accord, d'autant plus que ce n'est pas particulièrement difficile à implémenter... sauf peut-être s'ils font du bottom-up et qu'ils codent vraiment n'importe comment, évidemment.

> autant le fait que windows soit incompatible en interne avec des normes style posix (gestion des sockets différentes par exemple) n'apporte rien à l'utilisateur final, et complique significativement le portage du moteur (pas de l'interface) d'un certain nb de programmes sans que ça apporte quoi que ce soit :/ macos, sur ce point, est clairement supérieur ^^
>
> mais évidemment je parle en termes d'intérêt pour les développeurs et utilisateurs de logiciel : pour microsoft, l'intérêt est très différent, il vaut mieux que ça soit difficile de porter des programmes dans le sens windows->mac/unix pour garder leur monopole alors qu'inversement, apple a intérêt à faciliter la portabilité pour avoir un maximum de programmes, d'où leur position différente...
Très bien compris sur les deux.


Zephyr, on arrête là le troll ? Si toi tu as l'impression de débattre avec des fanatiques du libre, nous on a l'impression de débattre avec un fanatique de Windows...