Gof a écrit 2224 commentaires

Note: Je ne connais pas Fushia, donc je peux me tromper. Corrigez moi si j'ai tord.

je vois mal Google se refermer et limiter les plateformes supportant Android

Oui mais:

• Fushia est libre, mais pas copyleft, permettant au constructeur de faire des fork non libre pour leur platforme.
• Fushia est un micro-kernel, donc à priori les drivers fonctionnent en user-space avec une ABI stable (spéculation de ma part). Ce qui permettrais au fabricant matériel de créé des drivers proprio (ou pas) qui n'ont pas besoin d'être mis à jour avec les nouvelles version du noyaux. (Contrairement à Linux ou tout les driver doivent être ajusté et recompilé si on veux mettre à jour.)
• (En plus, le Kernel est écrit en C++ qui est bien mieux que C (troll facile de ma part :-) ). et il est même possible de faire des drivers en Rust et en Go je pense)

Ces points pourrait favoriser un écosystème où il existerait plus de matériel mieux supporté (via des driver closed source) que sous Linux. Sans oublier la puissance de Google.

Peut être aussi que le plan de Google est de faire fonctionner l'userspace d'Android avec soit Fushia, soit Linux, au début.

Donc au final, je ne crois pas que ce soit un argument.

https://fr.wikipedia.org/wiki/Google_Fuchsia

N'oublies pas l'option -R de less pour les couleurs.

Perso, j'ai dans mon bashrc:

export LESS="-Rd"

Bon, je me reponds à moi même pour préciser que la spec a quand même un intérêt pour faire du code performant. Il faut avoir une idée de la taille des cache et tout ça. Mais c'est inutile pour éviter les undefined behaviour.

Undefined behavior ça corresponds a une interdiction dans le code de la route. Tu pourras tant que tu veux dire a l'agent qui t'arrête après avoir rouler à 180 km/h ou brûler un feu rouge, que tu as étudié le manuel de ta voiture et que il n'y avait personne, mais tu te prendra quand même une amande.

Je vais avoir besoin de savoir ce que tu appelle programme un peu complexe et aussi d'exemple d'undefined behavior qu'on ne peut éviter.

Un programme un peu complexe c'est à dire tout programme un peu plus utile que hello world.
Et des undefined behavior c'est, par exemple, overflow de signed integer, ou déréférence d'un pointeur invalide, ou un cast sur un mauvais type, ou une data race.

Il me semble que les undefined behavior du C correspondent à des cas très précis et le plus souvent documenté par l'implémentation.

Ne pas confondre « undefined behavior » et « implementation defined behavior ».
Si tu fait du C, la spec du hardware n'a aucun intérêt, sauf si tu utilise des extension genre asm ou autre intrinsics. Et en particulier, si tu crois que la spec du hardware rends les undefined behavior prévisible, tu fait une belle erreur.

À lire: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Rust à aussi ses chances en temps que language d'assembleur de haut niveau.

Le C est en effet un langage très simple (mais difficile à maitriser).

"simple" n'est pas très objectif, et est aussi assez limitant. D'ailleurs, le brainfuck est encore plus "simple" (et difficile à maitriser). Pourtant il ne prendra jammais la place du C.

Peu de mots clés

Rust a moins de mot clés que C (35 mot clé en Rust, 44 en C)

abstraction très légère

Pareil pour Rust.

norme peu contraignante laissant de grandes libertés aux compilateurs […]

Mais rends la tâche du programmeur extrêmement difficile car il est quasiment impossible de faire un programme un peu complexe qui n'a pas une « undefined behavior ».

Tout cela permet en C d'être facile à porter sur une nouvelle architecture matérielle

En effet. Mais comme il a été déjà dit, écrire un frontend pour LLVM n'est pas très dificile non plus.

Trouver quelqu'un qui a un niveau réel d'expertise en Rust, c'est autre chose.

Il suffit de recruter un programmeur C ou C++ et de le faire coder en Rust. Il s'adaptera assez vite.

Je suis plutôt d'accord avec toi, mais le commentaire auquel je répondait semble utiliser le terme "modèles de programmation parallèle" pour dire api de haut niveau, telle que les go-routines ou map réduce. d'où les guillemets.

Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

Sur ce point je ne suis pas d'accord.
UB en C++ veux aussi dire que le compilateur peut faie n'importe quoi.

La rubrique « liens », c'est de la pollution numérique.

Les "modèles de programmation parallèle" simplifient un peu les choses, mais ça n'enlève pas le risque de data-races sur les données partagées.

