Renault a écrit 7174 commentaires

Oui c'est techniquement plus juste.
Après concernant cette technique, j’ai vu pas mal d'études sur le sujet et en gros ça fonctionnait pour un modèle d'ordinateur très précis à chaque fois car suivant le processeur, la carte mère ou le boîtier le bruit change et par conséquent le traitement ne permet pas une bonne restitution.

Et en plus il faut savoir quand le calcul de la machine traite de la cryptographie que du reste de l'ordinateur.

Beau travail , ça va m'aider au boulot.
Cependant, tu utilises l'expression KISS de manière trop publicitaire. D'autant qu'il n'y a pas de lien entre une application KISS et l'usage du shell contrairement à ce que tu sembles sous entendre.

Je te rassure, dans les puces Texas Instrument et Broadcom tu as du lourd aussi. :)
Entre la doc, la qualité du code et des commentaires, il y en a pour tous les goûts !

Bon, mais pourquoi systemd-logind, dbus activation dans le PID 1 ?

Si tu crois que tout ça est dans le PID 1, c'est que tu n'as vraiment aucune connaissance de base sur ce qu'est systemd ce qui rend ton argumentation contre lui caduque (je ne peux pas considérer comme sérieux des arguments de quelqu'un contre un truc pour lequel il ignore tout).

J’entends bien qu’il y ait dans les Linux moderne une certaine complexité qui n’était pas là avant (je pense aux cgroups, namespaces et capabilities principalement), mais c’est loin d’être insurmontable. De fait, ce n’est généralement pas la gestion des cgroups de systemd qui est critiqué quand on critique sa complexité.

Des gens qui maîtrisent tout le fonctionnement du noyau Linux, dans le monde ça doit se compter sur les doigts de la main et encore je ne suis même pas sûr qu'il y en ait.
Linux ce n'est pas uniquement la partie émergée de l'iceberg, à savoir son interface en espace utilisateur qui évolue assez peu et qui est en effet plutôt accessible à n'importe qui le souhaitant. Mais les rouages internes de tout ce logiciel c'est une autre histoire et peu de personnes semble s'offusquer qu'on ne puisse tout maîtriser.

À un moment il faut faire confiance aux outils que tu utilises et non vouloir tout comprendre et maîtriser car tu n'as pas le temps humainement de tenir la charge. Sinon si tu pars de ce principe là tu dois maîtriser aussi l'électronique de ta machine.

La notion d’abstraction est très puissante.

L'abstraction signifie que tu te dispenses de comprendre les couches inférieures pour que ça te reste simple. Quand tu programmes tu te fous bien souvent de ce que fait un objet par exemple, tu t'intéresse à l'interface.
Ici c'est pareil, sauf que tu sembles vouloir absolument maitriser les rouages de systemd alors qu'il suffit de comprendre son interface extérieure.

Simplement, étant donné les besoins auxquels sont capables de répondre les concurrents de systemd et leur complexité bien inférieure, j’ai un a priori très négatif sur la « nécessité » de cette complexité.

Et si tu demandais aux mainteneurs des distributions leurs avis sur tes solutions plus simples et iso-fonctionnelles ? Ces gens ne sont pas masos et accepteraient volontiers quelque chose de plus simple qui répond au même besoin.

systemd répond à des problématiques qui sont apparus avec l'informatique moderne tels que la mobilité, le caractère asynchrone de pas mal de services et périphériques, etc. Des choses dont les anciens outils y répondaient parfois partiellement ou mal car nécessitant des contorsions énormes pour parvenir au résultat souhaité.

L'informatique se complexifie, et ce n'est pas une injustice, c'est un fait, pour répondre aux besoins des gens il faut cette complexité. Tout comme les sciences se complexifient de jours en jour car on découvre des choses, car on a de nouveaux outils qui nous permettent d'aller plus loin, croire que l'informatique et l'industrie vont rester simple c'est se foutre le doigt dans l’œil (et ce n'est pas forcément intéressant).

