un_brice a écrit 1165 commentaires

Ca c'est impossible, si tu veux des enfants calme, tu les met devant un film ou tu les droguent… Mais si les enfants s'amusent, ils s'excitent

Tangente mais… T'as jamais joué à un jeu de construction au papa/à la maman? T'était pas trop concentré ou trop dans le rôle pour t'énerver? D'accord que les enfants on besoin de se défouler, mais je me suis aussi beaucoup amusé à construire des trucs. Et même à dévorer des livres!

C++ permet cela, c'est la manière dont il est utilisé à Google. En interne Go tends plutôt à remplacer Python, il est trop tôt pour dire si pytype inversera la tendance.

Le besoin d'écrit dans l'article est généralement géré par du duck-typing dans les langages dynamiques ou du structural typing dans les langages
statiques […] C'est ce que fais Go par exemple

Certains des besoins oui, mais l'un des avantages décrits pour std::size() est de s'utiliser facilement avec static_assert.
Au delà du duck typing/structural typing, le C++ essaie de fournir des outils pour vérifier à la compilation certains erreurs lors de l'utilisation de bibliothèques. Ce sont les exemples donnés avec expects ou static_assert.

Pour voir la différence: Google pytype implémente des validations statiques pour Python (potentiellement plus restrictives que le système de types du language). C'est à mon sens un besoin auquel Go réponds moins bien.

Plus tu progresse en séniorité plus les stocks et bonus représentent une part importante du salaire. Du coup les chiffres que tu mentionnent sont compatibles avec des salaires 2-3 fois plus élevés.

Ça reste moindre que les 500k$ net que groumly annonce mais du bon ordre de grandeur. Je confirme aussi le 120k$ salaire + 100k$ stock au début (un pote Googler a commencé là).

Je suis pas très convaincu. Au final j'ai pas l'impression que le système de cryptage empilé sur le système de fichier sera le maillon le plus faible. Si tu veux mitiger les risques associés à l'usage d'un matériel modifié par une personne arbitrairement qualifiée il te faut une chaîne de confiance… potentiellement jusqu'au niveau des microgiciels pour BadUSB.

Autres vecteur potentiels: une partition avec un FS kivabien et l'automount (dernière fois que j'en ai entendu parler, HFS+ a mis 3 ans à corriger une faille), un binaire SUID, un .desktop aux petits oignons… Ou même juste un récepteur de clavier logitech dans le boitier, s'il est suffisamment grand.

Bref en étant parano accès physique sans DRM -> game over. En étant plus réaliste j'imagine que les adversaires que tu affrontes seraient suffisamment déroutés par bien moins que de la crypto ;-)

Personnellement j'utilise le chiffrement matériel intégré à mon SSD. Aucun coût en performances, simple à mettre en œuvre, une sécurité modérée mais suffisante par rapport à ce que j'imagine être mes attaquants.

En théorie, tu donne ton shell à quiconque contrôle un dossier depuis lequel tu ls. En pratique ça a peu de chance d'être exploité.

Crédible mais à mon avis ça sera pas l'OS mais le vendeur de nuage qui fournira cette API et qui le fera en espace utilisateur.

Pour être très concret, à l'heure d'aujourd'hui, la Google Drive fournit déjà la plus grosse partie (centralisé et proprio bien sûr): versionnement, mode déconnecté, synchronisation hors ligne partielle, recherche par tag et full text. C'est très loin d'être parfait, mais la tendance est à l'unification du stockage à travers les produits Google. On arrivera probablement à une convergence: l'espace est déjà partagé avec Gmail, Cloud Print et G+, j'imagine qu'on verra Google Play Music lisant la musique de Google Drive avant 2024.

De manière plus abstraite on a plein d'OS de nos jours, et les gens utilisent des navigateurs qui essaient de ne même pas exposer l'existence d'un OS et des liseuses pour lequel chaque constructeur prend une décision produit par produit.

En conséquence ce que tu décrit tend à être proposé au dessus de l'OS (avec quand même des fois l'aide de l'OS, CF Storage Access Framework pour Android qui présente Google Drive au même titre que la carte SD).

