La Fibre

Télécom => Logiciels et systèmes d'exploitation => Free BSD Autres systèmes d'exploitation => Discussion démarrée par: corrector le 30 août 2016 à 05:47:54

Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 05:47:54
5 pages extraites du sujet Linux fête ses 25 ans (https://lafibre.info/logiciel/linux-fete-ses-25-ans/)

En entrant à l'IUT, j'ai découvert AIX, Internet (la LS Renater à 2 Mbps nous faisait tous baver d'envie), le système X-Window et ses terminaux monochromes, et j'ai été subjugué par la puissance des systèmes UNIX, et leur souplesse d'administration.
Et moi j'ai été subjugué par la merdicité des systèmes Unix :
- shells merdiques incompatibles les uns avec les autres, sémantique de ' vs " vs $ incompréhensible, splitting incompréhensible, les gens qui disent que c'est simple en général n'y comprennent RIEN
- philosophie moisie des outils en ligne commande qui font une chose et qui la font bien mais qui ne marche jamais
- utilitaires moisies qu'on n'arrive pas à combiner
- scripts moisis qui se chient dessus dès qu'un nom de fichier contient caractère aussi bizarre qu'un espace (for x in *)
- traitement de groupe de fichiers qui ne sont pas robustes (quels que soient les caractères des noms de fichier) qu'avec les extensions GNU à find et xargs
- le moindre traitement très simple de fichiers demande une super ligne de commande contenant une dizaines de commandes différentes
- 36 syntaxes différentes selon les utilitaires
- énormèment d'implicites qui rendent l'apprentissage plus difficile
- univers impénétrable réservé aux gourous
- difficulté extrême à rendre robuste un executable SUID
- sémantique Unix de open qui ne permet même pas d'ouvrir un fichier seulement s'il est ordinaire
- merdicité extrême de make (je vous mets au défi d'écrire un makefile faisant correctement ce que fait automatiquement n'importe quel compilateur intégré à la base : recompiler ce qu'il faut recompiler - même avec les extensions GNU)
- discours prétentieux sur la séparation du noyau et des logiciels alors qu'un composant monstrueux comme X a accès à tout
- va-chierisme des libristes : si tu signales un bug, on te dit que c'est documenté (ça ne l'est pas), c'est voulu (certainement pas), c'est normal (non), c'est attendu (non), tu peux le corriger toi-même (faux)
- hypocrisie abjecte des défenseurs de ces systèmes

Je vomis Unix/linux et ses fanboys.
Titre: Avis de corrector sur Unix
Posté par: spectrolazer le 30 août 2016 à 08:56:12
Je vomis Unix/linux et ses fanboys.
Et donc tu ne fais plus d'informatique ?!? Parce les clic/clac la souris, excuse moi mais...ou alors tu n'as pas le niveau pour assimiler ;)
Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 08:57:38
Et donc tu ne fais plus d'informatique ?!? Parce les clic/clac la souris, excuse moi mais...ou alors tu n'as pas le niveau pour assimiler ;)
Quel est le souci avec les clic/clac? Est-ce que tu essayes d'exprimer ta pensée, ou est-ce que tu essayes de penser quelque chose?
Titre: Avis de corrector sur Unix
Posté par: seb le 30 août 2016 à 09:00:32
Je vomis Unix/linux et ses fanboys.
Je n'en attendais pas moins de toi.

D'ailleurs je me demande s'il y a un seul truc que tu ne hais pas dans la vie, à part peut être ta personne.
Mais même ça, je n'en suis pas certain.
Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 09:09:42
Contrairement à d'autres, je ne hais PAS les valeurs p. (Je méprise les fan-boys décérébrés des valeurs p, évidemment, et les promoteurs bouffons des vaccinations les plus invraisemblables.)

Et toi, qu'est-ce que tu apprécies?
Titre: Avis de corrector sur Unix
Posté par: spectrolazer le 30 août 2016 à 09:11:46
Quel est le souci avec les clic/clac? Est-ce que tu essayes d'exprimer ta pensée, ou est-ce que tu essayes de penser quelque chose?
Assistanat ça te va comme réponse.
Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 09:17:26
Assistanat ça te va comme réponse.
Non, parce que ça ne veut rien dire.

Encore une fois, tu viens ici exprimer des idées, ou bien juste troller?
Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 09:23:56
Unix/linux est un culte maléfique où des "gurus" montrent leur supériorité avec des commandes magiques incompréhensibles du style :

Citer
Print file content in reverse order

$ sed -n '1!G;h;$p' thegeekstuff.txt
http://www.thegeekstuff.com/2010/11/50-linux-commands/
Titre: Avis de corrector sur Unix
Posté par: spectrolazer le 30 août 2016 à 09:37:47
Non, parce que ça ne veut rien dire.

Encore une fois, tu viens ici exprimer des idées, ou bien juste troller?

Ton aversion à Unix et consors semble principalement motivée par sa difficulté d'utilisation : on peut faire de l'informatique en mode "next/next" ou bien mettre les mains dans le cambouis, et c'est bien là l'essence même de ceux qui la pratique, non ?
Toute la nuance est là pour moi et c'est ce qui motive mes propos.
Après je cautionne complètement ce que tu dis mais je ne vois rien de comparable en terme d'outils/fonctionnalités dans les "autres types" d'OS.
Titre: Avis de corrector sur Unix
Posté par: spectrolazer le 30 août 2016 à 09:57:43
Contrairement à d'autres, je ne hais PAS les valeurs p. (Je méprise les fan-boys décérébrés des valeurs p, évidemment, et les promoteurs bouffons des vaccinations les plus invraisemblables.)

