Je pense que tar propose suffisamment d'options pour gérer ton cas.
Tu peux notamment mettre des règles d'(in|ex)clusion basées (ou non) sur des pattern.
Tu as aussi l'option -T qui, si je ne m'abuse, permet de fournir une liste de fichiers dans un fichier texte, que tu peux générer facilement avec find.
Tu peux d'ailleurs le combiner avec l'entrée standard (-T -) et l'option --null pour combiner directement ça à un find -print0, comem dans l'exemple plus haut mais en te passant de xargs (qui a pour effet de faire plusieurs appels si le nombre d'arguments est trop grand, d'où ton cas d'archive qui est réécrite plusieurs fois)
Mais pour plein d'autres, Oracle répond parfaitement à leur besoins.
Je formulerais plutôt ça: pour la plupart des gens oracle dépasse (souvent largement) leurs besoins et ils se retrouvent à payer (cher) une solution surdimensionnée.
Je ne doute pas que pour les montée en charge astronomiques et les besoins de disponibilités absolus, un oracle (bien configuré avec des admins compétants à son chevêt en permanence) est la meilleure solution. Mais dans beaucoup de cas on le choisit pour une raison aussi idiote que le "personnes n'a été viré pour avoir choisi IBM", là où un (my|pg)sql (encore une fois bien configuré avec des admins compétents) aurait très bien fait l'affaire.
Oui, c'est surtout les ingénieurs les plus doués/emblématiques/importants et les grand chefs de projets qu'il faut surveiller, si on en voit plusieurs s'en aller dans les mois qui viennent il faudra alors s'inquiéter de l'avenir des projets de feu Sun.
Et ayant à utiliser les deux, je trouve plus rapidement l'information que je veux dans la doc de postgresql, pour mysql je dois souvent passer par une recherche.
C'est probablement parce que les gens qui ont écrit la doc de PG pensent plus comme moi :-)
Pour connaitre la liste des fichiers dans le cache, je ne sais pas du tout comment on peut faire ça sous linux, mais ça doit exister probablement.
Ce ne sont pas les fichiers qui sont en cache, mais les pages individuelles, donc tu peux avoir un fichier à moitié en cache, dont un quart a été modifié et n'a pas encore été écrit sur le disque.
Dans la 2009.0 oui, mais KDE3 a été supprimé de la 2009.1, il reste juste les libs pour les programmes pas encore portés.
Par contre il y a des paquets (non officiels, cf annonce sur kde.org) de KDE 4.2.2 disponibles pour la 2009.0. Le problème c'est qu'ils sont maqué comme rendant obsolètes leurs équivalents KDE3, donc quand on les installe ils virent KDE3, mais tu peux réinstaller les paquets après, il n'y a pas d'incompatibilité (en tout cas je n'en ai pas constaté).
Mon conseil: notez tous vos paquets installés avant essai (rpm -qa|sort) pour ensuite pouvoir facilement trouver ce qui a été supprimé et pouvoir les remettre.
Pour faire du LaTeX avec une interface intuitive (mais qui propose malgré tout des raccourcis clavier pour toutes les fonctions et permet d'insérer du code TeX pour les besoins spéciaux) il y a LyX: http://www.lyx.org/
Et ça existe aussi pôur windows et mac si tu dois travailler avec des gens pas encore libérés ;-)
Ah, moi c'est le contraire, j'utilise le Ctrl qui est du même côté que la touche avec laquelle je veux faire une combinaison, comme ça je peux la faire d'un seule main.
Je ne connais pas hal, mais tu peux aller regarder sur le bugzilla de mandriva https://qa.mandriva.com/
pour voir s'il ne s'agit pas d'un problème connu, te sinon le rapporter pour qu'il soit corrigé dans la version finale.
Au hasard, le typage dynamique, le changement dynamique de classes d'une instance à la volée.
Ça ce sont des arguments pour éviter ce langage pour des projets de taille moyenne et à fortiori si c'est développé de façon modulaire par différentes équipes.
Déjà, va plutôt lire directement le fichier /proc/loadavg, ça t'économisera les commandes uptime et awk.
Exemple:
cut -d ' ' -f 1 /proc/loadavg
Ensuite, vu le $10 dans ton awk tu prend le troisième chiffre du load average, c'est à dire celui qui est moyenné sur 15 minutes, normal qu'il baisse lentement. Le premier est moyenné sur une minute et baissera beaucoup plus vite.
Mais de toute façon, comme tu dis à demi-mots, c'est très crade à la base.
Après test, du coup, je remarque que les boutons *s'effacent* lors du clic (au click-down) pour se redisposer ensuite (au click-up). C'est suffisant pour parer ce genre de "screenlogger" ?
Non, il suffit de faire la capture d'écran 0.1s après le mouse-up.
1) Ce n'est pas très utile, mais j'aime bien avoir cet historique de la vie d'un nouveau noyau, et les commentaires de Linus sont amusants à lire.
2) Très utile, ça c'est vraiment l'information que je cherche quand un nouveau noyau sort. Pour moi ça pourrait être encore un peu plus technique et détaillé, mais la dépèche est déjà très longue comme ça.
La liste des "en bref" est bien aussi.
3) Je pense que j'ai cliqué sur une quinzaine de liens de la dépèche, c'est intéressant quand on veut plus d'information.
N'importe quoi qui commence par un tiret?
(soit ce sera pris comme une option reconnue et il manquera le fichier, soit pas et ce sera une erreur d'option inconnue)
Tu connais un endroit où on peut récupérer ce JWebPane?
Parce que jusqu'à présent tout ce que j'ai vu sur les blogs des développeurs de sun c'est que c'est pour plus tard et on aurait bien besoin de ça pour pouvoir abandonner les immondes hack qui intègrent le moteur de firefox avec un heavyweight component.
Oui, et c'est bien le but, car les physiciens savent que le modèle standard de la physique des particules est incomplet, ne serait-ce que parce qu'il ne prend pas en compte la gravitation.
Il n'est pas question de faire une collision dans laquelle on va découvrir des nouveaux trucs, mais d'en faire beaucoup et puis de faire des statistiques sur les résultats.
En effet, les détecteurs énormes des grands accélérateurs ne sont sensibles qu'à certaines particules et à partir des données de ces particules (énergie, trajectoire) on déduit les séries de désintégrations qui ont eu lieu.
Car le résultat final n'est pas le même si les particules finales proviennent de la désintégration d'un higgs ou d'un quark top par exemple.
Le LEP (l'accélérateur électrons/positon qui se trouvait dans le même tunnel que l'actuel LHC) avait déjà accumulé des mesures qui laissaient supposer l'existence du higgs, mais étaient insuffisantes pour réellement le conclure et certaines personnes avaient regretté que l'expérience ne se poursuive pas quelques mois de plus pour accumuler assez de données.
C'est amusant comme à chaque fois que quelqu'un viens dire que le format deb n'est pas supérieur au format rpm il y a quelqu'un pour détourner la discussion en apt vs le reste du monde.
J'ai une machine qui est en mandriva 2008.1 et dont je fais les mises à jour successives depuis son installation initiale en mandrake 8.2!
Ma machine principale, plus récente et installée en x86_64, est actuellement en 2009.0 et a été initialement installée en 2007.0.
# Tout est dans tar
Posté par wismerhill . En réponse au message Compression d'un seul type de fichier. Évalué à 5.
Tu peux notamment mettre des règles d'(in|ex)clusion basées (ou non) sur des pattern.
Tu as aussi l'option -T qui, si je ne m'abuse, permet de fournir une liste de fichiers dans un fichier texte, que tu peux générer facilement avec find.
Tu peux d'ailleurs le combiner avec l'entrée standard (-T -) et l'option --null pour combiner directement ça à un find -print0, comem dans l'exemple plus haut mais en te passant de xargs (qui a pour effet de faire plusieurs appels si le nombre d'arguments est trop grand, d'où ton cas d'archive qui est réécrite plusieurs fois)
# logs?
Posté par wismerhill . En réponse au message Tomcat Apache Proxy et sendRedirect. Évalué à 2.
As-tu des erreurs dans les logs de tomcat (peut-être d'apache)?
Ton sendRedirect, est-ce que tu l'appelle bien AVANT que les header de la réponse aient été renvoyés? (dans une servlet ou une jsp?)
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par wismerhill . En réponse à la dépêche Oracle achète Sun. Évalué à 10.
Je formulerais plutôt ça: pour la plupart des gens oracle dépasse (souvent largement) leurs besoins et ils se retrouvent à payer (cher) une solution surdimensionnée.
Je ne doute pas que pour les montée en charge astronomiques et les besoins de disponibilités absolus, un oracle (bien configuré avec des admins compétants à son chevêt en permanence) est la meilleure solution. Mais dans beaucoup de cas on le choisit pour une raison aussi idiote que le "personnes n'a été viré pour avoir choisi IBM", là où un (my|pg)sql (encore une fois bien configuré avec des admins compétents) aurait très bien fait l'affaire.
[^] # Re: 9.40 dollards ?
Posté par wismerhill . En réponse à la dépêche Oracle achète Sun. Évalué à 7.
[^] # Re: Evil factor ?
Posté par wismerhill . En réponse à la dépêche Oracle achète Sun. Évalué à 4.
C'est probablement parce que les gens qui ont écrit la doc de PG pensent plus comme moi :-)
[^] # Re: quelques éléments de réponse
Posté par wismerhill . En réponse au message Manipuler le cache du système de fichier. Évalué à 5.
Ce ne sont pas les fichiers qui sont en cache, mais les pages individuelles, donc tu peux avoir un fichier à moitié en cache, dont un quart a été modifié et n'a pas encore été écrit sur le disque.
[^] # Re: J'ai aussi testé KDE 4 et ...
Posté par wismerhill . En réponse au journal kde : vers la fin du tunnel ?. Évalué à 4.
Si tu veux juste pouvoir mettre des icônes partout au hasard, il suffit de mettre le plasmoïde "vue de dossier" sur toute la surface disponible.
[^] # Re: Compilation Linux AMD/Intel
Posté par wismerhill . En réponse au journal Intel contribuera à GCC. Évalué à 3.
Ben si il les donne: 3.4GHz et 2GHz.
[^] # Re: KDE3 et KDE4 en même temps
Posté par wismerhill . En réponse au journal KDE 4 devient instable. Évalué à 4.
Par contre il y a des paquets (non officiels, cf annonce sur kde.org) de KDE 4.2.2 disponibles pour la 2009.0. Le problème c'est qu'ils sont maqué comme rendant obsolètes leurs équivalents KDE3, donc quand on les installe ils virent KDE3, mais tu peux réinstaller les paquets après, il n'y a pas d'incompatibilité (en tout cas je n'en ai pas constaté).
Mon conseil: notez tous vos paquets installés avant essai (rpm -qa|sort) pour ensuite pouvoir facilement trouver ce qui a été supprimé et pouvoir les remettre.
[^] # Re: très intéressant
Posté par wismerhill . En réponse au journal La touche ctrl de droite. Évalué à 2.
# LyX
Posté par wismerhill . En réponse au message Écrire un mémoire. Évalué à 1.
http://www.lyx.org/
Et ça existe aussi pôur windows et mac si tu dois travailler avec des gens pas encore libérés ;-)
[^] # Re: Moi je l'utilise tout le temps.
Posté par wismerhill . En réponse au journal La touche ctrl de droite. Évalué à 5.
# bugreport
Posté par wismerhill . En réponse au message Mandriva 2009.1 RC1. Évalué à 2.
https://qa.mandriva.com/
pour voir s'il ne s'agit pas d'un problème connu, te sinon le rapporter pour qu'il soit corrigé dans la version finale.
[^] # Re: Block ou closure ?
Posté par wismerhill . En réponse au journal Où l'on en apprend un peu plus sur Java 7. Évalué à 0.
Ça ce sont des arguments pour éviter ce langage pour des projets de taille moyenne et à fortiori si c'est développé de façon modulaire par différentes équipes.
[^] # Re: :)
Posté par wismerhill . En réponse au message Empecher l'asspiration de site. Évalué à 2.
Exemple:
cut -d ' ' -f 1 /proc/loadavg
Ensuite, vu le $10 dans ton awk tu prend le troisième chiffre du load average, c'est à dire celui qui est moyenné sur 15 minutes, normal qu'il baisse lentement. Le premier est moyenné sur une minute et baissera beaucoup plus vite.
Mais de toute façon, comme tu dis à demi-mots, c'est très crade à la base.
[^] # Re: sécurité vs facilité
Posté par wismerhill . En réponse au journal Les créateurs de formulaires sont complètement abrutis.... Évalué à 1.
Non, il suffit de faire la capture d'écran 0.1s après le mouse-up.
[^] # Re: Petites questions
Posté par wismerhill . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 2.
1) Ce n'est pas très utile, mais j'aime bien avoir cet historique de la vie d'un nouveau noyau, et les commentaires de Linus sont amusants à lire.
2) Très utile, ça c'est vraiment l'information que je cherche quand un nouveau noyau sort. Pour moi ça pourrait être encore un peu plus technique et détaillé, mais la dépèche est déjà très longue comme ça.
La liste des "en bref" est bien aussi.
3) Je pense que j'ai cliqué sur une quinzaine de liens de la dépèche, c'est intéressant quand on veut plus d'information.
4) Ce passage-là m'intéresse nettement moins.
[^] # Re: confirmer le mail
Posté par wismerhill . En réponse au journal Les créateurs de formulaires sont complètement abrutis.... Évalué à 2.
ça va plus vite que de retaper l'adresse email.
[^] # Re: Plusieurs possibilités
Posté par wismerhill . En réponse au message Enorme perte de place sur mon disque dur. Évalué à 7.
[^] # Re: ROhhhhhhh
Posté par wismerhill . En réponse à la dépêche Sortie de GNU Bash 4.0. Évalué à 1.
(soit ce sera pris comme une option reconnue et il manquera le fichier, soit pas et ce sera une erreur d'option inconnue)
[^] # Re: Utilité de QtJambi
Posté par wismerhill . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 1.
Parce que jusqu'à présent tout ce que j'ai vu sur les blogs des développeurs de sun c'est que c'est pour plus tard et on aurait bien besoin de ça pour pouvoir abandonner les immondes hack qui intègrent le moteur de firefox avec un heavyweight component.
[^] # Re: Comme d'hab
Posté par wismerhill . En réponse au journal Qui va gagner la course au Higgs ?. Évalué à 1.
[^] # Re: J'ai pas tout compris...
Posté par wismerhill . En réponse au journal Qui va gagner la course au Higgs ?. Évalué à 3.
En effet, les détecteurs énormes des grands accélérateurs ne sont sensibles qu'à certaines particules et à partir des données de ces particules (énergie, trajectoire) on déduit les séries de désintégrations qui ont eu lieu.
Car le résultat final n'est pas le même si les particules finales proviennent de la désintégration d'un higgs ou d'un quark top par exemple.
Le LEP (l'accélérateur électrons/positon qui se trouvait dans le même tunnel que l'actuel LHC) avait déjà accumulé des mesures qui laissaient supposer l'existence du higgs, mais étaient insuffisantes pour réellement le conclure et certaines personnes avaient regretté que l'expérience ne se poursuive pas quelques mois de plus pour accumuler assez de données.
[^] # Re: Mandriva et inconguités...
Posté par wismerhill . En réponse au message x86 : i386 vs i686. Évalué à 0.
[^] # Re: Mandriva et inconguités...
Posté par wismerhill . En réponse au message x86 : i386 vs i686. Évalué à 1.
Ma machine principale, plus récente et installée en x86_64, est actuellement en 2009.0 et a été initialement installée en 2007.0.