Linux n'a jamais eu pour but d'être simple, mais d'être le meilleur noyau possible et le plus performant possible. C'est comme ça que le noyau a été bâti et que le reste du système a suivi. La simplicité n'a jamais été un prérequis et une volonté manifeste, sauf peut être de quelques distributions comme ArchLinux. Si ton but est de maitriser toutes les couches de ton système, il vaut mieux aller voir ailleurs comme Minix qui est bien plus simple et fait pour ça (mais le revers c'est qu'il offre moins de fonctionnalité ce qui est logique).

C'est un système ouvert où chacun donne et prend ce qu'il veut dans ce "bazar". Ici systemd a été donné par Lennart, et pratiquement tout le monde l'a adopté malgré ses faiblesses. Tu peux t'en attrister car tu aurais préféré une autre solution, mais c'est comme ça, les gens ont choisi et tu es libre de suivre une autre voix mais ça me paraît ridicule de vouloir forcer à aller à contre courant de la situation actuelle (car les gens s'en foutent de ton avis, ils se préoccupent du leur).
En fait il faut voir le LL comme un système où tout le monde est égoïste (faire des choses pour se faire plaisir, répondre à ses besoins) mais dont le partage permet l'évolution car chacun va apporter sa pierre pour répondre à son besoin et le total donnerait une solution qui répond au besoin de tous (ou presque).

Parceque Gnome a en dependance systemd, parceque KDE va avoir en dependance systemd.

C'est la faute à GNOME et KDE hein. systemd n'est pas responsable des choix de ces logiciels le concernant.

Apres encore une fois, il y a des tres bonnes raisons pour et il y a probablement de tres bonne choses dedans

S'il y a de bonnes raisons, c'est que tout cela est justifié donc où est le problème ?

et encore une fois j'ai le droit de l'etre

Tu as le droit de l'être, mais sur ce sujet (pas forcément dans ce fil de discussion mais ailleurs), tu étais bien plus virulent à ce propos et tu ne te contentais pas d'être seulement déçu.

et je ne parle meme pas de remplacer le Grub ou la la seule logique c'est cette merde de "securite" et de lutte contre les terroristes… et donc d'empecher aux utilisateurs de changer quoi que ce soit sur le systeme.

C'est une option, ceux qui veulent et peuvent changer le feront, les autres pas. Je rappelle qu'il y a des machines où l'utilisateur n'a pas à avoir le droit de modifier le logiciel qu'il y a dedans, notamment en contexte professionnel sensible. Mais pour ton ordinateur personnel c'est une autre histoire (et elle ne sera pas impactée par ceci).

LP a précisé qu'il n'avait rien contre le fait que systemd supporte *BSD, mais que ce ne serait pas lui qui maintiendrait et coderait ces patchs car il trouve ça trop chiant. C'est son droit.

Des tas de programmes fonctionnent sur une plateforme uniquement pour les mêmes raisons et personne ne s'en offusque pour autant.

Si tu peux, il suffit que le composant que tu veux utiliser respecte l'API de systemd. Et tu peux même modifier systemd pour étendre l'API pour rendre ton outil encore plus intéressant que ce que propose systemd aujourd'hui.

Et moi dans tout ça, en tant qu'utilisateur non-esclavagiste d'un outil que quelqu'un choisi de développer et qui me convient, je n'ai rien demandé !

Moi perso je n'ai rien demandé à personne dans le LL, ils ont fait ce qu'ils ont voulu faire et je choisis ce qu'ils proposent. Et parfois il y a incompatibilité entre ce que je voudrais et ce que j'ai mais je m'en fous car je ne suis pas le centre du monde et les gens codent ce qu'ils veulent.

Non, mais tu t'étonnes que quand tu veux remplacer un frein à disque par un frein tambour il faille modifier pas mal de choses dans la voiture…
Et oui, dans une voiture de nombreux composants impactent d'autres composants dans la voiture, comme tout système (mécanique, électronique, informatique, etc.). Ce n'est pas aussi rose que tu sembles prétendre.

Sauf que rien ne t'empêche d'utiliser d'autres outils notamment les anciens pour remplacer systemd dans son ensemble avec pour propriété d'être plus modulaire.

