flan a écrit 1805 commentaires

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).

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.

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)

Une des principales raisons pour acheter un Mac, c'est OS X (tout dépend des gens, évidemment, mais la plupart de ceux que je connais qui ont pris un Mac l'ont fait avant tout pour O X, en toute connaissance)…
Et quand on choisit OS X par rapport à Windows et Linux, surtout quand on a eu un Linux, c'est généralement pour des avantages qui viennent du framework Cocoa. Pas besoin de savoir comment ça fonctionne ni comment ça s'appelle pour connaître certains points forts (et points faibles, toussa).

OS X n'a pas grand-chose en commun avec BSD. Le noyau est différent (OS X a un noyau Mach), seule une partie des outils autour du noyau sont repris de BSD. Quant au framework Cocoa (qui fait tout l'intérêt d'OS X par rapport aux autres OS), il est fait maison par Apple (bon, d'accord, et aussi par NS avant son intégration dans Apple).

Le dernier logo d'Apple n'a pas l'air d'être officiel, leur site officiel n'utilise qu'une version monochrome.

Linux possède un certain nombre d'avantages par rapports à BSD (et par rapport à Windows, OS X, HP-UX, …), et se forcer à être compatible avec tout le reste signifierait faire une croix sur ces avantages (tout du moins certains d'entre eux). Ça serait un peu dommage de s'embêter à les développer si c'est pour ne pas les utiliser après.
Personnellement, ça m'embêterait un peu que dans mon OS préféré, les applis n'utilisent plus toutes les API du système sous prétexte qu'on ne peut pas faire la même chose sur les autres OS ; je perdrais tout l'intérêt que j'ai à utiliser cet OS-là et pas un autre.

C'est bien d'être compatible avec tout le monde quand on peut, mais il ne faut pas non plus en faire un dogme inviolable sous peine de ne plus évoluer et ne plus se différencier.

Mais bon, de mon côté, j'ai toujours préféré utiliser des normes au niveau des protocoles et des formats de fichiers qu'au niveau de la tambouille interne :D

C'est un argument qui revient très souvent quand on parle d'iOS, qui ne dispose pas de navigateur de fichiers.

Mais je n'ai jamais été convaincu : au final, on se retrouve à avoir toujours des besoins de tri, copie, déplacement, renommage, suppression (etc.) des documents. Au final, chaque application se retrouve à réinventer la roue et à avoir son propre navigateur de documents.

Au final, voilà ce que ça apporte :
* des gestions de documents complètement incohérentes entre elles (telle appli permet de dupliquer, mais pas telle autre, etc.)
* des galères monstrueuses pour utiliser des documents de différentes natures
* lancement de l'application gérant les XXX pour utiliser XXX dans YYY
* des documents d'un même type qui sont répartis à travers toutes les applications qui gèrent ce type de document

Tout d'abord, je n'ai jamais dit que le système d'OS X Server était parfait, loin de là.
Et évidemment, quand tu maîtrises le sujet, tu peux avoir une meilleure installation… C'est vrai dans tous les domaines, ça. Un garagiste n'aura pas de problème à bichonner sa propre voiture, un cuisinier mangera plutôt bien et pour moins cher, un admin sys aura un meilleur serveur.

Cependant, Apple montre qu'il n'y a pas besoin d'être admin sys pour mettre en place un système relativement complexe, avec VPN, mail, calendrier, … chaque service étant basé sur Kerberos, LDAP et SSL. Si tu veux un truc complexe, il faudra bien sûr mettre les mains dans le cambouis à un moment ou un autre, mais on voit qu'il est possible de fortement repousser cette frontière.
Sur Linux, le niveau requis pour avoir installer l'équivalent de ce que propose OS X Server est beaucoup plus élevé (et non, tout le monde ne sait pas installer des services, contrairement à ce que tu dis).

C'est pourtant faisable ; OS X Serveur (avec la version 10.6 Snow Leopard) permet d'installer très facilement un serveur de mail, calendriers et carnet d'adresse, le tout sécurisé avec du SSL (mise en place du SSL : une case à cocher) et authentification au choix par mot de passe (connecté à une base LDAP) ou Kerberos (idem, suffit de cocher la case) et un webmail.
Et pourtant, ils se basent la plupart du temps sur des logiciels dispos sur Linux (apache, dovecot, calendar server, openldap, heimdal kerberos) avec quelques couches maison. Seulement, l'interface graphique est vraiment bien fichue et rend l'installation très facile même sans être admin sys. Dommage qu'elle soit quand même bien bugguée :(

