Michaël a écrit 2935 commentaires

Open Source : Ce terme est celui favorisé par l'OSI (forcément, c'est marqué dessus). Avantage : Pas d'ambigüité libre/gratuit. Inconvénient : De nombreuses boites s’engouffrent dans la brèche et utilisent ce terme à tort et à travers pour labelliser en tant que "logiciel open source" des logiciels qui ne répondent pas aux critères de l'Open Source selon la définition de l'OSI ni ceux du Logiciel Libre selon la définition de la FSF.

Si je me souviens bien, un des plus importants (en termes de visibilité et d'ancienneté) exemples de cette confusion vient d'un vendeur de système d'exploitation qui avait publié les sources de son OS sans pour autant le libérer. Le source était fourni, par exemple au titre de documentation, et le vendeur avait estampillé son logiciel open source ce qui en soi ne va pas à l'encontre du bon sens (mais bel et bien de l'usage normal de l'expression). Et je ne crois pas dire de bêtise en disant qu'il s'agit de Sun avec une version de Solaris, mais peut-être que vous voudrez me corriger.

Après je suis aussi d'accord que la philosophie UNIX en prend pour son grade mais bon... est-ce si dramatique ?

Oui c'est dramatique, parcequ'au delà d'une philosophie c'est une méthodologie de travail et en dévier induit une baisse temporaire de productivité (il faut apprendre des procédés complètement nouveaux) ce qui n'est rentable que sur le long terme et que si la productivité du nouveau système est supérieure à celle de l'ancien.

(même si les scripts apportent une souplesse qu’une syntaxe de configuration à base de clefs et de valeurs ne peut à mon avis pas égaler).

C'est sûr! Essentiellement la configuration des init dans FreeBSD est a base de clefs/valeurs (rc.conf) et on a la souplesse des scripts shell — puisqu'il s'agit de script shells!

Mais vouloir faire du remplaçant d’init un super programme se chargeant d’à peu près tout, […] sans même me référer à la « philosophie UNIX » et au principe du un-programme-pour-chaque-tâche j’ai du mal à voir ça comme une bonne idée.

Si on travaille pour entreprise qui vend du support pour les logiciels qu'on fabrique, alors l'idée deveint bien plus intére$$ante.

Et puis quand on compare, par exemple, le script pour openssh sous Slackware (rc.sshd) et pour systemd (sshd.service) force est de reconnaître que le second est malgré tout plus court et plus explicite.

Je préfère comparer le script pour openssh sous FreeBSD et sous systemd:

#!/bin/sh
#
# $FreeBSD: src/etc/rc.d/sshd,v 1.14.2.1 2009/08/03 08:13:06 kensmith Exp $
#

# PROVIDE: sshd
# REQUIRE: LOGIN cleanvar
# KEYWORD: shutdown

. /etc/rc.subr

name="sshd"
rcvar=`set_rcvar`
command="/usr/sbin/${name}"
keygen_cmd="sshd_keygen"
start_precmd="sshd_precmd"
pidfile="/var/run/${name}.pid"
extra_commands="keygen reload"

timeout=300

user_reseed()
{
        (
        seeded=`sysctl -n kern.random.sys.seeded 2>/dev/null`
        if [ "x${seeded}" != "x" ] && [ ${seeded} -eq 0 ] ; then
                warn "Setting entropy source to blocking mode."
                echo "===================================================="
                echo "Type a full screenful of random junk to unblock"
                echo "it and remember to finish with <enter>. This will"
                echo "timeout in ${timeout} seconds, but waiting for"
                echo "the timeout without typing junk may make the"
                echo "entropy source deliver predictable output."
                echo ""
                echo "Just hit <enter> for fast+insecure startup."
                echo "===================================================="
                sysctl kern.random.sys.seeded=0 2>/dev/null
                read -t ${timeout} junk
                echo "${junk}" `sysctl -a` `date` > /dev/random
        fi
        )
}

sshd_keygen()
{
        (
        umask 022

        # Can't do anything if ssh is not installed
        [ -x /usr/bin/ssh-keygen ] || {
                warn "/usr/bin/ssh-keygen does not exist."
                return 1
        }

        if [ -f /etc/ssh/ssh_host_key ]; then
                echo "You already have an RSA host key" \
                    "in /etc/ssh/ssh_host_key"
                echo "Skipping protocol version 1 RSA Key Generation"
        else
                /usr/bin/ssh-keygen -t rsa1 -b 1024 \
                    -f /etc/ssh/ssh_host_key -N ''
        fi

        if [ -f /etc/ssh/ssh_host_dsa_key ]; then
                echo "You already have a DSA host key" \
                    "in /etc/ssh/ssh_host_dsa_key"
                echo "Skipping protocol version 2 DSA Key Generation"
        else
                /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
        fi
        if [ -f /etc/ssh/ssh_host_rsa_key ]; then
                echo "You already have a RSA host key" \
                    "in /etc/ssh/ssh_host_rsa_key"
                echo "Skipping protocol version 2 RSA Key Generation"
        else
                /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
        fi
        )
}

sshd_precmd()
{
        if [ ! -f /etc/ssh/ssh_host_key -o \
            ! -f /etc/ssh/ssh_host_dsa_key -o \
            ! -f /etc/ssh/ssh_host_rsa_key ]; then
                user_reseed
                run_rc_command keygen
        fi
}

load_rc_config $name
run_rc_command "$1"

Le script sous FreeBSD est beacuoup plus long, mais il fait beraucoup plus de choses! Il s'occupe de générer la clef du serveur, lorsque ceci est nécessaire. Ce processus mis à part le script est

#!/bin/sh
#
# $FreeBSD: src/etc/rc.d/sshd,v 1.14.2.1 2009/08/03 08:13:06 kensmith Exp $
#

# PROVIDE: sshd
# REQUIRE: LOGIN cleanvar
# KEYWORD: shutdown

. /etc/rc.subr

name="sshd"
rcvar=`set_rcvar`
command="/usr/sbin/${name}"
pidfile="/var/run/${name}.pid"
extra_commands="reload"

load_rc_config $name
run_rc_command "$1"

Le progrès introduit par systemd en termes de clarté et de briéveté n'est pas si clair…

En fait le système à la BSD permet de regrouper les ordres de haut niveau pour commander un serveur dans un endroit bien défini, et a pour second avantage de fournir un cadre commun pour la configuration des serveurs. Voir les pages de man de rc.conf et rc.subr.

J'ai lu la moitié des commentaires et c'est simplement consternant.

Il ne faillait pas que tu te concentres sur les commentaires avec un score négatif. ;)

