zut, moi qui croyait que c'était Objective-C qui était le futur à apprendre pour les technos Apple, c'est ce que j'avais compris avant que Swift n'apparaisse.
Bon, je m'y perd ;-).
(et j’attends le prochain nom dans quelques années)
Bon, si tu veux troller avec moi sur les technos apple, va falloir affuter et te documenter un peu mieux que ca.
Deja, ca fait bien qq années qu'il ya des discussions pour moderniser Objective-C. Apple a mit un bon coup de collier sur la deuxième moitié des années 2000, et clang a fait des merveilles sur la période 2010-2013.
Ca ne change pas que quasiment tout le monde dans la communauté trouve qu'objective c est vieillot. Pointeurs, header, type scalaires pas objets (avec acrobaties via NSNumber ou NSValue), enums pourries, collections qui refusent nil, grosso modo toute la partie héritée directement de C a toujours dérangé la plupart des gens.
Yavait des débats sur le message sending par dessus tout ca, mais c'etait deja moins sujet a troll.
Bref, ca fait longtemps qu'objc est plus le future d'iOS/OSX. Au mieux, il était le present.
M'enfin, c'est sur que c'est pas en trollant a l'emporte piece sur linuxfr que tu vas apprendre ca.
Comme je sens une point d'ironie, voila la liste des technologies officiellement poussées par apple:
basic ou assembleur sur l'apple II (1977-1990)
pascal, basic ou C sur macos classic (1984-2000)
Transition a macosx: Carbon est offert pour une transition aisée, tout en étant clair que c'est du transitionnel
En parallele, passage a objective C + Cocoa (2001-present)
2014: Apple annonce Swift en beta. 1.0 est clairement annonce comme experimental (a vos risques et périls).
2015: Apple annonce 2.0. Les choses se stabilisent et le language est production ready (bien meilleur support dans cocoa, language par défaut a WWDC, language par défaut dans les templates Xcode etc.)
2016, Apple open source le runtime
Voila pour la leçon d'histoire.
Je vois 4 phases la dedans. Le 3 premieres ont durées au moins 13 ans.
Je te laisse deviner combien de temps va durer la 4ieme.
Si tu veux des indices: les seules features qu'objective c a reçu depuis 2014 servent a faciliter l'intefacage avec swift. Tous les ingénieurs d'apple avec qui j'ai bosse sur le campus poussent activement swift auprès des third party. WWDR aussi. Ca va devient dur de trouver un boulot dans le domaine si tu connais pas swift (perso je rejette d'emblée tout resume qui ne mentionne pas swift).
Voila, en deux ans, objective c est passe de seul language possible a legacy. Tu peux troller ce que tu veux, mais après 15 ans a apple, et une bonne dizaine a next, je trouve pas ca degueu comme duree de vie.
Apres, on peut aller en detail dans les raisons du changement.
Principalement le fait que objective c est super pas fiable de base (philosophie c "tu tiens la tronçonneuse toi meme"), et le fait qu'aussi douee soit l'équipe du runtime, ils ont atteint un mur de performance et de design. Ils peuvent tout simplement pas faire évoluer le language sans une cassure de compat'.
Petite pensée pour Firewire (en premier truc qui me passe par la tête).
Tu veux dire le truc qu'ils ont supporte de 99 a 2011?
Effectivement, un bon exemple. Tu noteras aussi que le marche firewire était bien mort depuis la moitié des années 2000. Apple a continue a le pousser malgré le fait qu'usb 2 ait gagne la guerre, et que firewire n'était utilise en gros que pour les camera DV (qui généralement proposait aussi une sortie usb).
Sinon, cette même entreprise sponsorise un compilateur C/C++ performant, donc si on se base sur la "marque", tu dois avouer que C/C++ est pas mal (ta "marque référence" y met du fric).
sigh.
C'est quoi ton point? Qu'apple supporte c++? Support, youpi, apple supporte c++. Et donc? A pas troller a l'emporte piece?
J'ai dit que c++ allait disparaitre du jour au lendemain? Non, j'ai dit que démarrer un nouveau project en c++ ne ferait probablement pas beaucoup de sens dans qq années, sortis de besoins tres spécifiques.
Attaque ad hominem, ça en dit long sur le niveau (sérieusement, tu as besoin d'attaquer les personnes qui ne te plaisent pas, de faire ce genre de gaminerie de cours d’école, plutôt que d'attaquer les idées, pour te sentir bien?)
Ben putain, il te faut pas grand chose.
En 95, t'etais au college, potentiellement au lycée. A cet age la, on ne sait pas ce que le mot "carrière" veut dire.
Ce language que tu traites de mode a été dans l'industrie plus longtemps que toi. J'appelle pas ca une mode, perso.
Si tu réponds oui, alors donne moi un bout de code répondant au 1er standard C++, c'est à dire de 1998 (donc, non, pas de 1995…) que je ne puisse pas compiler avec, par exemple, clang3.8.
Quant au C++17, vu qu'il n'est pas encore sorti, ça va être difficile de tester.
Tu vas pouvoir le compiler.
Et ton template, ou autre chose de pas kasher dans un header qq part, il va te jeter un warning, ou autre joyeuseté du genre. Et tu vas devoir porter le code, la, maintenant, parce qu'un warning, c'est une erreur, et que "if not now, then when?".
Je dis pas ca genre c'est horrible oh mon dieu le c++, Java te ferais la même chose avec des collections non typées, Swift va te casser les couilles sur un des millions de petits trucs qui ont changé depuis, etc.
Mon point c'est précisément que du coup vieux de 10 ans qui a pas été mit à jour, c'est du code pas maintenu, et le code pas maintenu, ben c'est plutôt pas terrible, et va falloir s'atteler à la tâche. Ca répondait à zenitram qui sous entendait que tu peux prendre du code vieux de 15 ans, le plopper dans ton projet et roule ma poule.
Et oui, clairement, avoir un compilo ca aide pour porter du code. C'est ce que je voulais dire par "est ce qu'on aura toujours une communauté et un compilo/interpreteur moderne 10 ans plus tard.".
Swift n'a pas de gc. Arc est pure compile time, et 100% déterministe.
Sinon, pour la pérennité, Ben non, t'es à peu près sûr que ca marchera pas.
Comme pour du c++ de 1995 dans un projet c++17.
Comme pour du Swift 2.3 dans 10 ans.
Ou du ruby. Ou plus ou moins tous les langages de la planète, sorti de c et Java, et les brontosaures qui sont figés dans le temps, fortran, cobol etc.
Et encore, même Java, ton code tu vas vouloir le moderniser.
Bref, la question c'est pas tant est ce que ca va tourner à l'identique (on a des release binaires et des abi stables pour ca), mais quel est le coût de maintenance au fil de l'eau, et est ce qu'on aura toujours une communauté et un compilo/interpreteur moderne 10 ans plus tard.
Swift est le langage de prédilection de la plateforme de development la plus populaire du moment, tourne sur quelque centaines de million de devices, et est poussé par la corporation la plus riche de la planète, connue pour faire des choix technologiques a tres long terme. Et qui au passage est aussi connue pour être une brute sur tout ce qui est dev tools, et emploie une des équipe de compilation les plus brillantes de la planète.
Je pense pas trop m'avancer en pariant que le language sera toujours la dans 10 ans.
Je voit pas ce que Python vient faire dans la catégorie "rapide, natif et toujours haut niveau", mais je te ferais remarquer que le langage a 25 ans. Dit autrement, il est sorti avant que t'envisages une carrière dans l'informatique. Et probablement même avant que tu comprennes vraiment le sens du mot "carrière".
le preprocesseur, le problème c'est son existence même. Le remplacement de chaînes de textes à la rache, c'était raisonnable en 77, plus vraiment en 2000.
les temps de compilation sont long, tres long. Et non, Java n'est clairement pas dans le même ordre de grandeur. Java peut être long sur les builds de release, quand tu lances les validateurs de styles, la génération de doc, les tests unitaires et tout ce genre de trucs. Mais tu fais tout ça pour une bonne raison, et la majeure partie à pas grand chose à voir avec le langage, mais la release. Sur un build de dev dans un ide, Java est plutôt rapide. Déjà rien que zapper le linker, quand on voit le temps que ca peut prendre sur un projet c++ costaud… Et c'est une métrique importante, tout ce qui contribue à une loop de feedback rapide est important
les generics Java ont leurs problèmes clairement (cough type erasure cough), mais bon. Ce que tu dit la, c'est en gros "les templates c++ sont un bordel sans nom, mais si tu te limites à juste une partie, c'est comme les autres langages". Sauf que tu te tapes toujours une compilation du template à chaque instantiation sur un type donne. Et ca rejoins l'autre critique: toutes ces features ont un coût, il faut les comprendre, savoir quand ne pas les utiliser, et faire doublement gaffe en code review.
la culture est pas la même sur la lib std: oui, c'est précisément le problème, cette culture.
'fin c'est chelou, tu demandes quels sont les points qui posent problèmes, quand on te les donne tu réponds en substance "ouais, c'est des problèmes, mais c'est pas grave, si on ignore les problèmes, y'a plus de problèmes".
Ben ouais, forcément.
une complexité terrifiante, avec un empilement de features parfois obscures, au point que la plupart des projets sérieux définissent explicitement ce qui est autorisé,
une syntaxe lourde, illisible et qui fait mal à la tête
des undefined behavior en veux tu en voilà
gestion manuelle de la mémoire (ca s'améliore)
des temps de compilations affreusement long
des messages d'erreurs de compilateurs ahurissant
une abi plus capricieuse que ma fille de 9 mois
des reliques du passé qui ne devraient plus exister dans un langage moderne, genre les header ou l'arithmétique de pointeurs
un manque de features moderne (optional, switch/case utile, enums objets, catégories/mixins etc)
Ca s'améliore ces derniers temps, mais tres, tres lentement.
Y'a un certain nombre de languages qui avancent sur le créneau "rapide, natif et toujours haut niveau" genre Swift, go ou rust.
Pour choisir c++ sur un nouveau projet, faut avoir de besoins très spécifiques. A la vitesse à laquelle la concurrence avance, mon petit doigt me dit que sous qq années, la principale raison de faire du c++, ca sera des raisons historiques.
Et toi, c'était quand le dernière fois que t'as admit que t'avais raconte des conneries?
Non, parce que tu débites un sacré paquet de troll à la minute quand même.
Le vigile arrive après qu'il ait tout pete, fin si on en croit la video, donc pas de flagrance pour lui,
Et les pommes employés ont sûrement pas envie de se fritter avec un mec qui a une boule de pétanque à la main.
Super coup de pub, des produits éclaté a la boule de pétanque et un connard en garde a vue!
Pis vu comment l'iPhone 7 est en back order pour 2 a 6 semaines, ils en ont clairement vachement besoin.
D'une part, c'est faux. Apple patch les failles critiques Dans la version n-1 même quand la version n est sortie. iOS 6 a eu son patch pour goto fail 6 mois après la sortie de 7.
D'autee part, si tu veux jouer à ce jeu, on peut s'amuser à compter le nombre de device exposés à des failles systèmes (ou les applis customs des opérateurs) qui n'ont jamais été updates par les opérateurs, et ca va pas aller dans ton sens.
Et même avec le playstore, quand je regarde chrome je vois "varies with device". Et pour les devices pre KitKat, autant ils utilisent aosp browser par défaut, et bonne fête des morts pour le mettre à jour lui.
En pratique, un téléphone Android ne recevra des mise à jour que pendant un an. Pas loin de la moitié des devices android tournent sur un os vieux de plus de 3 ans (KitKat). J'ai 46% d'iOS 10 15 jours après la sortie, 0.18% de gens qui ont un iOS qui date de 2013 ou plus vieux.
Compares le support moyen android à un ipad 2 qui a été 100% supporte pendant 5 ans, ou n'importe quel iPhone qui a 4 ans de support actif.
4 ans c'est tellement long à l'échelle du smartphone qu'en pratique ceux qui ont un téléphone aussi vieux ne s'en servent pas comme smartphone. Le 4s fait 0.15% de nos utilisateurs sur les 15 derniers jours, pour référence. 500 personnes sur 300 000.
Pas de quoi fouetter un chat.
Avoir les mises a jour : Ça fait un mois que je suis sous Android 7 … change de fabricant, s'il ne mets pas a jours
Wooaaaaa! Un téléphone de moins d'un an a des mises à jours, trop la classe, hé.
Bon, douleur pour ceux qui on un Nexus 5, qui lui n'aura eu au final que 2 mises à jour majeures.
Et encore, ca, c'est pour la crème de la crème, le fleuron de la marque Android.
Pendant ce temps la, en face, mon vénérable iPhone 5 de test en est à sa 4ieme mise à jour majeure, soit au moins 5 ans de support, et c'est pas exclut qu'il en reçoive une 5ieme l'année prochaine.
Bon, si tu as une fonction A qui devient B en terme de nommage sans changement à l'intérieur, tu fais tout à la main ? Tu valides chaque changement ?
Avant de balancer en production? Oui.
Les "c'est un petit patch, pis il est facile, il peut rien peter" je l'ai entendu un peu trop souvent, généralement pas longtemps avant que pager duty me gueule dessus.
Sans compter que bon, c'est typiquement le genre de trucs irrespectueux que je mentionnais plus haut. Les devs tiers ont autre chose a foutre que du sed + revalidation de leur code juste parce que quelqu'un n'a pas prit la peine de penser son nom de fonction suffisamment en detail, et decide de le changer.
'fin bon, vu le ton de la discussion, autant pisser dans un violon.
mais outre le marketing il y a la marge qui est immense, tu l'as dit toi même.
Bof. Elle est qu'a 30%. C'est plus que la plupart des constructeurs, mais si tu compares a des marges soft, c'est que dalle.
La marge + le marketing sont une grosse partie du prix des périphériques Apple, et ces éléments n'affectent en rien la qualité. La R&D est en dehors de la marge opérationnelle…
Ben pourtant, les ingénieurs, ils bossent pas a l'oeil, et faut bien les payer, et si possible avec les telephones vendus.
Pas forcément, les changements qui impactent les pilotes usuels dans le noyau sont souvent triviaux, souvent corrigés par des scripts.
Bref, pas besoin d'avoir le matos nécessairement sous la main.
Ah ben forcement, si les pilotes sont patches sans que le patcheur ne puisse tester son changement sur le matos a coup de git commit -A -m "J'ai patché les poutches, ca devrait marcher, mais au final j'en sait trop rien", ca explique bien des choses… Ca, c'est du rock, comme dirait l'autre.
La R&D n'a aucun impact sur la qualité du produit?
Leur extreme attention au detail et a la durabilité du produit (un 5 vieux de 4 ans fonctionne toujours tres bien sous ios 10, je le sait c'est mon device de test) n'a aucun impact sur la qualité du produit?
Le design intrinseque du produit (chassis costaud en alu) n'a aucun impact sur la durabilité du produit?
'fin ca a pas grand chose a voir avec la question.
Zenitram affirme que plus de la moitié du prix de l'iPhone part dans le marketing. Je demande une source.
Apple a une marge opérationnelle d'environ 30 a 35%. Le cout de fabrication est d'environ 30 a 35% du prix du telephone, suivant les sources.
Si je fait le calcule correctement, ca veut dire qu'il reste 30 a 40% du prix du telephone pour couvrir la R&D, le support, la logistique, le marketing et la pub. La R&D est clairement pas cheap, designer autant de CPU custom (secure enclave, M7, A10, et maintenant W1), c'est loin d'être cheap, de meme pour tout le reste du développement soft (vu les salaires ingénieurs us, c'est en milliards qu'il se compte le payroll d'apple).
Bref, c'etait une question réthorique. Apple est justement connu pour avoir un budget marketing/pub plutot faible une fois rapporté a leur volumes de ventes.
Le zenitram si pointilleux sur ces points de details est d'un coup vachement moins pointilleux quand ca l'arrange.
Ah ben c'est sur, si désigner, chez toi ca vaut dire "le mec qui dessine le boîtier du téléphone", forcément. En pratique, ca va un chtouille plus loin que ca.
Pour reprendre l'exemple de l'iPhone, plus de la moitié du prix est dans le marketing et je ne vois pas en quoi investir dans le marketing va rendre le produit plus résistant.
Source?
Les designers, ils bossent à l'œil?
Les ingénieurs soft aussi?
Moui, enfin yen a qui arrive à faire évoluer un framework sans tout peter en permanence.
AppKit et UIKit sont pas tous jeunes, et tu peux builder une appli vieille de 10 ans contre les dernières versions avec à peu près 0 problème. Le passage à la nouvelle version majeure prend rarement plus de 1 ou 2 jours, pour peu que tu suives un minimum les conventions.
Et même les nouvelles api viennent avec le même esprit que les existantes, ce qui facilite très grandement leur prise en main et adoption.
Je sais pas comment ca se passe sous Windows, mais je serais surpris si ca se passait différemment. Peter la compatibilité source, c'est irrespectueux et ca épuise les développeurs tiers.
Ca leur fait gâcher du temps qui n'est pas passé à bosser sur leur appli.
LOL fdroid. Le store qui vient d'annoncer en 2016 qu'ils supportent finalement les downloads en tache de fond et qui est rempli de pré Alpha finie à la pisse. Effectivement, ouais.
C'est juste que les drivers ne sont pas encore tous libre.
Et donc c'est pas encore libre?
Nan parce que le driver GSM ou GPS, c'est important sur un téléphone quand même, tu trouve pas?
Nan, parce que sinon à ce compte la, Windows est pas encore libre, donc c'est libre. Implacable ta logique.
Tu m'excusera de ne pas dédié ma mémoire a une entreprise que je haï de toute manière,
Marrant que tu te rappelles pas du procès qui a "terni a jamais leur réputation", visiblement t'avais décidé avant ce procès que tu les haïssais (c'est vachement fort comme mot quand même). J'en conclus que ce procès (qui n'a jamais existé soit dit en passant), ne t'as pas tant affecté que ca, et que tu racontes donc un peu beaucoup des conneries?
2) les preuves impossible a nier ils balancent que toute façon rien n'est libre suffit de regarder l'état des drivers sous Linux/Android/BSD/etc.
Non, j'ai parlé des drivers sous Android. Pas sous Linux ou bsd.
Il n'en reste qu'Android est aussi libre que Debian.
Non. La vaste majorité des applications android vont être au mieux amputees sans les google services. Une part faramineuse des applis existantes ont besoin des google services pour tourner.
C'est pas le cas des applis debian.
Raspberry Pi et ses concurrents font pression pour libérer un max de drivers, au bout d'un moment on pourra surement se faire un smartphone totalement libre avec de l'android/debian/ubuntu/voyager.
Et ben on en reparlera le jour ou ils auront réussi. Savoir que ca marchera potentiellement un jour, ca me fait une belle jambe.
Pour ton exemple de procès sur le soft, je n'en ai pas sous la main (flemme) mais je me rappel très bien d'une attaque en justice d'Apple contre Android (google) pour "plagiat" envers le menu déroulant du haut.
???
tout ce que je trouve sur le notification center, c'est samsung qui menaçait de porter plainte contre apple.
Marrant quand meme, on est passe de "ils attaquent tout le monde en justice" a "je me rappelle vaguement de cette histoire qui est arrive une fois, mais j'ai meme plus les details".
Mouais, d'un cote twitter se fait (a juste titre) défoncer quand ils ne font rien contre le harcèlement, et de l'autre ils se font insulter quand ils font qq chose.
Le pere Ney a l'air d'etre un drole d'oiseau, mais on est en droit de se demander quelle est la pertinence de publier son numéro de telephone, et surtout qu'est ce que reflets pense qu'il va arriver une fois publie? Tu peux tourner ca comme tu veux, ca, c'est tres limite.
Apres, oui, on est en droit de questionner les tweets du pere ney. Perso, meme si je trouve ca deplorable, c'est son droit d'être.
Et aussi son droit de répéter a qui veut l'entendre ce genre de conneries.
La ou ca se corse, comme on dit a Bastia, c'est quand des rigolos de ce genre se servent de leur horde de follower pour harceler les gens. Ce qui nous ramène au point 1. Problème c'est que le trolls sont suffisamment subtils, et twitter en a suffisamment rien a foutre pour que ca passe.
Apres, effectivement, ca fait tres ridicule/gaminerie vu de l'extérieur ces histoires kitetoa/jpney.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à -1.
nohup n'a pas été cassé, non.
Le process ignore toujours sighup. Systemd envoie un sigterm/sigkill.
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 8.
Bon, si tu veux troller avec moi sur les technos apple, va falloir affuter et te documenter un peu mieux que ca.
Deja, ca fait bien qq années qu'il ya des discussions pour moderniser Objective-C. Apple a mit un bon coup de collier sur la deuxième moitié des années 2000, et clang a fait des merveilles sur la période 2010-2013.
Ca ne change pas que quasiment tout le monde dans la communauté trouve qu'objective c est vieillot. Pointeurs, header, type scalaires pas objets (avec acrobaties via NSNumber ou NSValue), enums pourries, collections qui refusent nil, grosso modo toute la partie héritée directement de C a toujours dérangé la plupart des gens.
Yavait des débats sur le message sending par dessus tout ca, mais c'etait deja moins sujet a troll.
Bref, ca fait longtemps qu'objc est plus le future d'iOS/OSX. Au mieux, il était le present.
M'enfin, c'est sur que c'est pas en trollant a l'emporte piece sur linuxfr que tu vas apprendre ca.
Comme je sens une point d'ironie, voila la liste des technologies officiellement poussées par apple:
Voila pour la leçon d'histoire.
Je vois 4 phases la dedans. Le 3 premieres ont durées au moins 13 ans.
Je te laisse deviner combien de temps va durer la 4ieme.
Si tu veux des indices: les seules features qu'objective c a reçu depuis 2014 servent a faciliter l'intefacage avec swift. Tous les ingénieurs d'apple avec qui j'ai bosse sur le campus poussent activement swift auprès des third party. WWDR aussi. Ca va devient dur de trouver un boulot dans le domaine si tu connais pas swift (perso je rejette d'emblée tout resume qui ne mentionne pas swift).
Voila, en deux ans, objective c est passe de seul language possible a legacy. Tu peux troller ce que tu veux, mais après 15 ans a apple, et une bonne dizaine a next, je trouve pas ca degueu comme duree de vie.
Apres, on peut aller en detail dans les raisons du changement.
Principalement le fait que objective c est super pas fiable de base (philosophie c "tu tiens la tronçonneuse toi meme"), et le fait qu'aussi douee soit l'équipe du runtime, ils ont atteint un mur de performance et de design. Ils peuvent tout simplement pas faire évoluer le language sans une cassure de compat'.
Tu veux dire le truc qu'ils ont supporte de 99 a 2011?
Effectivement, un bon exemple. Tu noteras aussi que le marche firewire était bien mort depuis la moitié des années 2000. Apple a continue a le pousser malgré le fait qu'usb 2 ait gagne la guerre, et que firewire n'était utilise en gros que pour les camera DV (qui généralement proposait aussi une sortie usb).
sigh.
C'est quoi ton point? Qu'apple supporte c++? Support, youpi, apple supporte c++. Et donc? A pas troller a l'emporte piece?
J'ai dit que c++ allait disparaitre du jour au lendemain? Non, j'ai dit que démarrer un nouveau project en c++ ne ferait probablement pas beaucoup de sens dans qq années, sortis de besoins tres spécifiques.
Ben putain, il te faut pas grand chose.
En 95, t'etais au college, potentiellement au lycée. A cet age la, on ne sait pas ce que le mot "carrière" veut dire.
Ce language que tu traites de mode a été dans l'industrie plus longtemps que toi. J'appelle pas ca une mode, perso.
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 1.
Tu vas pouvoir le compiler.
Et ton template, ou autre chose de pas kasher dans un header qq part, il va te jeter un warning, ou autre joyeuseté du genre. Et tu vas devoir porter le code, la, maintenant, parce qu'un warning, c'est une erreur, et que "if not now, then when?".
Je dis pas ca genre c'est horrible oh mon dieu le c++, Java te ferais la même chose avec des collections non typées, Swift va te casser les couilles sur un des millions de petits trucs qui ont changé depuis, etc.
Mon point c'est précisément que du coup vieux de 10 ans qui a pas été mit à jour, c'est du code pas maintenu, et le code pas maintenu, ben c'est plutôt pas terrible, et va falloir s'atteler à la tâche. Ca répondait à zenitram qui sous entendait que tu peux prendre du code vieux de 15 ans, le plopper dans ton projet et roule ma poule.
Et oui, clairement, avoir un compilo ca aide pour porter du code. C'est ce que je voulais dire par "est ce qu'on aura toujours une communauté et un compilo/interpreteur moderne 10 ans plus tard.".
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
Swift n'a pas de gc. Arc est pure compile time, et 100% déterministe.
Sinon, pour la pérennité, Ben non, t'es à peu près sûr que ca marchera pas.
Comme pour du c++ de 1995 dans un projet c++17.
Comme pour du Swift 2.3 dans 10 ans.
Ou du ruby. Ou plus ou moins tous les langages de la planète, sorti de c et Java, et les brontosaures qui sont figés dans le temps, fortran, cobol etc.
Et encore, même Java, ton code tu vas vouloir le moderniser.
Bref, la question c'est pas tant est ce que ca va tourner à l'identique (on a des release binaires et des abi stables pour ca), mais quel est le coût de maintenance au fil de l'eau, et est ce qu'on aura toujours une communauté et un compilo/interpreteur moderne 10 ans plus tard.
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 3.
Swift est le langage de prédilection de la plateforme de development la plus populaire du moment, tourne sur quelque centaines de million de devices, et est poussé par la corporation la plus riche de la planète, connue pour faire des choix technologiques a tres long terme. Et qui au passage est aussi connue pour être une brute sur tout ce qui est dev tools, et emploie une des équipe de compilation les plus brillantes de la planète.
Je pense pas trop m'avancer en pariant que le language sera toujours la dans 10 ans.
Je voit pas ce que Python vient faire dans la catégorie "rapide, natif et toujours haut niveau", mais je te ferais remarquer que le langage a 25 ans. Dit autrement, il est sorti avant que t'envisages une carrière dans l'informatique. Et probablement même avant que tu comprennes vraiment le sens du mot "carrière".
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 10.
'fin c'est chelou, tu demandes quels sont les points qui posent problèmes, quand on te les donne tu réponds en substance "ouais, c'est des problèmes, mais c'est pas grave, si on ignore les problèmes, y'a plus de problèmes".
Ben ouais, forcément.
[^] # Re: Donc pour résumer…
Posté par groumly . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 9.
Lui, je sais pas mais moi:
Ca s'améliore ces derniers temps, mais tres, tres lentement.
Y'a un certain nombre de languages qui avancent sur le créneau "rapide, natif et toujours haut niveau" genre Swift, go ou rust.
Pour choisir c++ sur un nouveau projet, faut avoir de besoins très spécifiques. A la vitesse à laquelle la concurrence avance, mon petit doigt me dit que sous qq années, la principale raison de faire du c++, ca sera des raisons historiques.
[^] # Re: Feature phone
Posté par groumly . En réponse au journal Purism lance un sondage pour la création d'un téléphone entièrement libre avec infra chiffrée. Évalué à 3.
Facebook/snapchat, messenger/iMessage/Hangout et un Browser web.
Super simple à faire tenir sur un feature phone a e-ink.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à 2.
Et toi, c'était quand le dernière fois que t'as admit que t'avais raconte des conneries?
Non, parce que tu débites un sacré paquet de troll à la minute quand même.
[^] # Re: Petites remarques
Posté par groumly . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 1. Évalué à 10.
Ca se trouve, il est égyptien et riche.
[^] # Re: $
Posté par groumly . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 3.
Le vigile arrive après qu'il ait tout pete, fin si on en croit la video, donc pas de flagrance pour lui,
Et les pommes employés ont sûrement pas envie de se fritter avec un mec qui a une boule de pétanque à la main.
[^] # Re: $
Posté par groumly . En réponse au journal Lequel d'entre vous a fait ça ?. Évalué à 0.
Super coup de pub, des produits éclaté a la boule de pétanque et un connard en garde a vue!
Pis vu comment l'iPhone 7 est en back order pour 2 a 6 semaines, ils en ont clairement vachement besoin.
[^] # Re: Mon retour Ubuntu Phone + Bug Indicateur réseau
Posté par groumly . En réponse au journal Ubuntu Phone, un an après. Évalué à 6.
D'une part, c'est faux. Apple patch les failles critiques Dans la version n-1 même quand la version n est sortie. iOS 6 a eu son patch pour goto fail 6 mois après la sortie de 7.
D'autee part, si tu veux jouer à ce jeu, on peut s'amuser à compter le nombre de device exposés à des failles systèmes (ou les applis customs des opérateurs) qui n'ont jamais été updates par les opérateurs, et ca va pas aller dans ton sens.
Et même avec le playstore, quand je regarde chrome je vois "varies with device". Et pour les devices pre KitKat, autant ils utilisent aosp browser par défaut, et bonne fête des morts pour le mettre à jour lui.
En pratique, un téléphone Android ne recevra des mise à jour que pendant un an. Pas loin de la moitié des devices android tournent sur un os vieux de plus de 3 ans (KitKat). J'ai 46% d'iOS 10 15 jours après la sortie, 0.18% de gens qui ont un iOS qui date de 2013 ou plus vieux.
Compares le support moyen android à un ipad 2 qui a été 100% supporte pendant 5 ans, ou n'importe quel iPhone qui a 4 ans de support actif.
4 ans c'est tellement long à l'échelle du smartphone qu'en pratique ceux qui ont un téléphone aussi vieux ne s'en servent pas comme smartphone. Le 4s fait 0.15% de nos utilisateurs sur les 15 derniers jours, pour référence. 500 personnes sur 300 000.
Pas de quoi fouetter un chat.
[^] # Re: Mon retour Ubuntu Phone + Bug Indicateur réseau
Posté par groumly . En réponse au journal Ubuntu Phone, un an après. Évalué à 3.
Wooaaaaa! Un téléphone de moins d'un an a des mises à jours, trop la classe, hé.
Bon, douleur pour ceux qui on un Nexus 5, qui lui n'aura eu au final que 2 mises à jour majeures.
Et encore, ca, c'est pour la crème de la crème, le fleuron de la marque Android.
Pendant ce temps la, en face, mon vénérable iPhone 5 de test en est à sa 4ieme mise à jour majeure, soit au moins 5 ans de support, et c'est pas exclut qu'il en reçoive une 5ieme l'année prochaine.
[^] # Re: GTK+4
Posté par groumly . En réponse à la dépêche Firefox 49 en chansons. Évalué à 1.
Avant de balancer en production? Oui.
Les "c'est un petit patch, pis il est facile, il peut rien peter" je l'ai entendu un peu trop souvent, généralement pas longtemps avant que pager duty me gueule dessus.
Sans compter que bon, c'est typiquement le genre de trucs irrespectueux que je mentionnais plus haut. Les devs tiers ont autre chose a foutre que du sed + revalidation de leur code juste parce que quelqu'un n'a pas prit la peine de penser son nom de fonction suffisamment en detail, et decide de le changer.
'fin bon, vu le ton de la discussion, autant pisser dans un violon.
[^] # Re: Effet d'annonce ?
Posté par groumly . En réponse au journal Réparabilité de l’électroménager : SEB s’engage. Évalué à 3.
wut? Ca veut rien dire ta phrase.
Bof. Elle est qu'a 30%. C'est plus que la plupart des constructeurs, mais si tu compares a des marges soft, c'est que dalle.
Ben pourtant, les ingénieurs, ils bossent pas a l'oeil, et faut bien les payer, et si possible avec les telephones vendus.
[^] # Re: GTK+4
Posté par groumly . En réponse à la dépêche Firefox 49 en chansons. Évalué à 3.
Ah ben forcement, si les pilotes sont patches sans que le patcheur ne puisse tester son changement sur le matos a coup de
git commit -A -m "J'ai patché les poutches, ca devrait marcher, mais au final j'en sait trop rien", ca explique bien des choses… Ca, c'est du rock, comme dirait l'autre.[^] # Re: Effet d'annonce ?
Posté par groumly . En réponse au journal Réparabilité de l’électroménager : SEB s’engage. Évalué à 3.
La R&D n'a aucun impact sur la qualité du produit?
Leur extreme attention au detail et a la durabilité du produit (un 5 vieux de 4 ans fonctionne toujours tres bien sous ios 10, je le sait c'est mon device de test) n'a aucun impact sur la qualité du produit?
Le design intrinseque du produit (chassis costaud en alu) n'a aucun impact sur la durabilité du produit?
Tu vis sur quelle planète?
[^] # Re: Effet d'annonce ?
Posté par groumly . En réponse au journal Réparabilité de l’électroménager : SEB s’engage. Évalué à 1.
'fin ca a pas grand chose a voir avec la question.
Zenitram affirme que plus de la moitié du prix de l'iPhone part dans le marketing. Je demande une source.
Apple a une marge opérationnelle d'environ 30 a 35%. Le cout de fabrication est d'environ 30 a 35% du prix du telephone, suivant les sources.
Si je fait le calcule correctement, ca veut dire qu'il reste 30 a 40% du prix du telephone pour couvrir la R&D, le support, la logistique, le marketing et la pub. La R&D est clairement pas cheap, designer autant de CPU custom (secure enclave, M7, A10, et maintenant W1), c'est loin d'être cheap, de meme pour tout le reste du développement soft (vu les salaires ingénieurs us, c'est en milliards qu'il se compte le payroll d'apple).
Bref, c'etait une question réthorique. Apple est justement connu pour avoir un budget marketing/pub plutot faible une fois rapporté a leur volumes de ventes.
Le zenitram si pointilleux sur ces points de details est d'un coup vachement moins pointilleux quand ca l'arrange.
[^] # Re: Effet d'annonce ?
Posté par groumly . En réponse au journal Réparabilité de l’électroménager : SEB s’engage. Évalué à 1.
Ah ben c'est sur, si désigner, chez toi ca vaut dire "le mec qui dessine le boîtier du téléphone", forcément. En pratique, ca va un chtouille plus loin que ca.
[^] # Re: Effet d'annonce ?
Posté par groumly . En réponse au journal Réparabilité de l’électroménager : SEB s’engage. Évalué à -5.
Source?
Les designers, ils bossent à l'œil?
Les ingénieurs soft aussi?
[^] # Re: GTK+4
Posté par groumly . En réponse à la dépêche Firefox 49 en chansons. Évalué à 5.
Moui, enfin yen a qui arrive à faire évoluer un framework sans tout peter en permanence.
AppKit et UIKit sont pas tous jeunes, et tu peux builder une appli vieille de 10 ans contre les dernières versions avec à peu près 0 problème. Le passage à la nouvelle version majeure prend rarement plus de 1 ou 2 jours, pour peu que tu suives un minimum les conventions.
Et même les nouvelles api viennent avec le même esprit que les existantes, ce qui facilite très grandement leur prise en main et adoption.
Je sais pas comment ca se passe sous Windows, mais je serais surpris si ca se passait différemment. Peter la compatibilité source, c'est irrespectueux et ca épuise les développeurs tiers.
Ca leur fait gâcher du temps qui n'est pas passé à bosser sur leur appli.
[^] # Re: firefox
Posté par groumly . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 3.
LOL fdroid. Le store qui vient d'annoncer en 2016 qu'ils supportent finalement les downloads en tache de fond et qui est rempli de pré Alpha finie à la pisse. Effectivement, ouais.
Et donc c'est pas encore libre?
Nan parce que le driver GSM ou GPS, c'est important sur un téléphone quand même, tu trouve pas?
Nan, parce que sinon à ce compte la, Windows est pas encore libre, donc c'est libre. Implacable ta logique.
Marrant que tu te rappelles pas du procès qui a "terni a jamais leur réputation", visiblement t'avais décidé avant ce procès que tu les haïssais (c'est vachement fort comme mot quand même). J'en conclus que ce procès (qui n'a jamais existé soit dit en passant), ne t'as pas tant affecté que ca, et que tu racontes donc un peu beaucoup des conneries?
Non, j'ai parlé des drivers sous Android. Pas sous Linux ou bsd.
[^] # Re: firefox
Posté par groumly . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 5.
Non. La vaste majorité des applications android vont être au mieux amputees sans les google services. Une part faramineuse des applis existantes ont besoin des google services pour tourner.
C'est pas le cas des applis debian.
Et ben on en reparlera le jour ou ils auront réussi. Savoir que ca marchera potentiellement un jour, ca me fait une belle jambe.
???
tout ce que je trouve sur le notification center, c'est samsung qui menaçait de porter plainte contre apple.
Marrant quand meme, on est passe de "ils attaquent tout le monde en justice" a "je me rappelle vaguement de cette histoire qui est arrive une fois, mais j'ai meme plus les details".
[^] # Re: Oui, enfin quand on regarde les détails...
Posté par groumly . En réponse au journal Quand on délègue sa liberté d'expression à twitter. Évalué à 8.
Mouais, d'un cote twitter se fait (a juste titre) défoncer quand ils ne font rien contre le harcèlement, et de l'autre ils se font insulter quand ils font qq chose.
Le pere Ney a l'air d'etre un drole d'oiseau, mais on est en droit de se demander quelle est la pertinence de publier son numéro de telephone, et surtout qu'est ce que reflets pense qu'il va arriver une fois publie? Tu peux tourner ca comme tu veux, ca, c'est tres limite.
Apres, oui, on est en droit de questionner les tweets du pere ney. Perso, meme si je trouve ca deplorable, c'est son droit d'être.
Et aussi son droit de répéter a qui veut l'entendre ce genre de conneries.
La ou ca se corse, comme on dit a Bastia, c'est quand des rigolos de ce genre se servent de leur horde de follower pour harceler les gens. Ce qui nous ramène au point 1. Problème c'est que le trolls sont suffisamment subtils, et twitter en a suffisamment rien a foutre pour que ca passe.
Apres, effectivement, ca fait tres ridicule/gaminerie vu de l'extérieur ces histoires kitetoa/jpney.