Renault a écrit 7187 commentaires

N'oublie pas que je suis entièrement d'accord qu'avec ce niveau de revenu, pour en arriver là, l'argent devait être mal géré. Mais c'est courant comme situation (que ce soit avec des riches ou des pauvres là encore), et j'ai envie de dire, on s'en fou non ? C'est son problème.

Je ne trouve pas que cela fait un couac gouvernemental ou de la majorité. Si on s'attend à des députés parfaits sur tous les points, on ne les aura effectivement jamais. Il y aura toujours une phrase ou une situation qui gênera quelqu'un.

Du coup les gens ici préfèrent critiquer la majorité sur ce genre de détails assez insignifiants plutôt que de s'attaquer aux vrais sujets : les lois qu'ils pondent et également les vrais problèmes concernant les personnalité (je mets une différence entre cette déclaration sans grande signification selon moi et un Cahuzac par exemple).

Mais non ce n'est pas délirant avec une telle baisse de revenue. Si la personne gère mal ses sous et n'a pas de marge, la moindre baisse et tu dois t'adapter rapidement. Elle parle d'arrêter des dépenses inutiles, de déménager et de manger des plats de base en conséquence de ce changement. Nul doute qu'une fois qu'elle paiera un loyer plus abordable à son nouveau revenu et que certains frais dispendieux se calment, elle mangera autre chose que des pâtes avec ses 5000€.

Sa phrase ne signifie pas qu'avec 5000€ tu as du mal à vivre et que tu ne peux pas manger autre chose que des pâtes. Juste que quand tu perds un gros tiers de ton salaire, ton rythme de vie doit changer rapidement.

Tout à fait, en vérité le prix du vol en tenant compte de cela et des mesures de sécurités nécessaires ne sont pas très élevés (c'est proche du prix d'un vol en première classe pour cette distance par tête).

Mais bon, des polémiques sur tout et n'importe quoi, ça arrive à chaque gouvernement, et aucun ne peut être parfait.

On enchaine par une député qui dit qu'avec 5000€ net par mois elle doit manger des pâtes et ressortir des fringues de la cave1, je rappel qu'elle a aussi a peu près le même montant Indemnité_représentative_de_frais_de_mandat

Bah quand on lit le lien en question, on voit qu'elle parle de cela car elle est passée de 8000€ à 5000€ net/mois. Si elle avait un train de vie très élevé, avec des crédits associés, en vivant dans un quartier cher, une telle chute de revenue même quand tu es aisé ce n'est pas indolore.

Après elle gère peut être mal son argent aussi hein, mais riche comme pauvre c'est souvent un soucis. Je ne trouve pas le propos délirant.

Pourquoi les langages simples n'utilisent pas l'implémentation de bc par défaut, quitte à activer l'IEEE quand on a besoin de perfos ?

Car par défaut la précision des flottants suffisent et que la dégradation en performance serait trop importante.

Tu oublies que les entiers sont aussi sensibles à des cas limites hein, dans ton esprit il faudrait aussi du coup utiliser des représentations natives au delà de 32 ou 64 bits. Tu te rends compte de la perte en perf par rapport au gain estimé ?

J'ai l'impression que tu n'as aucune idée de l'impact de l'usage de non-flottants en terme de consommation mémoire et nombre de cycles nécessaires pour ces opérations.

Autrement dit, par défaut, les neuneus se cognent une implémentation limitée mais ultra performante

C'est qui le noeudnoeud ? Pour moi celui qui utilise python n'en est pas un car il est formé un minimum pour s'en servir et doit savoir quoi faire si cela lui pose un soucis.

Dans le cas d'un logiciel destiné à un utilisateur final non informaticien de métier, oui l'implémentation devrait éviter cela nativement.

je pense que vu les perfos actuelles des CPUs, on peut changer, oui…

On parle quand même de plusieurs ordres de grandeurs plus lent, tu multiplies ça par la quasi-totalité des instructions de ta machine (car les entiers devraient logiquement être concernés). Bref, tu vas dégrader par un gros facteur X (probablement plus que 5-10) toute ta machine juste pour de la précision qui n'apporte rien ? Super !

A ce propos je ne sais pas s'il s'agit d'une légende urbaine mais j'ai maintes fois ouïe dire que les cadres sup' des GAFAM, faisaient très attention à placer leur rejeton dans des établissements à l'apprentissage traditionnel cahiers/crayon, bien loin du numérique.

Mouais, je suis presque sûr que c'est plus lié au fait que les cadre sup' de ces boîtes, surtout au Royaume-Uni et aux USA, essayent de placer leurs enfants dans les meilleures écoles possibles qui sont souvent de grandes institutions privées avec des méthodes traditionnelles. C'est rarement là bas que tu verras les expérimentations du numérique à tout va, et les résultats sont bons grâce à la sélection à l'entrée et à des profs très compétents et avec des moyens pour les avoir et entretenir l'infrastructure scolaire.

Quand bien même ce serait une volonté pour eux que leurs enfants évitent le numérique, cela ne rend pas la justification correcte.

Donc pour vous, du moment qu'on n'arrivera jamais à faire une précision illimitée, on accepte une erreur d'une soustraction à 1 chiffre après la virgule.

Tu te trompes, le résultat renvoyé par Python est précis à 10^-16 près (ce qui est pas mal), on est loin d'une imprécision de 10^-1 que tu sembles sous entendre.

D'autant que, si on veut être tatillon, comme l'a soulevé Zenitram, le calcul ici est au chiffre significatif 10^0, donc tout résultat dont la valeur entière est correcte est bonne. Même 0.9.

• en général on se fout de la perfo (là l'exemple a été donné en Python interactif quand même, c'est pas rien !)

Je pense qu'il est préférable que Python ait un comportement cohérent entre sa forme interactive et sa forme dans un fichier texte. Cela évite les surprises quand tu passes de l'un à l'autre, cela évite du code pour gérer cela et qui peut être source de bogues.

La question est plutôt : qui utilise sérieusement son langage de programmation pour un calcul précis élémentaire ? Personnellement j'ai une calculette matérielle et une logicielle pour cela. Un langage de programmation n'est pas fait pour cela.

Et non la performance on ne s'en fout pas, je pense que tu pleurerais si tout était en multi-précision. D'autant que tu oublies que ta logique voudrait qu'on transpose cela aux entiers car il est inadmissible que la quasi totalité des langages empêches l'usage d'entier supérieurs à 32 ou 64 bits sans syntaxe spécifique. Et étant donné l'importance des entiers dans tout logiciel et l'impact en performances que cela aurait, je pense que tu es content que les langages se conforment plutôt à ce que le processeur propose malgré les imprécisions. Car ces imprécisions sont suffisantes quasiment tout le temps. Aux autres de s'adapter un peu quand ils ont vraiment besoin d'une grande précision (sur entier ou flottant).

• on peut toujours, pour ceux qui cherchent la perfo (ce que je soutiens c'est que c'est une large minorité) rebasculer vers le bon vieux IEE-machin (option de compil, déclaration dans le script du langage interprété ou je ne sais quoi)

Non ce n'est pas une minorité. Les flottants et les entiers étant partout dans tes logiciels, je pense sincèrement que tu regretterais une dégradation significatif des performances pour un gain en précision assez négligeable.

Voilà, ça force le trait évidemment, mais c'est ça que j'observe : la justification de la représentation interne qui rend une erreur de calcul acceptable sous pretexte que ça va plus vite. Aujourd'hui, a-t-on encore besoin de ce "ça va plus vite" par défaut ?

Les calculs des réels ce n'est pas gratuit. Dans l'idéal si tu ne peux avoir que des entiers, c'est le mieux. Je pense que tu n'as pas la moindre idée de l'impact de tout passer en multi-précision (de même pour les entiers au delà de 32 ou 64 bits, car oui tu oublies que la plupart des langages ne permettent pas des entiers plus grand nativement).

Sinon ton histoire des 1000 vs 1024, c'est aberrant. Les flottants ne sont pas parfaits, mais la précision est quand même grande (assez pour être acceptable), là tu nous présentes une erreur de 2,5% sur des cas très courant, ce n'est pas la même chose !

Le même Python est passé par défaut en UTF8 en représentation interne. Il y a 10 ans, j'aurais dit "c'est quand même con de faire de l'ASCII par défaut, on a besoin couramment d'écrire autre chose que les 90 caractères de base", on me serait tombé dessus avec les même arguments (ça coute cher, c'est pas prévu pour etc. etc.) ?

Sauf que l'UTF-8, c'est utile à tout le monde par défaut. Car oui nos logiciels sont utilisés dans le monde entier, la contrainte linguistique est omniprésente aujourd'hui. L'ASCII n'est plus suffisant. On cherche encore en quoi le flottant est inadapté dans la majorité des cas (indice, ce n'est pas vrai).

Python est un bon exemple, c'est un langage de script

Il peut faire langage de script, c'est avant tout un langage de programmation. Il n'a pas été conçu pour remplacer ton shell.

D'ailleurs tu noteras que les langages de scripts sont rarement pratiques pour faire des calculs en soi, car ce n'est pas leur rôle. Le shell est particulièrement pénible dans cet exercice.

Non ? Vraiment pas ?

Ce que tu ne comprends pas c'est qu'on parle de quelque chose par défaut. Python, comme d'autres langages, offrent des solutions natives pour faire ce que tu veux mais avec une syntaxe adaptée. Ils ont fait ce choix par défaut, qui est justifié et selon moi raisonnable. Ce n'est pas un bogue ou une erreur fondamentale d'avoir fait un tel choix. Cela est compatible avec leurs objectifs.

Pour moi ta critique serait valable uniquement si Python se présente comme un langage de programmation destiné à découvrir la programmation (ce qui n'est pas le cas) ou si Python était une application destinée à des utilisateurs non formés (comme pourrait l'être ton tableur, ta calculatrice ou ton logiciel de comptabilité).

J'ai vraiment l'impression que tu fais semblant de ne pas comprendre.

Ta remarque est légitime pour quelque chose qui fait un calcul pour l'utilisateur. Car ce dit utilisateur n'a pas à se soucier des mécanismes de la machine, il n'a pas à savoir ce qu'est un flottant, le développeur n'a pas à présumer à sa place de la précision souhaitée.

Mais là tu parles d'un langage de programmation générique, qui ne met pas l'accent pour être utilisable par n'importe qui pour faire n'importe quoi. Pour des raisons de performances il utilise les flottants par défaut. Comme la quasi totalité des langages et processeurs à notre disposition utilisent les flottants, ce n'est pas quelque chose de surprenant. On peut dire aussi qu'un informaticien doit de toute façon connaître les bases des calculs de sa machine que ce soit les flottants mais aussi la représentation des entiers de base.

Tu n'as pas su démontrer le gain de passer au tout multi-précision par rapport aux flottants. Car en réalité, la réelle nécessité du multi-précision est rare la quasi totalité des applications en ayant besoin s’accommodent très bien des flottants ce qui permet des calculs rapides mais aussi peu gourmands en énergies car le processeur s'en occupe pour toi avec des circuits dédiés et pas très gros. C'est tout bénéfique.

Pourtant, on ne peut pas dire que la programmation n'évolue pas, typiquement l'UTF8 s'impose malgré ses contraintes par rapport à l'ASCII car le gain est évident. Et jusque là personne ne semble se soucier vraiment de la question des flottants car manifestement, il n'y a pas de besoin.

Si après tout c'est si révolutionnaire, pourquoi tu ne propose pas ton correctif à Python pour le faire par défaut ? Tout le monde te suivrait.

L'exemple de python comme calculatrice est présent dés le premier chapitre dans tout les tutoriels de débutants, le présentant comme une calculatrice puissante.

C'est juste pour tester la bête, pas pour en faire une véritable calculatrice. Nul part j'ai vu que Python était présenté comme une véritable calculatrice.

Car tu sais, dans la quasi-totalité des tutoriels, parmi les premiers TP tu as justement la fameuse calculette. Je ne connais aucun de ces langages qui gèrent nativement les nombres décimaux non flottants ou la gestion des overflow des entiers.

Bref, ce sont des exercices, des exemples, pas un usage normal du langage.

Python s'est d'ailleurs imposé comme le langage d'étude pour les débutants. Parfois dés le collège. Je ne sais pas où ils en sont dans les programmes mais il me semble que la gestion des entiers/virgule flottantes par les ordinateurs, les normes IEEE 754, l'architecture des ordinateurs et tutti aux 4eme/3eme ça arrive un peu après Pythagore.

Personnellement je ne suis pas favorable à l'apprentissage du code (du moins d'un langage réel) avant le supérieur voire le lycée. Je ne pense pas que cela soit le plus important pour appréhender le numérique (d'autant que la majorité d'entre eux ne coderont pas). Il y a des langages adaptés pour les enfants ou adolescents, car sinon tu dois aussi expliquer ce qu'est un overflow, la gestion des erreurs, etc. Tu peux aller très loin si tu souhaites éviter qu'ils aient des surprises.

Python est également utilisé par des non-informaticiens, beaucoup de chimistes/bio-chimistes, ou simplement des autodidactes (l’apprentissage est ouvert à tous faut pas être sectaire).

Personne n'est sectaire, mais il faut réaliser qu'un langage de programmation ça reste un outil puissant mais qui a besoin d'une certaine expérience ou formation pour l'utiliser convenablement.

Pour les scientifiques, je pense qu'un petit mot dans leur livre de formation indiquant que les nombres décimaux n'ont pas toujours une représentation exacte suffit et indiquer quoi faire s'ils veulent une précision infinie. C'est tout.

Tu sais, cela me fait penser aux sciences qu'on enseigne à l'école. À la base, une racine carrée d'un nombre négatif, on t'enseigne que tu ne peux pas le calculer. Puis peu à peu tu apprends que si, pas dans R évidemment mais que tu peux en tirer quelque chose avec les nombres complexes. C'est pareil en physique où il y a des tonnes de simplification pour les gamins (Newton universel) avant finalement d'étudier les cas limites et que les simplifications ne fonctionnent plus.

Je ne vois pas pourquoi en informatique il en serait autrement, c'est un outil, qui nécessite des compétences et beaucoup de formation. C'est bien de simplifier, de rendre le sujet plus accessible, mais ne pas oublier que nos processeurs ont de quoi calculer des flottants très vite pour peu d'énergie. C'est bon de l'exploiter. Tâche éventuellement à des langages plus orientés débutants (Python n'a pas ce but) de cacher ce genre de choses.

OK --> []

Tu n'as pas à sortir, c'est vrai. Les nombres significatifs sont importants. On ne peut pas créer ex-nihilo de la précision. Le résultat sera toujours lié à la précision de l'entrée la moins précise.

Parce qu'on a inventé les ordinateurs pour calculer à notre place, et que maintenant qu'on a les moyens techniques qu'il fassent une soustraction de fin de primaire, il serait temps qu'ils le fassent sans se tromper, ne serait-ce à une erreur de 10-17?

Pour quel coût ?
Bien sûr que nos machines en sont capables, mais si tu ralentis la plupart des applications pour un gain nul, l'intérêt est discutable. De la même façon que de nombreux calculs en entiers normaux sont sensibles à l'overflow et d'autres effets du style également et peu de langages offrent une protection native contre cela.

Mais dans la majorité des cas on s'en fout et le gain en performance est réel. Pour les quelques cas où la précision infinie (ou du moins très grande) est requise, le développeur a tout le loisir d'utiliser une bibliothèque (voire une extension du langage) pour que cela fonctionne.

Car oui, je te l'assure, une précision aussi grande est vraiment rarement nécessaire.

On voit des chats qui tombent des chaises en fullHD sur Youtube, mais on fait toujours pas une soustraction de nombre difficilement représentables en binaire.

Si, on sait faire, mais il faut utiliser les outils adaptés pour.
En tout cas il n'est pas déconnant qu'un langage de programmation use par défaut des nombres en virgule flottante. On s'adresse à des techniciens ou ingénieurs, pas à de simple utilisateurs qui eux en effet ne doivent pas voir ce genre de choses. C'est quand même différent.

L’ADN mitochondrial est soumis aux mêmes pressions de sélection que l’ADN classique. Et presque aux mêmes mécanismes de mutation. Qu’il soit dans la mitochondrie plutôt que dans le noyau ne change pas grand chose du point de vue de la sélection naturelle.

Sauf que la mitochondrie n'est pas apparu par le mécanisme de l'ADN. C'est ça que je voulais dire, de même que notre corps ne génère pas de lui même la flore intestinale. Cela provient d'autres choses qui font tout autant parti du processus évolutif.

La question n'était pas vraiment au sujet de l'évolution de la mitochondrie elle même mais de son apparition dans les cellules vivantes.

Bah, non.

Regarde les mitochondries qui ne sont pas dans notre corps grâce à notre ADN, les bactéries dans notre tube digestif, l'influence de notre environnement sur notre raisonnement ou l'expression des gènes. Tout ceci évolue et fait parti du processus évolutif individuel et global. Pourtant, ces éléments ne sont pas dû uniquement à l'ADN mais viennent bien de l’extérieure ou par d'autres mécanismes.

Suffit de constater, deux jumeaux, avec le même ADN de départ, produiront des individus distincts, avec leur raisonnement propre, et des différences visibles physiquement aussi.