Et toi, qu'est-ce que tu apprécies?
[HS]
J'apprécie les vraies valeurs et  HAIR/MEPRISER ne font et ne feront, dans ce sens, jamais partie des verbes utilisés pour manifester les miennes.
(entre nous, s'il est question de pensée, tu devrais fortement t'inquiéter de l'état de la tienne pour en arriver à utiliser des verbes aussi forts que ceux-ci)

Puisque l'esprit semble corrompu, as-tu songé au corps par quelques activités défoulatoires ?
[/HS]
Titre: Avis de corrector sur Unix
Posté par: corrector le 30 août 2016 à 18:29:25
Ton aversion à Unix et consors semble principalement motivée par sa difficulté d'utilisation : on peut faire de l'informatique en mode "next/next" ou bien mettre les mains dans le cambouis, et c'est bien là l'essence même de ceux qui la pratique, non ?
Toute la nuance est là pour moi et c'est ce qui motive mes propos.
Après je cautionne complètement ce que tu dis mais je ne vois rien de comparable en terme d'outils/fonctionnalités dans les "autres types" d'OS.
Sur n'importe quel OS orienté utilisateur normal et pas orienté gourou barbu autiste, tu appuies sur une touche et ça recompile ce qu'il faut, sans faire un makemachin.

Je n'ai aucune envie de mettre les mains dans ce machin.
Titre: Avis de corrector sur Unix
Posté par: seb le 30 août 2016 à 21:00:14
Sur n'importe quel OS orienté utilisateur normal et pas orienté gourou barbu autiste, tu appuis sur une touche et ça recompile ce qu'il faut, sans faire un makemachin.
Les EDI ça existe aussi sous UNIX, tu sais ?

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.

Sinon, pour revenir un peu sur le fond de ton argumentaire :
- shells merdiques incompatibles les uns avec les autres, sémantique de ' vs " vs $ incompréhensible, splitting incompréhensible, les gens qui disent que c'est simple en général n'y comprennent RIEN
Quoique tu puisses en penser, la variété des shells disponibles fait partie des avantages du système.
Le choix est laissé à l'utilisateur d'utiliser celui qui lui convient le mieux, tant du point de vue ergonomie que fonctionnalités.
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.

Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
La plupart de ceux que j'écrivais il y a une dizaine d'années fonctionnaient de la même manière sous Linux, Solaris, AIX et UnixWare.
Je devais juste m'assurer qu'il sache sur quel système il tournait, et d'utiliser les commandes et options adéquates.

- philosophie moisie des outils en ligne commande qui font une chose et qui la font bien mais qui ne marche jamais
Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.

- utilitaires moisies qu'on n'arrive pas à combiner
Comme ?
 
- scripts moisis qui se chient dessus dès qu'un nom de fichier contient caractère aussi bizarre qu'un espace (for x in *)
Mauvais développeur(s) ?
seb@gaston:~/tmp$ cat ../test
#!/bin/sh

for x in *
do
echo "x=\"$x\""
done

seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"

- traitement de groupe de fichiers qui ne sont pas robustes (quels que soient les caractères des noms de fichier) qu'avec les extensions GNU à find et xargs
C'est un vrai problème quand on multiplie les tubes et qu'on traite des fichiers contenant des espaces dans leurs noms, mais il y a de nombreux moyens de le contourner, même sans faire appel aux outils GNU.

- le moindre traitement très simple de fichiers demande une super ligne de commande contenant une dizaines de commandes différentes
Comme par exemple ?

- 36 syntaxes différentes selon les utilitaires
Tous les utilitaires classiques peuvent être appelés en utilisant leur variante POSIX.
Dans ce cas, la syntaxe et les résultats sont identiques partout.

- énormèment d'implicites qui rendent l'apprentissage plus difficile
De quelle nature ?
Et plus difficile que quoi ?

- univers impénétrable réservé aux gourous
Uniquement à ceux qui sont barbus et autistes.
Quand tu n'es ni gourou, ni barbu, ni autiste, comme moi, tu ne peux à l'évidence rien y comprendre.

- difficulté extrême à rendre robuste un executable SUID
J'ai trouvé 16 exécutables avec le bit SUID positionné sur ma machine (sur un total de 2426 exécutables).
Ce n'est donc pas comme si cette problématique de sécurité, par ailleurs largement documentée, concernait le premier développeur venu.
Les autres savent normalement comment gérer l'affaire au niveau de leur code.

- sémantique Unix de open qui ne permet même pas d'ouvrir un fichier seulement s'il est ordinaire
Parce que c'est si compliqué que ça de le tester par toi même avant de chercher à l'ouvrir ?
Tu cherches vraiment la petite bête là.

- merdicité extrême de make (je vous mets au défi d'écrire un makefile faisant correctement ce que fait automatiquement n'importe quel compilateur intégré à la base : recompiler ce qu'il faut recompiler - même avec les extensions GNU)
Ça faisait 10 ans que je n'avais plus touché de Makefile ou de code C, et il m'a fallu 10 minutes pour écrire cette beauté :
seb@gaston:~/tmp$ cat main.c
#include "defs.h"
#include "hello.h"

void main( int argc, char *argv[] )
{
Hello(WORLD);
}

seb@gaston:~/tmp$ cat hello.c
#include <stdio.h>

#include "defs.h"
#include "hello.h"

void Hello( char *msg )
{
printf( "%s, %s.\n", HELLO, msg );
}

seb@gaston:~/tmp$ cat hello.h
void Hello( char *msg );

seb@gaston:~/tmp$ cat defs.h
#define HELLO "Hello"
#define WORLD "world"

seb@gaston:~/tmp$ cat Makefile
all: hello

hello: hello.o main.o
cc hello.o main.o -o hello

hello.o: hello.c hello.h defs.h
cc -c hello.c -o hello.o

main.o: main.c hello.h defs.h
cc -c main.c -o main.o

clean:
rm -f hello *.o

seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc -c main.c -o main.o
cc hello.o main.o -o hello

seb@gaston:~/tmp$ ./hello
Hello, world.

seb@gaston:~/tmp$ vi hello.c
seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc hello.o main.o -o hello

seb@gaston:~/tmp$ ./hello
Hello, world!

seb@gaston:~/tmp$ vi defs.h
seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc -c main.c -o main.o
cc hello.o main.o -o hello

seb@gaston:~/tmp$ ./hello
lol, corrector!

- discours prétentieux sur la séparation du noyau et des logiciels alors qu'un composant monstrueux comme X a accès à tout
Je ne comprends pas cette remarque, car X n'a accès qu'à ce que le noyau veut bien lui monter.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 11:03:44
Les EDI ça existe aussi sous UNIX, tu sais ?
Je ne parlais pas de ça. Je parlais de la tradition Unix de merde, d'ailleurs tout le monde avait compris.

Sinon tu pouvais aussi me répondre que le shell est de la merde mais que les gens dotés d'un peu de sens commun font leurs scripts en perl ou autre machin indépendant de l'OS.

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
Si c'est pour avoir une merde préhistorique avec des bizarreries et des types incompatibles...

Sinon, pour revenir un peu sur le fond de ton argumentaire :Quoique tu puisses en penser, la variété des shells disponibles fait partie des avantages du système.
Et la variété des comportements de /bin/sh, c'est un avantage?

Le choix est laissé à l'utilisateur d'utiliser celui qui lui convient le mieux, tant du point de vue ergonomie que fonctionnalités.
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.
Mais tu n'as pas toujours le choix de ton shell de login.

Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
Effort à la con, intellectualisme de merde.

Je NE veux PAS salir mon cerveau avec ça.

La plupart de ceux que j'écrivais il y a une dizaine d'années fonctionnaient de la même manière sous Linux, Solaris, AIX et UnixWare.
Je devais juste m'assurer qu'il sache sur quel système il tournait, et d'utiliser les commandes et options adéquates.
CQFD

Bon, tu arrives sur un Unix bizarre et inconnu, tu installes les machins GNU, et tu ne t'occupes plus du reste. Voilà pour la compatibilité.

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Voilà, comme Windows en fait. Cela marche assez souvent.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 11:13:11
Ça faisait 10 ans que je n'avais plus touché de Makefile ou de code C, et il m'a fallu 10 minutes pour écrire cette beauté :
Tu ne sais pas les risques auxquels tu t'exposes!

seb@gaston:~/tmp$ cat main.c
#include "defs.h"
#include "hello.h"

void main( int argc, char *argv[] )
Grave erreur!

main doit renvoyer un int, sinon tu as
- formellement : un comportement indéfini
- en pratique : une valeur de sortie non définie

En revanche, vu que tu n'as pas besoin de argc et argv, tu peux les omettre, ça vaut mieux que d'avoir des paramètres inutilisés.

hello.o: hello.c hello.h defs.h
cc -c hello.c -o hello.o
Manque plein de choses (indication de la norme souhaitée, warnings, etc.)

Tout cela n'est pas spécifique à linux ou Unix.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 11:32:32
Mauvais développeur(s) ?
Mauvais outils.

Je te mets au défi de justifier la sémantique des shell! Même de me l'expliquer!

seb@gaston:~/tmp$ cat ../test
#!/bin/sh

for x in *
do
echo "x=\"$x\""
done

seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"
Donc il faut TOUJOURS penser à mettre des quotes autour d'un "paramètre", désolé je ne trouve pas ça naturel et complètement débile. Et en pratique il y a des scripts qui se chient dessus si un paramètre contient des espaces.

Et surtout comme la plupart du temps il n'y a PAS d'espace dans les noms, une erreur ne se verra pas.

Tous les utilitaires classiques peuvent être appelés en utilisant leur variante POSIX.
Justement, la variante POSIX de la commande cp ne connait pas l'option -a, et donc la seule façon fiable de copier est tar ... | tar ....

C'est ça, "Unix". Pour faire quelque chose de passablement simple il faut une syntaxe complètement incompréhensible pour les débutants.

Dans ce cas, la syntaxe et les résultats sont identiques partout.
POSIX stipule plein de comportements débiles et est très limité. Déjà linux est pénible, mais alors s'il faut se restreindre aux trucs standards...

Bon, en résumé : presque TOUT est TROP compliqué sous nix.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 11:52:59
Parce que c'est si compliqué que ça de le tester par toi même avant de chercher à l'ouvrir ?
Tu cherches vraiment la petite bête là.
Dis, tu es sérieux, là?

Tu suggères vraiment de faire une vérification avec stat suivi de open?

Tu confirmes ce que je pensais de toi.
Titre: Avis de corrector sur Unix
Posté par: Hugues le 31 août 2016 à 12:18:05
Sinon moi j'aime bien OSX, et j'ai des espaces dans mes fichiers :p

/me sort
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 12:50:52
Je ne comprends pas cette remarque, car X n'a accès qu'à ce que le noyau veut bien lui monter.
Je ne sais pas ce que tu entends par "ce que le noyau veut bien lui monter"! N'importe quel processus par définition n'a accès qu'à ce que le noyau lui expose, mais parfois cet accès est direct; mais je me demande si tu sais faire la distinction entre un accès direct et un accès avec une intermédiation significative. Par exemple, certains périphériques donnent un accès direct, comme les port série, d'autre une construction artificielle, comme la souris PS2 du noyau.

Est-ce que /dev/mem est un accès direct pour toi?

hw/xfree86/os-support/linux/lnx_video.c :

Bool
xf86EnableIO(void)
{
#if defined(__powerpc__)
    int fd;
    unsigned int ioBase_phys;
#endif

    if (ExtendedEnabled)
        return TRUE;

#if defined(__powerpc__)
    ioBase_phys = syscall(__NR_pciconfig_iobase, 2, 0, 0);

    fd = open("/dev/mem", O_RDWR);
    if (ioBase == NULL) {
        ioBase = (volatile unsigned char *) mmap(0, 0x20000,
                                                 PROT_READ | PROT_WRITE,
                                                 MAP_SHARED, fd, ioBase_phys);
/* Should this be fatal or just a warning? */
#if 0
        if (ioBase == MAP_FAILED) {
            xf86Msg(X_WARNING,
                    "xf86EnableIOPorts: Failed to map iobase (%s)\n",
                    strerror(errno));
            return FALSE;
        }
#endif
    }
    close(fd);
#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__) && !defined(__arm__) && !defined(__m32r__) && !defined(__nds32__)
    if (ioperm(0, 1024, 1) || iopl(3)) {
        if (errno == ENODEV)
            ErrorF("xf86EnableIOPorts: no I/O ports found\n");
        else
            FatalError("xf86EnableIOPorts: failed to set IOPL"
                       " for I/O (%s)\n", strerror(errno));
        return FALSE;
    }
#if !defined(__alpha__)
    /* XXX: this is actually not trapping anything because of iopl(3)
     * above */
    ioperm(0x40, 4, 0);         /* trap access to the timer chip */
    ioperm(0x60, 4, 0);         /* trap access to the keyboard controller */
#endif
#endif
    ExtendedEnabled = TRUE;

    return TRUE;
}
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 13:02:42
Les EDI ça existe aussi sous UNIX, tu sais ?
Oui mais tous les élèves vont être enseignés, remplis, abrutis de débilités unixoïdes avant d'apprendre les trucs bien.

Comme make, qui est le problème et non la solution dans 99% des cas. Ou apprendre que toute grammaire doit être traitée avec lex/yacc et qu'il faut être débile pour écrire un analyseur à la main - alors que c'est le contraire, il faut être débile pour vouloir tout traiter avec un outil standard.

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
C'est bien, ça permet de compiler GCC.

Non je déconne, pourquoi pas installer GCC déjà compilé?

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Avec cet argument on justifie n'importe quoi.

Encore un petit effort et tu vas me justifier le bazar de autogen et autoconf!

Je ne sais pas si tu te rends compte de l'absurdité de ta position.

Déjà expliquer un makefile simple à un débutant, à quel moment chaque symbole est spécial, les paramètres make qui ne sont pas des paramètres shell, les multiples niveaux d'interprétation... beurk!
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 13:11:49
seb@gaston:~/tmp$ cat ../test
#!/bin/sh

for x in *
do
echo "x=\"$x\""
done

seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"
C'est un vrai problème quand on multiplie les tubes et qu'on traite des fichiers contenant des espaces dans leurs noms, mais il y a de nombreux moyens de le contourner, même sans faire appel aux outils GNU.
Traiter des noms de fichier contenant des espaces est le bas de l'échelle du traitement de noms de fichiers quelconques par des scripts shell.

Ensuite, tu as les retours à la ligne qui sont possibles dans un nom de fichier, mais qui vont mettre la zone si tu fais find | xargs, sauf avec l'option adéquate des GNU fileutils.

Tu as aussi le gag du nom de fichier commençant par un "-", ce qui passe avec certains utilitaires ou certaines commandes shell mais pas toutes. Avec GNU, tu as la protection "--", mais sous d'autres systèmes, je crois qu'il n'y a rien.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 13:30:09
- utilitaires moisies qu'on n'arrive pas à combiner
Comme ?
Comme sort et ses compagnons qui consomment les fichiers triés!

La commande sort est très puissante avec plein de possibilité de séparer les champs, d'inverser l'ordre, de trier selon plusieurs champs avec plusieurs interprétation (lexicographique/numérique/"humain").

Après avoir appris toutes ces options puissantes, tu te dis qu'évidemment uniq et comm vont accepter les mêmes options. Et bien non!

Donc après avoir conçu la commande sort, tu la fous à la poubelle, et tu construit un assemblage de commandes qui vont mettre l'entrée en un format simple que toutes ces commandes comprennent!
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 14:04:34
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.
Je ne vois pas l'intérêt de ce genre de comparaisons. Tu pourrais aussi bien dire Unix est nul, mais Winwin est pire. Bof bof.

Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
Avec des compilations conditionnelles, des variantes d'implèmentations (on compile un fichier différent selon le système), des couches d'abstraction, des contorsions... tu peux aussi faire des programmes complexes qui marchent aussi bien sous linux, *BSD, MacOS et Windows. C'est juste très très cher.

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Cela "marche", à un coût considérable!

IPv4 marche, aussi.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 14:29:43
[HS]
J'apprécie les vraies valeurs et  HAIR/MEPRISER ne font et ne feront, dans ce sens, jamais partie des verbes utilisés pour manifester les miennes.
(entre nous, s'il est question de pensée, tu devrais fortement t'inquiéter de l'état de la tienne pour en arriver à utiliser des verbes aussi forts que ceux-ci)

Puisque l'esprit semble corrompu, as-tu songé au corps par quelques activités défoulatoires ?
[/HS]
Je ne déteste que ceux qui donnent des conseils dans un domaine où ils sont notoirement incompétents, mais qui font croire qu'ils le sont, comme les économistes, les médecins, les climatologues, etc.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 14:46:23
Assistanat ça te va comme réponse.
Non, ça NE VA PAS!

Tu n'as pas l'air de comprendre que l'assistanat correspond à donner des trucs "gratuits" à des gens, en échange de rien du tout. Cette "gratuité" étant payée par l'ensemble de la communauté productrice de valeur. (Il y a aussi une communauté destructrice de valeur, dont le travail consiste à empêcher le travail de ceux qui produisent de la valeur.)

Le travail d'un logiciel n'est pas "gratuit", il est GRATUIT.
Titre: Avis de corrector sur Unix
Posté par: jack le 31 août 2016 à 14:52:55
Suis-je le seul à être importuné par ce genre de monologue absurde ?
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:08:18
Dis, tu es sérieux, là?

Tu suggères vraiment de faire une vérification avec stat suivi de open?
Tout le monde ou presque aura compris qu'entre le moment où tu fais stat (path) et open (path, options), ce que désigne path peut avoir changé.

Pour éviter ça, il faut faire un open sans ouverture de fichier.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:12:55
Ton aversion à Unix et consors semble principalement motivée par sa difficulté d'utilisation : on peut faire de l'informatique en mode "next/next" ou bien mettre les mains dans le cambouis, et c'est bien là l'essence même de ceux qui la pratique, non ?
Toute la nuance est là pour moi et c'est ce qui motive mes propos.
Après je cautionne complètement ce que tu dis mais je ne vois rien de comparable en terme d'outils/fonctionnalités dans les "autres types" d'OS.
Définis "cambouis".

En quoi le shell serait plus "le cambouis" que next/next?

Les deux sont d'un niveau stratosphérique par rapport au CPU.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:19:48
Je vomis Unix/linux et ses fanboys.
Je n'en attendais pas moins de toi.
Je ne pouvais pas me douter que ce vomi retomberait sur des forumeurs ici.

Je n'avais ABSOLUMENT AUCUN moyen de savoir qu'il y avait des fanboys ici, et non des utilisateurs avisés, méfiants et critiques.

De façon générale, je ne suis pas responsable du fait que mes critiques générales retombent sur des gens en particuliers. Ils n'ont qu'à pas être dans la cible!

Mes critiques ne sont dirigées vers aucune personne en particulier.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:22:42
Sinon moi j'aime bien OSX, et j'ai des espaces dans mes fichiers :p

/me sort
Est-ce que tu comprends le fonctionnement de OS X?

Est-ce que tu pourrais nous l'expliquer?
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:36:11
[Quels comportements sont implicites?]
Il y a énormèment de choses implicites en shell :

x=`echo "
"`

produit quoi? Est-ce évident?

Dans un répertoire vide :

touch 'x -i' '*'
rm *

fait quoi? Est-ce évident?

x='*'
ls $x

fait quoi? Est-ce évident?
Titre: Avis de corrector sur Unix
Posté par: mirtouf le 31 août 2016 à 15:41:59
(https://lut.im/mtHPUDLyWB/0GnfvfTsyKik7Ret.gif)
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 15:52:33
Mais j'ai à peine commencé!

Je n'ai même pas parlé des problèmes vraiment les plus sérieux!
Titre: Avis de corrector sur Unix
Posté par: alegui le 31 août 2016 à 16:19:13
Suis-je le seul à être importuné par ce genre de monologue absurde ?
Non, je le suis moi aussi, c'est dommage, j’apprenais des choses avec ce topic  :-\
Mais j'ai à peine commencé!
Ce serait gentil si tu pouvais écrire un seul message bien réfléchi et argumenté et de nous laisser le temps de répondre, ça créerait une discussion, une conversation, pas un monologue ! Un blog est plus adapté pour ça  ;) (et puis je crois que les gens sur ce forum ne sont pas si fermés que ça, ils leur faut juste des arguments)
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 16:31:36
Lequel de mes messages te semble mal réfléchi ou non argumenté?

Est-ce qu'au moins tu réalises que j'aborde de nombreux thèmes différents?

- utilitaires GNU (sort, comm)
- utilitaires POSIX (cp)
- /bin/sh
- sémantique de tous les shells (sauf zsh)
- makefile
- X Windows
- appels système Unix
etc.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 16:49:03
Est-ce qu'un modo veut bien mettre un gros coup de pied dans le derrière de corrector svp ?

Suis-je le seul à être importuné par ce genre de monologue absurde ?
1) Personne ne t'oblige à lire une discussion sur linux/Unix qui t'indispose - parce qu'elle montre des choses dérangeantes?
2) Si tu veux contre-argumenter, ce sera moins un "monologue".

Cela vaut POUR TOUT LE MONDE.

Je suis PARFAITEMENT dans la charte et pour une fois, je ne fais pas dévier le topic!!!
Titre: Avis de corrector sur Unix
Posté par: Jojo78 le 31 août 2016 à 16:54:43
Dommage, ça aurait pu être intéressant. Fil bon à mettre à la poubelle comme tant d'autres malheureusement.
Titre: Avis de corrector sur Unix
Posté par: zoc le 31 août 2016 à 16:55:38
pour une fois, je ne fais pas dévier le topic!!!
Bah si, le topic, c'est les 25 ans de Linux, pas un débat sur le fait que ce soit de la merde ou pas.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 16:59:29
Dommage, ça aurait pu être intéressant. Fil bon à mettre à la poubelle comme tant d'autres malheureusement.
Pourquoi, dommage? Quel est souci? Tu ne veux pas répondre aux messages argumentés que j'ai posté?

Pourquoi es-tu là, en fait?

Bah si, le topic, c'est les 25 ans de Linux, pas un débat sur le fait que ce soit de la merde ou pas.
Ah bon, donc on peut parler de quoi? Des dates? Du calendrier grégorien?

Est-ce que le souci n'est pas tout simplement que j'ai montré à certains forumeurs qu'ils n'avaient pas le niveau sur des sujets où ils étaient particulièrement bavards (coucou jack) et qu'ils me vouent une haine éternelle?
Titre: Avis de corrector sur Unix
Posté par: alegui le 31 août 2016 à 17:15:30
Lequel de mes messages te semble mal réfléchi ou non argumenté?
Par exemple,
Celui-ci (https://lafibre.info/logiciel/linux-fete-ses-25-ans/msg367126/#msg367126) est une attaque directe à une autre personne, non argumenté et qui n'apporte rien à la discussion.
Sinon, ce que l'on te reproche, c'est de ne ne pas synthétiser tes reproches dans un seul post clair et lisible au lieu de faire 10 posts imbuvables, ainsi que de faire des attaques personnelles, puis de se plaindre quand on n'argumente pas parce que ta prose est trop longue.

PS : si le hors-sujet ne pouvait pas trop se prolonger  ;)
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 17:16:11
Par exemple,
Celui-ci (https://lafibre.info/logiciel/linux-fete-ses-25-ans/msg367126/#msg367126) est une attaque
Perdu.

Merci d'avoir joué.

Sinon, ce que l'on te reproche, c'est de ne ne pas synthétiser tes reproches dans un seul post clair et lisible au lieu de faire 10 posts imbuvables, ainsi que de faire des attaques personnelles, puis de se plaindre quand on n'argumente pas parce que ta prose est trop longue.
En fait, le souci est que tu ne comprends RIEN de ce que j'explique.

Les messages sont argumentés, clairs et lisibles.

Tu n'argumentes pas parce que tu ne sais pas argumenter.
Titre: Avis de corrector sur Unix
Posté par: alegui le 31 août 2016 à 17:33:13
Les messages sont argumentés, clairs et lisibles.
Peut-être, à la limite ça m'est égal ce n'est pas le sujet de mon message, c'est plutôt qu’il faudrait que tu condenses tes multiples messages dans un seul beaucoup plus court, car on n'a pas forcèment besoin d'un dialogue de sourds. Si la longueur ne te suffit pas, tu peux toujours créer un blog où tu écriras les pavés que tu veux ;)

Par contre, si un modo pouvait déplacer tous les messages hors-sujet, ou les supprimer après que tous les intervenants importants les aient lu, ça permettrait de recentrer le topic sur le sujet, que je trouvais intéressant moi :'(

PS : et ce n'est pas une attaque personnelle, à mes débuts sur le forum je trouvais que pas mal de tes interventions étaient pertinentes
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 17:44:23
Peut-être, à la limite ça m'est égal ce n'est pas le sujet de mon message, c'est plutôt qu’il faudrait que tu condenses tes multiples messages dans un seul beaucoup plus court, car on n'a pas forcèment besoin d'un dialogue de sourds. Si la longueur ne te suffit pas, tu peux toujours créer un blog où tu écriras les pavés que tu veux ;)
Non, vraiment, je ne vois pas ce que tu reproches à mes messages. Je sais que parfois (souvent) je fais dériver les topics mais là on reste en plein dedans : les qualités et les défauts de Unix/linux.

Quand je critique quelque chose, c'est avec des arguments.

Et je critique beaucoup de choses différentes :
- fileutils GNU
- norme POSIX
- X Windows
- bash et co.

Quel intérêt de tout rassembler?

C'est un monologue parce que personne ne contre-argumente. Mais avoir un seul super-message interminable n'aiderait personne à contre-argumenter!!!!!

Vraiment je trouve que tu t'accroches aux branches.

Clairement, j'ai raison et les autres ont tort, point final.
Titre: Avis de corrector sur Unix
Posté par: butler_fr le 31 août 2016 à 17:58:55
Clairement, j'ai raison et les autres ont tort, point final.

ah oui vu comme ça on va aller loin...
Titre: Avis de corrector sur Unix
Posté par: PhilippeMarques le 31 août 2016 à 18:06:22
J'ai pas souvenir qu'ils prennent des abrutis à l'UPMC
Tu n'es pas manchot corrector,qu'est ce qui t'interdit de réécrire ce qui ne te plais pas ?
Tu aurais peut-être même ton nom dans une release note.
Cela aiderai tout le monde non ? Tu apporterai ta pierre à l'édifice,au lieu d'un débat stérile.

Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 18:13:23
Les comportements que je pointe ne sont pas (pour la plupart) des petits détails, ce sont des choix structurants.

Changer tout cela reviendrait à refaire un OS sur de nouvelles bases.

Remarque, certains essayent de totalement remplacer un composant traditionnel qui leur semble foireux. Par exemple, les gestionnaires de code sources traditionnels ont été remplacés, par mieux apparemment.

De même qu'un niveau d'Internet on essaye de remplacer IPv4 par IPv6, HTTP par HTTPS, etc.
Titre: Avis de corrector sur Unix
Posté par: alegui le 31 août 2016 à 18:20:43
Quel intérêt de tout rassembler?

C'est un monologue parce que personne ne contre-argumente. Mais avoir un seul super-message interminable n'aiderait personne à contre-argumenter!!!!!

Le but n'est pas de tout rassembler pour faire un post indigeste, mais de trier tes critiques pour ne garder que celles les plus intéressantes et renforcer ton argumentaire.

Pour faire un parallèle : pas besoin d'entrer dans les détails dans un réquisitoire de 3 pages, parce que personne ne te lira. Par contre, tu peux faire discrètement référence à un ouvrage complet en 5 tomes de 800 pages, qui détaille très précisèment ta pensée pour ceux qui sont motivés.

Les comportements que je pointe ne sont pas (pour la plupart) des petits détails, ce sont des choix structurants.

Changer tout cela reviendrait à refaire un OS sur de nouvelles bases.
Mais alors quel OS te plaît, et quelles sont les raisons pour cela?

------------------------------------------------------------------
Par contre, si un modo pouvait déplacer tous les messages hors-sujet, ou les supprimer après que tous les intervenants importants les aient lu, ça permettrait de recentrer le topic sur le sujet, que je trouvais intéressant moi :'(
Titre: Avis de corrector sur Unix
Posté par: PhilippeMarques le 31 août 2016 à 18:28:21
Il me semble que Linus était parti d'un constat similaire et allait à l'encontre d'Andrew Tanembaum et "minix" sur l'aspect monolithique du noyau et avait pris le parti de réécrire ce qui ne lui plaisait pas,tu as tous les outils à ta disposition pour réécrire ce que tu trouves bancal.
Tout est ouvert,cela ne tiens qu'à toi.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 18:42:52
Le but n'est pas de tout rassembler pour faire un post indigeste, mais de trier tes critiques pour ne garder que celles les plus intéressantes et renforcer ton argumentaire.
J'ai des tonnes de petites critiques, pas une grande critique philosophique.

Mais alors quel OS te plaît, et quelles sont les raisons pour cela?
LOL

Il n'y a vraiment aucun OS que me plaise. Mais j'avoue que je ne connais pas tellement d'OS foncièrement différents! (les nuances entre les *BSD, c'est de la br*lette)
Titre: Avis de corrector sur Unix
Posté par: Oxynux le 31 août 2016 à 18:55:54
Il n'y a vraiment aucun OS que me plaise. Mais j'avoue que je ne connais pas tellement d'OS foncièrement différents! (les nuances entre les *BSD, c'est de la br*lette)

