flan a écrit 1830 commentaires

À ce propos : avec Linux, le chemin n'est qu'une suite d'octets. C'est à l'application de savoir quel est l'encodage utilisé, et tu peux tout à fait avoir dans le même dossier des fichiers avec différents encodages.
Avec OS X, le système de fichiers (ou le noyau ?) impose l'utilisation d'un encodage (et d'une normalisation Unicode) bien précis.
Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).

Merci pour l'info, ça a l'air vraiment pas mal !
Je souffre à chaque fois que je dois faire du JS, et il y a des chances que je doive recoder une appli en Python + Qt (avec PySide) en JS…
Je me demande si je ne vais pas essayer avec Brython.

Ce qui te dérange, c'est surtout que des gens se sont mis ensemble et ont eu du succès.

C'est pratique, tu sais mieux que moi ce qui me dérange ou pas. Je me demande comment tu fais…

Au passage, non, ce sont les méthodes employées et les conditions de travail de leurs employés qui me dérange ; si les libraires s'unissent et qu'ils utilisent les mêmes méthodes, ça ne m'intéresse pas ; je pensais avoir été suffisamment clair en disant que les mauvaises conditions de travail me dérangent, mais manifestement non. Je ne comprends pas trop ce qu'il y a de compliqué là-dedans, pourtant.

Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode, simplement parce que ça reste vrai : l'utilisateur tape un caractère « è », il est représenté dans le système de fichiers par de l'UTF-8 (ou de l'UTF-16/-32), même si la normalisation qui pose problème se fait au niveau de l'Unicode. Le conflit n'existe pas en Latin-1, parce qu'il n'y a qu'une seule façon de représenter le « è » (et qu'il n'y a pas d'histoire de normalisation NFKD/NFKC en amont).

De plus, tant qu'on parle d'Unicode, les deux versions (« è » et « e + ` ») doivent être comparées comme étant égales par le logiciel. Par contre, quand elles sont encodées (en UTF-8) et que ça devient des séries d'octets, les deux versions sont différentes (Linux ne considère que des séries d'octets, sans prendre en compte que c'est de l'Unicode) et à ce moment là, on a un souci (deux fichiers avec un nom identique).

Mais bon, c'est vrai que c'est totalement hors-sujet de parler UTF-8 au lieu d'Unicode, il n'y a strictement aucun lien entre les deux. Mea Culpa.

Personnellement, je connais des libraires, et leurs conditions de travail sont quand même bien meilleures que celles des employés de base d'Amazon (qui ne gagnent pas 100k$/an, mais bon, c'est tellement pertinent de se concentrer sur les quelques ingés en ignorant le reste des employés…).

C'est tout de même totalement idiot (ou de mauvaise foi, au choix) de dire qu'une boîte comme Amazon a les mêmes armes qu'un libraire classique :
* pas le même pouvoir de négociation avec les éditeurs (certains doivent vendre à perte à Amazon sous peine d'être exclus et donc de perdre toute visibilité),
* pas le même pouvoir de négociation avec les transporteurs (plus le volume est important, moins tu paies),
* pas le même pouvoir de négociation avec les États pour les impôts,
* pas le nombre d'avocats pour trouver la meilleure optimisation fiscale,
* pas le même pouvoir de négociation avec les États pour avoir des subventions quand ils s'installent quelque part,
* possibilité de pressurer les employés au maximum en les payant un minimum.

Plus il y aura de grosses boîtes comme Amazon, moins les conditions de travail (pour les employés de base) seront bonnes. Je ne pense pas que ça te dérange plus que ça, mais personnellement ça m'empêche de faire la moindre commande à Amazon ; je ne veux pas subventionner un système que je n'aime pas.

3/ les Américains n'étaient pas au courant de leur existence et ils les ont trouvées bien trop tard et par hasard vu que les preuves qu'ils ont présentées étaient bidon. Ce n'est pas la seule fois où ils ont données de fausses preuves : ils avaient déjà essayé de montrer sur des images satellites un mouvement de troupes irakiennes allant vers l'Arabie Saoudite (de mémoire), alors qu'elles allaient dans la direction opposée…
Ce n'est pas pour rien que la France a décidé en 1995 de se doter de satellites d'observation : c'est parce que les images américaines n'étaient pas fiables.

Ça ne m'étonne pas que Mercurial ait vu le souci : ils ont l'air de se poser beaucoup de questions sur le sujet, tout comme les problèmes de collisions avec les fichiers qui ont des noms UTF-8 : il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être stocké comme un « è » ou comme un « e + ` »). Sur Linux, on aura donc plusieurs fichiers avec exactement le même nom (et de façon indiscernable pour l'application), alors que sur OS X le système de fichiers est normalisé (NFKD de mémoire) et il y aura un seul fichier (Windows est comme Linux, je crois).

Le typage dynamique est super pratique de temps en temps !
Mais 99% de mon code pourrait être typé statiquement sans problème. D'ailleurs, j'aimerais vraiment un Python typé statiquement par inférence de type.

À mon avis (basé sur assez peu de choses, je le reconnais), l'admin sys Linux moyen est nettement plus compétent que l'admin. sys Windows moyen, ne serait-ce que parce qu'il est beaucoup plus facile de s'improviser admin sys Windows (en cliquant suffisamment partout, on peut arriver à faire tomber en marche le système, sans comprendre ce qu'on a fait).

Je pense que tout le monde a connu des gens qui se sont improvisés experts Windows simplement en étant un peu moins mauvais que leur entourage.

Et entre les mains d'admin compétents et bien formés  ?

La seule chose à faire avec un mauvais admin, c'est de lui enlever les droits root en attendant qu'il soit bon ; il fera des catastrophes avec n'importe quel OS, GPO ou pas.

Parce que le HTTP permet beaucoup d'autres choses sans avoir à les recoder dans leur protocole maison, et ça va bien au-delà de binder des ports TCP sur 0.0.0.0 :

• nouvelles méthodes d'authentification (Apache ou Nginx permettent beaucoup de choses à ce niveau-là),
• utilisation de proxy (proxy directs ou reverse proxy),
• réutilisation de ports déjà ouverts sur les différents firewall,
• possibilité de faire du MITM pour la sécu…

mais je me demande toujours ce que ça donne en termes de perfs.

En effet, mais ça dépend de la méthode : faire du SSO avec kerberos est assez facile pour un client lourd, mais les méthodes genre Shibboleth sont nettement plus dures à passer (redirections multiples, utilisation de cookies, javascript, …).

La synchro HTTP est vraiment la bienvenue, ça aidera pas mal quand il est compliqué de faire ouvrir un port supplémentaire. En revanche, je me demande si la synchro HTTP est aussi performante que la version précédente.

Il manque encore l'authentification via HTTP (par exemple en se basant sur un header HTTP, au hasard REMOTE_USER). Ça permettrait d'avoir facilement pas mal de nouvelles méthodes d'authentification comme Kerberos.

Et parce que le port de nginx ne sera pas ouvert, peut-être ?
Concrètement, qu'est-ce que ça change que le port soit ouvert à travers Nginx ou directement par Seafile ?

Si tu fais référence à Sivens, ce sont des grenades offensives (et non défensives), qui ne sont pas spécialement dangereuses. 2 262 grenades de ce type ont été utilisées entre 2010 et novembre 2014 lors de manifestations, et je ne crois pas avoir entendu parler d'autant de morts.

Quand ce n'est qu'un fabricant de mobile qui pousse une techno (propriétaire), oui, il y a beaucoup de chance que ça plante.
Quand ils sont plusieurs à pousser un même OS libre sur leur matos, tout de suite, ça va beaucoup mieux. La preuve avec Android.
On mettra Apple à part, car ils ont su innover au niveau ergonomie.

Il est dur de généraliser à partir de 4 ou 5 exemples, surtout quand il y a presque autant d'exceptions que de cas réguliers, mais je ne suis pas sûr que le côté « libre » d'Android ait été pour quelque chose dans sa réussite. Je pense plutôt que c'est le « petit » coup de pouce de Google qui a aidé.
Google a choisi Linux parce qu'ils n'avaient rien à payer, qu'il répondait aux critères de choix et parce qu'ils pouvaient en faire ce dont ils avaient besoin, mais les fabricants ont choisi Android parce que c'était le choix de Google.

Et si ils ont abandonné les web-apps, c'est plutôt parce que ça les empêchait de contrôler ce que l'utilisateur pouvait installer, et donc monnayer l'installation des applis.

Je n'ai pas entendu parler de beaucoup de webapps sur iPhone quand il n'y avait que ça de possible. Par contre, les applications ont eu beaucoup de succès, alors que c'était un nouveau framework ET un nouveau langage (Objective-C) pour la plupart des développeurs.
D'ailleurs, il est toujours possible de faire des webapps sur iPhone. Pourtant, personne (ou presque) n'en fait.

Ça me rappelle un certain slogan : « write once, run anywhere », mais sans les perfs.

Je comprends pas, l'appli n'envoie pas plus d'info personelle si elle hostee par un serveur qui t'appartient. Un nignx, un cdn devant et ca roule, t'as pas besoin de plus. Mozilla pourrait meme proposer ca en service (gratuit ou payant, ca les regarde ça).

Une application en natif peut ne pas communiquer du tout ;-)

Ensuite, on est en droit d'esperer que firefox vise les developeurs pro, et pas pinpin qui a ecrit la 4200ieme calculatrice sur le store, telechargee par lui meme et sa maman. C'est pas delirant de demander que les developeurs web sachent configurer un serveur statique.

Les développeurs pro sont justement ceux qui vont vouloir gagner de l'argent avec leur application : autant partir sur les plates-formes qui maximisent le profit : Android et iOS.

Imaginez quelqu'un qui n'a même pas la 3G attendre la fin du chargement du pps rigolo de 5 Mo qu'un ami lui a envoyé pour pouvoir lire le mail urgent qu'il attend !

Tous les clients que j'ai utilisés proposent de ne pas télécharger les pièces jointes automatiquement.

Donc j'ai encore l'espoir que même si Firefox OS a du mal à percer, des jeux seront cependant proposés car ça coûte rien de les mettre à disposition s'ils ont été développés en HTML/JS.

Mais d'un point de vue du client, s'il n'y a aucune exclu à Firefox OS vu que toutes les applis sont par nature portables, autant rester sur iOS/Android/WindowsPhone : ils auront les applis de leur plate-forme en plus de celles de Firefox OS.

C'est même rien par rapport au prix du matériel (la plupart du temps). En revanche, c'est souvent un obstacle pour tester. C'est souvent plus facile de justifier une dépense en disant qu'on a comparé avec le reste et que ça vaut largement le prix qu'en se basant uniquement sur le site web (on a souvent des déceptions).

En effet, c'est bien Spotlight.

Je n'utilise absolument pas le côté social (à vrai dire, je ne vois pas trop ce que c'est) mais très souvent le moteur d'indexation. Au début (en 2005), je l'utilisais assez peu, mais maintenant très souvent, que ce soit pour ouvrir un programme (en ne tapant que les deux voire trois premières lettres), trouver un fichier (avec le début de son nom ou un mot à l'intérieur) ou pour d'autres petites opérations. La barre de recherche est accessible avec un raccourci clavier (sinon, ça perd tout son intérêt), et me permet d'accéder à bien plus que mes fichiers vu qu'il essaie de trouver l'opération la mieux adaptée à ma requête :

• nom d'une personne pour avoir son adresse ou passer un appel (audio / vidéo / SMS),
• somme d'argent (par exemple 12€) et conversion dans quelques monnaies (comme les dollars et les livres),
• opération mathématique,
• mot dont je veux la définition dans le dictionnaire,
• rechercher dans les mails, l'historique internet, le calendrier,
• rechercher la page wikipedia.

En pratique, il arrive bien à deviner quelle réponse il doit proposer en premier (même si les autres sont bien évidemment accessibles).
Bien sûr, ça ne m'empêche pas d'avoir des dossiers bien rangés, mais les parcourir à la main reste plus lent, même en sachant exactement où est le fichier et quel est son nom.

C'est le principe d'un investissement : tu fais une dépense instantanée qui sera rentabilisée (ou pas) plus tard.

Accessoirement, la performance de l'OS n'est qu'un des critères de choix. Pas mal d'autres critères entrent en compte : les petites habitudes des développeurs qui vont utiliser ces machines (s'ils sont tous linuxiens/unixiens, ils ne vont pas prendre du Windows), certaines possibilités de l'OS (je pense notamment à SSH, très utilisé dans ce monde-là et qui n'a pas de véritable équivalent sous Windows), un écosystème logiciel beaucoup plus développé que sous Windows (pour le HPC), …
De plus, je pense que l'absence de ligne de commande correcte a fait très mal à Windows pour les clusters, PowerShell est arrivé assez récemment pour enrayer le phénomène.