dave_null a écrit 358 commentaires

C'est très difficile pour un produit d'avoir une position ultra dominante sur un marché. Il faut répondre à tout les besoins et c'est impossible.

Le plus simple est de multiplier les références même si c'est le même groupe derrière. En cosmétique, L'Oréal est un bon exemple. Dans l'industrie automobile, Renault-Nissan aussi.

Pour le marché des navigateurs et du point de vue de Google, le plus simple est de financer Mozilla. Et c'est mieux pour l'image que de racheter Mozilla.

Effectivement c'est pas vraiment bon joueur.

Si je comprends bien le reproche est que Canonical peut faire du propriétaire grâce au CLA malgré la licence GPL.

Ça veut dire que l'on est encore une fois dans un troll BSD vs GPL ?

J'étais moi aussi dubitatif sur RDP, puis j'en ai eu besoin récemment. Le son et le presse papier (et pas juste du texte) sont gérés correctement. Plus intéressant pour moi, c'est aussi le cas de l'accélération graphique.

Je peux jouer à Minecraft avec RDP en Full HD sur une connexion 100mbits/s, et ça fonctionne bien avec une faible latence. Le protocole est assez intelligent pour mettre à jour seulement ce qui change et adapter la qualité de la transmission à la volée.

Plus concrètement, on peut travailler comme en local sans ralentissement, quel que soit le type de l'application, son toolkit et son thème graphique. La seule différence visible est des artefacts de compression type jpeg sur certains éléments quand ça bouge vite.

Quand je pense à la lenteur de X11, les problèmes de sécurité (on peut utiliser SSH mais ça consomme du CPU), les problèmes en cas de perte de connexion ou de sortie de veille, son incapacité à être utile dans un contexte multimédia, de pouvoir fonctionner avec une application qui n’envoie pas de données vectorielles… je ne le regrette pas.

X11 a été très utile mais il date d'une autre époque où les usages étaient bien différents.

La personne est très forte pour être inconnue sur Google, mis à part ce mail. Et vu les compétences que demande l'anonymat sur internet et le fait que son seul message visible est ce mail consternant, ce qui est débile si on fait attention à son image publique, je pense que c'est une identité créée pour l'occasion.

Oui mais le modèle est différent, Android est un OS mobile avant tout.

Toutes les interfaces sont à réécrire, les applications qui tournent en tache de fond ne sont plus la bonne façon de faire.

J'avais oublié mais dans la liste de mes applications natives j'ai aussi Vim et c'est une horreur de le voir se faire killer par Android sans qu'il puisse rien gérer. J'imagine que convertir Vim au modèle de services / évènements / interfaces d'Android est un travail énorme.

Du coup ce qu'il reste, c'est les algorithmes et des petites librairies. Mais est-ce vraiment intéressant de tout réutiliser ? Personnellement, il m'est arrivé de regarder le code source de OpenOffice ou Thunderbird pour comprendre et réutiliser des algorithmes. Mais au final il était souvent bien plus simple de réécrire juste la partie intéressante avec le langage de mon application que d'essayer d'intégrer à coup de masse un code C++ historique.

Il y a quand même iOS avec son Objective-C qui est esthétiquement une abomination à faire passer le C++ pour un langage de programmation limpide et lisible.

Je pense que l'on pourrait publier des articles reliant le syndrome de Stockholm et les développeurs Apple.

[Edit: grillé :D]

Certes, mais tu veux porter quoi en dehors des gros projets ? Android n'a pas besoin des applications de bureau classiques, c'est un nouvel OS avec de nouveaux concepts et de nouvelles interfaces utilisateur.

Ils partent sur quelque chose de neuf et ça fonctionne.

À part quelques gros projets qui visent les performances ou la réutilisation d'un code existant, très peu d'applications sont natives sur Android. Vu le nombre de périphériques, d'architectures différentes, le natif n'est pas la solution conseillée à moins d'en avoir vraiment besoin.

Sur ma tablette par exemple j'ai VLC, Firefox et un poc d'OpenOffice en natif. Et pour Firefox ils dessinent l'interface en Java pendant que le gros morceau en C++ se lance.

À cotés de ça, tu peux développer en Java avec un toolkit qui n'est pas très impressionnant mais qui fonctionne bien. Tu peux aussi faire du C# avec Mono, du HTML5/JavaScript, du QML/JavaScript (pas testé) et certainement plein d'autres choses. Même pour les jeux vidéos le natif n'est pas à la mode. La plupart sont en Java ou développés avec l'excellent mais pas libre framework Unity (qui n'a rien à voir avec Ubuntu). Et quand tu codes pour ton jeu Unity, c'est du C# avec Mono.

En esperant que ca ne tourne pas au drame qu'est Android !

Je trouve qu'Android apporte quelque chose. Et ce n'est pas plus mal de se débarrasser de tout l'aspect GNU/Unix pour proposer quelque chose de neuf et moderne. Après c'est beaucoup moins libre et totalement dirigé par Google, peut-être que ta critique était à ce sujet.

Cette histoire, ça fait un peu «J'ai demandé à mon GPS de me guider chez ma tante. Je me suis retrouvé par hasard au milieu d'une zone militaire secret défense sans avoir rencontré une seule barrière. Du coup j'ai photocopié et pris en photo tout ce que je pouvais prendre.»

Résumons :

Le bien

• Linux
• Debian
• Wayland

Le mal absolu

• Les utilisateurs non experts en développement et administration de système d'exploitation
• Les gens qui font des produits pour ces utilisateurs
• Les gens du marketing
• Et tout les produits développés par Canonical en général (Mir, upstart, Unity…)

Je suis d'accord avec ton analyse sur le fait que développer Mir et une erreur, et je préfère SystemD à Upstart moi aussi mais je ne pense pas que la haine soit la solution.

C'est pas un échec OpenID ? http://linuxfr.org/users/fravashyo/journaux/fin-de-myopenid-com-le-1er-fevrier (ou la page wikipedia qui peut se permettre d'avoir une liste de sites compatibles : http://fr.wikipedia.org/wiki/OpenID )

Oui je n'en ai pas besoin, mais je peux le faire et je trouve ça plus pratique que de switcher entre les bureaux ou fenêtres. Pourquoi m'en priver ? :)

