flan a écrit 1848 commentaires

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)

Le nom d'origine est Preview, Aperçu dans les versions francophones d'OS X.

Au passage, je ne vois pas où le sondage précise qu'on ne parle que de logiciels libres ou disponibles sur Linux…

J'imagine quand même que les employés ne décident pas eux-mêmes de la licence des produits qu'ils développent pour le boulot.

Google fait de l'ouvert quand ça les sert, du fermé quand ça les sert. Aucune histoire d'idéologie ou autre là-dedans…

La principale source de revenu de Google, c'est la pub, et pour ça, il faut :
- que tout le monde utilise les services Google (pour collecter des renseignements afin de mieux cibler les gens),
- avoir les meilleurs systèmes de traitement chez eux pour traiter les renseignements collectés,
- avoir les meilleurs services.

Bref, pour le 1, il vaut mieux avoir de l'open-source :
- c'est gratuit,
- même si on forke le logiciel, il y a des chances que les pointeurs vers les services Google restent dans le fork

Pour le 2 et le 3, il vaut mieux avoir du 100% proprio. Ça tombe bien, on ne peut pas dire que Google libère beaucoup le code de GMail, de PageRank, ou autre…

Idem, j'ai reçu cette semaine un premier spam sur mon adresse SFR. Ayant mon nom de domaine et un catch all, cette adresse est unique à SFR, et je ne recevais d'ailleurs plus rien vu que je ne suis plus abonné chez eux depuis 6 mois.

Il n'y a pas que le thème (relativement facile à émuler), ou le comportement (déjà plus complexe).
Ceci dit, si Qt, GTK, Win32 et Cocoa ont beaucoup de choses en commun (genre les boutons, les listes, les arbres, …), certains composants n'existent que sur une des plates-formes.

Il y a également l'intégration avec les services proposés (ou non) par l'OS.

Par exemple, je m'attends à ce qu'une appli utilise les API du système pour des choses aussi diverses que les certificats, mots de passe, contacts, calendriers, mails, proxy, …
Je trouve énervant d'avoir accepté une CA au niveau système, et qu'Opera ou Firefox ne la prenne pas en compte.

Y a aussi d'autres choses : sous OS X, les préférences sont stockées au format plist dans ~/Library/Preferences/nom_dns.plist. Sur Linux, ça sera plutôt dans ~/.nom_quelconque.
Toute l'application sera un dossier structuré sur OS X, et plutôt un binaire sous Linux, avec des fichiers un peu partout…