À toutes fins utiles, PlayN est développé par Google.

Plutôt que de flooder des serveurs et de gaspiller des ressources, va dans les préférences, désactive la publicité ciblée et désactive le ciblage.
Si tu veut donner des infos fausses, un bouton sur cette page te permet de décider ce Google pense de tes interêts.

Ça t'apportera pas d'avantages, en terme concrets tu fera juste perdre un pouillième à Google, et bien plus à toi même en équivalent temps. Mais si ça te donne l'impression de te battre ou d'aller à contre-courant, Google vaut bien des moulins à vent…

Ou une Asus Transformer tout simplement. Y'a emacs pour Android

Je ne savais pas, mais ça n'apparaît pas clairement dans ta source je trouve. Le Google Play est pas obligatoire non plus ?

Non, Google Play n'est pas obligatoire.

Donc tu peux utiliser ton android sans t'identifier autrement qu'avec le code SIM, comme un téléphone portable ordinaire ?

Oui. Tu n'auras pas accès au Play Store et tu devras installer tes APK toi même ou via un market alternatif.

[Les applis Google] ne font pas partie de AOSP mais elles doivent être installées sur le matériel pour que celui-ci puisse revendiquer la marque commerciale Android. Elles rendent obligatoire l'identification préalable de l'utilisateur au moyen d'un compte Google

À ma connaissance, c'est faux:

• L'usage de la marque est libre pour tous et ne requiert pas d'avoir les application [source].
• Avoir les applications Google, incluant le Play Store, sur le téléphone ne rends pas nécessaire de s'authentifier (il est possible de les désactiver ou juste de ne pas les utiliser).

L'usage de la marque Firefox et de l'interface utilisateur de Firefox OS, semble en revanche soumise à de stricts restrictions de partenariat ("any properties or assets associated specifically and directly with Firefox OS (e.g. the name, logo, user interface, etc.) are subject to partner licensing agreements") [source].

Merci de bien vouloir faire les corrections, notamment relatives au marketing idéologique de Firefox OS (qu'à titre personnel je trouve agaçant).

Pour les sauvegardes, je ne suis pas convaincu de l'utilité du pair à pair. Étant donné que tes donnés sont cryptées le fournisseur de stockage n'y a pas accès. Du coup avoir un système géré par une seule entité semble plus efficace car il peut ordonnancer les maintenances planifiées pour réduire le surcoût lié à la redondance, réduire les coûts liés au réseau, intervenir directement sur les nœuds en cas de problème…

En revanche il semble que Tarsnap soit lié à un fournisseur. Tu peut vouloir utiliser Duplicity qui en supporte de très nombreux. En choisissant ton fournisseur, tu module le risque à tes besoins avec tes contraintes de coût.

PS: Bien évidement, ceci est sous l'hypothèse à priori très réaliste que tu ai la possibilité de trouver un fournisseur de stockage (tu a accès à un moyen de paiement etc etc).

Tu n'a pas compris ce que disait l'auteur. La citation exacte est:

Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

Bien sûr que la glibc utilise ifdef pour se protéger (entre autre) contre les imports multiples.

La partie que seul Alibaba annonce, c'est que l'annulation était due à Google. Acer ne mentionne pas Google.

Une personne anonyme chez Alibaba dit qu'une personne anonyme de chez Acer leur aurait dit que…

Samsung maintient sa version d'Android et Google dit rien. ZTE (entre autres) a pas "l'expérience Google" (market &co) en Chine et Google dit rien…

En gros, si Acer vend du machin baba, google refuse de leur fournir android.

Google fournit Android à tous. De nombreux partenaires Android vendent des télphones sous d'autres OS. C'est juste Alibaba qui fait son FUD, voir Acer qui se débarasse d'un commercial ch*ant en lui repondant "on vous aime bien mais Google veux pas".

Tu aurais presque raison, a part le fait qu'ici l'info vient directement d'officiels d'Alibaba ET Acer qui sont cites anonymement

Non justement, c'est Alibaba qui dit que Acer a dit que… Pas Acer et Alibaba qui disent.

Bien sûr il y a des cas ou c'est nécessaire de gérer ça correctement (en embarqué par exemple). Mais pas ici.

Pour être plus précis: les cas en questions sont assez nombreux et dépendent du contexte d'éxécution. Quand tu programme tu ne sais souvent pas où ton code va finir après avoir été copié/collérefactoré vingt fois.

Le mieux que tu puisse faire c'est un truc du style [assert]

Pour donner un autre exemple sur un serveur ou dans une bibliothèque c'est vraiment pas ce qu'il y a de mieux à faire. Il faut tester et respectivement renvoyer une erreur au client (par ex indiquant de réessayer après un temps d'attente exponentiel en fonction du nombre d'erreurs) ou renvoyer à l'appelant un truc qui lui permet de faire ce qui convient.

Tout ce que tu fais c'est perdre des cycles à tester et rajoute du code qui prends de la place en cache

Et accessoirement te conformer à l'API.

C'est impossible de tester tout les cas possible d'échec de realloc. Et du code non testé à de forte chance de ne pas fonctionner

C'est pourtant facile d'injecter ce genre d'erreur.

Les systèmes d'exploitation moderne "overcommit" la mémoire

Ça dépends entre autres de l'humeur de ton sysadmin, et dans tout les cas c'est pas dans l'API.

Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.

Quand à toi, tu devrais questionner ce que tu lit ;-) Augmenter la taille des buffers mange de la RAM, pas du CPU. Ou alors il y a une astuce mais c'est pas trivial et certainement pas juste écrit dans le journal.