Par ailleurs, en rust, Tu n'est pas non plus encourager à utiliser des thread directement. Tu utilise une des API de la librairie standard ou des différentes crate qui exposent des abstractions.

Tu remplaces new par make_unique, et tu n'as plus besoin de delete.
Quand tu passe ton pointeur à une fonction qui prends un raw pointer et qui garde l'ownership, utilise my_ptr.release().

Qu'on ne peut pas faire de trucs «sales» en Rust.

Bien sûr que si, on peut. Il suffit d'écrire unsafe { ... }, et tu peux faire tout les truc « sales » que tu veux. C'est bien ça la force de rust: par défaut le compilateur vérifie, mais quand tu es sur de ce que tu fait, tu peux utiliser unsafe.

il ne peut plus vérifier et on perd l'intérêt du langage

On ne perd pas l'intérêt du langage car on peut limiter les zones unsafe à quelques primitives de base (par exemple CurrentFrameAllocator, CurrentFrameBox<T>) qui est reviewé avec plus d'attention, alors que la plupart du code reste en safe.

Je la conaissait avec des sages sales dans un train:
https://web.archive.org/web/20130919012100/http://linux-sottises.net/math.php

Qt 5.6 est une version LTS, maintenue jusqu'en 2019

https://en.wikipedia.org/wiki/Qt_version_history#Qt_5

En même temps, quel rapport entre le ciel à Pékin, et la production de Bitcoin, dont les mineurs sont supposé être situer à coté des centrale hydroéléctrique, hors des villes.

Non, la sécurité viens du fait qu'on peut difficilement contrôler la majorité de la puissance de calcul.
Contrôler les majorité des nœuds c'est facile, il suffit d'en lancer des milliers dans une VM : https://fr.wikipedia.org/wiki/Attaque_Sybil

Attention, Certains ce sont fait arrêter pour ce genre de choses.
https://fr.wikipedia.org/wiki/Aaron_Swartz#Affaire_JSTOR

Une autre alternative que j'utilise c'est htop au lieu de top

En effet, le CDATA est nécessaire en XHTML et permet à ce que le fichier soit quand même valide XML malgré le fait que le contienne des caractères tels que '<' ou '&'

Il semblerait que ce journal soit une fake news.
Déjà, il n'y a pas de srouce. Mais en cherchant un peu, on tombe sur un article publié récament sur ce site même: https://linuxfr.org/users/joalland/journaux/enigme-la-mouche-zobzob qui est en fait juste un exercice avec une histoire vraisemblablement purement fictive.

J'en déduit que la mouche Zobzob n'existe pas. Pas plus que le Fly Highschool Institute. Cet article est donc encore l'une des nombreux fake news juste destiné à attirer nos clics.

Comme toujours, faites attentions à ce que vous pouvez lire sur internet !

Qu'est-ce que ça veux dire Bronsoniser ?
Je suis nouveau sur ce site, désolé si ça a déjà été répondu.

En même temps, il n'envoie pas non plus ceux qui font des fautes dans des camps de torture avec peu de chance de survie.

Permet moi d'être en désacord sur les détails.

Si ce n'était qu'un problème de CPU, la gestion des atomics à l'ancienne à coups de bibliothèque suffirait.

Bah non justement, un appel à une fonction d'une bibliothèque est déjà une barrière complète pour le compilateur. Mais pas pour le CPU.

Par contre, si ce n'était qu'un problème de ré-ordonnancement par le compilateur, la gestion à coup de volatile suffirait.

Bien sûr, mais le processeur ne peut pas exécuter une opération (par exemple "ADD x, y") quand il n'a pas les données correspondantes (x et y)

Tout ne peux pas être éxécuter dans n'importe quel ordre. Je réagissait au fait que tu disait que « Le ré-ordonnancement est une optimisation importante du compilateur », alors que dans le contexte du message auquel tu réponds, ce n'est pas le compilateur, mais le CPU qui ré-ordonne.

le contraire de quoi

Le contraire du fait que les compilateurs doivent ordonnés les instructions dans le bon sans pour aider le CPU. (Mais c'est vrai que le compilateur à quand même encore des possibilité d'optimisations.)

alors le processeur serait obligé d'attendre la fin des instructions « charger » avant les instructions « utiliser » correspondantes.

Non, les processeurs font plein d'opérations en parallèle et ré-ordonne les instructions pour pouvoir les exécuter plus vite. (parfois même de manière spéculative)

En fait c'est le contraire: On utilise les opération atomique pour dire au compilateur d'introduire des barrières dans le code pour que le processeur ne ré-ordonne pas ces opérations.