Tu veux parler de pays qui casse des contrats de plusieurs milliards sur des prétextes fallacieux pour satisfaire leur autre ami? Si demain les USA devienne une dictature (leur dernier élu leur a quand même affirmé que les américains n'auraient plus besoin de voter https://www.theatlantic.com/politics/archive/2024/07/trump-vote-believers-summit/679273/ )
Toujours avec nos 'amis' d'outre atlantique qui n'ont jamais hésité a utiliser leur grandes oreilles pour favoriser leur entreprises à l'international, qui ne respectent pas leur accords passé (voir l'Iran) par exemple.
Enfin choisir comme exemple des pays ayant a minima vaste océan entre nous (et donc rendant difficile la sécurisation de la chaine), semble dénoter un certain angélisme.
Regarde le paysage mondial depuis 1924, il a sérieusement changé, et si on veut juste se limiter à 50ans, on est en dans les années 70, le monde à encore bien changé depuis.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je pourrais en rester là, mais je vais développer.
Je fais un truc dans mon coin, juste pour moi, puis j'en suis satisfait; avec une telle règle je suis incapable de montrer au monde mon génie. Je peux pas non plus publier sur un dépôt et espérer des contribution pour ajouter des fonctionnalité, corriger des bugs, ou même avoir d'autre testeurs. Je me retrouve prisonnier d'un système où la notion même d'aider bénévolement est alien.
De même, je veux utiliser une nouvelle version d'OS sur mon vieux téléphone, dont le fabriquant n'en a plus rien a foutre, et est même bien content que je soit obligé de passer à un nouveau modèle, plutôt que le mettre à jour via une solution libre.
L'essence même du logiciel libre est la liberté de modifier, exécuter, partager. Et là encore 1cents, c'est pas cher payé, mais on est plus en bénévolat.
Bref c'est une idée complètement conne, (selon mon point de vue).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Il n'y a que moi que ça énerve ces logiciels qui fonctionnaient sans OpenGL 4.x (mais avec moins d'effets, moins de textures, une résolution moindre, des capacités de traitement moindres) et qui du jour au lendemain ne se lancent plus car cette nouvelle exigence devient un pré-requis ?
Si c'est énervant, normalement la lib devrait gérer une rétrocompatibilité, c'est son rôle. La question est jusqu'à quand, et dois t'on conserver des bug car des gens se sont basés dessus ?
Avoir plusieurs implémentation d'un même fonction, ça se fait, ça peut se choisir au runtime, mais d'expérience, y'a que ce qui est utilisé couramment qui est testé, et lorsqu'on fait une évolution de la fonction (prise en compte de nouveau paramètres, correction), seule une implémentation est validée, le reste passe à la trappe.
C'est un investissement conséquent que de pouvoir tester plusieurs implémentation sur différentes archi; autant pour utiliser tel ou tel interface, on peut facilement faire des tests, pour des matériel différent c'est un poil plus compliqué.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je me cite : "c'est envisageable pour des lib spécifique, mais pas pour les programmes de tous les jours."
Oui pour les points critiques, on peut tenter de faire mieux que le compilo auquel on a précisé l'architecture, mais pour reprendre le sujet du journal lien c'est pas ça qui va faire qu'une appli mal codée va faire des miracles.
Pour la lib pointée, y'a différente implémentation selon l'archi, tu fais pas ça tous les jours.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Après, lire de l’AV1 sur une antiquité, c’est quand même un cas d’usage exotique.
Justement s'il répond au besoin, y'a pas de raison d'en changer. Par ailleurs tu le vieilli de pas mal d'années AMD_Phenom_II; pour être plus précis, fabriqué jusqu'en 2012, et il remplit très bien son rôle de boite multimédia.
Effectivement j'ai pas lu jusque là :D, pour ma défense, ce n'est pas le genre d'optimisation que je dois faire, c'est même le genre de truc à proscrire car trop dépendant du matériel, et si faut réécrire le bout d'assembleur lorsque on nous filera une autre machine, ça risque de poser problèmes. Pour la lib en questions ils sont obligés de regarder les capacité du proc, c'est envisageable pour des lib spécifique, mais pas pour les programme de tous les jours.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
ça c'est ce que tu fais uniquement lorsque le reste n'a pas permis d'atteindre les performances nécessaire.
Et ça implique de devoir différencier les binaires selon la plateforme (processeur), au risque d'avoir un crash franc de l'application; une solution est de vérifier les capacité du proc et choisir la bonne fonction, mais c'est rarement fait dans le cas des développement particuliers.
typiquement https://code.videolan.org/videolan/dav1d ne tournerai pas sur mon ancien proc qui ne gérait que l'AVX, et non l'AVX2. C'est dommage car il serait normalement amplement suffisant pour le décodage des vidéos.
Ou pour faire plus simple, dans le but de rendre le truc performant sur les anciennes plateforme, tu a fais un code qui ne tourne plus dessus :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console… avec des spécificité propres.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
alors normalement, une fois la connexion VPN établie tout passe par lui (les routes par défaut sont vers le VPN), pour les connexions déjà établies j'ai comme un doute, mais pour le reste toutes nouvelle connexion sont vers le VPN.
Ensuite si l'ordinateur est infecté, il peut très bien avoir une route passant en directe, mais on rentre dans des trucs plutôt évolué et bien compliqué. De mon point de vue le plus gros trou de sécurité est le recours à la prestation de service, avec des presta qui viennent sur site, et qui ont accès au réseau.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Alors là…. Je ne sais pas dans quelle boîte tu bosses, mais ça fait pas envie niveau sécurité.
Le PC lui même est sous Linux, avec antivirus qui fait ramer la machine; la machine est chiffrée à un certificat, et il faut en plus un token RSA pour entrer dans le VPN.
Par défaut on a accès qu'à un niveau faible sécurité (n'importe quel presta y a accès), pour aller au delà faut un 2eme token RSA (pour se connecter sur des VMs), avec un autre mot de passe. Pour utiliser une application interne faut être déclaré comme utilisateur de cette application… Bref c'est loin d'être idéal en terme de sécurité, mais c'est déjà mieux que dans pas mal d'endroit.
J'ajouterai que permettre de bosser lorsque le VPN est KO c'est plutôt pas mal; si tu passes en chômage technique parce que le réseau est KO
Ensuite la machine permet de se connecter à une base USB-C, un micro (USB) (car le micro du pc fait un bruit de ventilo), clavier… y'a sans doute moyen de sécuriser un peu plus le truc, mais à un moment faut laisser les gens bosser avec la sécurité et pas contre la sécurité.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
c'est par le réseau, donc tout aussi possible depuis le bureau.
Au bureau j'ai un proxy filtrant, chose que je n'ai pas à la maison, et le PC fournit par la boite permet de se connecter a internet hors VPN.
J'évite aussi d'utiliser le PC à la maison pour des trucs perso, mais j'ai un collègue qui y'a installé steam, et ça remplace son PC perso.
Je ne dis pas qu'il n'y a pas de solutions, juste que c'est un poil plus compliqué qu'une authentification à 2 facteurs si on prends le VPN comme solution.
Maintenant que j'y pense, il y a aussi la possibilité que quelqu'un subtilise le PC, le démonte, y ajoute un composant matériel malveillant, le remonte, puis le restitue au salarié sans qu'il en ait connaissance. J'ignore la probabilité de ce scénario.
Peu probable pour piquer des données personnelles; pour de l'espionnage, très probable, ensuite est-ce que Free pourrait en être la cible, aucune idée.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Le second facteur ne sert à rien si le PC de l'utilisateur est vérolé: le salarié ouvre lui même la porte.
Une solution plus gourmande en ressource consisterait à se connecter à des machines a distances qui elles ont 2 facteur, la machine distante étant toujours sous le contrôle de l'employeur, le salarié ne pourrait pas y faire n'importe quoi.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
L'insuline est normalement libre de droit, donc n'importe quel société ayant l'agrément devrait pouvoir la vendre à un tarif raisonnable aux USA; ce n'est pas le cas.
Sachant que c'est souvent la vie des gens qui est en jeu, on a du racket légal. La dessus les assureurs permettent de mitiger le problème (négociation directe pour les prix, qui fait qu'avec assurance c'est moins cher), mais on reste dans une logique de rentabilité, d'où les dérive pour ne pas rembourser.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
J'ai pas moinsé, mais par défaut j'ai pas été suivre le lien, je ne suis vraiment pas fan des vidéos, et encore moins chez le grand G.
C'est en lisant les autres commentaire sur un autre lien, que je me suis intéressé à la source (ie: le site d'origine, avec du texte). J'ai trouvé l'info intéressante.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
j'ai effectivement supposé que c'était le cas, et qu'il avait une ipv4 unique pour sa box, d'ailleurs si l'interface de bbox propose des redirections de ports, c'est probablement que c'est le cas
Pas forcément, il peut avoir toujours la plage A-B, ce qui permet une redirection à partir de ces ports là. Autre possibilité, l'opérateur ne s'est pas embêté a faire plusieurs versions de la box, enfin il a pu récupérer un logiciel qu'il a adapté a minima.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Mais à partir de ces chiffres on peut raisonnablement extrapoler sur le nombre de personnes incapables d'installer un logiciel et de le paramétrer aussi simple que cela puise te sembler à toi.
Beaucoup moins que le nombre d'ados ou d'enfants empêché de consultation par la mesure de contrôle d'âge; l'article que tu pointes à déjà 15 ans, et comme tu as pu le remarquer l'âge est un facteur important.
Mais aussi depuis 15 ans, les logiciels se sont nettement simplifiés.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Tu connais beaucoup de parent de 60 ans et plus; a supposer qu'ils aient eu leur môme a 45 ans, il a déjà 15 berge le môme. Faut donc ensuite descendre un peu, pour les 40-59 ans on est dans le 1,2% d’absence de capacité numérique; je ne parle pas d'accès ou non à internet, mais de l’absence de compétence.
Si on prends les 25-39 ans on est à 0,7%
On est très loin de "beaucoup", c'est un nombre qu'on peut facilement aider, pour peu qu'ils s'en donne la peine; et au vu du nombre croissant de démarche en ligne pour la scolarité, tu es en train de te focaliser sur une frange de la population qui est très réduite et qui a peu de chance de fournir un terminal à son môme.
Mais on en reviens toujours à qu'est ce que tu proposes qui soit un minimum efficace pour empêcher les jeunes d’accéder à du porno, je ne demande pas même pas 10% d'efficacité, même 0,1% serait déjà pas mal (indice le contrôle d'âge d'une dizaine de site ne fait aucune différence).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
C'est fou d'être à ce point déconnecté des réalités.
Faut arrêter de chercher des excuses, mettre l'accent sur le rôle des parents aura un effet supérieur, et de très loin, à forcer les sites a contrôler de manière efficace l'âge. La première mesure peut s'effectuer aujourd'hui, avec un effet immédiat, la seconde met du temps à se mettre en branle pour un effet imperceptible (donc inutile).
C'est compliqué ou incompréhensible pour beaucoup d'autres.
As tu déjà, ne serai-ce que testé avant de raconter des conneries? Le c'est trop compliqué, j'ai déjà prétendu pour ne pas effectuer une tâche, et si c'est trop compliqué de configurer le terminal perso du gamin, alors on en fourni pas. Et le PC familial est dans le salon, avec mot de passe non connu de la progéniture. Sinon, tu peux aussi le configurer avec ton môme, ça permet d'expliquer les règles du pourquoi.
Bref, même si pour des parents "c'est trop compliqué" (mais dans ce cas je plains leur gosses), la solution contrôle parental as un effet (global, mais y'a quelques trous dans la raquette), alors que la solution retenue, à part encombrer les tribunaux, à un effet nul (l'effet d'une cuillère pour vider un fleuve) voir négatifs (des parents pourraient penser que les sites ne sont pas visible et donc qu'il est inutile de configurer un filtre)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
C'est très mal comprendre le débat, il est aisé pour les parents de mettre un contrôle sur les terminaux (pc, et portable) il est impossible pour l'État d'avoir une solution un minium efficace sans mettre en place des mesure attentatoire aux libertés.
Ces solutions, en plus d'être inconstitutionnelle, sont également coûteuses.
Tu n'as pas fourni de solution efficace on t'a démontré que la solution retenue par le gouvernement est inutile, mais tu persiste a vouloir l'appliquer tout en fuyant le débat.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
qui donne un résultat complétement absurde si tu connais pas la mécanique interne. (et oui je sais qu'il faut utiliser a.equals(b) et non == sur des Integer)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Mais je n'ai pas vu tes propositions dans l'autre fil pour un système fiable et de confiance.
Mais parce que ce n'est pas possible. il n'y a aucune solution qui soit viable, je dis bien aucune, a part couper internet, ou réussir a faire appliquer ta loi locale, mondialement.
Par ailleurs tu retourne la charge de la faisabilité. C'est à la personne qui propose un tel système de contrôle de montrer que c'est possible, et, constitution Française oblige, être proportionnée au but recherché (ie mettre un flic derrière chaque écran n'est pas une solution proportionnée)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
mais il faut bien un moment qu'il y ait un acteur de confiance.
En fait non. Tu laisses les parents gérer l'accès internet de leur gamins. On est plus en 2000 avec des parents ignorant tout d'internet; toutes les solutions proposées sont contournables, et la plupart sont stigmatisante, et/ou intrusive sur la vie privée ou très facilement contournable; de l'avis même que tu as pointé.
Je suis même étonné qu'ils n'aient même pas noté que la caméra pouvait très bien ne pas pointer vers une vraie caméra, ni que tout le monde n'est pas doté d'un tel équipement.
Rajouter des intermédiaires c'est augmenter la surface d'attaque; comme en plus cet intermédiaire a des données personnelles, et dont certains ont honte, c'est une cible de choix pour pirate.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: cool
Posté par fearan . En réponse au journal Meta persiste à chercher du nucléaire pour ses datacenters IA.. Évalué à 5 (+2/-0).
Tu veux parler de pays qui casse des contrats de plusieurs milliards sur des prétextes fallacieux pour satisfaire leur autre ami? Si demain les USA devienne une dictature (leur dernier élu leur a quand même affirmé que les américains n'auraient plus besoin de voter https://www.theatlantic.com/politics/archive/2024/07/trump-vote-believers-summit/679273/ )
Toujours avec nos 'amis' d'outre atlantique qui n'ont jamais hésité a utiliser leur grandes oreilles pour favoriser leur entreprises à l'international, qui ne respectent pas leur accords passé (voir l'Iran) par exemple.
Enfin choisir comme exemple des pays ayant a minima vaste océan entre nous (et donc rendant difficile la sécurisation de la chaine), semble dénoter un certain angélisme.
Regarde le paysage mondial depuis 1924, il a sérieusement changé, et si on veut juste se limiter à 50ans, on est en dans les années 70, le monde à encore bien changé depuis.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Container
Posté par fearan . En réponse au message Livrer un environnement Python. Évalué à 3 (+0/-0).
Oui avec toutes ces belle technos on pourrait résumer a un vieux dicton, d'un grand philosophe :
Si vous avez un marteau, tout ressemble à un clou.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Non.
Posté par fearan . En réponse au journal Travail bénévole dans le monde du logiciel libre. Évalué à 10 (+15/-2).
Je pourrais en rester là, mais je vais développer.
Je fais un truc dans mon coin, juste pour moi, puis j'en suis satisfait; avec une telle règle je suis incapable de montrer au monde mon génie. Je peux pas non plus publier sur un dépôt et espérer des contribution pour ajouter des fonctionnalité, corriger des bugs, ou même avoir d'autre testeurs. Je me retrouve prisonnier d'un système où la notion même d'aider bénévolement est alien.
De même, je veux utiliser une nouvelle version d'OS sur mon vieux téléphone, dont le fabriquant n'en a plus rien a foutre, et est même bien content que je soit obligé de passer à un nouveau modèle, plutôt que le mettre à jour via une solution libre.
L'essence même du logiciel libre est la liberté de modifier, exécuter, partager. Et là encore 1cents, c'est pas cher payé, mais on est plus en bénévolat.
Bref c'est une idée complètement conne, (selon mon point de vue).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 3 (+0/-0).
Si c'est énervant, normalement la lib devrait gérer une rétrocompatibilité, c'est son rôle. La question est jusqu'à quand, et dois t'on conserver des bug car des gens se sont basés dessus ?
Avoir plusieurs implémentation d'un même fonction, ça se fait, ça peut se choisir au runtime, mais d'expérience, y'a que ce qui est utilisé couramment qui est testé, et lorsqu'on fait une évolution de la fonction (prise en compte de nouveau paramètres, correction), seule une implémentation est validée, le reste passe à la trappe.
C'est un investissement conséquent que de pouvoir tester plusieurs implémentation sur différentes archi; autant pour utiliser tel ou tel interface, on peut facilement faire des tests, pour des matériel différent c'est un poil plus compliqué.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 4 (+1/-0).
Je me cite : "c'est envisageable pour des lib spécifique, mais pas pour les programmes de tous les jours."
Oui pour les points critiques, on peut tenter de faire mieux que le compilo auquel on a précisé l'architecture, mais pour reprendre le sujet du
journallien c'est pas ça qui va faire qu'une appli mal codée va faire des miracles.Pour la lib pointée, y'a différente implémentation selon l'archi, tu fais pas ça tous les jours.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 4 (+1/-0).
Justement s'il répond au besoin, y'a pas de raison d'en changer. Par ailleurs tu le vieilli de pas mal d'années AMD_Phenom_II; pour être plus précis, fabriqué jusqu'en 2012, et il remplit très bien son rôle de boite multimédia.
AVX2 est arrivé dans les AMD mi 2015 avec Excavator_(microarchitecture) et ça doit dater de 2013 pour les intel.
Effectivement j'ai pas lu jusque là :D, pour ma défense, ce n'est pas le genre d'optimisation que je dois faire, c'est même le genre de truc à proscrire car trop dépendant du matériel, et si faut réécrire le bout d'assembleur lorsque on nous filera une autre machine, ça risque de poser problèmes. Pour la lib en questions ils sont obligés de regarder les capacité du proc, c'est envisageable pour des lib spécifique, mais pas pour les programme de tous les jours.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 5 (+2/-0).
ça c'est ce que tu fais uniquement lorsque le reste n'a pas permis d'atteindre les performances nécessaire.
Et ça implique de devoir différencier les binaires selon la plateforme (processeur), au risque d'avoir un crash franc de l'application; une solution est de vérifier les capacité du proc et choisir la bonne fonction, mais c'est rarement fait dans le cas des développement particuliers.
typiquement https://code.videolan.org/videolan/dav1d ne tournerai pas sur mon ancien proc qui ne gérait que l'AVX, et non l'AVX2. C'est dommage car il serait normalement amplement suffisant pour le décodage des vidéos.
Ou pour faire plus simple, dans le but de rendre le truc performant sur les anciennes plateforme, tu a fais un code qui ne tourne plus dessus :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 7 (+4/-0).
Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console… avec des spécificité propres.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tortue ? Symbole religieux ?
Posté par fearan . En réponse au lien Une gravure de tortue suggère une religion du Moyen-Orient datant d'il y a 37000 ans [HS Pratchett]. Évalué à 4 (+1/-0).
Chez moi ça marche ;)
Alors qu'en fait bouger suffit à faire venir la lumière :D
S'il a prétendu le faire, c'est logique de le dégager non ?
Rien a voir avec une quelconque croyance, c'est 'juste' des mot d'encouragement pour que la personne se sente moins seule, mais sans se mouiller.
Vu que l'histoire ne fait que bégayer, avec un peu de chance on peut tomber sur l'écho précédent
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Prétexte en bois
Posté par fearan . En réponse au lien Free met fin au télétravail « pour des raisons de cybersécurité ». Évalué à 3 (+0/-0).
alors normalement, une fois la connexion VPN établie tout passe par lui (les routes par défaut sont vers le VPN), pour les connexions déjà établies j'ai comme un doute, mais pour le reste toutes nouvelle connexion sont vers le VPN.
Ensuite si l'ordinateur est infecté, il peut très bien avoir une route passant en directe, mais on rentre dans des trucs plutôt évolué et bien compliqué. De mon point de vue le plus gros trou de sécurité est le recours à la prestation de service, avec des presta qui viennent sur site, et qui ont accès au réseau.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Prétexte en bois
Posté par fearan . En réponse au lien Free met fin au télétravail « pour des raisons de cybersécurité ». Évalué à 5 (+2/-0).
Le PC lui même est sous Linux, avec antivirus qui fait ramer la machine; la machine est chiffrée à un certificat, et il faut en plus un token RSA pour entrer dans le VPN.
Par défaut on a accès qu'à un niveau faible sécurité (n'importe quel presta y a accès), pour aller au delà faut un 2eme token RSA (pour se connecter sur des VMs), avec un autre mot de passe. Pour utiliser une application interne faut être déclaré comme utilisateur de cette application… Bref c'est loin d'être idéal en terme de sécurité, mais c'est déjà mieux que dans pas mal d'endroit.
J'ajouterai que permettre de bosser lorsque le VPN est KO c'est plutôt pas mal; si tu passes en chômage technique parce que le réseau est KO
Ensuite la machine permet de se connecter à une base USB-C, un micro (USB) (car le micro du pc fait un bruit de ventilo), clavier… y'a sans doute moyen de sécuriser un peu plus le truc, mais à un moment faut laisser les gens bosser avec la sécurité et pas contre la sécurité.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Prétexte en bois
Posté par fearan . En réponse au lien Free met fin au télétravail « pour des raisons de cybersécurité ». Évalué à 3 (+0/-0).
Au bureau j'ai un proxy filtrant, chose que je n'ai pas à la maison, et le PC fournit par la boite permet de se connecter a internet hors VPN.
J'évite aussi d'utiliser le PC à la maison pour des trucs perso, mais j'ai un collègue qui y'a installé steam, et ça remplace son PC perso.
Je ne dis pas qu'il n'y a pas de solutions, juste que c'est un poil plus compliqué qu'une authentification à 2 facteurs si on prends le VPN comme solution.
Peu probable pour piquer des données personnelles; pour de l'espionnage, très probable, ensuite est-ce que Free pourrait en être la cible, aucune idée.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Prétexte en bois
Posté par fearan . En réponse au lien Free met fin au télétravail « pour des raisons de cybersécurité ». Évalué à 8 (+5/-0).
Le second facteur ne sert à rien si le PC de l'utilisateur est vérolé: le salarié ouvre lui même la porte.
Une solution plus gourmande en ressource consisterait à se connecter à des machines a distances qui elles ont 2 facteur, la machine distante étant toujours sous le contrôle de l'employeur, le salarié ne pourrait pas y faire n'importe quoi.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Et s'il avait lancé un dé à la place ?
Posté par fearan . En réponse au lien Le patron des assurances UnitedHealthcare utilisait l'IA pour refuser des indemnisations. Évalué à 9 (+6/-0).
Non c'est la marchandisation de la santé. Y'a quelques temps un gars avait racheté un médicament pour lui donner un +5000% sur son prix. ( https://www.ouest-france.fr/sante/sida-il-augmente-de-5450-un-medicament-pour-faire-plus-de-benefices-3709702 )
L'insuline est normalement libre de droit, donc n'importe quel société ayant l'agrément devrait pouvoir la vendre à un tarif raisonnable aux USA; ce n'est pas le cas.
Sachant que c'est souvent la vie des gens qui est en jeu, on a du racket légal. La dessus les assureurs permettent de mitiger le problème (négociation directe pour les prix, qui fait qu'avec assurance c'est moins cher), mais on reste dans une logique de rentabilité, d'où les dérive pour ne pas rembourser.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Moinsage massif ?
Posté par fearan . En réponse au lien Victime d’une agression raciste, la police la met en garde à vue. Évalué à 4 (+1/-0).
J'ai pas moinsé, mais par défaut j'ai pas été suivre le lien, je ne suis vraiment pas fan des vidéos, et encore moins chez le grand G.
C'est en lisant les autres commentaire sur un autre lien, que je me suis intéressé à la source (ie: le site d'origine, avec du texte). J'ai trouvé l'info intéressante.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: questions bêtes
Posté par fearan . En réponse au message rustdesk bloqué par connexion bbox ?. Évalué à 5 (+2/-0).
j'ai effectivement supposé que c'était le cas, et qu'il avait une ipv4 unique pour sa box, d'ailleurs si l'interface de bbox propose des redirections de ports, c'est probablement que c'est le cas
Pas forcément, il peut avoir toujours la plage A-B, ce qui permet une redirection à partir de ces ports là. Autre possibilité, l'opérateur ne s'est pas embêté a faire plusieurs versions de la box, enfin il a pu récupérer un logiciel qu'il a adapté a minima.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 3 (+0/-0).
Je parle de logiciel, pas de système d'exploitation; dans ce domaine y'a que Emacs qui s'est simplifié.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# questions bêtes
Posté par fearan . En réponse au message rustdesk bloqué par connexion bbox ?. Évalué à 7 (+4/-0). Dernière modification le 03 décembre 2024 à 22:30.
Est-ce qu'il dispose de la totalité de l'adresse IP ou est elle partagée ?
Si c'est le cas, peut être faut il modifier la plage de port.
Autre possibilité, c'est qu'il est en NAT coté fournisseur, la pénurie d'IPV4 oblige les fournisseur a faire des trucs pas très net en IPV4.
Sinon en IPV6 est-ce que ça marche ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 3 (+0/-0).
Beaucoup moins que le nombre d'ados ou d'enfants empêché de consultation par la mesure de contrôle d'âge; l'article que tu pointes à déjà 15 ans, et comme tu as pu le remarquer l'âge est un facteur important.
Mais aussi depuis 15 ans, les logiciels se sont nettement simplifiés.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 3 (+0/-0).
Ou comment s'arrêter au titre…
Tu connais beaucoup de parent de 60 ans et plus; a supposer qu'ils aient eu leur môme a 45 ans, il a déjà 15 berge le môme. Faut donc ensuite descendre un peu, pour les 40-59 ans on est dans le 1,2% d’absence de capacité numérique; je ne parle pas d'accès ou non à internet, mais de l’absence de compétence.
Si on prends les 25-39 ans on est à 0,7%
On est très loin de "beaucoup", c'est un nombre qu'on peut facilement aider, pour peu qu'ils s'en donne la peine; et au vu du nombre croissant de démarche en ligne pour la scolarité, tu es en train de te focaliser sur une frange de la population qui est très réduite et qui a peu de chance de fournir un terminal à son môme.
Mais on en reviens toujours à qu'est ce que tu proposes qui soit un minimum efficace pour empêcher les jeunes d’accéder à du porno, je ne demande pas même pas 10% d'efficacité, même 0,1% serait déjà pas mal (indice le contrôle d'âge d'une dizaine de site ne fait aucune différence).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 5 (+2/-0).
Faut arrêter de chercher des excuses, mettre l'accent sur le rôle des parents aura un effet supérieur, et de très loin, à forcer les sites a contrôler de manière efficace l'âge. La première mesure peut s'effectuer aujourd'hui, avec un effet immédiat, la seconde met du temps à se mettre en branle pour un effet imperceptible (donc inutile).
As tu déjà, ne serai-ce que testé avant de raconter des conneries? Le c'est trop compliqué, j'ai déjà prétendu pour ne pas effectuer une tâche, et si c'est trop compliqué de configurer le terminal perso du gamin, alors on en fourni pas. Et le PC familial est dans le salon, avec mot de passe non connu de la progéniture. Sinon, tu peux aussi le configurer avec ton môme, ça permet d'expliquer les règles du pourquoi.
Bref, même si pour des parents "c'est trop compliqué" (mais dans ce cas je plains leur gosses), la solution contrôle parental as un effet (global, mais y'a quelques trous dans la raquette), alors que la solution retenue, à part encombrer les tribunaux, à un effet nul (l'effet d'une cuillère pour vider un fleuve) voir négatifs (des parents pourraient penser que les sites ne sont pas visible et donc qu'il est inutile de configurer un filtre)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 5 (+2/-0).
C'est très mal comprendre le débat, il est aisé pour les parents de mettre un contrôle sur les terminaux (pc, et portable) il est impossible pour l'État d'avoir une solution un minium efficace sans mettre en place des mesure attentatoire aux libertés.
Ces solutions, en plus d'être inconstitutionnelle, sont également coûteuses.
Tu n'as pas fourni de solution efficace on t'a démontré que la solution retenue par le gouvernement est inutile, mais tu persiste a vouloir l'appliquer tout en fuyant le débat.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je joue le jeu
Posté par fearan . En réponse au journal le défi du challenge : qu'affiche ce code. Évalué à 7 (+4/-0).
t'as la même en java
qui donne un résultat complétement absurde si tu connais pas la mécanique interne. (et oui je sais qu'il faut utiliser a.equals(b) et non == sur des Integer)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 4 (+1/-0). Dernière modification le 01 décembre 2024 à 19:36.
Mais parce que ce n'est pas possible. il n'y a aucune solution qui soit viable, je dis bien aucune, a part couper internet, ou réussir a faire appliquer ta loi locale, mondialement.
Par ailleurs tu retourne la charge de la faisabilité. C'est à la personne qui propose un tel système de contrôle de montrer que c'est possible, et, constitution Française oblige, être proportionnée au but recherché (ie mettre un flic derrière chaque écran n'est pas une solution proportionnée)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Preuve de mathurité ?
Posté par fearan . En réponse au lien Les moins de 16 ans bientôt interdits de réseaux sociaux en Australie. Évalué à 5 (+2/-0).
En fait non. Tu laisses les parents gérer l'accès internet de leur gamins. On est plus en 2000 avec des parents ignorant tout d'internet; toutes les solutions proposées sont contournables, et la plupart sont stigmatisante, et/ou intrusive sur la vie privée ou très facilement contournable; de l'avis même que tu as pointé.
Je suis même étonné qu'ils n'aient même pas noté que la caméra pouvait très bien ne pas pointer vers une vraie caméra, ni que tout le monde n'est pas doté d'un tel équipement.
Rajouter des intermédiaires c'est augmenter la surface d'attaque; comme en plus cet intermédiaire a des données personnelles, et dont certains ont honte, c'est une cible de choix pour pirate.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent