groumly a écrit 3288 commentaires

Non. Aucune sécurité n'est fiable a 100%.
Un système biométrique bien pensé comme TouchID (et j'imagine que dans le monde android il y en a aussi) est un énorme pas en avant d'un point de vue sécurité.

1- je peux trouver au moins un scénario où le déverrouillage par empreinte digitale est le moins fiable : je t'invites au bar, je te paye tournées sur tournées jusqu'à ce que tu t'écroule ivre mort. Et là, je peux tranquillou prendre ton téléphone, le déverrouiller avec ton doigt, changer les réglages de sécurités et me barrer avec. Ou plus rapide et moins coûteux, je peux t'assomer.
2- face à l'autorité judiciaire, tu as le droit de ne pas donner le mot de passe de ton téléphone ("droit à ne pas s'auto-incriminer"). Par contre, tu ne peux pas refuser le prélèvement de tes empreintes digitales (c'est un délit). Et une fois qu'ils ont ton empreinte, je ne pense pas qu'il soit compliqué de déverrouiller le téléphone.

C’est pour ça qu’ios prévoit de devoir retaper son mot de passe à chaque changement de sécurité, trash les clés touchid après 24 heures sans utilisation et offre un moyen rapide thrasher les clés touchid (5 pression rapides sur le lock button).

Quand on arrête 2 secondes les raisonnements à la mord moi le noeud, on se rend compte que 99% des gens ne vont pas se faire découper le doigt pour accéder au téléphone. Que si t’es un cible suffisamment privilégiée pour subir une attaque physique créée rien que pour toi, c’est pas un passcode qui va te sauver.
Et qu’au final, les lecteurs d’empreintes permettent de tout simplement faire utiliser un passcode a des gens qui autrement n’en aurait pas.

c'est un peu normal de voir n'importe qui débarquer et piller ton bateau, c'est la conséquence de tes choix.

Je suis à peu près certain que les conventions internationales interdisent la piraterie a leurs ressortissants, memes en eaux internationales. Donc non, rien de normal, et aucune conséquence d’un quelconque choix.

A moins que tu trouves normal de tuer son voisin.

Résultat : au premier essai, le téléphone s’est déverrouillé. Bon, en essayant une deuxième fois de suite, ça n’a pas fonctionné, mais une fois, c’est déjà une fois de trop 

Ben voyons. Des centaines de millions de touchid vendus, un marketing dément sur le côté sécurité, un paquet de gens qui s’y intéressent parce que forcément, cible de haut profil, et paf, pastèque, comme par hasard ou miracle, ça arrive à ton collègue.

Et surtout, surtout, l’empreinte te permet de passer d’un code pin à 10000 combinaisons à une passphrase vachement plus longue, en te permettant de ne pas avoir à la taper 150 fois par jours.

Vérifier qu'il s'agit bien d'un nombre avant d'essayer d'utiliser %

Ola, tu vas bien vite en besogne.
C’est quoi un nombre? Parce que isOdd(“13”) retourne true.
C’est pas vraiment un overflow ce qu’il vérifie ensuite, c’est plutôt de savoir si le nombre est un entier représentable sans approximation en ieee machin.parce que évidemment, javascript n’a pas de type entier.

Plus je regarde ce code, et plus je suis fasciné.
Ca dépend de is-number qui indique si la valeur est un nombre. Ou une chaîne qui représente un nombre (enfin, certains encodage d’un nombre, lesquels on sait pas trop).

Mais il check aussi pour isInteger, et ensuite pour isSafeInteger.
Naïvement, j’aurais pensé qu’un safe integer est aussi un integer, et qu’un integer est aussi un number, et donc pourquoi se faire chier a vérifier les trois si le troisième inclu les 2 autres. Mais après tout c’est javascript, et y’a potentiellement une bonne raison à ce merdier.

L’autre truc délirant c’est des choses comme is-thirteen. A première vue, ça l’air d’une blague de potache, mais comme ces couillons ont uploaded leur paquet sur npm, et que la communauté marche sur la tête, vu de l’exterieur on en arrive à se demander si c’est vraiment une blague. Ou si la blague est meta, et qu’en fait, la blague c’est que la communauté est si immature qu’elle upload des paquets à la con de ce genre sur npm.

donc intéressant même pour les non intéressés par nodejs

Oui et non.
Disons que la plupart des autres communautés ont largement résolu ce problème avant de passer à l’echelle comme node/npm l’a fait:

• langage suffisamment expressif avec une librairie standard suffisamment fournie qui permet d’éviter le grand n’importe quoi des femto libraries du javascript (une ligne == un framework), avec des blagues du genre “isOdd”, parce que croit le ou non, c’est pas évident de savoir si un chiffre est impair en JavaScript
• une communauté plus mûre qui se stabilise sur une poignée de framework applicatifs, plutôt que la foire a l’empoigne du monde js et son constant va et vient de nouveaux framework et réécriture d’ancien framework en mode “ce coup ci, c’est sur, on évite tous les bugs par design”
• des utilisateurs qui réfléchissent plus de 30 secondes avant d’ajouter une nouvelle dépendance (ou plutôt, plusieurs douzaines de dépendances, cf probleme femto libraries) et balancer en production, le tout sans bien évidemment vérifier qui est derrière ce qu’ils utilisent,
• outillage (et équipes en charge de l’infra) un peu plus mûr (signatures de paquets etc). Ça, ça évite notamment ce qu’il s’est passé ici, à savoir refourguer un projet connu et utilisé à un illustre inconnu sous prétexte de “j’ai pas le temps de maintenir ça”

En gros, même si le problème pourrait techniquement exister ailleurs, la culture du n’importe quoi qui prévaut dans le monde javascript couplée à un langage pourri sans stdlib et une communauté incapable d’apprendre des erreurs des autres (ou même simplement de regarder l’existanr) fait que node.js et npm, c’est comme regarder un train dérailler au ralenti. Tout le monde comprend ce qu’il se passe, personne ne peut rien y faire et ceux qui sont dans le train ont pas la moindre idée de ce qu’il se passe.

Effectivement, comme tu ne tapes pas le type de retour

Inference de type n'implique pas de ne pas être explicite sur les types de retour des fonctions. Et surtout, ca empêche pas de nommer ses fonctions décemment pour qu'on comprendre ce qu'elle fait et ce qu'elle retourne.
Ca veut juste dire que le compilateur n'a pas forcement besoin que tu explicites le type dans certains contextes. En pratique, être implicite sur les types de retour des fonctions, c'est une assez mauvaise pratique: ca force a lire l'implementation pour savoir ce qui est retourne, et si le language supporte des types avancés, genre union ou autres, ca peut t'emmener loin quand tu debugges.

Typiquement, ca c'est bien:

/// C'est assez clair ici que name() retourne une string, meme sans regarder le type de retour. Non pas que ca soit important ici, mais pour 
/// le code appelant, on devine aisément que le nom va être une String
public func name() -> String {
    // implementation
}

/// comme dit au dessus, c'est assez evident que name est une String, donc pas la peine de se répéter
let a = name().lowercased()

Et typiquement ca c'est mal:

/// Nom de function alakon, bon courage pour savoir ce que c'est cense faire
public func foo() {
    // implementation, de preference bien longue avec des if imbriqués et des early return
}

/// bonne fete des morts pour deviner ce qu'il se passe ici.
let a = foo()

En gros, les perfs s’ecroulent des que tu as plus de données que tu as de ram dispo.
En parallèle, si ton data set tient en ram, soit c’est pas du big data, soit t’es un milliardaire excentrique qui peut se permettre plusieurs teras de ram juste pour ton cluster mongo.

La question est donc, pourquoi je devrais passer par osdisc plutôt que par un autre fabricant de DVDs?

Non, la question c’est pourquoi tu viens poser la question sur linuxfr plutôt que d’envoyer un mail aux gars d’osdisc.

Apple ne presse plus de dvds pour macOS.
Même avec un mac tout neuf ya pas de disques dans la boîte. Ya une recovery partition sur le disque, et le reste se fait 100% en ligne.

On est pas vraiment d’accord, non.
L’article de billou s’applique à du soft pur, genre Windows. Ms peut vendre 1 licence ou 1000000 de licences Windows, le coût est fixe, le bénéfice variable.
Leur boulot s’arrete au moment où la première copie est produite.

Distribuer de la musique ou de la vidéo, c’est pas vendre du soft, c’est du service pur et dur.
Leur boulot s’arrête pas au moment où la première copie est produite. Au contraire, c’est la ou leur boulot commence. Quoiqu’il arrive, leur coût de distribution va croître linéairement avec leur nombre de client.

on n'a plus de coût de production après le premier exemplaire, diffuser à 10 ou 100.000 c'est pareil ou presque (le presque est négligeable).

Mouaif. Va demander aux mecs de chez Netflix si le coût est négligeable.
Servir 10 copies c’est pas la même chose que d’en servir 100 000, et 100 000 c’est pas la même chose que 1 000 000, et 1 000 000 c’est pas la même chose que 100 000 000. Les problems de distribution à cette échelle deviennent sacrément couillus à gérer, encore plus si tu veux le faire de façon économiquement viable.

Le coût d’acheminer la copie jusqu’à chez toi, il est loin d’être nul. Perso, j’imagine que la facture aws de Netflix est dans les 7 à 8 chiffres par mois. Et ça compte pas l’armee d’ingenieurs pour faire marcher le bouzin.
Ajoute tout ça ensemble, on est au dessus du dollar par utilisateur/an, voir plus. Quand on a 130 millions d’utilisateurs, ben ca fait plus de 130 millions de dollars par an. Et le coût est linéaire avec le nombre d’utilisateurs, pas constant.

Alors, ok, ça passe à l’echelle vachement mieux que de devoir gérer des centaines de millions de dvd, mais quand même. C’est pas une broutille, et c’est clairement pas négligeable.

Certains le sont, oui.

Donc tu FUD / trolles. C'est tout.

Bah, laisses le tranquille 2 minutes.
Il a passé les 15 dernières années à troller à fond les ballons en mode “microchiotte capusaypalibre”, tout ça pour les retrouver du côté des gentils.
Ca va lui coûter une blinde en thérapie pour s’en remettre, laisse le profiter de ses derniers trolls.

Tu ne vois pas la différence entre :
ZX81, Apple II, Thomson TO7 et MO5, Commodore VIC-20, Oric Atmos, Goupil, Amstrad CPC, Apple Macintosh, Atari ST, Amiga 500, et j'en passe des dizaines d'autres.
Et ce qui existe quelques années après l'arrivée des x86, avec une poignée d'architectures.
Et ce qui arrive vers 2006/2007 avec la fin des séries SPARC et Apple PPC ?

La difference que je vois, c'est que les interfaces materielles sont vachement plus standardisées, oui.
Mais je vois pas ce que ca a avoir avec l'assertion originale "apple ne fabrique plus de materiel", sous entendu avant ils en fabriquaient.
Apple n'a rien "fabrique" dans l'apple 2 et l'original mac. C'était de l'assemblage de pieces achetées a droite a gauche. Un assemblage très complique et très bien fini, certes, mais un assemblage quand meme.

Pour l'Apple 1 et 2, le Macintosh, Apple fabriquait du matériel.

Ok, donc je vais devoir demander plus précisément du coup.
Ils fabriquaient quoi exactement comme materiel en 1984?

et tout les éléments matériels sont les mêmes que dans à peu près n'importe quel autre smartphone.

Mais bordel, tu lit ce qui a été écrit au dessus? Apple désigne ses propres CPU dans les iMachins. Le SoC est conçu in house. Secure Enclave est conçu in house (et a atterit dans les mac au passage, sous le petit nom de T2).
Les Mx (detection de mouvement) est conçu in house.
Les SoC de la montre sont conçus in house.
Les Wx dans leurs écouteurs sont conçus in house aussi.

Mais le découplage reste très fort, on a les mêmes technos, les mêmes composants, les mêmes contraintes d'assemblage, entre un Wiko et un iPhone. Ce sont tous des SoC ARM.

Il faut te le dire comment? Dire que l'iPhone a les meme composants qu'un Wiko, c'est comme dire qu'un CPU AMD est le meme qu'un i7, et qu'AMD ne fait que revendre des pieces qu'ils ne fabriquent pas.
APPLE DESIGN SES PROPRES CPUS POUR IPHONE, BORDEL!

Le seul truc qui vient de chez Arm dans l'A12, c'est l'api publique du CPU: instruction set, nombre et noms des registres, l'interface binaire, ce genre de choses. Meme le GPU est conçu in house.
Ca te viendrais a l'esprit de dire que Wine n'écrit pas de soft et se contente d'utiliser du code standard, tout ca parce qu'ils reimplementent l'api windows?

Franchement, faut pas me dire qu'Apple vend du matériel, ça n'a aucun sens…

Oui, alors la, ca se discute très largement. Les gens achètent un iPhone a la fois pour le hard et le soft.
Le hard, c'est des trucs genre FaceID ou TouchID (qui n'existent nulle part ailleurs, parce qu'Apple a acheté la boite qui fait le lecteur d'empreinte, et parce que Secure Enclave est un chip designé in house). C'est des trucs genre une batterie qui tient longtemps, ou des écrans OLED de qualité (les deux derniers ne sont effectivement pas concus ou fabrique par eux, certes, en attendant tu les trouves pas ailleurs).