En réalité 0.9999999 (avec des 9 à l'infini) et 1 sont la même valeur d'un point de vue mathématique. C'est juste deux manière de l'exprimer.

Donc 1/3 * 3 = 0.9999999 (avec des 9 à l'infini) c'est exact.

Juste avec un langage comprenant 4 symboles (ou 64, selon le point de vue).

Je pense que c'est plus compliqué que cela. L'ADN n'est pas la seule composante de nos organismes pour nous donner de l'intelligence. Et d'ailleurs, malgré le fait que tout les êtres vivants ont plus ou moins la même base en terme de codage et de chimie, seules quelques espèces ont une intelligence qu'une IA actuelle ne sait pas reproduire. Et encore le niveau est très variable parmi eux.

Il faut prendre nos organismes comme un ensemble, tu as la partie neuronale, l'ADN, les protéines, toute la chimie organique qui gravite autour avec ses différents composants. Et il n'est pas improbable qu'une partie du fonctionnement de notre cerveau (et donc de son fonctionnement au niveau cellulaire) nous échappe encore.

Après ça doit certainement être possible de reproduire tout cela un jour sans doute. Mais l'évolution est loin d'avoir pondu quelque chose de simple pour ce résultat.

Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche. Ce serait pas mal d'activer une bibliothèque en précision infinie par défaut.

Pourquoi ?
Je veux dire, c'est un langage de programmation, tout programmeur un minimum compétent doit savoir cette histoire de flottant, du moins dans le langage qu'il utilise.

D'autant que la précision des flottants est suffisante pour la quasi totalité des usages.

Sinon Excel il fait comment ? C'est pas une blague : lui ne fait pas cette erreur, donc elle n'a rien d'évident ni de systématique cette erreur.

Excel est un logiciel, utilisé par des non informaticiens. Ils n'ont pas à se soucier de cette histoire de flottants. Python est un langage de programmation, ses utilisateurs doivent savoir ça car de toute façon cela se retrouve quasiment partout.

Tu découvres simplement que les nombres décimaux non entiers ne sont pas représentables nativement par un ordinateur de manière exact. Pour des raisons d'optimisation, la quasi-totalité des langages de programmation (qui se basent sur le comportement du processeur) utilisent une représentation de ces nombres comme flottant qui n'ont pas une précision infinie.

Si tu veux faire des calculs avec une précision infinie, il y a beaucoup de bibliothèques (internes ou externes) pour le faire, mais le coût en calcul sera beaucoup plus important.

Je suis d'accord avec tout ce que tu dis. Ce n'est pas moi qu'il faut convaincre. ;-)

Tant mieux tes propos avant n'étaient pas clairs dessus. :)

Voilà. Ce sera ma dernière réponse sur ce sujet car y répondre aussi me prend trop de temps.

J'en ai conscience et je te remercie d'avoir éclairci cela. Je pense que ce serait bien pour toi et le projet que quelqu'un t'assiste sur la communication, pour le faire pour Fedora notamment, c'est très chronophage mais essentiel. Et quand je vois tes messages sur Zemarmot, GIMP, tes confs et tout, tu abats un gros boulot (et de qualité) même en dehors du graphisme et du code.

La vision que tu présentes du libre est un peu utopique à mon avis (et moi aussi je l'avais).

Je ne suis pas naïf ne t'en fais pas je suis d'accord avec toi. C'est juste que je voyais un lien évident entre la Fondation Blender et GIMP par rapport à ce projet (avec leur activité passée) et que de souvenir tu n'avais jamais évoqué le sujet. Après bien entendu, il n'y avait et il n'y aura aucune garantie que cela se concrétise un jour. Et qui ne tente rien, n'a rien.

Cela étant dit, je t'invite à leur parler de nous (sur les réseaux sociaux par exemple). :-)

Je ne suis pas un adepte de ces services mais sur mon blog cela pourrait arriver oui. Je suis d'accord que cela peut avoir un terme un impact positif. C'est un beau projet en tout cas. ;)

Bon courage pour la suite.

Je comprends ton point de vue, je n'ai jamais dit qu'ils seraient d'accord ou que cela se ferait automatiquement.

Je vais quand même expliciter mon avis, cela pourra peut être t'aider sur la manière d'aborder la question. Notamment quand tu voudras en rediscuter avec eux.

Déjà tu parles d'émerger de la masse des petits projets. Je comprends que Blender Foundation ne souhaite investir au mieux quand dans des projets avec un gage de sérieux et de crédibilité. Peut être que ZeMarmot n'est pas un projet assez mature artistiquement parlant pour eux. Je peux le comprendre. Mais quand même, tu es parmi les plus gros contributeurs à GIMP de ces dernières années, ce n'est pas rien. Je pense que cet aspect peut aider à crédibiliser ton projet. Je doute qu'ils ne soient pas sensibles à cet aspect.

De plus, oui la Blender Foundation va aider essentiellement des projets concernant Blender directement. Mais c'est une vision un peu court termiste et non globale de l'écosystème.

Par exemple, Red Hat, Canonical ou SUSE investissent des ressources financières et humaines sur des projets comme GNOME alors que ce qu'ils vendent c'est surtout du support pour des serveurs. Mais améliorer GNOME fait de la publicité, permet aussi d'avoir un environnement plus complet et cohérent car le poste de travail de l'administrateur système ou de la secrétaire auront aussi le même système d'exploitation.

Là où je veux en venir c'est que Blender est un outil non autosuffisant pour les graphistes. GIMP, Inkscape et d'autres outils sont indispensables pour une entreprise orientée dans le secteur. Améliorer GIMP peut aider à améliorer l’implantation de Blender. D'autant que je crois que les deux logiciels peuvent être scripté par Python, cela pourrait permettre à un développeur d'aider des graphistes des deux métiers par exemple pour ajouter ce dont ils ont besoin. Je ne connais pas les possibilités des concurrents proprio, mais je doute qu'une telle possibilité existe.

Bref, Blender pourrait tirer un bénéfice si GIMP et d'autres logiciels pour graphistes parvenaient à s'améliorer.

Au moins tu es clair et tu sais ce que tu veux c'est bien, chouette projet.

Mais j'ai une question à propos du financement. Tu veux que les gens financent le film pour aider à contribuer au logiciel. Je comprends la logique et c'est une bonne idée.

Mais je ne crois pas que tu aies répondu à la question suivante : en fait ta démarche c'est celle de la Blender Fondation. Ils ont pas mal de films à leur actif et Blender a évolué avec ces films. As-tu tenté (et veux-tu tenter) de collaborer avec eux dans cette démarche ? Ne pourraient-ils pas vous aider d'une façon ou d'une autre à défaut de faire un film ensemble ?

Cela pourrait être un moyen de mutualiser la logistique, le marketing et d'améliorer peut être votre financement.

Nouveau format LUKS2, que l'on peut (la plupart du temps) mettre à jour depuis LUKS1

C'est une procédure simple et sans perte ? Quelles sont les fameux cas gênants ?

Notez le jeu de mot dans le titre.

Non il n'est pas mort en tant que tel. Mais l'objectif pour cette version n'est pas atteinte.

Il faut bien comprendre que l'aspect modulaire, le découpage du système en différentes couches, etc. est un objectif de long terme, amorcé depuis Fedora 21. Seulement Fedora 27 devait être une grande étape (et de nombreuses choses ont été faites en ce sens d'ailleurs) mais il reste du chemin.

De ce que j'ai compris une partie du système va être revu, ce qui explique l'annulation pour ce cycle. Notamment l'objectif est d'avoir accès aux dépôts normaux et modulaires, ce qui n'était pas je crois prévu dans la conception précédente. Comme c'est un objectif complexe, d'ici sa réalisation finale il faut s'attendre à quelques essais / erreurs du genre avant d'aboutir.

Là c'est toi qui est psycho-rigide et arrogant.

Mouais, enfin tu nous dis qu'en voyage tu ne vas pas sur le site de ta banque car tu as peur de l'homme du milieu. Une banque si elle n'est pas protégée contre cela, quitte là.

Pour une grosse majorité de la population l'utilisation d'un vpn est soit un truc obscure, soit un truc dont ils n'ont jamais entendu parler. On leur a juste dit : INTERNET C'EST DANGEREUX C'EST PLEIN DE HACKER RUSSES À CAPUCHE QUI VEULENT TE PIRATER

Mouais, la grosse majorité des gens ne semblent pas avoir un problème immense à saisir des mots de passes en clair sur un réseau non protégé tu sais. Alors bon les histoire de VPN et de l'Internet dangereux, on repassera.

La réalité est que d'accéder à son compte bancaire depuis l'étranger sans VPN ne doit pas être un problème.

Concernant l'environnement Pro, FreeBSD ça existe, mais plutôt dans l'embarqué j'ai l'impression : FreeNAS, pfSense, et probablement d'autres appliances plus ou moins connues. C'est probablement du à l'aisance avec laquelle on peut construire un système minimaliste (NanoBSD) et ça marche plutôt bien.

Mouais non, dans l'embarqué les *BSD ne sont pas très populaires non plus, tout comme Minix. Linux, FreeRTOS, Vworks, etc. ont bien plus de poids.

Des Linux très minimaliste, il y a un savoir faire énorme. Des solutions permettant de générer ta distribution pour une flotte de machines, ça existe aussi (Yocto). FreeBSD n'a pas beaucoup d'avantages de son côté pour ce domaine.

Sinon je voulais finir mon journal en évoquant le cas entreprise, j'étais étonné d'en trouvé si peu (en fait j'en ai jamais vu en Entreprise …) Pourtant ça serait un OS parfait pour certains usage serveur non ?

Si ça te paraît si idéal, c'est quand que tu montes ta boîte pour faire du support professionnel autour de FreeBSD ? Si c'est si facile et efficace, tu devrais y arriver facilement.

J'veux dire remplacer des AIX par des RedHat pour faire tourner des batchs, c'est un peu de la blague quand même ?!

Sauf que RedHat apporte un support de 10 ans (voire plus), que ce soit pour maintenir les composants (donc sécurité) ou développé certaines fonctionnalités sur mesure. C'est ça que veulent des pro, des garanties, un interlocuteur sur qui taper quand ça foire.

Sans compter aussi que Red Hat a une politique de formation pour former ses intervenants en internes mais aussi les admins sys des clients. Je ne connais aucun acteur d'envergure qui propose cela pour FreeBSD.

C'est pourtant des critères essentiels pour une infrastructure d'un client.