J'avais déjà réussi à récupérer l'intégralité d'un mail que j'étais en train de rédiger en ssh avec vim par ce moyen, en ne l'ayant évidemment jamais enregistré :-)
Euh, je ne dirais pas que c'est "juste rigolo". Il y a un réel esprit pédagogique derrière, quand même.
L'exemple en lui même, c'est clair qu'il ne nous intéresse pas (qui voudrait d'un binaire qui ne fait que retourner 42 ?). Mais le voyage qui nous est offert est très riche en informations (comme tu le dis effectivement, il nous explique tout octet par octet), donc libre à toi d'en reprendre les infos qui t'intéressent dans le cadre de ton projet ou tes applications futures.
Rigolo peut être, mais en tout cas très instructif, et complètement à l'inverse du concours du compilateur qui fournit le binaire le plus gros sur un code source qui ne fait rien (ÇA, c'est "rigolo, c'est tout" ) :-)
Il y a beaucoup de vrai dans ce que tu dis, et d'ailleurs mon objectif n'est clairement pas de faire des binaires tout petits : sur un OS complet, ce serait une perte de temps ridicule que de chercher à optimiser entrifouillant l'assembleur à la main, binaire par binaire.
En fait, je pense que beaucoup l'auront compris, l'idée est d'avoir une sorte de guide qui permette de mieux comprendre le mécanisme d'exécution d'un programme. Pour quelqu'un qui fait de l'embarqué et/ou de la compilation croisée, c'est un plus de bien saisir ces mécanismes. Et moi, je recherche justement une compréhension aussi complète que possible desdits mécanismes (notamment en ce qui concerne les librairies dynamiques).
Et le site cité en premier commentaire est un excellent point de départ, explications reproductibles à l'appui. La théorie, je peux l'avoir sur n'importe quel autre site de même degré de sérieux; j'avais surtout besoin de la pratique pour mieux saisir ces mécanismes.
Moi, en pratique, c'est mon serveur X qui vautre.
car j'ai un script qui fait un "while(true); do xcompmgr; done" grosso modo..
Donc je suppose que ça fait boum.
La solution ? arreter de jouer :-)
L'autre probleme, c'est la gestion des ombrages avec Xosd et Gdesklets par exemple.
Je vais suivre Xgl de très près car je suis très intéressé par les évolutions de l'environnement desktop sous linux..
Mais je me demande une chose quand même : qu'est ce qui différencie vraiment Xgl de X.org ? X.org n'est pas basé sur OpenGL, c'est ça ?
Je ne vois pas en quoi il est "indigne" de cracher sur les LL.
Au contraire, comme César avec ses échecs, il faut en tirer parti.
Je suis moi même un puriste des LL et je déteste presque maladivement les petits gars qui jurent haut et fort que Windows, c'est "trop bien" parce que "simple", "intuitif", qu"on peut y jouer à "Halo" ou "Doom 3" et que de toutes façons l'argument de la gratuité du LL ne colle pas puisque "j'ai même pas payé mon Windows"...
Très honnêtement, l'analyse de M. de la Clergerie prête plus à réfléchir qu'à vomir. Il faut surtout garder à l'esprit que les principaux acteurs de l'informatique actuellement ne sont pas les particuliers mais les entreprises. Et crois moi, le point de vue d'un PDG n'a rien à voir avec celui d'un ingénieur en info et encore moins avec celui d'un particulier.
Ce que je veux dire par là, c'est que LDLC a testé les LL probablement de leur plein gré, mais qu'ils ont vraisemblablement du faire face à des imprévus ou des obstacles difficiles à surmonter. Quels sont ils ? C'est la question qu'il faut leur poser. Le peu qu'ils indiquent dans l'article ne sont effectivement pas très constructifs (depuis quand est on a la merci des développeurs de LL ?? Autant en dire de même concernant M$), d'autant plus que leur choix de la solution "de tranquilité" leur lie en réalité les mains auprès de M$. J'aurai donc plutôt tendance à penser à une sorte de "coup de pute" par dessous la table, préparé à l'avance. Mais ce serait tomber dans la paranoïa et je refuse de tomber dans ce genre d'allégations sans preuves. Mais quand même, j'y pense, et j'imagine que beaucoup aussi.
C'est donc plus la politique de M$ qu'il faudrait fustiguer, et non LDLC, que j'aurai plutôt tendance à considérer comme une sorte de victime dans cette affaire. (enfin, "victime".. c'est à prendre avec des pincettes). Si je n'acheterai plus (en fait je n'ai jamais été chez eux) chez eux, c'est simplement parce que leur décision de se laisser faire par le plus gros éditeur me déçoit, pas parce qu'ils ont choisi M$ au lieu de LL, ce qui est leur plein droit.
Et à propos, j'ai beau être un fana de LL, je vais acheter mon matos dans le même magasin rue de Charenton, bien que toutes leurs machines soient sour Windows XP ... Chose que je trouve des plus normales.
Mais je ne dis pas que je ne sauterai pas de joie s'ils utilisaient ne serait ce qu'une petite RedHat dans un coin..
(sauf si on n'est qu'un pisseur de code qui s'extasie sur le fait de coder une fonction en 30 lignes au lieu de 29).
Tu voulais pas dire l'inverse plutôt ? ;-)
J'aurai plutôt tendance à m'extasier devant une fonction codée en 29 lignes au lieu de 30 que l'inverse :-) Quoique pour une ligne de gagnée.. ;o)
En fait, les seuls navigateurs de fichiers qui me plaisent sont [...] (j'ai honte) l'explorateur Windows
Tu n'as pas à avoir honte : je suis moi-même un debianiste puriste, et pourtant je ne peux m'empêcher de considérer l'explorateur de windows comme un excellent logiciel. Si seulement il était plus stable que ça...
Ce que j'aime dedans, c'est sa façon de gérer l'arborescence.
Pour ma part, je me sers donc de nautilus, que je trouve superbe, mais je m'en sers le moins possible. Cela dit j'aurai aimé qu'il m'affiche les dossiers sous forme arborescente de taille plus petite, et avec l'arborescence un peu plus visible que cela...
Il reste un excellent explorateur, mais j'ai vraiment plutôt tendance à utiliser cd et ls pour naviguer dans le système de fichiers.. :-)
Je suis vraiment trop con :-)
caterm, c'est pour le chinois.
avec katerm, ça marche tout de suite mieux :-)
quelques explications de ma half-success story :
j'ai installé canna, kinput2-canna, jvim, aterm-ml et accessoirement mlterm.
il suffit de s'assurer que canna est bien lancé en tant que démon (cannastat, qui n'a rien à voir avec canal sat, du package debian canna-utils devrait renseigner à ce propos.. ). ensuite, ce qui est nécessaire et suffisant pour avoir du japonais en console :
et hop, Shit-espace marche !! Par contre j'ai pas compris pourquoi il faut mettre ja_JP.UTF-8 ? Car quand je fais un cat sur un fichier contenant du japonais au format UTF8, ça me sort n'importe quoi, alors qu'un cat sur un même fichier mais au format ISO-8859, ça marche.
Sinon, on peut lancer directement katerm, il gère le japonais tout seul comme un grand :-) (et non pas caterm, bon sang de baka que je suis !)
Par contre pour la saisie de japonais au clavier dedans, c'est une autre histoire :-/
Mais dans tous les cas, jvim m'affiche bien du japonais, et c'est superbe :-)
(jvim sous katerm ou mlterm)
J'ai pu récupérer toutes ces infos dans la debian reference, en français.. donc mangez-en !!
Par contre j'arrive pas encore à avoir un wrapper clavier pour canna avec mes applications gtk, comme gaim, ou encore mes applications comme firefox. ni avec katerm d'ailleurs :(
c'est un personnage (virtuel) du fameux roman "Neuromancer" ("Neuromancien" en Francais) de William Gibson.
Oh punaise, je l'avais lu il y a des années, et je n'avais jamais réussi à retrouver le nom depuis !!
Si c'est bien celui avec la catwoman bionique, je le recommande chaudement !! ;-)
je me suis lancé dans la même aventure pas plus tard qu'hier, et malgré les nombreux tutoriaux que j'ai pu trouver ça et là sur le net, je suis désespéré...
En effet, après une réinstallation des divers paquetages mentionnés (c'était trop le bordel après mes divers tests, donc j'ai tout supprimé pour n'installer que ceux dont j'avais besoin), je n'ai réinstallé que ceux relatifs à canna, uim, kinput, scim, aterm-ml et jvim. Malheureusement, depuis :
- uim-im-switcher ne m'affiche plus rien du tout
- uim-applet-gnome m'affiche "?" au lieu des trois boutons de switch
- je n'ai jamais réussi à obtenir la toolbox kinput2
- 'caterm' ne m'affiche plus du tout les caractères japonais (des blancs à la place)
seul Emacs sait continuer à gérer le japonais. Je constate donc une régression de mon système depuis que j'essaie d'avoir un clavier bilingue dans une majorité de mes applications, toutes gnome/gtk (à part OOo et les émulateurs de terminal en l'occurence, et également Firefox (il me semble)).
J'ai très visiblement manqué une marche quelquepart, mais j'avoue ne plus rien comprendre du tout : est ce que quelqu'un connaît ces problèmes , et éventuellement leur solution ?
Je confirme, étant moi même en période d'essai actuellement. Avant même de démarrer, on m'a dit que c'était 3 mois renouvelables, et qu'il y a peu de chances que ça ne soit pas renouvelé :-)
Je pars donc du principe que la période d'essai est de 6 mois. Et c'est valable aussi bien pour moi que pour tous mes camarades au même niveau (bac +5, diplôme d'ingé ou équivalent à la fac, première embauche)...
Tu aurais peut etre un argument à donner(sur le pkoi c pas propre) ou c'est juste une question d'esthétique?
le système de packages offert par ta distrib, il est centralisé.
si tu choisis d'avoir des sources non officielles pour obtenir d'autres packages, tu prends le risque de te retrouver avec des binaires vérolés, mais au moins ça reste relativement cohérent avec ta distrib car ça a été généralement pensé pour.
dans l'idée où tu n'as pas les packages pour une appli donnée, il te reste donc les sources pour recompiler une appli et l'installer dans /usr/local si tu es quelqu'un de consciencieux et méthodique.
le système autopackage n'est pas si mal que ça en soi, mais si c'est pour installer dans /usr/local des binaires que je n'ai PAS compilés moi-même et qui ne sont donc pas en cohérence avec mes librairies, il va installer lui même d'autres librairies et au final l'ensemble est forcément sale.
en clair : soit tu choisis un système de packaging cohérent, et tu optes pour les sources et le triplet ./configure && make && make install, soit tu utilises autopackage et tu n'as pas de système cohérent : dans 6 mois, un an, voire plus, tu te retrouveras avec un disque dur surchargé de librairies inutiles. chose qui me rappelle furieusement un certain OS.
Jusque là, je n'ai fait grosso modo que traduire l'état d'esprit de celui à qui tu posais (intelligemment, hein) la question, et cet avis se rapproche beaucoup du mien.
Cependant, je pense que tous ces problèmes n'auraient pas lieu d'être. S'il existe des outils tels que alien ou, mieux rpm2cpio + cpio, je trouve qu'autopackage en soi est une excellente idée. Reste à voir ça de plus près (je parle pour moi) et à voir quelle différence il propose par rapport au format cpio, qui est à mon sens totalement indépendant de la distrib...
si autopackage exécute des scripts de pré/post installation, alors je dis "non". Car il est tout simplement impossible de faire des shellscripts de gestion de packages qui soient portables sur TOUTES les distributions. Rien que pour t'en convaincre, jette un oeil à la manière dont chacune d'elles gère le système d'init ...
A propos, vu que tu en parles..
ça fait un petit bout de temps que j'entends des gars utiliser ksh, mais honnêtement je n'en ai jamais compris ses atouts.
Pour ma part, j'utilise zsh dont le système de completion et sa gestion des corrections des fautes de frappe me font gagner un temps formidable.
Ai-je intérêt à tester ksh ? J'en doute, mais je suis tellement curieux.. :-)
Nan, c'est juste que je n'aime pas le foot :-)
Donc j'aime pas les gens qui le voient comme un truc a part entiere, avec un mépris profond pour tous les autres sports :-)
Donc un jeu de foot, quoi que tu dises, c'est un jeu de sport et rien d'autre, non mais ho.
Pour moi, non. Un jeu de foot n'a rien à voir avec un jeu de tennis, un jeu de golf, ou un jeu simulant les épreuves d'athlétisme des derniers JO. D'ailleurs, des jeux de foot, il y en a plus que ceux que j'ai cité qui sont sortis cette année, et j'en suis déjà à 5 (en mélangeant simulation et gestion).
dans ce cas crée aussi une catégorie "jeux de rugby", "jeux de hockey", etc etc, car ce sont d'excellents jeux que tu n'as même pas pris la peine d'essayer, pour oser démarquer les jeux de foot, et seulement ceux là, des jeux de sport...
> on the EPIA boards you must pass ACPI=off at boot
> je sais pas comment le faire mais c'est a tester ...
normalement (je sais pas, j'ai jamais testé geekbox) tu as une invite au tout début du boot, voire un ecran de démarrage qui te cache tout mais attend qques secondes...
il faut juste appuyer sur TAB a ce moment la, afin d'avoir l'invite de commande de boot -a moins qu'elle ne s'affiche déjà.
Et il suffit juste de rajouter cette option après le nom du noyau/de l'entrée à démarrer.
Par exemple sur un linux classique, avec lilo, ca donnera un truc du genre :
LILO: linux ACPI=off
pour booter l'entree lilo "linux" avec l'option ACPI en question..
c'est étrange cette proportion des gens qui s'affolent dès que la charge CPU est de 2%...
Les gens sont simplement débiles :-)
Car sur mon athlon 1,2Ghz, avec un enregistrement de la télévision directement en DiVX en qualité moyenne, un rip de DVD en DiVX au même moment, je lis mes mp3 ou mate des vidéos et surfe sur le net aussi aisément que si mon UPC (francisation douteuse de 'CPU' :)) était à moins de 2% d'activité système + utilisateur... Or il est, d'après gkrellm, à 95-100% d'activité durant ce temps.
Et bien entendu, le tout est d'une fluidité exemplaire.
(J'avoue que je ne peux quand même pas m'amuser à jouer à Enemy Territory en même temps que tout ce bazar, mais quand même.. ;))
C'est marrant, les gens achètent du matos dernier cri en oubliant que le problème est essentiellement logiciel, et non matériel...
C'est idiot de taper rm -fr *, il faut taper rm -fr .* *, ou encore mieux : find -exec rm '{}' ';' si on a vraiment beaucoup trop de fichiers dans notre dossier :-)
Bon ok ok, ca n'est pas le problème, mais quand même...
# Et /proc/kcore ?
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Comment recuperer un rapport non sauvegarde.. Évalué à 2.
[^] # Re: Intéressant mais...
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Compilation et optimisation de l'empreinte mémoire. Évalué à 2.
L'exemple en lui même, c'est clair qu'il ne nous intéresse pas (qui voudrait d'un binaire qui ne fait que retourner 42 ?). Mais le voyage qui nous est offert est très riche en informations (comme tu le dis effectivement, il nous explique tout octet par octet), donc libre à toi d'en reprendre les infos qui t'intéressent dans le cadre de ton projet ou tes applications futures.
Rigolo peut être, mais en tout cas très instructif, et complètement à l'inverse du concours du compilateur qui fournit le binaire le plus gros sur un code source qui ne fait rien (ÇA, c'est "rigolo, c'est tout" ) :-)
[^] # ...oui mais non :-)
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Compilation et optimisation de l'empreinte mémoire. Évalué à 1.
En fait, je pense que beaucoup l'auront compris, l'idée est d'avoir une sorte de guide qui permette de mieux comprendre le mécanisme d'exécution d'un programme. Pour quelqu'un qui fait de l'embarqué et/ou de la compilation croisée, c'est un plus de bien saisir ces mécanismes. Et moi, je recherche justement une compréhension aussi complète que possible desdits mécanismes (notamment en ce qui concerne les librairies dynamiques).
Et le site cité en premier commentaire est un excellent point de départ, explications reproductibles à l'appui. La théorie, je peux l'avoir sur n'importe quel autre site de même degré de sérieux; j'avais surtout besoin de la pratique pour mieux saisir ces mécanismes.
[^] # Re: Voila ?
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Compilation et optimisation de l'empreinte mémoire. Évalué à 5.
Merci !
;)
[^] # Re: Voila ?
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Compilation et optimisation de l'empreinte mémoire. Évalué à 5.
Je ne sais comment te remercier... :-)
[^] # Re: xv et opengl
Posté par Hugues Hiegel (site web personnel) . En réponse au journal XServeur 3D. Évalué à 1.
car j'ai un script qui fait un "while(true); do xcompmgr; done" grosso modo..
Donc je suppose que ça fait boum.
La solution ? arreter de jouer :-)
L'autre probleme, c'est la gestion des ombrages avec Xosd et Gdesklets par exemple.
Je vais suivre Xgl de très près car je suis très intéressé par les évolutions de l'environnement desktop sous linux..
Mais je me demande une chose quand même : qu'est ce qui différencie vraiment Xgl de X.org ? X.org n'est pas basé sur OpenGL, c'est ça ?
[^] # Re: LDLC est quand même un revendeur très correct
Posté par Hugues Hiegel (site web personnel) . En réponse au journal LDLC et leur migration .... Évalué à 1.
Au contraire, comme César avec ses échecs, il faut en tirer parti.
Je suis moi même un puriste des LL et je déteste presque maladivement les petits gars qui jurent haut et fort que Windows, c'est "trop bien" parce que "simple", "intuitif", qu"on peut y jouer à "Halo" ou "Doom 3" et que de toutes façons l'argument de la gratuité du LL ne colle pas puisque "j'ai même pas payé mon Windows"...
Très honnêtement, l'analyse de M. de la Clergerie prête plus à réfléchir qu'à vomir. Il faut surtout garder à l'esprit que les principaux acteurs de l'informatique actuellement ne sont pas les particuliers mais les entreprises. Et crois moi, le point de vue d'un PDG n'a rien à voir avec celui d'un ingénieur en info et encore moins avec celui d'un particulier.
Ce que je veux dire par là, c'est que LDLC a testé les LL probablement de leur plein gré, mais qu'ils ont vraisemblablement du faire face à des imprévus ou des obstacles difficiles à surmonter. Quels sont ils ? C'est la question qu'il faut leur poser. Le peu qu'ils indiquent dans l'article ne sont effectivement pas très constructifs (depuis quand est on a la merci des développeurs de LL ?? Autant en dire de même concernant M$), d'autant plus que leur choix de la solution "de tranquilité" leur lie en réalité les mains auprès de M$. J'aurai donc plutôt tendance à penser à une sorte de "coup de pute" par dessous la table, préparé à l'avance. Mais ce serait tomber dans la paranoïa et je refuse de tomber dans ce genre d'allégations sans preuves. Mais quand même, j'y pense, et j'imagine que beaucoup aussi.
C'est donc plus la politique de M$ qu'il faudrait fustiguer, et non LDLC, que j'aurai plutôt tendance à considérer comme une sorte de victime dans cette affaire. (enfin, "victime".. c'est à prendre avec des pincettes). Si je n'acheterai plus (en fait je n'ai jamais été chez eux) chez eux, c'est simplement parce que leur décision de se laisser faire par le plus gros éditeur me déçoit, pas parce qu'ils ont choisi M$ au lieu de LL, ce qui est leur plein droit.
Et à propos, j'ai beau être un fana de LL, je vais acheter mon matos dans le même magasin rue de Charenton, bien que toutes leurs machines soient sour Windows XP ... Chose que je trouve des plus normales.
Mais je ne dis pas que je ne sauterai pas de joie s'ils utilisaient ne serait ce qu'une petite RedHat dans un coin..
[^] # Re: Pisseur de code
Posté par Hugues Hiegel (site web personnel) . En réponse au journal L'ergonomie en voilà un sacré mot.... Évalué à 1.
Tu voulais pas dire l'inverse plutôt ? ;-)
J'aurai plutôt tendance à m'extasier devant une fonction codée en 29 lignes au lieu de 30 que l'inverse :-) Quoique pour une ligne de gagnée.. ;o)
[^] # Re: rox
Posté par Hugues Hiegel (site web personnel) . En réponse au journal XFCE 4.2 est sorti !. Évalué à 1.
Tu n'as pas à avoir honte : je suis moi-même un debianiste puriste, et pourtant je ne peux m'empêcher de considérer l'explorateur de windows comme un excellent logiciel. Si seulement il était plus stable que ça...
Ce que j'aime dedans, c'est sa façon de gérer l'arborescence.
Pour ma part, je me sers donc de nautilus, que je trouve superbe, mais je m'en sers le moins possible. Cela dit j'aurai aimé qu'il m'affiche les dossiers sous forme arborescente de taille plus petite, et avec l'arborescence un peu plus visible que cela...
Il reste un excellent explorateur, mais j'ai vraiment plutôt tendance à utiliser cd et ls pour naviguer dans le système de fichiers.. :-)
[^] # I am dumb !
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Saisir du japonais sous Linux. Évalué à 1.
caterm, c'est pour le chinois.
avec katerm, ça marche tout de suite mieux :-)
quelques explications de ma half-success story :
j'ai installé canna, kinput2-canna, jvim, aterm-ml et accessoirement mlterm.
il suffit de s'assurer que canna est bien lancé en tant que démon (cannastat, qui n'a rien à voir avec canal sat, du package debian canna-utils devrait renseigner à ce propos.. ). ensuite, ce qui est nécessaire et suffisant pour avoir du japonais en console :
kinput2&
export XMODIFIERS="@im=kinput2"
LC_ALL=ja_JP.UTF-8 mlterm
et hop, Shit-espace marche !! Par contre j'ai pas compris pourquoi il faut mettre ja_JP.UTF-8 ? Car quand je fais un cat sur un fichier contenant du japonais au format UTF8, ça me sort n'importe quoi, alors qu'un cat sur un même fichier mais au format ISO-8859, ça marche.
Sinon, on peut lancer directement katerm, il gère le japonais tout seul comme un grand :-) (et non pas caterm, bon sang de baka que je suis !)
Par contre pour la saisie de japonais au clavier dedans, c'est une autre histoire :-/
Mais dans tous les cas, jvim m'affiche bien du japonais, et c'est superbe :-)
(jvim sous katerm ou mlterm)
J'ai pu récupérer toutes ces infos dans la debian reference, en français.. donc mangez-en !!
Par contre j'arrive pas encore à avoir un wrapper clavier pour canna avec mes applications gtk, comme gaim, ou encore mes applications comme firefox. ni avec katerm d'ailleurs :(
[^] # Re: Wintermute...
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Mais qui c'est ce wintermute ?. Évalué à 1.
Oh punaise, je l'avais lu il y a des années, et je n'avais jamais réussi à retrouver le nom depuis !!
Si c'est bien celui avec la catwoman bionique, je le recommande chaudement !! ;-)
# Debian : pas mieux :(
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Saisir du japonais sous Linux. Évalué à 1.
je me suis lancé dans la même aventure pas plus tard qu'hier, et malgré les nombreux tutoriaux que j'ai pu trouver ça et là sur le net, je suis désespéré...
En effet, après une réinstallation des divers paquetages mentionnés (c'était trop le bordel après mes divers tests, donc j'ai tout supprimé pour n'installer que ceux dont j'avais besoin), je n'ai réinstallé que ceux relatifs à canna, uim, kinput, scim, aterm-ml et jvim. Malheureusement, depuis :
- uim-im-switcher ne m'affiche plus rien du tout
- uim-applet-gnome m'affiche "?" au lieu des trois boutons de switch
- je n'ai jamais réussi à obtenir la toolbox kinput2
- 'caterm' ne m'affiche plus du tout les caractères japonais (des blancs à la place)
seul Emacs sait continuer à gérer le japonais. Je constate donc une régression de mon système depuis que j'essaie d'avoir un clavier bilingue dans une majorité de mes applications, toutes gnome/gtk (à part OOo et les émulateurs de terminal en l'occurence, et également Firefox (il me semble)).
J'ai très visiblement manqué une marche quelquepart, mais j'avoue ne plus rien comprendre du tout : est ce que quelqu'un connaît ces problèmes , et éventuellement leur solution ?
[^] # Re: L'entreprenariat aussi
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Le stagiaire, c'est pas cher.... Évalué à 2.
Je pars donc du principe que la période d'essai est de 6 mois. Et c'est valable aussi bien pour moi que pour tous mes camarades au même niveau (bac +5, diplôme d'ingé ou équivalent à la fac, première embauche)...
[^] # Re: relis toi gros naze !!!!
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Un grep recursif en shell. Évalué à 1.
[^] # Re: Vivement que ça se démocratise... Mon Dieu NON !
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Autopackage. Évalué à 2.
le système de packages offert par ta distrib, il est centralisé.
si tu choisis d'avoir des sources non officielles pour obtenir d'autres packages, tu prends le risque de te retrouver avec des binaires vérolés, mais au moins ça reste relativement cohérent avec ta distrib car ça a été généralement pensé pour.
dans l'idée où tu n'as pas les packages pour une appli donnée, il te reste donc les sources pour recompiler une appli et l'installer dans /usr/local si tu es quelqu'un de consciencieux et méthodique.
le système autopackage n'est pas si mal que ça en soi, mais si c'est pour installer dans /usr/local des binaires que je n'ai PAS compilés moi-même et qui ne sont donc pas en cohérence avec mes librairies, il va installer lui même d'autres librairies et au final l'ensemble est forcément sale.
en clair : soit tu choisis un système de packaging cohérent, et tu optes pour les sources et le triplet ./configure && make && make install, soit tu utilises autopackage et tu n'as pas de système cohérent : dans 6 mois, un an, voire plus, tu te retrouveras avec un disque dur surchargé de librairies inutiles. chose qui me rappelle furieusement un certain OS.
Jusque là, je n'ai fait grosso modo que traduire l'état d'esprit de celui à qui tu posais (intelligemment, hein) la question, et cet avis se rapproche beaucoup du mien.
Cependant, je pense que tous ces problèmes n'auraient pas lieu d'être. S'il existe des outils tels que alien ou, mieux rpm2cpio + cpio, je trouve qu'autopackage en soi est une excellente idée. Reste à voir ça de plus près (je parle pour moi) et à voir quelle différence il propose par rapport au format cpio, qui est à mon sens totalement indépendant de la distrib...
si autopackage exécute des scripts de pré/post installation, alors je dis "non". Car il est tout simplement impossible de faire des shellscripts de gestion de packages qui soient portables sur TOUTES les distributions. Rien que pour t'en convaincre, jette un oeil à la manière dont chacune d'elles gère le système d'init ...
# ksh..
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Un grep recursif en shell. Évalué à 3.
ça fait un petit bout de temps que j'entends des gars utiliser ksh, mais honnêtement je n'en ai jamais compris ses atouts.
Pour ma part, j'utilise zsh dont le système de completion et sa gestion des corrections des fautes de frappe me font gagner un temps formidable.
Ai-je intérêt à tester ksh ? J'en doute, mais je suis tellement curieux.. :-)
[^] # Re: relis toi gros naze !!!!
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Un grep recursif en shell. Évalué à 2.
"Et ça a fait des études".
J'aime vraiment pas le ton de tes deux posts, alors qu'il proposait une fonction shell fort sympathique - et utile de surcroît -
[^] # Re: bon
Posté par Hugues Hiegel (site web personnel) . En réponse à la dépêche Interview de Linus Torvalds. Évalué à -3.
[^] # Re: Sérieusement...
Posté par Hugues Hiegel (site web personnel) . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 6.
Donc j'aime pas les gens qui le voient comme un truc a part entiere, avec un mépris profond pour tous les autres sports :-)
Donc un jeu de foot, quoi que tu dises, c'est un jeu de sport et rien d'autre, non mais ho.
[^] # Re: Sérieusement...
Posté par Hugues Hiegel (site web personnel) . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 3.
dans ce cas crée aussi une catégorie "jeux de rugby", "jeux de hockey", etc etc, car ce sont d'excellents jeux que tu n'as même pas pris la peine d'essayer, pour oser démarquer les jeux de foot, et seulement ceux là, des jeux de sport...
[^] # Re: Conf reduite, intervention Minime
Posté par Hugues Hiegel (site web personnel) . En réponse au journal Divx sous config Restreinte. Évalué à 3.
> je sais pas comment le faire mais c'est a tester ...
normalement (je sais pas, j'ai jamais testé geekbox) tu as une invite au tout début du boot, voire un ecran de démarrage qui te cache tout mais attend qques secondes...
il faut juste appuyer sur TAB a ce moment la, afin d'avoir l'invite de commande de boot -a moins qu'elle ne s'affiche déjà.
Et il suffit juste de rajouter cette option après le nom du noyau/de l'entrée à démarrer.
Par exemple sur un linux classique, avec lilo, ca donnera un truc du genre :
LILO: linux ACPI=off
pour booter l'entree lilo "linux" avec l'option ACPI en question..
Voila, j'espere t'avoir donné suffisamment d'infos :-/
# porn-get install hotbabe
Posté par Hugues Hiegel (site web personnel) . En réponse au journal hot-babes. Évalué à 2.
cf http://www.lesbian.mine.nu/(...)
en francais : http://lesbian.gnu.tsunanet.net/(...)
(Je me décharge de TOUTE responsabilité envers tout ce que vous pourrez lire ou voir sur ces liens !! Vous êtes prévenus :-))
# le mou et le dur.
Posté par Hugues Hiegel (site web personnel) . En réponse au journal la puissance d'un ordi. Évalué à 1.
Les gens sont simplement débiles :-)
Car sur mon athlon 1,2Ghz, avec un enregistrement de la télévision directement en DiVX en qualité moyenne, un rip de DVD en DiVX au même moment, je lis mes mp3 ou mate des vidéos et surfe sur le net aussi aisément que si mon UPC (francisation douteuse de 'CPU' :)) était à moins de 2% d'activité système + utilisateur... Or il est, d'après gkrellm, à 95-100% d'activité durant ce temps.
Et bien entendu, le tout est d'une fluidité exemplaire.
(J'avoue que je ne peux quand même pas m'amuser à jouer à Enemy Territory en même temps que tout ce bazar, mais quand même.. ;))
C'est marrant, les gens achètent du matos dernier cri en oubliant que le problème est essentiellement logiciel, et non matériel...
[^] # Re: Debian Sarge...
Posté par Hugues Hiegel (site web personnel) . En réponse au message [Terminal] Protéger le contenu d'un répertoire contre les fausses manipulations. Évalué à 2.
Tout programme correctement écrit s'appelle sous la forme "binaire [options...] [fichiers...]".
[^] # Re: Debian Sarge...
Posté par Hugues Hiegel (site web personnel) . En réponse au message [Terminal] Protéger le contenu d'un répertoire contre les fausses manipulations. Évalué à 2.
Bon ok ok, ca n'est pas le problème, mais quand même...