J'oubliais:

Extrait de ton lien :

Faudrait ptetre voir a lire plus loin que la section "early series" qui remonte a 2009.

2-3 paragraphes plus loin:

They are designed by Apple, and manufactured by Samsung and TSMC.

Apple n'a jamais fait de smartphone avec autre chose que de l'ARM.

Va falloir te renseigner un peu sur ce que "ARM Based" veut dire. Ca utilise l'instruction set ARM, c'est a peu près tout.

Oui ! Et ça a en gros commencé avec l'arrivée de l'IBM-PC et surtout des compatibles PC.

???
Et ils faisaient quoi avant les constructeurs, ils désignaient leurs propres CPU?
Ou ils faisaient comme apple avec l'apple II, il prenaient des pieces a droite a gauche et les assemblaient ensemble?

Apple est maintenant client d'Intel, de TSMC

Juste pour info, TSMC est un fondeur "pure-play". Dit autrement il ne font QUE de la fonderie. Pas de chip design. Leur business modele c'est de faire exclusivement la fabrication des designs des autres, et de ne pas concurrencer leurs clients avec leurs propres designs. https://en.wikipedia.org/wiki/Foundry_model#Dedicated_foundry
Donc en gros, t'es en train de dire que oui, Apple étant client TSMC, apple a ses propres designs a eux que personne d'autre n'a.

