Discussion :

[stardeath]

Ben moi j'ai pas de problème pour aller decommenter 2 lignes dans un .ini
c'est pour toi que ca semble complique

perso, j'ai pas de problème à cliquer sur "suivant", ni à changer un fichier de configuration, mais quand on me dit que c'est simple, j'aime bien ne pas être pris pour un imbécile. et désolé, changer un fichier conf c'est pas simple pour un utilisateur lambda ni pour moi quand je ne sais pas où se trouve ce foutu fichier

[Barsy]

dans la mesure ou on est en train de comparer avec Os x pour lequel 1 clic est necessaire, oui je considère 1 clic comme une étape. Donc c'est soit 1 vs 17 selon moi, et moins de 1 vs moins de 17 selon toi

Ben excuse moi, je préfère largement passer par une interface d'installation durant laquelle j'ai la possibilité de configurer un minimum mon outil. Configuration qui peut d'ailleurs éviter le conflit de port en sélectionnant le 8080 lors de l'étape où il est proposé.

c'est une terminologie que je n'ai jamais rencontrée sous Os x, d'ailleurs, le problème non plus je pense.

C'est bien ce que je pensais : tu reproches à Windows ta propre ignorance...

[Perplexe]

perso, j'ai pas de problème à cliquer sur "suivant", ni à changer un fichier de configuration, mais quand on me dit que c'est simple, j'aime bien ne pas être pris pour un imbécile. et désolé, changer un fichier conf c'est pas simple pour un utilisateur lambda ni pour moi quand je ne sais pas où se trouve ce foutu fichier

- Reprends les posts précédents, nul part on a dit que c'était simple, mais seulement proportionnel au niveau de l'utilisateur. Quelqu'un qui programme en PHP et ne sait pas bidouiller dans les fichiers de conf, c'est un peu suspect.

Ben excuse moi, je préfère largement passer par une interface d'installation durant laquelle j'ai la possibilité de configurer un minimum mon outil. Configuration qui peut d'ailleurs éviter le conflit de port en sélectionnant le 8080 lors de l'étape où il est proposé.

- Dans Mac Os X, tu peux également choisir le port. Maintenant, si tu préfères cliquer 17 fois lorsqu'une seule fois est nécessaire, je dirais que tu travailles pour un fabricant de souris.

C'est bien ce que je pensais : tu reproches à Windows ta propre ignorance...

- Moi je ne reproche rien à Windows. Je me contente de répondre à des assertions inexactes concernant Mac Os X. Maintenant, c'est vrai que si tu ouvres des boîtes de conserve avec un Opinel pendant 10 ans, tu seras plus agile pour ça que moi qui utilise un bête ouvre-boîte.


C'est assez comique de voir que ce topic qui concerne qui concerne le support futur du runtime Java par Apple tourne à la guéguerre sur des sujets périphériques.

Je lis qu'Apple est une plateforme fermée et sectaire et je réponds en donnant une liste objective de technologies ouvertes intégrées en standard dans Mac Os X. A ce sujet, je fais remarquer que c'est le seul os commercial répandu qui intègre effectivement ces technologies en standard.

Quelles sont les réponses à ça ? Un feu d'âneries sur la prétendue complexité d'une activation de PHP quand de l'autre coté, rien ne vient avec l'os.

Ce que je dis simplement, c'est que lorsqu'on compare Mac Os X avec le seul autre os commercial et répandu existant, cad Windows, on constate qu'il est plus complet au sortir de la boîte.

Je vois pas en quoi ça vous gêne au point d'aller pleurer à propos de 2 lignes à décommenter sur une plateforme que vous ne pratiquez pas.

Et j'ajouterai, comme d'hab, qu'au temps passé sur les 2 os concurrents, je pense être plus en position d'établir des comparaisons objectives que beaucoup ici.