iWork a l'immense (à mes yeux) inconvénient de ne pas supporter correctement les formats classiques (OpenXML et OpenDocument). Tu peux exporter dans ces formats, mais ce n'est pas pratique de travailler avec.

• Il y a parfois des bugs dont on se rend compte et dont on entend parler.
  Il est tout à fait possible que pas mal d'algos (et leurs implémentations) soient franchement bugguées, mais que ça ne se sait pas. Si une boîte fait -1% ou -2% à cause d'un algo foireux, personne ne s'en rendra compte vu que tout le monde peut mettre ça sur l'aléatoire « normal » de la bourse. Par contre, quand elle fait -99%, c'est tout de suite un peu plus visible…

• Tu peux avoir des bugs qui n'arrivent que quand n algos adverses (avec n grand, et chaque algo avec un comportement précis) se battent entre eux.

La barre de menus globale a tout de même plusieurs intérêts :
- gain de place,
- plus facile à viser à la souris : on « balance la souris tout en haut », et hop, on est bon,
- au moins, on sait où est le menu, quelle que soit l'application, vu qu'il est toujours à la même place.

Par contre, et c'est surtout vrai avec plusieurs écrans, la distance à parcourir à la souris peut être plus grande, et il faut savoir quelle fenêtre a le focus à l'instant du clic.

Personnellement, comme je suis souvent sur un portable en 1440x900, je trouve le gain de place apporté appréciable. Je n'aurais peut-être pas la même réaction si je bossais sur deux écrans en 2560x1600…

Et le cas des PDF ? Et si je cherche dans des .c ?

Je ne trouve pas spécialement futé d'avoir un moteur d'indexation pour la musique, un pour les photos, un pour les films, un pour les mails, … C'est quand même beaucoup plus pratique de tout indexer, quitte à réutiliser ce moteur centralisé dans tes applications.

Certains ont exactement le même problème, non avec les photos, mais avec des PDF ou de la musique.
* Pour la musique, si tu as classé (comme je le fais) par Artiste/Album/Chanson, comment fais-tu pour afficher les chansons jamais écoutées qui datent des années 90 ?

• Pour les PDF, même problème. Comment les trier ? Par auteur ? mais alors ce n'est pas pratique quand tu fais une recherche par thème. Par thème ? et si un PDF correspond à plusieurs thèmes ?

Pour utiliser un OS avec un système de fichiers indexé depuis maintenant quelques années (2005, je crois), je suis convaincu qu'un vrai explorateur de fichiers est nécessaire.

L'indexation est pratique car elle permet de chercher dans pas mal de sources de données (fichiers, mais aussi mails, calendriers, contacts, historique internet, …) pour trouver un objet unique. Exemples : retrouver le PDF d'un livre à partir de quelques mots-clefs du livre, un rdv dans ton agenda en te souvenant d'une personne invitée… Ça marche bien aussi en lanceur d'applications.