Après tout, d'après certains ici, SysV permettait de tout faire, donc ça doit être possible facilement non ?

Note que systemd n'est pas un blob binaire unique, tu peux remplacer chaque sous composant mais tu dois respecter une certaine API ce qui est le cas pour tout projet logiciel qui collabore avec un autre.

De nombreux programmes ne fonctionnent que pour Linux depuis la nuit des temps, ça t'empêche de dormir ?
Linux ne compile qu'avec les outils GNU actuellement, ça te pose un problème ?
X.org n'avait pas de remplaçant possible pendant 30 ans, ça te posait un problème ?

Etc.

Le probleme c'est que cela devient un truc enorme qui fera tout et le cafe et qu'il sera impossible de se passer.

Et ? Tu trouverais légitime que *BSD se plaignent car Linux est le système UNIX de référence dans le Logiciel Libre et qu'ils sont par conséquents délaissés ? Moi pas.
Si tu veux ne pas être à la traine, il suffit de rendre ta solution favorite meilleure et systemd ou autre technologie ne sera plus indispensable.

Et non un fork n'est pas la solution car quel interet de forker systemd? Cela sera la meme philosophie.

Maintiens les outils d'avant, c'est une solution possible et même facile d'après de nombreuses personnes, nous attendons la démonstration pratique de ces propos.

Je suis tout de meme persuade que l'on s'eloigne tres (trop?) loin de ce qui fait que beaucoup de linuxiens d'aujourd'hui sont sur ce systeme c'est a dire la possibilite de comprendre ce qui se passe et pouvoir adapter le systeme a leur besoin.

L'informatique s'est complexifiée depuis les débuts de Linux. Pratiquement personne maitrise des projets tels que Linux ou X.org en entier, sans compter le fonctionnement des interactions de tous les composants du système et du matériel. Tu es obligé de considérer une partie de ton système comme une boîte noire, après tous les admins systèmes le faisaient sans broncher envers X.org et Linux depuis longtemps alors que ce sont des composants essentiels. Pourquoi systemd serait différent ?

L'important est de pouvoir faire ce que l'on veut, avec la documentation et des options de disponibles ce que systemd ne supprime pas le moins du monde. Pas de tout comprendre car c'était déjà avant lui impossible.

Et ? C'est exactement ce que j’ai dit, il n'y a pas un complot interstellaire derrière. Le code source est disponible quelque part avant la fusion, donc tu peux le récupérer comme avant.

Udev est un logiciel qui a été laissé à l'abandon par son mainteneur c'est tout et son remplaçant se trouve dans systemd mais chacun peut maintenir le udev d'avant. C'est un cas classique.

Tu es en train de dire que Lennart a menacé les développeurs de udev et compagnie pour que leurs codes se retrouvent uniquement dans systemd, que tous les dépôts ont du être supprimés et qu'ils ne devaient sous aucun prétexte maintenir le tout en dehors de systemd ?

Je pense plus que ça s'est passé comme ça :
* systemd a inclus une fonctionnalité auparavant dévolu à un programme tiers ;
* les mainteneurs de ces programmes n'existaient plus ou ont abandonné le support du programme tiers car ils trouvent systemd plus attrayant.

Où est la responsabilité de systemd si les mainteneurs ont lâché l'affaire ou sont passés à systemd ? Le Logiciel Libre c'est sans garantie aucune, notamment de maintenance. Ici on est typiquement dans le cadre de programmes qui sont abandonnés, c'est triste pour certains mais cela arrive tous les jours. En quoi ici ça devrait être traité différemment ?
Comme le code source est libre, tu peux sans soucis continuer le support, c'est là l'avantage majeur du libre. Seulement ça ne se fait pas tout seul, remarque qu'il est possible de se cotiser pour payer des gens à le faire si vous y tenez vraiment.

Note qu'à ce rythme actuel (à savoir une branche en 4.5 ans) il faudrait 72 ans pour arriver à la branche 20.x. D'ici là si Linux est encore en développement, Linus ne sera probablement plus le mainteneur principal du noyau.

On se connait assez pour que tu saches que je suis tatillon sur les licences ;-).

