Je ne dis pas le contraire, mais il faut se rendre à l'évidence que pour les opérateurs la campagne n'est pas rentable à court terme. Installer la 4G là bas coûte cher et demande du temps, notamment parce qu'il faut y fibrer des équipements intermédiaires ce qui est déjà fait à proximité des villes mais pas en cambrousse. Avec une antenne en ville tu rentabilise bien plus vite l'investissement.
Il faut donc attendre que les infrastructures se mettent à niveau et que les équipements baissent en tarifs. Car avec les nouvelles fréquences allouées à 700 MHz en France, avec une antenne tu peux couvrir plus de territoire car la fréquence est basse et les nouvelles infrastructures pourront profiter des installations pour couvrir en une fois toutes les bandes de fréquence ce qui est moins cher que de faire en plusieurs étapes comme aujourd'hui en ville. Vu la faible rentabilité de la campagne pour eux, c'est normal que cela traine un peu.
Pour les offres, cela commence à arriver et c'est dans le plan THD de la France que les endroits trop isolés bénéficient de l'accès par satellite ou radio pour l'abonnement fixe d'ici 2020-2022. D'ailleurs Orange propose avec sa nouvelle box la possibilité d'utiliser la 4G pour récupérer Internet en cas de panne de la liaison fibre ou ADSL. Et l'offre Free avec 50 Go/mois (pour 20€) en 4G peut servir de ligne fixe en utilisant le téléphone comme routeur Wifi si le besoin n'est pas important et la couverture bonne. J'ai des copains qui font ça d'ailleurs.
C'est un début, nul doute que cela sera plus courant plus tard quand la campagne pourra profiter de la 4G.
Bah oui, faut bien que cela arrive un jour (2020 c'est dans longtemps quand même, tu auras le temps de t'y adapter et un téléphone 3G ça ne coûte rien).
Aux États-Unis ou Australie par exemple la 2G chez eux est déjà en train d'être coupée par les opérateurs et cela ne semble pas être un drame national.
Tu peux d'ailleurs voir les projets de coupure de service dans le monde.
Bref, il ne faut pas oublier que le spectre radio est très limité et que la 2G pour le moment occupe bien plus de bande passante que nécessaire (car le nombre d'usagers baisse constamment) en plus d'avoir des performances pourries et de nécessiter des puces spécifiques pour traiter ce signal analogique (le tout 4G permettrait sans doute un gros gain énergétique, de coûts et de performances car purement numérique).
Cela me paraît raisonnable de prévoir la coupure progressive du service dans le temps et l'espace en autoriser les opérateurs à exploiter ces fréquences pour la 3G et 4G dont le besoin est important pour assurer des débits corrects à tous les utilisateurs.
Mais cela peut être fait je pense intelligemment : prévoir plusieurs années en avance, et faire le transfert là où la 3G/4G est bien en place et dont le besoin est important (centre des grandes villes donc) avant de s'occuper à la campagne sur la fin quand le reste pourra prendre le relai.
Si, car les opérateurs connaissent le modèle de téléphone utilisé par chaque puce et ils ont une table de l'ensemble des identifiants uniques de chaque téléphone également pour notamment empêcher l'usage des téléphones volés.
Bref, un GSM libre n'empêche nullement une coupure de la ligne par l'opérateur ou l'État, de même que ta connexion Internet filaire n'est pas à l'abri parce que ton routeur est libre.
Car le matériel pour analyser le spectre radio n'est pas donné et que c'est vachement plus contraignant à travailler qu'une carte graphique où tu as accès notamment à l'écran (donc la destination de tes interventions). Sans accès au matériel télécom, il est difficile d'appréhender le système dans son ensemble pour éviter de commettre des fautes (qui peuvent être sanctionnées).
Sauf un, ils respectent le test d'homologation.
Après si le test d'homologation ne représente pas la réalité du terrain, c'est autre chose et ils n'en sont pas coupables.
On parlais du Macbook.
S'il est vrai que les constructeurs PC ont des marges ridicules et des ventes en recul, Apple tire l'essentiel de son revenu de l'iPhone et dans une moindre mesure de l'iPad.
Donc comparer l'argent disponible d'Apple avec des concurrents sur un secteur où Apple tire assez peu de revenus, c'est plutôt malhonnête.
De la même façon que tu ne compares pas les sous disponibles chez Microsoft et Sony sous prétexte qu'ils vendent des consoles, il y a la musique, le logiciels et d'autres matériels derrière à comparer où ils ne sont pas en concurrence.
Euh, si ton contrat de travail n'est pas respecté, il y a les prud'hommes.
Et c'est valide aussi pour un contrat de travail avec des clauses illégales.
Que veux-tu de plus ? Quand quelqu'un ne respecte pas la loi ou un contrat, c'est la case justice. C'est invariable. Je ne vois pas en quoi le télétravail est un problème différent du salaire là dessus…
C'est exact. Le salaire est une garantie, le reste ce sont des promesses, elles n'engagent que ceux qui y croient
Faut arrêter un peu.
Zenitram ne possède pas une SSII, dans ce genre de boîtes ne pas respecter ses promesses est très risqué pour les partenariats ou recrutements futurs.
Dans le monde du travail il est important de faire confiance, si tu veux que tout soit codifié à 100% c'est le meilleur moyen d'avoir des relations tendues et de ne rien obtenir de positif.
Oui, même le télétravail ou la promesse de bosser sur du libre sont des promesses, ce sont des clauses qui peuvent facilement sauter.
C'est le genre de choses qui se mettent normalement dans le contrat de travail. Du coup c'est très facile d'en faire une promesse contraignante.
De toute façon faut garder à l'esprit que c'est un CDD d'un an, une belle période d'essais pour tester l'entreprise et les promesses avant éventuellement de s'engager plus longuement.
Je t'en pris, prends sur ton temps pour faire les recherches qu'a fait Alenvers sur vos questions.
La seule source qu'il a utilisé contre mes arguments est erronée, donc bon.
Je ne parle pas de l'aspect technique des cgroups où je n'ai pas pris part à cette discussion.
Et l'état de l'art aurait du être fait initialement par Lennart pour proposé la meilleure façon de progresser, plutôt que de faire "on faut que comme ça et on essaie pas de voir ce qui pourrait être intéressant de mutualisé, ou si c'est possible".
C'est amusant.
En quoi c'est amusant ? Un gars va dire que l'avantage du Logiciel Libre, sa force, sa raison d'être c'est de fonctionner comme un bazar où chacun apporte ce qu'il veut, quand il veut, sa pierre à l'édifice, puis un autre va dire que non le gars plutôt que de faire ainsi il aurait du faire une RFC et y travailler pendant des années avant de proposer le projet final.
Quelle est la meilleure option ? Le bazar l'emporte je pense, déjà on ne peut pas forcer Lennart de faire un travail qu'il n'a pas forcément envie de faire.
De plus, il n'a forcé personne à utiliser son programme. Les gens l'ont pris telle qu'elle, c'est donc qu'il répondait au besoin ce qui ne l'incite pas à travailler sur la question de la portabilité. C'est à ceux qui veulent un systemd portable qui doivent y réfléchir.
N'oublions pas qu'à l'origine, le noyau Linux a été conçu pour être très proche de l'architecture i386. Pourtant aujourd'hui le noyau gère bien plus d'architectures matérielles, dont des architectures sans MMU…
systemd pourrait suivre cette voie. Pourquoi pas, personnellement je n'ai rien contre. Mais quelqu'un doit s'y atteler et prouver que c'est faisable sans tout foutre en l'air. En tout cas vouloir imposer cette tâche à Lennart est un non sens.
Tu veux dire plus ridicule qu'un type qui t'explique que l'init doit "babysitter" les processus (son terme) et les utilisateurs ?
systemd n'est pas qu'un système d'init, faudrait arrêter un jour de se fixer là dessus.
Plus ridicule que de considérer que linux est un château et qu'il ne faut surtout pas essayer de faire quelque chose qui pourrait servir à d'autres ?
Il est libre de faire ce qu'il veut pour son projet (ou son employeur peut décider de ce qu'il veut).
gros bloatware qui veut tout gérer, et prend des décisions franchement déplacée, en considérant uniquement leurs cas d'utilisation et disant que c'est tant pis pour ceux qui n'ont pas le sien ?
Si ce logiciels est si pourri, si techniquement horrible, pourquoi toutes les distributions y passent ? Pourquoi les gens se focalisent sur sa non portabilité sur les autres systèmes si ce programme ne les intéresse pas ?
Bref, râler là dessus n'a de sens que si on considère son utilité.
Tu es sur ? ou tu crois que peut être il acceptera ?
Est-ce important ?
L'avantage du libre, c'est que si le projet ne va pas dans le sens voulu par ses utilisateurs, on peut le forker. Si les gens n'ont pas confiance en Lennart ou veulent la portabilité absolument, le fork pourrait avoir lieu et détrôner la branche originale du projet.
Si le correctif pour la portabilité est simple et que Lennart refuse, il n'a pas de raison que le fork ne fonctionne pas.
Oeil, paille poutre.
Si tu as fait attention, mon message précédent était largement inspirée du style de mon ancien correspondant.
L'argument du tout au rien, du parfait ou rien, un grand classique.
Pour moi les *BSD c'est au minimum les trois connus : FreeBSD, OpenBSD et NetBSD pour des raisons historiques, de représentativité et de domaine d'exploitation.
Que seul l'un des deux est une telle interface et qu'on ignore l'avancement des autres sur le sujet (est-ce prévu à terme ?) est selon moi problématique.
75% des utilisateurs de BSD ce n'est pas négligeable.
Bon, je vais te poser la question :
tu as vérifié ta source avant de balancer des conneries ?
Ton graphe, si on somme l'ensemble donne 135.3%. Il est manifestement faux (ou alors tu as un livre génial de statistique qui va expliquer ce graphe) sans compter qu'on a aucune idée de comment cela a été mesuré (l'image vient de Wikimedia, mais qui a mesuré et comment ?)
Bref, ton chiffre, c'est du pipeau.
Avant de poster, tu pourrais au moins avoir des sources correctes et les lire correctement…
Le 100% de compatibilité n'a jamais existé. Il faut toujours commencer par quelque chose.
Je suis sûr que les utilisateurs d'OpenBSD et de NetBSD seront ravis de voir que la portabilité ils n'y ont pas le droit.
Après si on part du principe que les *BSD ont des PdM négligeables devant Linux, on peut dire que la portabilité de systemd actuelle est suffisante, non ?
Où est la limite donc ? C'est tellement arbitraire que s'en est ridicule.
S'il n'y a « plus qu'à » implémenter un interface, je pense qu'il y aura bien des gens qui l'implémenteront pour les autres unix (solaris, aix, …).
Possiblement, je ne suis pas expert en systemd et Lennart a présenté le refus par volonté d'être proche de Linux et qu'il n'a pas envie d'avoir un code trop bizarre pour gérer tout le monde. Si quelqu'un se ramène avec un code simple à gérer, je suis sûr qu'il l'acceptera. Du coup, qui est volontaire ?
Tu as cherché avant ? Non ? Ce serait bien si tu renseignais avant.
J'ai cherché et je maintiens mon point de vue : deux systèmes *BSD majeurs manquent à l'appel. On est donc loin d'une solution simple aussi générique que présenté (et évident à faire).
Mais balaye devant ta porte avant d'engueuler les autres. Merci.
PS : Remarque, j'apprends de mes erreurs. Quelque soit la façon d'exprimer les choses, on se fait pourrir ici. Et vu le peu de réaction de la « communauté » c'est normal. Donc, aucun intérêt à prendre des pincettes : cela ne fonctionne pas.
Je ne t'ai pas pourri, donc je ne mérite pas ce traitement.
Si tu veux, je peux te conseiller des livres sur le respect et les règles de communication. Après tout, tu as du chercher sur le sujet avant, non ?
Tu t'es renseigné avant de dire cela ? Parce que je parie qu'en cherchant environ 15 secondes je trouve un équivalent clair…
Ce serait bien si tu étais moins agressif…
Paf, premier lien de ma première recherche « freebsd cgroups ». Un click plus loin, je trouve rctl.
J'ai parlé des *BSD or apparemment un seul s'est penché pour le moment sur la question. Du coup mon point de vue reste valide : il n'y a pas d'équivalent sur l'ensemble des UNIX libres (on parle de portabilité globale je crois, c'est donc important comme précision).
Si tu l'es, tu devrais te renseigner sur L'attaque de l'homme du milieu.
sans HTTPS, tu n'as aucune garantie que l'ISO que tu télécharges est celle qui est sur le serveur (en plus de ne pas savoir si le serveur est légitime). Et ce n'est pas les SHA256sum qui va t'aider (il est au même endroit donc tout autant falsifiable).
Je trouve l'approche de Fedora intéressante.
Les ISOs sont en HTTP mais les hashs sont hébergés sur le site officiel en HTTPS. Cela évite à gaspiller des ressources pour chiffrer une communication lourde et pas confidentielle.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer.
Non. Cela veut dire prendre en compte les différente spécificités.
Tout dépend de la quantité de code en dehors du socle commun.
Si la quantité est faible et peu impactant (ne change pas l'architecture du programme) oui tu peux te permettre à gérer l'ensemble des différences.
Ici, ce n'est pas le cas. Typiquement les cgroups sont trop liés à Linux et trop au cœur de son architecture pour rendre cela élégant et simple sur d'autres systèmes.
videmment qu'il n'y aura pas de cgroup sous bsd, et alors est-ce que ça rend le 99% restant des autres features non pertinant ?
L'architecture de systemd a été conçue pour coller au fonctionnement de Linux car c'était son but d'exploiter les possibilités du noyau que ne permet pas POSIX par exemple.
C'est loin d'être aussi trivial que tu ne le prétends, et c'est pour ça que Lennart encourage les forks du projet plutôt que de gérer la portabilité.
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
Non.
Si le code a des #ifdef de partout pour gérer Linux d'un côté, *BSD de l'autre, XXXX finalement, c'est difficile à maintenir et ça va créer beaucoup de bogues pour un gain discutable.
La portabilité peut rendre robuste un programme, oui, mais pas si ce programme a couplage fort avec un autre composant où l'effet est inverse.
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement…
Pas forcément, la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
Et là l'espace utilisateur n'aurait rien à secouer de la "fragmentation" de systemd en différentes versions suivant les système.
surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible
SysV, ce n'est pas que le shell, c'est tout ce qu'il y a derrière les scripts et c'est là le problème. La gestion des périphériques ? Pas standardisée. Les modules de sécurité (SELinux et autres) ? Non plus. Les cgroups ? Oublie. Etc.
Même entre les différentes distributions ce n'était pas possible d’homogénéiser les scripts proprement. Et c'était très complexe dans une même distribution d'être cohérent, certains typiquement géraient que partiellement l'existence de SELinux par exemple.
Donc homogénéiser avec d'autres systèmes qui ont des différences fondamentales sur ces questions, c'est chercher la merde pour la maintenance de ce code unique.
Au final c'est l'utilisateur qui trinque et doit gèrer 50 façons différentes, ce qu'il ne fait pas. évidemment. Résultat ? Fragmentation de l'éco-système et affaiblissement/mort générale. Dire que seul Linux importe, c'est reffaire la même erreure et faire preuve de trop d'optimisme, il est probable qu'il soit perdant aussi…
À t'écouter on dirait que tout l'espace utilisateur doit prendre en charge systemd d'un côté, SysV de l'autre, etc.
C'est faux… À part quelques programmes assez spécifiques, les applications et utilisateurs s'en cognent de systemd. Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié…
Oui 100% d'accord. Vu que systemd est en gros cette nouvelle API/standard, c'est dommage de ne pas avoir pris l'opportunité de le faire correctement. 95% du code de systemd n'est pas du code system dépendant hein…
Vu que tu trouves le correctif nécessaire trivial, je t'invite à l'écrire, le maintenir et le soumettre. Lennart refuse car il sait que ce serait un gros travail. On attend ton code pour prouver le contraire.
Alors que, objectivement, porter un logiciel n'impacte pas sa qualité, au contraire. C'est tellement gros que venir affirmer le contraire est faire preuve d'une mauvaise foie flagrante.
Objectivement, il a en partie raison quand même sur ce point. Sinon c'est ignorer les impacts d'un portage.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer. Cela impose des limites, typiquement systemd repose sur les cgroups que les *BSD n'ont pas (ou en équivalent clair). Porter systemd revient soit à virer tout ce qui exploite les cgroups, ou alors à faire du code sale / difficile à maintenir pour se comporter sous Linux et *BSD de manière différente. Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc. si les comportements doivent différer car les mécanismes sous-jacents sont différents.
Bref, la raison technique invoquée est loin d'être délirante et pour un projet comme systemd les risques de soit le vider de son sens, soit de le rendre vraiment horrible à maintenir sont grands. La question à se poser est : est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ? C'est discutable. À dire vrai, je pense que pour exploiter au mieux les possibilités de chaque système, il est plus intéressant que ce soit disjoint. Après tout, cela a été globalement le cas depuis toujours (SysV n'a jamais été sous *BSD, et même entre les différents Linux ce n'était pas la joie). Pourquoi nécessairement changer ?
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.
Effectivement, si les paquets changent de nom, c'est pas simple.
Ce n'est pas ça le pire.
Les distributions embarquent des versions différentes de chaque application et donc dépendance. Pour que le tout fonctionne de manière cohérente, il faut souvent gérer un certain nombres de correctifs sur les paquets.
Sans oublier que le découpage des paquets n'est pas identique d'une distribution à l'autre, tu peux par exemple découper KDE, Qt ou la glibc de bien des manières différentes pour aboutir au même résultat. Mais ces différences, qui existent en réalité, vont également casser ta résolution de dépendance.
Sans oublier parfois l'incompatibilité manifeste entre deux paquets de distributions différentes, si un paquet a besoin de Qt 4 et l'autre de Qt 5, tu peux avoir des soucis si la distribution cible n'a pas plusieurs exemplaires de la bibliothèque.
Le risque est que cela divise la communauté et les aspects techniques pour des questions de guerre de clochers.
Les autres distributions et environnements de bureau ont travaillé sur quelque chose dont il semble que Canonical n'a pas exprimé beaucoup d'idées ou de requêtes. C'est dommage de faire son truc dans son coin alors que depuis 2 ans une solution technique était en discussion et ouverte à tous. Si au moins un effort notable pour travailler sur ce projet public avait été tenté, ça aurait eu du sens.
D'autant qu'il y a enfin une vraie synergie à faire de Flatpak un succès.
C'est beaucoup plus simple que de devoir faire la queue pour aller au guichet, c'est justement mieux chez les banques en ligne !
Pour encaisser un chèque au Crédit Agricole, c'était remplir un papier à mettre dans une enveloppe avec le chèque et la mettre dans une boîte en libre service en agence mais pas au guichet. Donc pas de queues.
Faudrait être fou pour avoir besoin du conseiller pour ça. Oo
Hors sujet complet, ça n'a rien à voir (c'est bon, on a déjà eu la discussion sur les CC ND, on doit vraiment re-expliquer encore et encore que ça n'a rien à voir? si je reprend la GPL et la modifie en disant "ce n'est pas la GPL", montre-moi comment je peux tromper le gens, par contre je ne peux pas le faire… Bizarre)
Ce n'est pas hors sujet, un texte intitulé "Mémoires de x" a du sens de ne pas être modifié car cela représente la vie de la personne qui l''a écrite dont ses pensées. Cela ne me paraît pas délirant que ce genre d'ouvrages ne soient contrôlés que par l'auteur car il est concerné/impliqué bien autrement que pour les autres formes d'arts. Il ne saurait être question de modifier la pensée de la personne, ce qui pourrait avoir des conséquences d'ailleurs.
Cet argument ne s'applique pas à l'art (pour moi un mémoire n'est pas artistique, faut le voir plus comme un journal intime mieux rédigé) et dont aux romans qui sont des fictions. Ta contre-attaque est hors sujet car je suis d'accord avec toi sur l'art libre.
Pareil pour les licences et le droit : une licence c'est figée, permettre la libre modification peut poser des soucis : cela n'a pas de sens de modifier la loi librement comme ça (cela doit suivre un processus législatif), ni une licence car cela peut entretenir la confusion (la licence se réfère à la GPL, mais laquelle ? Éditée par qui et quand ?)
(et pour troller : il est d'ailleurs rigolo de voir une interdiction de modifier, donc pas libre, sur la GPL sensée être faites par des gens aimant le libre, le libre c'est bien sauf pour ce qu'on fait nous ;-) )
RMS a justifié cela en disant que les textes légaux et de droits ne devaient pas être libres tout comme les mémoires par exemple.
Le but est d'éviter les effets de bords d'un tel cadre : attribuer des pensées que la personne n'a jamais eu, modifier la constitution ou le texte sur lequel la protection juridique se repose, etc.
Outre le fait que tu n'as pas su interpréter correctement le tableau, car les données se recoupent entre elles, tu interprètes mal pas mal de chose…
cancer 150000 morts (sûrement des branleurs avec une hygiène de vie déplorable)
D'après la page de Wikipédia sur le cancer :
En 2015, on estime le nombre de décès liés au cancer à 150 000. Le cancer lié au tabac est responsable de 47 000 décès. 15 000 décès sont, eux, associés aux cancers liés à l'alcool157.
En gros, plus d'un tiers des cancers sont largement imputable au mode de vie. Et on ne peut pas dire que l'État ne fait rien contre le tabac. L'alcool n'est pas assez combattu en France pour des raisons culturelles c'est vrai.
Et beaucoup de cancers sont eux dus soit à la génétique, soit à la vieillesse. La portion restante étant de causes inconnus ou très éparses. Difficile en tout cas de stopper les cancers autrement que ceux imputables au mode de vie.
maladies cardio vasculaires 140000 morts (surement des gros qui font pas d'effort pour se bouger le cul)
Difficile d'avoir des chiffres sur la part du mode de vie dans ces maladies. Cependant il est évident que le mode de vie a une incidence forte sur leur apparition : manque de sport, tabagisme, diabète, alimentation inadapté, etc.
Ce qui reste, comme pour les cancers, sont difficilement évitables.
drogues 94000 morts, dont tabac 60000 (tant pis pour les fumeurs) (et tant pis pour leurs enfants aussi tiens)
Hum, tu trouves que l'État ne lutte aps assez contre le tabac et les drogues ?
diabète : 32000 (encore des gros)
À part les diabétiques de type I, ce qui concerne moins d'un diabétique sur dix, ces morts là sont en effet évitables avec une meilleure hygiène de vie.
Il est vrai que l'État ne fait pas encore assez sur ce secteur, bien que ce soit en progrès.
accidents domestiques : 16000 (des cons, quand tu vois 8000 morts à cause des chutes)
suicides 13000 (encore des cons)
Hum, tu veux que l'État fasse quoi contre les suicides en particulier ? Ou même les accidents de la vie qui arrivent.
L'État peut difficilement faire un meilleur bilan, le système de santé dans ces cas sont assez efficaces dans l'ensemble. Le problème est que certaines maladies ne sont pas soignables, et certains patients sont parfois trop fragiles aussi.
Bref, faire mieux est délicat, et ce qui est possible de faire est un immense chantier (faire encore mieux contre les maladies nosocomiales, l'hygiène dans la population…).
Voilà, donc je pense qu'il y a autre chose que de s'occuper de ce qui est la 24e cause de mortalité en France (même si je déplore le moindre mort, évidemment) et d'occuper 80% de l'espace médiatique (pas 100%, on parle du cancer du sein parfois, ou de la prostate - parité oblige) avec un truc aussi insignifiant.
Tu oublies la lutte contre le tabagisme, les drogues, les campagnes de prévention ou de dépistages…
Je pense que le seul combat que l'État ne fait pas suffisamment c'est vis à vis de l'alcool, et éventuellement la malbouffe. Mais dire que seul la sécurité routière est visée c'est du grand n'importe quoi.
Sans oublier que rien n'empêche de lutter contre l'insécurité routière et les autres causes de mortalité. Ce n'est pas exclusif.
Au moins autant d'handicapés supplémentaires que de morts
Bref, c'est quand même utile de lutter contre, d'autant que tous ces accidents sont évitables avec le respect du code de la route (alors que beaucoup de décès en France sont dus à des choix de vies du citoyen, ou à une fin de vie normale). Des décès évitables et avec effets collatéraux, les accidents de la route sont plutôt bien placés.
La quasi-totalité des écoles privées, que ce soit post-bac ou primaire/collège/lycée bénéficient d'aides importantes de l'État voire d'entreprises dans le cadre de la taxe d'apprentissage.
Du coup le prix affiché est très loin du coût réel.
EDIT : si tu veux les bons tarifs, trouve une école privée hors contrat avec État et là ça rigole moins pour les frais de scolarité.
[^] # Re: Utilisateur exigeant qui assume ses choix, mais l'accessibilité
Posté par Renault (site web personnel) . En réponse au journal Lettre à mon copain Errol. Évalué à 4.
Puis les livres numériques peuvent être lus par un lecteur braille ou un synthétiseur vocal…
[^] # Re: Moi aussi
Posté par Renault (site web personnel) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 4. Dernière modification le 18 juin 2016 à 21:15.
Je ne dis pas le contraire, mais il faut se rendre à l'évidence que pour les opérateurs la campagne n'est pas rentable à court terme. Installer la 4G là bas coûte cher et demande du temps, notamment parce qu'il faut y fibrer des équipements intermédiaires ce qui est déjà fait à proximité des villes mais pas en cambrousse. Avec une antenne en ville tu rentabilise bien plus vite l'investissement.
Il faut donc attendre que les infrastructures se mettent à niveau et que les équipements baissent en tarifs. Car avec les nouvelles fréquences allouées à 700 MHz en France, avec une antenne tu peux couvrir plus de territoire car la fréquence est basse et les nouvelles infrastructures pourront profiter des installations pour couvrir en une fois toutes les bandes de fréquence ce qui est moins cher que de faire en plusieurs étapes comme aujourd'hui en ville. Vu la faible rentabilité de la campagne pour eux, c'est normal que cela traine un peu.
Pour les offres, cela commence à arriver et c'est dans le plan THD de la France que les endroits trop isolés bénéficient de l'accès par satellite ou radio pour l'abonnement fixe d'ici 2020-2022. D'ailleurs Orange propose avec sa nouvelle box la possibilité d'utiliser la 4G pour récupérer Internet en cas de panne de la liaison fibre ou ADSL. Et l'offre Free avec 50 Go/mois (pour 20€) en 4G peut servir de ligne fixe en utilisant le téléphone comme routeur Wifi si le besoin n'est pas important et la couverture bonne. J'ai des copains qui font ça d'ailleurs.
C'est un début, nul doute que cela sera plus courant plus tard quand la campagne pourra profiter de la 4G.
[^] # Re: Moi aussi
Posté par Renault (site web personnel) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 4.
Bah oui, faut bien que cela arrive un jour (2020 c'est dans longtemps quand même, tu auras le temps de t'y adapter et un téléphone 3G ça ne coûte rien).
Aux États-Unis ou Australie par exemple la 2G chez eux est déjà en train d'être coupée par les opérateurs et cela ne semble pas être un drame national.
Tu peux d'ailleurs voir les projets de coupure de service dans le monde.
Bref, il ne faut pas oublier que le spectre radio est très limité et que la 2G pour le moment occupe bien plus de bande passante que nécessaire (car le nombre d'usagers baisse constamment) en plus d'avoir des performances pourries et de nécessiter des puces spécifiques pour traiter ce signal analogique (le tout 4G permettrait sans doute un gros gain énergétique, de coûts et de performances car purement numérique).
Cela me paraît raisonnable de prévoir la coupure progressive du service dans le temps et l'espace en autoriser les opérateurs à exploiter ces fréquences pour la 3G et 4G dont le besoin est important pour assurer des débits corrects à tous les utilisateurs.
Mais cela peut être fait je pense intelligemment : prévoir plusieurs années en avance, et faire le transfert là où la 3G/4G est bien en place et dont le besoin est important (centre des grandes villes donc) avant de s'occuper à la campagne sur la fin quand le reste pourra prendre le relai.
[^] # Re: Moi aussi
Posté par Renault (site web personnel) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 3.
Si, car les opérateurs connaissent le modèle de téléphone utilisé par chaque puce et ils ont une table de l'ensemble des identifiants uniques de chaque téléphone également pour notamment empêcher l'usage des téléphones volés.
Bref, un GSM libre n'empêche nullement une coupure de la ligne par l'opérateur ou l'État, de même que ta connexion Internet filaire n'est pas à l'abri parce que ton routeur est libre.
[^] # Re: Moi aussi
Posté par Renault (site web personnel) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 8.
Car le matériel pour analyser le spectre radio n'est pas donné et que c'est vachement plus contraignant à travailler qu'une carte graphique où tu as accès notamment à l'écran (donc la destination de tes interventions). Sans accès au matériel télécom, il est difficile d'appréhender le système dans son ensemble pour éviter de commettre des fautes (qui peuvent être sanctionnées).
[^] # Re: Manque d'engouement, ou complexité ?
Posté par Renault (site web personnel) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 9.
Sauf un, ils respectent le test d'homologation.
Après si le test d'homologation ne représente pas la réalité du terrain, c'est autre chose et ils n'en sont pas coupables.
[^] # Re: Pas d'annonce de nouveaux portables non plus
Posté par Renault (site web personnel) . En réponse au journal Le malaise.. Évalué à 4.
On parlais du Macbook.
S'il est vrai que les constructeurs PC ont des marges ridicules et des ventes en recul, Apple tire l'essentiel de son revenu de l'iPhone et dans une moindre mesure de l'iPad.
Donc comparer l'argent disponible d'Apple avec des concurrents sur un secteur où Apple tire assez peu de revenus, c'est plutôt malhonnête.
De la même façon que tu ne compares pas les sous disponibles chez Microsoft et Sony sous prétexte qu'ils vendent des consoles, il y a la musique, le logiciels et d'autres matériels derrière à comparer où ils ne sont pas en concurrence.
[^] # Re: mouais
Posté par Renault (site web personnel) . En réponse au message [Offre d'emploi] Technicien informatique (pourvu). Évalué à 4.
Euh, si ton contrat de travail n'est pas respecté, il y a les prud'hommes.
Et c'est valide aussi pour un contrat de travail avec des clauses illégales.
Que veux-tu de plus ? Quand quelqu'un ne respecte pas la loi ou un contrat, c'est la case justice. C'est invariable. Je ne vois pas en quoi le télétravail est un problème différent du salaire là dessus…
[^] # Re: mouais
Posté par Renault (site web personnel) . En réponse au message [Offre d'emploi] Technicien informatique (pourvu). Évalué à 6.
Faut arrêter un peu.
Zenitram ne possède pas une SSII, dans ce genre de boîtes ne pas respecter ses promesses est très risqué pour les partenariats ou recrutements futurs.
Dans le monde du travail il est important de faire confiance, si tu veux que tout soit codifié à 100% c'est le meilleur moyen d'avoir des relations tendues et de ne rien obtenir de positif.
C'est le genre de choses qui se mettent normalement dans le contrat de travail. Du coup c'est très facile d'en faire une promesse contraignante.
De toute façon faut garder à l'esprit que c'est un CDD d'un an, une belle période d'essais pour tester l'entreprise et les promesses avant éventuellement de s'engager plus longuement.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
La seule source qu'il a utilisé contre mes arguments est erronée, donc bon.
Je ne parle pas de l'aspect technique des cgroups où je n'ai pas pris part à cette discussion.
C'est amusant.
En quoi c'est amusant ? Un gars va dire que l'avantage du Logiciel Libre, sa force, sa raison d'être c'est de fonctionner comme un bazar où chacun apporte ce qu'il veut, quand il veut, sa pierre à l'édifice, puis un autre va dire que non le gars plutôt que de faire ainsi il aurait du faire une RFC et y travailler pendant des années avant de proposer le projet final.
Quelle est la meilleure option ? Le bazar l'emporte je pense, déjà on ne peut pas forcer Lennart de faire un travail qu'il n'a pas forcément envie de faire.
De plus, il n'a forcé personne à utiliser son programme. Les gens l'ont pris telle qu'elle, c'est donc qu'il répondait au besoin ce qui ne l'incite pas à travailler sur la question de la portabilité. C'est à ceux qui veulent un systemd portable qui doivent y réfléchir.
N'oublions pas qu'à l'origine, le noyau Linux a été conçu pour être très proche de l'architecture i386. Pourtant aujourd'hui le noyau gère bien plus d'architectures matérielles, dont des architectures sans MMU…
systemd pourrait suivre cette voie. Pourquoi pas, personnellement je n'ai rien contre. Mais quelqu'un doit s'y atteler et prouver que c'est faisable sans tout foutre en l'air. En tout cas vouloir imposer cette tâche à Lennart est un non sens.
systemd n'est pas qu'un système d'init, faudrait arrêter un jour de se fixer là dessus.
Il est libre de faire ce qu'il veut pour son projet (ou son employeur peut décider de ce qu'il veut).
Si ce logiciels est si pourri, si techniquement horrible, pourquoi toutes les distributions y passent ? Pourquoi les gens se focalisent sur sa non portabilité sur les autres systèmes si ce programme ne les intéresse pas ?
Bref, râler là dessus n'a de sens que si on considère son utilité.
Est-ce important ?
L'avantage du libre, c'est que si le projet ne va pas dans le sens voulu par ses utilisateurs, on peut le forker. Si les gens n'ont pas confiance en Lennart ou veulent la portabilité absolument, le fork pourrait avoir lieu et détrôner la branche originale du projet.
Si le correctif pour la portabilité est simple et que Lennart refuse, il n'a pas de raison que le fork ne fonctionne pas.
Si tu as fait attention, mon message précédent était largement inspirée du style de mon ancien correspondant.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 6.
Pour moi les *BSD c'est au minimum les trois connus : FreeBSD, OpenBSD et NetBSD pour des raisons historiques, de représentativité et de domaine d'exploitation.
Que seul l'un des deux est une telle interface et qu'on ignore l'avancement des autres sur le sujet (est-ce prévu à terme ?) est selon moi problématique.
Bon, je vais te poser la question :
tu as vérifié ta source avant de balancer des conneries ?
Ton graphe, si on somme l'ensemble donne 135.3%. Il est manifestement faux (ou alors tu as un livre génial de statistique qui va expliquer ce graphe) sans compter qu'on a aucune idée de comment cela a été mesuré (l'image vient de Wikimedia, mais qui a mesuré et comment ?)
Bref, ton chiffre, c'est du pipeau.
Avant de poster, tu pourrais au moins avoir des sources correctes et les lire correctement…
Je suis sûr que les utilisateurs d'OpenBSD et de NetBSD seront ravis de voir que la portabilité ils n'y ont pas le droit.
Après si on part du principe que les *BSD ont des PdM négligeables devant Linux, on peut dire que la portabilité de systemd actuelle est suffisante, non ?
Où est la limite donc ? C'est tellement arbitraire que s'en est ridicule.
Possiblement, je ne suis pas expert en systemd et Lennart a présenté le refus par volonté d'être proche de Linux et qu'il n'a pas envie d'avoir un code trop bizarre pour gérer tout le monde. Si quelqu'un se ramène avec un code simple à gérer, je suis sûr qu'il l'acceptera. Du coup, qui est volontaire ?
J'ai cherché et je maintiens mon point de vue : deux systèmes *BSD majeurs manquent à l'appel. On est donc loin d'une solution simple aussi générique que présenté (et évident à faire).
Mais balaye devant ta porte avant d'engueuler les autres. Merci.
Je ne t'ai pas pourri, donc je ne mérite pas ce traitement.
Si tu veux, je peux te conseiller des livres sur le respect et les règles de communication. Après tout, tu as du chercher sur le sujet avant, non ?
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Ce serait bien si tu étais moins agressif…
J'ai parlé des *BSD or apparemment un seul s'est penché pour le moment sur la question. Du coup mon point de vue reste valide : il n'y a pas d'équivalent sur l'ensemble des UNIX libres (on parle de portabilité globale je crois, c'est donc important comme précision).
[^] # Re: Mirror ?
Posté par Renault (site web personnel) . En réponse au journal Sortie de Linux Mint bêta. Évalué à 7.
Je trouve l'approche de Fedora intéressante.
Les ISOs sont en HTTP mais les hashs sont hébergés sur le site officiel en HTTPS. Cela évite à gaspiller des ressources pour chiffrer une communication lourde et pas confidentielle.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
Tout dépend de la quantité de code en dehors du socle commun.
Si la quantité est faible et peu impactant (ne change pas l'architecture du programme) oui tu peux te permettre à gérer l'ensemble des différences.
Ici, ce n'est pas le cas. Typiquement les cgroups sont trop liés à Linux et trop au cœur de son architecture pour rendre cela élégant et simple sur d'autres systèmes.
L'architecture de systemd a été conçue pour coller au fonctionnement de Linux car c'était son but d'exploiter les possibilités du noyau que ne permet pas POSIX par exemple.
C'est loin d'être aussi trivial que tu ne le prétends, et c'est pour ça que Lennart encourage les forks du projet plutôt que de gérer la portabilité.
Non.
Si le code a des #ifdef de partout pour gérer Linux d'un côté, *BSD de l'autre, XXXX finalement, c'est difficile à maintenir et ça va créer beaucoup de bogues pour un gain discutable.
La portabilité peut rendre robuste un programme, oui, mais pas si ce programme a couplage fort avec un autre composant où l'effet est inverse.
Pas forcément, la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
Et là l'espace utilisateur n'aurait rien à secouer de la "fragmentation" de systemd en différentes versions suivant les système.
SysV, ce n'est pas que le shell, c'est tout ce qu'il y a derrière les scripts et c'est là le problème. La gestion des périphériques ? Pas standardisée. Les modules de sécurité (SELinux et autres) ? Non plus. Les cgroups ? Oublie. Etc.
Même entre les différentes distributions ce n'était pas possible d’homogénéiser les scripts proprement. Et c'était très complexe dans une même distribution d'être cohérent, certains typiquement géraient que partiellement l'existence de SELinux par exemple.
Donc homogénéiser avec d'autres systèmes qui ont des différences fondamentales sur ces questions, c'est chercher la merde pour la maintenance de ce code unique.
À t'écouter on dirait que tout l'espace utilisateur doit prendre en charge systemd d'un côté, SysV de l'autre, etc.
C'est faux… À part quelques programmes assez spécifiques, les applications et utilisateurs s'en cognent de systemd. Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié…
Vu que tu trouves le correctif nécessaire trivial, je t'invite à l'écrire, le maintenir et le soumettre. Lennart refuse car il sait que ce serait un gros travail. On attend ton code pour prouver le contraire.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
Objectivement, il a en partie raison quand même sur ce point. Sinon c'est ignorer les impacts d'un portage.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer. Cela impose des limites, typiquement systemd repose sur les cgroups que les *BSD n'ont pas (ou en équivalent clair). Porter systemd revient soit à virer tout ce qui exploite les cgroups, ou alors à faire du code sale / difficile à maintenir pour se comporter sous Linux et *BSD de manière différente. Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc. si les comportements doivent différer car les mécanismes sous-jacents sont différents.
Bref, la raison technique invoquée est loin d'être délirante et pour un projet comme systemd les risques de soit le vider de son sens, soit de le rendre vraiment horrible à maintenir sont grands. La question à se poser est : est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ? C'est discutable. À dire vrai, je pense que pour exploiter au mieux les possibilités de chaque système, il est plus intéressant que ce soit disjoint. Après tout, cela a été globalement le cas depuis toujours (SysV n'a jamais été sous *BSD, et même entre les différents Linux ce n'était pas la joie). Pourquoi nécessairement changer ?
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.
# Coupe-feu ?
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 4.
Pare-feu n'est pas techniquement plus juste ?
Le traducteur s'est un peu laissé aller. ;)
[^] # Re: Flatpak
Posté par Renault (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 3.
Ce n'est pas ça le pire.
Les distributions embarquent des versions différentes de chaque application et donc dépendance. Pour que le tout fonctionne de manière cohérente, il faut souvent gérer un certain nombres de correctifs sur les paquets.
Sans oublier que le découpage des paquets n'est pas identique d'une distribution à l'autre, tu peux par exemple découper KDE, Qt ou la glibc de bien des manières différentes pour aboutir au même résultat. Mais ces différences, qui existent en réalité, vont également casser ta résolution de dépendance.
Sans oublier parfois l'incompatibilité manifeste entre deux paquets de distributions différentes, si un paquet a besoin de Qt 4 et l'autre de Qt 5, tu peux avoir des soucis si la distribution cible n'a pas plusieurs exemplaires de la bibliothèque.
[^] # Re: Flatpak
Posté par Renault (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 7.
Le risque est que cela divise la communauté et les aspects techniques pour des questions de guerre de clochers.
Les autres distributions et environnements de bureau ont travaillé sur quelque chose dont il semble que Canonical n'a pas exprimé beaucoup d'idées ou de requêtes. C'est dommage de faire son truc dans son coin alors que depuis 2 ans une solution technique était en discussion et ouverte à tous. Si au moins un effort notable pour travailler sur ce projet public avait été tenté, ça aurait eu du sens.
D'autant qu'il y a enfin une vraie synergie à faire de Flatpak un succès.
[^] # Re: Le lien de téléchargement n'est pas vraiment un lien de téléchargement.
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie du livre blanc « Linux pour l'embarqué » édité par Smile. Évalué à 3.
Peut être liée au pays associé à l'IP pour éviter des numéros étrangers ?
[^] # Re: FUD
Posté par Renault (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 2.
Pour encaisser un chèque au Crédit Agricole, c'était remplir un papier à mettre dans une enveloppe avec le chèque et la mettre dans une boîte en libre service en agence mais pas au guichet. Donc pas de queues.
Faudrait être fou pour avoir besoin du conseiller pour ça. Oo
[^] # Re: Les licenses courtes
Posté par Renault (site web personnel) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 4.
Ce n'est pas hors sujet, un texte intitulé "Mémoires de x" a du sens de ne pas être modifié car cela représente la vie de la personne qui l''a écrite dont ses pensées. Cela ne me paraît pas délirant que ce genre d'ouvrages ne soient contrôlés que par l'auteur car il est concerné/impliqué bien autrement que pour les autres formes d'arts. Il ne saurait être question de modifier la pensée de la personne, ce qui pourrait avoir des conséquences d'ailleurs.
Cet argument ne s'applique pas à l'art (pour moi un mémoire n'est pas artistique, faut le voir plus comme un journal intime mieux rédigé) et dont aux romans qui sont des fictions. Ta contre-attaque est hors sujet car je suis d'accord avec toi sur l'art libre.
Pareil pour les licences et le droit : une licence c'est figée, permettre la libre modification peut poser des soucis : cela n'a pas de sens de modifier la loi librement comme ça (cela doit suivre un processus législatif), ni une licence car cela peut entretenir la confusion (la licence se réfère à la GPL, mais laquelle ? Éditée par qui et quand ?)
[^] # Re: Les licenses courtes
Posté par Renault (site web personnel) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 3.
RMS a justifié cela en disant que les textes légaux et de droits ne devaient pas être libres tout comme les mémoires par exemple.
Le but est d'éviter les effets de bords d'un tel cadre : attribuer des pensées que la personne n'a jamais eu, modifier la constitution ou le texte sur lequel la protection juridique se repose, etc.
[^] # Re: Déformer, amplifier, répéter
Posté par Renault (site web personnel) . En réponse au journal Le Rêve de Staline. Évalué à 5.
Outre le fait que tu n'as pas su interpréter correctement le tableau, car les données se recoupent entre elles, tu interprètes mal pas mal de chose…
D'après la page de Wikipédia sur le cancer :
En gros, plus d'un tiers des cancers sont largement imputable au mode de vie. Et on ne peut pas dire que l'État ne fait rien contre le tabac. L'alcool n'est pas assez combattu en France pour des raisons culturelles c'est vrai.
Et beaucoup de cancers sont eux dus soit à la génétique, soit à la vieillesse. La portion restante étant de causes inconnus ou très éparses. Difficile en tout cas de stopper les cancers autrement que ceux imputables au mode de vie.
Difficile d'avoir des chiffres sur la part du mode de vie dans ces maladies. Cependant il est évident que le mode de vie a une incidence forte sur leur apparition : manque de sport, tabagisme, diabète, alimentation inadapté, etc.
Ce qui reste, comme pour les cancers, sont difficilement évitables.
Hum, tu trouves que l'État ne lutte aps assez contre le tabac et les drogues ?
À part les diabétiques de type I, ce qui concerne moins d'un diabétique sur dix, ces morts là sont en effet évitables avec une meilleure hygiène de vie.
Il est vrai que l'État ne fait pas encore assez sur ce secteur, bien que ce soit en progrès.
Hum, tu veux que l'État fasse quoi contre les suicides en particulier ? Ou même les accidents de la vie qui arrivent.
L'État peut difficilement faire un meilleur bilan, le système de santé dans ces cas sont assez efficaces dans l'ensemble. Le problème est que certaines maladies ne sont pas soignables, et certains patients sont parfois trop fragiles aussi.
Bref, faire mieux est délicat, et ce qui est possible de faire est un immense chantier (faire encore mieux contre les maladies nosocomiales, l'hygiène dans la population…).
Tu oublies la lutte contre le tabagisme, les drogues, les campagnes de prévention ou de dépistages…
Je pense que le seul combat que l'État ne fait pas suffisamment c'est vis à vis de l'alcool, et éventuellement la malbouffe. Mais dire que seul la sécurité routière est visée c'est du grand n'importe quoi.
Sans oublier que rien n'empêche de lutter contre l'insécurité routière et les autres causes de mortalité. Ce n'est pas exclusif.
[^] # Re: ;-)
Posté par Renault (site web personnel) . En réponse au journal Le Rêve de Staline. Évalué à 0.
Les morts sur la route c'est aussi :
Bref, c'est quand même utile de lutter contre, d'autant que tous ces accidents sont évitables avec le respect du code de la route (alors que beaucoup de décès en France sont dus à des choix de vies du citoyen, ou à une fin de vie normale). Des décès évitables et avec effets collatéraux, les accidents de la route sont plutôt bien placés.
[^] # Re: .
Posté par Renault (site web personnel) . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 9. Dernière modification le 01 juin 2016 à 09:42.
La quasi-totalité des écoles privées, que ce soit post-bac ou primaire/collège/lycée bénéficient d'aides importantes de l'État voire d'entreprises dans le cadre de la taxe d'apprentissage.
Du coup le prix affiché est très loin du coût réel.
EDIT : si tu veux les bons tarifs, trouve une école privée hors contrat avec État et là ça rigole moins pour les frais de scolarité.