Antoine a écrit 5722 commentaires

Mais des choix faits sur les CPU des années 70 sont dans les architectures actuelles.

Lesquels ? Entre les caractéristiques d'implémentation d'un 8086 et celles d'un processeur Intel ou AMD d'aujourd'hui, il n'y presque rien en commun à part la compatibilité avec une variante obsolète du jeu d'instructions (puisque le mode réel, et même le mode 16 bits protégé ne sont plus utilisés).

"Hardware supported rings were among the most revolutionary concepts introduced by the Multics operating system, a highly secure predecessor of today's UNIX family of operating systems."

Dire que Multics était hautement sécurisé relève de la spéculation, car la sécurité informatique en tant que discipline n'existait pas à l'époque. Je rappelle que le premier ver Internet date de la fin des années 80.

Si un hoax concernant la corrélation QI / propagation de hoax pouvait aider à arrêter la propagation des hoax, il ne serait pas inutile.

Pour ce qui est du modèle MVC, personnellement je fais des applications 3 tiers avec JSF pour la présentation, des objets Java injectés dans mes Managed Beans pour la couche métier et Hibernate pour la persistance (toujours pareil des DAO injectés dans la couche métier).

On ne m'avait pas dit que la partie de business loto avait commencé.

Les protections ne sont pas les mêmes: les segments fournissent une protection à l'intérieur même d'un processus, c'est un peu comme si chaque tableau était dans son propre espace virtuel.

Oui, bien sûr, sauf qu'il n'y a pas assez de registres de segments pour cela, il faut donc passer son temps à recharger un segment un ou l'autre, ce qui est certainement peu efficace.

Enfin bon, si on veut absolument éviter les débordements de tableaux, on peut utiliser des structures de données adaptées au lieu d'imaginer des bidouilles architecturales. Ce n'est pas un hasard si ces problèmes ne se posent quasiment qu'en C.

Lis le lien de dominique dechamps sur multics, ça peut peut-être t'aider.

Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles.

ça te gonfles pas le lost+found toi ? Avec au mieux un gros bordel dedans, au pire un truc tout pété ?

Ça fait des années que je n'ai pas vu un système de fichiers cassé, donc c'est difficile de répondre.

Fsck ultra-rapide->incohérent_à_un_endroit->renvoi_snapshot_de_cet_endroit, ça serait mieux, non ? et je pari dessus.

Je n'ai pas compris. S'il y a un problème au fsck, tu remplaces silencieusement par un vieux snapshot?
Et si le snapshot lui-même fait partie des données corrompues ?

Je ne vois pas le rapport entre une fonctionnalité de vérification du système de fichiers et une fonctionnalité de production d'instantanés.
(les instantanés eux-mêmes devraient être vérifiés par fsck, d'ailleurs)

Si l'utilisateur est capable de reset en plein fsck sans systemd, il est fort propable qu'il le fasse avec un autre init.

Encore faut-il savoir qu'un fsck est en cours quand le système a l'air bloqué.

Tout était là pour faire de la sécurité: il n'y a plus de segments en mode 64bit sur les x86, comme les logiciels n'utilisaient pas la segmentation, AMD l'a retirer du jeux d'instruction pour le mode 64 bit :-(

Je ne vois pas le rapport entre les segments et la sécurité. Le genre de protection que les segments apportent, c'est le système de pagination qui les apporte aujourd'hui, c'est tout.

Est ce qu'on pourrait se passer de films qui révolutionnent les effets spéciaux ? Complètement ?

Moi je m'en passe très bien :)

Penser qu'il faut forcément des montagnes de fric pour impressionner le spectateur implique des choix techniques et esthétiques assez balisés. Même en restant dans la science-fiction, une des œuvres mythiques du genre, la Jetée a dû être faite avec un budget dérisoire (peut-être un SMIC ou deux ?) : un film presqu'entièrement en images fixes, où le seul effet spécial est justement le surgissement d'une séquence animée.

Et si ce n'est pas le cas, est ce qu'il faut considérer comme normal le fait de ne plus avoir l'évolution qu'on a connu précédemment ?

Je ne sais pas si c'est normal mais pour moi ce serait bienvenu.
Voir des bidules synthétiques toujours mieux rendus, ça m'impressionnait quand j'avais cinq ans, aujourd'hui j'ai d'autres critères.

Mais ne pense pas que la réponse magique du revenu universel soit sans failles.

Rien n'est sans faille ni magique, mais c'est bien pour cela qu'il serait dommage de se contenter du système actuel.

Il reste aussi le CNC qui - soit disant - est massivement financé par le racket^W^W la taxe SACEM^W^W redevance sur la copie privée.

Le CNC est parfaitement finançable par autre chose qu'une taxe sur la copie privée. Prétendre qu'il faut une taxe spécifique à la culture (à cause des méchants pirates (tm)) est une démagogie honteuse, et permet d'éviter de débattre les questions importantes, comme le bien-fondé des niches fiscales et l'allocation des recettes.

Sur un service où les temps de réponse sont importants, on écrit pas du code qui arrive à faire tellement d'I/O d'un coup qu'il bloque toutes les autres requêtes pendant une seconde, sur un serveur qui était pourtant sans aucune charge

On peut aussi se forcer à utiliser un Z80 pour prouver qu'on est capable d'écrire du code optimisé, mais en pratique, si ajouter une fraction de salaire en matériel permet de régler un problème de performance, je ne vois pas de raison de se priver. Il faut garder à l'esprit que bien souvent le matériel informatique coûte moins cher que l'optimisation d'un logiciel dédié.

Tu es certain que ton consommateur d'OpenID reconnaît correctement StartSSL? :p

Si Firefox et curl le reconnaissent, ça devrait aller, non ?

C'est probablement un peu tard, mais "on" (c'est à dire les gens qui se sont un peu investis dans OpenID) aurait du essayer de mettre en place une matrice de compatibilité entre solutions et/ou services.

Hé, je ne suis pas un expert, mais à ce que j'en ai vu, beaucoup de gens (qui implémentent des producteurs ou consommateurs d'identités OpenID) se sont plaints de l'absence de suite de tests officielle.

