Linux? - Page 133

GoldenCrystal n'arrête pas de dire que fork() ne sert à rien, donc forcément, on lui dit que si, ça sert, ça ne se remplace pas comme ça par autre chose.

Ouais sauf que tu ne me convaincras jamais…
Je sais parfaitement comment ça fonctionne (bon peut-être pas l'implémentation kernel en assembleur derrière, mais à vrai dire je m'en tape un peu), et y'a peu de chances que tu me fasses changer de position.
Le fait est qu'il n'y a quasiment aucune bonne raison de nécessiter fork de manière générale…
Le coup de redis est plus un hack qu'autre chose, même si ça a effectivement l'effet désiré. Ça marche, mais c'est un cas valide parmi combien de milliers où fork n'apporte vraiment rien… ?

RHJPP (./3960) :
Juste pour le plaisir d'une discussion dépourvue de sens ?

Malheureux ! Ça fait 133 pages que c'est comme çà !

J'étais donc hors sujet ?

RHJPP (./3960) :
Heu et alors ? Je t'explique seulement ce que tu n'avais visiblement pas compris dans l'intervention de Brunni, qu'il était sous-entendu que le clonage était de toute façon nécessaire lors de l'utilisation de processus légers et que l'usage d'une méthode à copie effective lors de la modification est ce qu'on attend de ce clonage.

De mon post, précisément celui que tu cites :

spectras (./3934) :
Si tu réalisais cette tâche dans un thread, soit tu obtiendrais une base de données corrompue, soit tu devrais implémenter toi-même un mécanisme de copy-on-write manuel.

RHJPP (./3960) :
Ha oui, doubler voir plus le trafic vers le disque parce que tu as été incapable de voir qu'une sauvegarde était déjà en cours, et par conséquent compromettre les performances de ton serveur ne te dérange pas ?

Pourquoi les deux sauvegardes devraient être sur le même support ? On peut tout à fait en faire une sur un support local et l'autre sur un NAS, pour ne donner que cet exemple.

RHJPP (./3960) :
Ce paragraphe ne se limite pas à une phrase. Ha ho tiens, la phrase suivante elle disait quoi en fait ?

— La suivante parle des problèmes à essayer de faire plusieurs sauvegardes sur le même fichier. Il me semblait inutile d'y répondre à partir du moment où j'avais précisé qu'on ne fait jamais ça.
— et comme tu vas refaire la même : celle d'après suppose que les sauvegardes sont faites à intervalle régulier. Je ne vois pas non plus d'où sort une telle supposition.
— et sur la dernière phrase du paragraphe, qui dit «il est peu probable qu'il y ait un fichier par sauvegarde car la taille occupée sur le disque serait un peu trop énorme », j'ai juste une réponse : bienvenue dans la vraie vie. T'as une idée de la capacité d'une bande ?
→ Voilà, t'as la réponse complète à tout le paragraphe.

RHJPP (./3960) :
Pourquoi parlerait-on de remplacer les uns par les autres alors ? Juste pour le plaisir d'une discussion dépourvue de sens ?

Ah ben ça
Oui. Ces deux fonctionnalités sont différentes et complémentaires. Sauf dans certains cas particuliers, on ne peut pas remplacer l'une par l'autre sans devoir modifier en profondeur le fonctionnement des programmes. C'est précisément ce que j'explique.

Une autre façon de voir la chose, c'est que fork(), ça revient à créer un thread qui dispose de sa propre copie de la mémoire et des handles.

Du coup, dire que tu peux t'en passer et implémenter la copie toi-même… Tu peux évidemment faire sans, mais c'est alors à toi de développer cette fonctionnalité manuellement dans ton application, avec des outils qui ne sont pas appropriés : tu ne peux pas utiliser la MMU pour faire ça (sauf si tu décides de développer un driver pour ton appli, mais ça revient à faire un driver qui implémente fork() en fait).

spectras (./3966) :
De mon post, précisément celui que tu cites :

spectras (./3934) :
Si tu réalisais cette tâche dans un thread, soit tu obtiendrais une base de données corrompue, soit tu devrais implémenter toi-même un mécanisme de copy-on-write manuel.