Enfin pour Unbuntu, ma dernière install remonte à plusieurs mois donc je ne suis pas à jour, et c'est vrai qu'à l'époque j'avais trouvé ça plutôt très bien fait. Par contre, pour un utilisateur néophyte, je ne suis pas certain qu'il soit aussi adapté que les 2 autres.

[Uther]

Ta comparaison n'a de sens que si tu compare de façon comparable. Pas sûr que Mac OS X reconnaisse facilement une carte graphique qui vienne pas de chez Apple. Déjà il a du mal avec les souris pas Apple
...
D'une manière générale, les fabricants testent les logiciels qu'ils vendent avec leur matos. Si quelqu'un vend du matos avec une distribution GNU-Linux, a priori, sauf si il fait très mal son travail, il devrait y avoir aucun soucis.

Sauf que le sujet n'était pas de faire une comparaison technique sur l'éventail de matériel supporté, si c'était le cas Linux gagne très largement.
Apple se simplifie clairement la tache en choisissant le matériel qu'il supporte. Nul doute qui si Ubuntu faisait pareil, son support serait impeccable, mais ce n'est pas le cas.
D'ailleurs, le support matériel de mon EeePC livré avec Linux était parfait.

Quant aux logiciels, c'est la même remarque : essayes d'installer Meld sur Mac OS X : ce n'est pas trivial, contrairement à n'importe quelle distrib GNU-Linux.

Je ne parle pas d'outils techniques qui ont été packagés avec un système pas du tout standard sur Mac et qui de toute façon ne sont pas vrai un problème vu que le public visé n'a pas peur de bidouiller.
Je te rappelle qu'on parlait de l'utilisation des users lambda. Une dmg ou un exe/msi, c'est enfantin à installer.

Un sacré frein pour qui ? pour quoi ? L'utilisateur de base, qu'est ce que ça peut lui faire qu'il y ai des deb, de rpm ou des tar.gz, si tous les logiciels qu'il utilise, il les a en quelques clics via son installateur de logiciels ?

Comme j'ai dit, si le logiciel est disponible dans les dépôts officiels, pas de problème c'est même plus simple.
Mais c'est quand il n'y est pas que ça ce corse. Les distrib ont beau faire un boulot énorme, il ne peuvent packager tout.

Personne n'empêche un développeur de faire de même pour les distributions GNU-Linux ou autres systèmes libres.

Sauf que ça ne se fait pas ou tout au plus pour 2-3 distributions, car c'est trop compliqué de tester sur l'ensemble des distributions.

Idem pour Windows et pour Mac OS X, il y a des logiciels qu'il n'y a pas.

Je ne parlais pas des logiciels qui n'existent pas pour l'OS mais des logiciels qui existent mais ne sont pas présents dans les dépots officiels de la distribution, ou pas avec la version souhaitée.

[trenton]

Sauf que le sujet n'était pas de faire une comparaison technique sur l'éventail de matériel supporté, si c'était le cas Linux gagne très largement.
Mais ici Apple se simplifie clairement la tache en choisissant le matériel qu'il supporte. Nul doute qui si Ubuntu faisait pareil, son support serait impeccable, mais ce n'est pas le cas.

C'est un point de vue, moi je pense que c'est au fabricant de matériel de fournir ses pilotes et de les tester. Et permettre à chaque constructeur d'être compatible, c'est plutôt positif pour la concurrence et pour le client aussi du coup. On a pas tous les mêmes goûts ni les mêmes besoin, et tout le monde n'a pas 300 euros à mettre dans une souris par exemple.

Je ne parle pas d'outils techniques qui ont été packagés avec un système pas du tout standard sur Mac et qui de toute façon ne sont pas vrai un problème vu que le public visé n'a pas peur de bidouiller.
Je te rappelle qu'on parlait de l'utilisation des users lambda. Une dmg ou un exe/msi, c'est enfantin à installer.

Moi ça m'aurait plu de pouvoir utiliser meld sur mac OS X, mais j'avais pas 15 minutes à perdre pour cela.

