Nicolas Boulay a écrit 16010 commentaires

Si tu as peu de mise à jour, tu fais plusieurs fichiers. Genre un fichier par année pour des photos.

"La première sécurité est la liberté"

Il n'y a pas d'info sur le genre de vitesse de connexion ou de débit accepté par mois.

"La première sécurité est la liberté"

J'ai une kimsufi mais sauver des Go photos avec 128ko/s d'upload, c'est hyper chiant.

Je pense que le plus simple c'est un ou 2 disques nomades cryptés (en cas de vol) stocké "ailleurs" : chez ses parents, au bureau, …

"La première sécurité est la liberté"

L'intérêt est dans le fait de garder de bonne relation avec Microsoft. Ensuite, si ils ont fait cela une fois, pourquoi ne pas l'avoir fait avec d'autres performances, beaucoup moins facile à prouver ?

"La première sécurité est la liberté"

Si le cloud te défreeze, crypte avec un logiciel comme truecrypt.

"La première sécurité est la liberté"

"Block ciphers (symmetric encryption algorithms): IDEA, CAST5, Camellia, Triple DES, AES, Blowfish, and Twofish." - wikipedia pour gpg

gpg utilise CAST5 par défaut.

"La première sécurité est la liberté"

si.

"La première sécurité est la liberté"

"Oui, en Java tu n’as pas le choix. Tu ne manipules que des références (sauf types primitifs il me semble), mais au final tout est passé par valeur."

Son explication avec un

  int foo (plop_t * plop){};
  ...
  foo(&plip);

est bizarre on peut dire aussi que ce n'est pas plip qui est transmis mais la référence à plip, qui sont donc aussi transmis par valeur.

"La première sécurité est la liberté"

Cela reste tordu. Dans les fait, tu peux faire une transmission par valeur ou par référence en C++, alors qu'en Java tu ne manipules que des références.

"La première sécurité est la liberté"

L'article raconte à peu prêt n'importe quoi.

Le passage par valeur implique une copie dans des registres. Java ne fait pas de copie à chaque appel de méthode sur un objet, et heureusement !

L'exemple est stupide :

public void foo(Dog d) {
    d = new Dog("Fifi"); // creating the "Fifi" dog
}

Dog aDog = new Dog("Max"); // creating the "Max" dog
// at this point, aDog points to the "Max" dog
foo(aDog);

La référence n'étant pas transmise, le comportement est logique. C'est le problème du "pointeur de pointeur" que l'on peut avoir parfois. Si au lieu de créer un nouveau chien, il changeant un champ de son chien, il verrait son erreur.

"La première sécurité est la liberté"

Mais tu as réellement besoin de le savoir ? Des langages comme Java ou OCaml passent tout par référence.

"La première sécurité est la liberté"

C'est rare les langages qui ne permettent pas un binding vers une fonction C quand les performances sont nécessaires.

"La première sécurité est la liberté"

Pourquoi tu n'aimes pas le passage par référence ?

"La première sécurité est la liberté"

Ou alors, il faut utiliser 2 puces, l'une ne servant que pour le drivers graphique(GPU).

"La première sécurité est la liberté"

Cela n'existe pas des petits chip graphique ? Dans le cas contraire, cela risque de manger beaucoup de cycle cpu. Sinon, il doit bien exister des fpga de quelques euros ou il est possible de faire des "blit" rapidement.

"La première sécurité est la liberté"

"Je dis ça, je déteste recopier sans comprendre, et du coup je le fais rarement, mais il manque parfois des bouts de démos dans mes cours ensuite :)"

Je déteste cette façon de faire cours. L'origine vient du fait de la 'mémoire de la main', qui permet de retenir pour certaine personne (mais pas toutes, chacun à sa methode : oral, visuel, de reformulation, écrite). Mais si le cours va tellement vite que l'on a même pas le temps de comprendre, c'est juste complètement idiot. Pourquoi le prof ne donne pas un polycopier, ce qui permet de suivre le cours et de tenter de comprendre pendant le cours.

"La première sécurité est la liberté"

"Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie."

Et pourtant si tu ne respectes pas tes 30 images/s ton film est illisible, idem pour le son. Pour un jeu, si le temps de réaction est au dessus d'une certaine valeur, c'est injouable. C'est ça le TR mou.

"Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision."

