Pour les textes imprimés j'adore et vénère Hermann Zapf et la police Palatino qu'il a dessinée — que j'associe avec Euler pour les maths. Palatino est vraiment une très belle fonte, qui a beaucoup de caractère mais pourtant très formelle et agréable à lire.
Pour les textes de type roman j'aime bien les caractères Didot.
Pour le travail sur écran, j'utilise principalement les fontes DejaVu, en grosse taille — mon terminal est en DejaVu Sans Monospace 12pt, Emacs itou.
Il manque la très faible résolution des écrans! Les polices à empattements sont trop détaillées pour y être affichées correctement — sur mon MacBook cela se passe mieux mais je crois bien que la résolution est d'envrion 98 DPI alors que mon autre écran a 72 DPI.
Globalement, je suis d'accord avec toi. Les serif me plient les yeux sur mon écran et je ne les remarque plus sur du papier. Il faut croire que ce sont là deux supports très différents :)
Ton écran a entre 72 et 98 DPI tandis qu'une imprimante d'entrée de gamme te donne du 300DPI. Les écrans d'ordinateur ne sont pas adaptés à l'affichage d'images détaillées!
mais de trouver dictatorial de devoir respecter des normes typologiques.
C'est tout simplement parceque ces règles n'existent pas: on ne prépare pas de la même façon un article de journal, un roman, une nouvelle, une monographie, un article scientifique: notes, bibliographie, page de titre, position des illustrations, lettrines, alignement des paragraphes et retraits, etc., tout est différent!
Les seuls points qui font consensus sont les espacements autour des signes de ponctuation. Youpi.
Les gens qui ne peuvent pas apprendre LaTeX et qui font des thèses en droit par exemple,
En quoi les gens qui font droit ne sont pas capable d'apprendre LaTeX? En Allemagne (tout du moins en NRW) les étudiants et les profs ne se censurent pas et beaucoup de non scientifiques* apprennent LaTeX.
Je parle des gens qui ne font pas de bio, physique ou math, public traditionnel de LaTeX en France.
Ah oui mais là ça devient chaud. Faut qu'il crash 1 fois sur deux, 1 fois sur 3 ou 1 fois sur 10 pour que l'on puisse dire que l'éditeur est responsable ?
Oui ça devient chaud: il n'y a pas de critère aveugle pour répondre à cette question, il faut argumenter et faire une réclamation — je le suppose, d'habitude j'envoie direct les gorilles avec les barre-à-mines.
Pour moi la clause "absolument aucune garantie" est importante pour protéger l'éditeur.
C'est justement cette clause qui n'est pas légale en droit français, et que réputée non écrite, tu te retrouves dans un cadre juridique pas trop adapté à l'industrie logicielle — avec des responsabilités trop importantes. Je crois que ce genre de choses est expliqué dans la FAQ de CeCILL.
Oui! Même sans aller dans des exemples aussi extrêmes si ton logiciel de retouche photo crache une fois sur deux lorsque tu essaies de sauver ton travail, il y a certainement assez de matière pour un recours. Dans le cas d'un soft proprio classique que tu as acheté dans le commerce on peut imaginer un remboursement, dans le cas de la CeCILL l'auteur est censé te proposer un arrangement pour la correction du bug, éventuellement moyennant finances de ta part.
Je ne vois pas comment on pourrait garantir le bon fonctionnement d'un logiciel, c'est à dire l'absence absolue de bug. C'est bien ce qui est spécifié par le point 9.1 de la CeCILL
On peut garantir le bon fonctionnement du logiciel sans pour autant garantir un fonctionnement parfait! C'est une grosse nuance! Le bon fonctionnement signifie probablement que le logiciel permet de faire ce pour quoi il est fait «dans des conditions normales d'utilisation» et si on pense que ce n'est pas le cas on est bien en droit de déposer un recours et d'entrer dans une discussion plus détaillée.
C'est plus ou moins ce que dit le CLUF de Windows.
Ensuite le paragraphe des licences CeCILL que tu cites énumère des effets secondaires non souhaitables du logiciel et les classe comme dommage indirect c'est à dire qu'il dit «ce genre de choses peut arriver sans pour autant qu'on puisse en conclure que le logiciel ne fonctionne pas.»
De mémoire, la CeCILL traduit la responsabilité de l'éditeur dans le bon fonctionnement du logiciel en obligeant ce dernier à proposer un «deal» à ses licenciés pour réparer le bug — par exemple dans le cadre d'un contrat.
Parceque du fait que Bob utilise le logiciel publié par Alice il devient un client de Alice — à cause de la licence — et qu'Alice lui fournit un service: le droit d'utiliser le logiciel.
Je ne crois pas que la clause de non responsabilité soit illégale car on la retrouve dans d'autres licences, propriétaires.
Ce qui est légal c'est la non responsabilité pour les dommages causés à un tiers (par exemple), qui découleraient du non fonctionnement du logiciel. Mais en ce qui concerne le bon fonctionnement du logiciel, l'éditeur est responsable.
Si cette clause est illégale, alors de nombreux contrats de licence propriétaires (y compris ceux traduits en français) sont inadaptés aussi, non ?
C'est bien possible!
Je ne me souviens pas avoir vu un seul CLUF sans une telle clause.
Il y a le CLUF de Windows par exemple (au moins de Windows 8). Il y a une garantie limitée du bon fonctionnement du logiciel, la garantie couvre le non-fonctionnement du logiciel lui-même, pas les efets secondaires de ce non fonctionnement.
De mon point de vue, la GPL envoie un mauvais message social par rapport à la BSD: elle vous permet de partager du code, mais ce n'est plus sans contrainte,
Si tu diffuses des logiciels en France, tu deviens de facto éditeur de logiciel et prestataire de service: il y a quelques contraintes assez sérieuses liées à ce statut.
Des experts juridiques estiment que la GPL comme la BSD sont inadaptées au droit français, car la clause d'absence de responsabilité est illégale. C'est la raison d'être des licences de la famille CeCILL.
Le TeX que tu utilises (je suppose que tu n'utilises pas MIXAL) est certainement assez différent de celui qu'a écrit Knuth, surtout si il s'appelle PDFTeX!
C'est sympa d'avoir des nouvelles de ces vieux outils GNU. Honnêtement je ne pensais pas qu'ils recevaient encore des mises à jours.
Pour quelle raison est-ce qu'il n'y aurait pas de mises à jours sur un vieux logiciel? Je ne vois pas trop ce que vient faire l'âge là dedans. Un projet avec 0 utilisateur, 0 utilisation ou 0 bug n'a pas besoin de mise à jour mais tous les autres, si!
Par exemple si tu regardes les programmes de base dans /bin de FreeBSD (difficile de faire plus vieux et plus basique tout en étant toujours utilisé)
Tu verras que même les commandes cp, mv etc. sont encore aujourd'hui mises à jour! (La première version de BSD est de 1988 et la première version FreeBSD est de 1994.)
Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.
C'est vrai que GTK est insupportablement bavard… ceci dit, bien que ne connaissant pas Qt, je connais assez C++ pour suspecter QT d'être lui aussi très bavard — de façon peut-être supportable.
En ce qui concerne l'écriture d'applications évoluées, l'extension du toolkit n'est pas du tout la bonne méthode. Ce qu'il-faut-faire™, c'est écrire un nouveau toolkit décrivant l'interface de l'application avec des éléments de très haut niveau et puis implémenter le toolkit de haut niveau avec un toolkit de bas niveau comme Gtk. La raison de faire ainsi est qu'on s'assure de l'homogénéité de l'interface de l'application et qu'on maîtrise complètement la surface d'utilisation du «tiers code» ce qui est un atout pour la maintenance (mise à jour ou changement du toolkit de bas niveau). Donc du coup on se contrefiche complètement que Gtk soit écrit en C et pas en C++.
Oui c'est le principe de compiler soit-mêmes ses paquets. En contrepartie, ca permet une configuration plus fine de son OS. Certains utilisateurs en semblent assez satisfait.
Le gros avantage du système de ports vis à vis d'un système de packages classique à la RPM ou DEB c'est à mes yeux la simplicité du processus d'installation.
En effet le système repose essentiellement sur make — c'est à dire un outil avec lequel est familier tout programmeur¹ — et a une documentation potable (porter's handbook) qui fait que porter un logiciel à l'arrache prend 12 minutes — j'ai effectivement fait mon premier port en une poignée de minutes en suivant linéairement la doc.
J'ai fait des ports pour Debian et pour Macports, si ce dernier est également très agréable, je garde une impression très négative de Debian, essentiellement à cause de la documentation que je jugeais bavarde et peu claire (trop de détails et pas assez de perspective).
Cette simplicité est aussi très appréciable pour faire une mise à jour vite-fait, mal fait, si la nouvelle version tarde un peu à arriver dans les ports et qu'on en a besoin.
Je ne connais pas les systèmes de ports de NetBSD et OpenBSD, mais ils semblent plus évolués que ceux de FreeBSD: NetBSD intègre complètement le paradigme de cross-compilation, il me semble, et OpenBSD part du principe qu'un port est un procédé comme un autre pour créer un package — ce qui donne un statut clair à ces deux choses.
¹ Oui on peut programmer sans connaître make, mais c'est une sorte de Bildungslücke, plutôt un handicap qu'un atout.
Moi j'ai trouvé un peu plus de deux affirmations différentes dans cet articles. En plus de ce que tu rappelles, il y a:
FreeBSD était alors vendu sur le net, comme l’OS ultime. Le digne successeur d’Unix. Le système d’exploitation qui devait supplanter Linux, car supérieur à tous les égards.
C’est encore ainsi qu’est présenté cet OS aujourd’hui, et à lire en détail sur le site et forum de FreeBSD, c’est encore plus flagrant.
J’étais donc constamment obligé d’arrêter d’utiliser les logiciels vulnérables, sinon, je prenais le risque à utiliser une version dangereuse, de compromettre mon système.
Les navigateurs web comme Firefox, ou les éditeurs de texte comme Openoffice ou LateX, demandaient très souvent à être recompilé.
À moins d’être un étriqué, il n’y a aucun argument logique et sensé, pour défendre cette manière de procéder avec les ports. (sauf très rare cas)
Pour résumer, chez FreeBSD, c’est du pipeau!
Bref FreeBSD ça craint de tous les points de vue : la gestion des paquets craint, la gestion des priorités craint, leur philosophie craint. FreeBSD, est un système d’exploitation obsolète et dangereux.
Rien n'est argumenté autrement que par «je raconte ma vie et j'ai raison.» Bref, à l'iguane!
L'expérience relatée, reproductible par tout le monde dans le cas des ports est un fait, prouve largement le contraire.
Pour reproduire les résultats de ton expérience il faut abandonner toute rationnalité, refuser de lire le manuel du logiciel et renoncer à solliciter l'avis des experts sur freebsd-questions. Les résultats de ton expérience montrent plus les effets du protocole expérimental que la qualité de l'OS: c'est une mauvaise expérience.
Au cas où ça t'aurait échappé, des gens utilisent vraiment cet OS en milieu industriel — tu devrais essayer de savoir pourquoi. Microsoft développe une solution de virtualisation qui prend en charge FreeBSD. Mais le poids de ta voix est sûrement plus important, hein!
Tut tut tut, d'abord tu assumes tes responsabilités. Tu as cité la page Ozone de Wikipédia, comme on est tous très con, on a besoin que tu nous cites les passages de l'article qui traitent du dégagement de gazs toxiques nuisibles en lien avec les semi-conducteurs. Une chose à la fois.
Tu ne devrais pas trop faire de pub autour de ton blog, car tout ce qu'on y lit démontre que tu ne sais ni configurer ni administrer ton système et que tu as des visions très naïves des problèmes de sécurité. Tu pourrais un peu nous parler de ton expérience vis à vis des problèmes de «productivité» et de «securité»?
Tu as autre chose à mettre en avant comme différence entre FreeBSD et Linux qu'une pseudo analyse affective?
Tout tes textes crient «je suis un Jean Kévin!»
Si tu veux vraiment te faire une idée de la santé du système, tu peux commencer par visiter le site web de la FreeBSD foundation et en particulier zieuter la liste des sponsors.
[^] # Re: Une solution différente, mais comment ?
Posté par Michaël (site web personnel) . En réponse au journal Linux et les jeux vidéo : site web en projet. Évalué à 3.
Ne pas savoir où on va est effectivement le meilleur moyen de n'arriver nulle-part!
# Palatino
Posté par Michaël (site web personnel) . En réponse au journal Votre police préférée. Évalué à 2.
Pour les textes imprimés j'adore et vénère Hermann Zapf et la police Palatino qu'il a dessinée — que j'associe avec Euler pour les maths. Palatino est vraiment une très belle fonte, qui a beaucoup de caractère mais pourtant très formelle et agréable à lire.
Pour les textes de type roman j'aime bien les caractères Didot.
Pour le travail sur écran, j'utilise principalement les fontes DejaVu, en grosse taille — mon terminal est en DejaVu Sans Monospace 12pt, Emacs itou.
Sur écran j'aime bien aussi Monaco.
[^] # Re: Usage
Posté par Michaël (site web personnel) . En réponse au journal Votre police préférée. Évalué à 3.
Il manque la très faible résolution des écrans! Les polices à empattements sont trop détaillées pour y être affichées correctement — sur mon MacBook cela se passe mieux mais je crois bien que la résolution est d'envrion 98 DPI alors que mon autre écran a 72 DPI.
[^] # Re: Qui va à la chasse...
Posté par Michaël (site web personnel) . En réponse au journal Votre police préférée. Évalué à 6.
Ton écran a entre 72 et 98 DPI tandis qu'une imprimante d'entrée de gamme te donne du 300DPI. Les écrans d'ordinateur ne sont pas adaptés à l'affichage d'images détaillées!
[^] # Re: L'édition de documents, est une catastrophe.
Posté par Michaël (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 1.
C'est tout simplement parceque ces règles n'existent pas: on ne prépare pas de la même façon un article de journal, un roman, une nouvelle, une monographie, un article scientifique: notes, bibliographie, page de titre, position des illustrations, lettrines, alignement des paragraphes et retraits, etc., tout est différent!
Les seuls points qui font consensus sont les espacements autour des signes de ponctuation. Youpi.
[^] # Re: L'édition de documents, est une catastrophe.
Posté par Michaël (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 2.
En quoi les gens qui font droit ne sont pas capable d'apprendre LaTeX? En Allemagne (tout du moins en NRW) les étudiants et les profs ne se censurent pas et beaucoup de non scientifiques* apprennent LaTeX.
[^] # Re: Bienvenu en absurdie
Posté par Michaël (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 2.
We have the way in! :D
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
Oui ça devient chaud: il n'y a pas de critère aveugle pour répondre à cette question, il faut argumenter et faire une réclamation — je le suppose, d'habitude j'envoie direct les gorilles avec les barre-à-mines.
C'est justement cette clause qui n'est pas légale en droit français, et que réputée non écrite, tu te retrouves dans un cadre juridique pas trop adapté à l'industrie logicielle — avec des responsabilités trop importantes. Je crois que ce genre de choses est expliqué dans la FAQ de CeCILL.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
Oui! Même sans aller dans des exemples aussi extrêmes si ton logiciel de retouche photo crache une fois sur deux lorsque tu essaies de sauver ton travail, il y a certainement assez de matière pour un recours. Dans le cas d'un soft proprio classique que tu as acheté dans le commerce on peut imaginer un remboursement, dans le cas de la CeCILL l'auteur est censé te proposer un arrangement pour la correction du bug, éventuellement moyennant finances de ta part.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
On peut garantir le bon fonctionnement du logiciel sans pour autant garantir un fonctionnement parfait! C'est une grosse nuance! Le bon fonctionnement signifie probablement que le logiciel permet de faire ce pour quoi il est fait «dans des conditions normales d'utilisation» et si on pense que ce n'est pas le cas on est bien en droit de déposer un recours et d'entrer dans une discussion plus détaillée.
C'est plus ou moins ce que dit le CLUF de Windows.
Ensuite le paragraphe des licences CeCILL que tu cites énumère des effets secondaires non souhaitables du logiciel et les classe comme dommage indirect c'est à dire qu'il dit «ce genre de choses peut arriver sans pour autant qu'on puisse en conclure que le logiciel ne fonctionne pas.»
De mémoire, la CeCILL traduit la responsabilité de l'éditeur dans le bon fonctionnement du logiciel en obligeant ce dernier à proposer un «deal» à ses licenciés pour réparer le bug — par exemple dans le cadre d'un contrat.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 0.
Parceque du fait que Bob utilise le logiciel publié par Alice il devient un client de Alice — à cause de la licence — et qu'Alice lui fournit un service: le droit d'utiliser le logiciel.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
Ce qui est légal c'est la non responsabilité pour les dommages causés à un tiers (par exemple), qui découleraient du non fonctionnement du logiciel. Mais en ce qui concerne le bon fonctionnement du logiciel, l'éditeur est responsable.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
C'est bien possible!
Il y a le CLUF de Windows par exemple (au moins de Windows 8). Il y a une garantie limitée du bon fonctionnement du logiciel, la garantie couvre le non-fonctionnement du logiciel lui-même, pas les efets secondaires de ce non fonctionnement.
[^] # Re: Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 1.
Pourquoi?
# Contrainte
Posté par Michaël (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 5. Dernière modification le 26 août 2013 à 10:35.
Si tu diffuses des logiciels en France, tu deviens de facto éditeur de logiciel et prestataire de service: il y a quelques contraintes assez sérieuses liées à ce statut.
Des experts juridiques estiment que la GPL comme la BSD sont inadaptées au droit français, car la clause d'absence de responsabilité est illégale. C'est la raison d'être des licences de la famille CeCILL.
https://linuxfr.org/recherche?utf8=%E2%9C%93&q=cecill
[^] # Re: Qu'est-ce qui est nouveau ?
Posté par Michaël (site web personnel) . En réponse à la dépêche Sortie de Gnu Bison 3.0. Évalué à 1.
Le TeX que tu utilises (je suppose que tu n'utilises pas MIXAL) est certainement assez différent de celui qu'a écrit Knuth, surtout si il s'appelle PDFTeX!
[^] # Re: Qu'est-ce qui est nouveau ?
Posté par Michaël (site web personnel) . En réponse à la dépêche Sortie de Gnu Bison 3.0. Évalué à 7.
Pour quelle raison est-ce qu'il n'y aurait pas de mises à jours sur un vieux logiciel? Je ne vois pas trop ce que vient faire l'âge là dedans. Un projet avec 0 utilisateur, 0 utilisation ou 0 bug n'a pas besoin de mise à jour mais tous les autres, si!
Par exemple si tu regardes les programmes de base dans /bin de FreeBSD (difficile de faire plus vieux et plus basique tout en étant toujours utilisé)
http://svnweb.freebsd.org/base/stable/9/bin/
Tu verras que même les commandes cp, mv etc. sont encore aujourd'hui mises à jour! (La première version de BSD est de 1988 et la première version FreeBSD est de 1994.)
[^] # Re: Qt vs Gtk
Posté par Michaël (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 2.
C'est vrai que GTK est insupportablement bavard… ceci dit, bien que ne connaissant pas Qt, je connais assez C++ pour suspecter QT d'être lui aussi très bavard — de façon peut-être supportable.
En ce qui concerne l'écriture d'applications évoluées, l'extension du toolkit n'est pas du tout la bonne méthode. Ce qu'il-faut-faire™, c'est écrire un nouveau toolkit décrivant l'interface de l'application avec des éléments de très haut niveau et puis implémenter le toolkit de haut niveau avec un toolkit de bas niveau comme Gtk. La raison de faire ainsi est qu'on s'assure de l'homogénéité de l'interface de l'application et qu'on maîtrise complètement la surface d'utilisation du «tiers code» ce qui est un atout pour la maintenance (mise à jour ou changement du toolkit de bas niveau). Donc du coup on se contrefiche complètement que Gtk soit écrit en C et pas en C++.
[^] # Re: Conclusion un peu hâtive, non ?
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 4.
Le gros avantage du système de ports vis à vis d'un système de packages classique à la RPM ou DEB c'est à mes yeux la simplicité du processus d'installation.
En effet le système repose essentiellement sur make — c'est à dire un outil avec lequel est familier tout programmeur¹ — et a une documentation potable (porter's handbook) qui fait que porter un logiciel à l'arrache prend 12 minutes — j'ai effectivement fait mon premier port en une poignée de minutes en suivant linéairement la doc.
J'ai fait des ports pour Debian et pour Macports, si ce dernier est également très agréable, je garde une impression très négative de Debian, essentiellement à cause de la documentation que je jugeais bavarde et peu claire (trop de détails et pas assez de perspective).
Cette simplicité est aussi très appréciable pour faire une mise à jour vite-fait, mal fait, si la nouvelle version tarde un peu à arriver dans les ports et qu'on en a besoin.
Je ne connais pas les systèmes de ports de NetBSD et OpenBSD, mais ils semblent plus évolués que ceux de FreeBSD: NetBSD intègre complètement le paradigme de cross-compilation, il me semble, et OpenBSD part du principe qu'un port est un procédé comme un autre pour créer un package — ce qui donne un statut clair à ces deux choses.
¹ Oui on peut programmer sans connaître make, mais c'est une sorte de Bildungslücke, plutôt un handicap qu'un atout.
[^] # Re: Instructif
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 3.
Moi j'ai trouvé un peu plus de deux affirmations différentes dans cet articles. En plus de ce que tu rappelles, il y a:
Rien n'est argumenté autrement que par «je raconte ma vie et j'ai raison.» Bref, à l'iguane!
[^] # Re: Instructif
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 8.
Pour reproduire les résultats de ton expérience il faut abandonner toute rationnalité, refuser de lire le manuel du logiciel et renoncer à solliciter l'avis des experts sur freebsd-questions. Les résultats de ton expérience montrent plus les effets du protocole expérimental que la qualité de l'OS: c'est une mauvaise expérience.
Au cas où ça t'aurait échappé, des gens utilisent vraiment cet OS en milieu industriel — tu devrais essayer de savoir pourquoi. Microsoft développe une solution de virtualisation qui prend en charge FreeBSD. Mais le poids de ta voix est sûrement plus important, hein!
[^] # Re: Conclusion un peu hâtive, non ?
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 5.
Apparemment, tu es le seul ici à penser ça. Si tu veux voir à quoi ressemble une argumentation, essaie de lire un livre.
[^] # Re: Instructif
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 7. Dernière modification le 18 août 2013 à 11:38.
Tut tut tut, d'abord tu assumes tes responsabilités. Tu as cité la page Ozone de Wikipédia, comme on est tous très con, on a besoin que tu nous cites les passages de l'article qui traitent du dégagement de gazs toxiques nuisibles en lien avec les semi-conducteurs. Une chose à la fois.
[^] # Re: Notoriété
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 5.
Fais attention, l'intensité est telle que ça pourrait être contagieux. Restons prudents.
# Démonstration
Posté par Michaël (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 9.
Tu ne devrais pas trop faire de pub autour de ton blog, car tout ce qu'on y lit démontre que tu ne sais ni configurer ni administrer ton système et que tu as des visions très naïves des problèmes de sécurité. Tu pourrais un peu nous parler de ton expérience vis à vis des problèmes de «productivité» et de «securité»?
Tu as autre chose à mettre en avant comme différence entre FreeBSD et Linux qu'une pseudo analyse affective?
Tout tes textes crient «je suis un Jean Kévin!»
Si tu veux vraiment te faire une idée de la santé du système, tu peux commencer par visiter le site web de la FreeBSD foundation et en particulier zieuter la liste des sponsors.
http://www.freebsdfoundation.org/donate/sponsors
Tu peux aussi regarder la liste des projets Google Summer of Code, etc., lire les rapports de la FreeBSD foundation, etc.