soit le consommateur reconnaît le certificat du fournisseur d'identité, soit pas. Dans ce second cas, effectivement, ça pose souci (notamment pour tous les autosignés et CA privées/peu répandues). Ne serait-ce pas ça qui te pose problème?

Non, je me suis fait chier à prendre un certificat chez StartSSL précisément pour l'éviter :-)

Ceci dit HTTPS ne semble pas être le seul problème ; parmi les sites qui refusent mon adresse OpenID, j'en vois qui tapent bien sur le serveur (des requêtes apparaissent dans les logs), mais qui ne vont pas plus loin et refusent l'authentification.

Les lois liées à la location immobilière sont tellement spécifiques que ça n'a pas grand intérêt de faire de telles analogies, AMHA.

Elle révèle surtout qu'il y a des gens qui portent encore au QI une importance, y compris parmi les rédacteurs de dépêches Linuxfr. Bientôt une analyse graphologique sur la personnalité des utilisateurs Windows ?

Mh, tu cherchais un service OpenID qui fonctionne, pas un service OpenID qui contourne les bugs de certains sites :]

Certes, SimpleID n'est probablement pas à blâmer, mais ça veut dire qu'OpenID en tant que standard a encore du chemin à faire.

Tu n'as pas essayé en rendant ton URL OpenID disponible via HTTP?

Si le service OpenID lui-même tourne sur une URL HTTPS, je ne suis pas sûr que ça fasse une différence, si ?

Donc le cache est toujours saturé. Et lorsque le cache est saturé, pour écrire dans le cache il faut d'abord qu'une partie des données en cache soient réellement écrites sur le disque.

Et donc au bout de quelques secondes ou minutes d'utilisation, on obtient les mêmes performances qu'un contrôleur sans cache, non ?

Si tu as un débit d'écriture constant au fil du temps, oui. Enfin, il me semble que la plupart des machines ne sont pas utilisées sur ce principe. Il y a typiquement des périodes sans aucune charge et des pics de charge temporaire. Il y a aussi le fait que sur beaucoup de services (du genre HTTP), les temps de réponse sont importants pour assurer une bonne qualité, donc il faut éviter que des écritures sur le système de fichier puissent bloquer pendant une seconde si d'autres requêtes sont en cours simultanément.

Les tests unitaires, c'est certes tres pratique, mais leur gros probleme, c'est qu'ils sont justement unitaires.

Tu peux ajouter des tests fonctionnels, ce n'est pas exclusif.

J'ai du mal a comprendre la logique en fait, une approche permet de trouver des bugs a coup sur tres tot, avant meme que le dev ait commite.
Quelle est le probleme avec au juste?