Quel OS te déplaît le moins alors ?  ;D
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 19:06:17
Quel OS te déplaît le moins alors ?  ;D
Pour la programmation, linux.
Titre: Avis de corrector sur Unix
Posté par: seb le 31 août 2016 à 19:24:28
Je ne parlais pas de ça. Je parlais de la tradition Unix de merde, d'ailleurs tout le monde avait compris.
Vu qu'un autre intervenant t'avait répondu quelque chose de similaire, je pense que tu devrais commencer à te poser des questions sur ta capacité à exprimer ta pensée.

En séparant le fond de la forme généralement fielleuse dans laquelle tu le lies, je pense que ça irait déjà beaucoup mieux.

Citation de: corrector
Sinon tu pouvais aussi me répondre que le shell est de la merde mais que les gens dotés d'un peu de sens commun font leurs scripts en perl ou autre machin indépendant de l'OS.
J'avoue que j'y ai pensé.  :)

Mais si je te l'avais suggéré, tu m'aurais probablement rétorqué que sur les plus vieilles brouettes, tu pourras toujours te brosser pour trouver un interpréteur perl à disposition (installé, installable ou même compilable par tes soins si tu tiens vraiment à te faire mal).
Tu feras donc avec ce que tu trouves, et s'il n'y a que du shell de base, ainsi soit il.

Citation de: corrector
Si c'est pour avoir une merde préhistorique avec des bizarreries et des types incompatibles...
Tu voulais un comportement homogène, tu l'as.

Citation de: corrector
Et la variété des comportements de /bin/sh, c'est un avantage?
Si j'ai utilisé /bin/sh, c'est uniquement pour te montrer que le plus basique des shells n'a aucun problème à traiter le cas que tu as donné.
Dans la vraie vie j'ai plutôt tendance à utiliser quelque chose d'un poil plus évolué pour éviter ces différences.

Citation de: corrector
Mais tu n'as pas toujours le choix de ton shell de login.
Si, toujours, contrairement au fond d'écran quand tu n'es pas sur ta machine.
Un exec /chemin/vers/ton/shell/de/predilection dans ton .profile, et le tour est joué.
Je m'en suis servi plus d'une fois.

Citation de: corrector
Effort à la con, intellectualisme de merde.
L'effort que je fais pour te répondre en ce moment n'en vaut certainement pas la peine non plus, donc je vais m'arrêter là.

Dans ta logique, tout doit s'adapter à corrector, et corrector ne doit jamais avoir à s'adapter à rien.
Bon courage dans la vie.
Titre: Avis de corrector sur Unix
Posté par: eruditus le 31 août 2016 à 19:34:33
Moi, j'aime pas vi, ni ed.
Le reste on s'y fait ou on est obligé de s'y faire.
Titre: Avis de corrector sur Unix
Posté par: cali le 31 août 2016 à 19:37:39
Dans ta logique, tout doit s'adapter à corrector, et corrector ne doit jamais avoir à s'adapter à rien.
Bon courage dans la vie.