Comme j'ai dit, si le logiciel est disponible dans les dépôts officiels, pas de problème c'est même plus simple.
Mais c'est quand il n'y est pas que ça ce corse.

Oui, mais la encore, aucune différence, si y'a pas de .msi/.dmg, ça se corse aussi sur Windows/Mac OS X.

Sauf que ça ne se fait pas ou tout au plus pour 2-3 distributions, car c'est trop compliqué de tester sur l'ensemble des distributions.

Si ton logiciel est vraiment intéressant, il trouvera des volontaires pour faire les paquets.

Je ne voulais pas dire des logiciels qui n'existent pas pour l'OS mais des logiciels qui existent mais ne sont pas présents dans les dépots officiels ou sous la version souhaitée.

Tu veux dire, comme meld sur mac os ?

[smarinier]

Vous n'avez sans doute pas bien lu. C'est l'abandon de la gestion par Apple de la maintenance du Runtime Java...Pas l'abandon de Java.

J'ai personnellement souffert plus d'une fois que ce Runtime soit maintenu par Apple et soit dépendant de son bon vouloir, et impose un changement de système pour avoir la version supérieure (cas du 1.5)...

Pour le cas similaire de GCC par exemple, c'est assez pénible de devoir supporter la version souvent buguée que délivre Apple au compte-goutte selon ses mises à jour de XCode. Il serait bien mieux que cette version soit totalement ouverte et indépendante du vendeur de machines.

Alors que la communauté Java se réapproprie son Runtime, et à mon avis, ça marchera bien mieux qu'avec Apple!

[Uther]

C'est un point de vue, moi je pense que c'est au fabricant de matériel de fournir ses pilotes et de les tester. Et permettre à chaque constructeur d'être compatible, c'est plutôt positif pour la concurrence et pour le client aussi du coup. On a pas tous les mêmes goûts ni les mêmes besoin, et tout le monde n'a pas 300 euros à mettre dans une souris par exemple.

Sur le fond je suis d'accord, mais il se trouve que dans la pratique, seul Microsoft peut s'assurer (grâce à ces part de marché) que les périphériques soient bien supportés et testés par les fabricants.

Moi ça m'aurait plu de pouvoir utiliser meld sur mac OS X, mais j'avais pas 15 minutes à perdre pour cela.

Oui enfin pour le coup c'est pas MacOS X le coupable mais le portage cheap. S'il y avait un dmg comme c'est préconisé sous Mac, pas de problème.

Oui, mais la encore, aucune différence, si y'a pas de .msi/.dmg, ça se corse aussi sur Windows/Mac OS X.

Parceque tu connais beaucoup d'outils grand public sous Mac OS X et Windows qui ne s'installent pas par .exe/.msi/.dmg?
Et si c'est le cas c'est clairement de leur faute de ne pas utiliser le système préconisé.

Si ton logiciel est vraiment intéressant, il trouvera des volontaires pour faire les paquets.

La encore, il y a la théorie et la pratique.
Dans les faits, quelque soit la distrib que j'ai essayé, il m'a toujours manqué des logiciels que j'avais sur d'autres.

[Uther]

Vous n'avez sans doute pas bien lu. C'est l'abandon de la gestion par Apple de la maintenance du Runtime Java...Pas l'abandon de Java.

J'ai personnellement souffert plus d'une fois que ce Runtime soit maintenu par Apple et soit dépendant de son bon vouloir, et impose un changement de système pour avoir la version supérieure (cas du 1.5)...
...
Alors que la communauté Java se réapproprie son Runtime, et à mon avis, ça marchera bien mieux qu'avec Apple!

On l'a très bien compris. Mais l'abandon du runtime n'est tout de même pas vide de sens : Apple ne vois plus Java comme un atout mais une gène.
L'interdiction d'applications java dans l'App Store est un autre signe encore plus clair.

