Krunch a écrit 4203 commentaires

Autre avantage de less: si on a mis 'eval "$(lesspipe)"' ou 'eval "$(lessfile)"' dans sont .*shrc, less peut rendre certains fichier lisibles directement (genre les .gz, les .pdf,...). Sinon il y a aussi run-mailcap(1).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En attendant la prochaine énigme de MISC, tu peux essayer celles ci (si c'est pas encore fait):
http://www.try2hack.nl/(...)
http://honeynet.org/misc/chall.html(...) (yen a qui sont passées dans MISC je pense)
http://vortex.labs.pulltheplug.com/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

UUOC: http://laku19.adsl.netsonic.fi/era/unix/award.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca répond pas vraiment à la question mais pour filtrer par après, il y a uniq(1). Sinon il y a surement moyen de configurer syslogd(8) pour faire ça. Ya aussi un article qui est passé récemment sur Slashdot sur l'utilisation de filtres bayesiens (c'est français ça ?) pour filtrer les logs: http://developers.slashdot.org/article.pl?sid=04/12/29/179203(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux peut-être remplacer les proxy HTTP/SMTP/... par des redirections au niveau IP avec iptables. Ca te fait des processes en moins et pas besoin de configurer toutes tes applications pour utiliser le proxy (bon ça fait pas énormément d'avantages en fait).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

les formats avec perte comme le png

PNG est un format *sans* perte (lossless)

http://w3c.org/Graphics/PNG/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Créer un .deb ou .rpm à partir des sources a priori c'est pas si compliqué que ça et pour un grand réseau ça vaut surement le coup de se casser un peu la tête pour le faire s'il n'existe pas déjà. Au pire tu fais une installation à partir des sources dans une sandbx et/ou en utilisant Stow, tu fais un tar.gz qui peut s'installer d'un coup de tar xzf pour ta distribution et pour le déploiement ensuite, je vois pas plus simple.

Par ailleurs Synaptics/aptitude est une bonne réponse à ton précédent commentaire (qui n'avais rien à voir avec le déploiement "de masse").

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le mot clé est "power over ethernet". Apparement ya même un standard IEEE pour ça.

http://en.wikipedia.org/wiki/Power_over_Ethernet(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il ya pkgsrc qui tourne sous Windows+SFU mais évidemment le repository ne contient que des programmes *nix (enfin je pense).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Apparement Bitrock ne gère pas du tout les dépendance: tout est contenu dans le paquet. Le seul "intérêt" c'est d'avoir un installeur graphique. Avec Autopackage le système de gestion des dépendances a pas l'air génial (dépendances sur des fichiers, comme les RPM à un moment, on a vu ce que ça a donné) mais au moins il y en a un et la prochaine version prévoit une intégration avec les systèmes de gestion des paquets des distributions.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Avec Debian et Ubuntu (ya surement moyen de faire la même chose pour la plupart des autres distributions), tu peux monter une archive Debian spécifique qui contient les paquets que tu veux en parrallèle de l'archive officielle. Après yapluka configurer apt pour lui dire d'aller chercher de préférence dans l'archive de l'entreprise et voilà.

Si tu t'arranges pour avoir des paquets virtuels qui dépendent des paquets à installer (genre un paquet "entreprise" qui dépend des paquets personnalisés), une fois que c'est en place, pour déployer la nouvelle (version de l') application, suffit de faire un apt-get update && apt-get dist-upgrade (un job cron et c'est bon). Je suis pas sûr que tu puisses faire un truc aussi pratique aussi facilement sous Windows.

Pour Zero Install si tu as plusieurs distributions différentes c'est vrai que ça peut être pratique mais si tu dois commencer à gérer les dépendances toi même, ça risque de pas être la joie.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et avec fakechroot tu peux même le faire sans être root apparement.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Par ailleurs il me semble qu'il n'y a pas de version française de Firefox 0.9 (pas dans Warty en tout cas).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est très vrai. Il y a un "Ask Slashdot" qui est passé il y a 2 jours qui parle de ce problème (et apparement c'est pas spécifique au libre) avec quelques solutions de secours: http://ask.slashdot.org/article.pl?sid=04/12/26/2114234(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux essayer de faire un système mixte: Warty/Hoary. Tu peux configurer APT pour qu'il aille chercher les paquets de Warty par défaut et de Hoary s'ils n'existent pas dans Warty ou si tu veux une version qui n'existe que dans Hoary.

http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.fr.html#s-de(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je fais des diagrammes d'objets pour avoir une idée des structures de données et des fonctions/méthodes dont j'aurai besoin et/ou du pseudo code pour me faire une idée du "workflow" général du programme avant de commencer. Pour la syntaxe exact, le diagramme c'est un truc dans le genre des graphs UML qu'on peut faire avec DIA (je connais pas grand chose d'UML en fait) et pour le pseudo code, du C et du français.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

J'ai pas encore trouvé mieux (d'un autre côté j'ai jamais codé de gros programmes non plus).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pas besoin de shell sur le serveur en fait, suffit que tu puisses te connecter à la db depuis une machine sur laquelle tu as un shell.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si tu as un shell sur la machine, va voir la doc de crontab(1) et mysqldump(1).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un Pentium 32Mo de RAM c'est "pleinement fonctionnel" avec links, pas avec Mozilla.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si tu ne peux pas te connecter à la machine qui fait CVS, fait en sorte qu'elle se connecte à toi.
http://www.linuxdocs.org/HOWTOs/mini/Firewall-Piercing.html(...)

Sinon j'ai jamais vraiment utilisé de système comme CVS mais d'après le peu que j'en connais, la solution est effectivement d'utiliser des branches mais je suis pas sûr que CVS gère bien les conflits au moment du "merge" et d'après http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison#4(...)

It is possible to develop on branches in CVS, but notoriously difficult and error-prone.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

en ce jour ou vous

c'est plutôt "où"

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je savais pas qu'il était interdit de parler de logiciels non libre ici ni d'être impatient de la sortie de drivers propriétaire sous Linux (pas GNU/ parce que c'est des drivers pour le noyau). djibb n'a pas fait l'éloge des drivers propriétaires ATI que je sache. Il faisait juste remarquer qu'ATI est sur le point de faillir à sa promesse. Personnellement je suis assez impatient aussi qu'ATI nous sorte des drivers dignes de ce nom. C'est vrai que le fait qu'ils soient propriétaire pose plusieurs problèmes mais en restant pragmatique, si on veut de la 3D convenable avec une carte ATI récente pour le moment ya pas trop le choix (c'est vrai aussi que si on se bouge pas ça risque pas de changer).

Par ailleurs AFAIK le but initial de Linux c'était (c'est?) pas de faire un truc entiérement libre (d'ailleurs au début ça l'était pas il me semble) mais bien de faire un truc qui marche. Je critique pas le Libre, c'est une bonne chose(tm) que Linux soit libre et se soit associé à GNU (ou l'inverse) mais c'est pas une raison pour rejeter systèmatiquement les logiciels propriétaires non plus. Si tu ne veux pas les utiliser, ne le fait pas (personne t'y oblige) mais n'empèche pas les autres de les utiliser.

Je vois pas bien en quoi le driver propriétaire d'ATI menace (la liberté de) GNU/Linux: c'est un module externe non indispensable qui ne sera clairement pas admis dans le noyau officiel tant qu'il ne sera pas sous GPL (et c'est tant mieux).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je pense pas que ça marche: si les .deb sont bien ajoutés au cache, ils ne sont pas listés dans /var/lib/dpkg/available et donc pas pris en compte lors de l'installation.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En fait le plus simple si tu as déjà les .deb c'est probablement de monter une archive APT avec apt-cacher ou apt-proxy puis de l'ajouter à ton sources.list. Pour savoir exactement quoi faire, lis la doc (j'ai jamais utilisé apt-cacher et ça fait longtemps que j'ai plus touché à apt-proxy).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.