David Marec a écrit 472 commentaires

Par contre, ce journaliste est mesquin, clairement à charge.

Qui est mesquin ?

Celui qui prétend que ZFS-on-Linux n'est qu'un terme à la mode, que ses performances ne sont pas si terribles et que son développement est à l'abandon ?

il explicite deux choses:

Si vous parles de ZFS, vous parlez de la version d'Oracle;
Cette version étant proprio, vous savez peut-être si c'est actif, pas moi

Et vous avez gobé cette pirouette ?

Que dit le message auquel il répond ?

Recently, an important kernel fpu symbol was declared GPL-only, causing significant issue for ZoL project.

Il est clairement question de ZOL. Ni Oracle, ni Larry Ellison n'ont quoi que ce soit avoir avec ce projet.

ZOL est sous CDDL, qui est, apparemment il faut le rappeler, une licence libre.

Je vais pas tout relever, mais j'ai vraiment eu l'impression que le type est un sysadmin qui touche pas au code, se mange pas les emmerdes de compat' d'ABI vs améliorations,

Argument d'autorité ?

ou les problèmes légaux (qui sont clairement abordés par Torvalds)…

Ben non, c'est loin d'être «clairement abordé».

Oui, dans le mail de Mr. Torvalds, il donne son avis personnel. Oui, il est une icône.

Voire un gnuru.

L'article parle pourtant d'une raison technique (si on parle bien de la même chose) :

L'impact technique du refus de continuer à exporter le symbole kernel_fpu n'est pas d'empêcher les modules d'accéder directement au FPU -

Sauf que le wrapper autour symbole est exporté , mais en GPL-only.

La suppression de l'accès à ce symbole exige donc que les développeurs de modules réinventent individuellement leur propre code

C'est curieux de dire ça, parce qu'il suffirait que les développeurs passent leur module sous licence GPL pour accéder de nouveau à ce symbole․

ton raisonnement est qu'OpenZFS n'a pas pu être intégré au noyau Linux à cause de la licence GPL (et non pas une volonté de Sun d'inventer une nouvelle licence CDDL incompatible avec la GPL).

C'est le cas. ZoL existait en tant que module OOT comme tant d'autres. Comme sous FreeBSD.
Ni Sun, Ni Oracle n'ont quoi que ce soit avoir avec ça.

Et au passage, la CCDL est une licence libre. Elle n'a jamais déclaré être incompatible avec GPL, c'est la FSF qui le dit.
Au passage, la SFLC est moins catégorique.

If the kernel copyright holders prefer the literal meaning to the equity of the license,

B.cantrill, DTrace

neither of us believed that the Linux community themselves would hold up CDDL as an obstacle.And certainly if you told me that a decade later, DTrace wouldn't be in Linux because of licensing FUD, I wouldn't have believed you.

.

Les développeurs du noyau Linux font bien ce qu'ils veulent, c'est leur code après-
tout.

Oui. Qu'ils assument leur choix au lieu de nous jouer du grand guignol.
Le seul à le faire est Greg Kroah-Hartman.

Les autres agitent le nom d'Oracle comme un chiffon rouge.

Si on parle de l'origine de la controverse, alors on parle alors de la maintenance du noyau datant d'un an qui a eu un impact important sur le projet ZFS on Linux.

Oui. Le changement de licence d'une directive, en gros.

Si j'ai bien compris l'article, cette décision est de Kroah-Hartman (et non pas Linus et encore moins Stallman),

Je n'ai jamais dit « linus » mais « »Linux ». Quand à Stallman, ses recommandations ont été suivies à la lettre.Alors que je me souviens que Linus avait dit au début des années 2000, qu'il refuserait tout patch qui limiterait la licence sur un code (en GPL-Only précisément). Mais, ça , c'était avant.

et affecte tous les modules et n'a pour but d'empêcher un plantage dans le noyau, donc rien à
voir avec un refus de voir OpenZFS marcher dans le noyau. (Mais j'ai peut-être mal compris).

Il n'y a rien de technique. C'est purement un changement de licence, les modules, même out-of-tree, qui l'utilisent devront désormais être eux-même sous licence GPL.
Et ZoL utilisait cette directive.

car Linux était justement le centre du monde des systèmes UNIX en 2005

Sérieusement ?

que Sun voulait garder ZFS sur OpenSolaris

Et ZFS fut rapidement intégré à FreeBSD.

Donc si je comprends bien le noyau Linux devrait changer de licence rien que pour intégrer ZFS ? LOL

Il suffisait de garder l'export tel qu'il était, aucun changement de licence requis, LOL.

Totalement faux

Vous avez mal lu l'origine de la controverse.

pour rappel le noyau Linux a été diffusé en GPL en 1991.

Pour rappel, depuis quand la macro EXPORT_SYMBOL_GPL vampirise EXPORT_SYMBOL ?

Notamment quand __kernel_fpu_begin et __kernel_fpu_end de fpu/core.c sont-elles passées de EXPORT_SYMBOL à EXPORT_SYMBOL_GPL ? Janvier 2019.
- en fait, l'export de base a été supprimé et remplacé par kernel_fpu_xx -

C'est cette modification qui pénalise une optimisation du module ZoL (une vectorisation SIMD, si je me souviens bien, ils ont du trouver une solution depuis).

Donc si Sun avait voulu en 2005 que ZFS

Sun développait pour Solaris/SunOS, Sun n'avait pas à "vouloir" intégrer le noyau Linux. Linux n'est pas le centre du monde.

C'est donc un choix délibéré de Sun

La GPL et surtout le passage d'une directive en GPL-only est un choix de Linux.

Greg Kroah-Hartman:

My tolerance for ZFS is pretty non-existant.

.

Pour rappel Stallman n'a rien à voir avec le développement du noyau Linux.

« C'est bien de commenter un lien, enfin il faut aussi lire l'article pointé par le lien » ;-)

Interpreting, enforcing and changing the GNU GPL, as applied to combining Linux and ZFS.
by Richard Stallman

C'est bien de commenter un lien, enfin il faut aussi lire l'article pointé par le lien ;-)
Jim Salter écrit dans son article

