Well, this page is from developer point on view on two trolls^W^Wmany point of views of a russian-doll troll


GNU/Linux distribution is about packaging and testing for the users

well, you already know what you are going to read:
Just to keep on subject, what many distributions have chosen is :

Developers have constrainsts


Some examples why it doesn't work

Well, let's begin with java developers who have pushed illogicality so far to succeed in industrializing it o_O

To make a long story short

But to be developed for the sake of precision (yep I'm biased too and may have overlooked things):
Security: http://zesty.ca/pubs/csd-02-1184.pdf User Interaction Design for Secure Systems (PDF, 16 pages)

perl packaging

well CPAN, why packaging it further ?
10:26 < jq> rda: ben ~2500 distrib cpan disponibles, tenues à jour
10:26 < rda> ennael: :)
10:27 < jq> rda: à comparer avec http://szabgab.com/distributions/
10:27 < erzulie> [ CPAN Modules in Distributions ]
10:27 < jq> (bon, ceci dit, la page date de 2007)
10:27 < rda> jq: ah oué.
10:28 < jq> note que cpan compte ~22250 dists actuellement
10:29 < rda> va falloir préparer la question "mais pourquoi repackager au dessus des outils de packages par language/techno ?" :)
10:30 < jq> plusieurs raisons :
10:30 < jq> - c'est + propre (plus de fichiers de vieilles versions qui trainent)
10:30 < jq> - c'est + facile : on le fait à ta place
10:31 < jq> - c'est + intégré : on se link avec les libs de la distrib
10:31 < jq> par contre, et là j'espère être très clair : je ne recommande pas d'utiliser le perl system pour des applis en prod
10:32 < rda> c'est à dire ?
10:32 < jq> ben si tu as une appli prod, je conseille de recompiler ton perl et les moduels que tu veux
10:32 < jq> comme ça, tu n'es pas dépendant du cycle d'upgrades
10:33 < jq> enfin, tu peux utiliser le perl system, mais à condition d'être au courant qu'une mise à jour va ... mettre à jour ton
environnement de prod
10:33 < rda> voilà.
10:33 < jq> voilà. :-)
10:33 < rda> du point de vue du dev/mainteneur de l'appli, vaut mieux recompiler et se découpler du système.
10:34 < jq> oui
10:34 < jq> surtout avec des releases tous les 6 mois

10:34 < rda> est-ce qu'on a des outils qui facilitent ça ? ou c'est juste trivial ?
10:34 < jq> qui facilitent quoi ?
10:35 < jq> la maj des packages perl ?
10:35 < rda> la fabrication d'un bundle pour une appli de prod.
10:36 < jq> euh non, mis à part freezer les packages perl
10:36 < jq> on peut fabriquer facilement un package rpm d'une dist cpan avec cpan2dist
10:37 < jq> mais je ne pense pas que ce soit ce dont tu parles
10:37 < rda> tu dis qu'il vaut mieux recompiler perl et les modules qu'on utilise, pour découpler une appli de prod de la plateforme en
dessous.
10:38 < jq> oui
10:38 < rda> il faut repartir de la source ou il y a justement moyen de prendre une photo de l'état du système (perl, modules) sur lequel
l'appli est développée ?
10:38 < jq> euh, il faut repartir de la source
10:39 < Nanar> 10:34:21 < jq> surtout avec des releases tous les 6 mois
10:39 < rda> ok. mais alors (je me fais l'avocat d'une partie puis de l'autre), qu'est-ce qu'on répond à un sysadmin qui préfèrent évidemment
garder toute la pile de packages de la distrib ?
10:39 < rda> (plutôt que d'avoir un truc à part)
10:39 < Nanar> on réinstalle pas les machines de prod tout les 6 mois non plus
10:40 < Nanar> en tant que sys admin, avoir un perl à coté c'est géré les maj de sécu moi même
10:41 < pterjan> t'as pas une equipe secu pour ca ? /o\
10:41 < rda> Nanar: ou au dev de le faire (ou au couple dev/admin)
10:42 < rda> ça dépend du contexte et du besoin en fait
10:42 < pterjan> le dev est pas toujours marié avec l'admin
10:42 < jq> après, c'est vrai que les machines de prod seront sur un upgrade plus lent (3 ans en moyenne) = => on peut utiliser le perl system
10:43 < Nanar> le dev n'a pas de compte à rendre coté sécurité (moins)
10:43 < jq> *cough*
10:43 < rda> pterjan: nan mais y a des boîtes qui font comme si.
10:44 < rda> Nanar: ça dépend du contexte encore et du découpage des rôles (et de qui se fait taper quand il y a un trou de sécu).
10:46 < rda> ça peut être l'occas d'effleurer le sujet.
10:46 < rda> Nanar: tu voudrais participer/intervenir ? (c'est le 15/16 avril)
10:46 < rda> faut faire un tour avec ruby, java, php et python aussi
10:47 < Nanar> c'est dans le domaine du possible
11:05 -!- rda [~romain@af83-2.dd.bearstech.net] has quit [Ping timeout: 250 seconds]
11:07 -!- Sat_job [~Kaoru@2a01:e35:8b7c:d0b0:21d:fff:febd:f21b] has joined #mageia-fr
11:11 < stormi> Bonjour
11:14 -!- rda [~romain@af83-1.dd.bearstech.net] has joined #mageia-fr
11:22 -!- coincoin [~dams@af83-2.dd.bearstech.net] has joined #mageia-fr
11:35 < misc> jq: faut arreter, j'ai des machines en prod avec des softs entirement en perl ( un serveur irc, un serveur jabber, un mud ) et
j'ai mis à jour tout les 6 mois sans que ça pete, perl est relativement stable et correct
11:37 < misc> gerer les modules à part, c'est bien souvent surveillé sa petit moitié de CPAN et faire le taf de sécu soit même, et si c'etait
pas soualant, on aurais des centaines de volontaires pour faire le taf
11:37 < misc> sauf que c'est soulant
11:42 < jq> misc: je parle d'applis de prod qui sont le coeur de métier d'une boîte
11:43 < jq> avec des $$$ à la clef
11:45 < misc> jq: bah dans ce cas, tu paye pour avoir un systéme qui bouge pas :)
11:46 < jq> voilà :-)
11:46 < misc> et faut être clair que faire ça, ça a un cout
11:46 < jq> oui
11:47 < misc> l'interet d'une distro linux, c'est bien la mutualisation, foutre son truc à coté, ça reviens à faire comme sous windows
11:47 < jq> on est d'accord - c'est bien pour ça que je suis devenu maintainer
11:48 -!- Sat_job [~Kaoru@2a01:e35:8b7c:d0b0:21d:fff:febd:f21b] has quit [Ping timeout: 248 seconds]
11:50 -!- mortalius_ [~mortalius@AAmiens-155-1-36-183.w92-142.abo.wanadoo.fr] has joined #mageia-fr
11:52 -!- mortalius [~mortalius@AAmiens-155-1-41-250.w92-142.abo.wanadoo.fr] has quit [Ping timeout: 246 seconds]
11:58 < misc> tiens, http://en.opensuse.org/openSUSE:Build_Service_application_blacklist , chromium est dans la blacklist d'opensuse
11:58 < erzulie> [ openSUSE:Build Service application blacklist - openSUSE ]
12:00 < mikala> misc: tu votes pour la mise en place d'une telle blacklist sur mageia ? ;o)
12:01 < misc> mikala: non mais ça serait peut être intéressant d'harmoniser les listes
12:02 < misc> enfin un truc important, c'est de savoir pourquoi chaque chose n'est pas dans core



There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki