Revision [2795]

Last edited on 2012-08-28 23:37:57 by BenoitAudouard
Additions:
Security: http://zesty.ca/pubs/csd-02-1184.pdf User Interaction Design for Secure Systems (PDF, 16 pages)
10:26 < jq> rda: ben ~2500 distrib cpan disponibles, tenues à jour
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
Deletions:
~- 10:26 < jq> rda: ben ~2500 distrib cpan disponibles, tenues à jour
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


Revision [526]

Edited on 2011-03-19 02:04:27 by BenoitAudouard
Additions:
===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
~-


Revision [397]

Edited on 2011-01-05 20:19:32 by BenoitAudouard
Additions:
Well, this page is from __developer__ point on view on two trolls^W^Wmany point of views of a russian-doll troll
===Developers have constrainsts===
~- always better to keep in touch with latest libraries, hey they need testing and bring new functionalities
~- of course, it has to be packaged, so we can provide a working environment (#define environment :p)
~~- libraries are a stable or fixed version
~~- we can't manage fixes we don't know (don't patch!) or we can't support it, too difficult to follow that many distributions you know
~~- we are providing the package that has to be tested, with all included to ease testing (but not integration)
~~- well, we can't package for all that distributions out there, so we are providing our own way to install'! yeah, yet another packaging software!
===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 be sure that all dependencies are available, sufice it to package them in the same jar as the program (hmmm package management provides dependancy support... avoids unnecessary duplication...)
~- just install in one directory to avoid
~- that's how many proprietary software end up deploying more than 300 MB, with all necessary framework included, rather than identifying their dependancies (and related software licenses...)
===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):
~- rpm vs deb
~- choose one, otherwise I write my own way to have dependancies installed
~- furthermore it manages correctly badly-designed OSes that do not come with package management, it avoids to manage multiple packaging systems
~- packaging is too long (yep learn my packaging way, makes it easier...)
~- overlooking that the goal is not packaging but provide integration (and testing)
Deletions:
well, this page is from __developer__ point on view on two trolls^W^Wmany point of views of a russian-doll troll
~~-
~~-
~~-
~~-


Revision [396]

Edited on 2011-01-04 23:55:47 by BenoitAudouard [precision]
Additions:
well, this page is from __developer__ point on view on two trolls^W^Wmany point of views of a russian-doll troll
Just to keep on subject, what many distributions have chosen is :
~- one way to package / install (yep that can be discussed)
~- provide _users_ with a stable base and provide developers (of the distribution) with a _testable_ base (pre-requisite being to be installed, through packages, yep the first line) to ensure identified functionalities & choice of integration with other software
~- this model has many drawbacks, among them (not exhaustive list from a developer point-of-view):
~~- yep, testing bleeding edge without know-how people,
~~- not that up-to-date as not following the VCS,
~~- integrating not stable developments that may be broken or just choosing the wrong version,
~~- choosing to integrate too many software that may not be compatible for obvious reasons in the end,
~~- assuming that people want a stable version meaning "working" or "with latest functionalities"
~~-
~~-
~~-
~~-
Deletions:
well, this page is from developer point on view on two trolls^W^Wmany point of views of a russian-doll troll


Revision [395]

The oldest known version of this page was created on 2011-01-04 23:44:54 by BenoitAudouard [precision]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki