Je m'excuse de poster encore une fois un problème technique sur
débats, mais je n'ai toujours pas accès au groupe configuration.
Plaignez-vous, je suis d'accord:
abuse@enter-net.com et
support@enter-net.com
Donc, je décide de mettre ma Libranet à jour. J'échange woody pour sid dans
le fichier de conf, et apt-get me rélécharge 500 megs de fichiers.
Questions, questions, questions... Tout s'installe sauf Gnome, pour lequel
il manque apparemment un fichier. (À noter que j'ai installè dans une
konsole de KDE en faisant su - , mais je ne pense pas que ça change
grand-chose.)
Je reboote, je suis toujours dans KDE 3.0 , xine ne fonctionne toujours pas
pour les fichiers asx ==> asf . C'est comme si rien n'avait changé. Y
a-t-il moyen de reprendre l'installation?
Qu'est-ce qui se passe, que se passa aqui? S'il se trouve que swaret
fonctionne mieux que apt-get, je vais piquer une crise.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Et paf, une debianerie totalement incompréhensible. Excuse moi,mais les histoire de fakeroot, root-pivot et autres dpkg --build c'est du bas
C'est pourtant du plus élémentaire besoin... Cela permet de positionner des droits sur des fichiers sans être obligé d'être root. Rien de sorcier là-dedans, et cela *devrait* exister dans tous les UNIX de la planète, étant donné qu'il est universellement admis qu'il est tout à fait dangereux de travailler sous root inutilement.
chinois occidental. Je ne dis pas que c'est pas bien, mais quand on doit utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et t'en reste là. L'avantage du libre, c'est que chacun fait comme il veut...
Et paf, une debianerie totalement incompréhensible. Excuse moi,mais les
histoire de fakeroot, root-pivot et autres dpkg --build c'est du bas
C'est pourtant du plus élémentaire besoin... Cela permet de
positionner des droits sur des fichiers sans être obligé d'être
root. Rien de sorcier là-dedans, et cela *devrait* exister dans tous
les UNIX de la planète, étant donné qu'il est universellement admis
qu'il est tout à fait dangereux de travailler sous root inutilement.
chinois occidental. Je ne dis pas que c'est pas bien, mais quand on doit
utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop
compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde
UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous
Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la
joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et
t'en reste là. L'avantage du libre, c'est que chacun fait comme il
veut...
Et paf, une debianerie totalement incompréhensible. Excuse moi,mais les histoire de fakeroot, root-pivot et autres dpkg --build c'est du bas
C'est pourtant du plus élémentaire besoin... Cela permet de positionner des droits sur des fichiers sans être obligé d'être root. Rien de sorcier là-dedans, et cela *devrait* exister dans tous les UNIX de la planète, étant donné qu'il est universellement admis qu'il est tout à fait dangereux de travailler sous root inutilement.
chinois occidental. Je ne dis pas que c'est pas bien, mais quand on doit utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et t'en reste là. L'avantage du libre, c'est que chacun fait comme il veut...
Surtout quand le code source en question ne vient pas avec une directory debian, ou bien vient avec une directory debian mais prévue pour unstable, ou autres plaisanteries du même genre. Excusez moi, mais de tous les programmes en code source qui m'intéressaient, il n'y en a pas un seul qui est passé avec apt-get source. Par contre avec la manip que Sam Hocevar a décrite, oui, ils sont passés, mais c'est une manip hautement merdique. Là encore faire le dh_make et espèrer que ça va fonctionner sans éditer debian/rules après essai et erreurs, c'est croire au père Noel, je sais c'est de saison.
Le rétroportage est une facilité offerte en plus du système de paquet de la distribution pour pallier certaines déficiences de Debian (le retard notamment). Il n'est jamais écrit que tout marche tip-top sans problème et que c'est totalement à la portée du premier con venu. Sinon, créer une distribution à jour serait complètement triviale : il n'y aurait qu'à rétroporter l'ensemble des paquets avec des sources à jour.
Surtout quand le code source en question ne vient pas avec une
directory debian, ou bien vient avec une directory debian mais
prévue pour unstable, ou autres plaisanteries du même genre. Excusez
moi, mais de tous les programmes en code source qui m'intéressaient,
il n'y en a pas un seul qui est passé avec apt-get source. Par
contre avec la manip que Sam Hocevar a décrite, oui, ils sont
passés, mais c'est une manip hautement merdique. Là encore faire le
dh_make et espèrer que ça va fonctionner sans éditer debian/rules
après essai et erreurs, c'est croire au père Noel, je sais c'est de
saison.
Le rétroportage est une facilité offerte en plus du système de paquet
de la distribution pour pallier certaines déficiences de Debian (le
retard notamment). Il n'est jamais écrit que tout marche tip-top sans
problème et que c'est totalement à la portée du premier con
venu. Sinon, créer une distribution à jour serait complètement
triviale : il n'y aurait qu'à rétroporter l'ensemble des paquets avec
des sources à jour.
Surtout quand le code source en question ne vient pas avec une directory debian, ou bien vient avec une directory debian mais prévue pour unstable, ou autres plaisanteries du même genre. Excusez moi, mais de tous les programmes en code source qui m'intéressaient, il n'y en a pas un seul qui est passé avec apt-get source. Par contre avec la manip que Sam Hocevar a décrite, oui, ils sont passés, mais c'est une manip hautement merdique. Là encore faire le dh_make et espèrer que ça va fonctionner sans éditer debian/rules après essai et erreurs, c'est croire au père Noel, je sais c'est de saison.
Le rétroportage est une facilité offerte en plus du système de paquet de la distribution pour pallier certaines déficiences de Debian (le retard notamment). Il n'est jamais écrit que tout marche tip-top sans problème et que c'est totalement à la portée du premier con venu. Sinon, créer une distribution à jour serait complètement triviale : il n'y aurait qu'à rétroporter l'ensemble des paquets avec des sources à jour.
OoO En cette nuit striée d'éclairs du mardi 30 décembre 2003, vers 02:49, Richard Delorme disait:
Je pense que si tu arrives avec un système de paquets aussi robuste que celui de Debian et un outil qui à partir des sources te génère un paquet tip top comme il faut sans rien faire du tout, tu intéresseras du monde. :)
Gentoo ?
On le crée comment le paquet Gentoo ?
emerge --buildpkg <nom-du-paquet>
-- Richard
OoO En cette nuit striée d'éclairs du mardi 30 décembre 2003, vers
02:49, Richard Delorme <abulmo@nospam.fr> disait:
Je pense que si tu arrives avec un système de paquets aussi robuste
que celui de Debian et un outil qui à partir des sources te génère un
paquet tip top comme il faut sans rien faire du tout, tu intéresseras
du monde. :)
OoO En cette nuit striée d'éclairs du mardi 30 décembre 2003, vers 02:49, Richard Delorme disait:
Je pense que si tu arrives avec un système de paquets aussi robuste que celui de Debian et un outil qui à partir des sources te génère un paquet tip top comme il faut sans rien faire du tout, tu intéresseras du monde. :)
Gentoo ?
On le crée comment le paquet Gentoo ?
emerge --buildpkg <nom-du-paquet>
-- Richard
Richard Delorme
OoO En ce milieu de nuit étoilée du mardi 30 décembre 2003, vers 03:03, Richard Delorme disait:
Soit quasiment le triple de ce qu'utilise xine.
Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?) ou non mais je constate juste (et apprécie) sa légèreté, pour obtenir un GUI tout à fait comparable à celui de gmplayer, sans dépendre de l'usine à gaz GTK+.
et pas mal de trucs sont collés dans la libxine, il faut donc regarder les dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car cela ne rajoute pas de nouvelles dépendances.
-- Richard
OoO En ce milieu de nuit étoilée du mardi 30 décembre 2003, vers
03:03, Richard Delorme <abulmo@nospam.fr> disait:
Soit quasiment le triple de ce qu'utilise xine.
Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?) ou non mais je
constate juste (et apprécie) sa légèreté, pour obtenir un GUI tout à
fait comparable à celui de gmplayer, sans dépendre de l'usine à gaz GTK+.
et pas mal
de trucs sont collés dans la libxine, il faut donc regarder les
dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car cela
ne rajoute pas de nouvelles dépendances.
OoO En ce milieu de nuit étoilée du mardi 30 décembre 2003, vers 03:03, Richard Delorme disait:
Soit quasiment le triple de ce qu'utilise xine.
Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?) ou non mais je constate juste (et apprécie) sa légèreté, pour obtenir un GUI tout à fait comparable à celui de gmplayer, sans dépendre de l'usine à gaz GTK+.
et pas mal de trucs sont collés dans la libxine, il faut donc regarder les dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car cela ne rajoute pas de nouvelles dépendances.
-- Richard
Vincent Bernat
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers 11:32, Richard Delorme disait:
Je pense que si tu arrives avec un système de paquets aussi robuste que celui de Debian et un outil qui à partir des sources te génère un paquet tip top comme il faut sans rien faire du tout, tu intéresseras du monde. :)
Gentoo ? On le crée comment le paquet Gentoo ?
emerge --buildpkg <nom-du-paquet>
La bonne blague. On fait comment quand y'a pas de .emerge dispo ? -- NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE -+- Bart Simpson on chalkboard in episode BABF13
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers
11:32, Richard Delorme <abulmo@nospam.fr> disait:
Je pense que si tu arrives avec un système de paquets aussi
robuste que celui de Debian et un outil qui à partir des sources
te génère un paquet tip top comme il faut sans rien faire du
tout, tu intéresseras du monde. :)
Gentoo ?
On le crée comment le paquet Gentoo ?
emerge --buildpkg <nom-du-paquet>
La bonne blague. On fait comment quand y'a pas de .emerge dispo ?
--
NON-FLAMMABLE, IS NOT A CHALLENGE
NON-FLAMMABLE, IS NOT A CHALLENGE
NON-FLAMMABLE, IS NOT A CHALLENGE
-+- Bart Simpson on chalkboard in episode BABF13
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers 11:32, Richard Delorme disait:
Je pense que si tu arrives avec un système de paquets aussi robuste que celui de Debian et un outil qui à partir des sources te génère un paquet tip top comme il faut sans rien faire du tout, tu intéresseras du monde. :)
Gentoo ? On le crée comment le paquet Gentoo ?
emerge --buildpkg <nom-du-paquet>
La bonne blague. On fait comment quand y'a pas de .emerge dispo ? -- NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE -+- Bart Simpson on chalkboard in episode BABF13
Vincent Bernat
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers 11:49, Richard Delorme disait:
Soit quasiment le triple de ce qu'utilise xine. Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?)
Personnellement, j'ai l'impression qu'ils réinventent un peu la roue. Beaucoup d'efforts pour quelque chose qui n'apporte pas grand chose au final. Ils auraient pris GTK, cela leur aurait sans doute simplifié la vie, évité des bugs propres à leur toolkit, etc.
ou non mais je constate juste (et apprécie) sa légèreté, pour obtenir un GUI tout à fait comparable à celui de gmplayer, sans dépendre de l'usine à gaz GTK+.
D'un autre côté, si ton seul critère, c'est le nombre de librairies, je ne te cacherai pas qu'il suffit de compiler en statique pour les diminuer. Depuis sa version 2, GTK est devenu très modulaire, ça se traduit en tout un tas de librairies. À moins de ne pas utiliser une seule application GTK, ça te coûte moins cher en mémoire que chaque application qui refait son propre toolkit.
Cela dit, pour Xine, ils laissent le choix puisqu'il y a toujours xine-ui pour les uns et gxine pour les autres.
et pas mal de trucs sont collés dans la libxine, il faut donc regarder les dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car cela ne rajoute pas de nouvelles dépendances.
En effet, tout est compilé en statique. Cela dit, mplayer fait la même chose pour ce qui n'est pas du GUI. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers
11:49, Richard Delorme <abulmo@nospam.fr> disait:
Soit quasiment le triple de ce qu'utilise xine.
Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?)
Personnellement, j'ai l'impression qu'ils réinventent un peu la
roue. Beaucoup d'efforts pour quelque chose qui n'apporte pas grand
chose au final. Ils auraient pris GTK, cela leur aurait sans doute
simplifié la vie, évité des bugs propres à leur toolkit, etc.
ou non mais je constate juste (et apprécie) sa légèreté, pour
obtenir un GUI tout à fait comparable à celui de gmplayer, sans
dépendre de l'usine à gaz GTK+.
D'un autre côté, si ton seul critère, c'est le nombre de librairies,
je ne te cacherai pas qu'il suffit de compiler en statique pour les
diminuer. Depuis sa version 2, GTK est devenu très modulaire, ça se
traduit en tout un tas de librairies. À moins de ne pas utiliser une
seule application GTK, ça te coûte moins cher en mémoire que chaque
application qui refait son propre toolkit.
Cela dit, pour Xine, ils laissent le choix puisqu'il y a toujours
xine-ui pour les uns et gxine pour les autres.
et pas mal de trucs sont collés dans la libxine, il faut donc
regarder les dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car
cela ne rajoute pas de nouvelles dépendances.
En effet, tout est compilé en statique. Cela dit, mplayer fait la même
chose pour ce qui n'est pas du GUI.
--
if (user_specified)
/* Didn't work, but the user is convinced this is the
* place. */
2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
OoO En cette fin de matinée radieuse du mardi 30 décembre 2003, vers 11:49, Richard Delorme disait:
Soit quasiment le triple de ce qu'utilise xine. Xine utilise son propre toolkit (un peu pourri au passage)
Je ne sais pas s'il est pourri (sur quel critère ?)
Personnellement, j'ai l'impression qu'ils réinventent un peu la roue. Beaucoup d'efforts pour quelque chose qui n'apporte pas grand chose au final. Ils auraient pris GTK, cela leur aurait sans doute simplifié la vie, évité des bugs propres à leur toolkit, etc.
ou non mais je constate juste (et apprécie) sa légèreté, pour obtenir un GUI tout à fait comparable à celui de gmplayer, sans dépendre de l'usine à gaz GTK+.
D'un autre côté, si ton seul critère, c'est le nombre de librairies, je ne te cacherai pas qu'il suffit de compiler en statique pour les diminuer. Depuis sa version 2, GTK est devenu très modulaire, ça se traduit en tout un tas de librairies. À moins de ne pas utiliser une seule application GTK, ça te coûte moins cher en mémoire que chaque application qui refait son propre toolkit.
Cela dit, pour Xine, ils laissent le choix puisqu'il y a toujours xine-ui pour les uns et gxine pour les autres.
et pas mal de trucs sont collés dans la libxine, il faut donc regarder les dépendances de celles-ci si on veut être juste. :)
Non, en comptant les dépendances de libxine ça ne change rien car cela ne rajoute pas de nouvelles dépendances.
En effet, tout est compilé en statique. Cela dit, mplayer fait la même chose pour ce qui n'est pas du GUI. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
Stephane TOUGARD
Patrice Karatchentzeff wrote:
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et
Je savais pas que t'avais un compte sur mes machines !!!
Ceci dit, parler de nouveaute et mettre ca en parallele avec la reunion d'antiquites qu'est une Debian, ca me parait un poil deplace.
t'en reste là. L'avantage du libre, c'est que chacun fait comme il veut...
Je fais comme je veux sur n'importe quel Unix, qu'il soit Libre ou pas. Cette capacite d'adaptation n'est pas une invention du Libre mais d'Unix. Mais la, il faudrait un poil savoir ce qu'est Unix pour en parler.
-- http://www.unices.org
Patrice Karatchentzeff wrote:
C'est sûr que le système de paquets est une nouveauté dans le monde
UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous
Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la
joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et
Je savais pas que t'avais un compte sur mes machines !!!
Ceci dit, parler de nouveaute et mettre ca en parallele avec la reunion
d'antiquites qu'est une Debian, ca me parait un poil deplace.
t'en reste là. L'avantage du libre, c'est que chacun fait comme il
veut...
Je fais comme je veux sur n'importe quel Unix, qu'il soit Libre ou pas.
Cette capacite d'adaptation n'est pas une invention du Libre mais
d'Unix. Mais la, il faudrait un poil savoir ce qu'est Unix pour en
parler.
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris). Mais comme c'est une avancée, soit tu t'y mets, soit tu la joues Stéphane, tu gardes UNIX tel qu'il était il y a vingt ans, et
Je savais pas que t'avais un compte sur mes machines !!!
Ceci dit, parler de nouveaute et mettre ca en parallele avec la reunion d'antiquites qu'est une Debian, ca me parait un poil deplace.
t'en reste là. L'avantage du libre, c'est que chacun fait comme il veut...
Je fais comme je veux sur n'importe quel Unix, qu'il soit Libre ou pas. Cette capacite d'adaptation n'est pas une invention du Libre mais d'Unix. Mais la, il faudrait un poil savoir ce qu'est Unix pour en parler.
-- http://www.unices.org
Patrice Karatchentzeff
Stephane TOUGARD writes:
[...]
Je fais comme je veux sur n'importe quel Unix, qu'il soit Libre ou pas.
Tiens, explique-moi comment tu recompiles le noyau d'un AIX, HP-UNIX ou bien d'un VMS...
Pour faire ce que tu veux, il y a un moment où il faut avoir les sources... Seules Unix libres le permettent.
Je ne dis pas que c'est pas bien, mais quand on doit
utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris).
Désolé de te contredire, mais il y a un système de paquets avec résolution de dépendance assez simple à utiliser sur IRIX depuis la version 3.3 (~1989) au moins. Donc comme nouveauté on fait mieux. Je ne reproche pas à Debian d'avoir un système de paquets, je reproche à Debian d'avoir un système de construction de paquets horriblement compliqué.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <87d6a6ry63.fsf@belledonne.chartreuse.fr>,
p.karatchentzeff@free.fr disait...
Je ne dis pas que c'est pas bien, mais quand on doit
utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop
compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde
UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous
Solaris).
Désolé de te contredire, mais il y a un système de paquets avec
résolution de dépendance assez simple à utiliser sur IRIX depuis la
version 3.3 (~1989) au moins. Donc comme nouveauté on fait mieux. Je ne
reproche pas à Debian d'avoir un système de paquets, je reproche à Debian
d'avoir un système de construction de paquets horriblement compliqué.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Je ne dis pas que c'est pas bien, mais quand on doit
utiliser SOlaris, IRIX, Linux et en plus Debian c'est chiant, c'est trop compliqué.
C'est sûr que le système de paquets est une nouveauté dans le monde UNIX propriétaire (bien qu'il y ait eu des précédents, au moins sous Solaris).
Désolé de te contredire, mais il y a un système de paquets avec résolution de dépendance assez simple à utiliser sur IRIX depuis la version 3.3 (~1989) au moins. Donc comme nouveauté on fait mieux. Je ne reproche pas à Debian d'avoir un système de paquets, je reproche à Debian d'avoir un système de construction de paquets horriblement compliqué.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , disait...
Tiens, explique-moi comment tu recompiles le noyau d'un AIX, HP-UNIX ou bien d'un VMS...
Ceux-là personnellement je ne sais pas. Sous IRIX c'est très très dur : "autoconfig" pour qu'il soit installé directement en /unix, ou "lboot" pour qu'il soit créé en tant que /unix.new (pour décider de ce qu'on veut en faire), achtement difficile. Ah oui, il faut être root, quand même.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <87smj2q70k.fsf@belledonne.chartreuse.fr>,
p.karatchentzeff@free.fr disait...
Tiens, explique-moi comment tu recompiles le noyau d'un AIX, HP-UNIX
ou bien d'un VMS...
Ceux-là personnellement je ne sais pas. Sous IRIX c'est très très dur :
"autoconfig" pour qu'il soit installé directement en /unix, ou "lboot"
pour qu'il soit créé en tant que /unix.new (pour décider de ce qu'on veut
en faire), achtement difficile. Ah oui, il faut être root, quand même.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Tiens, explique-moi comment tu recompiles le noyau d'un AIX, HP-UNIX ou bien d'un VMS...
Ceux-là personnellement je ne sais pas. Sous IRIX c'est très très dur : "autoconfig" pour qu'il soit installé directement en /unix, ou "lboot" pour qu'il soit créé en tant que /unix.new (pour décider de ce qu'on veut en faire), achtement difficile. Ah oui, il faut être root, quand même.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
