Moui, faut nuancer un peu quand même. Redhat est loin d'être parmi les employeurs les plus compétitifs et un rapide coup d'oeil à glassdoor me montre que le gars gagne probablement nettement moins qu'un développeur un poil expérimenté chez Google par exemple.
Je ne dis pas qu'ils ne sont pas bon, loin de là. Au contraire, je pense que le rapport qualité/prix est assez élevé. Il n'en reste pas moins que Redhat fait exactement comme toutes les autres boîtes: recruter les meilleurs parmi ceux qu'ils peuvent s'offrir, ce qui est différent des meilleurs dans l'absolu.
Bref je pense qu'il est assez légitime de dire que tel ou tel bout de code ne serait pas jugé acceptable ailleurs. Et la réponse n'est pas nécessairement que ceux qui l'affirment pourraient aller prétendre au salaire du gars qui a pondu le code, mais aussi parfois qu'ils gagnent déjà bien plus (ou bien assez) ailleurs.
Et puis y a pas que l'argent dans la vie non plus, donc l'argument "si tu peux faire mieux, va te faire payer à sa place" est beaucoup trop simpliste, peu importe la façon dont on aborde le problème.
Au passage, ce bout de code ne serait jamais accepté chez moi ;)
Ça n'en fait pas quelque chose d'intrinsèquement mauvais mais, selon la durée de vie du code en question, ça peut être un choix globalement rentable ou non: pour schématiser, capex-- vs opex++. L'argument des gens qui râlent contre ce code est qu'un système d'init devrait avoir pour vocation de durer dans le temps, donc avoir un coût de maintenance le plus faible possible (bon y en a aussi qui râlent parce que le code moche c'est Mal(tm), mais c'est un autre problème :)).
En même temps je comprends parfaitement Redhat, et une des spécificités du libre c'est que l'"opex" est mutualisé dans une certaine mesure, ce qui rend l'optimisation de "capex" plus attractive... En gros le point critique est d'être juste assez bon pour convaincre les autres d'adopter, et hop, par magie les coûts de maintenance sont partiellement transférés à des tiers. Finalement c'est un bel exemple de l'économie autour du libre :)
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Yann Hodique (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
Moui, faut nuancer un peu quand même. Redhat est loin d'être parmi les employeurs les plus compétitifs et un rapide coup d'oeil à glassdoor me montre que le gars gagne probablement nettement moins qu'un développeur un poil expérimenté chez Google par exemple.
Je ne dis pas qu'ils ne sont pas bon, loin de là. Au contraire, je pense que le rapport qualité/prix est assez élevé. Il n'en reste pas moins que Redhat fait exactement comme toutes les autres boîtes: recruter les meilleurs parmi ceux qu'ils peuvent s'offrir, ce qui est différent des meilleurs dans l'absolu.
Bref je pense qu'il est assez légitime de dire que tel ou tel bout de code ne serait pas jugé acceptable ailleurs. Et la réponse n'est pas nécessairement que ceux qui l'affirment pourraient aller prétendre au salaire du gars qui a pondu le code, mais aussi parfois qu'ils gagnent déjà bien plus (ou bien assez) ailleurs.
Et puis y a pas que l'argent dans la vie non plus, donc l'argument "si tu peux faire mieux, va te faire payer à sa place" est beaucoup trop simpliste, peu importe la façon dont on aborde le problème.
Au passage, ce bout de code ne serait jamais accepté chez moi ;)
Ça n'en fait pas quelque chose d'intrinsèquement mauvais mais, selon la durée de vie du code en question, ça peut être un choix globalement rentable ou non: pour schématiser, capex-- vs opex++. L'argument des gens qui râlent contre ce code est qu'un système d'init devrait avoir pour vocation de durer dans le temps, donc avoir un coût de maintenance le plus faible possible (bon y en a aussi qui râlent parce que le code moche c'est Mal(tm), mais c'est un autre problème :)).
En même temps je comprends parfaitement Redhat, et une des spécificités du libre c'est que l'"opex" est mutualisé dans une certaine mesure, ce qui rend l'optimisation de "capex" plus attractive... En gros le point critique est d'être juste assez bon pour convaincre les autres d'adopter, et hop, par magie les coûts de maintenance sont partiellement transférés à des tiers. Finalement c'est un bel exemple de l'économie autour du libre :)