totof2000 a écrit 9656 commentaires

Disons que si j'avais eu le choix j'aurais choisi autre chose que Debian, mais là je ne l'ai pas, il me faut du redhat ou centos. Finalement ça a marché avec un phénomène étrange en désactivant ACPI + APIC, j'ai réussi l'installation mais impossible d'avoir une interface réseau qui fonctionne (je n'ai d'ailleus pas eu de proposition de configration réseau lors de l'installation). Il a fallu que je réactive l'ACPI et l'APIC au niveau du grub pour que ça marche et que je configure le réseau après.

Possible, mais ce que je reproche dans ce cas à la distrib, c'est de ne pas laisser une possibilité d'installation avancée en mode texte, J'ai réussi une installation complète en mode texte, mais le partitionnement ne me plaisait pas. J'aurais aimé pouvoir le personnaliser. Puis il faut avouer que l'installateur en mode graphique de centos n'est pas des plus rapides ….

Je passerai probablement par la suite via un kickstart, mais là je suis dans un problème d'oeuf et de poule ….

Il m'a suffit de désactiver ACPI et APIC lors du boot. Mais je trouve lamentable de ne pas proposer un partitionnement personnalisé au bboot texte ….

Merci, je vais tester ça. S'il y a d'autres idées, je suis preneur.

Cordialement.

Ben je viens de devoir le faire, mais c'est paeut-être parce que je ne veux pas installer la dernière verson,

De toute façon, comme ça me gave, je vais essayer avec un openjdk.

Je suis assez d'accord avec toi : je trouve Windows contre-productif dans l'utilisation que j'en ai tous les jours. Windows n'est pas ue interface pour travailler mais une interface pour bricoler ou jouer.

Si pour une raison X ou Y tu passes ton temps à lancer 10000 process qui vont te modifier ta crontab en même temps, c'est que tu as un gros problème.

Ensuite si tu n'es pas capable dans ton oganisation de définir une méthode de gestion des cron unique (on parlait ici de l'interfaçage avec d'autres outils de gestion de config par exemple), c'est plus un pb d'organisation qu'un pb d'outil. L'outil doit être capable en amont de gérer les modifications multiples de plusieurs personnes en simultané. Et si tu utilises ce genre d'outil, ce n'est pas non plus pour t'amuser à éditer les fichiers con à la main.

Il y a parfois une nécessité d'imprimer (factures, ou documents administratifs, pratique par exemple d'imprimer sa déclaration de revenus que la ville te demande pour pouvoir inscrire ton enfant à la cantine).

Pour certains (comme mon épouse), le besoin et le plaisir de faire des choses "jolies" sur papier (maque-pages personnalisés par exemple ou trucs de ce genre). C'est d'ailleurs pour ça que je ne me suis pas (encore) débarassé de mon imprimante couleur.

Après, il faut savoir faire la part des choses, et ne pas imprimer inutilement, mais ce n'est pas parce que certains peuvent se passer d'imprimante que tout le monde le peut. Et imprimer au boulot des trucs perso, personnellement ça me gène.

Ah puis parfois, c'est pratique d'avoir un dcument sous forme papier lorsque tu sais que tu n'auras pas accès au net pendant un certain temps (pendant que tu réinstalles et reconfigure une machine par exemple, ou pour lire dans les transports).

Les goûts et les couleurs… l'indentation a pour gros avantage que les blocs de code sont ce que tu vois lorsque tu lis.

Je ne suis pas contre l'indentation obligatoire, loin de là, par contre là on est dans un des paradoxes de Python et de sa règle "Explicit is better than implicit." ou justement l'indentation est quelque chose d'implicite, contrairement à une accolade ou un autre délimiteur qui lui est explicite. Autre paradoxe : explicite et duck typing me paraissent comlêtement contradictoires.

C'est sa présence dans la liste des paramètres qui te gène, ou bien son utilisation obligatoire pour accéder aux attributs de l'objet ?
Sa présence dans la liste des paramètres

Explicit is better than implicit.

Ca c'est une grosse connerie. Le fait de déclarer une fonction au niveau d'un bloc définissant un objet est largement explicite pour en déduire qu'il s'agit d'une méthode de l'objet. Il faudrait être complètement demeuré pour déclarer à ce niveau quelque chose qui ne soit pas propre à l'objet. Et globalement, etre explicite à l'excès pousse à se répéter sans cesse, et c'est ce que je reproche justement à Python (Perl quant à lui est dans l'autre extrême, mais ce n'est pas le sujet).

Mais pourquoi passer par Perl ? Après tu m'étonnes qu'on va dire que cron n'est pas user friendly …

Oups, j'mes gouré … :)

c'est crontab -l >/tmp/fichier_cron

Le reste ne change pas.