Le logiciel LIBRE n'a pas à être coincé dans l'API UNIX à jamais.

Plus qu'une API dont on serait prisonnier ou non, UNIX est une philosophie et une méthodologie de travail éprouvée dont trois principes fondamentaux sont:

1. On crée des processus complexes en composant grâce au shell des processus simples.
2. Les processus simples ont une fonction bien définie et opèrent sur un type général de données, en l'occurence les fichiers textes.
3. Les processus complexes s'interfacent facilement avec le shell.

Si on crée un outil qui respecte ces trois points, alors tout utilisateur UNIX expérimenté pourra l'utiliser de façon optimale en très peu de temps, car il dispose déjà de toute la méthodologie: en clair il n'a qu'à apprendre ce qui est propre à l'application mais sait comment manipuler les données qu'elle va lui fournir. Tandis que si un outil ne respecte pas ces points, alors outre ce qui est propre à l'application, il faut apprendre de nouveaux protocoles et de nouveaux outils pour utiliser les données de l'application. Si tant est que ces outils existent…

Ses paires approuvent (ou pas), et participent (ou pas).

Il y a un e de trop dans cette phrase, qui devient fort amusante!

Je vois ici principalement de la jalousie crasse.

Oui sûrement…

> Je ne peux pas laisser dire ça. Sur un réseau local
Forcément, si tu te place dans un cas particulier...

Vu qu'on parle grosso-modo de débit de données, le type de réseau n'est peut-être pas un paramètre à omettre non?

> lorsque les très très hauts débits se populariseront X sera l'objet d'un regain d'intérêt
Ha ok. Donc en fait, il faut attendre que les connexion s'améliorent pour que X devienne intéressant... mouai

Tu veux dire que tu devras atteindre que les connexions s'améliorent pour que X devienne intéressant pour toi. C'est déjà intéressant pour ceux qui travaillent en réseau local. Ensuite il y a déjà des endroits où on a des très hauts débits, et j'ai déjà travaillé de longues heures en session distante sur des machines séparées de 500, 600km sans que la latence ne soit véritablement gênante (pourtant, je suis chatouilleux). Ensuite je rappelle que l'asymétrie des débits de communication est un artéfact introduit par les fournisseurs qui n'a pas de raison technique: si cette asymétrie disparaissait, on aurait de bien meilleurs performances.

Quels genres de programmes utilises-tu en connexion X déportée?

de connecter un bureau distant :
Avec une latence énorme compte tenu de la quantité de données qui transitent. On se retrouve très facilement avec des temps de réponse supérieurs à la seconde. Alors qu'un logiciel bien conçu doit pouvoir être utilisé plus rapidement en console ( via ssh par exemple ).