Eh bien oui, mais je cite ton message qui cite lui-même celui de Brunni. Et ton message montre que tu n'as pas du tout compris ce que Brunni voulait dire (Brunni, je t'en pris, si je me trompe, tu peux le dire). Et ma réponse à ton post que je cite, c'est pour essayer de t'expliquer ce que tu n'as pas compris. J'ai visiblement échoué, mais ce n'est pas grave.

RHJPP (./3960) :
Ha oui, doubler voir plus le trafic vers le disque parce que tu as été incapable de voir qu'une sauvegarde était déjà en cours, et par conséquent compromettre les performances de ton serveur ne te dérange pas ?

Pourquoi les deux sauvegardes devraient être sur le même support ? On peut tout à fait en faire une sur un support local et l'autre sur un NAS, pour ne donner que cet exemple.

Tu réponds sur ce dont je ne parlais pas ? Intéressant, mais hors sujet. Je parlais uniquement du cas où tu souhaites lancer une nouvelle sauvegarde sur un support alors que la sauvegarde précédente vers le même support a échoué. Tu vas me dire que tu ne fais jamais deux fois tes sauvegardes sur le même support ? Que vient faire la possibilité d'utiliser plusieurs supports là-dedans ?

RHJPP (./3960) :
Ce paragraphe ne se limite pas à une phrase. Ha ho tiens, la phrase suivante elle disait quoi en fait ?

— La suivante parle des problèmes à essayer de faire plusieurs sauvegardes sur le même fichier. Il me semblait inutile d'y répondre à partir du moment où j'avais précisé qu'on ne fait jamais ça.

Bah, relis ? La phrase suivante dit qu'on peut vouloir faire la sauvegarde dans un fichier temporaire pour ne pas compromettre la dernière sauvegarde valide. Autrement dit, pour par exemple ne pas perdre ses sauvegardes si une coupure d'électricité se produit pendant la sauvegarde.

spectras (./3966) :
— et comme tu vas refaire la même : celle d'après suppose que les sauvegardes sont faites à intervalle régulier. Je ne vois pas non plus d'où sort une telle supposition.

Tu n'as qu'à ajouter le mot moyen après intervalle si tu veux.

— et sur la dernière phrase du paragraphe, qui dit «il est peu probable qu'il y ait un fichier par sauvegarde car la taille occupée sur le disque serait un peu trop énorme », j'ai juste une réponse : bienvenue dans la vraie vie. T'as une idée de la capacité d'une bande ?

Bah oui, tu trouves ça extraordinaire ? Même avec une bande, faire une sauvegarde toutes les minutes des 10 Go de base comme le suggérait Kevin, c'est trop gros. Et je peux ajouter que même si ça pouvait se faire, ce ne serait que tu gâchis de place et il ne me semble pas que ce soit le but lorsqu'on fait des sauvegardes.

Du coup, dire que tu peux t'en passer et implémenter la copie toi-même...

Si encore j'avais dit ça... Je n'ai pas encore donné mon avis sur la question. Je n'intervenais que parce que tu répondais à côté de la plaque, ou que tu faisais exprès de ne pas comprendre dans ./3934. J'aurais dû savoir que tu ne le supporterais pas et m'abstenir, désolé.


Bon, sinon, avec tout ça, j'ai enfin décidé si j'aimais bien fork ou pas. Et bien je suis partagé. D'un côté fork c'est pratique si tu as besoin de faire exactement tout ce qu'il fait, mais pas s'il fait des choses en trop... En fait, je trouve que fork n'est pas assez pur comme fonction. Par exemple, pour faire une sauvegarde de la base, fork, c'est pratique puisque tout le processus est copié, on n'a pas à le faire. Mais aussi, pourquoi le processus de sauvegarde aurait-il besoin de tout ce que contenait le processus principal ? Je vais me retrouver avec des copies multiples de choses dont je n'aurai jamais besoin... Par exemple, imaginons que mon processus principal réserve 5 Go de mémoire pour son fonctionnement et que la base à sauvegarder ne fasse pas plus de 10 Mo. Que va-t-il se passer au moment du fork pour la sauvegarde ? Bon peut-être que la base va être recopiée lorsque le processus principal va modifier sa version, et ça c'est cool parce que c'est ce que je veux. Mais que va-t-il maintenant se passer lorsque le processus principal va tout naturellement utiliser la mémoire qu'il a réservée ? La mémoire va être copiée, mais ce n'est pas du tout ce que je voulais ! Et les performances du serveur pendant la copie de ces 5 Go vont sans doute être réduites ! Bon, ce phénomène ne se produit souvent qu'à une petite échelle, mais il me semblerait plus correct de ne cloner que ce dont on a réellement besoin. fork fait trop de choses et il devrait être décomposé.