et leur objectif premier n'est pas de vendre du matériel

Et c'est quoi leur objectif premier alors?
La plupart de leur soft est gratuit, et ils font 30 milliards par trimestre sur l'iPhone seul. Ok, ils cherchent a developer leur division services, mais faut arrêter de raconter n'importe quoi 5 minutes, apple est principalement une boite de hard. Ils vivent principalement sur le materiel qu'ils vendent.

Tu peux te fabriquer exactement le même matériel que dans les produits d'Apple, même CPU, même GPU, mêmes branchements, même dalle graphique, etc, sans rien demander à Apple.

Absolument pas, non. Les Ax, Mx, Sx, Tx, Secure Enclave, TouchId, les machins dans leurs écouteurs sont des chips conçus et désignés par Apple. Sur une base ARM, certes, mais c'est comme dire qu'un cpu AMD peut être acheté chez Intel parce que c'est une base x86.
C'est a des lieux de ce qu'il se passe dans le monde android ou tout le monde achète littéralement le meme SoC de chez Qualcomm.

À comprendre bien sûr, un Mac c'est un packaging au dessus de composants standards, et de normes construites sur les évolutions de l'IBM-PC et des puces Intel, donc pas de matériel en provenance d'Apple, juste la boîte en aluminium.

Oui, enfin à ce compte là tout le monde a “arrêté de faire du matériel”, ou plutôt personne n’a commencé à en faire. 100% des constructeurs de pc utilisent des composants standards si tu va par la. A la rigueur sun, ibm avec leurs mainframes, et encore.
Apple mettait du ppc dans ses mac avant de faire de l’intel, et du 68k avant ça. Ils ont décollé de façon significative justement avec l’iphone qui a des chips in house depuis 2011…