Je ne peux pas laisser dire ça. Sur un réseau local, il n'y a pas de temps de latence et c'est probablement un des cas d'utilisation les plus importants. Sur les réseaux non locaux les débits montants des particuliers sont certes limitants pour la communication, mais si tu as une connexion non bridée, cela marche tout de suite mieux (en fait très bien). De plus quelques astuces permettent de réduire la quantité de données transitant, notamment abaisser la profondeur (bits/couleur) de l'affichage et utiliser un toolkit bien carré et sans dégradé.

Au contraire, je pense que lorsque les très très hauts débits se populariseront X sera l'objet d'un regain d'intérêt puisqu'après tout pour tout avoir «dans le cloud» il suffit de transformer sa machine locale en terminal X.

Maintenant, tu me dis qu'il faut faire tourner X pour avoir une ligne de commande fonctionnelle...

Ce que je te dis c'est que:
- Soit tu ne fais pas tourner de serveur X et tu te contentes d'une console qui n'a pas la fonctionnalités que tu veux.
- Soit tu fais tourner un serveur X et tu as une console avec les fonctionnalités que tu veux.

Donc que tu dois faire tourner X pour avoir les fonctionnalités que tu veux. Quelle est la machine sur laquelle tu rechignes à faire tourner X? J'ai vraiment l'impression que ta position tient plus du caprice et du parti pris que d'un problème sérieux.

Je regrette [...] que l'architecture de nos systèmes ressemble de plus en plus à des oignons qui empilent couches sur couches.

Si je comprends bien le problème pour la réalisation d'une console UTF8, c'est que le hardware a des fontes de caractères avec 256 positions. Si tu veux afficher plus de 256 caractères différents (i.e. proposer un support crédible de UTF-8), il faut utiliser un mode graphique, autrement dit introduire une couche supplémentaire si j'ai bien compris ce qui te chagrine.

Super merci!

Le fait que le format des messages soit tout à fait libre et sans conventions rend le parsing impossible.

Ça n'a aucune importance: chaque log doit être analysé selon l'application qui l'a généré. Quelque soit le système que tu utilises, tu ne peux pas utiliser le même outil pour analyser les logs de SUDO, de ton serveur MAIL, de ton serveur HTPP, SMTP, ou FTP, tout simplement parceque ce sont des applications complètement différentes. Le fait de créer un format commun pour les parser n'a pas de gros intérêt parceque de toutes façons l'analyse des contenus doit dépendre de l'application. L'idéal serait que chaque application écrivant des LOGs fournissent aussi un parser pour ses logs. En l'absence de tel parser on survit bien en utilisant les outils UNIX habituels. Utiliser un format structuré complexe nécessiterait donc d'avoir des équivalents de SED, AWK, PERL, SORT, CUT, PASTE, JOIN etc., etc. capables de travailler directement sur ce format, sinon on se retrouve avec une perte de fonctionnalité et une plus grande complexité à l'analyse des fichiers: avantage 0, inconvénients ÉNORMES.

La lecture des fichiers log est totalement inefficace, il est impossible d'accéder rapidement au 100e message par exemple, ou d'avoir les messages à un moment donné.

C'est complètement impertinent. Ce qui t'intéresse quand tu lis des logs c'est de lire tous les LOGS et de les filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée. Le numéro de ligne est un atefact qui ne sert à rien.

Les logs prennent vraiment énormément de place. Un petit problème dans postfix (genre un relai défaillant) et on se retrouve vite avec un fichier log de 1GO juste avec les essais ratés de transmission.

Le bonne solution à ce problème est d'embaucher un vrai admin système.

La solution existante (SYSLOG) est bien dans l'esprit de UNIX: un système ultra simple que tu peux étendre comme tu veux. Par exemple, tu peux déporter les logs sur un PIPE nommé pour les faire traiter par le programme que tu veux et qui peux te remplir toutes les tables SQL que tu veux.

On peut, par configuration et avec l'aide de logrotate, forcer une rotation quand un fichier dépasse une certaine taille.

Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.

Par ailleurs, je ne comprends pas non plus pourquoi il développe ça dans le cadre de systemd, plutôt que de faire un projet séparé. Pour minimiser la maintenance peut-être ?

À mon avis c'est plutôt parcequ'il ne comprend rien à UNIX.

La consommation mémoire

C'est certain mais est-ce vraiment un facteur limitant sur une station de travail? Même mon AM2 K6 et ses 4Mo en acheté en 1999.

