🚲 Tanguy Ortolo a écrit 12293 commentaires

Sans cette limitation, ça existe, seulement ça ne s'appelle plus un vélo. C'est ce qu'on appelle couramment un vélomoteur, et légalement, ça entre dans la catégorie des cyclomoteurs. Rien d'interdit, ça doit simplement être immatriculé et il faut au moins le BSR pour conduire ça je crois.

C'est un peu logique en fait, un vélo, c'est à la base un truc sur lequel on pédale pour rouler. Y ajouter un moteur, ça n'a rien de nouveau, ce qui est nouveau c'est que le moteur en question soit électrique, ce qui ne change rien à part le bruit et la fumée en moins. Ce n'est plus un vélo, et comme ça existe depuis longtemps, c'est tout à fait prévu par le code de la route.

Sérieusement, rien de nouveau sous le soleil, depuis quoi, cinquante ans, plus peut-être, un truc avec des pédales et un moteur assez puissant mais pas trop quand même, ça existe, c'est utilisé et règlementé. Maintenant, on en fait avec des moteurs électrique, mais ça ne change rien de ce point de vue.

Après, si vous y mettez un moteur plus puissant encore (plus de 50 cm³ pour de la combustion, je ne sais pas combien de watts pour de l'électrique), vous passez dans la catégorie de ce qui s'appelle couramment un gros scooter ou une moto, et légalement une motocyclette, pour laquelle il faut un permis spécial.

À ma connaissance, Python 2 et Perl 5 ne sont pas caduques et sans aucune mise à jour depuis 7 ans.

Deux raisons. La première, qui est le plus importante : parce que personne ne s'est porté volontaire pour maintenir un paquet guile-1.8 pour les deux années à venir. Et la seconde, qui est sans doute la cause de la première : parce que c'est obsolète depuis longtemps et plus du tout maintenu en amont, ce qui signifie que tout le travail de maintenance, y compris l'adaptation, voire la rédaction des corrections de sécurité, incomberait au mainteneur de ce paquet.

Maintenant, si tu es prêt à te charger de l'empaquetage, et à faire en sorte de corriger d'une façon ou d'une autre les failles de Guile 1.8 alors que plus aucune version n'en a été publiée depuis décembre 2010, tu peux toujours te porter volontaire, mais j'ai peur qu'il ne soit un peu tard pour cela maintenant.

A cause de l’engagement pour un système le plus stable possible, on se retrouve avec des logiciels soit obsolètes, soit absents.

Ben non, ça n'a rien à voir, au contraire. À cause de la lenteur des développeurs de Lilypond pour passer à la version actuelle de Guile, ce logiciel ne peut plus figurer dans la testing qui est trop à jour pour permettre de l'utiliser avec sa dépendance obsolète.

Si tu veux utiliser Lilypond, ce n'est pas un système moins stable et plus récent qu'il te faut, au contraire, c'est un système plus antique de figé. Autrement dit, la Debian précédente.

Sinon, de l'essence, genre essence F (ou C, mais c'est plus volatil donc casse-pied, parce que ça s'évapore très vite du chiffon qu'on utilise).

Parler de Linux pour une distribution est un abus de langage. Linux n'est qu'un noyau. Les distributions que nous connaissons aujourd'hui sont issues du projet GNU

Non, pas toutes. Pas Android, qui constitue tout de même une plate-forme dont l'utilisation est loin d'être confidentielle.

. Le projet GNU n'est qu'un des multiples projets dont sont issus les composants de l'écosystème autour de ce noyau.

T'en as d'autres ?

Des projets dont sont issues des composants d'un écosystème autour du noyau Linux ? Oui, Android.

Opérateur têtards en français, si j'ai bien compris.

Mmh, dans les deux cas, on manipule et on mesure des champs immatériels, à savoir le champ électrique et le champ magnétique, créés par des phénomènes tout à fait matériels, à savoir l'accumulation d'électrons et l'orientation d'atomes…

Blocs

Diverses corrections au niveau de la gestion des blocs, cela va de l’ordonnanceur, à la gestion du bug de l'année 2038.
Pas mal de changements côté NVMe (qui permet une bien meilleure exploitation des disques solides que AHCI), […]

