lit toutes les pages man, aucune ne mentionne de logout, uniquement "immunité au sighup". Ce qui parait logique, sinon la commande serait appelée nologout.
Que la doc GNU fasse un raccourci sighup == log out illustre bien l'ampleur du problème et a quel point des guignols comme Albert passent pour des clowns (et encore je met le L pour rester poli).
nohup est documente comme "le process resistera a sighup".
La doc de sighup dit "le signal est envoye quand le controlling terminal est ferme".
rien ne documente ce qu'il se passe quand la derniere session de l'utilisateur est fermée (i.e. quand l'utilisateur se délogue).
ET C'EST TRES PRECISEMENT LE PROBLEME QUE SYSTEMD ADDRESSE.
C'est une sémantique qui est complètement absente de posix, et cette absence de sémantique a mene au bordel actuel.
Pour revenir a l'enculage de mouche initial: systemd a change un comportement non documente. Donc systemd n'a rien casse, vu qu'il n'y a rien de documenter.
Albert_ Trump le windowsien reposait depuis des années sur un details d'implementation non documente qui pouvait changer a tout moment pour faire son admin comme un clampin, et vient par derriere donner des leçons, comme a son habitude.
systemd n'envoie pas un hangup.
L'appli survit au hangup. Par contre, ya rien qui dit que lorsque l'utilisateur se déloge, l'init est pas cense nettoyer les process qui n'ont rien a foutre la a coup de sigterm/sigkill.
C'est juste pas documente, tu peux pas casser quelque chose qui n'est pas documente.
Quitte à troller, je dirai que le workflow digne de Windows 98, ce serait bien de se dire « je laisse ma session ouverte parce que si je la ferme apache.exe de mon WAMP va se faire tuer ».
Ce workflow est pas tellement mieux que:
ssh user@host
nohup httpd &
Ctrl d
Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.
Si tu veux que ca tourne en tache de fond, fais en un vrai service, ou dit a systemd que c'est un service ad hoc (e.g. une tâche qui tourne longtemps en background et va se terminer toute seule).
Ben écoutes, lit la man page de nohup, et revient me dire que ca devrait survivre à un sigkill,
Tout ce que man dit, c'est que le process survit nohup quand le controlling terminal est fermé. Pas que lorsque la session est fermée, tous les zombie doivent rester vivant, highlander style, contre vents et marée, même quand pinpin au pays des trululu a décider de ssh dans une machine de prod et nohup un process à la rache et l'oublier la.
Si t'as un workflow digne de Windows 98, ca ne regarde que toi.
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.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à 0.
lit toutes les pages man, aucune ne mentionne de logout, uniquement "immunité au sighup". Ce qui parait logique, sinon la commande serait appelée nologout.
Que la doc GNU fasse un raccourci sighup == log out illustre bien l'ampleur du problème et a quel point des guignols comme Albert passent pour des clowns (et encore je met le L pour rester poli).
nohup est documente comme "le process resistera a sighup".
La doc de sighup dit "le signal est envoye quand le controlling terminal est ferme".
rien ne documente ce qu'il se passe quand la derniere session de l'utilisateur est fermée (i.e. quand l'utilisateur se délogue).
ET C'EST TRES PRECISEMENT LE PROBLEME QUE SYSTEMD ADDRESSE.
C'est une sémantique qui est complètement absente de posix, et cette absence de sémantique a mene au bordel actuel.
Pour revenir a l'enculage de mouche initial: systemd a change un comportement non documente. Donc systemd n'a rien casse, vu qu'il n'y a rien de documenter.
Albert_ Trump le windowsien reposait depuis des années sur un details d'implementation non documente qui pouvait changer a tout moment pour faire son admin comme un clampin, et vient par derriere donner des leçons, comme a son habitude.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à 1.
systemd n'envoie pas un hangup.
L'appli survit au hangup. Par contre, ya rien qui dit que lorsque l'utilisateur se déloge, l'init est pas cense nettoyer les process qui n'ont rien a foutre la a coup de sigterm/sigkill.
C'est juste pas documente, tu peux pas casser quelque chose qui n'est pas documente.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à -2.
Ah oui, tu m'en diras tant. on dirait une réponse de Trump quand on lui a cloué le bec. T'es la pour rendre Linux grand à nouveau?
Et donc, sinon, la man page de nohup, elle dit quoi au sujet de sigterm, sigkill et la fermeture de la session utilisateur?
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à 2.
Ce workflow est pas tellement mieux que:
ssh user@host
nohup httpd &
Ctrl d
Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.
Si tu veux que ca tourne en tache de fond, fais en un vrai service, ou dit a systemd que c'est un service ad hoc (e.g. une tâche qui tourne longtemps en background et va se terminer toute seule).
Les zombies, c'était une façon de parler.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par groumly . En réponse au journal systemd: attention à RemoveIPC. Évalué à -1.
Ben écoutes, lit la man page de nohup, et revient me dire que ca devrait survivre à un sigkill,
Tout ce que man dit, c'est que le process survit nohup quand le controlling terminal est fermé. Pas que lorsque la session est fermée, tous les zombie doivent rester vivant, highlander style, contre vents et marée, même quand pinpin au pays des trululu a décider de ssh dans une machine de prod et nohup un process à la rache et l'oublier la.
Si t'as un workflow digne de Windows 98, ca ne regarde que toi.
[^] # 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.