Je rajouterai juste que pour obtenir les erreurs d'execution de la crontab, on peut rajouter une ligne
MAILTO=mon@mail.tld
Dans ce cas, cron envoie un mail. Par contre, il envoie un mail dès qu'il reçoit quelque chose dans la sortie standard, donc il faut peut-être le désactiver en temps normal, suivant ce que tu lances.
Mais pourquoi VNC ? C'est dommage, ça va consommer plein de mémoire pour rien, alors qu'un accès en shell doit amplement suffir, surtout si c'est juste un serveur de fichier (auquel tu vas probablement très peu accéder une fois qu'il tournera).
au niveau du mode de fonctionnement, ça a l'air de bien tourner, et un truc dans le genre un peu plus scripté pour les webmasters, ça pourrait bien le faire.
Si tu as un accès web au boulot et chez toi, tu peux utiliser un aggregateur en ligne, ça peux faire ce que tu veux. Je ne met pas celui que j'utilise sinon on va dire que je fais ma pub :-)
Aie aie aie... Le fichier /tmp est généralement vidé au démarrage du système. Si ton /tmp est sur la même partition que ton système, ça va être très chaud.
Je me sens pas moins seul, mais j'avoue que j'ai un peu souri en lisant la nouvelle.
Plutôt que de simplement se conformer aux règles d'usage (je répète le mot important: d'USAGE), ils ont voulu appliquer le droit d'auteur, de manière bête et méchante, sans aucune considération pour les spécificités du média qu'ils utilisent: la solution la plus simple pour tout le monde aurait été évidemment un fichier robots.txt bien configuré, ça aurait pris 5 minutes et google l'aurait respecté sans problème.
Mais c'est ce que je me tue à répéter: plein de solutions techniques sont disponibles pour pouvoir publier ce qu'on veut comme on veut, mais le monde est ainsi fait qu'il y aura toujours des gens pour se plaindre du tapage nocturne le jour du réveillon et exiger le respect inconditionnel de leur droit d'auteur sans tenir compte des possibilités qu'ils ont pour exercer leur droit. Pour ces gens-là, le monde devra toujours tourner autour d'eux, et c'est bien dommage, parce que ça pénalise tout le monde.
« Et l'Éternel dit : Voici, ils forment un seul peuple et ont tous une même langue, et c’est là ce qu'ils ont entrepris ; maintenant rien ne les empêcherait de faire tout ce qu'ils auraient projeté. Allons ! descendons, et là confondons leur langage, afin qu’ils n’entendent plus la langue, les uns des autres. Et l’Éternel les dispersa loin de là sur la face de toute la terre ; et ils cessèrent de bâtir la ville. »
Tu as pas oublié un chiffre ?
Parce qu'à 10'000 requêtes par jour, en prenant un cas extrême où tu as en fait 15000 requêtes réparties sur une plage horaire réduite de 6h, si je calcule bien ça fait du 15000 / (6*60) = 41 requête par minute. Ce qui parait pas beaucoup. Est-ce que tu prévois des périodes avec des grosses charges ?
Sans rien connaître de ton service, même s'il y a des pics de charge, j'aurai tendance à dire que ce n'est pas sur la couche de transport qu'il pourrait y avoir un problème de performance, mais ça dépend complètement de ton application, et comme tu ne donnes pas beaucoup de détail, c'est difficile de donner un diagnostic.
Sinon, il faut voir que la réponse dépend aussi du matériel, sur un petit serveur avec peu de RAM, Apache2/PHP généralement sera plus performant, mais avec plein de mémoire ça change la donne.
A ta place, avant de te lancer sur un développement qui n'est peut-être pas nécessaire, je testerais la charge avec JMeter et si ça ne va pas, j'essaierai déjà de tuner mon serveur apache, et je ferais ensuite un test sous tomcat si je continue à ne pas être satisfait des performances.
Pour la partie "galère xhtml/javascript/css/support par les différents navigateurs", je trouve que c'est de moins en moins vrai.
D'abord, pour le javascript, sauf à faire des choses très pointues, ça marche plutôt bien (et de toute façon, tout le monde utilise des bibliothèques comme prototype qui font pas mal du sale boulot).
Ensuite, pour l'affichage, si tu utilises du xhtml/css, ça va plutôt bien quand même, surtout depuis XHTML. Au contraire même, le xhtml est très propre, et le principe d'accessibilité est à bien garder en tête: l'application doit pouvoir s'afficher n'importe où, y compris ne pas s'afficher (si la page est lue plutôt que vue). Dans ces conditions, il y a très peu de cas où on galère pour l'affichage, parce que justement on ne doit s'en préoccuper que modérément (et savoir accepter que son affichage diffère d'un navigateur à l'autre).
En revanche, je suis plutôt d'accord avec toi, le mélange entre le (x)html et le code, c'est pas terrible, et à part la solution que tu cherches ("tout généré par le code"), il n'existe pas grand chose de satisfaisant.
Si ton problème est juste de trouver ce fichier:
# locate mysql.so
/var/lib/mysql/mysql.sock
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux/auto/DBD/mysql/mysql.so
/usr/lib/php/extensions/mysql.so
#
Pour le P2P, la plupart des clients (Azureus par exemple) incluent une interface web, généralement sous forme de plug-in.
De mémoire, Azureus en possède au moins 2, et on peut lui envoyer des torrents via un upload de fichier, c'est très pratique.
Pour le FTP, c'est tellement simple qu'il n'y a même pas besoin d'interface, tu repères ton lien quelque part, tu te connectes en ssh sur ta machine, et tu lances un petit nohup wget TON-URL &
et ça marche tout seul.
C'est marrant, j'avais pas du tout compris la question comme toi... Je l'avais comprise comme étant la recherche d'un arrondi au millier supérieur ou inférieur... probablement à cause des exemples.
Si c'est un arrondi tel que seuls des 0 peuvent suivre le premier digit, pas la peine d'utiliser des log10 (heureusement parce que bonne chance en bash), ça reste trivial:
#!/bin/bash
function rounda {
if [[ ${1:1:1} == "" ]] ; then
echo "$1"
else
if [ ${1:1:1} -gt 5 ] ; then
first=$(( ${1:0:1} + 1 ))
else
first=${1:0:1}
fi
echo -n $first
l="`echo $1 | wc -c`"
for i in `seq 2 $(($l-1))`; do echo -n "0" ; done
fi
}
Je parlais de l'extraction automatique du contenu du RSS, pas forcément du contenu du blog. Autrement dit, personne ne bookmarke un fil RSS, et personne ne va ouvrir un fil RSS à la main pour le lire, c'est toujours un robot qui s'en charge dans une procédure automatique, qu'il soit intégré à un site web, à un aggrégateur, ou à navigateur web.
J'aurais dit le caractère d'échappement aussi, dommage.
Faudrait regarder dans les sources comment est implémenté le parser. Tu pourrais aussi essayer de mettre la chaine entre guillemets, on ne sait jamais, si les commentaires ne sont pas effacés avant le parsing ça peut marcher, sur un coup de bol... :-)
Très bien, si ça te fait plaisir, quel est le problème ?
Je ne vois pas du tout où se trouve la difficulté à encoder la petite dizaine de licence qui couvre 95% des besoins de tout le monde, tout en laissant la possibilité d'exprimer une licence spécifique pour les 5% restant.
Mais parce que tu ne vois pas de problème, il n'y a pas de problème ? Ca doit être facile, la vie, vue comme ça :-)
Je vais te donner un exemple. Il y a encore quelques mois, un petit groupe de bloggeurs altermondialistes utilisaient ouliblog comme planet pour regrouper l'ensemble de leur articles et se fédérer.
C'était très facile: le leader rajoutait les fils RSS de chacun des membres, et chacun pouvait venir consulter les fils. C'était aussi très pratique pour eux d'avoir un planet qu'ils pouvaient référencer et sur lequel renvoyer leurs visiteurs.
Ils ont quitté ouliblog, parce que ça n'est plus possible, à cause des restrictions d'accès (le lecteur RSS est devenu privé). Comme chacun se trouve sur une plateforme d'hébergement différente, aucune ne gérant le tag creative common (le seul utilisable automatiquement), parce qu'il faut être honnête, personne ne l'utilise parce que c'est juste une extension quelconque à laquelle personne ne prête attention, il n'est PAS possible pour moi de leur permettre d'être hébergé sur ouliblog. Ils ont quitté ouliblog, ce qui est normal, parce que ça ne répondait plus du tout à leur besoin. Personnellement, ça ne m'empêche pas de dormir, mais je trouve ça dommage pour eux.
Pour l'anecdote, aucun ne savait ce qu'était un planet, ils étaient naturellement venus à cette utilisation-là d'ouliblog, je me suis aperçu après-coup de l'utilisation qu'ils en faisaient, et à laquelle je n'avais pas pensé.
S'il y avait une façon automatique de gérer le droit de distribution d'un fil RSS, j'aurais pu sans problème l'implémenter dans ouliblog et leur permettre de créer leur planet communautaire.
Les champs dc:rights, copyrights, etc, sont des champs à texte libre. Il n'y a rien qui permette à un outil de déterminer automatiquement les droits d'exploitation d'un fil RSS.
Comme tu le dis toi-même: The atom:rights element SHOULD NOT be used to convey machine-readable licensing information. Autrement dit, le champs ne permet pas de déterminer mécaniquement une quelconque information de license.
Après il est toujours possible de faire des extensions, ce n'est pas compliqué, n'importe qui peut en faire une nouvelle. Le problème, c'est que les extensions ne sont jamais utilisées (déjà que le RSS est souvent approximatif). Dans la mesure ou le RSS est un format initialement destiné à l'extraction automatique de contenu, il n'est quand même pas délirant de penser qu'il faudrait systématiquement définir la license d'exploitation qui va avec.
Merci d'avoir pris le temps d'approfondir ce qu'était ouliblog. J'aurais dû expliquer au début en quoi ça consistait, et j'aurais dû expliquer que la démarche derrière ce projet est à la fois technique (obtenir un lecteur RSS confortable et adapté à la lecture d'un grand nombre de fils) et éthique (respect du droit d'auteur, mise en avant des blogs, en particulier en donnant la possibilité aux utilisateur de mettre des "coups de coeurs" sur des billets, et développement en open-source). Mais là, on m'aurait encore plus taxé de faire ma pub, et ce n'était pas le sujet.
C'est surtout pour ça que j'ai réagis vivement à tes accusation de pillage (je schématise) alors que c'est tout le contraire de ma démarche.
Pour les plaignants, j'en ai eu très peu en 1 an de mise en service, et j'ai toujours veillé à respecter les souhaits des auteurs. Quitte à ne plus récupérer un fil RSS ou à restreindre l'affichage des billets à l'utilisateur connecté uniquement. Globalement ça marche plutôt bien.
Note aussi qu'il y a deux parties à ouliblog: un lecteur de RSS, plutôt classique, et un portail qui regroupe les derniers billets publiés. La seule partie sur laquelle on pourrait vraiment ergoter, c'est sur cette dernière, pour l'affichage des miniatures d'images publiées sur les blogs. Mais d'une part il s'agit de miniature, d'autre part elles ne restent en moyenne que quelques heures. Au pire, je la virerai, mais ça serait dommage parce que c'est bien sympa et que ça ne cause vraiment aucun préjudice.
# smarty
Posté par deadbeef . En réponse au message php template. Évalué à 1.
# Freshmeat + RSS ?
Posté par deadbeef . En réponse au journal Bannière publicitaire Opensource ?. Évalué à 1.
# Domaine
Posté par deadbeef . En réponse au message Question cookies.... Évalué à 4.
setcookie('style', $_POST['style'], time()+(365*24*3600),'/', "mon-site.fr") ;
# c'est compatible
Posté par deadbeef . En réponse au message ext3 sous windows. Évalué à 1.
[^] # Re: problème de PATH ?
Posté par deadbeef . En réponse au message redirection ntpdate avec cron. Évalué à 1.
MAILTO=mon@mail.tld
Dans ce cas, cron envoie un mail. Par contre, il envoie un mail dès qu'il reçoit quelque chose dans la sortie standard, donc il faut peut-être le désactiver en temps normal, suivant ce que tu lances.
# VNC ?
Posté par deadbeef . En réponse au message Modifier un client léger en serveur de fichier. Évalué à 1.
# en 1 ligne
Posté par deadbeef . En réponse au message Renommer avec le nom du répertoire. Évalué à 2.
(modifie "echo cp" par cp ou mv)
# influenceurs
Posté par deadbeef . En réponse au journal [proposition] Un système pour faire connaître les logiciels libres. Évalué à 1.
http://influenceurs.net/
au niveau du mode de fonctionnement, ça a l'air de bien tourner, et un truc dans le genre un peu plus scripté pour les webmasters, ça pourrait bien le faire.
# un aggregateur en ligne
Posté par deadbeef . En réponse au message Un serveur RSS??. Évalué à 3.
# aie
Posté par deadbeef . En réponse au message nettoyage auto de /tmp. Évalué à 2.
Essaye d'utiliser debugfs : http://www.faqs.org/docs/Linux-mini/Ext2fs-Undeletion.html
# juste un mot pour décrire ce gachis : robots.txt
Posté par deadbeef . En réponse au journal Publication web, rss, google. Évalué à 3.
Plutôt que de simplement se conformer aux règles d'usage (je répète le mot important: d'USAGE), ils ont voulu appliquer le droit d'auteur, de manière bête et méchante, sans aucune considération pour les spécificités du média qu'ils utilisent: la solution la plus simple pour tout le monde aurait été évidemment un fichier robots.txt bien configuré, ça aurait pris 5 minutes et google l'aurait respecté sans problème.
Mais c'est ce que je me tue à répéter: plein de solutions techniques sont disponibles pour pouvoir publier ce qu'on veut comme on veut, mais le monde est ainsi fait qu'il y aura toujours des gens pour se plaindre du tapage nocturne le jour du réveillon et exiger le respect inconditionnel de leur droit d'auteur sans tenir compte des possibilités qu'ils ont pour exercer leur droit. Pour ces gens-là, le monde devra toujours tourner autour d'eux, et c'est bien dommage, parce que ça pénalise tout le monde.
# Hélas...
Posté par deadbeef . En réponse au message multi-installation. Évalué à 4.
http://fr.wikipedia.org/wiki/Tour_de_Babel
# dix mille ?
Posté par deadbeef . En réponse au message Comment avoir LE serveur SOAP/WSDL qui poutre ??. Évalué à 2.
Parce qu'à 10'000 requêtes par jour, en prenant un cas extrême où tu as en fait 15000 requêtes réparties sur une plage horaire réduite de 6h, si je calcule bien ça fait du 15000 / (6*60) = 41 requête par minute. Ce qui parait pas beaucoup. Est-ce que tu prévois des périodes avec des grosses charges ?
Sans rien connaître de ton service, même s'il y a des pics de charge, j'aurai tendance à dire que ce n'est pas sur la couche de transport qu'il pourrait y avoir un problème de performance, mais ça dépend complètement de ton application, et comme tu ne donnes pas beaucoup de détail, c'est difficile de donner un diagnostic.
Sinon, il faut voir que la réponse dépend aussi du matériel, sur un petit serveur avec peu de RAM, Apache2/PHP généralement sera plus performant, mais avec plein de mémoire ça change la donne.
A ta place, avant de te lancer sur un développement qui n'est peut-être pas nécessaire, je testerais la charge avec JMeter et si ça ne va pas, j'essaierai déjà de tuner mon serveur apache, et je ferais ensuite un test sous tomcat si je continue à ne pas être satisfait des performances.
[^] # Re: Petit tour
Posté par deadbeef . En réponse au journal Web toolkit. Évalué à 2.
D'abord, pour le javascript, sauf à faire des choses très pointues, ça marche plutôt bien (et de toute façon, tout le monde utilise des bibliothèques comme prototype qui font pas mal du sale boulot).
Ensuite, pour l'affichage, si tu utilises du xhtml/css, ça va plutôt bien quand même, surtout depuis XHTML. Au contraire même, le xhtml est très propre, et le principe d'accessibilité est à bien garder en tête: l'application doit pouvoir s'afficher n'importe où, y compris ne pas s'afficher (si la page est lue plutôt que vue). Dans ces conditions, il y a très peu de cas où on galère pour l'affichage, parce que justement on ne doit s'en préoccuper que modérément (et savoir accepter que son affichage diffère d'un navigateur à l'autre).
En revanche, je suis plutôt d'accord avec toi, le mélange entre le (x)html et le code, c'est pas terrible, et à part la solution que tu cherches ("tout généré par le code"), il n'existe pas grand chose de satisfaisant.
# mplayer ?
Posté par deadbeef . En réponse au message Fichiers MKV. Évalué à 3.
De mon expérience, quand mplayer marche pas, y a pas beaucoup de chance pour que ça marche ailleurs.
# locate
Posté par deadbeef . En réponse au message Installer un module mysql pour un rpm ?. Évalué à 2.
# locate mysql.so
/var/lib/mysql/mysql.sock
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux/auto/DBD/mysql/mysql.so
/usr/lib/php/extensions/mysql.so
#
[^] # Re: ben...
Posté par deadbeef . En réponse au message Lancer à distance des téléchargements. Évalué à 2.
De mémoire, Azureus en possède au moins 2, et on peut lui envoyer des torrents via un upload de fichier, c'est très pratique.
Pour le FTP, c'est tellement simple qu'il n'y a même pas besoin d'interface, tu repères ton lien quelque part, tu te connectes en ssh sur ta machine, et tu lances un petit
nohup wget TON-URL &
et ça marche tout seul.
[^] # Re: pas trop
Posté par deadbeef . En réponse au message Calcul arrondi en shell. Évalué à 3.
Si c'est un arrondi tel que seuls des 0 peuvent suivre le premier digit, pas la peine d'utiliser des log10 (heureusement parce que bonne chance en bash), ça reste trivial:
#!/bin/bash
function rounda {
if [[ ${1:1:1} == "" ]] ; then
echo "$1"
else
if [ ${1:1:1} -gt 5 ] ; then
first=$(( ${1:0:1} + 1 ))
else
first=${1:0:1}
fi
echo -n $first
l="`echo $1 | wc -c`"
for i in `seq 2 $(($l-1))`; do echo -n "0" ; done
fi
}
echo 424242 = `rounda 424242`
echo 128 = `rounda 128`
echo 11 = `rounda 11`
résultat:
424242 = 400000
1985 = 2000
128 = 100
11 = 10
[^] # Re: oui mais non
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
# pas trop
Posté par deadbeef . En réponse au message Calcul arrondi en shell. Évalué à 3.
#!/bin/bash
function roundk {
a=$(( $1 / 1000 ))
b=$(( $1 % 1000 ))
if [ $b -gt 500 ] ; then
echo $(( $1 + 1000 - $b ))
else
echo $(( $1 - $b ))
fi
}
echo 19985 = `roundk 19985`
echo 1024 = `roundk 1024`
[^] # Re: a essayer
Posté par deadbeef . En réponse au message Cups, samba et mot de passe contenant #. Évalué à 3.
Faudrait regarder dans les sources comment est implémenté le parser. Tu pourrais aussi essayer de mettre la chaine entre guillemets, on ne sait jamais, si les commentaires ne sont pas effacés avant le parsing ça peut marcher, sur un coup de bol... :-)
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Je ne vois pas du tout où se trouve la difficulté à encoder la petite dizaine de licence qui couvre 95% des besoins de tout le monde, tout en laissant la possibilité d'exprimer une licence spécifique pour les 5% restant.
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Je vais te donner un exemple. Il y a encore quelques mois, un petit groupe de bloggeurs altermondialistes utilisaient ouliblog comme planet pour regrouper l'ensemble de leur articles et se fédérer.
C'était très facile: le leader rajoutait les fils RSS de chacun des membres, et chacun pouvait venir consulter les fils. C'était aussi très pratique pour eux d'avoir un planet qu'ils pouvaient référencer et sur lequel renvoyer leurs visiteurs.
Ils ont quitté ouliblog, parce que ça n'est plus possible, à cause des restrictions d'accès (le lecteur RSS est devenu privé). Comme chacun se trouve sur une plateforme d'hébergement différente, aucune ne gérant le tag creative common (le seul utilisable automatiquement), parce qu'il faut être honnête, personne ne l'utilise parce que c'est juste une extension quelconque à laquelle personne ne prête attention, il n'est PAS possible pour moi de leur permettre d'être hébergé sur ouliblog. Ils ont quitté ouliblog, ce qui est normal, parce que ça ne répondait plus du tout à leur besoin. Personnellement, ça ne m'empêche pas de dormir, mais je trouve ça dommage pour eux.
Pour l'anecdote, aucun ne savait ce qu'était un planet, ils étaient naturellement venus à cette utilisation-là d'ouliblog, je me suis aperçu après-coup de l'utilisation qu'ils en faisaient, et à laquelle je n'avais pas pensé.
S'il y avait une façon automatique de gérer le droit de distribution d'un fil RSS, j'aurais pu sans problème l'implémenter dans ouliblog et leur permettre de créer leur planet communautaire.
[^] # Re: effectivement...
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 2.
Comme tu le dis toi-même: The atom:rights element SHOULD NOT be used to convey machine-readable licensing information. Autrement dit, le champs ne permet pas de déterminer mécaniquement une quelconque information de license.
Après il est toujours possible de faire des extensions, ce n'est pas compliqué, n'importe qui peut en faire une nouvelle. Le problème, c'est que les extensions ne sont jamais utilisées (déjà que le RSS est souvent approximatif). Dans la mesure ou le RSS est un format initialement destiné à l'extraction automatique de contenu, il n'est quand même pas délirant de penser qu'il faudrait systématiquement définir la license d'exploitation qui va avec.
[^] # Re: Du DRM dans les RSS ?
Posté par deadbeef . En réponse au journal Du RSS et de sa bonne utilisation.... Évalué à 3.
C'est surtout pour ça que j'ai réagis vivement à tes accusation de pillage (je schématise) alors que c'est tout le contraire de ma démarche.
Pour les plaignants, j'en ai eu très peu en 1 an de mise en service, et j'ai toujours veillé à respecter les souhaits des auteurs. Quitte à ne plus récupérer un fil RSS ou à restreindre l'affichage des billets à l'utilisateur connecté uniquement. Globalement ça marche plutôt bien.
Note aussi qu'il y a deux parties à ouliblog: un lecteur de RSS, plutôt classique, et un portail qui regroupe les derniers billets publiés. La seule partie sur laquelle on pourrait vraiment ergoter, c'est sur cette dernière, pour l'affichage des miniatures d'images publiées sur les blogs. Mais d'une part il s'agit de miniature, d'autre part elles ne restent en moyenne que quelques heures. Au pire, je la virerai, mais ça serait dommage parce que c'est bien sympa et que ça ne cause vraiment aucun préjudice.