Bon ça fait plusieurs fois que je repasse, que j'ai la flemme et que je referme l'onglet. Je vais juste me contenter de ça du coup :

RHJPP (./3967) :
fork fait trop de choses et il devrait être décomposé.

Pour n'importe qui disposant d'une vague idée du fonctionnement d'une MMU post-1980 (adressage virtuel, pagination, tout ça), cette phrase est « just wrong ».

Tout le reste de ton message repose sur ça en fait. Je crois y déceler une incompréhension fondamentale de ce qu'est fork() et de ce qui se passe quand tu fais un fork().
Mais peut-être serait-ce plus simple si tu explicitais ce que tu entends par le décomposer ?

RHJPP (./3967) :
ah oui, tu trouves ça extraordinaire ? Même avec une bande, faire une sauvegarde toutes les minutes des 10 Go de base comme le suggérait Kevin, c'est trop gros. Et je peux ajouter que même si ça pouvait se faire, ce ne serait que tu gâchis de place et il ne me semble pas que ce soit le but lorsqu'on fait des sauvegardes.

Sans aller à 1 par minute (ce qui serait possible, juste sans intérêt), 1 par jour est non seulement tout à fait envisageable, mais même plus ou moins standard. Surtout sur une base aussi minuscule.
Pour comparaison, une bande tu mets entre 3 et 5 To dessus, et tes 10Go sont sauvegardés en environ 30 secondes.

Alors c'est vrai, c'est des moyens que t'as pas dans la PME du coin. Mais ça tombe bien, parce que la PME du coin n'a pas ces besoins.

10Go en 10s sur bande ? Faudra m'expliquer... déjà, rien que le temps de positionner la bande au bon endroit s'il y a eu une restoration peut prendre de longues minutes. Pour peu qu'il s'agisse d'une incrémentielle et que les index soient sur la bande et non sur un disque, il faut le temps de la lecture et du positionnement, tu arrives facilement à 30 minutes pour bien moins de 10Go en LTO-2 (petit format, mais encore assez courant...).
Sinon, je ne sais pas où tu sors tes "entre 3 et 5To" par bande, si je ne m'abuse le LTO-6 ne fait pas plus de 2,5Go, et les données enregistrées sont souvent difficilement compressibles (en tout cas re ratio de 2 me semble carrément exagéré).

Et je ne suis pas d'accord avec le fait que la PME du coin n'a pas ces besoin. Pour peu qu'il s'agisse d'une PME qui fasse du traitement audio, vidéo ou photo, elle va devoir gérer des volumes de données énormes. Alors effectivement, dans la plupart des cas, ce sont des données statiques (encore que ça ne soit pas forcément vrai) et on sort de la situation du fork(), mais on ne peut pas présupposer des besoins de stockage d'une PME.

Nil (./3969) :
mais on ne peut pas présupposer des besoins de stockage d'une PME.

Ca c'est certain meme

RHJPP (./3967) :
j'ai enfin décidé si j'aimais bien fork ou pas. Et bien je suis partagé.

J'aime beaucoup cette phrase

spectras (./3968) :

RHJPP (./3967) :
fork fait trop de choses et il devrait être décomposé.

Pour n'importe qui disposant d'une vague idée du fonctionnement d'une MMU post-1980 (adressage virtuel, pagination, tout ça), cette phrase est « just wrong ».

Ou pas, mais ce n'est pas vraiment grave si tu ne me comprends pas.

Nil (./3969) :
10Go en 10s sur bande ? Faudra m'expliquer...

En 30s, pas en 10. L'explication est simple : 160Mo/s x2 (ratio de compression). Soit 320Mo/s si tu l'alimentes de manière optimale, conduisant à 31s pour 10Go.