Sinon il peut aussi adapter les outils qu'il utilise, bon ça marche pas aussi bien quand on utilise du propriétaire...
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 19:42:58
Vu qu'un autre intervenant t'avait répondu quelque chose de similaire, je pense que tu devrais commencer à te poser des questions sur ta capacité à exprimer ta pensée.
Je ne vois VRAIMENT rien qui laisse penser que le problème vient de moi.

Si, toujours
Non, tu ne sais pas de quoi tu parles - une fois de plus.

Il y a de nombreux cas où un shell de login ne peut pas être modifié, dès que le /etc/passwd n'est pas accessible directement.

contrairement au fond d'écran quand tu n'es pas sur ta machine.
Un exec /chemin/vers/ton/shell/de/predilection dans ton .profile, et le tour est joué.
Ben non!

TCSH: Startup and shutdown (http://www.tcsh.org/tcsh.html/Startup_and_shutdown.html)
Citer
Startup and shutdown

A login shell begins by executing commands from the system files /etc/csh.cshrc and /etc/csh.login. It then executes commands from files in the user's home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) (+). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)
Aucune mention de .profile

Caramba, encore raté!

Dans ta logique, tout doit s'adapter à corrector, et corrector ne doit jamais avoir à s'adapter à rien.
Tout devrait s'adapter à l'utilisateur normal et non aux détraqués.

Bon courage dans la vie.
Merci.
Titre: Avis de corrector sur Unix
Posté par: PhilippeMarques le 31 août 2016 à 20:11:15
Moi, j'aime pas vi, ni ed.
Le reste on s'y fait ou on est obligé de s'y faire.
:/ed faut pas pousser non plus
yy
p
ed faut pas pousser non plus
:wq!
:D
Ensuite faut pas avoir honte de voir le regard des petits jeunes qui disent, "tu sais qu'ils ont inventé Word pour le traitement de texte ?"
Titre: Avis de corrector sur Unix
Posté par: Hugues le 31 août 2016 à 20:16:22
Est-ce que tu comprends le fonctionnement de OS X?

Est-ce que tu pourrais nous l'expliquer?


J'appuie sur le bouton de mon Mac Pro (c), et BOUM IL S'ALLUME

(http://i1.kym-cdn.com/photos/images/newsfeed/000/166/464/tumblr_lozdsb0bKx1qbnd1c.gif)
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 20:16:32
Rappel de l'historique du fils de la sous-discussion :

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
Si c'est pour avoir une merde préhistorique avec des bizarreries et des types incompatibles...
Tu voulais un comportement homogène, tu l'as.
Avec le compilateur pré-installé?

Justement je t'explique que c'est complètement aléatoire, imprévisible, NON homogène!!!

Je me demande si tu as une réelle expérience nix!

Si j'ai utilisé /bin/sh, c'est uniquement pour te montrer que le plus basique des shells n'a aucun problème à traiter le cas que tu as donné.
Dans la vraie vie j'ai plutôt tendance à utiliser quelque chose d'un poil plus évolué pour éviter ces différences.
Je ne dis que pas c'est insurmontable, je dis que c'est CHIANT et que c'est FACILE de ne pas écrire ça correctement.
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 20:19:01

J'appuie sur le bouton de mon Mac Pro (c), et BOUM IL S'ALLUME

(http://i1.kym-cdn.com/photos/images/newsfeed/000/166/464/tumblr_lozdsb0bKx1qbnd1c.gif)
J'espérais que tu nous raconterais comment fonctionne la sécurité par "application" sous OS X.

Mais lol, quoi!
Titre: Avis de corrector sur Unix
Posté par: Hugues le 31 août 2016 à 20:20:53
Ah le machin que j'ai désactivé des que je l'ai ouvert ?
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 21:17:14
/me épluche les 12000 derniers messages de corrector pour en trouver un qui est réfléchi ou argumenté.
P.ex. ces messages?

https://lafibre.info/tcpip/time_wait/msg322278/#msg322278
https://lafibre.info/cryptographie/http-strict-transport-security/msg220249/#msg220249
https://lafibre.info/cryptographie/securite-contre-lecoute-lors-de-la-connexion-lafibre-info/
Titre: Avis de corrector sur Unix
Posté par: vivien le 31 août 2016 à 21:19:44
Moi je sais comment fonctionne l'anti-virus sous OS X :

(https://lafibre.info/images/international/200706_anti-virus_belge.jpg)
Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 22:28:00
C'est le système de types de Caml!
Titre: Avis de corrector sur Unix
Posté par: seb le 31 août 2016 à 23:34:25
Non, tu ne sais pas de quoi tu parles - une fois de plus.

Il y a de nombreux cas où un shell de login ne peut pas être modifié, dès que le /etc/passwd n'est pas accessible directement.
Ben non!

TCSH: Startup and shutdown (http://www.tcsh.org/tcsh.html/Startup_and_shutdown.html)Aucune mention de .profile

Caramba, encore raté!
Comme je sais lire, je déduis de ces informations que c'est le fichier .login qu'il faut modifier dans ce cas.
Et surprise (mais en fait pas), ça fonctionne :
Citer
root@gaston:~# su - toto
gaston:~% echo "exec /bin/bash -l" > .login
gaston:~% logout
root@gaston:~# su - toto
toto@gaston:~$
C'est que je suis un véritable hacker, moi.

Il n'y a vraiment que dans le cas où l'administrateur aura explicitement cherché à interdire le shell que ça ne fonctionnera pas.
En somme l'exception qui confirmera la règle que tu peux changer de shell si tu le souhaites.

Titre: Avis de corrector sur Unix
Posté par: corrector le 31 août 2016 à 23:40:34
Mais tu ne vois pas quel est le souci quand on utilise open après access.
Titre: Avis de corrector sur Unix
Posté par: seb le 31 août 2016 à 23:55:39
Mais tu ne vois pas quel est le souci quand on utilise open après access.
Non, clairement pas.

Car si j'avais des fichiers qui changeaient de type en l'espace de quelques microsecondes je ne me dirais pas que l'appel open() est mal fichu, mais m'interrogerais plutôt sur la raison de ces changements, et sur l'opportunité de lancer des traitements sur des données aussi instables.

Citation de: corrector
Manque plein de choses (indication de la norme souhaitée, warnings, etc.)
On se fout pas mal de la qualité de mon code C ou des options de compilation, car elles n'étaient pas l'objet de ton "défi" :
Citation de: corrector
- merdicité extrême de make (je vous mets au défi d'écrire un makefile faisant correctement ce que fait automatiquement n'importe quel compilateur intégré à la base : recompiler ce qu'il faut recompiler - même avec les extensions GNU)
Le Makefile que j'ai pondu en deux minutes répond très exactement à ce cahier des charges.

Citation de: corrector
Donc il faut TOUJOURS penser à mettre des quotes autour d'un "paramètre", désolé je ne trouve pas ça naturel et complètement débile. Et en pratique il y a des scripts qui se chient dessus si un paramètre contient des espaces.
Naturel ou pas, protéger ses variables par des guillemets en shell, ça fait partie des bonnes pratiques.
Ceux qui ne suivent pas les bonnes pratiques d'un langage de programmation sont de mauvais développeurs, ce n'est pas plus compliqué que ça, et n'a rien à voir avec les qualités et défauts intrinsèques du langage de programmation concerné.

Citation de: corrector
Justement, la variante POSIX de la commande cp ne connait pas l'option -a, et donc la seule façon fiable de copier est tar ... | tar ....
Mais un cp -a n'est pas, et n'a jamais été, une façon fiable de copier un fichier !
À moins que tu considères que l'attribut atime d'un fichier n'ait aucune valeur.

Citation de: corrector
Est-ce que /dev/mem est un accès direct pour toi?
Xorg n'a plus accès à la mémoire du système au travers de cette interface, alors en quoi est-ce gênant ?

Citation de: corrector
Après avoir appris toutes ces options puissantes, tu te dis qu'évidemment uniq et comm vont accepter les mêmes options. Et bien non!
Je me dis surtout que je ne vois pas le rapport avec la choucroute :
Citation de: corrector
- utilitaires moisies qu'on n'arrive pas à combiner

Citation de: corrector
l y a énormèment de choses implicites en shell :

Tous tes exemples sont évidents pour moi, mais c'est peut être parce que j'ai appris à marcher (comprendre les bases du shell) avant d'essayer de courir (développer des scripts).
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 09:16:05
Car si j'avais des fichiers qui changeaient de type
Non, jamais. Un fichier peut changer de contenu, être tronqué, étendu, mais il ne change JAMAIS de type :

- un fichier régulier reste un fichier régulier
- un répertoire reste un répertoire
- une FIFO nommée reste une FIFO nommée
- une socket UNIX reste une socket UNIX (bon ce type-là, on peut pas le open de toute façon)
- un périphérique reste un périphérique (du même type, de mêmes numéros)

Par contre, un chemin (un nom) peut désigner une chose puis une autre.

En Unix tradi, tu as bien un moyen simple pour ouvrir un fichier uniquement si c'est un répertoire (l'option O_DIRECTORY) mais pas uniquement si c'est un fichier normal!!!

Et toi, tu trouves ça acceptable, parce que tu n'y comprends rien.

en l'espace de quelques microsecondes
Comment peux-tu garantir qu'il ne s'écoule pas plus longtemps?

Tu ne peux pas. La plupart du temps, il ne s'écoulera qu'un temps trivial. Parfois, le thread unique du processus sera suspendu, et il s'écoulera beaucoup plus de temps.

je ne me dirais pas que l'appel open() est mal fichu, mais m'interrogerais plutôt sur la raison de ces changements, et sur l'opportunité de lancer des traitements sur des données aussi instables.
Oui, parce que tu ne sais pas programmer.

Tu es parfaitement incompétent. Ce n'est pas une attaque, c'est un constat.

L'espace des noms de fichier est partagé, comme une variable globale. Les autres processus peuvent modifier les noms de fichiers à tout moment.

Tu peux croiser les doigts, mais tu n'as pas de garantie. Donc tu ne peux pas assurer la sécurité.

Mais tu ne comprends RIEN à la sécurité informatique, donc peu importe!

On se fout pas mal de la qualité de mon code C
Non. Ton code est incorrect et tu ne connais pas Unix, sinon tu saurais que tout processus a une valeur de retour. C'est un des premiers trucs qu'on apprend!

D'ailleurs make lui-même utilise cette valeur de retour : si elle est non nulle, il s'arrête parce que ça indique une erreur. Si tu ignores cela, c'est que tu ne connais pas le fonctionnement de make.

ou des options de compilation,
Tu méconnais l'importance des options parce que tu ne sais pas programmer.

Les bonnes options t'informent de ce genre d'erreur.

car elles n'étaient pas l'objet de ton "défi" :Le Makefile que j'ai pondu en deux minutes répond très exactement à ce cahier des charges.
Non. Déjà tu répliques dans un fichier externe les dépendances qui sont déjà indiquées dans le code source. Si tu trouve ça bien, tu ne comprends vraiment rien à la programmation et à l'informatique.

Si tu supprimes le #include dans le .c et le fichier .h, make va refuser de compiler ton programme.

Cela n'arrive pas dans un vrai environnement de programmation qui n'est pas cautionné par les gens ... comme toi.
Titre: Avis de corrector sur Unix
Posté par: BadMax le 01 septembre 2016 à 09:22:23
Tu chipotes : tu peux faire un void main() et sortir avec exit(valeur).

(relance la roue et part en courant)
Titre: Avis de corrector sur Unix
Posté par: eruditus le 01 septembre 2016 à 09:25:00
Tout à fait. Personnellement, je trouve cette méthode bien plus élégante. Et maintenant, on va laisser réfléchir corrector sur l'élégance de cette solution. :)
Titre: Avis de corrector sur Unix
Posté par: BadMax le 01 septembre 2016 à 09:26:31
:/ed faut pas pousser non plus
yy
p
ed faut pas pousser non plus
:wq!
:D
Ensuite faut pas avoir honte de voir le regard des petits jeunes qui disent, "tu sais qu'ils ont inventé Word pour le traitement de texte ?"

Tu leur répond qu'il y a Latex pour avoir un doc avec une vraie mise en forme.

#TeamVieux
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 09:32:41
Tu chipotes : tu peux faire un void main() et sortir avec exit(valeur).

(relance la roue et part en courant)
Et non, en tout pas de façon conforme :

Citer
5.1.2.2.1 Program startup

1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent;9) or in some other implementation-defined manner

ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)

Bien sûr, un compilateur peut définir d'autre prototypes autorisés, notamment en Unix, la forme à trois paramètres avec char **envp.
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 09:44:58
Naturel ou pas, protéger ses variables par des guillemets en shell, ça fait partie des bonnes pratiques.
Sauf dans le seul shell pas trop mal conçu (zsh).

Ne pas demander au programmeur ce genre d'attention permanente, ça fait partie des bonnes pratiques de conception d'un outil de programmation. Ce que tu ne peux pas savoir puisque tu ne sais pas programmer!

En plus, même avec les quotes, si tu utilises des utilitaires ordinaires prenant des noms de fichiers en ligne commande, tu vas avoir quelques difficultés avec les noms de fichiers commençant par "-". Le shell aura du mal à te protéger de ça, puisqu'il n'y a pas de convention universelle pour quoter "-" dans un argument en ligne de commande.

Ceux qui ne suivent pas les bonnes pratiques d'un langage de programmation sont de mauvais développeurs, ce n'est pas plus compliqué que ça, et n'a rien à voir avec les qualités et défauts intrinsèques du langage de programmation concerné.
C'est cela oui.

Si un outil demande une attention constante à des choses peu intuitives qui n'existent dans aucun langage de programmation normal... j'abandonne. Je pense que tu trolles.

Mais un cp -a n'est pas, et n'a jamais été, une façon fiable de copier un fichier !
Ah bon, alors quelle est la façon fiable de copier un fichier?

À moins que tu considères que l'attribut atime d'un fichier n'ait aucune valeur.
Bien évidemment.

Qui pense que l'attribut atime d'une copie d'un fichier n'a pas aucune valeur?

Xorg n'a plus accès à la mémoire du système au travers de cette interface, alors en quoi est-ce gênant ?
Tu me dis que si une pratique n'existe plus, ça n'a pas d'importance qu'on l'ait niée à l'époque?

Tu dis que maintenant Xorg ne peut plus attaquer le noyau?

Tu dis donc qu'il n'est plus nécessaire de désactiver Xorg pour la sécurité d'un système?
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 09:50:34
Tu leur répond qu'il y a Latex pour avoir un doc avec une vraie mise en forme.

#TeamVieux
Vous avez remarqué que les mathématiciens qui publient l'utilisent et que beaucoup de physiciens, non?

Cela ne vous pique pas parfois un peu les yeux?
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 10:08:51
Sinon il peut aussi adapter les outils qu'il utilise,
C'est un grand classique.

Tu peux dire quels outils open source tu as adapté, et ce que ça t'a coûté?

bon ça marche pas aussi bien quand on utilise du propriétaire...
Depuis la nuit des temps, le compilateur de MS, Visual C/C++ est distribué avec le code source des composants intégrales (bibliothèques ou DLL) qui appartiennent à MS et pour lequel MS a le droit de le distribuer, et le programmeur a le droit de faire toute modification.
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 10:24:43
Il me semble que Linus était parti d'un constat similaire et allait à l'encontre d'Andrew Tanembaum et "minix" sur l'aspect monolithique du noyau et avait pris le parti de réécrire ce qui ne lui plaisait pas,tu as tous les outils à ta disposition pour réécrire ce que tu trouves bancal.
Je pense que "monolithique" est un terme dans lequel chacun met ce qu'il vaut.

Pour certains, linux est "monolithique" parce que tout est dans un seul espace mémoire, contrairement à GNU Hurd. Mais linux est structuré en composants logiciels ayant des interfaces et des dépendances bien définies.

On peut aussi utiliser "monolithique" pour parler de compiler linux en intégrant le plus de modules possibles "en dur", et pas "en module" (à chargement dynamique).
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 10:28:26
Moi, j'aime pas vi, ni ed.
Le reste on s'y fait ou on est obligé de s'y faire.
Mais ce ne sont que des outils, tu n'es pas forcé de les utiliser (en principe).

Tu as le choix des outils, mais le système vient avec son architecture et ses composants de base. Les scripts de base du système GNU/linux sont écrits en bash, langage lourdingue comme toutes les variantes de sh.

Quasiment tout est ridiculement peu lisible en sh.
Titre: Avis de corrector sur Unix
Posté par: eruditus le 01 septembre 2016 à 10:32:44
Si si. Il existe des centaines de millieers (voir des millions) d'équipements dans le monde où seul vi ou ed est disponible, et où il est impossible de faire autrement que de les utiliser de temps à autre.
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 10:39:46
Et tu ne peux pas utiliser scp?
Titre: Avis de corrector sur Unix
Posté par: eruditus le 01 septembre 2016 à 10:59:03

Je ne dois pas écrire français
Citer
et où il est impossible de faire autrement que de les utiliser de temps à autre
Titre: Avis de corrector sur Unix
Posté par: jack le 01 septembre 2016 à 11:06:35
Citation de: corrector
Mais tu ne vois pas quel est le souci quand on utilise open après access.
Je vois le soucis : access ne sert à rien.
Si t'as les droits, alors le open va fonctionner.
Si tu n'as pas les droits, alors open va t'envoier chier.

Aucune plus value à faire un access avant.

Essaie et gère lorsque ta tentative échoue, plutôt que de tourner autour du pot.
Citer
Easier to ask for forgiveness than permission
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 11:13:31
Je vois le soucis : access ne sert à rien.
Si t'as les droits, alors le open va fonctionner.
Si tu n'as pas les droits, alors open va t'envoier chier.

Aucune plus value à faire un access avant.

Essaie et gère lorsque ta tentative échoue, plutôt que de tourner autour du pot.
Exactement!

Utiliser access, c'est :
- des lignes de code en plus
- un appel système en plus (donc un passage en mode noyau en plus)
- de la complexité sans aucun gain
- un risque d'oublier de vérifier le code d'erreur la seconde fois
- introduire un cas particulier qui ne sera jamais testé : si access dit OK mais que open indique une erreur de permissions

Et pourtant, en utilisant strace on voit BEAUCOUP d'appels à access.
Titre: Avis de corrector sur Unix
Posté par: jack le 01 septembre 2016 à 12:48:59
Si si. Il existe des centaines de millieers (voir des millions) d'équipements dans le monde où seul vi ou ed est disponible, et où il est impossible de faire autrement que de les utiliser de temps à autre.

Ça me fait penser à un HPC sous suse (pas opensuse), probablement en "mode recovery" ou autre (dunno sque c'est):
T'as pas vi
T'as pas nano
T'as pas emacs
T'as pas ed

Le seul truc pour éditer un fichier ... cat .....
Titre: Avis de corrector sur Unix
Posté par: PhilippeMarques le 01 septembre 2016 à 15:09:24
Ça me fait penser à un HPC sous suse (pas opensuse), probablement en "mode recovery" ou autre (dunno sque c'est):
T'as pas vi
T'as pas nano
T'as pas emacs
T'as pas ed

Le seul truc pour éditer un fichier ... cat .....

t'es pas dans la merde < cat >> systeme_a_la_con

#TeamVieux

Cela fais longtemps que j'ai pas regardé du C mais c'est comme le vélo.
seb : ton code "pourri";) il lui manque pas <stdio.h> ?
En retour de main, de mémoire, on est pas censé gérer un code d'erreur à renvoyer ?

Pour LaTex,si c'est la gente masculine,c'est pas un problème de répondre ça,cela se complique quand on répond  à la gente féminine.
Elle risqueraient d'y voir le synonyme de durex.

Tu veux un truc bien formé ? Utilise Latex
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 15:20:19
seb : ton code "pourri";) il lui manque pas <stdio.h> ?
seb@gaston:~/tmp$ cat hello.c
#include <stdio.h>
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 15:27:38
À moins que tu considères que l'attribut atime d'un fichier n'ait aucune valeur.
Non, il a une valeur négative!

Citer
From: Ingo Molnar [email blocked]
To:   Alan Cox [email blocked]
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date:   Sat, 4 Aug 2007 23:03:51 +0200


* Ingo Molnar [email blocked] wrote:

> noatime,nodiratime gave 50% of wall-clock kernel rpm build performance
> improvement for Dave Jones, on a beefy box. Unless i misunderstood
> what you meant under 'fraction of a percent' your numbers are _WAY_
> off. Atime updates are a _huge everyday deal_, from laptops to
> servers. Everywhere on the planet. Give me a Linux desktop anywhere
> and i can tell you whether it has atimes on or off, just by clicking
> around and using apps (without looking at the mount options). That's
> how i notice it that i forgot to turn off atime on any newly installed
> system - the system has weird desktop lags and unnecessary disk
> trashing.

i cannot over-emphasise how much of a deal it is in practice. Atime
updates are by far the biggest IO performance deficiency that Linux has
today. Getting rid of atime updates would give us more everyday Linux
performance than all the pagecache speedups of the past 10 years,
_combined_.


it's also perhaps the most stupid Unix design idea of all times. Unix is
really nice and well done, but think about this a bit:

   ' For every file that is read from the disk, lets do a ... write to
     the disk! And, for every file that is already cached and which we
     read from the cache ... do a write to the disk! '

tell that concept to any rookie programmer who knows nothing about
kernels and the answer will be: 'huh, what? That's gross!'. And Linux
does this unconditionally for everything, and no, it's not only done on
some high-security servers that need all sorts of auditing enabled that
logs every file read - no, it's done by 99% of the Linux desktops and
servers. For the sake of some lazy mailers that could now be using
inotify, and for the sake of ... nothing much, really - forensics
software perhaps.

   Ingo

http://kerneltrap.org/node/14148
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 16:02:11
J'ai trouvé 16 exécutables avec le bit SUID positionné sur ma machine (sur un total de 2426 exécutables).
Parce que tu crois sérieusement qu'on peut estimer la surface d'exposition au nombre d'exécutables?

MDR

Ce n'est donc pas comme si cette problématique de sécurité, par ailleurs largement documentée, concernait le premier développeur venu.
Les autres savent normalement comment gérer l'affaire au niveau de leur code.
Je ne sais pas si tu te rends compte du contrôle sur l'environnement qu'a celui qui lance le processus.

Cela m'étonnerait vu que tu ne comprends pas des choses bien plus simples.
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 17:13:16
Parce qu'un machin comme linux est très complexe et qu'il y a très régulièrement des failles.

Et là tu as l'air malin avec tes "politiques" SElinux que tu as mis des heures à définir finement, puisque tout est contourné.
Titre: Avis de corrector sur Unix
Posté par: cali le 01 septembre 2016 à 18:16:47
C'est un grand classique.

Tu peux dire quels outils open source tu as adapté, et ce que ça t'a coûté?

Du noyau à mon client mail, quand un truc me déplaît ou qu'il manque quelque chose, je rajoute/modifie. Il y a même des gens qui me donnent des sous parfois pour que je le fasse pour eux. Il se passe rarement une journée sans que je touche à quelque chose.
Titre: Avis de corrector sur Unix
Posté par: corrector le 01 septembre 2016 à 18:21:14
Je crois que très peu de gens font ça.

Même quand ils trouvent un bug assez gênant et assez simple, ils attendent qu'il soit corrigé!
Titre: Avis de corrector sur Unix
Posté par: vivien le 02 septembre 2016 à 22:08:46
Hors sujet déplacé : Linux (et tout les autres OS) c'est *bientôt* du passé (https://lafibre.info/serveur-linux/linux-et-tout-les-autres-os-cest-bientot-du-passe/)