(et, mais je ne suis pas sûr que ça s'applique, le trafic réseau ssh simple vs. X déporté).

Il suffit de se logguer depuis un terminal X pour économiser le déport de connexion X.

Les espaces fine insécable posent des problèmes d'affichage pour iOS, Android et Windows XP, ce qui fait que j'y suis plutôt opposé car cela rend la lecture sur ces plate-formes très difficile.

J'ignorais ces problèmes. Pour ma part je n'utilise jamais ces espaces directement car d'après moi ils devraient être insérés automatiquement par les logiciels.

Je m'attendais à une interview plus dense.

S'il fallait comparer „Die Zeit” à un journal français ce serait certainement «Le Monde» et, tout quotidien national confondu, je ne crois pas qu'on ait en France droit à des interviews aussi intéressantes, tout en restant dans le domaine de travail d'un quotidien national.

Par rapport au texte que j'ai soumis, outre une meilleure présentation pour laquelle je ne peux que remercier les modérateurs, il y a quelques différences qui n'auraient pas dû être introduites en l'état car elles transforment le contenu du texte. J'ai obtenu le droit de présenter une traduction, mais pas de transformer le contnenu à ma guise.

La première phrase de l'interview ne présente pas Linus Torvalds comme le créateur du noyau Linux, cœur du système d’exploitation libre GNU/Linux mais comme le créateur du système d'exploitation libre (l'article défini renvoie à Linux, utilisé dans le titre). Il faudrait revenir sur ce changement: si la confusion entre le système d'exploitation et son noyau entretenue par l'article est insupporable, les modérateurs peuvent insérer une «note des modérateurs» (entre crochets).

Ensuite un intertitre a disparu, dont le contenu est «les gens ne s'intéressent pas pour les ordinateurs en tant que tels» et qui apparaissait après l'énumération des trois chemins.

Pour respecter l'accord que m'ont très gentiment donné l'auteur de l'interview et le journal l'ayant publiée, il faudrait revenir sur ces deux modifications.

Les modifications de présentation sont plutôt pas mal, et j'adresse mes remerciements au modérateur pour ce travail, cependant il reste quelques problèmes.

1. Les espaces ajoutées avant les signes de ponctuations !? ne sont pas les bonnes: il faut mettre des espaces fines, c'est à dire U+202F NARROW NO-BREAK SPACE. Dans mon navigateur on ne fait aucune différence visuelle (l'espace a la même taille qu'une espace normale alors qu'elle devrait en faire le tiers) mais quitte à corriger autant que la correction rende le texte juste au lieu de transformer un texte faux en texte faux.

2. Dans une énumération on introduit plutôt les éléments par un tiret cadratin — que par une pastille à l'américaine.

3. Dans une énumération, si les termes de l'énumération sont des phrases, on peut très bien les commencer par une majuscule et les finir par des points. Dans le cas particulier qui nous intéresse comme le deuxième et troisième terme de l'énumération sont formés de plusieurs phrases je trouve la solution pas de majsucule et fin par un point-virgule plutôt malheureuse.

Pour ça mes références sont:

1. http://unicode.org/udhr/n/notes_fra.html

2. Jean-Pierre Lacroux, Orthotypographie. Orthographe & typographie française. Dictionnaire raisonné.

3. Jacques André, Petites leçons de typographie, août 2008, 52 p.

3: troll console - xterm sous X en mode vesa.

Ce n'est pas un troll: si tu veux utiliser une console Unicode c'est une solution à considérer. Je ne vois pas trop l'avantage de la console: même si je l'utilise parfois, je ne crois pas qu'il y ait quoique ce soit qu'elle fasse mieux qu'un terminal X ou rxvt, ou ce qu'on veux. Par conséquent si le support Unicode de la console est important pour ton travail, je ne vois pas trop ce qui te retiens d'utiliser les émulateurs de terminaux X11.

J'ai mentionné le mode VESA pour indiquer que cette solution est toujours disponible, même pour les cartes graphiques mal supportées par X11.

Concernant la coloration syntaxique avec vim, je savais qu'il fallait chercher du côté de la variable TERM. Je me suis donc plongé dans les archives de la liste de discussion, pour finalement trouver une obscure variable non documentée: export TERM=wsvt25.

Comme cette affirmation me paraît un peu grosse, je tente le Google avec un combo magique:

netbsd console color

Chez moi le premier résultat est

http://www.netbsd.org/docs/guide/en/chap-cons.html

et après un bref survol des titres on trouve un paragraphe

8.1.1.5.2. Getting applications to use colors on the console

qui donne l'incantation mystérieuse dont tu parles. Tu remarqueras que je n'ai même pas triché en utilisant des connaissances spéciales (du type ajouter TERM dans ma requête).

Ce n'est pas vraiment ma conception de «variable obscure et pas documentée».

des hacks plutôt que des solutions, et des arguments pour dire qu'il n'est pas nécessaire d'avoir des solutions.

Si ces gens disent que le support de l'UTF-8 dans la console n'est pas prioritaire parcequ'il est très bien supporté sous X et que tu peux lancer un serveur X en mode VESA avec un XTerm en plein écran pour travailler «en mode console» et bien je ne vais pas pouvoir de m'empêcher de penser qu'ils ont raison et que le support de l'UTF-8 dans la console est loin d'être la chose la plus urgente à changer.

Ceci dit, j'ai quand-même payé mon coup de Google:

utf8 console netbsd

et je tombe, en premier choix sur

http://wiki-static.aydogan.net/Unicode

qui donne les informations ou les références pertinentes.

quel intérêt d'avoir les sources ? Pour se faire mousser ?

Les sources permettent plusieurs choses:
- pallier une documentation floue, en levant l'ambigüité à la racine;
- illustrer l'utilisation de certaines fonction ou bibliothèques;
- mieux comprendre l'organisation d'un logiciel.

Cela étant dit, il est tout-à-fait possible de revendre tel quel son code GPL, gagner de l'argent dessus, et ne rien lui rendre. Faut juste trouver un acheteur un peu con...

Si c'est son code GPL il peut le revendre sous une autre licence à une acheteur pas forcément si con que ça.

Ou alors il y a un moyen de tagger dans un mailer linux?

Dans Seamonkey tu as 5 tags prédéfinis (Important, Work, Personal, TODO, Later) et tu peux en ajouter à l'envi. Les neuf premiers tags peuvent être positionnés par les touches 1-9, la touche 0 efface les tags d'une mail. Ces tags peuvent faire l'objet d'un test dans une recherche. Je rappelle que Seamonkey permet de sauvegarder une recherche comme un dossier (les dossiers soi-disant intelligents).

Je suppsoe que Thunderbird fait la même chose et dispose de quelques fonctions supplémentaires peut-être un peu amusantes (du genre affichage des histogrammes).

PANPAN

Pas vraiment, c'est canvas travaille uniquement au niveau pixel. Une fois que ta demande est fait, ils n'ont plus aucune idee de ce que tu leur as demande, une image, une ligne, du texte.

Et bien non, justement: c'est le contraire de ce que tu dis que j'ai écrit et je ne me uis pas trompé. En Tk on utilise la méthode create du canvas pour créer des objets:

pathName create type coordList ?option value ...?
Create a new item in pathName of type type. The exact format of the arguments after type depends on type, but >usually they consist of the coordinates for one or more points, followed by specifications for zero or more item >options. See the subsections on individual item types below for more on the syntax of this command. This command returns >the id for the new item.

Comm indiqué par la doc cette opération retourne un id qui peut être utilisée pour manipuler ultérieurement les objets crées, ce qui vu de chez moi ne ressemble pas trop à un oubli. Dans Gtk, GnomeCanvas offre exactement le même fonctionnement et ça m'étonnerait bien que Qt ne propose pas un mécanismen analogue.

Le canvas est stateful, le mieux pour comprendre l'intérêt est de lire leur tutoriel (en gros si on dessine un rectangle et qu'on veut le faire bouger, au lieur d'effacer le canvas et en redessiner un autre comme on ferait dans la plupart des toolkits, on lui dit juste de se déplacer.

C'est aussi le cas des deux toolkits que j'ai programmés, à savoir Tk (widget canvas) et Gtk (widget GnomeCanvas). Cela m'étonnerait bien que Qt ne propose pas un widget analogue. Il se pourrait que la première apparition de ce type de widget soit dans Tk.

et gpanpan

Il n'est même pas mention de réseau, puisqu'il veut partager des fichiers entre utilisateurs sur le même serveur.

C'est pour ça qu'une solution basée sur les permissions UNIX habituelles (ugo) me semble préférable à une solution basée sur un service réseau.

J'ai un peu du mal à voir à quoi doit ressembler le document final… le but est d'avoir un texte aligné à gauche avec certaines lignes habillées par une accolade et marquées d'un renvoi, ansi que des indications de texte à droite des lignes concernées (les ffx-v etc.). J'ai bon?

Un point désagréable est que le trait des accolades a une épaisseur différente selon sa hauteur (il y a, de mémoire trois épaisseurs possibles), donc même en avançant un peu dans la bonne direction, cela ne va pas être évident. Le meilleur conseil que je peux te donner est de poser ta question sur le newsgroup comp.text.tex (anglophone).