Sinon, fondamentalement, ça semble être un problème d’ordonnanceur plus que noyau versus utilisateur (j'ai pas de chiffres mais franchement quelques changements de contexte ça semble super bon marché comparé à être préempté au mauvais moment). Et pour paraphraser l'auteur de Jack, ça fait longtemps qu'on fait plus le boulot dans les bottom halves des gestionaires d’interruptions. Je comprendrais que le gars défende un ou deux syscalls supplémentaire pour ordonner des trucs spécifique au scheduler (encore qu'à mon avis y'a déjà ce qu'il faut) mais là… j'ai du mal à interpréter son choix de conception autrement que comme une envie de garder l'API OSS en y rajoutant les fonctions modernes.
Mais je suis peut être mauvaise langue. On verra bien où ça nous mène.

Il y a pleins d'autres manières de prendre l'empreinte d'un téléphone (adresse MAC, stocker un identifiant dans une mémoire partagée…). Amha, l'intention d'Apple est simplement d'empêcher l'erreur fréquente qui consiste à confondre cet ID pour un ID utilisateur afin d'éviter les problème lors des reventes (récement il y a eu le cas d'un jeu qui utilisait cet ID comme « secret » pour permettre d'accéder à son compte sans mot de passe).

C'est une question de génie logiciel et pas d'anonymat.

Pas selon www.fauxpensource.org qui, citant l'inventeur du terme, indique « La description d'un logiciel qui prétends être open source, mais ne présente pas l'une des libertés requises par la Définition de l'Open Source » ("A description of software that claims to be open source, but lacks the full freedoms required by the Open Source Definition.") .

À nouveau, tu peux te battre pour un développement collaboratif , sans novlangue et sans tordre la définition de ce qu'est un logiciel libre.

C'est pas du «fauxpensource». Le code est libre. Simplement le développement n'est pas collaboratif.
Si Apple libérait le code de la dernière version d'IOs, et les bootloaders des téléphones, si MS libérait le code de Windows, même un an après sa sortie, nous applaudirions cet acte courageux. Même si ils n'ouvraient pas un accès public à leur repository. Google a eu ce courage. Le code publié est libre.

Tu peux te battre pour un développement collaboratif , sans novlangue et sans tordre la définition de ce qu'est un logiciel libre.

Comme quand tu installe «une distribution Linux» en fait. Finalement Android c'est pas assez ouvert (développement non collaboratif) mais en fait ça l'est trop (les constructeurs font ce qu'ils veulent du code)… Va falloir se décider.

La version Android 3.x Honeycomb n'ayant pas été publiée en opensource

Elle a été publiée, simplement ça n'a pas été tagué dans le git.