Évidemment, l'alimenter de manière optimale est difficile, et c'était justement ce que je disais un peu plus haut : que le souci de sauvegarder toutes les minutes n'était pas dans la sauvegarde elle-même mais dans sa préparation, et que du coup ça a complètement du sens d'en figer une copie en mémoire. Ceci étant dit, avec le bon matériel c'est possible, genre réseau de sauvegarde dédié en 10Gbps.
(et oui, s'il faut dérouler la bande c'est long, mais si on va par là, s'il faut la charger c'est encore plus long, et s'il faut attendre que l'opérateur sorte des embouteillages sur la N118, c'est même plus long encore)..

Nil (./3969) :
Pour peu qu'il s'agisse d'une incrémentielle[...]

C'est vrai. Mais si c'est une sauvegarde incrémentale, il n'y a pas 10Go à sauvegarder, en revanche il y a davantage de traitement à faire dessus, ce qui là encore rend le fait d'en figer une copie pour la sauvegarder pertinent.

Le sujet étant l'usage du fork() par redis pour la sauvegarde, j'avais délibérément pris le cas le plus pessimiste à savoir un dump bête et méchant fréquent. Les exemples que tu donnes sont plus réalistes, mais bien plus favorables à l'usage du fork() tel qu'il est fait par redis.

Nil (./3969) :
je ne sais pas où tu sors tes "entre 3 et 5To" par bande, si je ne m'abuse le LTO-6 ne fait pas plus de 2,5Go, et les données enregistrées sont souvent difficilement compressibles (en tout cas re ratio de 2 me semble carrément exagéré).

Le ratio de 2 est celui utilisé par la grande majorité des constructeurs, avec 2 exceptions notoires : IBM, qui utilise un ratio de 3 et Sony, que je ne connais pas mais c'est plus que 2.
Le ratio de 2 est généralement proche de celui constaté en usage réel. IBM est un peu optimiste.
Avec ce ratio de 2, tu obtiens 3Go pour des bandes LTO5, et 5Go pour des bandes LTO6.

Nil (./3969) :
on ne peut pas présupposer des besoins de stockage d'une PME.

Là aussi c'est vrai, mais ça sort du contexte de mon post, qui était l'usage de fork() par redis, et donc les besoins correspondants.
Par ailleurs, il ne faut pas confondre les besoins de stockage, les besoins de sauvegarde et les besoins d'archivage, les trois ne sont que très rarement corrélés.

(enfin bon de toutes façons la supposition de départ, à savoir un backup toutes les minutes, était pour le moins farfelue).

spectras (./3973) :
(enfin bon de toutes façons la supposition de départ, à savoir un backup toutes les minutes, était pour le moins farfelue).

Ca, c'est clair (sinon, tu présupposes aussi que tout le monde soit en LTO-6, ce qui n'est probablement pas le cas )

RHJPP (./3967) :
Mais que va-t-il maintenant se passer lorsque le processus principal va tout naturellement utiliser la mémoire qu'il a réservée ? La mémoire va être copiée, mais ce n'est pas du tout ce que je voulais ! Et les performances du serveur pendant la copie de ces 5 Go vont sans doute être réduites ! Bon, ce phénomène ne se produit souvent qu'à une petite échelle, mais il me semblerait plus correct de ne cloner que ce dont on a réellement besoin. fork fait trop de choses et il devrait être décomposé.

C'est là que tu te trompes, le copy-on-write s'effectue à une granularité de page, souvent 4ko pour résumer. Donc si l'état mémoire des deux processus dérive, ce sera par petits pas de 4ko, l'espace mémoire complet n'est pas dupliqué. Et c'est donc exactement l'effet recherché.

spectras (./3966) :
Du coup, dire que tu peux t'en passer et implémenter la copie toi-même… Tu peux évidemment faire sans, mais c'est alors à toi de développer cette fonctionnalité manuellement dans ton application, avec des outils qui ne sont pas appropriés : tu ne peux pas utiliser la MMU pour faire ça (sauf si tu décides de développer un driver pour ton appli, mais ça revient à faire un driver qui implémente fork() en fait).

Sans manipuler la MMU directement on la manipule forcément à travers les appels système. Tu peux a avoir une sémantique de copy-on-write au sein d'un processus, tu peux faire une sorte de cow-memcpy avec un shm que tu re-mmap en MAP_PRIVATE, pas besoin de patcher le kernel pour ça.


Ça faisait longtemps que j'étais pas passé sur yaronet, 5 ans ? c'est marrant de voir qu'il y a toujours les mêmes

twindruff (./3975) :
C'est là que tu te trompes, le copy-on-write s'effectue à une granularité de page, souvent 4ko pour résumer. Donc si l'état mémoire des deux processus dérive, ce sera par petits pas de 4ko, l'espace mémoire complet n'est pas dupliqué. Et c'est donc exactement l'effet recherché.