Autant une bonne partie de son article est étayé, sur ce coup là, c'est "croyez moi sur parole, je connais des gars qui …".

La suite de ce même paragraphe qui conteste la pertinence des propos de Linus sur le sujet, s'appuie sur … Z-o-L et OpenZFS.

Je veux bien croire qu'il y ait une équipe "active" autour ce produit, mais il faut bien avouer que la faible communication d'Oracle sur le sujet entretient le doute.

Donc OpenZFS est un fork d'OracleZFS, chacun des deux projets évolue donc séparément depuis dix ans.

Il y a alors trois projets, avec ZFS on linux.

Le ZFS d'Oracle est complètement abandonné à ma connaissance.
En ce qui concerne les deux forks, il y a eu pas mal de manœuvres l'année dernière pour les rapprocher.

Chez IxSystem, ils ont même créé un module Z-o-L pour FreeBSD.

Quel rapport ?
Ces sources ont déjà été données dans un lien précédent.

Il s'agit ici d'un article qui répond aux critiques de L. Torvalds.

Si Sun ou Oracle avaient voulu que ZFS soit incorporés au noyau Linux,

Ce n'est pas à Sun ou Oracle de « vouloir ». Ici, c'est clairement Linus (et Stallman) qui ne « veut pas ».

Et ce, après avoir affirmé «  It was always more of a buzzword than anything else ».

rien que pour intel , nous avons 9 générations d'intel "core" et les intel "non core",

… Sans compter que Intel a eu la bonne idée d'appeler une de ses micro-architectures core,

• qui correspond généralement dans les paramètre de tuning pour compilateurs à core2.

Ce n'est pas un robot, mais un ensemble de bibliothèques et d'outils pour monter une architecture de modules (tâches) qui communiquent entre eux via des messages (synchrones ou pas), sur un OS linux.

Du moins c'est à ça que ça ressemblait la dernière fois que je l'ai eu entre les mains.

La force de cet ensemble est plus dans les fonctions spécialisées qu'il fournit.
Comme la relocalisation de différentes sources de geo3D (camera, laser trackers, nuage de points) dans un même référentiel, ou la possibilité de rejouer les sorties d'un module en entrée d'un autre.

A noter que ce travail a été financé par la fondation NetBSD et poussé sur une branche officielle le 25 novembre.

---

Si vous ne savez pas encore à qui donner des étrennes, pensez-y.

C’est un article de vulgarisation,

Je ne vois pas trop où se trouve la vulgarisation ici.

bien sûr qu’il prend des raccourcis
ça ne veut pas dire qu’il est faux

Et donc, c'est qu'il dit vrai ?

D’ailleurs, cet article est cité par plusieurs personnes assez connu dans le monde de la cryptographie […] Filippo Valsorda

'connais pas.

Dans le même genre tu as On Linux's Random Number Generation de Thomas Pornin,

Justement, cet article contredit en plusieurs point le précédent.

qui en plus d’être « moins technique »,

Au contraire, il est technique.

est beaucoup plus critique vis à vis du fonctionnement dans Linux

Évidemment, c'est un dev OpenBSD. C'est même l'auteur de crypto/aes si je ne me trompe pas.

D'ailleurs vous retrouverez ce point de vue dans les commentaires et les ml linux sur le sujet:

«Later on, a system call was added, to get randomness without having to open a file and use a file descriptor;
it is named getrandom(). That system call finally implements the proper behavior,
i.e. blocking until a sufficient amount of initial entropy has been gathered since last boot, but never blocking afterwards.
Incidentally, this is what /dev/urandom does on sane systems (e.g. FreeBSD or macOS). Applications should simply use getrandom(), and be happy.»

A mettre en lien avec ce commentaire du mainteneur de LRNG:

«removing that pool would effectively get rid of the idea that Linux has a true random-number generator (TRNG), which "is not insane; this is what the *BSD's have always done"»

Cet article est à prendre avec des pincettes, il prend pas mal de raccourcis et il me semble contredire les propos du mainteneur de LRNG.