Des périphériques à l'état solide, des SSD quoi, qui ne sont justement pas des disques !

(Au passage, je n'ai jamais compris d'où sortait ce nom étrange de « périphérique à l'état solide », comme si les vénérables disques durs étaient à l'état liquide ou gazeux : personnellement, je préfère parler de périphérique de stockage flash.)

où est défini la longueur de la clé symétrique dans mon système,est ce paramètrable ?

C'est le paramètre de configuration Ciphers du client OpenSSH, cf ssh_config.

Oulà, ce n'est pas non plus « la documentation Debian », c'est une documentation sur Debian !

en lisant la doc sur ssh:

C'est gentil, mais ça, ce n'est pas la doc sur SSH, c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.

Si tu veux plus de détails, c'est la RFC qui définit le protocole SSH qu'il va falloir aller voir. Mais de mémoire, il me semble qu'une clef symétrique est simplement une chaîne d'octets aléatoires d'une certaine longueur. Donc, pour répondre à tes questions :

comment le client génère t il la clé symétrique

En prenant des octets dans /dev/random je pense.

a quel moment

Au début, vu que cette clef symétrique va être utilisée dans toute la suite, dans la mesure où elle est au cœur de l'initialisation d'un canal sécurisé, qui est l'objet de la connexion SSH.

et est ce toujours la même clé ?

D'une session sur l'autre, non, elle est générée pour chaque connexion SSH. En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.

impossibilité de révoquer : si si, tu peux révoquer (suffit de faire un mail au support frama et on suspend ton don récurrent par CB)

Non, je parle de révocation directe par le donateur. Mettre fin à un prélèvement en demandant au débiteur de l'arrêter, c'est super quand tout va bien, mais par nature, ce genre de méthode ne marche que quand tout va bien, or le but de ce genre de démarche est parfois de mettre fin à un problème, qu'il s'agisse d'un abuse volontaire, d'un bug ou d'un piratage.

