Tu peux compiler et installer une application sans qu'elle passe par Apple (heureusement pour les développeurs !)
Ce que tu ne peux pas faire sans validation par Apple, c'est distribuer ton code via l'AppStore. De plus, il y a un système pour que les entreprises puissent déployer leurs applications internes sans passer par l'AppStore d'Apple. J'ose espérer qu'il n'y a pas besoin de validation d'Apple pour ce genre d'applis, mais on peut s'attendre au pire.
J'imagine que le coût du benchmark doit être pris en charge, au moins en partie, par le constructeur. Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.
Accessoirement, il doit y avoir plusieurs essais, à cause des pannes. Sur ce genre de machines, les pannes sont fréquentes et normales.
En quoi serait-ce la mort des freeware ? Il suffit de regarder ce qui se passez sur l'iPhone ou les Android pour se rendre compte qu'il y a environ 50% d'applications gratuites.
Donne donc des chiffres plus fiables. Personnellement, ça ne me choque pas plus que ça. Jailbreaker un téléphone demande tout de même quelques connaissances informatiques, même basiques (je ne vois pas ma mère le faire, par exemple), et ce n'est pas parce que tu possèdes ces connaissances que tu vas forcément jailbreaker ton téléphone. Pour reprendre une méthode de statistique fiable, au doigt mouillé, je connais pas mal de gens qui bossent dans l'informatique (avec largement le niveau pour le jailbreak), et qui pourtant ne l'ont pas fait. Mais à nouveau, si tu as de meilleurs chiffres, je suis preneur.
Apple a tout de même intégré un certain nombre de choses qui n'étaient possibles qu'avec le jailbreak dans les premières versions, ce qui le rend moins utile quand on ne veut pas d'applis piratées.
En 2011, il y aurait eu en gros 7-8% d'iPhone jailbreakés en France (loin des 75% que tu annonces), et il y aurait des applications piratées sur 38% de ceux-ci (d'après PinchMedia, je n'ai pas vu d'autres sources). Le taux de jailbreak monte à 40% en Chine, mais est entre 5 et 10% dans les pays occidentaux.
Supporter OS X, ok, mais comment ?
Avoir une « vraie » appli OS X, c'est avoir une appli qui utilise les composants du système, du genre :
- le proxy
- le correcteur orthographique et grammatical
- les raccourcis clavier (modifiables par le système)
- le trousseau de mots de passe et de certificats
- les API pour les contacts et les mails
- l'API système pour faire du plein écran
Alors, oui, ça commence à arriver, mais que ce soit avec Qt ou avec un autre toolkit, il est nécessaire d'avoir du code spécifique à OS X (comme il en faut sûrement pour Linux ou Windows). Faire du code identique quelque soit l'OS et être bien intégré au système me semble vraiment impossible, quelque soit le toolkit utilisé.
Sauf que reprendre le look & feel natif, ce n'est pas seulement changer la couleur des boutons. Par exemple, tu peux avoir un widget (composant élémentaire de l'interface graphique : bouton, liste déroulante, élément de menu, …) qui existe sur un OS et pas sur un autre, comme c'est le cas avec Vista par rapport aux autres OS. Autre exemple, avec OS X, tu as une seule icône pour toutes les fenêtres de l'application, icône que tu peux animer (faire rebondir, ou la modifier).
C'est assez loin du modèle Windows XP et Gnome 2 où tu as une icône par fenêtre, icône qui est figée. Dur d'avoir un toolkit qui adopte vraiment le style natif de chaque plate-forme.
Je fais bien la différence, mais tu peux avoir plusieurs solutions de SSO en parallèle : Kerberos qui va te logguer sur les différents sites de l'intranet de ton entreprise, Facebook qui va te logguer sur tous les sites qui utilisent Facebook pour t'authentifier (je ne connais que Clubic qui permette d'utiliser Facebook pour se logguer, mais j'imagine bien qu'il y a pas mal d'autres sites), …
Je pensais donc à un système qui stocke tous tes mots de passe (comme un trousseau d'accès), mais qui en plus gère l'aspect SSO de ces comptes (renouveler le ticket, par exemple).
Par exemple, un trousseau simple utiliserait le mot de passe associé à Clubic pour te connecter sur Clubic, alors qu'un système conscient du SSO te connecterait à Facebook si tu ne l'es pas déjà, puis utiliserait cette connexion pour te connecter sur Facebook.
Mais bon, attendons d'en savoir plus :D
Idem !
Est-ce une sorte de panneau de contrôle dans lequel on rentre tous ses identifiants (son mot de passe Kerberos, son compte Facebook, son compte Google, son certificat PKCS12, son mot de passe LDAP, …), et quand on doit s'identifier, le framework trouve tout seul le bon identifiant à utiliser ?
Just par curiosité, quels sont les problèmes de distutils ? Je m'en sers régulièrement (pour faire des .deb et des .tar.gz de mes modules Python), et je trouve que cela fonctionne plutôt bien :)
Personnellement, je trouve que les extensions sont complètement archaïques. Le type MIME est pas mal, mais trop empirique (si je ne me trompe pas, il se base sur l'extension et le début du fichier, donc bien trop peu pour distinguer un .m d'un .c ou d'un .h si les extensions sont absentes).
À mes yeux, le nom du fichier (qui est choisi par l'utilisateur) ne devrait pas déterminer le type du contenu (qui est choisi par l'application).
Sur les anciens Mac OS et Mac OS X, un fichier est un triplet (nom de fichier, données, ressources), alors que sur Windows et Linux, c'est simplement un couple (nom de fichier, données).
Les ressources stockaient toutes sortes de métadonnées : type complet, mais aussi application ayant créé le fichier, application ayant ouvert le fichier (très pratique pour les images, par exemple), icône représentant le fichier (aperçu pour un PDF, par exemple).
Ça permet d'avoir deux fichiers avec la même extensions et un début de fichier similaire (donc impossible à distinguer au niveau MIME), mais modifiés par des applications différentes.
Et comme ces ressources font partie du fichier au même titre que les données, elles étaient recopiées en même temps sur les disques externes (c'est l'origine des fichiers ._.toto quand on copie un fichier toto sur un système de fichiers qui ne connaît pas les ressources, comme FAT32). Vous imaginez bien que cela a posé quelques soucis à l'heure d'internet :D
Je trouve ce système bien mieux pensé que la version windowsienne et linuxienne, même si elle n'est pas parfaite et qu'elle pourrait être améliorée.
Au passage, il n'y aura pas de Python 2.8, et il n'y aura plus de nouvelles fonctionnalités sur la branche 2.7.
Il n'y a plus qu'à attendre que les grandes bibliothèques passent toutes à Python 3 pour vraiment lancer le mouvement (PyQt est déjà compatible, Django 1.5 le sera, SQLAlchemy fonctionne, Matplotlib est bien avancé, il semble rester encore du boulot pour Twisted, PiL n'est pas être prête).
Je traduis l'introduction :
> * un langage doit être prédictible. […]
> * un langage doit être cohérent. […]
> * un langage doit être concis. […]
> * un langage doit être fiable. […]
> * un langage doit être débuggable. […]
> Ma position est celle-ci :
> PHP est plein de surprises : mysql_real_escape_string, E_ALL
> PHP est incohérent : strpos, str_rot13
> PHP demande de l'emballage (boilerplate), comme la gestion d'erreurs autour des appels C
> PHP n'est pas fiable (== qui n'a pas le sens habituel et qui ne sert à rien, foreach ($foo as &$bar))
> PHP est opaque (pas de stracktrace par défaut, rapports d'erreurs complexes)
>
> Ne me dites pas que « de bons développeurs peuvent écrire du bon code dans n'importe quel langage », ou de mauvais développeurs blah, blah, blah. Ça ne veut rien dire. Un bon charpentier peut enfoncer un clou avec une pierre ou un marteau, mais combien en avez-vous vus taper quelque chose avec des pierres ? […]
> Ne me dites pas que c'est la responsabilité du développeur de se souvenir des centaines d'exceptions étranges et de comportements surprenant. Oui, c'est nécessaire dans tous les systèmes. […] PHP n'est rien qu'un paquet d'exceptions […]
> Ne me dites pas que « c'est comme ça que l'API C fonctionne ». Quel intérêt d'utiliser un langage haut-niveau s'il ne fournit que quelques aides et wrappers C ? Autant écrire du C !
Je ne fais du dev web qu'à titre perso, mais j'ai pris la peine d'apprendre Python + Django. Ça demande un investissement initial certain, mais qui est très largement rentabilisé par rapport à du PHP basique (et je trouve Django bien plus simple à utiliser que Symfony, même si je n'ai pas eu beaucoup d'expérience avec ce dernier).
Au final, avec Django, on se retrouve à écrire quelques classes Python pour le modèle de données, quelques fonctions pour les pages appelées (une page == une fonction en gros), avec quelques templates HTML, et hop, c'est fini :) J'exagère, mais à peine ^
Es-tu sûr ? Même pas le « et adressées à des tiers », qui change tout ?
Le premier paragraphe concerne les correspondances papier, le second les correspondances électroniques, mais dans les deux cas, le problème ne s'applique que quand tu n'es ni l'auteur, ni le destinataire de la correspondance.
D'ailleurs, petite citation de Me Eolas :
Diffuser le contenu d'une correspondance peut-être puni par la loi, même si on est le destinataire de la correpondance en question (ici un sexto).
Depuis quand ?
À partir du moment où l'on est destinataire du message, et qu'il n'y a pas de contraintes extérieures (genre un gros tampon SECRET DÉFENSE au-dessus :D), tu peux faire tout ce que tu veux.
Dans l'autre cas, tu n'es pas censé lire les messages qui ne te sont pas destinés (et rien qu'intercepter les correspondances est puni par la loi).
En effet, c'est peut-être le seul avantage de PHP.
Mais :
* ce n'est pas une bonne idée de faire ça,
* tu peux faire sensiblement la même chose avec Python en CGI.
Pour moi, le plus gros défaut est quand même le ==, qui ne sert strictement à rien (comme tout le monde le fait remarquer)… mais pourquoi utiliser le symbole ==, avec un sens différent de celui utilisé dans tous les langages, qui prête à confusion, qui ne sert à rien, et qui a changé de sens entre PHP4 et PHP5 ?
Les « tableaux » sont également une blague. Les physiciens se plaignent avec la dualité onde-corpuscule, mais que devrait-on dire de ces objets qui se comportent parfois comme des listes, parfois comme des ensembles, et parfois comme des tables de hash ? Impossible de savoir quel sera le comportement adopté en fonction de la situation.
Je comprends que PHP ait pu avoir du succès à sa sortie, mais actuellement, je ne le comprends plus tellement. Je ne vois pas un seul avantage intrinsèque de PHP par rapport à ses concurrents, notamment par rapport à Python (vu que je maîtrise maintenant assez bien Python, après avoir fait pas mal de PHP).
J'ai plutôt l'impression qu'on sait tout du nouvel iPhone, et qu'il n'a vraiment rien de franchement révolutionnaire, que ce soit niveau matériel ou logiciel.
Un écran un peu plus grand, un processeur plus puissant, plus de ram, … Il y aura peut-être la 4G de la partie, mais très sincèrement, je doute que ça change la vie (surtout vu son déploiement actuel).
Et il y aura d'autant moins d'effet de surprise que tout semble déjà connu sur l'iPhone 5. Ok, peut-être pas son nom.
Je trouve tout de même l'argument vraiment très faible. Ils n'aiment pas le XML ? Pas grave, soit ils utilisent du JSON (correctement indenté, ça passe sans problème), soient ils forkent simplement plistlib pour qu'elle accepte du YAML en plus du XML, du JSON et du binaire. C'est quand même beaucoup moins compliqué que de tout recoder uniquement parce qu'ils trouvent que le plist en XML n'est pas assez lisible…
Sur OS X, tous les fichiers de données des applications (sauf évidemment les outils UNIX historiques) sont soit en plist, soit en sqlite. Ça concerne aussi bien les fichiers de configuration que les fichiers de préférences ou que les fichiers de description d'une application (l'équivalent du .desktop linuxien). À l'usage, c'est très confortable.
Aucun parseur à écrire, une bibliothèque existe dans à peu près tous les langages (c'est même de base dans Python), un programme peut lire les fichiers de configuration et de données de n'Importe quelle application, il y a quelques éditeurs graphiques pour les modifier (XCode en propose un, par exemple), …
Actuellement, faire un programme qui va lire et modifier les configuration de trucs comme Apache ou OpenLDAP est plutôt galère, il faut réécrire un parseur sans savoir si on a pensé à tous les cas… Rajouter et supprimer via un script une entrée dans le crontab est assez périlleux à mes yeux. Avec des fichiers en plist, ces opérations seraient extrêmement simples.
Après, le côté XML peut rebuter un peu (même si à l'usage, ce n'est pas si gênant). Mais comme déjà dit, il suffirait de rajouter un autre format plus humain à plistlib, et ce n'est vraiment pas compliqué…
Non, tu dois confondre avec autre chose, ou alors c'est l'expression bac-à-sable qui est trompeuse.
Si on met une application dans un bac-à-sable, ce n'est pas pour jeter ce qu'elle fait (faire des tests, donc), mais simplement pour qu'elle fasse ce qu'elle veut (y compris du travail utile, genre naviguer sur internet, écrire un texte, …) à l'intérieur de son bac-à-sable.
Si elle veut prendre un seau ou une nouvelle pelle, elle doit demander aux parents et ce sont eux qui acceptent et qui amènent les objets (comprendre : elle passe par des API système pour accéder aux autres ressources systèmes comme le système de fichiers).
C'est curieux, je trouve qu'OS X est justement le système où il y a le plus d'interactions entre applications.
Le framework Cocoa permet d'avoir au niveau système énormément d'API utilisées par la plupart des applications ainsi que des formats d'échange communs :
- contacts (la même API est utilisée pour tous les contacts, qu'ils soient locaux, ou stockés via CardDAV, Exchange, LDAP, Yahoo!, iCloud),
- calendriers (même chose),
- mails,
- musique,
- favoris internet,
- photos,
- filtres d'image (fichiers .qtz, applicables sur des photos que des vidéos, ou comme animations en économiseur d'écran),
- mots de passe et certificats (une seule application pour tout gérer, et permettant de recréer des certificats),
- dictionnaire, correcteur orthographique et grammatical et autocorrection,
- reconnaissance et synthèse vocale,
- glisser-déposer d'une application à l'autre (on glisse l'icône du fichier ouvert — visible dans la barre de titre — dans une autre application, et ça marche),
- sélecteur de couleurs et de polices de caractères,
- pilotage des applications en Automator, AppleScript, Objective C, Python, Ruby,
- fichiers de configuration (format .plist - toutes les applications OS X utilisent le même format pour les fichiers de conf' ! ) et de stockage (bases sqlite3),
- sauvegarde (TimeMachine n'est pas limité aux fichiers, on sélectionne le carnet d'adresse, on lance TimeMachine, et on peut retrouver des contacts effacés),
- recherche indexée (pour indexer convenablement de nouveaux types de fichiers),
- synchronisation via iCloud
- changement des raccourcis clavier de n'importe quelle application.
Le système est encore loin d'être parfait, et c'est notamment dommage que la synchro ne se fasse que par iCloud. Mais je vois difficilement comment peut-on dire qu'il n'y a pas de fortes interactions entre applications…
Je t'avoue que je n'ai aucune idée des raisons qui poussent les gens à acheter un Mac, et à moins que tu aies des chiffres précis, je ne vois pas trop l'intérêt d'en parler.
Je dis seulement que ce qui fait la plus-value d'OS X (quels que soient les avantages ou inconvénients du système), c'est avant tout le framework Cocoa. Si tu l'enlèves, tu te retrouves avec un UNIX tout ce qu'il y a de plus classique, sans intérêt particulier par rapport aux autres.
Même si tu mettais Linux ou NT à la place de Mach (modulo les « quelques » problèmes techniques), presque personne ne s'en rendrait compte. Par contre, si tu enlèves Cocoa, la situation risque d'être différente. (par contre, si quelqu'un pouvait changer HFS+ par un vrai système de fichiers, ça serait une bonne idée)
[^] # Re: Un mini-message plus qu'un journal
Posté par flan (site web personnel) . En réponse au journal VLC passe à la LGPL. Évalué à 3.
Tu peux compiler et installer une application sans qu'elle passe par Apple (heureusement pour les développeurs !)
Ce que tu ne peux pas faire sans validation par Apple, c'est distribuer ton code via l'AppStore. De plus, il y a un système pour que les entreprises puissent déployer leurs applications internes sans passer par l'AppStore d'Apple. J'ose espérer qu'il n'y a pas besoin de validation d'Apple pour ce genre d'applis, mais on peut s'attendre au pire.
[^] # Re: En vrac...
Posté par flan (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 2.
J'imagine que le coût du benchmark doit être pris en charge, au moins en partie, par le constructeur. Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.
Accessoirement, il doit y avoir plusieurs essais, à cause des pannes. Sur ce genre de machines, les pannes sont fréquentes et normales.
[^] # Re: On parie?
Posté par flan (site web personnel) . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 1.
En quoi serait-ce la mort des freeware ? Il suffit de regarder ce qui se passez sur l'iPhone ou les Android pour se rendre compte qu'il y a environ 50% d'applications gratuites.
[^] # Re: Le chantage à la pomme
Posté par flan (site web personnel) . En réponse au journal ice cream sandwich, je ne mange pas de ce pain-là. Évalué à 2.
Donne donc des chiffres plus fiables. Personnellement, ça ne me choque pas plus que ça. Jailbreaker un téléphone demande tout de même quelques connaissances informatiques, même basiques (je ne vois pas ma mère le faire, par exemple), et ce n'est pas parce que tu possèdes ces connaissances que tu vas forcément jailbreaker ton téléphone. Pour reprendre une méthode de statistique fiable, au doigt mouillé, je connais pas mal de gens qui bossent dans l'informatique (avec largement le niveau pour le jailbreak), et qui pourtant ne l'ont pas fait. Mais à nouveau, si tu as de meilleurs chiffres, je suis preneur.
Apple a tout de même intégré un certain nombre de choses qui n'étaient possibles qu'avec le jailbreak dans les premières versions, ce qui le rend moins utile quand on ne veut pas d'applis piratées.
[^] # Re: Le chantage à la pomme
Posté par flan (site web personnel) . En réponse au journal ice cream sandwich, je ne mange pas de ce pain-là. Évalué à 8.
En 2011, il y aurait eu en gros 7-8% d'iPhone jailbreakés en France (loin des 75% que tu annonces), et il y aurait des applications piratées sur 38% de ceux-ci (d'après PinchMedia, je n'ai pas vu d'autres sources). Le taux de jailbreak monte à 40% en Chine, mais est entre 5 et 10% dans les pays occidentaux.
[^] # Re: qt
Posté par flan (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 7.
Supporter OS X, ok, mais comment ?
Avoir une « vraie » appli OS X, c'est avoir une appli qui utilise les composants du système, du genre :
- le proxy
- le correcteur orthographique et grammatical
- les raccourcis clavier (modifiables par le système)
- le trousseau de mots de passe et de certificats
- les API pour les contacts et les mails
- l'API système pour faire du plein écran
Alors, oui, ça commence à arriver, mais que ce soit avec Qt ou avec un autre toolkit, il est nécessaire d'avoir du code spécifique à OS X (comme il en faut sûrement pour Linux ou Windows). Faire du code identique quelque soit l'OS et être bien intégré au système me semble vraiment impossible, quelque soit le toolkit utilisé.
[^] # Re: qt
Posté par flan (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
Sauf que reprendre le look & feel natif, ce n'est pas seulement changer la couleur des boutons. Par exemple, tu peux avoir un widget (composant élémentaire de l'interface graphique : bouton, liste déroulante, élément de menu, …) qui existe sur un OS et pas sur un autre, comme c'est le cas avec Vista par rapport aux autres OS. Autre exemple, avec OS X, tu as une seule icône pour toutes les fenêtres de l'application, icône que tu peux animer (faire rebondir, ou la modifier).
C'est assez loin du modèle Windows XP et Gnome 2 où tu as une icône par fenêtre, icône qui est figée. Dur d'avoir un toolkit qui adopte vraiment le style natif de chaque plate-forme.
[^] # Re: ?
Posté par flan (site web personnel) . En réponse au journal GNOME et Ubuntu n’en finissent pas de s’éloigner. Évalué à 2.
Je fais bien la différence, mais tu peux avoir plusieurs solutions de SSO en parallèle : Kerberos qui va te logguer sur les différents sites de l'intranet de ton entreprise, Facebook qui va te logguer sur tous les sites qui utilisent Facebook pour t'authentifier (je ne connais que Clubic qui permette d'utiliser Facebook pour se logguer, mais j'imagine bien qu'il y a pas mal d'autres sites), …
Je pensais donc à un système qui stocke tous tes mots de passe (comme un trousseau d'accès), mais qui en plus gère l'aspect SSO de ces comptes (renouveler le ticket, par exemple).
Par exemple, un trousseau simple utiliserait le mot de passe associé à Clubic pour te connecter sur Clubic, alors qu'un système conscient du SSO te connecterait à Facebook si tu ne l'es pas déjà, puis utiliserait cette connexion pour te connecter sur Facebook.
Mais bon, attendons d'en savoir plus :D
[^] # Re: ?
Posté par flan (site web personnel) . En réponse au journal GNOME et Ubuntu n’en finissent pas de s’éloigner. Évalué à 3.
Idem !
Est-ce une sorte de panneau de contrôle dans lequel on rentre tous ses identifiants (son mot de passe Kerberos, son compte Facebook, son compte Google, son certificat PKCS12, son mot de passe LDAP, …), et quand on doit s'identifier, le framework trouve tout seul le bon identifiant à utiliser ?
Ou est-ce un remplacement de PAM ?
[^] # Re: Packaging
Posté par flan (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 1.
Just par curiosité, quels sont les problèmes de distutils ? Je m'en sers régulièrement (pour faire des .deb et des .tar.gz de mes modules Python), et je trouve que cela fonctionne plutôt bien :)
[^] # Re: les questions essentielles
Posté par flan (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 3.
Personnellement, je trouve que les extensions sont complètement archaïques. Le type MIME est pas mal, mais trop empirique (si je ne me trompe pas, il se base sur l'extension et le début du fichier, donc bien trop peu pour distinguer un .m d'un .c ou d'un .h si les extensions sont absentes).
À mes yeux, le nom du fichier (qui est choisi par l'utilisateur) ne devrait pas déterminer le type du contenu (qui est choisi par l'application).
Sur les anciens Mac OS et Mac OS X, un fichier est un triplet (nom de fichier, données, ressources), alors que sur Windows et Linux, c'est simplement un couple (nom de fichier, données).
Les ressources stockaient toutes sortes de métadonnées : type complet, mais aussi application ayant créé le fichier, application ayant ouvert le fichier (très pratique pour les images, par exemple), icône représentant le fichier (aperçu pour un PDF, par exemple).
Ça permet d'avoir deux fichiers avec la même extensions et un début de fichier similaire (donc impossible à distinguer au niveau MIME), mais modifiés par des applications différentes.
Et comme ces ressources font partie du fichier au même titre que les données, elles étaient recopiées en même temps sur les disques externes (c'est l'origine des fichiers ._.toto quand on copie un fichier toto sur un système de fichiers qui ne connaît pas les ressources, comme FAT32). Vous imaginez bien que cela a posé quelques soucis à l'heure d'internet :D
Je trouve ce système bien mieux pensé que la version windowsienne et linuxienne, même si elle n'est pas parfaite et qu'elle pourrait être améliorée.
[^] # Re: sshfs
Posté par flan (site web personnel) . En réponse au journal Sleipnir : proxy quick & dirty pour bien coder. Évalué à 7.
Cette solution offre l'avantage de ne pas avoir à modifier le fichier sur le serveur distant ;)
# Python 2, c'est fini
Posté par flan (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 7.
Au passage, il n'y aura pas de Python 2.8, et il n'y aura plus de nouvelles fonctionnalités sur la branche 2.7.
Il n'y a plus qu'à attendre que les grandes bibliothèques passent toutes à Python 3 pour vraiment lancer le mouvement (PyQt est déjà compatible, Django 1.5 le sera, SQLAlchemy fonctionne, Matplotlib est bien avancé, il semble rester encore du boulot pour Twisted, PiL n'est pas être prête).
[^] # Re: Souhaitons une belle mort à PHP
Posté par flan (site web personnel) . En réponse à la dépêche Sortie de txt2tags en version PHP. Évalué à 2.
Je pense que le lien plus haut ( http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ) donne un certain nombre de bonnes raisons :)
Je traduis l'introduction :
> * un langage doit être prédictible. […]
> * un langage doit être cohérent. […]
> * un langage doit être concis. […]
> * un langage doit être fiable. […]
> * un langage doit être débuggable. […]
> Ma position est celle-ci :
> PHP est plein de surprises : mysql_real_escape_string, E_ALL
> PHP est incohérent : strpos, str_rot13
> PHP demande de l'emballage (boilerplate), comme la gestion d'erreurs autour des appels C
> PHP n'est pas fiable (== qui n'a pas le sens habituel et qui ne sert à rien, foreach ($foo as &$bar))
> PHP est opaque (pas de stracktrace par défaut, rapports d'erreurs complexes)
>
> Ne me dites pas que « de bons développeurs peuvent écrire du bon code dans n'importe quel langage », ou de mauvais développeurs blah, blah, blah. Ça ne veut rien dire. Un bon charpentier peut enfoncer un clou avec une pierre ou un marteau, mais combien en avez-vous vus taper quelque chose avec des pierres ? […]
> Ne me dites pas que c'est la responsabilité du développeur de se souvenir des centaines d'exceptions étranges et de comportements surprenant. Oui, c'est nécessaire dans tous les systèmes. […] PHP n'est rien qu'un paquet d'exceptions […]
> Ne me dites pas que « c'est comme ça que l'API C fonctionne ». Quel intérêt d'utiliser un langage haut-niveau s'il ne fournit que quelques aides et wrappers C ? Autant écrire du C !
Le reste du texte est bien intéressant :)
[^] # Re: Souhaitons une belle mort à PHP
Posté par flan (site web personnel) . En réponse à la dépêche Sortie de txt2tags en version PHP. Évalué à 2.
Je ne fais du dev web qu'à titre perso, mais j'ai pris la peine d'apprendre Python + Django. Ça demande un investissement initial certain, mais qui est très largement rentabilisé par rapport à du PHP basique (et je trouve Django bien plus simple à utiliser que Symfony, même si je n'ai pas eu beaucoup d'expérience avec ce dernier).
Au final, avec Django, on se retrouve à écrire quelques classes Python pour le modèle de données, quelques fonctions pour les pages appelées (une page == une fonction en gros), avec quelques templates HTML, et hop, c'est fini :) J'exagère, mais à peine ^
[^] # Re: Encore un qui a trop fumé la moquette
Posté par flan (site web personnel) . En réponse au journal Légaliser la possession de pédopornographie pour sauver le Net. Évalué à 1.
Es-tu sûr ? Même pas le « et adressées à des tiers », qui change tout ?
Le premier paragraphe concerne les correspondances papier, le second les correspondances électroniques, mais dans les deux cas, le problème ne s'applique que quand tu n'es ni l'auteur, ni le destinataire de la correspondance.
D'ailleurs, petite citation de Me Eolas :
Eolas:
Oui, on peut les publier. Ce n'est pas une atteinte au secret de la correspondance puisque cette atteinte suppose que celui qui la commet soit de mauvaise foi, en sachant que le courrier ne lui est pas destiné. »
[^] # Re: Encore un qui a trop fumé la moquette
Posté par flan (site web personnel) . En réponse au journal Légaliser la possession de pédopornographie pour sauver le Net. Évalué à -1.
Depuis quand ?
À partir du moment où l'on est destinataire du message, et qu'il n'y a pas de contraintes extérieures (genre un gros tampon SECRET DÉFENSE au-dessus :D), tu peux faire tout ce que tu veux.
Dans l'autre cas, tu n'es pas censé lire les messages qui ne te sont pas destinés (et rien qu'intercepter les correspondances est puni par la loi).
[^] # Re: Tu chipotes.
Posté par flan (site web personnel) . En réponse au journal PHP, A Fractal Of Bad Design. Évalué à 0.
En effet, c'est peut-être le seul avantage de PHP.
Mais :
* ce n'est pas une bonne idée de faire ça,
* tu peux faire sensiblement la même chose avec Python en CGI.
[^] # Re: Tu chipotes.
Posté par flan (site web personnel) . En réponse au journal PHP, A Fractal Of Bad Design. Évalué à 5.
Pour moi, le plus gros défaut est quand même le ==, qui ne sert strictement à rien (comme tout le monde le fait remarquer)… mais pourquoi utiliser le symbole ==, avec un sens différent de celui utilisé dans tous les langages, qui prête à confusion, qui ne sert à rien, et qui a changé de sens entre PHP4 et PHP5 ?
Les « tableaux » sont également une blague. Les physiciens se plaignent avec la dualité onde-corpuscule, mais que devrait-on dire de ces objets qui se comportent parfois comme des listes, parfois comme des ensembles, et parfois comme des tables de hash ? Impossible de savoir quel sera le comportement adopté en fonction de la situation.
Je comprends que PHP ait pu avoir du succès à sa sortie, mais actuellement, je ne le comprends plus tellement. Je ne vois pas un seul avantage intrinsèque de PHP par rapport à ses concurrents, notamment par rapport à Python (vu que je maîtrise maintenant assez bien Python, après avoir fait pas mal de PHP).
# Nouveau choc, vraiment ?
Posté par flan (site web personnel) . En réponse au journal H-48 avant le nouveau choc sur la planète high-tech. Évalué à 8.
J'ai plutôt l'impression qu'on sait tout du nouvel iPhone, et qu'il n'a vraiment rien de franchement révolutionnaire, que ce soit niveau matériel ou logiciel.
Un écran un peu plus grand, un processeur plus puissant, plus de ram, … Il y aura peut-être la 4G de la partie, mais très sincèrement, je doute que ça change la vie (surtout vu son déploiement actuel).
Et il y aura d'autant moins d'effet de surprise que tout semble déjà connu sur l'iPhone 5. Ok, peut-être pas son nom.
[^] # Re: Bientôt vendredi
Posté par flan (site web personnel) . En réponse à la dépêche Le point sur udev et systemd. Évalué à 1.
Je trouve tout de même l'argument vraiment très faible. Ils n'aiment pas le XML ? Pas grave, soit ils utilisent du JSON (correctement indenté, ça passe sans problème), soient ils forkent simplement plistlib pour qu'elle accepte du YAML en plus du XML, du JSON et du binaire. C'est quand même beaucoup moins compliqué que de tout recoder uniquement parce qu'ils trouvent que le plist en XML n'est pas assez lisible…
Sur OS X, tous les fichiers de données des applications (sauf évidemment les outils UNIX historiques) sont soit en plist, soit en sqlite. Ça concerne aussi bien les fichiers de configuration que les fichiers de préférences ou que les fichiers de description d'une application (l'équivalent du .desktop linuxien). À l'usage, c'est très confortable.
Aucun parseur à écrire, une bibliothèque existe dans à peu près tous les langages (c'est même de base dans Python), un programme peut lire les fichiers de configuration et de données de n'Importe quelle application, il y a quelques éditeurs graphiques pour les modifier (XCode en propose un, par exemple), …
Actuellement, faire un programme qui va lire et modifier les configuration de trucs comme Apache ou OpenLDAP est plutôt galère, il faut réécrire un parseur sans savoir si on a pensé à tous les cas… Rajouter et supprimer via un script une entrée dans le crontab est assez périlleux à mes yeux. Avec des fichiers en plist, ces opérations seraient extrêmement simples.
Après, le côté XML peut rebuter un peu (même si à l'usage, ce n'est pas si gênant). Mais comme déjà dit, il suffirait de rajouter un autre format plus humain à plistlib, et ce n'est vraiment pas compliqué…
[^] # Re: Sandboxing et moindre privilège
Posté par flan (site web personnel) . En réponse au journal Un article sur le sandboxing de Chrome sous Linux. Évalué à 6.
Non, tu dois confondre avec autre chose, ou alors c'est l'expression bac-à-sable qui est trompeuse.
Si on met une application dans un bac-à-sable, ce n'est pas pour jeter ce qu'elle fait (faire des tests, donc), mais simplement pour qu'elle fasse ce qu'elle veut (y compris du travail utile, genre naviguer sur internet, écrire un texte, …) à l'intérieur de son bac-à-sable.
Si elle veut prendre un seau ou une nouvelle pelle, elle doit demander aux parents et ce sont eux qui acceptent et qui amènent les objets (comprendre : elle passe par des API système pour accéder aux autres ressources systèmes comme le système de fichiers).
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par flan (site web personnel) . En réponse au journal udev forké. Évalué à 5.
Pour moi, le chantage, c'est quand tu forces quelqu'un à faire quelque chose, en le menaçant de lui faire autre chose s'il n'obéit pas.
Là, je ne vois pas trop quelle est la menace brandie en cas de désobéissance, alors que c'est tout de même l'élément le plus important du chantage.
[^] # Re: Faut-il changer d'OS?
Posté par flan (site web personnel) . En réponse au journal Pour Miguel de Icaza, Linux (sur le Desktop) est mort !. Évalué à 7.
C'est curieux, je trouve qu'OS X est justement le système où il y a le plus d'interactions entre applications.
Le framework Cocoa permet d'avoir au niveau système énormément d'API utilisées par la plupart des applications ainsi que des formats d'échange communs :
- contacts (la même API est utilisée pour tous les contacts, qu'ils soient locaux, ou stockés via CardDAV, Exchange, LDAP, Yahoo!, iCloud),
- calendriers (même chose),
- mails,
- musique,
- favoris internet,
- photos,
- filtres d'image (fichiers .qtz, applicables sur des photos que des vidéos, ou comme animations en économiseur d'écran),
- mots de passe et certificats (une seule application pour tout gérer, et permettant de recréer des certificats),
- dictionnaire, correcteur orthographique et grammatical et autocorrection,
- reconnaissance et synthèse vocale,
- glisser-déposer d'une application à l'autre (on glisse l'icône du fichier ouvert — visible dans la barre de titre — dans une autre application, et ça marche),
- sélecteur de couleurs et de polices de caractères,
- pilotage des applications en Automator, AppleScript, Objective C, Python, Ruby,
- fichiers de configuration (format .plist - toutes les applications OS X utilisent le même format pour les fichiers de conf' ! ) et de stockage (bases sqlite3),
- sauvegarde (TimeMachine n'est pas limité aux fichiers, on sélectionne le carnet d'adresse, on lance TimeMachine, et on peut retrouver des contacts effacés),
- recherche indexée (pour indexer convenablement de nouveaux types de fichiers),
- synchronisation via iCloud
- changement des raccourcis clavier de n'importe quelle application.
Le système est encore loin d'être parfait, et c'est notamment dommage que la synchro ne se fasse que par iCloud. Mais je vois difficilement comment peut-on dire qu'il n'y a pas de fortes interactions entre applications…
[^] # Re: BSD
Posté par flan (site web personnel) . En réponse au journal Linux-only ; et BSD ?. Évalué à 1.
Je t'avoue que je n'ai aucune idée des raisons qui poussent les gens à acheter un Mac, et à moins que tu aies des chiffres précis, je ne vois pas trop l'intérêt d'en parler.
Je dis seulement que ce qui fait la plus-value d'OS X (quels que soient les avantages ou inconvénients du système), c'est avant tout le framework Cocoa. Si tu l'enlèves, tu te retrouves avec un UNIX tout ce qu'il y a de plus classique, sans intérêt particulier par rapport aux autres.
Même si tu mettais Linux ou NT à la place de Mach (modulo les « quelques » problèmes techniques), presque personne ne s'en rendrait compte. Par contre, si tu enlèves Cocoa, la situation risque d'être différente.
(par contre, si quelqu'un pouvait changer HFS+ par un vrai système de fichiers, ça serait une bonne idée)