Pas du tout. L'effet recherché n'est pas du tout de dupliquer tout l'espace mémoire modifié par le processus parent. Oui, la copie ne se fait que page par page, mais ça change quoi ? Dans mon exemple, les 5 Go alloués ne l'ont pas été pour faire joli, ils sont utilisés... Alors oui, si le processus parent ne fait rien pendant que son enfant travaille, c'est cool, pas de problème. Mais s'il touche à de la mémoire, celle-ci est recopiée et si c'est une partie que le fils n'utilise pas, elle l'est quand même, pour rien. Si un processus lourd est lancé en parallèle, c'est bien parce que la tâche à accomplir risque de prendre du temps alors que le processus parent a autre chose à faire. Et souvent, faire quelque chose implique de modifier de la mémoire. Alors ok, s'il modifie peu de choses, fork fait à peu près ce qu'on veut, mais sinon, non.

Je ne comprends pas cette volonté de prouver que quelque chose est parfait alors que ce n'est pas le cas. fork a ses avantages comme la simplicité dans certains cas, mais a des défauts dans d'autres. En fait, ce ne sont pas vraiment des défauts, c'est qu'il n'est pas adapté. fork ne devrait pas être systématiquement utilisé lorsque l'on souhaite lancer un processus lourd utilisant la copie d'une zone mémoire du parent. On devrait pouvoir demander une copie (qui ne sera effectuée que lors de la modification) d'une zone mémoire et la donner en paramètre à un nouveau processus. C'est certainement possible, mais pas simplement avec fork.

spectras (./3934) :
Enfin, même s'il était possible de demander à l'OS de prendre un instantané et de l'écrire dans un fichier (ce que aucun OS ne permet à ma connaissance), ça ne permettrait pas de réaliser la sauvegarde, car l'OS n'est pas capable de faire une sérialisation propre des structures mémoire de la base de données.

"personnellement" je n'utilise jamais de structure, je fait tout à la main (exemple : https://github.com/r043v/rdd/blob/master/rdd.c#L23 )
pour le coup l'os pourrais me faire mon dump sans sourciller ?

robinHood (./3930) :
donc on peut faire cette copie "virtuelle" sans devoir faire forcément un fork ? ca rulez

robinHood (./3949) :
mis à part ca je suis allé regarder le copy-on-write et je suis très déçu de ne trouver un jolie void* cow(void*); nulle part :- /

une api dédié ? ou pour le coup seul fork propose cette fonctionnalité "bas niveau"
ce qui va parfaitement avec

fork fait trop de choses et il devrait être décomposé.

(mis à part ca, redis n'est pas con, il vérifié que la save est terminé avant d'en lancer une nouvelle, mais il fait tout de même par default (avec un l ) une save quant 1000 modif sont effectués en moins de 60 secondes, à vous de voir si c'est trop ou non, cela ne me parais pas "trop")

concernant les pme, voici 3 mois que je travaille au corps mon ancien patron lui mettant en avant (entre autre) l’absence totale de saves etc
et me voila actuellement avec un contrat ou je touche 10% du CA brut et ca ça rulez :- D

Dans mon exemple, les 5 Go alloués ne l'ont pas été pour faire joli, ils sont utilisés... Alors oui, si le processus parent ne fait rien pendant que son enfant travaille, c'est cool, pas de problème. Mais s'il touche à de la mémoire, celle-ci est recopiée et si c'est une partie que le fils n'utilise pas, elle l'est quand même, pour rien. Si un processus lourd est lancé en parallèle, c'est bien parce que la tâche à accomplir risque de prendre du temps alors que le processus parent a autre chose à faire. Et souvent, faire quelque chose implique de modifier de la mémoire. Alors ok, s'il modifie peu de choses, fork fait à peu près ce qu'on veut, mais sinon, non.

Je n'ai jamais dit que c'était une solution parfaite ... C'est juste une solution simplissime pour faire des snapshots.
Il faut que tu arrêtes de raisonner avec ton exemple d'un système de base de données (SGBD) qui utilise 5Go de mémoire pour "son fonctionnement" pour 10Mo de données utiles parce qu'il est un peu bête.
Aucun SGBD n'utilise 5Go pour "son fonctionnement" pour si peu de données. D'abord c'est quoi la mémoire qu'il utilise pour "son fonctionnement"?
Les 99,9% de mémoire qu'un système comme redis utilise c'est pour les données utiles: indexes + stores, et c'est celles-là qu'on veut sauvegarder ...

RHJPP (./3976) :
On devrait pouvoir demander une copie (qui ne sera effectuée que lors de la modification) d'une zone mémoire et la donner en paramètre à un nouveau processus. C'est certainement possible, mais pas simplement avec fork.

Je l'ai expliqué plus haut, tu peux faire ça avec de la mémoire partagée (shm) que tu peux remapper à loisir en copy-on-write, même pas besoin d'être dans un processus externe. Simplement ça nécessite que tu alloues tes objets utiles (à backuper) dans cette zone, rajoute de la complexité dans le code.

robinHood (./3949) :
mis à part ca je suis allé regarder le copy-on-write et je suis très déçu de ne trouver un jolie void* cow(void*); nulle part :- /

Tu peux faire ça comme ça http://www.mirari.fr/OSN8
Extrait:

int fd = shm_open("/utile", O_RDWR | O_CREAT, 0600);
ftruncate(fd, size);
int *p1 = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
int *p2 = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); /* cow */