Bref, on prend évidemment les virements permanents (j'en profite pour rappeler que certaines banques font payer les virements de banque à banque !).

Il me semble que c'est interdit par le règlement SEPA. Ou plutôt, qu'un virement SEPA peut être facturé, mais obligatoirement au même tarif qu'il soit ou non à destination d'une autre banque. Du coup, la seule façon licité de facturer les virement externes, c'est de facturer aussi les virements internes, et une banque qui en serait là ne garderait pas ses clients bien longtemps.

Le don récurrent par CB a plusieurs inconvénients :

• les frais ;
• l'expiration ;
• l'impossibilité de le révoquer sans gros effets de bords, la seul possibilité étant l'opposition sur la carte, autant que je sache.

L'adhérent qui n'a pas accès à Internet, je ne suis pas sûr qu'il soit très concerné par la possibilité de don ou de cotisation par virement. Pour eux, ce sera plutôt des chèques, non ?

À noter que, si SEPA prévoit plusieurs champs (objet sur quatre lignes, référence, et plus encore il me semble…) certaines banques permettent très peu de personnalisation, voire limitent artificiellement l'ensemble de caractères utilisable. Ainsi, avec la BNP, on ne peut remplir qu'un seul champ (a priori, l'objet je pense), sur une seule ligne limitée à quelque chose comme 60 caractères, sans possibilité d'utiliser le caractère « / ». Ça viole la règlementation SEPA, et quant un fournisseur demande d'utiliser une référence avec un / dedans, ce qui n'est pas si bizarre que ça quand on y pense, eh bien on ne peut pas, et on doit déclencher un traitement manuel en les contactant pour leur expliquer qu'on n'a pas pu à cause de la banque, et qu'il faut qu'ils cherchent le virement avec tel autre objet à la place.

Super, alors si c'est une fausse excuse pour que je refuse de donner mon identité bancaire à une association pour qu'elle prélève sur mon compte, c'est également une fausse excuse pour qu'elle refuse de me donner le sien pour que j'y verse mes dons.

Un IBAN est un identifiant qui n'est pas censé être sensible mais qui l'est quand même, les associations ont des raisons de ne pas le publier / le communiquer à des inconnus.

Merci pour cet argument, c'est pour ça qu'il n'est pas question que je l'écrive sur un papier pour le donner à un démarcheur d'association. :-)

Ah oui, l'April, je m'en souviens bien en effet.

Pourquoi les associations ayant des permanents ont des besoins récurrents d'argent ? (tiré de l'épisode 3)

À ce sujet, j'ai tout de même une interrogation. J'ai l'impression que le fait que les associations qui démarchent les gens dans la rue ne cherchent à obtenir des dons réguliers que depuis quelques années. Alors soit je me trompe, et elles procèdent ainsi depuis bien plus longtemps, soit il s'agit d'un phénomène nouveau, et dans ce cas, qu'est-ce qui a bien pu changer pour créer cette pratique ?

Enfin, deuxième interrogation : avez-vous déjà vu une association acceptant les dons réguliers par virement plutôt que par prélèvement ? Personnellement, il est hors de question que j'autorise une association à prélever librement sur mon compte, en fait je déteste fournir ainsi les clefs de mon compte à qui que ce soit, et je n'accepte de le faire que pour un nombre très limité de fournisseurs, qui se comptent sur les doigts d'une main. En effet, une telle autorisation est discrétionnaire, et permet au débiteur de prélever ce qu'il veut, quand il veut. On m'objecte régulièrement les deux réponses suivantes :

• une association sérieuse n'abusera pas d'une autorisation de prélèvement, et ne l'utilisera que pour prélever le montant prévu aux dates prévues ;
• je peux toujours contrôler ces prélèvements, et au besoin y faire opposition a posteriori, et révoquer cette autorisation.

Seulement, ce n'est pas suffisant. Une association sérieuse n'abusera effectivement pas volontairement d'une autorisation de prélèvement, mais des erreurs, des bugs, des piratages, des actes de malveillance, ça arrive, et ce n'est jamais voulu. Une autorisation de prélèvement est une porte ouverte à ce genre de problème, une porte que je préfère laisser fermer pour éliminer ce risque. Quand à la possibilité d'opposition et de révocation, c'est bien, mais ça nécessite de contrôler soigneusement son relevé de compte, et encore une fois, je préfère éliminer a priori tout risque plutôt que de le contrôler a posteriori.

Tout ça pour dire qu'il existe une alternative à l'autorisation de prélèvement, qui ne comporte aucun de ces inconvénients, et dont le résultat pratique est le même pour le débiteur : le virement permanent. Seulement, de toutes les associations qui m'ont démarchées pour obtenir un don régulier de ma part, aucune n'a accepté de me donner leur identité bancaire pour que j'établisse un virement permanent. Dommage pour elles, je veux bien leur donner de l'argent à ma façon, mais si elles n'en veulent pas…

Le SATA est toujours échangeable à chaud, pas besoin de matériel spécifique. En revanche, ce que tu peux avoir, c'est des paniers qui permettent de changer facilement les disques durs.

Ben non, pas vraiment. Dans les deux il y a une carte mère, un ou plusieurs processeurs, de la mémoire, des disques durs et des trucs branchés sur PCIe. Le gros serveur aura sans doute deux alims, plus puissantes, plus de processeurs, plus de mémoire, plus de disques durs, mais fondamentalement, c'est la même chose en plus gros.

Apparemment, il est très malsain de lancer un 'fsck.ext4' sur une partition dm-crypt.

Oulà oui ! C'est à dire, si tu as lancé le fsck sur le périphérique physique sous-jacent, c'est très malsain en effet, parce que ce qu'il contient n'est pas du tout de l'Ext4, mais du LUKS qui contient, chiffré, un volume Ext4. Essayer de l'interpréter comme de l'Ext4, ça va donner du grand n'importe quoi. Imagine une voiture contenant un vélo, et un type en train d'essayer de la réparer comme si c'était un vélo, sans voir que ce qu'il doit réparer, c'est le vélo qui est dedans : « Oulà, votre vélo a deux roues de trop, il faut les retirer ! », etc.

Du coup, mon mot de passe ne marche plus pour déchiffrer la partition. Quelqu'un sait-il si je peux espérer quelque chose de mieux que ne rien récupérer du tout ?

Non, là j'ai bien peut que ce soit bel et bien fichu, après qu'fsck ait longuement réparer un truc qui n'était pas de l'Ext4 de façon à ce que ça ressemble à un Ext4 bien propre, le résultat n'a sans doute plus grand chose de récupérable en tant que LUKS…

Quelqu'un sait-il pourquoi 'fsck.ext4' ne donne absolument aucune alerte pour empêcher les débiles de mon genre de faire ce que j'ai fait ?

Alors, j'ai une hypothèse à ce sujet. Un volume LUKS, ça a un en-tête qui commence au tout début, qui s'étend sur 592 octets, et qui est suivi de plusieurs emplacements de stockage de clefs de déchiffrement (qui sont chiffrées avec un mot de passe). Un système de fichiers Ext4, ça a un superbloc qui commence à l'octet 1024.

Du coup, je soupçonne ta partition d'avoir un jour contenu directement un système de fichiers Ext4, avec son superbloc à l'octet 1024, s'étendant sur une certaine longueur (les octets 0 à 1023 sont inutilisé par Ext4, pour laisser de la place à un éventuel chargeur de démarrage il me semble). Plus tard, tu as sans doute mis à la place un volume LUKS, avec son en-tête de l'octet 0 à l'octet 591, suivi par un emplacement contenant la clef de déchiffrement protégée par ton mot de passe, suivie par des emplacements réservés à d'autres clefs mais laissés vide dans ton utilisation. Le superbloc de ton ancien système de fichiers Ext4 est donc probablement resté intouché, dans la zone réservée pour ces éventuelles clefs supplémentaires.

Tu avais donc un une partition contenant un volume LUKS, identifiable à son en-tête à l'octet 0, mais également un ancien superbloc Ext4, éventuellement tronqué et sans données correctes pour sons système de fichiers, mais toujours reconnaissable. C'est à mon avis pour ça que fsck a bien détecté un système de fichiers Ext4 (sans cela, il se serait terminé immédiatement en t'indiquant que ce n'était pas de l'Ext4, ou que c'était abîmé au point d'être méconnaissable et irrécupérable) et a commencé à faire son boulot.

Pour éviter ce genre de truc, étant donné que les différentes utilisations d'un disque dur ou d'une partition (système de fichier FAT, Ext*, NTFS, volume physique LVM, volume RAID, volume LUKS…) placent leurs superblocs, leurs méta-données, bref leur point d'entrée et signature permettant de les reconnaître, à différents endroits, le plus sûr consiste, à chaque changement d'usage d'un périphérique, à le remplir de zéros. Ou au moins à remplir de zéros le début (disons quelques mébi-octets, pour être sûr) et la fin (parce que des tables de partitions GPT ont une copie de leurs méta-données à la fin ,et que certains volumes RAID ont l'intégralité de leurs méta-données à la fin !).

http://www.ivg.social-sante.gouv.fr/decryptage-des-idees-recues-sur-l-ivg.html

Est-ce que l’IVG peut rendre stérile ou causer des difficultés pour tomber enceinte par la suite ?
Une IVG ne rend pas stérile, une grossesse peut être envisagée dès le mois qui suit.

Y a-t-il des conséquences psychologiques après une IVG ?
Réponse du gynécologue Philippe Faucher :

"La majorité des études scientifiques sérieuses qui ont été publiées sur le sujet montrent qu’il n’y a pas de séquelle à long terme psychologique de l’avortement. Il n’y a pas de syndrome post-traumatique qui persisterait à distance, plusieurs années après un avortement.

Au moment de l’IVG, ce n’est pas un moment très agréable à passer.
Mais là c’est comme pour la douleur physique, il y a des femmes qui le vivent on va dire plutôt bien et puis il y a des femmes qui le vivent plutôt mal : donc qui sont tristes, qui pleurent. Et à ce moment là il ne faut pas hésiter à demander à des professionnels formés à l’accompagnement psychologique de vous aider."

Cela évoque une possible conséquence psychologique uniquement à court terme.