When you start adding features, put me down as a +1 for adding GitHub login.
@thaljef:
The world is a very big place. If you can conquer just a tiny patch of it, you can live quite comfortably. At least, that's what I tell myself every morning. Follow your dream.
Nice one, man. I'm totally adding that to my fortune file. ;->
]]>Under cron (or system startup, or manually running scripted tasks), I typically have a launcher script that I use if I need to set up an environment. The reason is that I want to have an explicit environment when running things as root. As myself, that is an entirely different story, but as root, I want to know exactly what is going on.
--MLX
]]>I install Perl in a number of places, and like the fact that my chosen method for installing Perl and modules works the same on all of them.
That said, why don't you write a separate blog post on "packaging perl for sysadmins" or somesuch. I'd like to read opinions and suggestions from a more seasoned sysadmin on how to approach these sort of things.
]]>http://mail.pm.org/pipermail/melbourne-pm/2007-May/002316.html
I think developers prefer CPAN because they can immediately get things done, sys admins like order and integration of components into their environment that will play nice with their tool chains. Ultimately if you are deploying across multiple platforms flexibility is key, however in a homogenous environment rapid deployment using native tools is preferred. If the aim is a stable production environment (especially one that can be brought up and torn down quickly - think cloud) my vote is for package managers, even if I have to create my own repo and packages.
It's not a holy war for me however,in development mode I may delay creating a package and use CPAN temporarily, although this has the potential to become a rabbit hole quickly if some module is using Moose for example.
Again, not a holy war. Flexibility and pragmatism, and your particular use cases should dictate behavior instead of dogma and stubbornness.
]]>* Read Tweets from your timeline.
* See who you follow.
If that's the case you need a privacy policy since users signing in with this service will expose you to private data in their Twitter accounts that they might not want to share with you.
]]>20:16 mohawk TimToady: if perl5 were to be re-branded as Camel Perl (subject of course to a conversation with Mr O'Reilly), how would you feel about that? 20:16 * TimToady thinks it wouldn't make any substantive difference 20:17 mohawk are you "no strong feelings one way or the other"? 20:17 * TimToady thinks people will still call it perl5 20:17 * TimToady has no strong feelings on the branding of perl5 these days]]>
I am also unclear on your reasoning for the problem. Is it: 1) because you don't like how long the module list is with the extra entries? 2) The submissions of Acme:: and related modules are NOT going into Acme:: like they should.
3) Bandwidth or storage space problem for the administration.
4) They are annoying to look at when looking for "real*" modules.
If it is just the 'noise' of looking at Acme::yourname modules, or the annoyance thereof; then should there not be some sort of filter put in place? (more than what exists today) This would be better than to just annihilate the whole category.
If it is the problem of Acme::yourname:: not being used when it should be, then some new policies may be in order.
If it is the problem of bandwidth, perhaps more mirrors are in order, or stricter checks for duplicate or redundant data. Also checking for data that is not to be uploaded. I realize this is being done to a certain degree already, but there is always more that can be done. I would gladly volunteer my time for such a purpose.
To banish experimentation to some other place when it has been done this way for years is something you can only wish for, it's like wishing for developers to all test their modules correctly, it will never happen. There are deadlines, workloads, and time itself to consider.
To quote Buddy Burden's comment, "In a perfect world, I think I'd love to have one of each" of those.
You are always going to have people that will color outside the lines. I could go on and on but I must cut this short, if you require more information from me, don't hesitate to write me an e-mail message.
* The term, '"real" modules' means something different to each of us. Because of this dynamic, it is not possible to please everyone, all of the time.
]]>