Et ce n'est pas tellement différent avec les iPhone, pas de différence fondamentale avec n'importe quel autre smartphone : de l'ARM, de l'USB, des composants choisis a priori pour leur qualité, et un prix multiplié par 5.

Oui, alors, bon, faut ptetre arrêter de dire n’importe quoi des fois.
https://en.m.wikipedia.org/wiki/Apple-designed_processors

Apple design beaucoup de chips. Le soc iPhone/iPad/watch, Secure Enclave, les m-chips, les t-chips. Idems pour les écouteurs sans fils, ou encore Touch ID. Je sais pas ce qu’il te faut de plus.

• macOS arrive a faire la correction automatique sur 2 langues, mais ca marche pas a a 100% et des fois ca donne des trucs chelou, genre fin corrigé en find,
• pour le reste, j'ai passe l'essentiel de ma carrière aux US, donc je connais pas le jargon franco-français, désolé.

Si on prend les faits et rien que les faits, un utilisateur qui souhaite recevoir et envoyer des mails n'a pas des besoins beaucoup plus raffinés qu'il y a 10 ou 15 ans, et pourtant, même ce genre d'appli (pas toutes bien sûr) prend désormais un temps fou rien qu'à se lancer.

Ca se discute. Autocompletion des noms dans l'email (genre de @mention que outlook fait, très pratique), gestion du carnet d'addrese, recherche avancée et instantanée, gestions des tags, gestions des fils, detections des mailings lists (e.g. le bandeau "this mail was sent from a mailing list, click here to unsuscribe" que Mail.app ajoute au dessus de certains mails pour éviter d'avoir a chercher le lien pour se desinscire). Ca c'est juste Mail.app ces 10 dernières annees, qui est franchement super light niveau features. Outlook en fait beaucoup beaucoup plus.
La gestion du spam devient de plus en plus raffinée (meme si elle est effectivement souvent faite cote serveur).

De plus, en lisant ton message, j'ai l'impression que tu nous dépeins la situation chez toi au niveau de l'ingénierie logicielle qui semble assez saine, mais je ne sais pas ce qui te conduit à généraliser.

Je retourne la question a l'auteur, qu'est ce qui le conduit a généraliser comme il le fait?
Mon constat se base sur ce qui se fait dans mon industrie (a savoir, les moyens/gros du monde des applis mobile grand public). Je suis au premier rang de ce milieu, et je sais très bien ce que fait la concurrence (grosso modo la meme chose que nous, grosso modo en meme temps).

La performance n'est pas la priorité absolue, c'est sur. Mais on garde un oeil dessus (littéralement, on a des dashboards divers et varies pour le réseau et les perfs clients. On sait quand le business commence a souffrir a cause des perfs, et pour les optimizations, ben c'est un compromis temps passe/argent gagne, tout simplement). C'était pareil ya 10 ans (sauf qu'a l'époque, on mesurait vachement moins, alors on savait pas ou mettre le curseur niveau perf ¯_(ツ)_/¯).

Ya des points noirs, oui, clairement. Le web est probablement vraiment a la traine avec ses montagnes de JS de partout. Mais en fait non. Ces pages qui font dresser les cheveux sur la tete a être plus grosses que win95, quand tu regardes de plus près, la vaste majorité du temps, ca vient de boites dont le coeur de metier n'est pas la technologie.
Typiquement, les sites de news. Leur département technologie est généralement considéré comme un mal nécessaire (a l'inverse d'une boite genre airbnb ou l'ingénierie est au coeur de la boite). Ils ont pas le pouvoir de corriger ce genre de choses (ou n'arrivent pas a attirer les ingénieurs qui pourraient tirer la sonnette d'alarme).

Clairement tout n'est pas parfait, mais prétendre "tout est plus gros et plus lent, sans aucune raison, tout fout l'camp ma bonne dame, c'était mieux a vent", c'est un peu gros quand meme.

C'est pas ce dont parle l'article, visiblement.
windows 95 et 10, les pages web et leurs pubs, android, gmail. Il parle pas de l'industrie aéronautique, mais du milieu grand public.

Alors ça, tu peux oublier. Il y a une quantité de softs où tu te demandes si la procédure d'installation a été testée, si la compilation par un tiers a été testée (le fameux "ça compile chez moi")…

Ben voyaons.
Ya 10 ans, le concept de CI était encore nouveau, les procedures de test/build étaient pour la plupart manuelles. Spring et la dependency injection était un truc révolutionnaire (et comme par hasard, vu d'un mauvais oeil par les cetaimieuavan et les onatoujourfaitcommssa).
Les frameworks de test sont très très loin de ce qu'on avait a l'époque.
Le "spolsky test" était encore de rigueur pour évaluer une boite. J'ai eu un candidat junior qui me l'a pose récemment, ca m'a fait bizarre de me faire demander "est ce que vous utilisez un VCS?".

Yavait autant de code pas testé ya 10 ans que maintenant (si ce n'est plus, comparativement). C'est juste que ce code n'existe plus maintenant (ou a été refactoré depuis).

Donc non, la qualité a pas empiré avec le temps. Elle est passe d'un concept bizarre (tu devrais être content que ca boote, te plains pas!) a une pratique mal comprise et souvent mal voire pas appliquée.

Bref c'est assez représentatif de tout l'article, un biais et une exagération au ridicule qui dessert le problème et qui ne convaincra que les convaincus.

Clairement.
Il a l'air de complement ignorer le fait que le software en fait exponentiellement plus a chaque release/amelioration du hard.
Alors, ouais, windows 95 était plus petit qu'une page web, mais il était aussi plutôt basique niveau fonctionalités, crashait a droite a gauche, fallait configurer les irq et dma pour sa carte son a la main (en fait non, mais justement, les mecs qui venaient du dos se plaignaient qu'il fallait un cd-rom entier pour win 95, vous vous rendez compte).

C'est très facile d'oublier a quel point le software d'il ya 10 ans était primitif. Et ya 10 ans, on avait la meme discussion, et on avait oublie a quel point le software d'il ya 20 ans est primitif.

Perso, je bosse dans les applis mobile. En 6 ans, le code de mon appli a grossi grosso modo 5 ou 6x. On a aussi streamline beaucoup de choses (erreurs de jeunesse), ce qui veut dire qu'en pratique, le code est bien 10x plus gros que la version streamlinée d'il ya 6 ans.
On en fait beaucoup plus pour nos utilisateurs. L'appli est vachement plus finie. Des petites touches qui ont l'air de pas grand chose mais simplifient énormément la vie des gens finissent par prendre énormément de code (J'en ai une en tête qui a l'air de rien, se manifeste par juste une petite popup qui prend presque autant de code que la feature qu'elle complemente et nous a prit 1 mois a ecrire).

On en fait beaucoup plus pour nous. On a corrige des bugs. plein. Ca finit par faire plein de cas si ceci ou cela, des refactoring. On se rend compte que le problème est beaucoup plus complexe qu'on le pensait, et forcement, on en fait plus.
On a de l'ab testing de partout. Absolument tout est ab teste. Ca veut dire 2 fois plus de code pour chaque changement (control + variante).
On a de l'analytics de partout (produit, pas marketing). Ca rend notre vie vachement plus simple: on peut decider beaucoup plus vite de si une feature marche, on a un contrôle beaucoup plus find sur le rollout des features, on a plus de visibilité sur ce que les gens font vraiment, ce qui aide énormément a decider la direction a donner au produit.

Tout est plus gros, et consomme plus de resources. Mais tout fait aussi beaucoup plus de choses. c'est aussi con que de dire "ma Clio fait 2 fois le poids de ma deuch, l'industrie auto deconne a plein tubes".
Et ta deuch, pour te rafraichir l'été, fallait ouvrir la fenêtre et accélérer pour faire du vent. Quand t'avais un accident, tu crevais dans un tas de ferraille. Ca a prit 50 ans a l'industrie automobile pour optimizer ces problèmes, sur un produit qui a un scope très précis et limite.
Tu peux pas comparer ca a quelque chose comme du soft pur dont le scope n'est limite que par l'imagination.

Le problème qu'il a est avec la philosophie "un produit évolue constamment et très rapidement sinon il est mort". Je veux pas dire, mais ca fait un bail que ce débat est réglé. Ceux qui pense que les evolutions doivent être lente ne sont plus la pour en parler.

La personne qui a écrit cette page n’est clairement pas ouverte à la discussion.
Dans son opinion, Apple == caca, point à la ligne.