Dans l'absolu, aucun. Le problème c'est avec la version Java de cette approche :

• il y a une phase de compilation explicite
• la verbosité du langage est largement augmentée (noms d'identifiants à rallonge, pas d'inférence de type...)

Je suis bien d'accord que ce n'est pas inhérent à l'approche décrite, mais on parle bien de Java, pas d'un langage idéal.

Ca remplace pas la doc, mais ca permet de comprendre plus facilement (universal_newline est achement plus comprehensible que u).

open() étant une fonction super utilisée, je ne vois pas pourquoi le programmeur lambda ne finirait pas par reconnaître les trois ou quatre options d'ouverture possibles.

Encore une fois, c'est comme ls. Tu as le droit de préférer listDirectoryContents --verbose-listing, mais je crois que la plupart voudront continuer à utiliser ls -l.

Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?

Si, c'est naïf (ou, plus exactement, ce qui est naïf est de croire que 100% de couverture permet de détecter tous les bugs). N'empêche que les tests permettent de détecter et de prévenir des bugs beaucoup plus "intéressants" (lire : tordus) que la compilation.

Bon, j'ai installé et configuré SimpleID (c'est un peu moins facile que je ne l'espérais), mais mon OpenID merde avec un tiers des sites que j'ai essayés... Déjà un certain nombre d'entre eux refusent l'URL en HTTPS !

Faut se trimbaler avec beaucoup de crayons pour la coloration syntaxique, et j'ai entendu dire que le rechercher/remplacer n'était pas très au point.

Certes, mais est-ce qu'un Linux fonctionne bien dessus ?

Sans ventilateur, l'Atom ? Tu es sûr ?

man SRV, utilisé par Jabber et SIP entre autres.

M'enfin, j'éviterais d'utiliser SIP comme exemple d'un protocole bien fichu. Dans le genre usine à gaz inimplémentable proprement, ils ont fait fort.

Tu connais un langage objet qui n'a pas d'appel de méthode sur un objet parce que dans le commentaire précédent tu affirmais que tout les langages objets ne l'ont pas.

Non, relis. Je veux bien croire que mes messages sont concis, mais je n'ai pas dit cela.

Après oui savoir comment sa fonctionne est important je n'ai pas dis le contraire.

Tu as dit "tu nous parle de détail d'implémentation", ce qui est faux. Maintenant je n'ai pas envie de refaire le débat, donc si tu n'as rien à ajouter, restons-en là.

Ça n'évolueras jamais ? Python n'ajouteras jamais de fonctionnalités à sa fonction open() ?

Mais bien sûr qu'il y ajoute des fonctionnalités. Et d'ailleurs des arguments séparés ont été ajoutés pour certains d'entre eux. Mais les fonctionnalitéss de base restent accessibles simplement via la chaîne de flags, et cela suffit dans la majorité des cas.

Désolé, mais je n'ai jamais vu un seul utilisateur de Python se plaindre de ce que open() produisait du code trop concis et qu'il faudrait plutôt des constantes à rallonge à la place. Et je ne connais personne qui préfère écrire O_CREAT | O_WRONLY plutôt que "wb".

Tu écris 20 caractères de plus

Dans l'exemple Java dont on parlait, c'était AMHA beaucoup plus de 20 caractères. Et avant de les écrire, il faut les mémoriser. Et après, il faut les relire. Comme c'est la philosophie adoptée par Java pour toutes ses APIs, cela produit du code hyper-verbeux.

Enfin bon, libre à toi d'ignorer l'évidence.

Il est surtout nettement plus précis dans son utilisation. Le open() python a très peu de possibilités face au open() système. Être haut niveau ne signifie pas être limité. Java se situe entre les deux.

On commence à s'éloigner franchement du sujet, mais le open() de Python 3 a des possibilités que n'a pas le open() système, comme d'ouvrir un flux unicode (en choisissant l'encodage et le mode de traitement des erreurs), de faire une traduction automatique des caractères de fin de ligne, de choisir une stratégie de buffering, ou de wrapper un descripteur de fichier existant. C'est ce que j'appelle fournir une API haut niveau.

Et, oui, si tu veux accéder aux flags bas niveau du open() système, tu peux utiliser os.open(), qui est une simple indirection vers l'appel système, et qui te produit un descripteur de fichier que tu peux réutiliser avec... open(). Donc tu n'es pas plus limité qu'en Java, et les cas d'usage courants sont largement plus lisibles et concis.