C'est justement ce qui me surprend dans ton discours du jour. ;)

Mais il faut être réaliste : il y a une zone grise, qu'on le veuille ou pas.

La zone grise concerne souvent des clauses potentiellement illégales des licences, le fait que le brevet logiciel n'est pas reconnu partout dans le monde et des techniques de rétro-ingénieries qui sont souvent légales sous conditions.

Violer la non redistribution c'est un viol manifeste de la loi, de même que de télécharger sans avoir payé un CD de musique dont l'auteur ne souhaite pas la libre redistribution. Même si c'est rarement condamné juridiquement, je n'inciteras pas aux gens de le faire et de cacher ce problème sous le tapis.

Aurait-il fallu interdire à Firefox de lire le JPEG et le GIF car la loi l'interdisait (brevets)?

Les brevets logiciels n'existent pas en Europe. De mémoire les briques qui gèrent ce format ne proviennent pas de Mozilla eux mêmes. Donc normalement il n'y a pas grand chose à reprocher à eux pour cela (et si ça a été fait par des européens, je ne vois pas le soucis, après si Mozilla doit faire une version américaine et européenne pour être en conformité avec la loi ça aurait une bonne chose qu'ils le fassent, mais je suis européen perso).

Aurait-il fallu enlever le support de .doc d'OpenOffice car la loi dit que c'est pas bien?

Est-ce qu'il est interdit de reproduire le format doc ? Je ne sais pas, tous les logiciels ou formats propriétaires n'interdisent pas la rediffusion et la réimplémentation de formats. SI tu as un lien je suis preneur, et je serais pour le respect du droit.
Note après qu'en France, pour des raisons d'interopérabilités, cela pourrait être légal.

Quid des émulateurs libres impossibles à utiliser sans contrefaçon de la ROM, est-ce crédible que les gens vont faire du légal avec?

Le logiciel n'est pas illégal même si sa fonction incite fortement à ne pas respecter la loi. C'est à l'utilisateur de faire attention dans ce cas, le développeur ne risque rien.

Et la clé AACS alors? Tiens, bizarre mais les libristes étiaent pour la diffuser, alors que clairement interdit.

Normalement en France c'est possible pour des raisons d'interopérabilité. La HADOPI n'a pas su expliquer clairement à VLC qu'ils enfreignaient la loi dans un tel cadre.

Etonnant, la zone grise est mal, sauf quand le libre peut en profiter.

Non, pas vraiment, en tout cas pas pour moi.
Un développeur qui ne respecte pas une licence et son droit local fait pour moi une mauvaise chose, mais le soucis ici est que le développement peut être mondial et donc avec des lois différentes sur certains cas comme les brevets ce qui rend certains LL bien légaux dans nos contrées notamment.

Mais la non redistribution, si elle est indiquée dans la licence, est régie par la convention de Genève et là ce n'est plus une zone grise. :)

Justement, tu auras le choix et il est fort probable que tes distributions feront le choix par défaut de ne pas les inclure.

Le libre ne peut donc pas avancer avec des outils servant à limiter les libertés des utilisateurs à l'intérieur…

Si Mozilla devient négligeable en PdM et que le W3C n'a que des membres de Apple, Microsoft et Google, je ne donne pas cher des libertés du Web et de ses standards…

Donc non, parfois faire une concession sur le proprio peut donner plus d'élan au mouvement du libre que de ne rien concéder de ce point de vue. Même si c'est triste d'en arriver là.

Je vois bien qu'ils n'ont pas eu le choix et c'est triste qu'ils soient obliger de faire cela, c'est une trahison pour les utilisateurs libristes de firefox :/
Le libre a toujours IceCat et Iceweasel ;)

Il n'y a pas de trahison, la solution de Mozilla inclus un binaire non libre que si tu le souhaites, comme Flash, Firefox reste libre mais permet en étant non libres de lire des formats qui intéressent les gens.

Et IceCat et Iceweasel ne sont pas plus libres que Firefox et Thunderbird, c'est le même code avec des noms et logos différents car Debian ne respecte pas les conditions pour avoir le droit de les exploiter. Et c'est un employé de Mozilla qui gère ça en plus.