Pas besoin de sighup, regarde mon commentaire au dessus …Quand je ds que crontab est user friendly, on veut pas me croire, mais pourtant les faits sont là.

crontab >/tmp/fichier_cron

Tu fais tes modifs …

crontab /tmp/fichier_cron pour prise en compte. Et le tour est joué.

Accessoirement, ça permet de revenir en arrière quand tu fais des modifs ….

Personnellement, ce que j'ai remarqué là ou je suis passé, c'est que les cas tordus d'utilisation de cron nécessitant de lire la doc sont des cas ou un ordonnanceur plus évolué ferait mieux l'affaire.

Il ne faut pas oublier que cron n'est fait à la base que pour déclencher des taches périodiques avec ordonnancement simple.

Merci, je vais jeter un oeil. Si je peux regrouper le tout dans lemême "moteur", ce sera plus simple … Je reste ouvert à toute autre solution. Je préfèrerais avoir à éviter de développer mon propre moteur de blog :).

j'ai besoin d'un blog en plus d'un wiki :). Ils n'ont pas la même utilité … Je ne veux pas d'un blog ou je racconte ma vie, mais plutôt un blog qui me permettrait de prendre des notes dans le temps sur les divers projets perso qui sont en cours chez moi. Le wiki permet peut-être de le faire mais ce n'est pas spécialement fait pour. Le wiki, je me le réserve pour autre chose (rédaction de documents plus "formels" tels que doc d'utilisation, docs techniqies, etc …).

Je ne comprends pas ta réponse. Qu'entends-tu par "translateur de langage", "langage plus commun" et "publication plus classique" ?

Mon besoin est clair : transformer des billets de blog en docbook, avec possibilité d'automatiser la chaine de transformation. J'ai une iée précise en tête pour faire ça (que je n'ai pas envie de dire ici pour le moment). Si direct vers docbook n'est pas possible, je peux passer par un format intermédiaire qui lui serait transformable en docbook ….

Je préfère largement un GUI "à la con"
et moi une cli "à la cron" …. :)

ce GUI est plus rapide que le fichier cron.

Pas pour des modifications en masse de plusieurs scripts dont le chemin d'accès aurait changé dans un fichier cron de plusieurs dizaines de lignes (ce qui m'est arivé il n'y a pas tres longtemps d'ailleurs). Si j'avais du modifier les chemins 1 à 1 via GUI, j'y serais encore …

Ben disons que j'ai peut-être dérivé …. parce que j'ai eu affaire ces derniers temps à des GUI mal fichues …

les fichiers texte c'est pour le débuguage, le scripting et les masochistes :) )

Pas d'accord … Il y a bien des fois ou je peste contre des interfaces graphiques censées être "user friendly" mais qui ne le sont pas parce que la logique de l'interface est mal pensée (et bien souvent elle ne peut pas être pensée autrement), alors qu'un bête fichier texte permet d'avoir une vue d'ensemble et de naviguer dans le fichier sans se prendre la tête à cliquer dans tous les sens : au pire j'ouvre deux fenetres et visualise le fichier si une partie de celui-ci nécessite de comprendre une autre partie pas visible à l'écran.

Dans un GUI ce n'est pas toujours possible d'ouvrir plusieurs instances de la même fenetre mais qui afficherait des paramètres situés à des endroits différents (parfois possible avec des interfaces web avec les onglets mais pas toujours).

Alors attention, ne me faites pas dire ce que je n'ai pas dit : la GUI est pratique dans certains cas (notamment lorsqu'on ne sait pas trop ce que l'n fait), mais dans eaucoup de cas celle-ci n'est pas appropriée.

Ya rien de plus user friendly que vi ….

.

.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
(ça c'est pour achever ceux qui ont failli s'étrangler lorsque j'ai parlé du côté user-friendly de cron).

J'irais même jusqu'à dire qu'avec un bon IDE tu ne les tapes pas …
Ah non, pitié, pas ça …. Je me bats assez avec ce genre d'horreur qui t'insère des trucs dont tu ne veux pas parce qu'il s'imagine mieux que toi savoir ce que tu veux faire.

Na, vi ça va encore (mis à part VIM et ses colorations syntaxiques ou indentations par défaut qui sont assez horribles).
Emacs dans le genre 'outil pour extra-terrestres ayant 20 doigts par mains" est pas mal dans son genre.

Personnellement je l'utilise sans problème, même s'il faut de temps en temps que je reprenne la doc pour m'assurer de bien faire ce que je veux. après il faut savoir ce que l'on entend par "user friendly". Pour moi un outil "user friendly" est un outil qui ne prend pas des plombes à ce charger, et dans lequel il ne faut pas cliquer 5O fois pour dérouler 13000 fenetres juste pour ajouter ou modifier un paramètre.