[ Précédent :: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 :: Suivant ]
Re: Avec sed
Je plussoie.
On peut faire plus court en virant l'option n (donc affichage implicite), et donc virer p aussi.
Et tant que l'on y est, on peut donner la commande pour faire l'inverse, soit tout afficher à partir du motif :
sed -ne '/TIMESTAMP 12\/31\/2007/,$ p' < fichier
Voila, comme ça, ça restera dans Google Aide-mémoire ! :-)
[ Répondre ]
Re: grep?
Je me réponds à moi-même : la même réponse a été donnée plus bas (il me semblait bien avoir lu tous les commentaires pourtant). Ca vaudrait le coup de refaire une petite page de formation à sed, parce que ça tombe dans l'oubli ...
[ Répondre ]
Re: résolu !, Mais ...
T'aurais pas installé les pilotes Samsung, des fois ? /o\
Sinon, est-ce que ton /tmp est situé sur une partition qui lui est propre ou bien fait-il partie de celle de / ? Dans ce cas, un / plein empêche a fortiori d'écrire dans /tmp ...
Enfin, lorsqu'une partition est presque pleine, il faut se souvenir qu'il reste toujours quelques % utilisables seulement par root, spécialement pour que celui-ci puisse faire le ménage ...
[ Répondre ]
Sockets C - C++
J'ai eu le même problème et franchement, j'ai fini par refaire mes propres classes. Pour deux raisons :
- Les libs que l'on trouve sur la toile sont soit des APIs Windows, soit des outils qui ont été faits dans les mêmes conditions que les tiennes. Il n'y a donc aucune garantie que ces trucs soient plus propres ni plus faciles à utiliser que ce que tu vas produire. Honnêtement, je n'ai pas cherché plus longtemps que çà non plus, mais si ce n'est pas destiné à un gros projet open-source servant de référence et repris par des dizaines de personnes, la recherche et l'investissement personnel deviennent plus importants que la rédaction de son propre code (ce n'est évidemment pas vrai pour tous les cas de figure).
- L'API des sockets BSD est à s'arracher les cheveux car c'était à la base une tentative d'universalisation de tous les modes de communication, et il ont essayé de couvrir large dès le départ. C'était une bonne idée, mais maintenant on se traîne depuis des décenies des choses qui ne servent à rien.
D'autre part, il y avait clairement une notion d'abstraction et de classification qui sont aujourd'hui caractéristiques de la programmation objet. Citons par exemple la notion d'adresse réseau sockaddr étendue en sockaddr_in mais par redéfinition. Même pas un union de structures puisque les familles de protocoles sont déclarées à postériori. Dans cette structure, une autre structure pour l'adresse en particulier, in_addr, laquelle ne contient en tout et pour tout qu'un seul et unique membre, un long de 32 bits !
A l'utilisation, on est obligé d'utiliser des cast explicites pour transformer un sockaddr_in en sockaddr général pour ne pas prendre de warnings à la compilation. Coté init, c'est pas triste non plus : le modèle a beau être cohérent, il est implémenté de telle manière que tout est à la charge du développeur : hton{sl}() à tout bout de champ à chaque fois qu'il faut changer une adresse, et obligé de spécifier à l'intérieur de chaque structure pourtant déjà spécialisé le type d'adresse (AF_INET), simplement pour que les fonctions dont on a dû abstraire les paramètres puisse les recaster dans l'autre sens en connaissance de cause. Au secours !
Par contre ...
... par contre, encapsuler tout ce merdier dans des classes n'est pas plus compliqué que d'écrire un programme réseau classique en C pour quelqu'un qui s'y est déjà collé, et on se retrouve au final avec trois ou quatre objets maximum, lequels ne sont pas dérivés plus loin. Du coup, la programmation des sockets qui a l'air si difficile en C semble très simple même avec ses propres objets.
Donc, d'expérience, ce qui est utile pour écrire un daemon text-based est :
- Ses propres sockets (ci-dessus).
- Un analyseur de regexp (en encapsulant encore les routines C système).
- Un mini-parser. Pas besoin de réécrire yacc, mais il n'y a rien de mieux qu'une grammaire BNF pour décrire la syntaxe d'une ligne valide.
- Un petit automate à pile. On trouve les classes, cette fois, mais ce n'est pas bien dur non plus de refaire le sien une fois pour toutes.
A partir de là, tu peux déclencher un événement sur n'importe quel flux d'entrée. En te démerdant bien, tu peux faire un programme complètement coopératif sans avoir besoin de pondre un thread.
Bon courage.
[ Répondre ]
Re: Tu sors
J'ai oublié le lien :
http://www.adobe.com/licensing/developer/fileformat/faq/
[ Répondre ]
Re: Tu sors
Hélas
Can I use the File Format Specification to create a SWF interpreter or player?
- No, the File Format Specification is provided for the specific purpose of enabling software applications to export to the SWF file format.
Can I use the File Format Specification to create a FLV encoder or an FLV streaming service?
- No, the File Format Specification is provided for the specific purpose of enabling software applications to export to the SWF file format.
Gnash violerait donc bien les termes de cette licence d'utilisation.
[ Répondre ]
Re: Tu sors
On est vendredi, c'est permis.
Pareil, je ne comprends pas les gens qui sont partis en croisade contre le Flash. Certes, ça pourrait être encore mieux, mais il y a quand même bien pire.
Le format est - presque - ouvert, le plug-in est disponible sous Linux même si, à ce que j'en ai entendu, il ne fonctionne que sur x86, et surtout le produit en lui-même est très bien réalisé. Et puis dans le domaine, c'est-à-dire un client léger d'animations vectorielles, il est de fait qu'il n'y a pas grand chose de disponibles non plus (surtout à l'époque où c'est sorti). Alors, évidemment, il faut laisser disponible la source de la vidéo, et pas faire n'importe quoi avec (sites tout-en-flash), mais c'est pas pire qu'un site qui dit "votre navigateur est incompatible" ou autre bêtise.
Par contre, je regrette d'une part que Macromédia soit devenue Adobe. On passe d'une boîte dynamique et innovante (à l'origine de ce genre de projets), à un poids lourd de l'informatique qui a fait une acquisition stratégique et qui va rendre ce genre d'initiative beaucoup plus compliqué, à mon goût.
D'autre part, je ne comprends pas la politique de leurs spécos : On a le droit de faire un logiciel qui exporte en Flash, mais pas de réaliser un lecteur, alors que leur composeur est hors de prix mais que l'Adobe Flash Player ne coûte rien. La seule raison plausible qui me vienne à l'esprit est la volonté d'éviter les forks, et l'évolution d'un format plus abouti à partir du SWF de base ...
[ Répondre ]
Avec su
Question à 2,50 balles. Ton utilisateur est-il réel et doit-il pouvoir se logguer quand même ?
Si non, tu mets soit un setuid bit sur l'exécutable si c'en est un, soit tu passes par su si c'est vraiment un script.
Si oui, tu définis le script ou l'exécutable comme shell de l'utilisateur. Il sera automatiquement exécuté à la connexion à l'exclusion de tout le reste et la session se referma avec lui.
[ Répondre ]
La vache
Bac+5 pour être technicien d'exploitation ! Je pensais qu'il y avait de l'emploi dans l'informatique ...
Sérieusement, le candidat a-t-il une chance de faire un peu d'administration système lui-même ou est-ce qu'il ne sera que le faire valoir des informaticiens titulaires ?
Etant donné que j'ai déjà occupé ce genre de poste (pour aujourd'hui bosser dans le milieu de la recherche, ouf !), je voudrais savoir s'il y a possibilité d'évoluer, s'il y a des chances d'être chargé de mettre en oeuvre les "solutions proposées", ou si, comme c'est déjà arrivé, le techos va être grosso-modo chargé de vérifier que le daemon ne plante pas ?
Maintenant, les questions pragmatiques :
- Quel pourcentage de Linux (et UNIX) dans le job ?
- Quel salaire approximatif ?
[ Répondre ]
Hmm. Trackerd ?
Il y a des logiciels pour suivre l'activité disque et système en général, sous Linux, mais le plus simple est encore de faire un top car un processus qui bouffe du disque bouffe en général du CPU en même temps.
Si tu utilises GNOME sous Ubuntu, il y a des chances que le processus en question soit trackerd. Je le kille à chaque fois pour le peu qu'il me sert et le pire, c'est qu'on en dit la même chose sur le web :
http://rootix.info/?p=53
[ Répondre ]
Rien.
« Exceed » est un serveur X qui fonctionne sur le poste client. Il n'y a rien à installer de plus sur une machine Linux, mais il faut configurer le logger (xdm, gdm, ...) pour lui demander d'écouter les requêtes xdmcp.
Voir dans le fichier de conf', donc.
[ Répondre ]
Re: Pas de bol...
En même temps, c'est un courrier-type qu'il a reçu (ce qui prouve bien qu'il y a suffisamment de demandes pour justifier un développement propre).
Si ça se trouve, ils ont configuré un anti-spam pour renvoyer la même réponse à tous les mails ressemblant de près ou de loin à celui-ci.
[ Répondre ]
Re: Pas de bol...
Sans compter qu'il y a des extrémistes Windows comme il y a des extrémistes Unix. Et puis il y a également ceux à qui on a confié une tâche qui n'est pas dans leur domaine de compétence et dont ils se seraient passés bien volontiers.
M'enfin bon. Ils auraient pu faire un PDF géant, à la limite. Ca aurait été crade d'un point de vue web, pas référencé, mais au moins ça aurait été vite fait et ce serait passé chez tout le monde de la même façon.
[ Répondre ]
OSMOSE !
Ah oui, mais ce n'est pas n'importe quelle émission, c'est Osmose. Dommage que ça passe si tard, mais d'un autre côté, ça permet de profiter de deux heures d'émission d'un coup.
Ca fait un moment que je n'écoute plus maintenant (parce que j'ai un boulot incompatible avec ce genre d'horaire), mais autant que je me souvienne, tous les sujets sont en général très intéressants.
Comme on est pas à une heure de grande écoute, l'émission n'a pas besoin d'être aussi formattée qu'un JT ou un show télévisé en prime-time. Du coup, la majeure partie du temps reste consacrée à l'intervenant lui-même, et le programmateur musical s'en donne à coeur joie ("J'fume plus d'shit" de Stupeflip et "Vous êtes un arbre" de SDA. Un bidonaute, probablement).
On en parlait ici (y a presque trois ans déja) :
https://linuxfr.org//~yeKcim/18398.html#584646
[ Répondre ]
Re: cron vs sleep() ?
Heureusement je ne le déclenche qu'une fois et j'appelle via ce programme un autre pour chaque utilisateur qui a demandé un réveil à l'heure actuelle. Je n'ai donc pas plus d'une itération de ce programme à chaque minute (si cron).
C'est déjà trop, à mon avis. Et ça reste du polling.
L'idée est très bonne mais implique qu'à chaque changement dans le fichier, je fasse une réorganisation de ma "liste d'attente". Ca me semble un peu plus lourd à mettre en place mais c'est beaucoup plus économe en performances.
C'est comme ça que cela se passe déjà pour la plupart des daemons, notamment Apache et PostgreSQL. On envoie un signal au processus pour lui demander de relire la conf' (un outil tout fait existe en général pour le faire). Au pire, tu mets un timeout dans ton daemon pour lui demander de relire le fichier toutes les minutes, mais ça devient superflu.
[ Répondre ]
[ Précédent :: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 :: Suivant ]



Re: Oh, juste un doigt...
(+1 rien que pour la conclusion ! :-)
[ Répondre ]