Je t'invite à lire ce billet : http://standblog.org/blog/post/2014/05/19/Mozilla-et-les-DRM-une-autre-perspective

Encore je suis d'accord avec toi globalement dans ce sujet. Mais là plus du tout.

Tu es en train d'expliquer qu'en gros violer les licences c'est courant, ce n'est pas graves, etc. Moi je n'aime pas trop qu'on incite à ne pas respecter la loi et le droit d'auteurs de certaines personnes même si on n'est pas d'accord avec ces clauses.

L'avantage indéniable du LL est clairement la libre redistribution, ça permet entre autres dans ce genre de projets de ne pas se prendre la tête à savoir s'il peut ou pas le faire. Tu balayes cet avantage d'un revers de main en incitant à violer potentiellement des licences.

C'est trop facile de dire que le proprio a mainte avantages sur le libre (ce qui est vrai pour beaucoup de logiciels) mais si tu omets de comparer l'ensemble des facteurs incluant notamment le respect de la licence (qui n'est pas un détail dans le sujet dont on parle), il est normal d'arriver à ce résultat biaisé.

Le bonhomme peut effectivement mettre du non libre si ça lui chante mais ça me paraît primordial qu'il respecte les licences de ces produits et certains d'entre eux peuvent interdire la libre rediffusion notamment d'un point de vue professionnel.

Ce qui est encore plus formidable c'est le travail abattu depuis le début de LibreOffice.

Je veux dire, les évolutions ne sont pas toujours très visibles (bien qu'en performances il y a eu un net progrès par exemple), mais on voit qu'ils se donnent les moyens pour faciliter les travaux futurs par le nettoyage et la mise en place de procédures adéquats et attirer ainsi de nouveaux contributeurs.

Pour un projet de cette taille, stopper l'inertie débutée aux débuts de Sun c'est difficile et ils y arrivent peu à peu et c'est admirable. LibreOffice se donne clairement les moyens de régler ses défauts. On ne peut pas dire autant à priori de OpenOffice.org par exemple…

En tout cas c'est sympa que le projet communique sur les changements importants d'arrière plan.

Exactement, comme au théâtre où l'auteur récupère une partie des sous liées à la représentation.

Ce que je n'aime pas dans ton approche c'est le côté : ils ont fait un travail, potentiellement énorme, ils ont donc le droit à une rémunération et à un contrôle sur leur bébé hors du commun.

Regarde, dans le monde logiciel tu as des tas de gens qui ne vivent pas de leurs productions et livrent tout gratuitement et librement et cherchent à minimiser au maximum de ce que permet la loi leurs droits dessus. Cela n'a pas tué cette industrie, ni empêché les gens de vivre et de créer alors que certains cherchent l'excellence de leurs bébés.

Des tas d'auteurs, très talentueux et reconnus aujourd'hui n'ont pas récolté les lauriers de leurs vivants et l'argent qui va avec. Produire une œuvre d'art recherché n'implique pas d'exiger autant de contres parties pour qu'ils puissent le rentabiliser au maximum. De même qu'un brevet a une durée très limitée (20 ans) alors qu'il a pu coûter très cher en R&D, cela ne signifie pas qu'il est nécessaire de leur octroyer des droits incroyables dessus pour rentabiliser cette R&D d'autant que ça peut ne rien rapporter (les brevets les plus coûteux ne sont pas forcément rentables).

Pourquoi l'art aurait une telle exception ?

Idéalement il faudrait une troisième voie sur tout le tracé mais c'est impossible à faire. Il faut de nouvelles lignes complètes si on veut vraiment une solution durable.

Après que ce soit une LGV ou pas, perso je m'en moque mais tu semblais dire que la France était équipé alors que ce n'est pas tout à fait vrai, les besoins de demain sont loin d'être remplis par la situation actuelle.

(un peu comme les brevets).

Un brevet n'est pas renouvelable, c'est une durée fixe au moment du dépôt.
Certains pays comme la France peuvent révoquer ce dépôt si le brevet n'est pas exploité, mais c'est loin d'être générique au monde entier.