L'auteur de ce site a oublié certains problèmes autour de /dev/urandom.
Il a fallu y ajouter un spinlock, parce que lorsque plusieurs processus interrogeaient ce device, ils pouvaient recevoir un jeu de de données similaire.Puis, pour éviter les embouteillages, on a créé autant de réserves derrière urandom qu'il y a de noeuds NUMA … quand il y en a.

Enfin, il suffit de lire les discussions lors de la sortie de la 5.3 en octobre dernier pour voir que cette situation est assez complexe.
Depuis l'introduction du syscall getrandom() dans 3.17, puis des implémentations de getentropy() et getrandom() dans la glibc 2.25, il y a eu pas mal de chemin parcouru.

Ceci dit, linux semble se rapprocher des implémentations BSD (notamment Open), qui n'ont jamais bloqué. (urandom est un lien vers random sous freeBSD ).

$ seq 2008 2019

Les étiquettes les plus fréquentes seront les [], le noyau, []

Bof, on a vu passer trois versions de noyau linux cette année sans la moindre dépêche …

C'est vrai que le hardware ainsi que le bas niveau c'est complexe et compliqué

C'est sans doute un «autre monde» et surtout un gros bordel.
Entre tous les ISA, procs, SOCs, bus en tous genre, fonctionnalités en pagailles sur un bus …

ça demande de l'investissement

Oui.

Si tu veux vraiment y aller, risque-toi sur RISC-V.
Lorsque l'on vient du x86, on peut trouver ça rafraichissant.

Marre de lancer des éditeurs txt qui te bouffent 256Mo de RAM pour lire un fichier de 4ko.

Ouaip ! D'ailleurs, j'ai un paquet pré-compilé vscode pour FreeBSD, en magasin.
Le build a pris 4 heures sur mon petit Xeon 8 cœurs.

Ouais, j’en ai aussi marre de vim qui bouffe 1MB de RAM sans même ouvrir un fichier.

8MB sur mon FreeBSD.
( vscode: 1.3 GB)

Ah, non en fait je m’en fous, j’ai 16GB de RAM.

Ben oui, si on a acheté de la RAM, ce serait gâcher que de ne pas l'utiliser !

Apparemment, il n'existe pas encore de paquetages pré-compilé, peut-être parce que ce port requiert un réglage particulier pour poudriere:

david@poudriere:~ % tail -1 /usr/local/etc/poudriere.conf
MAX_FILES_vscode=4096

Il est disponible ici; attention, adresse IPV6.

david:~>grep url /usr/local/etc/pkg/repos/llanura.conf
#    url: "http://llanura.local/packages/release11-HEAD/",
    url: "http://poudriere.lapinbilly.eu/packages/stable12-default/",

Il se lance ensuite par code-oss. A découvrir.

C'est une version recompilée depuis les sources ? Ou bien la version non libre de Microsoft ?

Il est disponible en tant que port. C'est à dire qu'il est intégré dans l'arbre sous forme de Makefile dédié.
Dans ce cas précis, il s'agit de sources à télécharger et à compiler.

C'est très long, surtout electron6.
Il n'est pas encore disponible en tant que paquetage pré-compilé, c'est pourquoi je suis en train de le construire dans ma propre poudrière.

Je suppose qu'il s'agit de cette SA.
- C'est en lien avec les trous dans SGX. -

Par contre, ça me semble très compliqué à exploiter, voire quasiment impossible depuis l'extérieur, sans s'appuyer sur une autre faille.

Contre-mesure: installer les derniers correctifs du micro-code Intel.

Même pas, il faut une mise à jour BIOS/UEFI pour ça.

Dans l'interview, il semble dire que c'est durant son temps libre au travail.

Mais qu'est-ce donc que du temps libre au travail ?
Un temps de pause n'est pas du temps libre, parce que vous n'êtes pas, justement, libre de vaquer à des occupations personnelles.

Certains glandent sur internet, d'autres se forment ou font de la veille techno, et d'autres codent de trucs perso.

Sur du matériel ,et dans un cadre, fournit par l'entreprise, donc. Sauf accord entre les deux parties, ces «trucs» ne sont plus perso: ils appartiennent à l'entreprise.

Ca serait en France, le mec aurait déjà perdu, ça a été développé sur son temps de travail, temps libre ou pas

C'est soit sur son temps libre, soit sur son temps de travail. Et ce n'est pas ce qui motivera la décision du juge.
La décision dépendra du cadre dans lequel le salarié exerce dans l'entreprise: son contrat de travail ou les ordres donnés par l'employeur.

1. Le salarié a-t-il produit un logiciel en lien avec sa fonction au sein de l'entreprise ?
2. Le salarié a-t-il utilisé du matériel de l'entreprise ?
3. L'employeur a -t- il commandé un produit en lien avec le logiciel au salarié ?

Si je comprend bien l'article, en Russie, le problème va se poser de la même manière.

Bah, si ça compile,c'est que ça fonctionne !

Il n'y a pas de véritable lien entre « logiciels propriétaires » et brevets logiciel.

et plan9 ?