J'utilise déjà des mods Vim et un clavier bépo donc je dois avouer qu'un bras en plus serait pratique (puis sexuellement ça peut être marrant).

Enfin en général le 21/9 a un IDE en plein écran avec trois fichiers (trois fichiers c'est pas si énorme que ça quand tu fais de la POO avec une classe par fichier). Et le deuxième écran sert à avoir la documentation, les mails, les réseaux sociaux et compagnie…

La nouvelle police d'écriture sur la version mobile est excellente. La lisibilité est bien meilleure et en plus l'écriture est jolie :-)

La résolution verticale est la même qu'un écran 16/9 Full-HD (1080 pixels) donc les barres ont de la place. Un dock/barre des taches à gauche de l'écran à la Unity est la seule optimisation nécessaire selon moi.

Il faut plus voir ça comme une alternative à un double écran. Et d'ailleurs, j'ai un 16/10 en deuxième écran à cotés et sa résolution verticale est de 1050 pixels, ce qui est plus faible.

Ça permet d'éditer plein de fichiers en même temps tout en ayant encore beaucoup de marge visuellement.

Je pense que c'est surtout une question d'habitudes. Je travaille avec un 21/9 et je trouve ça très pratique.

Oui mais là on parle du démarrage. En hibernation, windows 8 est aussi très bon. Je n'ai aucune idée de comment il fait mais j'ai 16go de ram et la reprise est instantanée même après 3 mois sans électricité.

C'est peut-être plus productif à court terme, mais à long terme je pense que même sur du backoffice c'est un mauvais calcul.

L'exemple que je connais le mieux est le backoffice de AirFrance. Ils ont une architecture orientée service très complète et belle techniquement (bien qu'un peu lente), qui pourrait parfaitement exposer au web des belles API REST avec un peu de travail.

Actuellement ils ont des espèces de «choses» Java J2E qui font un gloubi-boulga entre plein de services et des interfaces HTML-IE6 développées de manière certes productives mais in-maintenables.

La logique des vues est totalement explosée entre le serveur et le client avec des états dans tout les sens, c'est quasiment impossible à tester efficacement et à faire évoluer sans repartir de zéro. Le problème, c'est que ces gloubi-boulga contiennent désormais beaucoup trop de logique métier pour pouvoir évoluer à faible coût.

Une séparation API REST/Web aurait imposé de créer la logique entre les services cotés serveur une bonne fois pour toute et simplifier le développement cotés client. Après c'est une façon de faire nouvelle et la plupart des applications concernées datent de la sombre époque PHP/MySQL/HTML/JavaScript dans un seul fichier.

Pour ma part je suis assez mitigé sur les frameworks qui veulent abstraire tout le html/javascript.

En général, le résultat est quelque chose de lourd et opaque que l'on ne maîtrise pas. Et dans une application web ce qui compte c'est l'interface utilisateur. Donc laisser le contrôle de l'interface utilisateur à quelque chose que l'on ne maîtrise pas, c'est un risque.

Je vois une architecture web comme ceci :

• Backend
  • API HTTP REST, ou API WebSocket, dans une technologie quelconque, ce n'est pas important pour les développeurs de l'application web et les utilisateurs
• FrontEnd
  • Interface HTML avec moteur de template quelconque
  • JavaScript ou un autre langage qui se compile en JavaScript
  • CSS avec pré-processeur quelconque (SASS, Less…)

Globalement, cela permet de garder la maîtrise du HTML, qui est selon moi bien plus pratique à utiliser que les déclarations d'interfaces dans les langages de programmation. Même chez les développeurs Qt, la tendance est à utiliser un langage déclaratif pour les interfaces avec Qt Quick au lieu de se taper des centaines de lignes de code inintéressantes en C++.

Pour finir, AngularJS est selon moi excellent car il permet de maîtriser le HTML tout en offrant un système de templates et de composants très performant et particulièrement adapté au gros projets.

Oui le Dell est plus cher.

Il est temps d'investir dans un bon SSD. Windows7 démarre en 20 secondes et Windows 8 en quelques secondes.

Tout s'achète.

Je pense que pour le macbook air c'est aussi pour des questions de place/design/coût. J'ai un Dell E6230 et par rapport au macbook, ce n'est pas la même classe (ni le même écran).