Le fait est que pour une très grande majorité des paquets ça se passe très bien
T'oublies de dire que pour le reste ça se passe tres mal.
Le pb du package manager, c'est que:
1) Des que tu sors des clous, ça devient tres douloureux,
2) Il y aura toujours des cas ou il faudra sortir des clous dans une utilisation professionnelle.
1 + 2 veut dire que je vais perdre du temps. Vu mon salaire, ça va pas plaire a mon boss et il prefere me filer une machine a 2500ドル plutôt que de me voir perdre une demi journée par mois pour résoudre ces problèmes a la con, ça lui coute moins cher.
Les systems a la windows/macos ont l'avantage de marcher de façon beaucoup plus uniforme, tu perds tres peu de temps en permanence.
Les packages maangers te font perdre BEAUCOUP de temps régulièrement.
C'est toujours la meme rengaine:
- Utilise debian!
- Ouais, mais j'ai besoin de firefox, pas firebird
- ben passes en unstable alors.
- ben ouais, mais j'ai pas spécialement envie de faire un apt-get dist upgrade et retrouver ma machine en carafe parce qu'un blaireau a committe un paquet pete
- ben utilise une ubuntu alors
- retour a la case départ il me faut "XXX" et il est pas dispo ou pas dans la bonne version. Et je veux pas prendre le risque de devoir une upgrade majeure tous les 6 mois.
- ben t'as cree ta distrib alors!
- ...
Tu me crois pas? C'est exactement ce qui a été dit dans ce fil.
C'est pas complique, et c'est pas comme si la solution au problème était inconnue. Les utilisateurs veulent:
1) Une base stable (OS + userland de base), costaud et qui change peu souvent. Tous les 2 a 5 ans on va dire
2) Par dessus ça, la possibilité d'avoir n'importe quelle version de n'importe quelle appli, ou plusieurs versions en parallèles. Generalement, ça veut dire "la dernière sortie".
3) Pouvoir mettre a jour une appli sans toucher a tous le reste du système. Quand je met a jour macHG j'ai pas envie de devoir puller au passage python 3.0-dev parce que le packageur a trouve que c'était cool de patcher MachHG avec du 3.0 specific. Et j'ai pas specialemtn envie de me retrouver avec custom build tire d'un nightly snapshot parce que le meme blaireau a trouve cool de prendre une version bleeding edge qu'upstream n'a pas signed off.
Les packages managers pechent le plus souvent sur 2.
La meilleure solution a 2, c'est du rolling release, mais ça fout 1) en l'air du coup.
Et par design du system, le point 3) sera toujours problématique.
On s'en fout de savoir que la solution est techniquement meilleure dans un monde bizarre invente par les geeks. La meilleure solution est celle qui satisfait 1, 2 et 3 a la fois, en faisant le compromis le plus acceptable possible.
C'est ce que Apple et MS font. Encore qu'apple s'amuse parfois a faire de grand changement en cours de route.
Les packages managers ne satisfont rien du tout, ne font aucun compromis et t'expliquent comment te passer de ce dont t'as besoin.
Les rolling release, c'est du continuous delivery appliqué au desktop. C'est un concept que je trove genial pour notre environnement de prod, mais il est hors de question que ça s'approche de ma machine ce truc. Je suis pas un environnement de prod, et j'ai besoin de stabilité.
Disons que je veux une machine de dev pour le taff.
Il me faut un JDK. Dans une version tres particulière.
Il me faut tomcat, dans une version tres particulière.
Il me faut maven, dans une version tres particulière (2.0.11).
Et il me faut une autre version de maven tres particulière (3.0.qqchose, ma mémoire me faut défaut). Oui, on a process de build mongolien ou certains projets se buildent avec 2.0.11 et d'autres avec 3.0
Il me faut aussi eclipse en 3.6 et pas un 3.7 parce que m2eclipse sur 3.7 utilise 3.0 en interne et que ça m'arrange pas.
La raison étant que les environnement de prods et de build utilisent ces versions tres particulière. Il est assez peu probable qu'utiliser tomcat 6.0.24 au lieu de .19 cause un probleme.
Mais ça arrivera un jour. Et ce jour on va en chier pour trouver le problème, ou le simple fait que les gars de la QA aient trouve le problème me fait passer pour un mickey.
De meme avec mvn, je peux dire au gars de l'automation engineering que ça build sur ma box, si ça se banane sur jenkins, ça va leur faire une belle jambe.
’a 99,999% de chance qu’il soit légitime, mais bon pour le plaisir de troller je suppose que tu vas dire que c’est un patch de sale gruik fait à l’arrache (parce que c’est connu que tous les mainteneurs sont des dév. ratés, des engeances du diable qui insèrent des bugs rien que pour le plaisir).
Ben excuses moi, mais le process qualité est loin d'être terrible. Les distros patchent firefox de partout, il se trouve que ça marche la plupart du temps, probablement parce que personne ne l'utilise.
La plupart du temps ça marche. Jusqu'à ce que ça marche plus.
Le kernel? Prend toi ta régression de consommation dans la gueule, elle est a peine résolue, ça fait combien de temps?
Scale ca au volume de windows sur desktop ou iOS, tu vas commencer a en voir des pb arriver. C'est pas spécialement une grande nouvelle que les process QA du libre communautaire sont mauvais en général. Et encore, ça c'est quand ils existent. Quand un patch de sécurité est déployé en qq heures, c'est qu'il a tout simplement PAS été teste DU TOUT.
Et c'est pas un reproche, les communautaires font ce qu'ils peuvent avec leurs moyens, ils font deja tres bien.
Je vais (encore) me repeter, mais l'exemple OpenSSL est assez parlant, non? Une passoire déployée en prod pendant 2 ans, et la faille a été trouvée par pur hasard par un utilisateur qui a remarque qq chose de bizarre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: nombre de distros, finition globale et paquets
Posté par pasScott pasForstall . En réponse au journal On devrait manger ce qu'on donne à notre chien. Évalué à 2.
T'oublies de dire que pour le reste ça se passe tres mal.
Le pb du package manager, c'est que:
1) Des que tu sors des clous, ça devient tres douloureux,
2) Il y aura toujours des cas ou il faudra sortir des clous dans une utilisation professionnelle.
1 + 2 veut dire que je vais perdre du temps. Vu mon salaire, ça va pas plaire a mon boss et il prefere me filer une machine a 2500ドル plutôt que de me voir perdre une demi journée par mois pour résoudre ces problèmes a la con, ça lui coute moins cher.
Les systems a la windows/macos ont l'avantage de marcher de façon beaucoup plus uniforme, tu perds tres peu de temps en permanence.
Les packages maangers te font perdre BEAUCOUP de temps régulièrement.
C'est toujours la meme rengaine:
- Utilise debian!
- Ouais, mais j'ai besoin de firefox, pas firebird
- ben passes en unstable alors.
- ben ouais, mais j'ai pas spécialement envie de faire un apt-get dist upgrade et retrouver ma machine en carafe parce qu'un blaireau a committe un paquet pete
- ben utilise une ubuntu alors
- retour a la case départ il me faut "XXX" et il est pas dispo ou pas dans la bonne version. Et je veux pas prendre le risque de devoir une upgrade majeure tous les 6 mois.
- ben t'as cree ta distrib alors!
- ...
Tu me crois pas? C'est exactement ce qui a été dit dans ce fil.
C'est pas complique, et c'est pas comme si la solution au problème était inconnue. Les utilisateurs veulent:
1) Une base stable (OS + userland de base), costaud et qui change peu souvent. Tous les 2 a 5 ans on va dire
2) Par dessus ça, la possibilité d'avoir n'importe quelle version de n'importe quelle appli, ou plusieurs versions en parallèles. Generalement, ça veut dire "la dernière sortie".
3) Pouvoir mettre a jour une appli sans toucher a tous le reste du système. Quand je met a jour macHG j'ai pas envie de devoir puller au passage python 3.0-dev parce que le packageur a trouve que c'était cool de patcher MachHG avec du 3.0 specific. Et j'ai pas specialemtn envie de me retrouver avec custom build tire d'un nightly snapshot parce que le meme blaireau a trouve cool de prendre une version bleeding edge qu'upstream n'a pas signed off.
Les packages managers pechent le plus souvent sur 2.
La meilleure solution a 2, c'est du rolling release, mais ça fout 1) en l'air du coup.
Et par design du system, le point 3) sera toujours problématique.
On s'en fout de savoir que la solution est techniquement meilleure dans un monde bizarre invente par les geeks. La meilleure solution est celle qui satisfait 1, 2 et 3 a la fois, en faisant le compromis le plus acceptable possible.
C'est ce que Apple et MS font. Encore qu'apple s'amuse parfois a faire de grand changement en cours de route.
Les packages managers ne satisfont rien du tout, ne font aucun compromis et t'expliquent comment te passer de ce dont t'as besoin.
Les rolling release, c'est du continuous delivery appliqué au desktop. C'est un concept que je trove genial pour notre environnement de prod, mais il est hors de question que ça s'approche de ma machine ce truc. Je suis pas un environnement de prod, et j'ai besoin de stabilité.
Disons que je veux une machine de dev pour le taff.
Il me faut un JDK. Dans une version tres particulière.
Il me faut tomcat, dans une version tres particulière.
Il me faut maven, dans une version tres particulière (2.0.11).
Et il me faut une autre version de maven tres particulière (3.0.qqchose, ma mémoire me faut défaut). Oui, on a process de build mongolien ou certains projets se buildent avec 2.0.11 et d'autres avec 3.0
Il me faut aussi eclipse en 3.6 et pas un 3.7 parce que m2eclipse sur 3.7 utilise 3.0 en interne et que ça m'arrange pas.
La raison étant que les environnement de prods et de build utilisent ces versions tres particulière. Il est assez peu probable qu'utiliser tomcat 6.0.24 au lieu de .19 cause un probleme.
Mais ça arrivera un jour. Et ce jour on va en chier pour trouver le problème, ou le simple fait que les gars de la QA aient trouve le problème me fait passer pour un mickey.
De meme avec mvn, je peux dire au gars de l'automation engineering que ça build sur ma box, si ça se banane sur jenkins, ça va leur faire une belle jambe.
Ben excuses moi, mais le process qualité est loin d'être terrible. Les distros patchent firefox de partout, il se trouve que ça marche la plupart du temps, probablement parce que personne ne l'utilise.
La plupart du temps ça marche. Jusqu'à ce que ça marche plus.
Le kernel? Prend toi ta régression de consommation dans la gueule, elle est a peine résolue, ça fait combien de temps?
Scale ca au volume de windows sur desktop ou iOS, tu vas commencer a en voir des pb arriver. C'est pas spécialement une grande nouvelle que les process QA du libre communautaire sont mauvais en général. Et encore, ça c'est quand ils existent. Quand un patch de sécurité est déployé en qq heures, c'est qu'il a tout simplement PAS été teste DU TOUT.
Et c'est pas un reproche, les communautaires font ce qu'ils peuvent avec leurs moyens, ils font deja tres bien.
Je vais (encore) me repeter, mais l'exemple OpenSSL est assez parlant, non? Une passoire déployée en prod pendant 2 ans, et la faille a été trouvée par pur hasard par un utilisateur qui a remarque qq chose de bizarre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.