Quant à l'avenir de Java sous Mac il n'est pas gagné. Il va falloir un nouveau Runtime qui mettra du temps à atteindre le niveau d'intégration de celui d'Apple.
Et pour cela, il faut également qu'Oracle et/ou la communauté autour de l'OpenJDK se mobilise. Sachant que, même si Apple laisse OS X 10.7 libre d'installer ce qu'il veut, il y a fort à craindre que les applications hors Apps Store soient interdites dans le futur (OS X 10.8 ou 10.9).
A la place d'Oracle j'y réfléchirait à deux fois.

[stardeath]

...

non, je sais me débrouiller en php mais je ne sais pas configurer apache, il y a aucun rapport entre les 2 mais bon.

c'est moi ou pour le reste tu t'amuses à ressortir des arguments fallacieux qui ont été démontés sur d'autres topics, ils ne seront pas plus valides ici

et si tu veux un exemple, regarde les condamnations de microsoft par l'europe sur la présence de certains logiciels inclus ...

[Barsy]

Moi je ne reproche rien à Windows. Je me contente de répondre à des assertions inexactes concernant Mac Os X. Maintenant, c'est vrai que si tu ouvres des boîtes de conserve avec un Opinel pendant 10 ans, tu seras plus agile pour ça que moi qui utilise un bête ouvre-boîte.

Je vois ça, à force d'utiliser un "vulgaire ouvre boîte" on finit par ne plus savoir comment fonctionne la boîte en elle-même n'est-ce pas ?

Enfin, pour ma part, ce problème de gestion des ports, je l'ai appris en développant des applications client/serveur en C++ sur Linux. Et comme je l'ai dit, la même chose peut se produire sous MacOS X. Et je ne vois aucune assertion inexacte dans mes propos.

[trenton]

Sur le fond je suis d'accord, mais il se trouve que dans la pratique, seul Microsoft peut s'assurer (grâce à ces part de marché) que les périphériques soient bien supportés et testés par les fabricants.

