Donc tu préfères utiliser 100% du temps le même language, quitte à avoir 100% de ses inconvénients sans aucun des avantages dans 99,9% des cas :)
Nan mais pkoi pas, t'assumes c déjà bien :)
Sinon tu as des alternatives entre les 2, qui te laisse jouer avec des void * après avoir indiqué au compilo que t'étais un warrior avec un -unsafe, mais je citerai pas de nom au risque de réveiller un autre troll ;)
Plus tu ajoute d'étape (et de couches) moins la solution me semble pertinente, du point de vu performance comme de la maintenabilité.
Ce qui coûte en performance, ce n'est pas le fait d'ajouter de "couche", mais d'ajouter des services : GC, contrôle d'accès aux ressources, etc.
Grosso modo la VM .Net émule une CPU pourquoi garder cette émulation si elle peut être évitée ?
Il n'y a aucune forme d'émulation. la VM .NET est prévue dès le départ pour exposer un bytecode destiné à être compilé en code natif avant exécution, voir même avant déploiement.
Je présume que .Net est comme JVM est qu'elle est restée compatible (même modèle d'exécution) depuis la première version jusqu'à
Non elle a évoluée. Le CLR en est à la version 4.0.
La bibliothèque standard et le ramasse miette ne font pas partie de la VM.
Un sous-ensemble de la bibliothèque fait implicitement parti de la VM, et le GC est un service de la VM et en fait donc pleinement parti.
Ce que tu ne comprends pas, c'est ce qu'apporte une VM :
* une couche d'abstraction complète => portabilité. Pour un OS, c'est un gros atout.
* un modèle mémoire indépendant du hardware => possibilité d'ajouter des mécanismes de protection purement software, portable au passage, qui ne nécessite pas de faire appel aux ring hardware pour isoler les processus : paradoxalement il en résulte des performances bien meilleures qu'avec un OS classique basée suér les ring hardwares.
* un bytecode vérifiable avant exécution : pour un OS, pouvoir vérifier un programme avant de l'exécuter est un énorme atout niveau fiabilité et sécurité.
Il en résulte un OS beaucoup plus indépendant de la machine, avec un code beaucoup plus portable, plus simple, plus fiable et plus facile à maintenir.
Car oui, la JVM comporte aussi des bugs. Sauf que, quand mon programme Java plante à cause d'elle, je suis bien plus embêté
On parle pas de plantage mais de sécurité : il est fort probable que la JVM sera patchée plus vite que ton programme écrit dans ton coin.
Après c'est un problème différent, c'est le problème de dépendance envers un composant tiers : JVM, Qt, GTK,libxyz, etc.
Et tu crois que la VM Java elle est codée en Java ou en C/C++ ?
Et tu crois qu'aucune bibliothèque Java de calcul n'est optimisée avec du code écrit en C/C++ ?
Et tu crois que le code Java est généralement interprété ou traduit en code natif comme le C avant exécution ?
Franchement faut arrêter les conneries, dans 90% des cas le Python est attrocement lent. Java n'est pas une foudre de guerre, loin de là, mais c'est pas du tout comparable.
Ça t'amuse de lire la moitié des commentaires avant de répondre ? Le fait de travailler en permanence avec un compte root, c'est le genre de faille monstrueuse.
Y dit qu'il voit pas le rapport. Parlons des OS modernes si tu veux bien.
Tu affirmes que c'est la première fois que tu entends que les problèmes de sécu sont liées au language. Bah moi je te renvoi aux nombreux rapports de failles, sous Linux ou Windows, et tu verras que beaucoup d'entre elle sont directement liées à l'utilisation d'un langage bas niveau.
Et pourtant ce ne sont pas censé être des codeurs du dimanche qui codent un OS, que ce soit chez Microsoft ou les développeurs du Kernel Linux. Comme quoi il y a bien un problème fondamental avec ce type de langage : t'as beau être compétent, il est impossible de faire un programme sans bug. D'où l'idée d'avoir d'une VM qui ajoute une couche d'abstraction aux conneries du développeur pour s'assurer que 90% des bugs ne se transforment pas en failles potentielles.
Java. Une exception ça doit être gérée si ça ne l'ai pas le problème est le même qu'un segfault et si le développeur a pris soin de gérer convenablement les exceptions il en aurais fais de même en C pour vérifier ce qu'il déréférence.
T'as jamais codé c'est pas possible, comme si un déréférencement se traduisait systématiquement par un segfault...
Et puis on s'en cogne total de la gestion de l'exception ou du segfault : par définition, elles ne sont censé apparaître que dans des cas exceptionnels, cad non-prévus par le développeur, et donc non gérées. On parle de sécurité, pas de s'assurer qu'un programme est correct : l'objectif est donc de s'assurer qu'en cas de bug, ce qui arrive tôt ou tard, le système s'assure que ca ne se transforme pas en faille de sécurité. la VM s'en assure pour certains types de bug (accès mémoire, accès ressources systèmes), là ou le C/C++ ouvre la porte grande ouverte à toutes les failles possibles.
Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.
la méta-programmation. 3 avantages ignorés par Java.
Euh, la méta-programmation ignoré de Java par rapport à C++, c'est une blague j'espère ?
C'est aussi la première fois que j'entends dire (ou que je lis écrire) que Windows a (eu ?) des problèmes de sécurité à cause du C/C++. Alors qu'il existe d'autres systèmes très sûr en C
... qui ont exactement le même problème.
Analyse les failles, que ce soit sous Windows ou sur le Kernel, tu vas voir le nombre de fois qu'il y a un problème de déréférencement de pointeur ou de débordement de tampon. Dire que c'est uniquement dû à la taille de la cible ou à un problème de conception est vraiment une façon étrange de chercher à innocenter le C++ à tous les coup.
Microsoft a bien compris le problème en bossant sur Singularity, un OS basé non plus sur du C++ mais sur une VM issue de .NET.
Quel est le rapport avec la choucroute ?
Aucun langage n'a prévu ce mécanisme par défaut, ce ne sont que des bibliothèques qui permettent de s'abonner à des modifications du système de fichier. Exemple : inotify, utilisable en C++ ou en Java, bien avant Java7...
En sécurité, il faut des garanties. Et permettre au programmeur de faire des conneries (comme ne pas utiliser la STL quand c'est possible), c'est la garantie d'avoir des programmes qui partent en prod avec les dites conneries.
Et il y a pleins de contexte où la STL n'est pas utilisable.
Là c'est plutôt toi le n'importe quoi :)
> En tout cas il ne fait pas ce que tu veux
> Dans les deux cas tu as une erreur, tu le repère et tu corrige.
Justement, le problème est là : le programme ne plante pas, en apparence il fait ce que veux, et donc tu ne corriges pas. Parfois il n'y a même pas de débordement pendant la phase dev/qualif : les données en entrée font que tu ne sors jamais des limites du tableau, jusqu'au passage en prod et l'arrivée de données non-anticipées (typiquement une attaque) sur ce bug caché :
Comme indiqué précédemment, un des élément rendant un programme Java moins "dangereux" est la gestion automatique de la mémoire : pas de débordement de tampon possible. Evidemment rien n'empêche un bug dans la JVM, mais les bugs dans le programme de Geek@SSII23 est beaucoup plus probable ;)
j'ai bien parlé d'icônes arrondies, pas de tuiles arrondies qui est un paradigme totalement différent.
Ce qui est, mon dieu, encore pire ! Des tuiles à la place d'icônes ! Mais bon, si tu veux aller par là, tu affiches la liste des applications (qui est bien le but de l'écran dont on parle) sur Windows Phone, et comble de l'horreur, tu as une liste (et pas une mosaïque !!) et avec des icônes (et pas des tiles cette fois) carrée (roooooh).
qui est un paradigme totalement différent.
Sacrilège ! J'osais pas aller jusque là au risque de me faire taxer de pro-Microsoft, je te remercie.
que tu répondes à cet argument- est basée sur un screenshot qui met en comparaison deux téléphones dans deux contextes différents.
Mouarf. Le fait est que Samsung affiche ça en grand dans le métro, dans la rue, tout simplement pour montrer qu'eux aussi vendent un truc au look aussi sexy qu'Apple. Ca reste un menu destiné à lancer une application, donc en soit ca s'utilise pour faire la même chose, dans le même contexte.
Mais si cet écran c'est pas pour faire du marketing en montrant qu'ils ont un clone d'Apple, expliquez-moi à quoi sert cette interface ajoutée au dessus d'Android (qui s'utilise très bien sans) ?
Ce qui est absurde, c'est de tenter de se persuader qu'il n'y a pas d'alternative.
Mais vous avez raison, arrêtons de chercher à innover, Apple a trouvé la disposition optimale.
Remercions Samsung qui a su être lucide et clairvoyant en appliquant à la lettre ces règles d'ergonomies élémentaires de la même manière.
Ne parlons même pas des concurrents qui tentent lamentablement d'innover au prix de gros sacrifice d'ergonomie :
Meego par Nokia, avec ses icones TROP arrondies qui donnent une fraîcheur totalement anti-ergonomique.
HTC, avec sa surcouche Sense et son système de pagination totalement contre-intuitif, puisqu'il n'a pas les bullets Apple.
Google, qui a cherché à intégrer, comble de l'horreur, une barre de recherche sur son desktop, vous imaginez ? Apple a-t-il fait ça ? Non ? Alors ?
Windows Phone avec ses tiles carrées alors que c'est bien connus, les coins arrondis, c'est un principe de base d'ergonomie. Sans parler qu'ils ont carrement mis le titre dans le tile au lieu de le mettre en dessous comme c'est pourtant préconisé par les règles d'ergonomies élémentaires !
Et ces boulets d'HP, qui ont oublié qu'il fallait absolument mettre une mosaïque de 4x4 au lieu de 4x3 dans leur webOS !
Et enfin, applaudissons Samsung, qui à travers ses panneaux publicitaires géant, sait mettre en avant sa principal qualité : le respect des standards ergonomiques.
Mangez des pommes.
A part l'utilisation d'une mosaïque il n'y a à peu prêt aucun rapport entre ces 2 interfaces.
Si tu compares l'interface du Galaxy S vs iPhone, les similitudes sont beaucoup plus nombreuses :
- Même layout global : barre de notification en haut, menu d'application central et barre de raccourcis en bas.
- Barre de notification avec même niveau d'informations.
- Menu avec le même type d'icones (arrondis, texte blanc en dessous), le même nombre de lignes/colonnes, système de pagination identique. Au oui une différence, les bullet de pagination sur le samsung sont en haut.
- barre de raccourcis en bas d'hauteur équivalente, un fond clair intermédiaire similaire, une icone "phone" avec le même logo et le même code couleur.
Clairement Samsung a repompé, faut vraiment être de mauvaise foi pour le nier. HTC de son côté a fait une surcouche Android qui se démarque (on aime ou on aime pas...)
Mais bon visiblement il est mieux venu de taper sur Apple que sur Samsung, ton commentaire semblant beaucoup plus pertinent.
Sinon, cette histoire, qu'est-ce que ça vous inspire ?
Ben déjà, que sur le fond Apple n'a pas tord, quand on regarde les 2 interfaces, Samsung s'est vraiment pas foulé :
Après je trouve ça toujours aussi ridicule d'utiliser les brevets pour dire "eh il a copié". Oué c'est une copie, et alors ? Personne n'est dupe, et ça montre juste que Samsung ne sait pas innover (pour ce cas précis), ce qui est plutôt avantageux pour Apple : mieux vaut avoir des concurrents "suiveurs" que cherchant à se démarquer.
Pourquoi les fabricants de téléphones, en sont encore en 2011 à privilégier les accords commerciaux avec des éditeurs de systèmes mobiles douteux, plutôt que de vendre leurs téléphones nus (ou avec un équivalent de FreeDos pour téléphone), avec possibilité d'installer l'OS de notre choix ?
Peut-être parceque la demande d'un téléphone sans système pour l'exploiter représente un marché quasi-nul auprès du grand public ?
Peut-être parcqu'il n'existe pas d'OS suffisament générique pour tourner sur n'importe quel téléphone avec un simple LiveUSB et qu'il faut un minimum de travail d'intégration et de collaboration entre le fabriquant et le fournisseur de l'OS ?
A noter tout de même que celà n'est valable que pour les serveurs hébergés sur le territoire américain. Microsoft & Co proposent de choisir la "région" d'hébergement, entre autre pour ces questions légales justement.
Ils auraient pû innover par rapport à la concurrence en utilisant des FS innovants autre que la FAT, aucun doute que tu pourras m'en citer plein.
C'est du meme niveau que dire que Danone devrait creer un nouveau systeme de fichier universel parcequ'ils utilisent des ordinateurs.
TomTom n'est pas un simple utilisateur d'ordinateur : ils conçoivent des produits avec du soft embarqué, personnalisent et développent des logiciels. Faut pas non plus les prendre pour des bisounours qui ont pris la FAT parcque le grand méchant il est en position dominante et qu'ils ont pas eu le choix.
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
Donc tu préfères utiliser 100% du temps le même language, quitte à avoir 100% de ses inconvénients sans aucun des avantages dans 99,9% des cas :)
Nan mais pkoi pas, t'assumes c déjà bien :)
Sinon tu as des alternatives entre les 2, qui te laisse jouer avec des void * après avoir indiqué au compilo que t'étais un warrior avec un -unsafe, mais je citerai pas de nom au risque de réveiller un autre troll ;)
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
quand ils sont virtuels et donc potentiellement surchargés ?
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
C'est d'ailleur ce que font les runtimes un peu malin, celui de .NET détecte très bien le test d'une boucle for du genre :
for(int i = 0; i < tab.Length; i++)
...
Et il supprime la vérification des bornes lors de l'accès au tableau.
http://blogs.msdn.com/b/clrcodegeneration/archive/2009/08/13/array-bounds-check-elimination-in-the-clr.aspx
Après, sauf à faire du calcul intensif, le gain est minime voir insignifiant :
http://blogs.msdn.com/b/ricom/archive/2006/07/12/663642.aspx
[^] # Re: Les développeurs Java
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Ce qui coûte en performance, ce n'est pas le fait d'ajouter de "couche", mais d'ajouter des services : GC, contrôle d'accès aux ressources, etc.
Il n'y a aucune forme d'émulation. la VM .NET est prévue dès le départ pour exposer un bytecode destiné à être compilé en code natif avant exécution, voir même avant déploiement.
Non elle a évoluée. Le CLR en est à la version 4.0.
Un sous-ensemble de la bibliothèque fait implicitement parti de la VM, et le GC est un service de la VM et en fait donc pleinement parti.
Ce que tu ne comprends pas, c'est ce qu'apporte une VM :
* une couche d'abstraction complète => portabilité. Pour un OS, c'est un gros atout.
* un modèle mémoire indépendant du hardware => possibilité d'ajouter des mécanismes de protection purement software, portable au passage, qui ne nécessite pas de faire appel aux ring hardware pour isoler les processus : paradoxalement il en résulte des performances bien meilleures qu'avec un OS classique basée suér les ring hardwares.
* un bytecode vérifiable avant exécution : pour un OS, pouvoir vérifier un programme avant de l'exécuter est un énorme atout niveau fiabilité et sécurité.
Il en résulte un OS beaucoup plus indépendant de la machine, avec un code beaucoup plus portable, plus simple, plus fiable et plus facile à maintenir.
[^] # Re: manquement
Posté par TImaniac (site web personnel) . En réponse au sondage Quel est le système d'exploitation de votre (éventuel) smartphone ?. Évalué à 0.
merci :)
# manquement
Posté par TImaniac (site web personnel) . En réponse au sondage Quel est le système d'exploitation de votre (éventuel) smartphone ?. Évalué à 0.
Forcement, il en manquait un, donc je peux pas voter =)
Windows Phone \o/
[^] # Re: Les développeurs Java
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
A ton avis, qui a écrit ce commentaire 1/2h avant toi :
http://linuxfr.org/nodes/86730/comments/1251702
:-p
On parle pas de plantage mais de sécurité : il est fort probable que la JVM sera patchée plus vite que ton programme écrit dans ton coin.
Après c'est un problème différent, c'est le problème de dépendance envers un composant tiers : JVM, Qt, GTK,libxyz, etc.
[^] # Re: et python ? :)
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
Et tu crois que la VM Java elle est codée en Java ou en C/C++ ?
Et tu crois qu'aucune bibliothèque Java de calcul n'est optimisée avec du code écrit en C/C++ ?
Et tu crois que le code Java est généralement interprété ou traduit en code natif comme le C avant exécution ?
Franchement faut arrêter les conneries, dans 90% des cas le Python est attrocement lent. Java n'est pas une foudre de guerre, loin de là, mais c'est pas du tout comparable.
[^] # Re: Les développeurs Java
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Y dit qu'il voit pas le rapport. Parlons des OS modernes si tu veux bien.
Tu affirmes que c'est la première fois que tu entends que les problèmes de sécu sont liées au language. Bah moi je te renvoi aux nombreux rapports de failles, sous Linux ou Windows, et tu verras que beaucoup d'entre elle sont directement liées à l'utilisation d'un langage bas niveau.
Et pourtant ce ne sont pas censé être des codeurs du dimanche qui codent un OS, que ce soit chez Microsoft ou les développeurs du Kernel Linux. Comme quoi il y a bien un problème fondamental avec ce type de langage : t'as beau être compétent, il est impossible de faire un programme sans bug. D'où l'idée d'avoir d'une VM qui ajoute une couche d'abstraction aux conneries du développeur pour s'assurer que 90% des bugs ne se transforment pas en failles potentielles.
T'as jamais codé c'est pas possible, comme si un déréférencement se traduisait systématiquement par un segfault...
Et puis on s'en cogne total de la gestion de l'exception ou du segfault : par définition, elles ne sont censé apparaître que dans des cas exceptionnels, cad non-prévus par le développeur, et donc non gérées. On parle de sécurité, pas de s'assurer qu'un programme est correct : l'objectif est donc de s'assurer qu'en cas de bug, ce qui arrive tôt ou tard, le système s'assure que ca ne se transforme pas en faille de sécurité. la VM s'en assure pour certains types de bug (accès mémoire, accès ressources systèmes), là ou le C/C++ ouvre la porte grande ouverte à toutes les failles possibles.
Affirmation gratuite. Tu peux argumenter ?
[^] # Re: Les développeurs Java
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
... qui ont exactement le même problème.
Analyse les failles, que ce soit sous Windows ou sur le Kernel, tu vas voir le nombre de fois qu'il y a un problème de déréférencement de pointeur ou de débordement de tampon. Dire que c'est uniquement dû à la taille de la cible ou à un problème de conception est vraiment une façon étrange de chercher à innocenter le C++ à tous les coup.
Microsoft a bien compris le problème en bossant sur Singularity, un OS basé non plus sur du C++ mais sur une VM issue de .NET.
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
Quel est le rapport avec la choucroute ?
Aucun langage n'a prévu ce mécanisme par défaut, ce ne sont que des bibliothèques qui permettent de s'abonner à des modifications du système de fichier. Exemple : inotify, utilisable en C++ ou en Java, bien avant Java7...
https://launchpad.net/inotify-java
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
En sécurité, il faut des garanties. Et permettre au programmeur de faire des conneries (comme ne pas utiliser la STL quand c'est possible), c'est la garantie d'avoir des programmes qui partent en prod avec les dites conneries.
Et il y a pleins de contexte où la STL n'est pas utilisable.
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Là c'est plutôt toi le n'importe quoi :)
> En tout cas il ne fait pas ce que tu veux
> Dans les deux cas tu as une erreur, tu le repère et tu corrige.
Justement, le problème est là : le programme ne plante pas, en apparence il fait ce que veux, et donc tu ne corriges pas. Parfois il n'y a même pas de débordement pendant la phase dev/qualif : les données en entrée font que tu ne sors jamais des limites du tableau, jusqu'au passage en prod et l'arrivée de données non-anticipées (typiquement une attaque) sur ce bug caché :
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Côté .NET il y a des trucs arrivés pour faciliter la programmation concurrentiel : la TPL (Task Parallel Library), le couple async/await
http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
http://msdn.microsoft.com/fr-fr/vstudio/async
[^] # Re: porosité aux virus
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Comme indiqué précédemment, un des élément rendant un programme Java moins "dangereux" est la gestion automatique de la mémoire : pas de débordement de tampon possible. Evidemment rien n'empêche un bug dans la JVM, mais les bugs dans le programme de Geek@SSII23 est beaucoup plus probable ;)
Mais il y a bien d'autres aspects, un bon article sur la sécurité dans les JVM/.NET :
http://www.dotnetguru.org/articles/securite/Partie1/Securite.html
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Feuilleton de l'été: Guerre des brevets :(Apple vs Samsung). Évalué à 0.
Oh et puis tiens, c'est comme dire que cette interface était géniale après tout : enfin une interface Linux qui respectait les standards d'ergonomie !
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Feuilleton de l'été: Guerre des brevets :(Apple vs Samsung). Évalué à -3.
Ce qui est, mon dieu, encore pire ! Des tuiles à la place d'icônes ! Mais bon, si tu veux aller par là, tu affiches la liste des applications (qui est bien le but de l'écran dont on parle) sur Windows Phone, et comble de l'horreur, tu as une liste (et pas une mosaïque !!) et avec des icônes (et pas des tiles cette fois) carrée (roooooh).
Sacrilège ! J'osais pas aller jusque là au risque de me faire taxer de pro-Microsoft, je te remercie.
Mouarf. Le fait est que Samsung affiche ça en grand dans le métro, dans la rue, tout simplement pour montrer qu'eux aussi vendent un truc au look aussi sexy qu'Apple. Ca reste un menu destiné à lancer une application, donc en soit ca s'utilise pour faire la même chose, dans le même contexte.
Mais si cet écran c'est pas pour faire du marketing en montrant qu'ils ont un clone d'Apple, expliquez-moi à quoi sert cette interface ajoutée au dessus d'Android (qui s'utilise très bien sans) ?
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Feuilleton de l'été: Guerre des brevets :(Apple vs Samsung). Évalué à -2.
Ce qui est absurde, c'est de tenter de se persuader qu'il n'y a pas d'alternative.
Mais vous avez raison, arrêtons de chercher à innover, Apple a trouvé la disposition optimale.
Remercions Samsung qui a su être lucide et clairvoyant en appliquant à la lettre ces règles d'ergonomies élémentaires de la même manière.
Ne parlons même pas des concurrents qui tentent lamentablement d'innover au prix de gros sacrifice d'ergonomie :
Et enfin, applaudissons Samsung, qui à travers ses panneaux publicitaires géant, sait mettre en avant sa principal qualité : le respect des standards ergonomiques.
Mangez des pommes.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Feuilleton de l'été: Guerre des brevets :(Apple vs Samsung). Évalué à -3.
A part l'utilisation d'une mosaïque il n'y a à peu prêt aucun rapport entre ces 2 interfaces.
Si tu compares l'interface du Galaxy S vs iPhone, les similitudes sont beaucoup plus nombreuses :
- Même layout global : barre de notification en haut, menu d'application central et barre de raccourcis en bas.
- Barre de notification avec même niveau d'informations.
- Menu avec le même type d'icones (arrondis, texte blanc en dessous), le même nombre de lignes/colonnes, système de pagination identique. Au oui une différence, les bullet de pagination sur le samsung sont en haut.
- barre de raccourcis en bas d'hauteur équivalente, un fond clair intermédiaire similaire, une icone "phone" avec le même logo et le même code couleur.
Clairement Samsung a repompé, faut vraiment être de mauvaise foi pour le nier. HTC de son côté a fait une surcouche Android qui se démarque (on aime ou on aime pas...)
Mais bon visiblement il est mieux venu de taper sur Apple que sur Samsung, ton commentaire semblant beaucoup plus pertinent.
# mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Feuilleton de l'été: Guerre des brevets :(Apple vs Samsung). Évalué à -6.
Ben déjà, que sur le fond Apple n'a pas tord, quand on regarde les 2 interfaces, Samsung s'est vraiment pas foulé :
Après je trouve ça toujours aussi ridicule d'utiliser les brevets pour dire "eh il a copié". Oué c'est une copie, et alors ? Personne n'est dupe, et ça montre juste que Samsung ne sait pas innover (pour ce cas précis), ce qui est plutôt avantageux pour Apple : mieux vaut avoir des concurrents "suiveurs" que cherchant à se démarquer.
[^] # Re: Mauvais logiciel changer logiciel
Posté par TImaniac (site web personnel) . En réponse au journal C'est ça l'expérience utilisateur intuitive et ergonomique chez Gnome/Rhythmbox ?. Évalué à 2.
C'est pas le seul, Banshee y travaille également.
[^] # Re: Mais putain de bordel.
Posté par TImaniac (site web personnel) . En réponse au journal Le N9 ou comment flinguer son produit phare. Évalué à 10.
Peut-être parceque la demande d'un téléphone sans système pour l'exploiter représente un marché quasi-nul auprès du grand public ?
Peut-être parcqu'il n'existe pas d'OS suffisament générique pour tourner sur n'importe quel téléphone avec un simple LiveUSB et qu'il faut un minimum de travail d'intégration et de collaboration entre le fabriquant et le fournisseur de l'OS ?
[^] # Re: geoloc
Posté par TImaniac (site web personnel) . En réponse au journal Le cloud c'était une bonne idée.... Évalué à 6.
Bon ben le commentaire précédent montre que les américains se croient tout permis, même en dehors de leur territoire :(
# geoloc
Posté par TImaniac (site web personnel) . En réponse au journal Le cloud c'était une bonne idée.... Évalué à -4.
A noter tout de même que celà n'est valable que pour les serveurs hébergés sur le territoire américain. Microsoft & Co proposent de choisir la "région" d'hébergement, entre autre pour ces questions légales justement.
[^] # Re: Stratégie commerciale
Posté par TImaniac (site web personnel) . En réponse au journal Nokia abandonne Meego. Évalué à -1.
Ils auraient pû innover par rapport à la concurrence en utilisant des FS innovants autre que la FAT, aucun doute que tu pourras m'en citer plein.
TomTom n'est pas un simple utilisateur d'ordinateur : ils conçoivent des produits avec du soft embarqué, personnalisent et développent des logiciels. Faut pas non plus les prendre pour des bisounours qui ont pris la FAT parcque le grand méchant il est en position dominante et qu'ils ont pas eu le choix.