ils brident aussi le streaming et le direct download pour les non dégroupés
J'ai pas l'impression perso.
Il y a eu des soucis y'a 2 mois, mais ça n'a duré que quelques jours, depuis j'ai aucun soucis particulier. En général c'est plutôt le service de dd en face qui bride volontairement sauf à payer un compte "premium".
leur foutent en plus une augmentation de 20% sur la gueule.
Pour les non-dégroupés c'est plutôt 6% (option TV). Personne te force à prendre une V6 hein.
SI tu regardes les screenshots sur ce lien, http://www.universfreebox.com/article12828.html , tu verras un lien vers http://floss.freebox.fr . Le serveur ne semble pas encore actif, mais il est indiqué sur le screenshot qu'il contient plus d'information sur les modifcations apportées aux logiciels libres listés.
Hors la freebox fait partie de cette infrastructure réseau
Donc la freebox est louée.
Donc la freebox est distribuée.
Ils en sont où les chti gars qui avaient porté plainte sur la base de ce même raisonnement ? Ils avaient un site mais Google n'arrive pas à me le remonter... (je dois pas être doué).
Ce n'est pas à moi de décider.
Tu dis que ce n'est pas cohérent, tu as donc un avis !
L'état disait jusque là 50/50.
La commission européenne dit 60/40.
Quel est donc ton avis ?
Comme ça, ils ne pourront, eux, pas dire n'importe quoi.
Parcque tu confonds encore une fois la notion de services contractuels (ce sur quoi se base la TVA) et la notion de coûts de mise en oeuvre interne à l'entreprise.
Tu ne peux pas exiger d'un fournisseur qu'il sépare son offre commerciale en options totalement distinctes financièrement alors qu'elles ne le sont pas techniquement.
Par contre, il faudrait afficher des prix cohérents (genre pas la TV à 50% du prix), et la ça serait con pour le business des FAI...
Tiens, au lieu de râler sur le 50/50, propose !
Quel est selon toi, entre les 3 services offerts (TV, téléphonie, Internet), le ratio de TVA cohérent ?
Et montre nous sur quoi se base tes chiffres.
Donc la TV à 5.5 n'aurai JAMAIS dû être sur plus de 50% de la facture.
Free te vend contractuellement des services. Que l'ensemble de ses services s'appui sur une infrastrcuture réseau commune qui englobe 90% de leur charge, c'est LEUR problème, et l'état comme l'europe n'a pas son mot à dire là dessus, et ca n'a strictement rien à voir avec la TVA à 5.5 qui se concentre sur ce que tu vends.
Tu vas pas demander à un restaurateur de différencier la TVA en fonction de ses coûts internes (salaires, electricité, loyer, matières premières, etc.).
C'est la seule chose que je veux dire : je sais très bien que c'est la partie "Internet" qui coûte le plus cher
Non, y'a pas une partie qui coûte plus cher que l'autre justement : elles nécessitent toutes la même infrastructure sous-jacente qui a un coût fixe.
c'est de l'entube depuis des années
Absolument pas, celà a toujours été clairement et officiellement un coup de pouce de l'état aux FAI, un peu comme la TVA à 5.5 pour les restaurateurs. Maintenant depuis il y a eu la crise, Free&co n'ont plus besoin d'aide pour développer le marché, les caisses sont vides, la commission réclame un ratio différent, et hop, l'état saute sur l'occasion pour supprimer cette niche fiscale. Très logiquement les intéressés essaient de contourner le problème.
Tu les auras avec la fibre, ça changera rien.
Non, la fibre optique ce n'est pas du dégroupage.
Ce qui est rigolo dans ton raisonnement, c'est que tu continues à ignorer que les FAIs payaient la COSIP à la place de la TVA.
T'as essayé chez Orange ?
Parcque y'a toujours l'offre 8 megamax "ADSL uniquement sans engagement", même en rase campagne.
Ou alors t'es tellement loin du DSLAM que tu n'est pas éligible chez eux...
Mais bon là t'as toujours l'option de l'offre satellite.
Bref, t'as toujours le choix, t'es juste de mauvaise foi : tu voudrais une offre personnalisée au prix qui t'intéresse. Rien à voir avec la concurrence qui joue à plein dans ce secteur.
Si Free affiche 9€ HT pour l'accès Internet, ben je ne vois pas pourquoi il ne pourrait pas offrir une offre Internet pure dans les genre 15€ TTC.
Parcque tu oublies ce que vend Free. Il te vend des services et un accès physique, commun à tous ces services. Et transporter de la Voix, de la TV ou de l'internet, ca nécessite de louer une boucle locale, d'installer des DSLAM, une architecture réseau, etc.
Donc s'ils assumaient les coûts réels, ils feraient un truc du genre :
90% de la facture => infrastructure et réseau
3% => connectivité IP
3% => TV
3% => Téléphonie.
(Je caricature c'est sûrement pas les bonnes proportions).
C'est pas pour rien que tous les acteurs offrent du triple play : ca coûte globalement le même prix quelque soit la combinaison de services que tu veux, l'infrastructure sous-jacente étant dans tous les cas déployée et a un coût fixe.
le truc énorme étant de dire que le prix ne change pas alors qu'il grimpe déjà de 6€ quand on demande exactement le même service qu'avant
Euh, que les choses soient clair : si tu veux le même service qu'avant, tu prends la Freebox V5, l'offre est toujours dispo, au même prix, sans surcoût.
Non clairement tout le monde a bien vu l'augmentation de prix, et tout le monde a bien vu que c'était pas pour les mêmes services, il n'y a aucun entubage commercial.
Et puis c'est une façon assez sympatique de mettre en évidence la taxe FranceTelecom sur la boucle locale : cela peut inciter des coproprios réticents à fibrer leur immeule et ainsi se passer des 6€ en +; à l'avenir la proportion de dégroupé va diminuer.
Je paye toujours pour l'offre TV (60%) dont je n'ai pas besoin
Si tu veux une offre à la carte, tu vas pas chez Free. Et va pas dire que t'as pas le choix.
Celui qui a joué le jeu en stimulant cette concurrence, c'est la commission européenne comme l'aime à le rappeler Zenitram.
La commission a juste demandé de modifier le ratio de taxe 50/50 à 40/60. Autant dire que l'impact aurait été très limité voir probablement non repercuté. C'est l'état qui a choisi la taxe 19,6 sur l'ensemble.
Free était bien content comme les autres d'empocher la baisse de TVA sans baisser ses tarifs. C'est donc à elle que revient le mérite.
Tu oublies de préciser que Free n'a pas répercuté la taxe COSIP qui est venue s'ajouter quand la TVA a baissé.
Est ce qu'il faut supporter un format libre et potentiellement dépourvu de risques juridiques comme WebM ou ogg/theora, lisible sous tous les OS, ou bien un format soumis à des brevets logiciels par un troll patent qui réclame des sommes faramineuses à tous les maillons de la chaine ?
Ce qui est rigolo, c'est la logique totalement inverse qu'on les gens pragmatiques :
Est ce qu'il faut supporter un format libre et risqué juridiquement comme WebM ou ogg/theora, ou bien un format payant mais non risqué juridiquement ?
C# est également vraisemblablement plus agréable à utiliser que Java, et mieux conçu. Cependant, ça n'est pas une grosse révolution, donc je ne vois pas ce qui justifie qu'on s'embarrasse d'un nouveau venu
Ben la réponse est dans ta phrase précédente : quand un développeur passe des heures sur son code, surtout quand il fait des logiciels libres sur son temps perso, il a envie d'utiliser les outils avec lesquels :
1 - il est habitué (s'il vient du monde .NET)
2 - qui lui plaisent (choix du langage notamment)
3 - qui réponde à ses besoins (frameworks, libs).
A l'époque où Mono a démarré, il n'y avait pas vraiment d'alternative au java proprio qui soit à la hauteur, Mono avait donc tout son sens.
Un autre atout : l'alternative. Les récentes craintes autour de Java et du comportement de Oracle montre bien qu'il est tout à fait pertinent d'avoir plusieurs technos concurrentes et d'avoir le choix.
Donc après que celà occupe 70Mo sur le desktop, à côté de tout le reste, clairement on s'en tape.
C'est chianf.
Ca gène qui ?
Sur le desktop, je penses que tout le monde s'en tape de 70Mo, qui sont partagés par toutes les applis. Et si vraiment ca te gène, y'a mkbundle qui permet de déployer le strict minimum pour une application donnée.
Sur les devices mobiles, par exemple sur iPhone, le runtime compressé tombe à 3Mo. C'est encore beaucoup mais largement acceptable si on compare à la taille que peuvent prendre les graphiques.
La, tu exageres, tu sait très bien que Microsoft peut avoir des brevets sur l'implementation de System.Web sans qu'ils aient des brevets sur HTTP.
Oui enfin ca serait malheureux que Mono ne trouve pas une implémentation alternative comme le font toutes les autres technos...
En plus pour ton point, les drafts ça peut durer *très longtemps* parfois, voire ne jamais se concrètiser donc je trouve loin d'être ridicule de le compter.
Oui c'est possible.
Surtout qu'il cherche pas à réfléchir ou vérifier 2 minutes les références qu'il trouve.
Prenons les 3 principaux namespaces utilisés :
- System.Xml : pas de bol, Wikipedia dit des conneries, on retrouve ce namespace à l'ECMA. (et ca prend 2 minutes à vérifier dans l'url source de wikipedia : http://msdn.microsoft.com/en-us/netframework/aa569283.aspx). Et hop, 188 références sur les 419 sont bidons.
- System.Linq : un des fondement de C# 3, en cours de normalisation à l'ECMA (à l'état de draft en 2010) : il peut encore les compter si ça l'amuse, mais est-ce bien représentatif ? 155 références qui ne seront bientôt plus à compter.
- System.Web : le namespace pour faire des requêtes HTTP... Si Microsoft a des brevets là dessus, c'est pas les applications Mono qui vont avoir spécifiquement des enmerdes, c'est beaucoup plus de monde.
En fait, si on prend ce qui reste, c'est à dire quasiment rien, c'est plutôt rassurant : on s'aperçoit que les applications qui tournent sous Mono ne s'appui sur aucune brique potentiellement problématique (System.Windows.Forms, ADO.NET, etc.).
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant…
Eh sinon fait du C#, t'as des structures nommées Int16, Int32, Int64 ;)
C'est d'ailleur assez rigolo de voir comment les approches divergent :
en C#, int n'est qu'un alias de Int32, long un alias de Int64, short un alias de Int16.
En C, c'est l'inverse, int32_t est un typedef de int ou autre en fonction de la plateforme.
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées
Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser.
Ben en Java c'est pas un hasard.
Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête
Euh, en même temps t'as une alternative ? La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
C'est le concept même des types "primitifs" : ils sont là pour stocker de l'information, à toi de structurer son accès avec une classe qui encapsule ces données.
Si t'as peur, tu peux même mettre un commentaire pour le futur.
Si t'es pas d'accord, propose moi une alternative à cette hérésie en Java pour stocker ta couleur.
En quoi c’est ridicule ?
C'est ridicule parcqu'une bonne pratique consiste, quand tu souhaites que ton algo soit indépendant d'un type, à mettre un typedef (à défaut de template ou de généricité).
Il est sémantiquement idiot, si ton algo se veut indépendant de la taille des données manipulées, de mettre "int" plutôt que "long" ou "patate".
Ben nan, et c’est très précisément ce que je voulais dire.
C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.
unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.
Relis mon exemple. Tu ne l’as pas compris.
Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
Le C, c'est un compromis entre portabilité et performance.
il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.
la sémantique générale de l’algorithme multiplyByTwo est préservée
Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.
Je suppose donc que je ne peux pas savoir :
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
D'après la norme Java ? non.
Avec des API dédiés, bien sûr que oui.
C'est toute la différence : le langage, la JVM, sont normalisés de telle sorte qu'ils sont totalement indépendant de la machine physique, ce qui garantie sa portabilité. Après tu peux utiliser des API qui font autre chose, c'est ton problème mais plus celui de la norme.
Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Tu vas rire, mais tu les utilises indépendament de ton architecture : que ce soit du 16, 32, 64 bits, ou pourquoi pas demain 128 ou je ne sais quoi.
Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer, tout comme le C évolue...
Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ?
C'est quoi cet argument ridicule ? Le C s'est vu ajouté des types à taille fixe en 99, et personne ne trouve que c'est un boulet, bien au contraire. Si demain il y a besoin de types plus large encore, il suffira de rajouter de nouveaux keywords, waouuh va falloir tout réécrire ?
Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable, et il n'y a aucun inconvénient lié à l'évolutivité des plateformes.
[^] # Re: HADOPI aussi
Posté par TImaniac (site web personnel) . En réponse au journal Free réinvente le « double play » et casse le tarif unique. Évalué à 2.
J'ai pas l'impression perso.
Il y a eu des soucis y'a 2 mois, mais ça n'a duré que quelques jours, depuis j'ai aucun soucis particulier. En général c'est plutôt le service de dd en face qui bride volontairement sauf à payer un compte "premium".
leur foutent en plus une augmentation de 20% sur la gueule.
Pour les non-dégroupés c'est plutôt 6% (option TV). Personne te force à prendre une V6 hein.
[^] # Re: SIP alternatif
Posté par TImaniac (site web personnel) . En réponse au journal Free réinvente le « double play » et casse le tarif unique. Évalué à 1.
[^] # Re: va savoir
Posté par TImaniac (site web personnel) . En réponse au journal free + nouveaux frais +gpl. Évalué à 1.
http://freebox.flouzo.fr
quelqu'un en sait un peu plus ?
# va savoir
Posté par TImaniac (site web personnel) . En réponse au journal free + nouveaux frais +gpl. Évalué à 5.
Hors la freebox fait partie de cette infrastructure réseau
Donc la freebox est louée.
Donc la freebox est distribuée.
Ils en sont où les chti gars qui avaient porté plainte sur la base de ce même raisonnement ? Ils avaient un site mais Google n'arrive pas à me le remonter... (je dois pas être doué).
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 2.
C'était chiant. C'est résolu avec la nouvelle freebox justement.
http://www.universfreebox.com/article12828.html
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 2.
Tu dis que ce n'est pas cohérent, tu as donc un avis !
L'état disait jusque là 50/50.
La commission européenne dit 60/40.
Quel est donc ton avis ?
Comme ça, ils ne pourront, eux, pas dire n'importe quoi.
Parcque tu confonds encore une fois la notion de services contractuels (ce sur quoi se base la TVA) et la notion de coûts de mise en oeuvre interne à l'entreprise.
Tu ne peux pas exiger d'un fournisseur qu'il sépare son offre commerciale en options totalement distinctes financièrement alors qu'elles ne le sont pas techniquement.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 2.
Tiens, au lieu de râler sur le 50/50, propose !
Quel est selon toi, entre les 3 services offerts (TV, téléphonie, Internet), le ratio de TVA cohérent ?
Et montre nous sur quoi se base tes chiffres.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 2.
Free te vend contractuellement des services. Que l'ensemble de ses services s'appui sur une infrastrcuture réseau commune qui englobe 90% de leur charge, c'est LEUR problème, et l'état comme l'europe n'a pas son mot à dire là dessus, et ca n'a strictement rien à voir avec la TVA à 5.5 qui se concentre sur ce que tu vends.
Tu vas pas demander à un restaurateur de différencier la TVA en fonction de ses coûts internes (salaires, electricité, loyer, matières premières, etc.).
C'est la seule chose que je veux dire : je sais très bien que c'est la partie "Internet" qui coûte le plus cher
Non, y'a pas une partie qui coûte plus cher que l'autre justement : elles nécessitent toutes la même infrastructure sous-jacente qui a un coût fixe.
c'est de l'entube depuis des années
Absolument pas, celà a toujours été clairement et officiellement un coup de pouce de l'état aux FAI, un peu comme la TVA à 5.5 pour les restaurateurs. Maintenant depuis il y a eu la crise, Free&co n'ont plus besoin d'aide pour développer le marché, les caisses sont vides, la commission réclame un ratio différent, et hop, l'état saute sur l'occasion pour supprimer cette niche fiscale. Très logiquement les intéressés essaient de contourner le problème.
Tu les auras avec la fibre, ça changera rien.
Non, la fibre optique ce n'est pas du dégroupage.
Ce qui est rigolo dans ton raisonnement, c'est que tu continues à ignorer que les FAIs payaient la COSIP à la place de la TVA.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 3.
Parcque y'a toujours l'offre 8 megamax "ADSL uniquement sans engagement", même en rase campagne.
Ou alors t'es tellement loin du DSLAM que tu n'est pas éligible chez eux...
Mais bon là t'as toujours l'option de l'offre satellite.
Bref, t'as toujours le choix, t'es juste de mauvaise foi : tu voudrais une offre personnalisée au prix qui t'intéresse. Rien à voir avec la concurrence qui joue à plein dans ce secteur.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 5.
Parcque tu oublies ce que vend Free. Il te vend des services et un accès physique, commun à tous ces services. Et transporter de la Voix, de la TV ou de l'internet, ca nécessite de louer une boucle locale, d'installer des DSLAM, une architecture réseau, etc.
Donc s'ils assumaient les coûts réels, ils feraient un truc du genre :
90% de la facture => infrastructure et réseau
3% => connectivité IP
3% => TV
3% => Téléphonie.
(Je caricature c'est sûrement pas les bonnes proportions).
C'est pas pour rien que tous les acteurs offrent du triple play : ca coûte globalement le même prix quelque soit la combinaison de services que tu veux, l'infrastructure sous-jacente étant dans tous les cas déployée et a un coût fixe.
le truc énorme étant de dire que le prix ne change pas alors qu'il grimpe déjà de 6€ quand on demande exactement le même service qu'avant
Euh, que les choses soient clair : si tu veux le même service qu'avant, tu prends la Freebox V5, l'offre est toujours dispo, au même prix, sans surcoût.
Non clairement tout le monde a bien vu l'augmentation de prix, et tout le monde a bien vu que c'était pas pour les mêmes services, il n'y a aucun entubage commercial.
Et puis c'est une façon assez sympatique de mettre en évidence la taxe FranceTelecom sur la boucle locale : cela peut inciter des coproprios réticents à fibrer leur immeule et ainsi se passer des 6€ en +; à l'avenir la proportion de dégroupé va diminuer.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 2.
[^] # Re: Il est où le problème ?
Posté par TImaniac (site web personnel) . En réponse au journal TVA sur les offres triple play: nouvel épisode. Évalué à 4.
Si tu veux une offre à la carte, tu vas pas chez Free. Et va pas dire que t'as pas le choix.
Celui qui a joué le jeu en stimulant cette concurrence, c'est la commission européenne comme l'aime à le rappeler Zenitram.
La commission a juste demandé de modifier le ratio de taxe 50/50 à 40/60. Autant dire que l'impact aurait été très limité voir probablement non repercuté. C'est l'état qui a choisi la taxe 19,6 sur l'ensemble.
Free était bien content comme les autres d'empocher la baisse de TVA sans baisser ses tarifs. C'est donc à elle que revient le mérite.
Tu oublies de préciser que Free n'a pas répercuté la taxe COSIP qui est venue s'ajouter quand la TVA a baissé.
[^] # Re: Hmmm...
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft propose un plugin h264 pour Firefox. Évalué à 3.
Cependant, le MPEG-LA s'engage à protéger ses clients en utilisant toute son artillerie (lourde) juridique.
[^] # Re: Hmmm...
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft propose un plugin h264 pour Firefox. Évalué à 3.
Ce qui est rigolo, c'est la logique totalement inverse qu'on les gens pragmatiques :
Est ce qu'il faut supporter un format libre et risqué juridiquement comme WebM ou ogg/theora, ou bien un format payant mais non risqué juridiquement ?
[^] # Re: Ton alarmiste
Posté par TImaniac (site web personnel) . En réponse au journal Il fallait s'y attendre.. Évalué à 5.
Ben la réponse est dans ta phrase précédente : quand un développeur passe des heures sur son code, surtout quand il fait des logiciels libres sur son temps perso, il a envie d'utiliser les outils avec lesquels :
1 - il est habitué (s'il vient du monde .NET)
2 - qui lui plaisent (choix du langage notamment)
3 - qui réponde à ses besoins (frameworks, libs).
A l'époque où Mono a démarré, il n'y avait pas vraiment d'alternative au java proprio qui soit à la hauteur, Mono avait donc tout son sens.
Un autre atout : l'alternative. Les récentes craintes autour de Java et du comportement de Oracle montre bien qu'il est tout à fait pertinent d'avoir plusieurs technos concurrentes et d'avoir le choix.
Donc après que celà occupe 70Mo sur le desktop, à côté de tout le reste, clairement on s'en tape.
[^] # Re: Ton alarmiste
Posté par TImaniac (site web personnel) . En réponse au journal Il fallait s'y attendre.. Évalué à 0.
Ca gène qui ?
Sur le desktop, je penses que tout le monde s'en tape de 70Mo, qui sont partagés par toutes les applis. Et si vraiment ca te gène, y'a mkbundle qui permet de déployer le strict minimum pour une application donnée.
Sur les devices mobiles, par exemple sur iPhone, le runtime compressé tombe à 3Mo. C'est encore beaucoup mais largement acceptable si on compare à la taille que peuvent prendre les graphiques.
[^] # Re: Source...
Posté par TImaniac (site web personnel) . En réponse au journal Il fallait s'y attendre.. Évalué à 3.
[^] # Re: Source...
Posté par TImaniac (site web personnel) . En réponse au journal Il fallait s'y attendre.. Évalué à 3.
Oui enfin ca serait malheureux que Mono ne trouve pas une implémentation alternative comme le font toutes les autres technos...
En plus pour ton point, les drafts ça peut durer *très longtemps* parfois, voire ne jamais se concrètiser donc je trouve loin d'être ridicule de le compter.
Oui c'est possible.
[^] # Re: Source...
Posté par TImaniac (site web personnel) . En réponse au journal Il fallait s'y attendre.. Évalué à 10.
Prenons les 3 principaux namespaces utilisés :
- System.Xml : pas de bol, Wikipedia dit des conneries, on retrouve ce namespace à l'ECMA. (et ca prend 2 minutes à vérifier dans l'url source de wikipedia : http://msdn.microsoft.com/en-us/netframework/aa569283.aspx). Et hop, 188 références sur les 419 sont bidons.
- System.Linq : un des fondement de C# 3, en cours de normalisation à l'ECMA (à l'état de draft en 2010) : il peut encore les compter si ça l'amuse, mais est-ce bien représentatif ? 155 références qui ne seront bientôt plus à compter.
- System.Web : le namespace pour faire des requêtes HTTP... Si Microsoft a des brevets là dessus, c'est pas les applications Mono qui vont avoir spécifiquement des enmerdes, c'est beaucoup plus de monde.
En fait, si on prend ce qui reste, c'est à dire quasiment rien, c'est plutôt rassurant : on s'aperçoit que les applications qui tournent sous Mono ne s'appui sur aucune brique potentiellement problématique (System.Windows.Forms, ADO.NET, etc.).
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Eh sinon fait du C#, t'as des structures nommées Int16, Int32, Int64 ;)
C'est d'ailleur assez rigolo de voir comment les approches divergent :
en C#, int n'est qu'un alias de Int32, long un alias de Int64, short un alias de Int16.
En C, c'est l'inverse, int32_t est un typedef de int ou autre en fonction de la plateforme.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Co(...)
;)
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser.
Ben en Java c'est pas un hasard.
Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête
Euh, en même temps t'as une alternative ? La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
C'est le concept même des types "primitifs" : ils sont là pour stocker de l'information, à toi de structurer son accès avec une classe qui encapsule ces données.
Si t'as peur, tu peux même mettre un commentaire pour le futur.
Si t'es pas d'accord, propose moi une alternative à cette hérésie en Java pour stocker ta couleur.
En quoi c’est ridicule ?
C'est ridicule parcqu'une bonne pratique consiste, quand tu souhaites que ton algo soit indépendant d'un type, à mettre un typedef (à défaut de template ou de généricité).
Il est sémantiquement idiot, si ton algo se veut indépendant de la taille des données manipulées, de mettre "int" plutôt que "long" ou "patate".
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.
unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.
Relis mon exemple. Tu ne l’as pas compris.
Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
Le C, c'est un compromis entre portabilité et performance.
il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.
la sémantique générale de l’algorithme multiplyByTwo est préservée
Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
D'après la norme Java ? non.
Avec des API dédiés, bien sûr que oui.
C'est toute la différence : le langage, la JVM, sont normalisés de telle sorte qu'ils sont totalement indépendant de la machine physique, ce qui garantie sa portabilité. Après tu peux utiliser des API qui font autre chose, c'est ton problème mais plus celui de la norme.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Tu vas rire, mais tu les utilises indépendament de ton architecture : que ce soit du 16, 32, 64 bits, ou pourquoi pas demain 128 ou je ne sais quoi.
Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer, tout comme le C évolue...
Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ?
C'est quoi cet argument ridicule ? Le C s'est vu ajouté des types à taille fixe en 99, et personne ne trouve que c'est un boulet, bien au contraire. Si demain il y a besoin de types plus large encore, il suffira de rajouter de nouveaux keywords, waouuh va falloir tout réécrire ?
Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable, et il n'y a aucun inconvénient lié à l'évolutivité des plateformes.