Par contre, à part ce cas (trouver un objet unique), l'indexation est franchement peu pratique :
- soit parce que le fichier n'est pas unique (des copies à peine modifiées existent)
- soit parce que tu veux travailler avec un ensemble de fichiers (un lot de photos avec du texte, les fichiers source d'un programme, …)
- l'indexation ne t'offre pas de garantie sur le résultat de ta recherche : tu archives de façon automatique tous les fichiers d'un projet pour le sauvegarder. Pour ça, tu choisis comme critère de recherche « extension:".pdf", contient: "TOTO" ». Manque de pot, tu télécharges un autre PDF qui n'a rien à voir, mais qui contient également TOTO. Pouf, tu vas l'archiver sans t'en rendre compte.
- accessoirement, il n'y a pas d'API simple pour que les programmes se servent de la recherche (*)

Bref, selon mon expérience, les deux sont complémentaires.

(*) Quoique… Avec Fuse, je peux faire un point de montage /Volumes/Rercherches, tel que le dossier /Volumes/Recherches/Extension:.pdf/Contient:TOTO contienne en permanence tous les fichiers qui correspondent à ces critères ^{^}

Quel Windows as-tu installé en dernier ?
J'ai essayé Windows 7, et je n'ai eu strictement aucun pilote à installer, tout était fourni de base (y compris les pilotes graphiques). D'ailleurs, ce n'est pas pour rien que Windows Vista et 7 sont si gros : ils arrivent avec plusieurs gigaoctets de pilotes.

Microsoft a tout de même bien travaillé sur son OS, et sur beaucoup de points Windows 7 n'a plus rien à voir avec Windows XP, y compris point de vue stabilité et rattrapages de plantages.
Je m'explique : sur Linux, mon X11 plante régulièrement (au bout de 15j) . Sûrement la faute des pilotes NVidia, mais ça tue X et je dois récupérer tous mes .*.swp créés par vim, y compris sur des machines distantes. Un peu pénible à chaque fois.
Sur Windows 7, un problème de pilote graphique se solde par un écran qui devient noir une demi-seconde, et tout continue comme avant, même si tu es dans un jeu. Pas besoin de relancer les applications.

Tout pareil, mais je ne vois pas l'intérêt de passer par un lecteur *en javascript*…
Ça fait des années que Safari sur Mac OS X sait ouvrir un PDF dans un onglet, je ne sais pas s'il le garde en RAM ou dans /tmp (à vrai dire, je m'en moque), mais je trouve ça très pratique. Par contre, le lecteur PDF d'OS X (à ma connaissance, Safari utilise le moteur de rendu PDF intégré à OS X tout comme il utilise le moteur de rendu HTML du système) est codé en code natif (Objective C, a priori) pour des raisons de performances.
Ouvrir un PDF un peu gros avec un lecteur JS me semble suicidaire…

Sur OS X, il y a quelque chose de fantastique : http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ukelele
Un petit utilitaire pour faire sa propre disposition de clavier, avec la possibilité de repartir d'une disposition existante.
On obtient un fichier XML qu'on met soit en global, soit dans son home et qui est utilisable immédiatement (pas besoin de fermer sa session, fort heureusement).

Personnellement, ça fait 5 ans maintenant que j'ai un AZERTY avec les chiffres d'un QWERTY, et |, \, _, # en accès direct (à la place de ù, °, -, @). Pour faire du LaTeX, avoir directement le \ change la vie :D

Sur iOS (je ne connais pas Android), l'application par défaut pour les courriels fait de l'IMAP ou du POP avec du SMTP, avec la possibilité de faire de l'Exchange (un poil moins libre que l'IMAP, mais pas ce n'est quand même pas du REST me semble-t-il). Par défaut, on peut sélectionner iCloud, Gmail, Yahoo!, Aol ou Hotmail (ou autre), mais ça évite simplement d'entrer les réglages des serveurs, une fois configuré on obtient de l'IMAP ou du POP.

Ça me fait pas mal penser d'une part au protocole Bonjour / Zeroconf (très utilisé par les produits Apple, notamment), et d'autre part à l'autoconfiguration dispo sur les Mac.
Exemple : j'ai un compte local toto sur un OS X client, que j'ai installé en dehors de mon réseau local. Sur mon réseau local, j'ai un serveur OS X, avec pas mal de services (mails, calendriers, carnet d'adresse, jabber, par exemple).
Automatiquement, l'OS X client détecte que :
- il y a un OS X server sur le réseau local
- le compte toto y est également défini
- il y a les services mails, calendriers, carnet d'adresse, jabber (…)
- il propose de configurer les logiciels correspondant

Pour info, Zeroconf permet d'annoncer sur un réseau local à peu près n'importe quel service, (ldap, http, imap, streaming audio ou vidéo, ssh, ftp, imprimantes, …).
Le plus simple serait de s'inspirer de Zeroconf (qui remplit plutôt bien son rôle, mais qui est limité au réseau local) pour le rendre utilisable sur un réseau global.

Je trouve également que ça ne vaut pas forcément le coup de préciser les méthodes d'authentification lors de l'annonce du service :
- elles peuvent être annoncées lors de la connexion (HTTP)
- les différentes méthodes connues peuvent être essayées (c'est le cas avec certains clients mail récents)