Oui, il faut bien choisir son matériel (mais au début je pensait qu'on parlais de GNOME ou des logiciels libres, pas du matériel). Mais dans l'ensemble, le matériel est quand même plutôt compatible si on est prêt à installer des drivers pas libres. Et de toute façon, un simple utilisateur n'installe pas son système, donc le problème ne se pose pas pour lui.

Parceque tu connais beaucoup d'outils grand public sous Mac OS X et Windows qui ne s'installent pas par .exe/.msi/.dmg?
Et si c'est le cas c'est clairement de leur faute de ne pas utiliser le système préconisé.

Des logiciels grand publics qu'il n'y a pas sur Mac OS ou Windows, oui, j'en connais.

[Perplexe]

non, je sais me débrouiller en php mais je ne sais pas configurer apache, il y a aucun rapport entre les 2 mais bon.

Alors Mac Os est fait pour toi 1 clic pour Apache et 2 hashes pour PHP...

c'est moi ou pour le reste tu t'amuses à ressortir des arguments fallacieux qui ont été démontés sur d'autres topics, ils ne seront pas plus valides ici

Le problème n'est pas tellement que mes réponses se répètent, mais que les affirmations qu'elles démontent persistent malgré tout.

et si tu veux un exemple, regarde les condamnations de microsoft par l'europe sur la présence de certains logiciels inclus ...

Tu crois vraiment que tu vas convaincre quelqu'un ici que Ms pourrait se faire condamner pour intégrer à Windows un Apache ou un SqlLite avec l'accord de la communauté des dévs ?

La question ici est de savoir si l'arret du runtime Java par Apple est un problème, et certains crient au sectarisme de la part d'Apple. Il suffit de renseigner objectivement les lecteurs pour que ceux qui veulent faire preuve de bonne foi s'aperçoivent que cette condamnation est à nuancer.

Après, que certains irréductibles s'excusent de ne pas utiliser Mac ...

[Perplexe]

Je vois ça, à force d'utiliser un "vulgaire ouvre boîte" on finit par ne plus savoir comment fonctionne la boîte en elle-même n'est-ce pas ?

Oui enfin je démontais des "boîtes" depuis bien longtemps avant que tu ne sois né

Enfin, pour ma part, ce problème de gestion des ports, je l'ai appris en développant des applications client/serveur en C++ sur Linux. Et comme je l'ai dit, la même chose peut se produire sous MacOS X.

Je n'ai pas dit que ça ne pouvait pas se produire, mais que ça ne se produisait pas suffisamment souvent pour qu'on en fasse mention dans un tutoriel.

Et je ne vois aucune assertion inexacte dans mes propos.

Mais qui a dit qu'il s'agissait de toi ?

[yoyo88]

On l'a très bien compris. Mais l'abandon du runtime n'est tout de même pas vide de sens : Apple ne vois plus Java comme un atout mais une gène.
L'interdiction d'applications java dans l'App Store est un autre signe encore plus clair.

Quant à l'avenir de Java sous Mac il n'est pas gagné. Il va falloir un nouveau Runtime qui mettra du temps à atteindre le niveau d'intégration de celui d'Apple.
Et pour cela, il faut également qu'Oracle et/ou la communauté autour de l'OpenJDK se mobilise. Sachant que, même si Apple laisse OS X 10.7 libre d'installer ce qu'il veut, il y a fort à craindre que les applications hors Apps Store soient interdites dans le futur (OS X 10.8 ou 10.9).
A la place d'Oracle j'y réfléchirait à deux fois.

de toute façons Apple veut avoir une mains mise sur les application présent dans son Apple Store et promouvoir Objective C comme actuellement avec l'iphone...

Pour moi viré la JVM de mac c'est plus un prétexte pour poussé les développeurs à allez sur Objective C et bénéficier d'une plus grande médiatisation grâce a l'Apple store.

Bref ils veulent créer un ecosysteme Apple un peu a la .net tous en essayant de garantir une certaine qualité en niveau applicatif.

faut pas oublier qu'Apple est un marque qui a fait sa réputation grâce a la qualité de ses produit (exception a la règles : ITune! )

bon après on risque de se retrouver avec un système comme l'Iphone qui perso ne me convient pas du tout.

[_skip]

de toute façons Apple veut avoir une mains mise sur les application présent dans son Apple Store et promouvoir Objective C comme actuellement avec l'iphone...

Ce serait une manière de se garantir l'exclusivité d'un certains nombre de software en limitant les possibilités multi-OS des applications.

[yoyo88]

Je n'ai pas dit que ça ne pouvait pas se produire, mais que ça ne se produisait pas suffisamment souvent pour qu'on en fasse mention dans un tutoriel.

un problème de port plus rare sous MAC que sous les autres OS?
ta pas du installé beaucoup de logiciel utilisant des ports...

Qu'elle que soit l'OS, t'es l'instant que tu a 2 applications qui essaye d'accéder a un même port tu aura des conflits...

[jcoq6340]

IPhone ne supporte pas java
donc c'est pa nouveau

[_skip]

IPhone ne supporte pas java
donc c'est pa nouveau

Depuis quand MacOSx c'est iPhone?

[Perplexe]

un problème de port plus rare sous MAC que sous les autres OS?
ta pas du installé beaucoup de logiciel utilisant des ports...

Qu'elle que soit l'OS, t'es l'instant que tu a 2 applications qui essaye d'accéder a un même port tu aura des conflits...

Ça j'ai eu maintes occasions de le comprendre sous Windows. Mais je n'ai pas le souvenir de l'avoir rencontré sous Mac Os X.

Probablement parce que l'écosystème Mac Os X est plus homogène, du fait d'un nombre de développeurs moindre et peut-être de guidelines de développement plus strictes ?

[bouye]

Depuis quand MacOSx c'est iPhone?

Depuis toujours

iOS is derived from Mac OS X, with which it shares the Darwin foundation, and is therefore a Unix-like operating system by nature.