reno a écrit 3886 commentaires

Avec de bon graphismes vectoriels je vois pas où est le problème.

Bah, heureusement que tu ne crées pas des applications, la taille des icônes n'est pas le problème principal..
Personne n'a dit qu'il y avait une différence fondamentale, mais bon si tu mets une application prévu sur une tablette sur un smartphone ça risque d'être pénible a utiliser car il y aura trop de boutons sur une petite surface, donc il faut adapter l'UI, pareil dans l'autre sens: tes utilisateurs de tablettes trouveront une appli de smartphone "pauvre" car pas conçu pour un grand écran.

Dans l'articles des Inrocks il y a "Un bon administrateur réseau, quand il se prend une attaque comme ça [DDOS], n’a besoin que de quelques minutes pour réagir" et là je trouve ça très curieux comme phrase: certes si le déni de services est fait en faisant consommer des ressources à un serveur, ce n'est pas toujours trop compliquer de réagir (encore que ça dépend assez de l'attaque), mais si la bande passante de ton accès est saturé là ça peut devenir très compliquer!

OK, j'y suis peut-être aller un peu fort. Mais bon la doc de "référence" ne parle pas du sujet (quand même assez fondamental) alors j'ai quelque excuse non?

Tiens une dépêche qui parle d'ADA ?

Bah non: je doute que Rust arrive à la cheville d'Ada sur bien des sujets, un exemple: dans leur doc de "référence", ils ne parlent même pas de ce qui se passe en cas de débordement entier, je suppose que la sémantique du C/C++ est tellement imprimé chez eux qu'ils n'envisagent même pas d'avoir un autre comportement..
Pourtant avoir des entiers avec un comportement sain (big int ou exception en cas d'overflow par défaut, débrayable pour les cas ou il faut 100% des perfs du CPU) dans un langage conçu au 21ème siècle ça ne serait pas un mal..

Si je suis d'accord avec toi en gros, je pense que les GPUs ont des gros problèmes, même en local à cause de leur histoire: au départ il s'agissait d'accelerer une application (une appli de CAD ou bien un jeu), passer d'une application a plusieurs est très compliqué (surtout que ça n'est pas un gros argument pour les ventes donc la priorité est secondaire pour les vendeurs) donc même maintenant ça n'est pas terrible: je ne pense pas qu'utiliser un GPU soit compatible avec des garanties temps réels par exemple.

Bref, la 3D a l'heure actuelle c'est loin d'être mur, alors quand on rajoute du distant la dessus forcément ça ne peut qu'exacerber les problèmes..

Si tu crois que je défends MU, tu te trompes..
Je remarque qu'un des arguments contre eux est assez mauvais "en tant que tel" (ceci dit si c'est le même utilisateur qui crée ces liens alors effectivement le reproche devient légitime).

"Tous en partagent une pleine maîtrise", et bien sauf s'ils respectent le contrat d'utilisation qui vient en général avec..

Il y a 16 ans on pouvait se permettre d'utiliser un seul CPU, maintenant ce n'est pas une bonne idée et par défaut les evenements c'est mono-CPU.

Ceci dit, il y a thread et thread par exemple en D les variables globales sont thread local par défaut et il faut les marquer "shared" pour qu'elles soient partagées par plusieurs thread, ce qui est déjà un progrès.

Enfin par rapport au C++ pas par rapport à Ada.

"La propriété est le travail", euh quand tu dis que tu possède un terrain, c'est quel travail au juste?
Avoir poser la cloture?

Tiens ça m'a fait penser a un truc d'ailleurs ça: un des reproches du gouvernement est que si un fichier était accessible par plusieurs liens et qu'un des liens était montrés comme étant une copie illégale, MégaUpload ne virait pas le fichier mais juste l'accès par ce lien.
Mais d'après la "couleur des bits", c'est un raisonemment foireux: si A et B utilisent le même outil pour ripper le même contenu, le fichier généré sera le même et un site web tel que MégaUpload a tout intérêt a "dédupliquer" le contenu, si A publie le lien partout mais pas B (copie "privée"), le lien A est illégal mais pas forcément le lien B et donc le fichier..

Sinon j'aime bien le bug report sur les pb de latence d'android qui montre bien que google n'en a strictement rien à foutre: http://code.google.com/p/android/issues/detail?id=3434

Merci pour le lien, ça me rappelle les bugs report sur Java qui duraient des années avec plusieurs centaines de commentaires.
Mais bon là c'était moins drôle car j'avais besoin des corrections, en spectateur non intéressé c'est plus amusant.

PulseAudio est LGPL que Google évite dans Android donc porter l'API native d'Android au dessus de PA comme évoquer dans l'article me parait une perte de temps..

Je serai Google je payerai les dev de PA pour qu'ils acceptent de mettre leur code en licence BSD, ça coûterait probablement moins cher que d’améliorer AudioFlinger.

Mais si les 2 sont malicieux t'es toujours dans la mouise.

Pas vraiment: si les 2 sont malicieux de la même manière, tu es dans la mouise, autrement la différence sera vue quand même.

Dans l'article « Reflections on trusting trust », Ken Thompson a écrit :

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

Ça date: David A. Wheeler a trouvé un moyen de contourner le compilateur malhonnete de Thompson, relis la page wikipédia sur le sujet..

Ahem, pour que l'exemple que tu donne soit réaliste il faudrait que toutes les applications qui utilisent libpng utilisent une sandbox correctement ce qui est peu réaliste.
Donc en théorie ça ne change rien: il faut mettre à jour le système rapidement, mais en pratique ça peut changer beaucoup de chose car si ton webbrowser et ton filebrowser sont tous les deux "sandboxisés" correctement et bien comme ce sont les applications que tu utilises 99% du temps, le risque que tu sois affecter par la faille est très, très inférieur.

Note que
1) les applications web prennent de plus en plus d'importance
2) Chrome supporte déjà Capsicum
ça fait déjà une adoption très importante..

