C'est du grand n'importe quoi ca, parce que le problème est le même avec tout produit nouveau. Le consommateur ne sait pas que ca existe au début, mais il y a du bouche à oreille, de la pub, des revues du produit, etc… et il commence à se répandre.
Les systèmes sans Windows, ben visiblement tout le monde s'en fout, sauf ceux avec une pomme dessus.
Marrant, Dell y arrive pourtant. Sony et HP y arrivaient et ont arrèté, et la CE, qui visiblement n'a aucun problème à poursuivre les sociètés US, n'a pas poursuivi MS pour cela.
Mon petit doigt me dit plutôt que tu prèfères imaginer Microsoft comme coupable idéeal plutot q'admettre que le grand public n'en a rien à battre d'avoir un choix entre leur système de prédilection pré-installé et un système obscur.
La vente non liée existe, depuis des années plusieurs vendeurs le font, et elle est restée anecdotique comparé au marché. Ca en dit long sur l'intéret du grand public.
Pour la seconde question, ce qui me choque le plus c'est la justification par l'état de fait : il n'y a sur le marché grand public que de la vente lié. Donc les consommateurs ne souhaitent pas autre chose. Donc la vente liée est une pratique acceptable. N'est-ce pas là un raisonnement qui se mord la queue ?
Du tout non.
La vente "non liée" existe et n'a clairement aucune présence significative sur le marché, signifiant que le consommateur en général ne recherche pas cela.
Je lis avec intérêt tes commentaires sur linuxfr, il en ressort que tu es compétant et surtout, tu as un avis différent de l'avis général, ce qui est souvent source de discussions intéressantes, mais qu'est ce que tu peux être impoli, c'est dingue ;)
On va dire que des années dans la jungle de linuxfr m'ont endurci :)
Je ne veux absolument pas dire que le non initialisé est mieux ou moins bien que le initialisé par défaut, je veux dire que les deux sont dangereux.
Mai justement, moi ce que je te dis est que non-initialisé est PIRE que initialisé par défaut, et c'est factuel.
Ensuite cela ne veut pas dire que initialisé par défaut est super et idéal hein, mais à choisir entre les 2 un est bien plus sûr que l'autre.
Mais qu'en est il d'autres types comme les entiers, les booléans où les char ? le \0 par défaut sur un char a certainement autant de chances de ne pas faire planter ton programme qu'un 42 ou un 12 par défaut, mais il est tout aussi faux si ce zéro n'était pas ton intention.
Cela revient de nouveau au fait que la solution est meilleure que non-initialisé tout en n'étant pas idéale. Les valeurs par défaut choisies vont le plus souvent sauver le développeur qui n'initialise pas ses valeurs. Pas toujours, mais le plus souvent.
Idéalement le développeur choisit des options du compilo l'avertissant qu'il utilise une variable non initialisée. Mais sans cela, l'initialisation par défaut aide à sauver beaucoup de gens.
Le fait que les variables non-initialisées sont bcp plus dangereuses que les variables initialisées à une valeur par défaut est un fait établi. Ce n'est pas un cas d'opinion.
C'est quoi la valeur par défaut d'un pointeur de fonction qui as du sens ? nullptr, ou une fonction au hasard ? Les deux cas n'ont pas de sens et sont dangereux, bref, avoir un pointeur "default-initialised" n'as pas de sens.
nullptr est la bonne valeur, et la raison est super simple :
nullptr assure que si la fonction est appelée ton soft crashe (accès à la page d'addresse 0 qui n'est pas mappée --> aucune exécution de code) sans pouvoir permettre d'exécution de code non controllée
laisser le pointeur non initiliasé permet à un attaquant de manipuler le soft jusqu'à ce qu'il ait la valeur qu'il veut au bon endroit (sur la stack en causant certains appels à être fait pour mettre les valeurs qu'il veut sur la stack, en mémoire avec un heap spray) et lui permettre ainsi d'exécuter du code arbitraire
Bref tu peux penser ce que tu veux, mais si tu oses aller donner ton explication à n'importe quelle personne en sécurité (moi par exemple, qui a passé les 12 dernières années dans le milieu) tu vas leur filer un arrèt cardiaque tellement ton explication ne tient absolument pas la route et démontre un manque de compréhension des enjeux.
Les valeur par défaut sont, à mon sens, plus dangereuses que les valeur non-initialisée.
Ca peut être ton sens, mais en pratique ce n'est absolument pas le cas.
L'exemple flagrant est les pointeurs, notamment pointeurs de fonction. Si tu le garde non-initialisé tu as un énorme trou de sécurité potentiel.
Ensuite, il n'y a absolument aucun besoin d'avoir un code instable pour aller chercher ces erreurs, n'importe quel compilateur décent te détectera une variable non-initialisée sur demande
De plus, les valeurs par défaut des types primitifs sont assez évidentes, mais celles de types plus élaborés sont totalement dépendants des choix des auteurs de la classe, et cela rend le code bien moins lisible.
Gni ? Tu demandes quoi là ? Evidemment que l'auteur de la classe va mettre ce qu'il désire dans le constructeur par défaut, c'est son code ! Tu veux faire quoi à la place ?
Parce que dans le cas géneral une variable non initialisée a de fortes chances de se retrouver avec tous les bits à zero car l'endroit en mémoire ou elle est allouée est à zero (tant que c'est pas sur la stack) ?
lorsque le score d'un journal tourne significativement négatif (disons 5 - pour un + ou autre avec un minimum de X votes), le système regarde l'âge du compte, et si le compte a moins de 48h, le journal est tout simplement supprimé ou mis sur une queue pour les modérateurs qui décident si il est viré ou pas.
Pour moi l'objectif est de rendre l'attractivité de créer un compte jetable pour poster un journal de merde faible.
Enelever le journal assez rapidement serait assez efficace, faut juste trouver les bons paramêtres pour éviter de virer les journaux des autres.
Je te dirais que c'est bien plus lisible et comprehensible, la function te lance une erreur si la conversion ne fonctionne pas, il est explicite dans la ligne que c'est de l'hex, tu n'as pas à devoir rajouter un '0x' en texte et risquer un problème si par hasard il y en a déjà un, la fonction supporte 0x 0X ou même pas de préfixe.
Parser un fichier dont tu ne maitrise pas le contenu sera pas trivial quelque soit le langage. Le principal avantage d'autres langages sera qu'ils valident plus facilement les données (tu peut toujours valider en shell unix avec une expression régulière si tu veux avoir quelque chose plus fiable) et te remontent une erreur plus claire.
Pas seulement, les autres langages ont aussi l'avantage que la déserialisation et conversion texte -> chiffre n'est à faire qu'une fois, au début.
Comment aurait-tu fait en powershell pour l'exemple que tu donne ? Une étape de déserialisation de chaque ligne dans un objet ? Cette désrialisation s'appuie sur quoi pour faire de l'arbitraire ?
Tout à fait, et évidemment cette étape initiale peut être plus ou moins complexe selon les données, mais une fois faite, je peux avoir 32 stages à mon pipe, et je n'ai plus à faire de conversion ou autres, c'est bien plus simple.
Et oui évidemment tu peux faire ça en python très bien, c'est ce que j'ai fait au final (flemme de passer le fichier sur Windows).
La question n'est pas si je suis allé chercher loin. Bash est turing complet, au final tu peux écrire un browser web complet en bash si tu veux. C'était simplement de démontrer à quel point bash peut être douloureux à cause du traitement en texte de tout ce qui passe, à chaque étape
et comment fais-tu la différence entre un nombre en octal/décimal/binaire/hexadécimal?
Si il n'a aucune indication, ca va être impossible évidemment, mais t'as typiquemment un préfixe. Et pour n'importe quel traitement un peu complexe tu fais simplement une première passe ou tu déserialise les données et les convertit pour les tourner en objet, et ensuite tu peux faire les traitement que tu veux de manière simple et sûre, là ou en bash tu es forcé de traiter du texte à chaque stage de ton pipe et te retaper de maudites conversion - parsing à chaque étape.
Mais tu assumes que tu connais les données à l'avance, ce qui n'est évidemment pas le cas.
Là cette semaine, je m'amuses à devoir traiter des données qui sont le résultat d'opérations sur un fichier reçu d'une boite externe histoire de sortir des stats.
J'ai pas choisi le format, j'ai pas choisi quelles infos extraire, … J'ai essayé de le faire avec une ligne de pipes dans bash (le processus en question tourne sous Linux), j'ai perdu des cheveux et assez vite abandonné.
Ben tu commences à comprendre la problématique. J'ai filé des exemples de base pour montrer à quel point cela devient le bordel si le format change un tout petit peu. Tu remarqueras que dans le monde réel, c'est fréquemment plus compliqué que juste une colonne dont toutes les valeurs ont le même format.
Tu as un type de donnée (un entier), et selon sa représentation textuelle, il faut utiliser 32 méthodes diffèrentes pour le traiter : utiliser des options diffèrentes, utiliser des commandes diffèrentes,…
Rappelons la problématique : traitement de données arbitraire.
Les données, elles pourraient être une colonne d'entiers en base 10, ça pourrait aussi être 5 colonnes dont la 3ême est la colonne de chiffres avec des colonnes séparées par des espaces ou tabs, mais pas de bol, les 2 premières colonnes sont des colonnes de texte, avec potentiellement des tabs-espaces dans le contenu. Et là ben tu vas t'amuser à rajouter ton 0x ou sortir la 3ème colonne pour la mettre en 1er
Les données, tu contrôles par forcèment leur format, tu dois vivre avec. Alors oui, c'est "possible" de tout faire avec bash, mais mon dieu quel bordel et douleur pour le faire hors des cas simples.
Je ne parles pas d'un changement dans la sortie de l'application, mais le parsage de texte est super fragile car la séparation entre champs est très fragile.
Combien de ces softs te sortent des colonnes basées soit sur un espace ou un tab ? Imagine que le contenu d'une des colonnes contienne un tab ou un espace, pas ta prochaine commande dans le pipe va pas faire la diffèrence et verra une colonne de plus sur cette ligne…
Voila, c'est tout ce qu'il faut pour pêter le pipe, et c'est purement dû au fait que le formattage texte empêche une séparation forte entre les champs.
Et je ne parles pas du bordel que c'est de gèrer les nombres et faire du tri avec le formattage texte…
C'est pas objet, c'est pas typé mais c'est souple comme un langage humain et ça marche pas si mal depuis des dizaines d'année (pour certaines tâches précises).
Ben le truc est qu'en Powershell tu peux faire les 2… objet, ou texte que tu parses. L'un n'empêche pas l'autre.
Je n'ai jamais dit que tous les policiers étaient avides de sang, loin s'en faut. Je t'ai en revanche fourni des arguments structurels qui expliquent pourquoi les policiers exécutent aveuglément les ordres, même quand ceux-ci sont en opposition manifeste avec la Constitution ou la Convention Européenne des Droits de l'Homme.
Non guignol tu n'as présenté que des cas isolés et tu oses en faire une systématisation car ca arrange ta vision du monde.
Il me paraît donc culotté, eu égard au fait que je t'ai présenté des arguments solides (avec en illustration un documentaire sur la formation des CRS), de me répondre avec un présent de vérité général sans fond ni chiffres.
Sans fond ni chiffres ? Fous toi de moi. Va simplement voir combien de fois la France a été condamnée par la cour européenne des droits de l'homme, et compare à la taille de la population.
Non mais vraiment, il te faut une greffe du cerveau à ce niveau, c'est grâve.
Montre moi un pays ou un département où c'est pire que "la police a foncé dans le tas et je vois des gens bléssés alors j'ai bien des trucs à dire sur la police"
Mon dieu mon dieu… tu n'es jamais sorti de la France dis-moi ?
Va demander aux Egyptiens comment leur police fonctionne, ensuite va faire un tour en Turquie, et n'oublie pas la Syrie et l'Iraq en passant, ou si tu veux plus d'exotisme, fais un tour dans les favelas brésiliens pendant une descente de police.
Ensuite, quand tu te seras aguerri, ben n'hesites pas à aller en Erythree, au Soudan, …
Ce n'est pas très intelligent d'utiliser l'argument de la "majorité est contre toi", c'est un système juridique qui avait lieu au moyen age on appel ca l'inquisition… on a brulé des sorcières pour ça.
LOL, brûlé des sorcières, rien que ça.
Je lui souligne que plusieurs personnes plutôt sensées lui pointent toutes qu'il manque sérieusement de balance dans ses propos histoire qu'il réflechisse un peu et se remette en question. Il n'y a pas de bûcher ici, juste une recommendation à aller voir un psy pour un problême averé.
[^] # Re: Il faut lire
Posté par pasBill pasGates . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à -9.
C'est du grand n'importe quoi ca, parce que le problème est le même avec tout produit nouveau. Le consommateur ne sait pas que ca existe au début, mais il y a du bouche à oreille, de la pub, des revues du produit, etc… et il commence à se répandre.
Les systèmes sans Windows, ben visiblement tout le monde s'en fout, sauf ceux avec une pomme dessus.
[^] # Re: Pas vraiment pour rien
Posté par pasBill pasGates . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à -2.
Marrant, Dell y arrive pourtant. Sony et HP y arrivaient et ont arrèté, et la CE, qui visiblement n'a aucun problème à poursuivre les sociètés US, n'a pas poursuivi MS pour cela.
Mon petit doigt me dit plutôt que tu prèfères imaginer Microsoft comme coupable idéeal plutot q'admettre que le grand public n'en a rien à battre d'avoir un choix entre leur système de prédilection pré-installé et un système obscur.
La vente non liée existe, depuis des années plusieurs vendeurs le font, et elle est restée anecdotique comparé au marché. Ca en dit long sur l'intéret du grand public.
[^] # Re: Il faut lire
Posté par pasBill pasGates . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à -6.
Du tout non.
La vente "non liée" existe et n'a clairement aucune présence significative sur le marché, signifiant que le consommateur en général ne recherche pas cela.
[^] # Re: Pas vraiment pour rien
Posté par pasBill pasGates . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à -9.
Ben non justement. T'as une cour de justice qui vient de dire qu'il n'y a rien d'illégal à cela.
Sans parler du fait que MS est hors de cela, c'est les constructeurs qui décident de comment vendre leurs systèmes.
Ben tu sais, un ordinateur ca n'éxecute pas de système d'exploitation, ca sert à jouer, à faire des feuilles de calcul ou du traitement de texte
[^] # Re: Pas uniquement string
Posté par pasBill pasGates . En réponse au journal Switch, chaîne constante et c++. Évalué à 1.
On va dire que des années dans la jungle de linuxfr m'ont endurci :)
Mai justement, moi ce que je te dis est que non-initialisé est PIRE que initialisé par défaut, et c'est factuel.
Ensuite cela ne veut pas dire que initialisé par défaut est super et idéal hein, mais à choisir entre les 2 un est bien plus sûr que l'autre.
Cela revient de nouveau au fait que la solution est meilleure que non-initialisé tout en n'étant pas idéale. Les valeurs par défaut choisies vont le plus souvent sauver le développeur qui n'initialise pas ses valeurs. Pas toujours, mais le plus souvent.
Idéalement le développeur choisit des options du compilo l'avertissant qu'il utilise une variable non initialisée. Mais sans cela, l'initialisation par défaut aide à sauver beaucoup de gens.
[^] # Re: Pas uniquement string
Posté par pasBill pasGates . En réponse au journal Switch, chaîne constante et c++. Évalué à 1.
Non qu'on se comprenne bien.
Déreferencer un pointeur NULL va causer une exception.
mov [eax],0x1 avec eax=0x0000000000000000 va causer un access violation
Ensuite que le compilo optimise ta représentation en C et enlève les instructions qui déreferencent NULL, c'est une autre histoire.
[^] # Re: Pas uniquement string
Posté par pasBill pasGates . En réponse au journal Switch, chaîne constante et c++. Évalué à 3.
Qu'on se comprenne.
Le fait que les variables non-initialisées sont bcp plus dangereuses que les variables initialisées à une valeur par défaut est un fait établi. Ce n'est pas un cas d'opinion.
nullptr est la bonne valeur, et la raison est super simple :
Bref tu peux penser ce que tu veux, mais si tu oses aller donner ton explication à n'importe quelle personne en sécurité (moi par exemple, qui a passé les 12 dernières années dans le milieu) tu vas leur filer un arrèt cardiaque tellement ton explication ne tient absolument pas la route et démontre un manque de compréhension des enjeux.
[^] # Re: Pas uniquement string
Posté par pasBill pasGates . En réponse au journal Switch, chaîne constante et c++. Évalué à 4.
Ca peut être ton sens, mais en pratique ce n'est absolument pas le cas.
L'exemple flagrant est les pointeurs, notamment pointeurs de fonction. Si tu le garde non-initialisé tu as un énorme trou de sécurité potentiel.
Ensuite, il n'y a absolument aucun besoin d'avoir un code instable pour aller chercher ces erreurs, n'importe quel compilateur décent te détectera une variable non-initialisée sur demande
Gni ? Tu demandes quoi là ? Evidemment que l'auteur de la classe va mettre ce qu'il désire dans le constructeur par défaut, c'est son code ! Tu veux faire quoi à la place ?
[^] # Re: Pas uniquement string
Posté par pasBill pasGates . En réponse au journal Switch, chaîne constante et c++. Évalué à 0. Dernière modification le 01 septembre 2016 à 21:17.
Parce que dans le cas géneral une variable non initialisée a de fortes chances de se retrouver avec tous les bits à zero car l'endroit en mémoire ou elle est allouée est à zero (tant que c'est pas sur la stack) ?
# Autre idée
Posté par pasBill pasGates . En réponse à l’entrée du suivi Délai d'activation des permissions des nouveaux comptes ?. Évalué à 3 (+0/-0).
Perso je suggères plutôt cela :
Pour moi l'objectif est de rendre l'attractivité de créer un compte jetable pour poster un journal de merde faible.
Enelever le journal assez rapidement serait assez efficace, faut juste trouver les bons paramêtres pour éviter de virer les journaux des autres.
[^] # Re: Et ?
Posté par pasBill pasGates . En réponse au journal Bienvenue en Musulmanie !. Évalué à 10.
Et toi probablement demander des fonds pour une greffe de cerveau
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 0.
Ben oui bien sur que c'est faisable, je ne doutes pas de la faisabilité.
Mais regarde ta version bash, tu trouves ça pratique et simple?
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1.
Tout a fait, il faut faire ton parsing avec n'importe quel langage utilisé
En powershell, la ligne pour du hex serait :
Get-Content val.txt | sort {[convert]::toint64($_.split()[0],16)}
Je te dirais que c'est bien plus lisible et comprehensible, la function te lance une erreur si la conversion ne fonctionne pas, il est explicite dans la ligne que c'est de l'hex, tu n'as pas à devoir rajouter un '0x' en texte et risquer un problème si par hasard il y en a déjà un, la fonction supporte 0x 0X ou même pas de préfixe.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 2.
Pas seulement, les autres langages ont aussi l'avantage que la déserialisation et conversion texte -> chiffre n'est à faire qu'une fois, au début.
Tout à fait, et évidemment cette étape initiale peut être plus ou moins complexe selon les données, mais une fois faite, je peux avoir 32 stages à mon pipe, et je n'ai plus à faire de conversion ou autres, c'est bien plus simple.
Et oui évidemment tu peux faire ça en python très bien, c'est ce que j'ai fait au final (flemme de passer le fichier sur Windows).
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 2.
La question n'est pas si je suis allé chercher loin. Bash est turing complet, au final tu peux écrire un browser web complet en bash si tu veux. C'était simplement de démontrer à quel point bash peut être douloureux à cause du traitement en texte de tout ce qui passe, à chaque étape
Si il n'a aucune indication, ca va être impossible évidemment, mais t'as typiquemment un préfixe. Et pour n'importe quel traitement un peu complexe tu fais simplement une première passe ou tu déserialise les données et les convertit pour les tourner en objet, et ensuite tu peux faire les traitement que tu veux de manière simple et sûre, là ou en bash tu es forcé de traiter du texte à chaque stage de ton pipe et te retaper de maudites conversion - parsing à chaque étape.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1.
Mais tu assumes que tu connais les données à l'avance, ce qui n'est évidemment pas le cas.
Là cette semaine, je m'amuses à devoir traiter des données qui sont le résultat d'opérations sur un fichier reçu d'une boite externe histoire de sortir des stats.
J'ai pas choisi le format, j'ai pas choisi quelles infos extraire, … J'ai essayé de le faire avec une ligne de pipes dans bash (le processus en question tourne sous Linux), j'ai perdu des cheveux et assez vite abandonné.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 2.
Tu as raté un élément très important de Powershell :
il peut utiliser n'importe quel objet COM de manière naturelle, sans que l'application ait été prévue pour Powershell.
Et les interfaces COM dans les softs sous Windows sont super-répandues pour permettre l'administration, et cela depuis des siècles.
cf. Citrix par exemple : https://www.citrix.com/blogs/2008/07/25/powershell-and-mfcom-lets-get-started/
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1.
Ben tu commences à comprendre la problématique. J'ai filé des exemples de base pour montrer à quel point cela devient le bordel si le format change un tout petit peu. Tu remarqueras que dans le monde réel, c'est fréquemment plus compliqué que juste une colonne dont toutes les valeurs ont le même format.
Tu as un type de donnée (un entier), et selon sa représentation textuelle, il faut utiliser 32 méthodes diffèrentes pour le traiter : utiliser des options diffèrentes, utiliser des commandes diffèrentes,…
Rappelons la problématique : traitement de données arbitraire.
Les données, elles pourraient être une colonne d'entiers en base 10, ça pourrait aussi être 5 colonnes dont la 3ême est la colonne de chiffres avec des colonnes séparées par des espaces ou tabs, mais pas de bol, les 2 premières colonnes sont des colonnes de texte, avec potentiellement des tabs-espaces dans le contenu. Et là ben tu vas t'amuser à rajouter ton 0x ou sortir la 3ème colonne pour la mettre en 1er
Les données, tu contrôles par forcèment leur format, tu dois vivre avec. Alors oui, c'est "possible" de tout faire avec bash, mais mon dieu quel bordel et douleur pour le faire hors des cas simples.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1.
Ben non… cf. cet exemple et la valeur 20400001000
```
ubuntu@ip-172-31-1-133:~$ cat val3.txt
400000000 _crt0
400000039 __newr0
400001C14 get_new_task_id
400001385 output_str_j1
200000020 reg1
200000038 reg4
20400001000 status
400001E0C t1
400001E70 t2
400001D14 taskid_to_ec_range
ubuntu@ip-172-31-1-133:~$ cat val3.txt |sort -k1 -g
400001C14 get_new_task_id
400001D14 task_id_to_ec_range
400001E0C t1
200000020 reg1
200000038 reg4
400000000 _crt0
400000039 _newr0
400001385 outputstrj1
20400001000 status
400001E70 t2
```
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 0.
0xaef
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1. Dernière modification le 24 août 2016 à 09:03.
Je ne parles pas d'un changement dans la sortie de l'application, mais le parsage de texte est super fragile car la séparation entre champs est très fragile.
Combien de ces softs te sortent des colonnes basées soit sur un espace ou un tab ? Imagine que le contenu d'une des colonnes contienne un tab ou un espace, pas ta prochaine commande dans le pipe va pas faire la diffèrence et verra une colonne de plus sur cette ligne…
Voila, c'est tout ce qu'il faut pour pêter le pipe, et c'est purement dû au fait que le formattage texte empêche une séparation forte entre les champs.
Et je ne parles pas du bordel que c'est de gèrer les nombres et faire du tri avec le formattage texte…
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . En réponse au journal Microsoft: Powershell libéré. Évalué à 1.
Ben le truc est qu'en Powershell tu peux faire les 2… objet, ou texte que tu parses. L'un n'empêche pas l'autre.
[^] # Re: Powershell et cURL - mauvaise volonté
Posté par pasBill pasGates . En réponse au journal PowerShell sur Linux. Évalué à 4.
Non guignol tu n'as présenté que des cas isolés et tu oses en faire une systématisation car ca arrange ta vision du monde.
Sans fond ni chiffres ? Fous toi de moi. Va simplement voir combien de fois la France a été condamnée par la cour européenne des droits de l'homme, et compare à la taille de la population.
Non mais vraiment, il te faut une greffe du cerveau à ce niveau, c'est grâve.
[^] # Re: Powershell et cURL - mauvaise volonté
Posté par pasBill pasGates . En réponse au journal PowerShell sur Linux. Évalué à 5.
Mon dieu mon dieu… tu n'es jamais sorti de la France dis-moi ?
Va demander aux Egyptiens comment leur police fonctionne, ensuite va faire un tour en Turquie, et n'oublie pas la Syrie et l'Iraq en passant, ou si tu veux plus d'exotisme, fais un tour dans les favelas brésiliens pendant une descente de police.
Ensuite, quand tu te seras aguerri, ben n'hesites pas à aller en Erythree, au Soudan, …
LOL, brûlé des sorcières, rien que ça.
Je lui souligne que plusieurs personnes plutôt sensées lui pointent toutes qu'il manque sérieusement de balance dans ses propos histoire qu'il réflechisse un peu et se remette en question. Il n'y a pas de bûcher ici, juste une recommendation à aller voir un psy pour un problême averé.
[^] # Re: Powershell et cURL - mauvaise volonté
Posté par pasBill pasGates . En réponse au journal PowerShell sur Linux. Évalué à 6.
Vu d'ici ?
Tu veux dire vu de l'asile psychiatrique ? Pas étonnant.