#!/bin/sh
f(){ gcc -Wall -o /tmp/cscript.$$ -x c – && /tmp/cscript.$$ "$@"
ret=$? ; rm -f /tmp/cscript.$$ ; exit $ret;}
f "$@" <<EOF_REALLY_JUST_KEEP_GOING
//
// Code C
//
#include
int main(int argc, char** argv)
{
printf( "Appel de %s avec %d arguments\n", argv[0], argc-1 );
return 0;
}

Il existe sous linux, depuis la version 2.6.9, le RAID10 builtin, que je nommerais par la suite "RAID10″ et utiliserais "RAID1+0″ pour la version classique, c’est à dire deux RAID1 agrégé avec un RAID0.
Il n’est pas précisé pour l’explication du "RAID10″ que le nombre de disque est au minimum de 2, ce qui permet d’avoir des performances améliorées en lecture pour un coût moindre que le "RAID1+0″, les performances en écriture sont quelques peu inférieures.

À noter également dans ce "RAID10″, les disques doivent être de taille similaires pour éviter de perdre de l’espace disque, contrairement au RAID1+0 où l’on peut par exemple avoir deux paires de deux de tailles similaire par paire et récupérer un maximum d’espace disque grace au RAID0 agrégeant les deux mirroirs.

Cheers.

Retty s’introduit dans le processus de destination avec ptrace (comme le ferait un debugger), il y introduit un code (comme le ferait un cracker) puis le lance.
Le code en question fait en sorte de fermer le terminal parent puis de le remplacer par celui de l’adoptant. Mais tout ceci se fait sans l’accord du noyau et par conséquent la commande tty ne retourne pas le bon tty.

Du coup ca marche dans la plupart des cas, le processus fait confiance à sa famille d’accueil et peut utiliser son terminal comme si de rien n’était. Mais il arrive que le processus veuille connaitre sa famille d’origine (commande tty) et comme souvent elle n’est plus là ça pose de problèmes (sauf si le vrai parent n’a pas disparu).