class, merci ! :- )

twindruff (./3978) :
Il faut que tu arrêtes de raisonner avec ton exemple d'un système de base de données (SGBD) qui utilise 5Go de mémoire pour "son fonctionnement" pour 10Mo de données utiles parce qu'il est un peu bête.

Ouais, mais je ne parlais pas de bases de données. Mon exemple était pour un programme quelconque qui manipule de grandes quantités de mémoire et qui n'a pas grand-chose à sauvegarder. J'avais plus dans l'esprit une application de traitement scientifique qui à partir de grandes quantités de données obtient des résultats où un état à sauvegarder régulièrement. Mais je suis sûr qu'on peut trouver beaucoup d'autres applications ayant ce profil.

twindruff (./3978) :
Je l'ai expliqué plus haut, tu peux faire ça avec de la mémoire partagée (shm) que tu peux remapper à loisir en copy-on-write, même pas besoin d'être dans un processus externe. Simplement ça nécessite que tu alloues tes objets utiles (à backuper) dans cette zone, rajoute de la complexité dans le code.

Bah c'est très bien de pouvoir remplacer fork lorsque celui-ci n'est pas adapté

RHJPP (./3976) :
les 5 Go alloués ne l'ont pas été pour faire joli, ils sont utilisés... Alors oui, si le processus parent ne fait rien pendant que son enfant travaille, c'est cool, pas de problème. Mais s'il touche à de la mémoire, celle-ci est recopiée et si c'est une partie que le fils n'utilise pas, elle l'est quand même, pour rien.

Mais non!

1 -> Le pere (la mere, parent1 ou parent2, voir le St Esprit suivant tes choix) alloue 5Go.
2 -> il fait un fork

a) d'une part grace au CoW on ne duplique pas les 5Go
b) une fois le fork effectué les deux processus sont DIFFERENTS donc
- Si le pere change une partie des 5Go le fils n'est pas impacté, ou du moins le fils va dupliquer les pages modifié pour garder les version originales.
- Si le fil nb'a pas besoins des 5Go pour l'allouer avant ? En regle général, on ne fork pas comme ça, en tout cas pas en plein milieux d'un calcul. Au pire, le fil peux faire un free sur les 5Go alloué !

Si le pere modifie ça mémoire ça n'impact pas le fil, et vice-versa. Si tu veux que la mémoire soit partagé il faut faire... des threads et non un fork!

robinHood (./3977) :
me voila actuellement avec un contrat ou je touche 10% du CA brut et ca ça rulez :- D

Et bin, joli! Du CA de la boîte?! Ca me paraît énorme! (sauf si vous êtes <4 dans la PME... )
Godzil, ./3982> p'tain fais un effort, ça pique vraiment les yeux de te lire

10% brut des sites que je lui refais avec un contrat hyper verrouillé, pour une 20ene de sites à la fin

disons que sa politique étais de prendre des gens en contrat aidé, apprentissage, CIRMA etc, par exemple pour rentrer chez lui j'avais du avant tout demander le rsa (en contrat CIRMA il touche lui aussi mon rsa ce salaud!) x_x

