En 2000, Apple avait surtout comme image de marque d'être un truc ringard en train de mourir, et tout le monde s'attendait à ce qu'ils aient le même sort qu'Atari, Amiga et les autres.
L'écran rétina et la batterie inamovible (et non irremplaçable) sont arrivés bien après.
Et pourtant, ça fait 15 ans que leurs ventes (et leurs parts de marché) augmentent pour les ordis.
C'est un peu facile de dire que c'est l'image de marque qui suffit à vendre des millions de machines. "Il suffit d'avoir super bonne réputation et d'avoir du bon matos à vendre pour en vendre des millions".
Bah oui, "il suffit". Pourquoi ne font-ils pas la même chose chez Red Hat ou Canonical ?
Oui, pour tous les utilisateurs, il faut être admin.
Sinon, tu utilises "HKEY_CURRENT_USER\Software\Classes\directory\Background\shell" et ça ne concerne que ton utilisateur (et tu n'as pas besoin d'être root).
Après, évidemment, supprimer une clef importante peut être dangereux, un peu comme si tu supprimais un fichier de root et que tu t'étonnais que ton système parte en vrille…
En tout cas, ça pourrait rebuter les packageurs.
J'ai voulu faire des .deb pour un projet web (basé sur Django). Au final, j'ai cinq .deb différents (ni les mêmes fichiers, ni les mêmes dépendances - et je ne parle pas seulement des versions) pour trois versions d'Ubuntu et deux de Debian.
Je ne suis pas allé plus loin…
En l'occurence, pour rajouter des actions personnalisées à l'explorateur de Windows, il faut passer par une obscure clé du Registre Windows.
Linux 1. Windows : 0.
Où est le problème ? Écrire une clef de registre n'est pas forcément plus compliqué qu'écrire un fichier…
Dans le même style, j'ai eu le malheur de vouloir changer le fond d'écran Gnome dans un script de postinstall. Déjà, il faut trouver la commande, qui consiste plus ou moins à écrire une clef du registre Gnome.
Ensuite, écrire une ligne dans un fichier demande que X soit lancé (entre autres), et du coup la commande plante (vu que ce n'est pas le cas pendant la postinstall).
Note : je me suis planté, Heimdal accepte de stocker sa base dans LDAP. Va falloir que je regarde pourquoi je ne l'ai pas fait également (j'étais parti sur cette solution pour MIT Kerberos, avant de basculer sur Heimdal).
Actuellement, je n'ai pas du tout de Samba (je progresse assez lentement : je n'ai pas beaucoup de temps à consacrer au projet, je cherche à avoir une infra complète et je veux que tout s'installe automatiquement, du coup j'en suis encore à l'étape de la supervision après avoir mis la couche Kerberos/OpenSSL/LDAP/NTP/DNS/DHCP).
Je ferai probablement du Samba, mais uniquement en partage de fichiers (et ce n'est même pas sûr, j'hésite avec OpenAFS).
L'API Python peut être pratique si tu veux faire des scripts pour créer les utilisateurs (ou équivalent), plutôt que d'avoir un code Python qui appelle du shell qui appelle du Python. A part ça, pas de raison particulière.
A plus long terme, ça veut dire avoir une dépendance supplémentaire à du Python 2 alors que les distribs passent à Python 3 par défaut.
Si tu acceptes d'avoir deux LDAP, tu dois pouvoir t'en passer ; j'avais besoin de schémas pour Samba, Asterisk et Kerberos (et perso je souhaite avoir un seul LDAP).
disclaimer : je ne suis pas admin sys, je fais plutôt ça par curiosité
J'ai un peu regardé Samba 4, et au final j'ai repris l'ensemble DNS/LDAP/Kerberos. Ce n'est pas encore assez sec à mon goût. Ils sont partis pour beaucoup de Python… mais Python 2 seulement alors que Python 3 est annoncé depuis très longtemps et qu'il est assez facile de faire un code compatible 2/3. Il y a quelques fonctions que je n'ai jamais réussi à faire fonctionner en utilisant l'API (absolument pas documentée, d'ailleurs). Pour les GPO, la seule interface de configuration fournie est le client lourd Windows. On ne peut pas ajouter ses propres schémas LDAP, donc il faudra probablement un LDAP à côté quand même.
Je trouve que l'approche du fuzzing ressemble pas mal au Property-based testing (on définit une propriété que doit respecter une fonction, et on teste des entrées plus ou moins aléatoires sur la fonction. Le fuzzing ici décrit fonctionne sur le programme complet, alors que le property based testing teste surtout les fonctions individuellement.
Je note la chose bien précieusement : je vais devoir faire du tri dans pas mal de photos également, avec plein de doublons.
Je ne sais pas encore quand je m'y collerais, mais ça va m'être bien utile !
désolé, ce n'était pas clair :
- ça oblige à utiliser MIT car Heimdal ne permet de stocker sa base dans LDAP (et Heimdal est obligatoire si tu veux faire du pkinit avec OS X).
- ça ajoute une vulnérabilité dans le sens où tu as une dépendance double (LDAP dépend de Kerberos, qui dépend de LDAP). Je ne sais pas trop comment ça se passe si l'un des deux met un peu de temps à démarrer, par exemple.
Pourquoi avoir stocké kerberos dans ldap ? De mémoire, ça oblige à utiliser MIT et non Heimdal et ça rajoute une vulnérabilité, mais c'est vrai que ça facilite les sauvegardes.
imaginons, tu es un pilote de drone, tu vois dans ton viseur le n°1 de l'Etat Islamique ou de Boko Haram, tu tires ou tu tires pas?
La question n'est pas si simple, même en admettant qu'il n'y ait pas de victimes collatérales. Plein de bonnes raisons s'opposent à l'utilisation de drones armés, même sans ces victimes civiles.
J'ai quand même du mal à voir en quoi la surveillance est généralisée. Actuellement, si on se réfère aux chiffres de la CNCIS (qui sont librement consultables), il y a moins de 3 000 personnes qui sont sur écoute, et il n'y a pas de raison que ce chiffre augmente réellement. On est très loin d'une surveillance généralisée.
Je ne comprends même pas comment on peut tenir ce discours.
Il y a eu un premier plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Il y a eu un second plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Il y a eu un troisième plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Comment peut-on penser un seul instant qu'un nouveau plan va changer quoique ce soit ? Sérieusement ?
Sauf que le plan de la troïka va empirer la situation, et les créanciers vont au final récupérer encore moins d'argent car
* la Grèce ne pourra jamais rembourser ce qu'elle doit déjà,
* sa capacité à rembourser va diminuer,
* ses dettes ont encore été augmentées.
Le plan imposé par l'UE n'a donc pas pour but de rembourser les emprunts grecs. Et ce n'est pas moi qui le dit, c'est le FMI (qu'on peut difficilement traiter de crypto-communiste…)
ce n'est pas évident de faire ça en gardant un maximum de compatibilité.
Personnellement, je me sers pas mal de ces annotations (ou en spécifiant le type dans les docstrings), mon IDE est tout à fait capable de les utiliser pour de la vérification de type. Je limite l'utilisation du typage dynamique de Python aux seuls cas où ça permet de vraiment diminuer la quantité de code. Au final, j'ai très peu de bugs à l'exécution (autres que des vraies erreurs d'algo que j'aurais eues avec n'importe quel langage). Un langage typé statiquement ne m'apporterait pas grand-chose à ce niveau-là, mais c'est fortement lié à l'IDE ET à la documentation.
Mais ça revient à faire de la politique en s'attachant un bras dans le dos, en se privant gratuitement d'un moyen d'agir, qui est peut-être le plus important. Aucune grande politique étatique n'a été faite sans action particulière sur la monnaie pour pouvoir la financer.
Le système européen tombe dans le même travers, en voulant figer dans la Constitution la politique monétaire, alors que la politique monétaire doit par nature s'adapter aux circonstances (parfois en favorisant l'inflation, parfois en la limitant).
Je ne comprends toujours pas l'intérêt à ce que tout le monde fasse tous les calculs.
Ce n'est pas le fait qu'il y ait X personnes qui ont trouvé le même résultat qui te garantit la fiabilité de ce dernier, mais le fait que tu calcules toi-même pour vérifier.
Dans ce cas, pourquoi obliger les autres personnes à refaire aussi le calcul, alors qu'il ne les intéresse potentiellement pas ? Si tu es obligé de faire le calcul pour être sûr du résultat, le fait que les autres l'ait également fait (donc ethereum) ne t'apporte rien.
Accessoirement, les nouveaux venus n'auront pas faits tous les calculs de l'historique, donc le fait que tous les calculs auront été faits par 100 000 personnes ou par 5 personnes ne change strictement rien pour eux. Donc autant les faire faire par une seule personne. À nouveau, ethereum n'apporte rien.
Racontons-nous une petite histoire, avec d'un côté ethereum, de l'autre boinc.
À t0 = 0 jour, il y a 10 personnes sur ethereum, qui font un calcul A,
À t1 = 10 jours, il y a 100 personnes sur ethereum, qui font un calcul B,
À t2 = 20 jours, toto rejoint la Communauté et il y a 10 001 personnes sur ethereum pour faire le calcul C.
De l'autre côté, il y a 101 personnes sur boinc de t0 à t2, date à laquelle toto rejoint la communauté boinc.
Ils ont également fait les calculs A', B', et C' aux mêmes moments.
Si je comprends bien la théorie d'ethereum, toto doit considérer que les résultats de A et B sont plus fiables que ceux de A' et B' (alors qu'il y a moins de gens à les avoir calculés ! ), et pour C se moque du nombre de personnes dans la communauté vu que de toute façon il a fait lui-même le calcul.
Franchement, je ne comprends pas.
Je ne vois toujours pas ce qu'apporte le fait que tout le monde fasse le même calcul.
À partir de combien de personnes différentes estimes-tu que le calcul est fiable ? 10 000 ? Dans ce cas, si Ethereum ne sert à rien s'il n'y a que 9 999 personnes connectées, et consomme tout à fait inutilement des ressources s'il y a 10 001 personnes connectées par rapport à du BOINC classique.
Là, même si on a 100 000 machines, on n'a pas plus de puissance de calcul qu'avec la plus faible de toutes. J'ai franchement l'impression que c'est tout simplement la pire des méthodes pour résoudre le problème de confiance, ce qui explique au passage l'originalité de la solution ^
[^] # Re: A l'install
Posté par flan (site web personnel) . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 0.
En 2000, Apple avait surtout comme image de marque d'être un truc ringard en train de mourir, et tout le monde s'attendait à ce qu'ils aient le même sort qu'Atari, Amiga et les autres.
L'écran rétina et la batterie inamovible (et non irremplaçable) sont arrivés bien après.
Et pourtant, ça fait 15 ans que leurs ventes (et leurs parts de marché) augmentent pour les ordis.
C'est un peu facile de dire que c'est l'image de marque qui suffit à vendre des millions de machines. "Il suffit d'avoir super bonne réputation et d'avoir du bon matos à vendre pour en vendre des millions".
Bah oui, "il suffit". Pourquoi ne font-ils pas la même chose chez Red Hat ou Canonical ?
[^] # Re: A l'install
Posté par flan (site web personnel) . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 2.
A se demander comment a fait Apple pour remonter la pente et livrer des millions d'ordinateurs…
[^] # Re: A l'install
Posté par flan (site web personnel) . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 3.
Oui, pour tous les utilisateurs, il faut être admin.
Sinon, tu utilises "HKEY_CURRENT_USER\Software\Classes\directory\Background\shell" et ça ne concerne que ton utilisateur (et tu n'as pas besoin d'être root).
Après, évidemment, supprimer une clef importante peut être dangereux, un peu comme si tu supprimais un fichier de root et que tu t'étonnais que ton système parte en vrille…
[^] # Re: A l'install
Posté par flan (site web personnel) . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 5.
En tout cas, ça pourrait rebuter les packageurs.
J'ai voulu faire des .deb pour un projet web (basé sur Django). Au final, j'ai cinq .deb différents (ni les mêmes fichiers, ni les mêmes dépendances - et je ne parle pas seulement des versions) pour trois versions d'Ubuntu et deux de Debian.
Je ne suis pas allé plus loin…
[^] # Re: A l'install
Posté par flan (site web personnel) . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 3.
Où est le problème ? Écrire une clef de registre n'est pas forcément plus compliqué qu'écrire un fichier…
Dans le même style, j'ai eu le malheur de vouloir changer le fond d'écran Gnome dans un script de postinstall. Déjà, il faut trouver la commande, qui consiste plus ou moins à écrire une clef du registre Gnome.
Ensuite, écrire une ligne dans un fichier demande que X soit lancé (entre autres), et du coup la commande plante (vu que ce n'est pas le cas pendant la postinstall).
[^] # Re: stockage ldap
Posté par flan (site web personnel) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 2.
Ok, merci.
Note : je me suis planté, Heimdal accepte de stocker sa base dans LDAP. Va falloir que je regarde pourquoi je ne l'ai pas fait également (j'étais parti sur cette solution pour MIT Kerberos, avant de basculer sur Heimdal).
[^] # Re: Microsoft Active Directory
Posté par flan (site web personnel) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 3.
Actuellement, je n'ai pas du tout de Samba (je progresse assez lentement : je n'ai pas beaucoup de temps à consacrer au projet, je cherche à avoir une infra complète et je veux que tout s'installe automatiquement, du coup j'en suis encore à l'étape de la supervision après avoir mis la couche Kerberos/OpenSSL/LDAP/NTP/DNS/DHCP).
Je ferai probablement du Samba, mais uniquement en partage de fichiers (et ce n'est même pas sûr, j'hésite avec OpenAFS).
L'API Python peut être pratique si tu veux faire des scripts pour créer les utilisateurs (ou équivalent), plutôt que d'avoir un code Python qui appelle du shell qui appelle du Python. A part ça, pas de raison particulière.
A plus long terme, ça veut dire avoir une dépendance supplémentaire à du Python 2 alors que les distribs passent à Python 3 par défaut.
Si tu acceptes d'avoir deux LDAP, tu dois pouvoir t'en passer ; j'avais besoin de schémas pour Samba, Asterisk et Kerberos (et perso je souhaite avoir un seul LDAP).
[^] # Re: Microsoft Active Directory
Posté par flan (site web personnel) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 5.
disclaimer : je ne suis pas admin sys, je fais plutôt ça par curiosité
J'ai un peu regardé Samba 4, et au final j'ai repris l'ensemble DNS/LDAP/Kerberos. Ce n'est pas encore assez sec à mon goût. Ils sont partis pour beaucoup de Python… mais Python 2 seulement alors que Python 3 est annoncé depuis très longtemps et qu'il est assez facile de faire un code compatible 2/3. Il y a quelques fonctions que je n'ai jamais réussi à faire fonctionner en utilisant l'API (absolument pas documentée, d'ailleurs). Pour les GPO, la seule interface de configuration fournie est le client lourd Windows. On ne peut pas ajouter ses propres schémas LDAP, donc il faudra probablement un LDAP à côté quand même.
# Property-based testing
Posté par flan (site web personnel) . En réponse au journal Fuzzing : éprouver les entrées de vos développements. Évalué à 4.
Je trouve que l'approche du fuzzing ressemble pas mal au Property-based testing (on définit une propriété que doit respecter une fonction, et on teste des entrées plus ou moins aléatoires sur la fonction. Le fuzzing ici décrit fonctionne sur le programme complet, alors que le property based testing teste surtout les fonctions individuellement.
# Merci !
Posté par flan (site web personnel) . En réponse à la dépêche Katal, catalogue de fichiers. Évalué à 3.
Je note la chose bien précieusement : je vais devoir faire du tri dans pas mal de photos également, avec plein de doublons.
Je ne sais pas encore quand je m'y collerais, mais ça va m'être bien utile !
[^] # Re: stockage ldap
Posté par flan (site web personnel) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 3.
désolé, ce n'était pas clair :
- ça oblige à utiliser MIT car Heimdal ne permet de stocker sa base dans LDAP (et Heimdal est obligatoire si tu veux faire du pkinit avec OS X).
- ça ajoute une vulnérabilité dans le sens où tu as une dépendance double (LDAP dépend de Kerberos, qui dépend de LDAP). Je ne sais pas trop comment ça se passe si l'un des deux met un peu de temps à démarrer, par exemple.
# stockage ldap
Posté par flan (site web personnel) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 2.
Merci pour ce journal intéressant.
Pourquoi avoir stocké kerberos dans ldap ? De mémoire, ça oblige à utiliser MIT et non Heimdal et ça rajoute une vulnérabilité, mais c'est vrai que ça facilite les sauvegardes.
[^] # Re: Arguments faiblards
Posté par flan (site web personnel) . En réponse au journal Dévoiler la «libre» politique,. Évalué à 4.
La question n'est pas si simple, même en admettant qu'il n'y ait pas de victimes collatérales. Plein de bonnes raisons s'opposent à l'utilisation de drones armés, même sans ces victimes civiles.
[^] # Re: Tout est dans le texte
Posté par flan (site web personnel) . En réponse au journal Quand on lit ça, on comprend le pourquoi de la loi renseignement et de la surveillance généralisée. Évalué à -1.
J'ai quand même du mal à voir en quoi la surveillance est généralisée. Actuellement, si on se réfère aux chiffres de la CNCIS (qui sont librement consultables), il y a moins de 3 000 personnes qui sont sur écoute, et il n'y a pas de raison que ce chiffre augmente réellement. On est très loin d'une surveillance généralisée.
[^] # Re: Support hardware VP9
Posté par flan (site web personnel) . En réponse au journal Codec War S42E84. Évalué à 2.
et concrètement, qu'est-ce que ça donne ? Ce n'est pas parce que Google met des choses à disposition que c'est utilisé en pratique.
[^] # Re: Civilisation ?
Posté par flan (site web personnel) . En réponse au journal Un véritable civilisation open-source ?. Évalué à 5.
Je ne comprends même pas comment on peut tenir ce discours.
Il y a eu un premier plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Il y a eu un second plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Il y a eu un troisième plan d'austérité, qui a augmenté la dette et réduit sa capacité à rembourser (en plus de détériorer la société grecque).
Comment peut-on penser un seul instant qu'un nouveau plan va changer quoique ce soit ? Sérieusement ?
[^] # Re: Civilisation ?
Posté par flan (site web personnel) . En réponse au journal Un véritable civilisation open-source ?. Évalué à 5.
Sauf que le plan de la troïka va empirer la situation, et les créanciers vont au final récupérer encore moins d'argent car
* la Grèce ne pourra jamais rembourser ce qu'elle doit déjà,
* sa capacité à rembourser va diminuer,
* ses dettes ont encore été augmentées.
Le plan imposé par l'UE n'a donc pas pour but de rembourser les emprunts grecs. Et ce n'est pas moi qui le dit, c'est le FMI (qu'on peut difficilement traiter de crypto-communiste…)
[^] # Re: Résumé de l'épisode précédent
Posté par flan (site web personnel) . En réponse au journal La dernière kubuntu ?. Évalué à 5.
Il en a tout à fait le droit, en tout cas.
[^] # Re: PEP 484 : module typing, le nouveau standard pour les annotations de typage
Posté par flan (site web personnel) . En réponse à la dépêche Parution de Python 3.5. Évalué à 3.
ce n'est pas évident de faire ça en gardant un maximum de compatibilité.
Personnellement, je me sers pas mal de ces annotations (ou en spécifiant le type dans les docstrings), mon IDE est tout à fait capable de les utiliser pour de la vérification de type. Je limite l'utilisation du typage dynamique de Python aux seuls cas où ça permet de vraiment diminuer la quantité de code. Au final, j'ai très peu de bugs à l'exécution (autres que des vraies erreurs d'algo que j'aurais eues avec n'importe quel langage). Un langage typé statiquement ne m'apporterait pas grand-chose à ce niveau-là, mais c'est fortement lié à l'IDE ET à la documentation.
[^] # Re: Monnaie libre
Posté par flan (site web personnel) . En réponse au journal Un véritable civilisation open-source ?. Évalué à 4.
Mais ça revient à faire de la politique en s'attachant un bras dans le dos, en se privant gratuitement d'un moyen d'agir, qui est peut-être le plus important. Aucune grande politique étatique n'a été faite sans action particulière sur la monnaie pour pouvoir la financer.
Le système européen tombe dans le même travers, en voulant figer dans la Constitution la politique monétaire, alors que la politique monétaire doit par nature s'adapter aux circonstances (parfois en favorisant l'inflation, parfois en la limitant).
[^] # Re: petite question
Posté par flan (site web personnel) . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à 9.
Ne me dis pas que tu as d'autres critères que la pile réseau quand tu choisis ton OS !
[^] # Re: Monnaie libre
Posté par flan (site web personnel) . En réponse au journal Un véritable civilisation open-source ?. Évalué à 8.
Un concept puissant qui ruine toute possibilité de construire une politique monétaire, et donc toute politique tout court ?
[^] # Re: "Il faut payer"?
Posté par flan (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 5.
Je ne comprends toujours pas l'intérêt à ce que tout le monde fasse tous les calculs.
Accessoirement, les nouveaux venus n'auront pas faits tous les calculs de l'historique, donc le fait que tous les calculs auront été faits par 100 000 personnes ou par 5 personnes ne change strictement rien pour eux. Donc autant les faire faire par une seule personne. À nouveau, ethereum n'apporte rien.
Racontons-nous une petite histoire, avec d'un côté ethereum, de l'autre boinc.
À t0 = 0 jour, il y a 10 personnes sur ethereum, qui font un calcul A,
À t1 = 10 jours, il y a 100 personnes sur ethereum, qui font un calcul B,
À t2 = 20 jours, toto rejoint la Communauté et il y a 10 001 personnes sur ethereum pour faire le calcul C.
De l'autre côté, il y a 101 personnes sur boinc de t0 à t2, date à laquelle toto rejoint la communauté boinc.
Ils ont également fait les calculs A', B', et C' aux mêmes moments.
Si je comprends bien la théorie d'ethereum, toto doit considérer que les résultats de A et B sont plus fiables que ceux de A' et B' (alors qu'il y a moins de gens à les avoir calculés ! ), et pour C se moque du nombre de personnes dans la communauté vu que de toute façon il a fait lui-même le calcul.
Franchement, je ne comprends pas.
[^] # Re: et ca marche ?
Posté par flan (site web personnel) . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 3.
Le message d'origine parle de la masse totale du drone, pas de son armement ;)
[^] # Re: "Il faut payer"?
Posté par flan (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 5.
Je ne vois toujours pas ce qu'apporte le fait que tout le monde fasse le même calcul.
À partir de combien de personnes différentes estimes-tu que le calcul est fiable ? 10 000 ? Dans ce cas, si Ethereum ne sert à rien s'il n'y a que 9 999 personnes connectées, et consomme tout à fait inutilement des ressources s'il y a 10 001 personnes connectées par rapport à du BOINC classique.
Là, même si on a 100 000 machines, on n'a pas plus de puissance de calcul qu'avec la plus faible de toutes. J'ai franchement l'impression que c'est tout simplement la pire des méthodes pour résoudre le problème de confiance, ce qui explique au passage l'originalité de la solution ^