Après bien sûr, un framework de sécurité n'est intéressant que si les applications l'utilisent.

La vitesse d'adoption de nouveauté est très variable: les outils d'analyse de consommation électrique ont fait évoluer les logiciels rapidement,
l'adoption d'XCB par GTK/Qt/EFL traîne, la sécurité est peu vendeur (la preuve: les capabilities n'arrivent que maintenant en mainstream) donc l'adoption risque d'être longue surtout quand à l'heure actuelle, elle n'est dispo que pour FreeBSD!

On a tout de même énormément de chance qu'il y ai des gens vachement motivés et qui ne souffrent pas d'un égo surdimensionné

Bah tu es trop optimiste, il y a beaucoup de gens intéressés par améliorer le noyau Linux, donc parfois ça finit par rentrer ok, mais il y a aussi des fonctionnalités très, très intéressantes qui ont été rejetée, et qui n'arriveront peut-être jamais dans le noyau..

Un exemple: une "synchronisation" entre le gestionnaire de mémoire virtuelle et un GC, ce qui permet d'avoir le bénéfice du swap même avec un GC: gain de performance potentiellement très important..

Ceci dit, ces super-fonctionnalités, j'ignore quel était la maturité de leurs demandes d'inclusions: les fonctionnalités ne sont pas tout, il y a la maintenabilité du code, de l'API aussi..

Et bien tu parles de quoi?
De serveur? La OK, FreeBSD me parait tres bien et même supérieur a Linux par certains coté.
De client? Coté pilotes ils sont à la traine il me semble et ça c'est un gros handicap.

Bon alors, première à troller mais les capabilities (si mon cerveau de blonde ne me trahit pas) c'est "emprisonner" les processus dans des sandboxes comme le fait chrome. C'est ça ?

Il y a plusieurs façon d'implémenter des sandbox, mais oui c'est ça.

Mais si ce concept est si vieux mais si puissant, pourquoi il a pas été intégré sur les premiers UNIX dès leurs naissances ?

1) Unix c'est pas tout récent non plus
2) il y a une tentative d'explication ici: http://www.eros-os.org/essays/capintro.html

Personnellement je dirais que:
-l'inertie en informatique est énorme
-ce ne pas le seul cas ou quelque chose de mieux est rejeter: Ada vs C par exemple, la qualité de l'outil/la puissance du concept est juste un facteur, d'autres facteurs interviennent aussi: prix, simplicité d'utilisation/d'implémentation/compréhension, ou même les modes, le hasard..

Si je met un nouveau protocole au dessus d'IP, valide 100% pour Internet, qui parit que je ne me ferait pas refouler?

Bah tu connais déjà la réponse des tests ont montrés que par exemple SCTP ne passe que sur 50% des box:
http://www.bortzmeyer.org/home-gateway.html

A priori, même les téléphones ne savent pas encore faire de l'ipV6 correctement.

Bah, ça ce n'est pas une raison: il suffit de désactiver la fonctionnalité par défaut et de mettre a coté de la case d'activation un texte du genre,
"Attention, l'activation de cette fonctionnalité peut rendre non-fonctionnel votre accès réseau si votre téléphone implémente mal IPv6!".

Bref tu confirmes les homos sont inhumains?

J'ai l'impression qu'en voulant le secourir de s'être tirer une balle dans le pied, tu lui a tirer dessus au bazooka: ton extrait n'est pas mieux..

Un dév qui a mal manifestement mal compris la distinction entre classe et instance.

Ou qui a zappé une paire de parenthèses ce qui peut arriver a tout le monde.

Un exemple de plus comme quoi le typage dynamique implique de tester beaucoup..

Je parlai de code incorrect (dépassement de tableau, variable non initialisée, utilisant une opération non définie) qui fonctionne par chance, en C ou C++ c'est très fréquent: http://blog.regehr.org/archives/213

En Java? A moins d'utiliser les thread, ça me parait plus difficile..

Après du code naïf/inefficient/redondant/pas robuste/pas maintenable/pas lisible, ça existe dans n'importe quel langage, mais c'est autre chose.

Pas faux, mais si tu as un telephone de base pourquoi prendre un abonnement avec Internet??