bref ca ajouté à une ancienne politique concernant les clients "passable", ca fait que les équipes tournent sans cesse, une dizaine de personne différente à du passer sur chaque site, sites d'origine fait très très vite, à l'arash, bref moyen

pour finir, le dernier algo de google à défoncé un des site principal, passant de 1er ~ 3eme à la page 14 (en même temps, 7000 produits et 300k pages référencé ca le fait pas)

donc il etais dans la merde, avais dégagé l'ensemble des employés "création web" qui restais, bref j'ai vu la faille et m'y suis engouffré, il à vachement confiance en moi et mon associé, ayant tous les deux bossé pour lui avant, mais cette fois nous sommes une boite nous aussi ce n'est pas comme avant

Bien joué

robinHood (./3985) :
chez lui j'avais du avant tout demander le rsa (en contrat CIRMA il touche lui aussi mon rsa ce salaud!) x_x

WHAT!!!?

Attends, tu parles quand même pas du boss avec qui t'avait une liste de différends professionnels et personnels longue comme le bras ?!

celui la même ^^

concernant l'immeuble ont avais réussi à faire annuler le permis de construire et depuis il c'est calmé sur ce sujet

pour les droit d'auteur des réalisations de mon associé, ce con s'en tape plus ou moins, il l'attaquera jamais la dessus (pourtant il y avais largement de quoi faire -_- ), moi même j'avais vachement fait prospérer la boite (elle fait plein de chose mais en gros 50% de l'activité c'est de la création de faire-part) en réalisant moult éditeurs en ligne, au lieu que le client donne simplement son texte, qu'un maquettiste fasse ensuite un bat etc, la ça sort directement une planche A3 haute résolution, prête à être imprimé/découpé/plié/envoyé, gain de temps 10000%

bref c'est aussi un juste retour des choses, il nous avais utilisé la c'est à notre tour ^^

---

http://entrepreneur.lesechos.fr/entreprise/social/aides/aide27-contrat-insertion-revenu-minimum-d-activite-cirma-36.php

Aides à l'employeur
En contrepartie de l'embauche de salariés sous CIRMA, les employeurs bénéficient pendant la durée de la convention d'une aide financière allouée par le département ou la collectivité d'un montant égal à celui du RSA attribué à une personne isolée. Cette aide est prise en charge en partie par l'État via l'ASP en cas d'embauche d'un bénéficiaire du RSA.

Le service de l'aide à l'employeur est assuré par le département ou un délégataire pour les salariés bénéficiaires du RSA, et par l'ASP pour les bénéficiaires de l'ASS ou de l'AAH.
L'aide est versée à l'employeur mensuellement par avance et est proratisée sur la base d'1/30e.
À noter : pour les bénéficiaires du RSA, le département peut également prendre en charge tout ou partie des coûts inhérents aux embauches effectuées sous CIRMA (coûts liés à la visite médicale obligatoire, frais engagés pour l'acquisition de matériel de sécurité, etc.) ainsi que des frais engagés pour dispenser aux salariés concernés, pendant le temps de travail, certaines formations autres que celles nécessaires à l'adaptation des salariés à l'évolution de leur emploi.

visiblement le contrat n'existe plus, mais oui c'est abusé ^^

enfin je l'avais aussi utilisé dans mon sens, au bout de six mois je devais re signer le contrat au CEDIS, j'ai refusé de le faire sans être augmenté, bon j'ai eu du black simplement mais le coup de pression avais fonctionné hehe

Je comprends pas pourquoi tu veux rebosser avec un type comme ça, même si pour le moment c'est à ton avantage ça crève les yeux qu'il te refera une saloperie dès qu'il le pourra...

je verrais bien mais j'ai vraiment verrouillé le contrat, en fait la il à simplement un droit d'exploitation, rien ne lui appartient à part les nom de domaines, et même si il les revend je touche 10% et le contrat est transféré avec

aussi il à pris un associé qui est lui vraiment réglo, il à remis pas mal de chose sur les rails depuis qu'il est la

et puis il faut avouer c'etais un peu la galère de clients ces derniers temps la au moins j'ai du taf ^^

robinHood (./3985) :
sites d'origine fait très très vite, à l'arash, bref moyen

à la RACHE bordel!

robinHood (./3990) :
en fait la il à simplement un droit d'exploitation

bien, bien ouej