En effet, c'est pro-git. Tellement que c'en devient presque de la mauvaise foi. :-)
Et le "gros argumentaire" inverse : Why Git Ain’t Better Than X, rédigé du point de vue d'un afficionados de Bazaar.
Et enfin un argumentaire qui calme les choses : Git vs. Mercurial: Please Relax. Celui-ci est un peu en retard, notamment parce que git n'est plus une multitude de petits binaires comme au début, mais les arguments n'en sont pas moins toujours valables.
Avec Mercurial, il y a aussi l'action rebase, même si je ne l'utilise pas.
J'ai plutôt tendance à utiliser des MQs, voire aussi à les versionner elle-mêmes.
Qu'est-ce que les MQs ? C'est une série de patchs que tu peux empiler (qpush) et dépiler (qpop), les réordonner, le tout à volonté. Il y a d'autre possibilités, mais ceci est la base.
Quand je travaille sur une fonctionnalité ou une correction de bug, je commence toujours une MQ. Par exemple, je décide d'ajouter une nouvelle fonction, et de l'utiliser un peu partout pour mutualiser le code :
créer une MQ (automatiquement) et un premier patch
hg qnew add-new-function
ajouter de la nouvelle fonction
créer un second patch
hg qrefresh && hg qnew use-new-function
modifier le code pour appeler la nouvelle fonction
s'apercevoir que l'API a un manque
dépiler au premier patch
hg qrefresh && hg qpop
changer la fonction
empiler au patch suivant
hg qrefresh && hg qpush
modifier le code
s'apercevoir d'un bug dans la fonction
dépiler au premier patch
hg qrefresh && hg qpop
corriger la fonction
empiler au patch suivant
hg qrefresh && hg qpush
tester, ça marche
hg qfinish
Et voilà. Et on peut aussi versionner les MQs, qui du coup se trouvent être un repository Mercurial à part entière, donc on peut le clonner, le pusher et le puller. Si je fais une MQ sur une machine A, et que je veux l'utiliser sur une machiune B , je peux, au choix :
la cloner depuis la machine B via ssh vers la machine A
la pusher depuis la machine A vers un repository en ligne, et ensuite la cloner sur la machine B
clonner la MQ sur une clé USB sur la machine A, transférer la clé vers la machine B, et cloner la MQ depuis la clé USB sur la machine B
J'utilise le plus souvent 1. et 2. Par exemple, pour le projet que je maintein et développe :
Ça fait aussi un espèce de rebase, si on veut. Alors oui, il y a certains petits manques par rapport à git. Par exemple, si un patch est déjà appliqué, qpush ne s'en aperçoit pas. C'est pas très grave, un qdelete fait l'affaire.
Franchement, ce sont pour moi devenues des opérations triviales^Wbanales.
J'utilise Mercurial pour gérer mon ${HOME}, pour gérer mes scripts de déploiement de machines virtuelles, etc...
D'accord, peut-être que ça ne passe pas à l'échelle comme pour le noyau Linux, quoique de très gros projets sont gérés avec brio sous Mercurial.
je pense à la batterie intégrée au contrôleur par exemple.
Euh, elle peut servir à quoi ? (C’est une vraie question.)
Les contrôleurs RAID matériels ont une grosse quantité de RAM qui sert de cache :
optimiser la lecture en gardant les blocs les plus lus
optimiser les écritures en ré-ordonnant les accès
Dans le cas de l'écriture différée, l'OS croit avoir écrit sur le disque, alors que le contrôleur le garde en mémoire. La batterie va permettre au contrôleur RAID de terminer l'écriture des blocs en l'air et ainsi garantir l'intégrité des données : ce que l'OS croit avoir écrit, bin en fait, c'est réellement écrit !
Dans des cas extrêmes, ca permet même de garantir le maintien du cache de lecture pour avoir un boot plus rapide. Mais là, on atteint des sommets... en coût du contrôleur, pour un gain discutable...
Si je passe à Mercurial, est-ce uniquement de la branlette cérébrale, où puis-je y voir d'autres intérêts par rapport à SubVersion ?
Le "merge". Dans Subversion, j'ai toujours eu des embêtements de merge. Avec Mercurial, jamais. Des conflits, certes, mais pas d'embêtement. Par exemple, dans Subversion, les "tree conflicts", c'est une catastrophe à résoudre. Dans Mercurial, il n'y a même pas besoin de cette notion. Pareil pour git.
Est-ce que Git est mieux que Mercurial [...] ?
En venant de Subversion, Mercurial est plus évident que git, j'ai trouvé.
Certes, git c'est "le bien pasque c'est Linus qui l'a fait et qu'on utilise ça pour le noyau". git est puissant. Vraiment très puissant. Mais la gestion au quotidien est d'une complexité effrayante. Même si ça s'est amélioré au fil du temps, git reste vraiment un outil pour "power-user", alors que Mercurial est facile d'accès.
Après plus de deux ans de maintenance de mon projet avec Mercurial, je doit avouer que c'est vraiment puissant. Certes, je n'ai pas un modèle hyper-décentralisé comme le noyau, mais tout de même. Ce que j'apprécie énormément dans Mercurial, c'est la gestion intégrée des MQ, c-à-d une série de patchs dans laquelle on se balade par "push" et "pop", un peu à la quilt (qui a servi de référence pour les MQ).
Je participe aussi un peu à des projets sous git, et je dois avouer que heureusement stgit est là, sinon je ne sais pas comment les gens font pour faire des séries et naviguer facilement dedans.
De toute façon, il existe des moyens simples de passer de l'un à l'autre, si au final la solution que tu as choisie ne te plait pas.
un mec [...] qui n'ai jamais joué a mario kart j'en connais aucun
Heu, moi non plus... Ça fait deux, alors... ;-)
tu n'a jamais eu de console, ni même de potes qui avaient une nintendo? Ou tous simplement tu ne joue pas a ce genre de jeux?
Je n'ai jamais eu de console (sauf une X-Box Gen-1, mais avec XBMC dessus dès le début), mes potes et moi on ne faisait pas de jeux console, et de plus je n'aime pas ce genre de jeux... :-)
Et sinon, voilà un petit moyen de générer facilement un script pour iptables. Le site est un peu ancien, ne permet pas de générer des choses compliquées, mais pour faire un petit pare-feu simple, c'est largement suffisant :
Il y a quelques années, j'ai commencé avec ce site, puis en lisant la doc, et les commentaires, j'en suis arrivé à le faire par moi-même. Je fais maintenant des scripts plutôt complexes, maintenant, mais la base fournie par ce script est très complète.
P.S : Le système passe par un routeur qui est connecté au modem
Si ce routeur est une box , alors pas be soin de parefeu. La box fait déjà parefeu pour toi.
Tu peux facilement le savoir. Quelle est la forme de l'adresse IP de la machine que tu veux protéger ? Si elle est d'une de ces familles, alors pas de souci :
10.x.y.z
172.16.x.y à 172.31.x.y
192.168.x.y
Cela veut dire que ton routeur fait du NAT et que donc ton réseau à la maison est de toute façon invisible du Grand Ternet.
J'ai trouvé ce site très intéressant pour comprendre le réseau et sa gestion sous Linux. En particulier la page sur netfilter et iptables est trés bien construite.
Ceci dit, ext{2,3,4}fs ont eux aussi un support du RAID. Lors de la création du FS ext, on peut spécifier certains paramètres qui permettent d'optimiser le FS en fonction du RAID sous-jacent ; ce sont les options étendues (extended options dans la page de man) suivantes :
stride : c'est le nombre de blocks contigus sur un disque
stripe-width : c'est le nombre de blocks contigus sur les disques de données
D'un autre côté, si on peut juste utiliser btrfs au-dessus d'un RAID, alors on peut aussi s'en ficher que btrfs gère nativement du RAID.
Donc, reste à savoir ce que supporter le RAID veut dire. Pour extfs, c'est une optimisation du placement des méta données. Pour btrfs, je ne sais pas.
Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.
C'est justement le but de la manœuvre: ne pas avoir besoin de les récupérer sur le disque.
Tout à fait d'accord. Mais ce n'est ce sur quoi je réagissait. patrick_g a dit :
les pages en statut « clean » peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (memory reclaiming) va enregistrer les pages dans leur espace de stockage particulier.
Or, une page clean n'est pas enregistrées sur le disque. Son entrée dans la page table est simplement suprimée, et la RAM qu'elle utilisait est de suite disponible pour y mettre une autre page (du même processus, ou d'un autre).
Seules les pages dirty sont écrites sur le disque.
Maintenant, ce nouveau mécanisme ajoute une étape intermédiaire : plutôt que de trasher la page, elle est envoyée au cleancache qui va la stocker temporairement au cas où elle serait demandée dans pas longtemps . Ce stockage peut alors être effectué de différentes manières :
la page est envoyée au swap
ça ne change rien par rapport à avant
la page est compressée en RAM
cleancache va stocker plusieurs pages compressées en utilisant moins de pages au total
ça reviens un peu à un truc qui existait il y a 15 ans sous Win3.11 qui faisait exactement ça; enfin, qui essayait... ;-)
la page est compressée en RAM, puis envoyée au swap
l'échange vers/depuis le swap est plus rapide
la page est toujours en RAM
si la pression est vraiment trop forte, on vire la page de la RAM plus tard
la pages est envoyée sur un périphérique bloc très rapide (eg. SSD)
un peu comme si c'était un swap
si ce périphérique se remplit trop, la page est migrée vers le vrai swap
Attention ! Ces possibilités ne sont pas (toutes) disponibles dans le 3.0. cleancache propose juste une infrastructure générique pour y brancher différentes politiques de gestions des pages.
pourquoi ne pas avoir un périphérique avec une tonne de RAM lente ?
C'est pas faux ! ;-)
Cette RAM jouerai le même rôle envers les disques que le cache envers la RAM. Une espèce de cache, sauf qu'au lieu d'être entre le processor et la RAM, il serait entre la RAM et le disque, en quelque sorte...
Maintenant, faire un tel truc ne devrait pas être ultra complexe. Il faudrait:
un contrôleur SATA-3 esclave
un paquet de barettes de RAM
quelques petits composants par-ci par-là
et une petite batterie en case de coupure de courant
Quand la pression mémoire est trop importante, alors les pages en statut « clean » peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (memory reclaiming) va enregistrer les pages dans leur espace de stockage particulier. Cet espace, nommé backing store, c’est tout simplement le disque ou la partition d’échange (swap) de la machine.
Je ne suis pas sur de ceci...
Justement, si les pages sont clean, c'est que leur contenu n'a pas changé par rapport au backingstore (le disque, quoi...). Donc on peut simplement les virer de la RAM sans état d'âme.
Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.
Les pages dirty, quant à elles, sont en effet ré-écrite sur le HDD.
Les deux cas ci-dessus, c'est pour les pages qui sont créées à cause de la lecture d'un fichier. Par contre, les pages qui n'ont pas de correspondance avec un fichier, comme les pages obtenues avec un malloc(), sont en effet envoyées dans le swap.
Maintenant, il est aussi possible d'utiliser le swap pour stocker des pages qui sont clean, si le swap est plus rapide que le disque d'où vient la page, ou si elle vient du réseau.
A-t-on vu un jour une plainte "Mon message de forum a été utilisé alors que je n'avais pas mis de licence donc mon mon droit d'auteur est violé"
En théorie, c'est tout à fait possible. OK, je dis bien en théorie . Et en spécifiant la licence, je lui impose certes des devoirs, mais aussi, et surtout, je lui octroie explicitement des droits. Ce n'est peut-être pas la licence qui te plait le plus ; c'est celle de mon choix. Tant pis si elle ne te plaît pas. Tant pis si elle ne lui plaît pas.
Et puis, franchement, que peut donc imposer la GPLv2 à un script shell ? Aucun binaire n'est généré.
si il garde le script pour lui et l'utilise au quotidien, le résultat (eg. fichiers générés) n'est de toute façon pas couvert par la GPLv2 ( et heureusement, sinon on ne pourrait pas compiler le code de logiciels privateurs avec gcc)
si il redistribue le script, ce que la GPLv2 autorise, la seule contrainte que je lui impose est que le destinataire obtienne les mêmes droits que lui.
"tenez, je vous aide sur un simple message de forum, mais si vous acceptez mon aide, alors vous devez utiliser la licence que je choisis !
Heu... Comment dire. C'est moi qui ai écrit le script. Je peux bien lui coller la licence que je veux, non ?
Certes, c'est le résultat d'un ensemble de réflexions partagées, mais si tu suis le cheminement des commentaires, tu verras tout de même comment j'en suis arrivé à ce script sans réutilisation de code... J'ai correctement crédité Tonton Benoit pour son idée de fifo créée avec mktemp et d'utilisation de la fifo en entrée de zenity .
Par ailleurs, aucune licence n'est visible sur la page du post. Donc si je n'en met pas une explicitement, il n'a pas le droit d'utiliser ce script, puisque par défaut le droit de propriété intellectuelle français (et ailleurs aussi, IIRC) n'autorise pas l'utilisation sans accord explicite de l'auteur. En précisant une licence telle que la GPLv2, je lui donne explicitement le droit, en se conformant à la licence, de réutiliser ce script.
Ceci dit, si je me trompe ( et c'est toujours possible, personne n'est infaillible, même pas moi ;-) ), du coup il ne peut pas utiliser ce script, puisque je ne lui en ai pas donnée. Du coup. :-(
Aller, je ne résiste pas à faire une nouvelle proposition ! :-)
Voilà, c'est assez complet, avec tout plein de commentaires, tous les cas tordus auxquels j'ai pensé sont pris en compte, le ménage est fait.
Ne reste plus qu'à remplacer la boucle for par le vrai boulot à faire, abstraire un peu pour le rendre générique et réutilisable (au cas où il y ai besoin de plusieurs progress dans le même script), etc..
Je l'ai fait en Anglais, car je vais me le mettre de côté, çui-ci... :-)
Enjoy !
#!/bin/bash# (C) 2011 "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr># License: GPLv2# In case the user cancels, we want to be notifiedcancelled=n
# Create the fifo# Note! If the witer comes and goes (eg. multiple open()# and close() of the fifo), the reader seems to get a# SIGPIPE. So we just open the fifo once using FD#6, see below.# Original idea by "Tonton Benoit" <xmpp:maxime@neurone-network.org>fifo_dir="$( mktemp -d )"fifo="${fifo_dir}/fifo"
mkfifo "${fifo}"# Print progress, and catch cancel# There is a slight race here, as we can get cancelled# between the check and the printf, but as we are emptying# the fifo (see below), we can still print into it.
report_progress(){if["${cancelled}"="n"]; thenprintf"%s\n""${1}" >&6 2>/dev/null
else return 1
fi}# Catch cancel:# - set global variable# - empty the fifo so we don't block in report_progress, above# Need to do that before running zenity, or there is# a slight race window where the user could cancel, and us# not having our trap set yet.# Note: when we finally remove the fifo, 'cat' will die. We# don't care about this, but we want it to be silent
trap_cancel(){cancelled=y
cat "${fifo}" >/dev/null 2>&1 &
}trap trap_cancel SIGHUP
# Start the progress report# Consign output to oblivion, as there is a race window# in case we were to remove the fifo just while zenity# was not yet finished (ie. on its dying path, but not# yet dead)
zenity --progress --title="Test"\
--text="progression..."\
--percentage=0 \
--auto-close \
--auto-kill \
>/dev/null 2>&1 \
<"${fifo}" &
progress_pid="${!}"# In case we are ourselves killed (think Ctrl-C!), we need# to kill zenity, and leave it no chance to bite us back.# Yes, there is a slight race window here, too, in case the# user kills us between the moment we launch zenity, and# the moment we set up the trap. But we can't set the trap# before we know the PID of zenity... This is unavoidable... :-(
trap_int(){kill -9 ${progress_pid}exec 6>&-
rm -rf "${fifo_dir}"printf'Argh, user killed us... :-(\n'exit 1
}trap trap_int SIGINT
# Opening FD#6 for writing earlier than that seems# to hang?!?... OK, anyway we only need it now...exec 6>"${fifo}"# Start our job, now...for((i=0; i<=100; i++ )); dosleep 0.1
report_progress "${i}"||break;
done# We end up here for two reasons:# 1- the job finished, so zenity (in auto-close) is now# about to die by itself, so will no longer bug us# 2- the job was cancelled, so zenity is about to die# by itself as well, so won't bother us either# So, we no longer have a valid reason to traptrap - SIGHUP SIGINT
# The fifo is of no use, now. Close FD#6 first.exec 6>&-
rm -rf "${fifo_dir}"if["${cancelled}"="y"]; thenprintf"Argh, user cancelled us... :-(\n"fiprintf"Now, i='%s'\n""${i}"
Pour Linux, il faudrait un paquet 32bits qui force l'installation de ses dépendances également en 32bits.
Heu... Bienvenue chez Debian, Ubuntu, Fedora, openSuSE, j'en passe et des meilleures...
Sur ma Squeeze 64-bits, je n'ai aucun souci à installer des packages 32-bits, et les dépendances suivent... D'accord, le package doit être correctement fait.
MAIS ! Cela ne fonctionne plus si la sortie de la boucle est à son tour 'pipée' dans une commande :
Là, je sèche... :-/
Alors, je crois que j'ai la réponse. Prenons ce bout de code :
while foo-bar; dovar=blabla
done |grep toto
Si je comprends bien POSIX dit explicitement (à la fin du chapitre) qu'un sous-shell doit être utilisé dans ce cas :
Additionally, each command of a multi-command pipeline is in a subshell environment; [...]
En fait, la commande while foo-bar; do blabla; done est une commande composée (multi-command), et en plus le résultat est pipé, donc ça rentre dans cette définition.
Donc il n'est pas possible de récupérer la valeur de '${var}' en dehors de la boucle while.
Donc, si tu veux récupérer sa valeur, tu devras faire un truc du genre :
J'ai compris que c'est parce que $var est déclaré dans un processus fils et qu'il ne peut donc pas passé de variable au processus père.
En effet.
[...] il est possible d'utiliser fifo mais je ne comprends vraiment pas comment ca s'utilise. Chaque essai que j'ai fait s'est soldé par un échec (script qui reste en attente)
D'abord, ici, fifo n'est qu'un nom de fichier; un fichier particulier : c'est un pipe nommé (pipe==fifo). En gros, c'est un tuyau. Un processus écrit d'un côté du tuyau, et un autre lit de l'autre côté. C'est à sens-unique.
Le problème des pipes, c'est qu'il ont une taille fixe, 4KiB IIRC. Le processus qui écrit est bloqué dès que le pipe est rempli, ce qui peut arriver si personne ne lit à l'autre bout, ou si l'autre bout ne se vide pas assez vite. Dès que le lecteur lit un bout du pipe, l'écrivain peut alors recommencer à le remplir. Ainsi de suite.
L'exemple que tu pointes (mal, ceci dit, il faut lire tout les commentaires pour voir à quoi tu fais référence) est bancal. Reprenons-le :
dépasse les 4KiB, alors ca va bloquer en attendant que le pipe se libère, ce qui n'arrivera jamais avec ce script, puisque la lecture se fait après :
while read ligne; do((var= var + 1 ))echo$vardone < fifo # <--- ici on lit depuis le pipe
Donc, il faut mettre l'écrivain en arrière plan, pour qu'il puisse continuer à écrire.
En plus, il y a une erreur de syntaxe sur cette ligne :
((var= var + 1 ))# On devrait écrcire : var=$(( var + 1 ))
#!/bin/sh
rm -f fifo # Suppression de la fifo au cas ou...
mkfifo fifo # Création de la fifo# Lancement de l'écrivain', en arrière plan, pour qu'il ne bloque# pas sur remplissage de la fifo : note le '&' en fin de ligne
cat "${fichier}" | grep "${valeur_recherche}" > fifo &
# Lancement du 'lecteur'while read ligne; dovar=$(( var +1))printf"%s"\n" "${var}"done < fifo# Resultat :printf "J'ai lu '%s' lignes\n" "${var}"# Plus besoin de la fifo, on la supprime
rm -f fifo
MAIS ! Cela ne fonctionne plus si la sortie de la boucle est à son tour 'pipée' dans une commande :
while read ligne; dovar=$(( var +1))printf"%s"\n" "${var}"done < fifo |zenity
Tu n'es aucunement obligé de fournir toutes les versions et tu le sais très bien.
Parfaitement, je le sais. Mais du coup, pour les architectures que je ne fournis pas, quelle solution ? Retour à la case départ, ne touchez pas vos 20 milles euros...
les principales architectures de ton public
Et comment je sais quelles sont les "principales architectures de [mon] public" ? Justement, de mon poitn de vue, c'est toutes les architectures sur les quelles Linux tourne.
rien n'empêche de faire plusieurs binaires pour séparer un peu les choses
Et on en revient au fait qu'il faut plusieurs binaires.
De toute façon, FatELF ne résout pas les problèmes. Vraiment, aucun.
Premièrement, le problème du packaging. Chaque distribution, pour chaque plateforme cible, devra de toute façon proposer un package. Cela, FatELF ne le résout pas. Sauf à uniformiser la gestion des packages entre toutes les distros, et n'avoir qu'un seul format. Et on voit bien que ce n'est pas faisable. Et que ce n'est pas ce que FatELF propose.
Deuxièmement, pour créer un FatELF, il faudrait toujours compiler pour plusieurs architectures (eg. x8632 + x86_64), ce qui déplace le problème un cran plus haut. J'entends, qui serait en charge de cette génération ? Surement pas les distros, aucun intérêt pour elle de générer ce genre de binaires. Surement pas non plus le _upstream des packages, ils n'ont aucune connaissance de la liste des architectures qui devraient être supportées, sauf à toutes les supporter; auquel cas cela devient virtuellement impossible (Cf. mon premier commentaire). Reste à trouver un intermédiaire, genre une meta-distro. Et encore, je ne vois pas quel intérêt de ce genre d'entité y trouverait.
La vraie question, à mon avis, est : quel est le problème que FatELF essaie de résoudre ?
Premièrement, certainement pas résoudre la compilation croisée. Soit on compile nativement sur plusieurs systèmes, et on agrège le tout dans un FatELF. Waouu ! Quelle galère. Même avec des VMs... Soit on cross-compile sur un seul et unique système, et on se retrouve dans l'état actuel. Waouu ! On n'a pas avancé...
Deuxièmement, certainement pas la disponibilité cross-architecture des packages FLOSS. On a les sources, on peut re-compiler. OK, certains ont des bugs dans ce domaine, mais comme on vient de le voir, FatELF ne corrige pas ça automagiquement. Retour à la case départ, ne touchez pas vos 20kE.
Que reste-t-il ? Ah, oui, les éditeurs de logiciels non FLOSS, dont on n'a pas les sources, pour qui il serait alors plus simple de faire une seule livraison pour toutes les machines qu'ils veulent supporter. Mais encore une fois, ca ne résout aucun problème, encore faut-il ques ces éditeurs veuillent supporter telle ou telle architecture. Et le cas échéant, il est, à mon avis (qui vaut ce qu'il vaut, mais je travaille dans ce domaine depuis plus de treize ans [1]), beaucoup plus simple de fournir une archive par plateforme supportée, beaucoup plus simple.
Ils peuvent bien faire ce qu'ils veulent, de toute façon. Soit leur logiciel est indispensable, et une entreprise qui en a besoin installera de toute façon la distro requise sur une machine (physique ou virtuelle, et je connais ce cas en milieu pro); soit leur logiciel n'est pas indispensable (il y a un ou plusieurs concurrent, FLOSS ou non), et l'entreprise se dirigera vers la solution alternative.
Et franchement, pour mon cas 'particulier à la maison', les logiciels non-FLOSS, je m'en bat le bambou sur le coin de la table... ;-)
Quant à Mme Michu, qu'utilise-t-elle ? Windows ? OK, on sort du cadre. Ubuntu sur PC ? C'est déjà l'architecture supportée par tous les vendeurs de logiciels privateurs.
Hop,
Moi.
[1] Ce qui ne veut pas non plus dire que j'ai raison, c'est juste l'expérience qui parle...
PS. Purée, mon premier gros, gros commentaire... Désolé...
PPS. Comment c'est-y qu'on fait le symbole 'euro' avec la touche Meta ?
PPPS. Non, je ne suis pas méchant. ;-)
PPPPS. Bon quatrième re-lecture, tant pis, je poste... ;-)
Et pour quelle ABI du noyau ? Puis-je utiliser les AIO ? Et les futex ? Etc...
Ça va faire vraiment beaucoup, beaucoup de possibilités si je veux faire un binaire qui tourne vraiment partout... Il va être vraiment très, très gros...
Pourquoi me limiterai-je à certaines possibilités si je veux vraiment que mon logiciel soit largement utilisé ?
Ah si, je sais !... Je fournit les sources en GPLv2 (Troll Inside). Qui veut l'utiliser peut toujours le compiler. (re-Troll re-Inside).
Mouaif, bof... Utilise plutôt la seconde solution :
dans un fichier dans /etc/modprobe.d/
Le fichier doit finir en '.conf'.
mais ça n'est pas pris en compte après un reboot.
Par défaut, Debian et Ubuntu (kof!kof!... ;-]) démarrent sur un initrd. Si le module est chargé à partir de l'initrd, alors il faut re-générer cet initrd pour qu'il prenne en compte les nouvelles options que tu as spécifiées :
[^] # Re: Quelques comparatifs existants
Posté par ymorin . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 1.
En effet, c'est pro-git. Tellement que c'en devient presque de la mauvaise foi. :-)
Et le "gros argumentaire" inverse : Why Git Ain’t Better Than X, rédigé du point de vue d'un afficionados de Bazaar.
Et enfin un argumentaire qui calme les choses : Git vs. Mercurial: Please Relax. Celui-ci est un peu en retard, notamment parce que git n'est plus une multitude de petits binaires comme au début, mais les arguments n'en sont pas moins toujours valables.
Hop,
Moi.
[^] # Re: Mon utilisation de git ...
Posté par ymorin . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 3.
Avec Mercurial, il y a aussi l'action rebase, même si je ne l'utilise pas.
J'ai plutôt tendance à utiliser des MQs, voire aussi à les versionner elle-mêmes.
Qu'est-ce que les MQs ? C'est une série de patchs que tu peux empiler (qpush) et dépiler (qpop), les réordonner, le tout à volonté. Il y a d'autre possibilités, mais ceci est la base.
Quand je travaille sur une fonctionnalité ou une correction de bug, je commence toujours une MQ. Par exemple, je décide d'ajouter une nouvelle fonction, et de l'utiliser un peu partout pour mutualiser le code :
Et voilà. Et on peut aussi versionner les MQs, qui du coup se trouvent être un repository Mercurial à part entière, donc on peut le clonner, le pusher et le puller. Si je fais une MQ sur une machine A, et que je veux l'utiliser sur une machiune B , je peux, au choix :
J'utilise le plus souvent 1. et 2. Par exemple, pour le projet que je maintein et développe :
Pour utiliser ces deux MQs :
(La MQ default est toujours créée.)
Et après, je peux les pusher en retour vers le serveur:
Maintenant, si le repository a changé, je dépile ma MQ, je pull les nouveaux changements, et je réapplique la MQ en résolvant les conflits :
Ça fait aussi un espèce de rebase, si on veut. Alors oui, il y a certains petits manques par rapport à git. Par exemple, si un patch est déjà appliqué, qpush ne s'en aperçoit pas. C'est pas très grave, un qdelete fait l'affaire.
Franchement, ce sont pour moi devenues des opérations triviales^Wbanales.
J'utilise Mercurial pour gérer mon ${HOME}, pour gérer mes scripts de déploiement de machines virtuelles, etc...
D'accord, peut-être que ça ne passe pas à l'échelle comme pour le noyau Linux, quoique de très gros projets sont gérés avec brio sous Mercurial.
Hop,
Moi.
[^] # Re: Btrfs
Posté par ymorin . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 4.
Les contrôleurs RAID matériels ont une grosse quantité de RAM qui sert de cache :
Dans le cas de l'écriture différée, l'OS croit avoir écrit sur le disque, alors que le contrôleur le garde en mémoire. La batterie va permettre au contrôleur RAID de terminer l'écriture des blocs en l'air et ainsi garantir l'intégrité des données : ce que l'OS croit avoir écrit, bin en fait, c'est réellement écrit !
Dans des cas extrêmes, ca permet même de garantir le maintien du cache de lecture pour avoir un boot plus rapide. Mais là, on atteint des sommets... en coût du contrôleur, pour un gain discutable...
Hop,
Moi.
# Mon point de vue, pour ce qu'il vaut... ;-)
Posté par ymorin . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 6.
Le "merge". Dans Subversion, j'ai toujours eu des embêtements de merge. Avec Mercurial, jamais. Des conflits, certes, mais pas d'embêtement. Par exemple, dans Subversion, les "tree conflicts", c'est une catastrophe à résoudre. Dans Mercurial, il n'y a même pas besoin de cette notion. Pareil pour git.
En venant de Subversion, Mercurial est plus évident que git, j'ai trouvé.
Certes, git c'est "le bien pasque c'est Linus qui l'a fait et qu'on utilise ça pour le noyau". git est puissant. Vraiment très puissant. Mais la gestion au quotidien est d'une complexité effrayante. Même si ça s'est amélioré au fil du temps, git reste vraiment un outil pour "power-user", alors que Mercurial est facile d'accès.
Après plus de deux ans de maintenance de mon projet avec Mercurial, je doit avouer que c'est vraiment puissant. Certes, je n'ai pas un modèle hyper-décentralisé comme le noyau, mais tout de même. Ce que j'apprécie énormément dans Mercurial, c'est la gestion intégrée des MQ, c-à-d une série de patchs dans laquelle on se balade par "push" et "pop", un peu à la quilt (qui a servi de référence pour les MQ).
Je participe aussi un peu à des projets sous git, et je dois avouer que heureusement stgit est là, sinon je ne sais pas comment les gens font pour faire des séries et naviguer facilement dedans.
De toute façon, il existe des moyens simples de passer de l'un à l'autre, si au final la solution que tu as choisie ne te plait pas.
Hop,
Moi.
[^] # Re: Déception
Posté par ymorin . En réponse au journal SuperTuxKart 0.7.2 est sorti !. Évalué à 3.
Heu, moi non plus... Ça fait deux, alors... ;-)
Je n'ai jamais eu de console (sauf une X-Box Gen-1, mais avec XBMC dessus dès le début), mes potes et moi on ne faisait pas de jeux console, et de plus je n'aime pas ce genre de jeux... :-)
Hop,
Moi.
# Yeux fatigués....
Posté par ymorin . En réponse au journal SuperTuxKart 0.7.2 est sorti !. Évalué à 2.
J'ai lu : "la troll-list"
Pffiou... ;-)
Sinon, merci de m'avoir fait connaître STK, ca fait un jeu casual pour jouer sur la téloche pour quand les potes viennent ! :-)
Hop,
Moi.
[^] # Re: Vraiment besoin d'un parefeu ?
Posté par ymorin . En réponse au message Configuration simple d'un firewall. Évalué à 1.
Et sinon, voilà un petit moyen de générer facilement un script pour iptables. Le site est un peu ancien, ne permet pas de générer des choses compliquées, mais pour faire un petit pare-feu simple, c'est largement suffisant :
Easy Firewall Generator for IPTables
Il y a quelques années, j'ai commencé avec ce site, puis en lisant la doc, et les commentaires, j'en suis arrivé à le faire par moi-même. Je fais maintenant des scripts plutôt complexes, maintenant, mais la base fournie par ce script est très complète.
Hop,
Moi.
# Vraiment besoin d'un parefeu ?
Posté par ymorin . En réponse au message Configuration simple d'un firewall. Évalué à 2.
Si ce routeur est une box , alors pas be soin de parefeu. La box fait déjà parefeu pour toi.
Tu peux facilement le savoir. Quelle est la forme de l'adresse IP de la machine que tu veux protéger ? Si elle est d'une de ces familles, alors pas de souci :
Cela veut dire que ton routeur fait du NAT et que donc ton réseau à la maison est de toute façon invisible du Grand Ternet.
J'ai trouvé ce site très intéressant pour comprendre le réseau et sa gestion sous Linux. En particulier la page sur netfilter et iptables est trés bien construite.
Bon courage !
Hop,
Moi.
[^] # Re: Btrfs
Posté par ymorin . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 10.
Entièrement d'accord la dessus.
Ceci dit, ext{2,3,4}fs ont eux aussi un support du RAID. Lors de la création du FS ext, on peut spécifier certains paramètres qui permettent d'optimiser le FS en fonction du RAID sous-jacent ; ce sont les options étendues (extended options dans la page de man) suivantes :
D'un autre côté, si on peut juste utiliser btrfs au-dessus d'un RAID, alors on peut aussi s'en ficher que btrfs gère nativement du RAID.
Donc, reste à savoir ce que supporter le RAID veut dire. Pour extfs, c'est une optimisation du placement des méta données. Pour btrfs, je ne sais pas.
Hop,
Moi.
[^] # Re: Les pages propres
Posté par ymorin . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 1.
Ou plutôt un contrôleur PCI express, 8x ou 16x tant qu'à faire... ;-)
[^] # Re: Les pages propres
Posté par ymorin . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 8.
Tout à fait d'accord. Mais ce n'est ce sur quoi je réagissait. patrick_g a dit :
Or, une page clean n'est pas enregistrées sur le disque. Son entrée dans la page table est simplement suprimée, et la RAM qu'elle utilisait est de suite disponible pour y mettre une autre page (du même processus, ou d'un autre).
Seules les pages dirty sont écrites sur le disque.
Maintenant, ce nouveau mécanisme ajoute une étape intermédiaire : plutôt que de trasher la page, elle est envoyée au cleancache qui va la stocker temporairement au cas où elle serait demandée dans pas longtemps . Ce stockage peut alors être effectué de différentes manières :
Attention ! Ces possibilités ne sont pas (toutes) disponibles dans le 3.0. cleancache propose juste une infrastructure générique pour y brancher différentes politiques de gestions des pages.
C'est pas faux ! ;-)
Cette RAM jouerai le même rôle envers les disques que le cache envers la RAM. Une espèce de cache, sauf qu'au lieu d'être entre le processor et la RAM, il serait entre la RAM et le disque, en quelque sorte...
Maintenant, faire un tel truc ne devrait pas être ultra complexe. Il faudrait:
Bon, je te rassure, ça existe :
Hop,
Moi.
# Les pages propres
Posté par ymorin . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 5.
Je ne suis pas sur de ceci...
Justement, si les pages sont clean, c'est que leur contenu n'a pas changé par rapport au backingstore (le disque, quoi...). Donc on peut simplement les virer de la RAM sans état d'âme.
Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.
Les pages dirty, quant à elles, sont en effet ré-écrite sur le HDD.
Les deux cas ci-dessus, c'est pour les pages qui sont créées à cause de la lecture d'un fichier. Par contre, les pages qui n'ont pas de correspondance avec un fichier, comme les pages obtenues avec un malloc(), sont en effet envoyées dans le swap.
Maintenant, il est aussi possible d'utiliser le swap pour stocker des pages qui sont clean, si le swap est plus rapide que le disque d'où vient la page, ou si elle vient du réseau.
Bon, je vais finir la lecture...
Hop,
Moi.
[^] # Re: Quelqu'un est surpris ?
Posté par ymorin . En réponse au journal La vente liée a encore de beaux jours devant elle.. Évalué à 8.
Je dirai plutôt :
Ils ont peur de la technologie car ils ne la maîtrisent pas.
[^] # Re: Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 1.
En théorie, c'est tout à fait possible. OK, je dis bien en théorie . Et en spécifiant la licence, je lui impose certes des devoirs, mais aussi, et surtout, je lui octroie explicitement des droits. Ce n'est peut-être pas la licence qui te plait le plus ; c'est celle de mon choix. Tant pis si elle ne te plaît pas. Tant pis si elle ne lui plaît pas.
Et puis, franchement, que peut donc imposer la GPLv2 à un script shell ? Aucun binaire n'est généré.
Hop,
Moi.
[^] # Re: Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 0.
Heu... Comment dire. C'est moi qui ai écrit le script. Je peux bien lui coller la licence que je veux, non ?
Certes, c'est le résultat d'un ensemble de réflexions partagées, mais si tu suis le cheminement des commentaires, tu verras tout de même comment j'en suis arrivé à ce script sans réutilisation de code... J'ai correctement crédité Tonton Benoit pour son idée de fifo créée avec mktemp et d'utilisation de la fifo en entrée de zenity .
Par ailleurs, aucune licence n'est visible sur la page du post. Donc si je n'en met pas une explicitement, il n'a pas le droit d'utiliser ce script, puisque par défaut le droit de propriété intellectuelle français (et ailleurs aussi, IIRC) n'autorise pas l'utilisation sans accord explicite de l'auteur. En précisant une licence telle que la GPLv2, je lui donne explicitement le droit, en se conformant à la licence, de réutiliser ce script.
Ceci dit, si je me trompe ( et c'est toujours possible, personne n'est infaillible, même pas moi ;-) ), du coup il ne peut pas utiliser ce script, puisque je ne lui en ai pas donnée. Du coup. :-(
Hop,
Moi.
[^] # Re: Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 1.
Bon, pas d'autre améliorations ?
Aller, je ne résiste pas à faire une nouvelle proposition ! :-)
Voilà, c'est assez complet, avec tout plein de commentaires, tous les cas tordus auxquels j'ai pensé sont pris en compte, le ménage est fait.
Ne reste plus qu'à remplacer la boucle for par le vrai boulot à faire, abstraire un peu pour le rendre générique et réutilisable (au cas où il y ai besoin de plusieurs progress dans le même script), etc..
Je l'ai fait en Anglais, car je vais me le mettre de côté, çui-ci... :-)
Enjoy !
Hop,
Moi.
[^] # Re: debian
Posté par ymorin . En réponse au journal Linux 3 et Python : bugs en approche. Évalué à 3.
Hé non... Le candidat est le 2.6.39+35 qui vient de wheezy (aka testing).
Mais je te l'accorde, c'est pas tellement mieux ! (Merde, on n'est même pas trolldi...) :-)
Hop,
Moi.
[^] # Re: Et des « FatPkg » indépendants d'une distribution ?
Posté par ymorin . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 3.
Heu... Bienvenue chez Debian, Ubuntu, Fedora, openSuSE, j'en passe et des meilleures...
Sur ma Squeeze 64-bits, je n'ai aucun souci à installer des packages 32-bits, et les dépendances suivent... D'accord, le package doit être correctement fait.
Ou alors, j'ai pas bien saisi ta phrase... :-/
Hop,
Moi.
[^] # Re: Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 1.
Ouais ! Bravo ! Nous avons un gagnat ! :-)
Ça, moi, j'aime bien ! Vraiment ! ;-)
Oui, deux points :
Hop,
Moi.
[^] # Re: Et des « FatPkg » indépendants d'une distribution ?
Posté par ymorin . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 1.
Hé bien parce qu'un OS 64-bit bien foutu comporte une couche d'émulation 32-bit. C'est le cas pour Windows et pour Linux. Pour Mac, no lo se .
[^] # Re: Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 1.
Alors, je crois que j'ai la réponse. Prenons ce bout de code :
Si je comprends bien POSIX dit explicitement (à la fin du chapitre) qu'un sous-shell doit être utilisé dans ce cas :
En fait, la commande while foo-bar; do blabla; done est une commande composée (multi-command), et en plus le résultat est pipé, donc ça rentre dans cette définition.
Donc il n'est pas possible de récupérer la valeur de '${var}' en dehors de la boucle while.
Donc, si tu veux récupérer sa valeur, tu devras faire un truc du genre :
C'est crade, mais ça marche... :-(
Hop,
Moi.
# Mais pourquoi est-il aussi méchant ?
Posté par ymorin . En réponse au message zenity : processus père/fils, fifo,…. Évalué à 5.
En effet.
D'abord, ici, fifo n'est qu'un nom de fichier; un fichier particulier : c'est un pipe nommé (pipe==fifo). En gros, c'est un tuyau. Un processus écrit d'un côté du tuyau, et un autre lit de l'autre côté. C'est à sens-unique.
Le problème des pipes, c'est qu'il ont une taille fixe, 4KiB IIRC. Le processus qui écrit est bloqué dès que le pipe est rempli, ce qui peut arriver si personne ne lit à l'autre bout, ou si l'autre bout ne se vide pas assez vite. Dès que le lecteur lit un bout du pipe, l'écrivain peut alors recommencer à le remplir. Ainsi de suite.
L'exemple que tu pointes (mal, ceci dit, il faut lire tout les commentaires pour voir à quoi tu fais référence) est bancal. Reprenons-le :
Si le contenu filtré :
dépasse les 4KiB, alors ca va bloquer en attendant que le pipe se libère, ce qui n'arrivera jamais avec ce script, puisque la lecture se fait après :
Donc, il faut mettre l'écrivain en arrière plan, pour qu'il puisse continuer à écrire.
En plus, il y a une erreur de syntaxe sur cette ligne :
MAIS ! Cela ne fonctionne plus si la sortie de la boucle est à son tour 'pipée' dans une commande :
Là, je sèche... :-/
[^] # Re: Pas d'accord...
Posté par ymorin . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 10.
Parfaitement, je le sais. Mais du coup, pour les architectures que je ne fournis pas, quelle solution ? Retour à la case départ, ne touchez pas vos 20 milles euros...
Et comment je sais quelles sont les "principales architectures de [mon] public" ? Justement, de mon poitn de vue, c'est toutes les architectures sur les quelles Linux tourne.
Et on en revient au fait qu'il faut plusieurs binaires.
De toute façon, FatELF ne résout pas les problèmes. Vraiment, aucun.
Premièrement, le problème du packaging. Chaque distribution, pour chaque plateforme cible, devra de toute façon proposer un package. Cela, FatELF ne le résout pas. Sauf à uniformiser la gestion des packages entre toutes les distros, et n'avoir qu'un seul format. Et on voit bien que ce n'est pas faisable. Et que ce n'est pas ce que FatELF propose.
Deuxièmement, pour créer un FatELF, il faudrait toujours compiler pour plusieurs architectures (eg. x8632 + x86_64), ce qui déplace le problème un cran plus haut. J'entends, qui serait en charge de cette génération ? Surement pas les distros, aucun intérêt pour elle de générer ce genre de binaires. Surement pas non plus le _upstream des packages, ils n'ont aucune connaissance de la liste des architectures qui devraient être supportées, sauf à toutes les supporter; auquel cas cela devient virtuellement impossible (Cf. mon premier commentaire). Reste à trouver un intermédiaire, genre une meta-distro. Et encore, je ne vois pas quel intérêt de ce genre d'entité y trouverait.
La vraie question, à mon avis, est : quel est le problème que FatELF essaie de résoudre ?
Premièrement, certainement pas résoudre la compilation croisée. Soit on compile nativement sur plusieurs systèmes, et on agrège le tout dans un FatELF. Waouu ! Quelle galère. Même avec des VMs... Soit on cross-compile sur un seul et unique système, et on se retrouve dans l'état actuel. Waouu ! On n'a pas avancé...
Deuxièmement, certainement pas la disponibilité cross-architecture des packages FLOSS. On a les sources, on peut re-compiler. OK, certains ont des bugs dans ce domaine, mais comme on vient de le voir, FatELF ne corrige pas ça automagiquement. Retour à la case départ, ne touchez pas vos 20kE.
Que reste-t-il ? Ah, oui, les éditeurs de logiciels non FLOSS, dont on n'a pas les sources, pour qui il serait alors plus simple de faire une seule livraison pour toutes les machines qu'ils veulent supporter. Mais encore une fois, ca ne résout aucun problème, encore faut-il ques ces éditeurs veuillent supporter telle ou telle architecture. Et le cas échéant, il est, à mon avis (qui vaut ce qu'il vaut, mais je travaille dans ce domaine depuis plus de treize ans [1]), beaucoup plus simple de fournir une archive par plateforme supportée, beaucoup plus simple.
Ils peuvent bien faire ce qu'ils veulent, de toute façon. Soit leur logiciel est indispensable, et une entreprise qui en a besoin installera de toute façon la distro requise sur une machine (physique ou virtuelle, et je connais ce cas en milieu pro); soit leur logiciel n'est pas indispensable (il y a un ou plusieurs concurrent, FLOSS ou non), et l'entreprise se dirigera vers la solution alternative.
Et franchement, pour mon cas 'particulier à la maison', les logiciels non-FLOSS, je m'en bat le bambou sur le coin de la table... ;-)
Quant à Mme Michu, qu'utilise-t-elle ? Windows ? OK, on sort du cadre. Ubuntu sur PC ? C'est déjà l'architecture supportée par tous les vendeurs de logiciels privateurs.
Hop,
Moi.
[1] Ce qui ne veut pas non plus dire que j'ai raison, c'est juste l'expérience qui parle...
PS. Purée, mon premier gros, gros commentaire... Désolé...
PPS. Comment c'est-y qu'on fait le symbole 'euro' avec la touche Meta ?
PPPS. Non, je ne suis pas méchant. ;-)
PPPPS. Bon quatrième re-lecture, tant pis, je poste... ;-)
# Pas d'accord...
Posté par ymorin . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 10.
Heu.. Non. ;-)
Je suis developpeur, quelles architectures dois-je mettre ?
Pour quelles libc ?
Et pour quelle ABI du noyau ? Puis-je utiliser les AIO ? Et les futex ? Etc...
Ça va faire vraiment beaucoup, beaucoup de possibilités si je veux faire un binaire qui tourne vraiment partout... Il va être vraiment très, très gros...
Pourquoi me limiterai-je à certaines possibilités si je veux vraiment que mon logiciel soit largement utilisé ?
Ah si, je sais !... Je fournit les sources en GPLv2 (Troll Inside). Qui veut l'utiliser peut toujours le compiler. (re-Troll re-Inside).
Hop,
Moi.
# Module? What module? :-)
Posté par ymorin . En réponse au message ajouter un paramètre à un module au boot. Évalué à 4.
Mouaif, bof... Utilise plutôt la seconde solution :
Le fichier doit finir en '.conf'.
Par défaut, Debian et Ubuntu (kof!kof!... ;-]) démarrent sur un initrd. Si le module est chargé à partir de l'initrd, alors il faut re-générer cet initrd pour qu'il prenne en compte les nouvelles options que tu as spécifiées :
Hop,
Moi.