Oui et on s'en contre-fou. On détermine un ou une série de path d'execution long, on prends 50% de marge et c'est bon (avec cache froid, sans appel système, ni lock). Dans la vrai vie.

gcc -MM c'est pas mal. Mais globalement, make, c'est pas top. cmake semble avoir la faveur de beaucoup de monde. si tu as un petit projet, tout recompiler ne prend en général pas trop de temps, non plus.

"La première sécurité est la liberté"

" Le TR, c'est garantir qu'une opération peut être effectuée en un nombre de cycle déterminé"

N'importe quoi.

Le TR c'est garantir un temps d’exécution borné (réagir en moins de 100ms max, exécuter une fonction cycle en 20ms max). Tes histoires d'instructions qui mettent plus ou moins de temps, on s'en tape complètement, ce temps max est borné. Il suffit d'en tenir compte. En TR dure, ils ont peur des caches write back, mais bon… ils ont une bonne quantité de marge.

Les jeu vidéo, les lecteurs multimédias sont des TR mou et c'est finalement plus dure à faire. Un TR dure qui franchi sa limite, plante, un TR mou doit faire quelques choses d'intelligent (frame drop, freeze, …).

"Je parlais de make. Make ne sait pas ce qu'est un fichier C++. Il sait simplement qu'un .C va être compilé en .o"

C'est également n'importe quoi. make sait simplement qu'un fichier dépend d'autres fichiers, et dispose d'une commande shell pour recréer le fichier si une des dépendances est plus récente. Cela peut être les fichiers .c mais aussi .h.

"Mais je n'ai jamais réussi à le mettre en place de manière fiable."

Et alors ?

"La première sécurité est la liberté"

Un jeu vidéo, c'est du temps réel. Il n'y a pas de vie en jeu, mais demande au joueur si il aime les lags.

"(le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas),"

Si il peut. (gcc -MM de tête) C'est juste très chiant, car en général, une simple modification peut entrainer une cascade de recompilation. En général, les .h ne sont pas inclus, les .c impactés étant aussi modifiés, cela ne se voit pas. En pratique, il faut parfois faire un "make clean".

"La première sécurité est la liberté"

Le top et le moins chère, c'est netbook récent pour l'autonomie et les nouveaux atom un peu plus rapide + un tablette genre Wacom ( https://www.materiel.net/tablette-graphique/ ).

La tablette pas graphique s'utilise comme une souris mais est bien plus précis. Pour le dessin, les tablettes d'entré de gamme sont un peu trop imprécise (phénomène de marche d'escalier sur un trait droit), c'est à tester j'imagine.

"La première sécurité est la liberté"

L'avantage c'est que c'est plus rapide. Le défaut, c'est que tu peux avoir des plantages mémoires, après l'allocation (si tu as un "overcommit" supérieur à 1 ou 100%)…

L'avantage aussi, c'est qu'un new ou malloc en plein milieu d'un code code "temps réel", c'est prendre un gros risque sur la latence (min : qq cycles, max 15 000 cycles). Le top, c'est tout de même de ne plus avoir d'allocation mémoire après un certain stade. Tu es à peu prés sûr que ton code ne peut plus planter pour des raisons externes.

"La première sécurité est la liberté"

Elle est alloué d'une certain façon, mais les pages physiques ne sont pas mappé à ce niveau là. Le système sait juste qu'en cas de fautes mémoires, il faut allouer physiquement les pages et non pas retourner un segfault.

Le COW, c'est en cas de fork, sur la gestion des segments de data, qui ne sont dupliquer qu'en cas de modification.

"La première sécurité est la liberté"

Pour moi, le seul moment ou tu as une classe, c'est que de façon statique et non dynamique, tu as un traitement global au niveau de la classe mère. Si il n'y a pas de traitement, il aurait fallu faire une inclusion.

Le cas typique, est l'usine d'image, capable d'ouvrir du png ou du jpeg, mais qui retourne toujours une "image".

"La première sécurité est la liberté"

Ben non justement, l'allocation mémoire est retardé sous linux. Linux n'alloue réellement la mémoire qu'au premier accès. Donc la mémoire n'est pas rééllement consommé au lancement.

"La première sécurité est la liberté"

Sauf si tout est dans le .h. Sur une application , j'avais triplé la vitesse.

"La première sécurité est la liberté"