<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_24_0319228</id>
	<title>Helping Perl Packagers Package Perl</title>
	<author>samzenpus</author>
	<datestamp>1261677960000</datestamp>
	<htmltext><a href="mailto:jamie@slashdot.org" rel="nofollow">jamie</a> writes <i>"chromatic has a great post today on the conflict between <a href="http://www.modernperlbooks.com/mt/2009/12/helping-perl-packagers-package-perl.html">OS distributions and CPAN's installations of perl modules</a>, along with some suggestions for how to start resolving this maddening problem: '[Though Debian has] made plenty of CPAN distributions available as .debs, I have to configure my CPAN client myself, and it does not work with the system package manager. There's no reason it couldn't. Imagine that the system Perl 5 included in the default package... had a CPAN client configured appropriately. It has selected an appropriate mirror (or uses the redirector). It knows about installation paths. It understands how to use LWP...' The idea of providing guidelines to distros for how to safely package modules is a great one. Could modules request (a modified?) test suite be run after distro-installation? Could Module::Build help module authors and distro maintainers establish the rules somehow?"</i></htmltext>
<tokenext>jamie writes " chromatic has a great post today on the conflict between OS distributions and CPAN 's installations of perl modules , along with some suggestions for how to start resolving this maddening problem : ' [ Though Debian has ] made plenty of CPAN distributions available as .debs , I have to configure my CPAN client myself , and it does not work with the system package manager .
There 's no reason it could n't .
Imagine that the system Perl 5 included in the default package... had a CPAN client configured appropriately .
It has selected an appropriate mirror ( or uses the redirector ) .
It knows about installation paths .
It understands how to use LWP... ' The idea of providing guidelines to distros for how to safely package modules is a great one .
Could modules request ( a modified ?
) test suite be run after distro-installation ?
Could Module : : Build help module authors and distro maintainers establish the rules somehow ?
"</tokentext>
<sentencetext>jamie writes "chromatic has a great post today on the conflict between OS distributions and CPAN's installations of perl modules, along with some suggestions for how to start resolving this maddening problem: '[Though Debian has] made plenty of CPAN distributions available as .debs, I have to configure my CPAN client myself, and it does not work with the system package manager.
There's no reason it couldn't.
Imagine that the system Perl 5 included in the default package... had a CPAN client configured appropriately.
It has selected an appropriate mirror (or uses the redirector).
It knows about installation paths.
It understands how to use LWP...' The idea of providing guidelines to distros for how to safely package modules is a great one.
Could modules request (a modified?
) test suite be run after distro-installation?
Could Module::Build help module authors and distro maintainers establish the rules somehow?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543368</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>maxume</author>
	<datestamp>1261665060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Successful coordination would mean always waiting for the last third party release, so the policy of not worrying about what third party folks are up to isn't really that bad.</p></htmltext>
<tokenext>Successful coordination would mean always waiting for the last third party release , so the policy of not worrying about what third party folks are up to is n't really that bad .</tokentext>
<sentencetext>Successful coordination would mean always waiting for the last third party release, so the policy of not worrying about what third party folks are up to isn't really that bad.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542764</id>
	<title>Not just Perl</title>
	<author>Dorsai65</author>
	<datestamp>1261652040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>This isn't just a Perl problem; there are several packages that I know of that different distros have problems with.</p><p>I think it's more the nature of F/OSS: anybody that <strong>can</strong> repackage things, will -- just like anyone that wants to, can cobble together their own distro.</p><p>I don't see the problem going away for Perl, or any other package -- or even for the various distributions. As long as there are True Believers in<nobr> <wbr></nobr>.deb vs<nobr> <wbr></nobr>.rpm vs. git,<nobr> <wbr></nobr>/usr vs<nobr> <wbr></nobr>/opt, Gnome vs KDE, and so on, I see it continuing to be a problem. Nobody wants to give up a little bit of <em>their</em> "freedom" to do-as-they-damn-well-please in order to establish some consistency and minimum standards so as to make life easier for mere users. <a href="http://slashdot.org/journal/209879/Linux-vs-Linux-vs-Linux-vs-" title="slashdot.org">I've previously suggested</a> [slashdot.org] that the fragmentation of Linux (of which this particular situation is just an example) is what's REALLY keeping Linux off more desktops.</p><p>But, hey, what do I know? I'm just one of those folks that only wants to get actual productive work done, and remembers what it was like for me when I made the switch from Windows(tm) to Linux.</p></htmltext>
<tokenext>This is n't just a Perl problem ; there are several packages that I know of that different distros have problems with.I think it 's more the nature of F/OSS : anybody that can repackage things , will -- just like anyone that wants to , can cobble together their own distro.I do n't see the problem going away for Perl , or any other package -- or even for the various distributions .
As long as there are True Believers in .deb vs .rpm vs. git , /usr vs /opt , Gnome vs KDE , and so on , I see it continuing to be a problem .
Nobody wants to give up a little bit of their " freedom " to do-as-they-damn-well-please in order to establish some consistency and minimum standards so as to make life easier for mere users .
I 've previously suggested [ slashdot.org ] that the fragmentation of Linux ( of which this particular situation is just an example ) is what 's REALLY keeping Linux off more desktops.But , hey , what do I know ?
I 'm just one of those folks that only wants to get actual productive work done , and remembers what it was like for me when I made the switch from Windows ( tm ) to Linux .</tokentext>
<sentencetext>This isn't just a Perl problem; there are several packages that I know of that different distros have problems with.I think it's more the nature of F/OSS: anybody that can repackage things, will -- just like anyone that wants to, can cobble together their own distro.I don't see the problem going away for Perl, or any other package -- or even for the various distributions.
As long as there are True Believers in .deb vs .rpm vs. git, /usr vs /opt, Gnome vs KDE, and so on, I see it continuing to be a problem.
Nobody wants to give up a little bit of their "freedom" to do-as-they-damn-well-please in order to establish some consistency and minimum standards so as to make life easier for mere users.
I've previously suggested [slashdot.org] that the fragmentation of Linux (of which this particular situation is just an example) is what's REALLY keeping Linux off more desktops.But, hey, what do I know?
I'm just one of those folks that only wants to get actual productive work done, and remembers what it was like for me when I made the switch from Windows(tm) to Linux.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542478</id>
	<title>why attack python?</title>
	<author>timmarhy</author>
	<datestamp>1261688100000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>it seems the first response on here is to attack python - no wonder you can't solve anything, you spend so much time trying to deflect attention away from what are obvious failings.</htmltext>
<tokenext>it seems the first response on here is to attack python - no wonder you ca n't solve anything , you spend so much time trying to deflect attention away from what are obvious failings .</tokentext>
<sentencetext>it seems the first response on here is to attack python - no wonder you can't solve anything, you spend so much time trying to deflect attention away from what are obvious failings.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543336</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>Pjotr</author>
	<datestamp>1261664700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Another option is using a package system that properly handles dependencies. <a href="http://www.nixos.org/" title="nixos.org" rel="nofollow">http://www.nixos.org/</a> [nixos.org], for example, allows multiple Perl versions, multiple CPAN trees - and even within CPAN different module dependencies. That makes for predictable deployment, and can help development too when testing diffferent CPAN dependencies. Interestingly Nix can be used inside Debian. I have it on all my systems to test different setups. Way to go Nix! There is also an article on linux.com.</p></htmltext>
<tokenext>Another option is using a package system that properly handles dependencies .
http : //www.nixos.org/ [ nixos.org ] , for example , allows multiple Perl versions , multiple CPAN trees - and even within CPAN different module dependencies .
That makes for predictable deployment , and can help development too when testing diffferent CPAN dependencies .
Interestingly Nix can be used inside Debian .
I have it on all my systems to test different setups .
Way to go Nix !
There is also an article on linux.com .</tokentext>
<sentencetext>Another option is using a package system that properly handles dependencies.
http://www.nixos.org/ [nixos.org], for example, allows multiple Perl versions, multiple CPAN trees - and even within CPAN different module dependencies.
That makes for predictable deployment, and can help development too when testing diffferent CPAN dependencies.
Interestingly Nix can be used inside Debian.
I have it on all my systems to test different setups.
Way to go Nix!
There is also an article on linux.com.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30556402</id>
	<title>Re:CPAN was both why I started using perl and stop</title>
	<author>Anonymous</author>
	<datestamp>1261848780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>See post above, which I wholeheartedly second:</p><p>"Bit me on Ubuntu 8.04. Which is still the most recent LTS release, and readily available at VPS providers like Slicehost and Linode."</p></htmltext>
<tokenext>See post above , which I wholeheartedly second : " Bit me on Ubuntu 8.04 .
Which is still the most recent LTS release , and readily available at VPS providers like Slicehost and Linode .
"</tokentext>
<sentencetext>See post above, which I wholeheartedly second:"Bit me on Ubuntu 8.04.
Which is still the most recent LTS release, and readily available at VPS providers like Slicehost and Linode.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545322</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542258</id>
	<title>CPAN was both why I started using perl and stopped</title>
	<author>Fished</author>
	<datestamp>1259783160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>The problem is module dependencies... any non-trivial module now has so many dependencies now that it is almost inevitable one will fail to install.  And than you're kind of screwed (unless you go and build it b hand.)  And then there's the insanity of auto-updating perl itself to get a module.  CPAN's badly broken and needs to be replaced entirely, which is a lot of why I pretty much quit using perl for a long time.  Recently, my job changed and I got a lot of perl code.  Man, I miss Ruby now.</htmltext>
<tokenext>The problem is module dependencies... any non-trivial module now has so many dependencies now that it is almost inevitable one will fail to install .
And than you 're kind of screwed ( unless you go and build it b hand .
) And then there 's the insanity of auto-updating perl itself to get a module .
CPAN 's badly broken and needs to be replaced entirely , which is a lot of why I pretty much quit using perl for a long time .
Recently , my job changed and I got a lot of perl code .
Man , I miss Ruby now .</tokentext>
<sentencetext>The problem is module dependencies... any non-trivial module now has so many dependencies now that it is almost inevitable one will fail to install.
And than you're kind of screwed (unless you go and build it b hand.
)  And then there's the insanity of auto-updating perl itself to get a module.
CPAN's badly broken and needs to be replaced entirely, which is a lot of why I pretty much quit using perl for a long time.
Recently, my job changed and I got a lot of perl code.
Man, I miss Ruby now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545322</id>
	<title>Re:CPAN was both why I started using perl and stop</title>
	<author>acid06</author>
	<datestamp>1261679460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Please stop spreading FUD around. This bug (Perl updating itself through CPAN) has been fixed for several years.<br>At least once a month I need to setup a new Perl install with all the dependency-heavy modules and I have no issues whatsoever - if it's failing for you, you're clearly doing something wrong.<br>Have you considered asking for help instead of spreading FUD on Slashdot?</p></htmltext>
<tokenext>Please stop spreading FUD around .
This bug ( Perl updating itself through CPAN ) has been fixed for several years.At least once a month I need to setup a new Perl install with all the dependency-heavy modules and I have no issues whatsoever - if it 's failing for you , you 're clearly doing something wrong.Have you considered asking for help instead of spreading FUD on Slashdot ?</tokentext>
<sentencetext>Please stop spreading FUD around.
This bug (Perl updating itself through CPAN) has been fixed for several years.At least once a month I need to setup a new Perl install with all the dependency-heavy modules and I have no issues whatsoever - if it's failing for you, you're clearly doing something wrong.Have you considered asking for help instead of spreading FUD on Slashdot?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543124</id>
	<title>Bug Report Time?</title>
	<author>hAckz0r</author>
	<datestamp>1261660560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Seriously, if Debian is 'breaking functionality' that makes part of their own distribution unusable, wouldn't it makes sense to file a bug report directly with Debian? While you are at it take all the Perl package maintainers and have them help elevate the priority of that bug report so they can't just ignore it. Having it officially declared a bug would be a logical first step.</htmltext>
<tokenext>Seriously , if Debian is 'breaking functionality ' that makes part of their own distribution unusable , would n't it makes sense to file a bug report directly with Debian ?
While you are at it take all the Perl package maintainers and have them help elevate the priority of that bug report so they ca n't just ignore it .
Having it officially declared a bug would be a logical first step .</tokentext>
<sentencetext>Seriously, if Debian is 'breaking functionality' that makes part of their own distribution unusable, wouldn't it makes sense to file a bug report directly with Debian?
While you are at it take all the Perl package maintainers and have them help elevate the priority of that bug report so they can't just ignore it.
Having it officially declared a bug would be a logical first step.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542292</id>
	<title>Ah, the age old question</title>
	<author>gringer</author>
	<datestamp>1259783580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How much Perl should a Perl Packager package, if a Perl Packager could Package Perl?</p></htmltext>
<tokenext>How much Perl should a Perl Packager package , if a Perl Packager could Package Perl ?</tokentext>
<sentencetext>How much Perl should a Perl Packager package, if a Perl Packager could Package Perl?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542582</id>
	<title>Responding as a CPAN admin...</title>
	<author>adamkennedy</author>
	<datestamp>1261647780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Is the parent a bad post, or a good troll?</p><p>Some responses if I may...</p><p>Perl dependencies are specified by class name, not by distribution package name. So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.</p><p>As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.</p><p>1.2437 is a normalised version of 1.243.7. Downstream distos have implementations of this logic available to them in places like CPAN::Version. But yes, it is a bit weird for the newcomer. It's the price of 5-10 year back-compatibility, alas.</p><p>As for Perl 5.10, almost nothing on the CPAN will depend on it. The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).</p><p>So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.</p></htmltext>
<tokenext>Is the parent a bad post , or a good troll ? Some responses if I may...Perl dependencies are specified by class name , not by distribution package name .
So ( theoretically ) as long as there 's a way to resolve a class to a file ( which is standard ) and thence to an operating system package ( " which package contains file X " should n't be that hard ) then there 's no reason that Perl package dependencies ca n't be mapped down into distro package space.As for the versions , 1.30 is more correctly more recent than 1.2437 , because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.1.2437 is a normalised version of 1.243.7 .
Downstream distos have implementations of this logic available to them in places like CPAN : : Version .
But yes , it is a bit weird for the newcomer .
It 's the price of 5-10 year back-compatibility , alas.As for Perl 5.10 , almost nothing on the CPAN will depend on it .
The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility , or Perl 5.8.5ish ( around 5 years ) for regular things ( which is the first version where Unicode became bug free and universally usable ) .So Perl 5.10 is having almost no impact on compatibility , and wo n't for at least another couple of years .</tokentext>
<sentencetext>Is the parent a bad post, or a good troll?Some responses if I may...Perl dependencies are specified by class name, not by distribution package name.
So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.1.2437 is a normalised version of 1.243.7.
Downstream distos have implementations of this logic available to them in places like CPAN::Version.
But yes, it is a bit weird for the newcomer.
It's the price of 5-10 year back-compatibility, alas.As for Perl 5.10, almost nothing on the CPAN will depend on it.
The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542176</id>
	<title>Re:May I Be the First To Say This</title>
	<author>sneilan</author>
	<datestamp>1259781660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well, my next trick was actually going to be all about how I like vi.<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Well , my next trick was actually going to be all about how I like vi .
: )</tokentext>
<sentencetext>Well, my next trick was actually going to be all about how I like vi.
:)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543114</id>
	<title>Re:And what other languages too?</title>
	<author>buchner.johannes</author>
	<datestamp>1261660440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>You are thinking too small. Any package that has submodules/extensions has the same problem. Such software typically created and uses their own extension system.<br>Some examples: Firefox extensions, Apache+PHP applications (wordpress), emacs, claws mail extension<nobr> <wbr></nobr>... Virtually any package that can act as a platform. Just take a look in your package manager.</p><p>The current idea is to push everything into the repo too. Good because it is reviewed and checked twice; bad as it is incomplete and inconsistent (half is over the package manager, half over another tool [e.g. cpan]).</p><p>One solution would be to make the package manager pluggable, so it can install subpackages sanely, and can access the repo of the other party.</p></htmltext>
<tokenext>You are thinking too small .
Any package that has submodules/extensions has the same problem .
Such software typically created and uses their own extension system.Some examples : Firefox extensions , Apache + PHP applications ( wordpress ) , emacs , claws mail extension ... Virtually any package that can act as a platform .
Just take a look in your package manager.The current idea is to push everything into the repo too .
Good because it is reviewed and checked twice ; bad as it is incomplete and inconsistent ( half is over the package manager , half over another tool [ e.g .
cpan ] ) .One solution would be to make the package manager pluggable , so it can install subpackages sanely , and can access the repo of the other party .</tokentext>
<sentencetext>You are thinking too small.
Any package that has submodules/extensions has the same problem.
Such software typically created and uses their own extension system.Some examples: Firefox extensions, Apache+PHP applications (wordpress), emacs, claws mail extension ... Virtually any package that can act as a platform.
Just take a look in your package manager.The current idea is to push everything into the repo too.
Good because it is reviewed and checked twice; bad as it is incomplete and inconsistent (half is over the package manager, half over another tool [e.g.
cpan]).One solution would be to make the package manager pluggable, so it can install subpackages sanely, and can access the repo of the other party.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544458</id>
	<title>Re:Debian solution ...</title>
	<author>Randle\_Revar</author>
	<datestamp>1261674120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I am not 100\% sure, but I think modern (dh 7.x) dh-make-perl will auto-answer a lot/all of the CPAN questions if you run it before you run plain CPAN</p></htmltext>
<tokenext>I am not 100 \ % sure , but I think modern ( dh 7.x ) dh-make-perl will auto-answer a lot/all of the CPAN questions if you run it before you run plain CPAN</tokentext>
<sentencetext>I am not 100\% sure, but I think modern (dh 7.x) dh-make-perl will auto-answer a lot/all of the CPAN questions if you run it before you run plain CPAN</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542448</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>placatedmayhem</author>
	<datestamp>1261687620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>RHEL5, released March 14, 2007, uses Python 2.4.3, which was released March 29, 2006.  Given a reasonable package-freeze/testing/bugfix cycle, using this version seems about right.  Also, Python 2.5.0 was released September 19, 2006 -- I know I wouldn't want to make a potentially major jump for all my system tools before publishing a major distro release.

</p><p>Perhaps you should rethink the presentation of your point next time -- given what you've said already concerning RHEL5 and Python2.4, you should also be saying "RHEL5 uses Linux 2.6!  That was released back in 2003!!!! ZOMG!!!"

</p><p>In re: Python 3 migration, moving to the Python 3 series presents FAR bigger issues than addon-distribution, namely the changing and/or removal of some particularly widely-used items from Python 2.

</p><p>I will agree with you that distribution of third-party modules can be annoying in Python, but that's not necessarily the Python developers' problem.  Why should they be implicitly responsible for something that is third-party?  Just because another platform is doing it?  C'mon, that's a flimsy argument at best.</p></htmltext>
<tokenext>RHEL5 , released March 14 , 2007 , uses Python 2.4.3 , which was released March 29 , 2006 .
Given a reasonable package-freeze/testing/bugfix cycle , using this version seems about right .
Also , Python 2.5.0 was released September 19 , 2006 -- I know I would n't want to make a potentially major jump for all my system tools before publishing a major distro release .
Perhaps you should rethink the presentation of your point next time -- given what you 've said already concerning RHEL5 and Python2.4 , you should also be saying " RHEL5 uses Linux 2.6 !
That was released back in 2003 ! ! ! !
ZOMG ! ! ! " In re : Python 3 migration , moving to the Python 3 series presents FAR bigger issues than addon-distribution , namely the changing and/or removal of some particularly widely-used items from Python 2 .
I will agree with you that distribution of third-party modules can be annoying in Python , but that 's not necessarily the Python developers ' problem .
Why should they be implicitly responsible for something that is third-party ?
Just because another platform is doing it ?
C'mon , that 's a flimsy argument at best .</tokentext>
<sentencetext>RHEL5, released March 14, 2007, uses Python 2.4.3, which was released March 29, 2006.
Given a reasonable package-freeze/testing/bugfix cycle, using this version seems about right.
Also, Python 2.5.0 was released September 19, 2006 -- I know I wouldn't want to make a potentially major jump for all my system tools before publishing a major distro release.
Perhaps you should rethink the presentation of your point next time -- given what you've said already concerning RHEL5 and Python2.4, you should also be saying "RHEL5 uses Linux 2.6!
That was released back in 2003!!!!
ZOMG!!!"

In re: Python 3 migration, moving to the Python 3 series presents FAR bigger issues than addon-distribution, namely the changing and/or removal of some particularly widely-used items from Python 2.
I will agree with you that distribution of third-party modules can be annoying in Python, but that's not necessarily the Python developers' problem.
Why should they be implicitly responsible for something that is third-party?
Just because another platform is doing it?
C'mon, that's a flimsy argument at best.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166</id>
	<title>Better fix it somehow</title>
	<author>Anonymous</author>
	<datestamp>1259781540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform...</p></htmltext>
<tokenext>A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform.. .</tokentext>
<sentencetext>A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542266</id>
	<title>Really, who has time for pathetic Linux pkgmgrs?</title>
	<author>Anonymous</author>
	<datestamp>1259783220000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Perl has had one of the best package management systems of any language or operating system for nearly as long as Linux has even been around.  In stark contrast every Linux package manager has been little more then a sad and pathetic joke.</p><p>The Linux mob is the one that needs to sort their shit out, but it'll never happen, it's not in their nature.  It's not hard at all to link CPAN with another good package manager (for example, FreeBSD has done a fine job of this).  Getting it to work with the jokes that are rpms, debs, etc however...good luck.  And don't expect the Perl side to help much until the Linux side finally builds or adopts a package manager that doesn't suck complete balls.</p></htmltext>
<tokenext>Perl has had one of the best package management systems of any language or operating system for nearly as long as Linux has even been around .
In stark contrast every Linux package manager has been little more then a sad and pathetic joke.The Linux mob is the one that needs to sort their shit out , but it 'll never happen , it 's not in their nature .
It 's not hard at all to link CPAN with another good package manager ( for example , FreeBSD has done a fine job of this ) .
Getting it to work with the jokes that are rpms , debs , etc however...good luck .
And do n't expect the Perl side to help much until the Linux side finally builds or adopts a package manager that does n't suck complete balls .</tokentext>
<sentencetext>Perl has had one of the best package management systems of any language or operating system for nearly as long as Linux has even been around.
In stark contrast every Linux package manager has been little more then a sad and pathetic joke.The Linux mob is the one that needs to sort their shit out, but it'll never happen, it's not in their nature.
It's not hard at all to link CPAN with another good package manager (for example, FreeBSD has done a fine job of this).
Getting it to work with the jokes that are rpms, debs, etc however...good luck.
And don't expect the Perl side to help much until the Linux side finally builds or adopts a package manager that doesn't suck complete balls.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542916</id>
	<title>Same problem with RubyGems as well</title>
	<author>mcnazar</author>
	<datestamp>1261656000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I recall the same issue with the Ubuntu and the Ruby community over RubyGems.</p><p>Ubuntu packagers would have preferred the use of APT instead of RubyGems for Gem installations, despite the fact that APT's lagged behind RubyGems.</p></htmltext>
<tokenext>I recall the same issue with the Ubuntu and the Ruby community over RubyGems.Ubuntu packagers would have preferred the use of APT instead of RubyGems for Gem installations , despite the fact that APT 's lagged behind RubyGems .</tokentext>
<sentencetext>I recall the same issue with the Ubuntu and the Ruby community over RubyGems.Ubuntu packagers would have preferred the use of APT instead of RubyGems for Gem installations, despite the fact that APT's lagged behind RubyGems.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544574</id>
	<title>Re:May I Be the First To Say This</title>
	<author>Randle\_Revar</author>
	<datestamp>1261674900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I am beginning to think emacs is, in fact, greater than vim (emacs is obviously &gt; vi). But emacs key bindings are still far behind vim's</p></htmltext>
<tokenext>I am beginning to think emacs is , in fact , greater than vim ( emacs is obviously &gt; vi ) .
But emacs key bindings are still far behind vim 's</tokentext>
<sentencetext>I am beginning to think emacs is, in fact, greater than vim (emacs is obviously &gt; vi).
But emacs key bindings are still far behind vim's</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542256</id>
	<title>common lisp sort of does this</title>
	<author>Trepidity</author>
	<datestamp>1259783100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.cliki.net/common-lisp-controller" title="cliki.net">common-lisp-controller</a> [cliki.net] is an attempt to make Common Lisp package management play nicely with Debian package management, so, for example, trying to load a package within ASDF (Lisp) finds the appropriate Debian package if it's installed (like the linked article discusses doing for CPAN).</p><p>Strongly package-manager-based distributions like Debian usually don't put a lot of effort into making stuff outside the distribution work well, though. If you want some C library that isn't in Debian, you're going to have to build it yourself and stick it somewhere, and all the stuff in Debian isn't going to know about it. Similarly, if you want some CPAN module that isn't packaged in Debian (the Perl equivalent of a third-party shared library that isn't packaged in Debian), you're going to have to muck with it yourself, and it won't be in the usual dependency chain.</p><p>The usual Debian answer to these sorts of problems is: well, if it's maintained, useful, and under a DSFG license, let's just package it! Things get much less nice if the user is installing a bunch of custom stuff, and especially trying to get locally installed and package-managed stuff to play together nicely. CPAN having trouble with that is just one instance of nearly every other system that has its own custom package manager, from Python to GNU R to Scheme.</p></htmltext>
<tokenext>common-lisp-controller [ cliki.net ] is an attempt to make Common Lisp package management play nicely with Debian package management , so , for example , trying to load a package within ASDF ( Lisp ) finds the appropriate Debian package if it 's installed ( like the linked article discusses doing for CPAN ) .Strongly package-manager-based distributions like Debian usually do n't put a lot of effort into making stuff outside the distribution work well , though .
If you want some C library that is n't in Debian , you 're going to have to build it yourself and stick it somewhere , and all the stuff in Debian is n't going to know about it .
Similarly , if you want some CPAN module that is n't packaged in Debian ( the Perl equivalent of a third-party shared library that is n't packaged in Debian ) , you 're going to have to muck with it yourself , and it wo n't be in the usual dependency chain.The usual Debian answer to these sorts of problems is : well , if it 's maintained , useful , and under a DSFG license , let 's just package it !
Things get much less nice if the user is installing a bunch of custom stuff , and especially trying to get locally installed and package-managed stuff to play together nicely .
CPAN having trouble with that is just one instance of nearly every other system that has its own custom package manager , from Python to GNU R to Scheme .</tokentext>
<sentencetext>common-lisp-controller [cliki.net] is an attempt to make Common Lisp package management play nicely with Debian package management, so, for example, trying to load a package within ASDF (Lisp) finds the appropriate Debian package if it's installed (like the linked article discusses doing for CPAN).Strongly package-manager-based distributions like Debian usually don't put a lot of effort into making stuff outside the distribution work well, though.
If you want some C library that isn't in Debian, you're going to have to build it yourself and stick it somewhere, and all the stuff in Debian isn't going to know about it.
Similarly, if you want some CPAN module that isn't packaged in Debian (the Perl equivalent of a third-party shared library that isn't packaged in Debian), you're going to have to muck with it yourself, and it won't be in the usual dependency chain.The usual Debian answer to these sorts of problems is: well, if it's maintained, useful, and under a DSFG license, let's just package it!
Things get much less nice if the user is installing a bunch of custom stuff, and especially trying to get locally installed and package-managed stuff to play together nicely.
CPAN having trouble with that is just one instance of nearly every other system that has its own custom package manager, from Python to GNU R to Scheme.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543490</id>
	<title>g-cpan</title>
	<author>Deorus</author>
	<datestamp>1261666560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>As usual, Gentoo is a step ahead of the competition in this regard (and has been for a long time):</p><p><tt>jps@karma ~ $ eix g-cpan<br>* app-portage/g-cpan<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Available versions:  0.13.01 0.13.02 0.14.0 ~0.14.1\_rc1 ~0.15.0 0.15.0-r1<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Homepage:            <a href="http://www.gentoo.org/proj/en/perl/g-cpan.xml" title="gentoo.org">http://www.gentoo.org/proj/en/perl/g-cpan.xml</a> [gentoo.org]<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Description:         g-cpan: generate and install CPAN modules using portage</tt></p><p>Since Portage is only a collection of installation instructions, any kind of vendor package is suitable for it; this is unlike the primitive package managers that come bundled with every other distribution that still have problems with vendor packages as well as software which they have no license to redistribute.</p></htmltext>
<tokenext>As usual , Gentoo is a step ahead of the competition in this regard ( and has been for a long time ) : jps @ karma ~ $ eix g-cpan * app-portage/g-cpan           Available versions : 0.13.01 0.13.02 0.14.0 ~ 0.14.1 \ _rc1 ~ 0.15.0 0.15.0-r1           Homepage : http : //www.gentoo.org/proj/en/perl/g-cpan.xml [ gentoo.org ]           Description : g-cpan : generate and install CPAN modules using portageSince Portage is only a collection of installation instructions , any kind of vendor package is suitable for it ; this is unlike the primitive package managers that come bundled with every other distribution that still have problems with vendor packages as well as software which they have no license to redistribute .</tokentext>
<sentencetext>As usual, Gentoo is a step ahead of the competition in this regard (and has been for a long time):jps@karma ~ $ eix g-cpan* app-portage/g-cpan
          Available versions:  0.13.01 0.13.02 0.14.0 ~0.14.1\_rc1 ~0.15.0 0.15.0-r1
          Homepage:            http://www.gentoo.org/proj/en/perl/g-cpan.xml [gentoo.org]
          Description:         g-cpan: generate and install CPAN modules using portageSince Portage is only a collection of installation instructions, any kind of vendor package is suitable for it; this is unlike the primitive package managers that come bundled with every other distribution that still have problems with vendor packages as well as software which they have no license to redistribute.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544408</id>
	<title>Better than ruby/gems</title>
	<author>prog-guru</author>
	<datestamp>1261673820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I usually download the tar.gz for a perl module, then it's a simple 'perl Makefile.pl &amp;&amp; make &amp;&amp; make test'.  Install honors DESTDIR, so then I can package it myself, every time.  If my distro ever does release an updated module, my package system should pick it up then.</p><p>Gems on the other hand, I haven't been able to package at all.  Best solution I've seen is Debian, they set up a 'quarantine' under<nobr> <wbr></nobr>/var/lib/gems, with it's own bin directory and everything, to keep gems away from Debian packaged ruby libs.  Then you get to fight with vendoring, config.gem, initializers, etc.  I got to the point on one app where I just gave up and copied the libraries into RAILS\_ROOT/lib.  I sure hope rails 3.0 improves this.</p></htmltext>
<tokenext>I usually download the tar.gz for a perl module , then it 's a simple 'perl Makefile.pl &amp;&amp; make &amp;&amp; make test' .
Install honors DESTDIR , so then I can package it myself , every time .
If my distro ever does release an updated module , my package system should pick it up then.Gems on the other hand , I have n't been able to package at all .
Best solution I 've seen is Debian , they set up a 'quarantine ' under /var/lib/gems , with it 's own bin directory and everything , to keep gems away from Debian packaged ruby libs .
Then you get to fight with vendoring , config.gem , initializers , etc .
I got to the point on one app where I just gave up and copied the libraries into RAILS \ _ROOT/lib .
I sure hope rails 3.0 improves this .</tokentext>
<sentencetext>I usually download the tar.gz for a perl module, then it's a simple 'perl Makefile.pl &amp;&amp; make &amp;&amp; make test'.
Install honors DESTDIR, so then I can package it myself, every time.
If my distro ever does release an updated module, my package system should pick it up then.Gems on the other hand, I haven't been able to package at all.
Best solution I've seen is Debian, they set up a 'quarantine' under /var/lib/gems, with it's own bin directory and everything, to keep gems away from Debian packaged ruby libs.
Then you get to fight with vendoring, config.gem, initializers, etc.
I got to the point on one app where I just gave up and copied the libraries into RAILS\_ROOT/lib.
I sure hope rails 3.0 improves this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542544</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>adamkennedy</author>
	<datestamp>1261647000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.</p><p>It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation<nobr> <wbr></nobr>:)</p><p>In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with <a href="http://openjsan.org/" title="openjsan.org">OpenJSAN</a> [openjsan.org] and (more recently) for C with <a href="http://ccan.ozlabs.org/" title="ozlabs.org">The CCAN</a> [ozlabs.org] (run by Rusty Russel).</p><p>Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.</p></htmltext>
<tokenext>I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community , and I repeat the offer every now and then.It usually goes down as well as you might expect when someone from Python people hear the word " Perl " anywhere in a coversation : ) In the mean time , we 've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN [ openjsan.org ] and ( more recently ) for C with The CCAN [ ozlabs.org ] ( run by Rusty Russel ) .Both of these are arguably more sophisticated than Python 's packaging , although of course both of them are still down in the range of 100 packages .</tokentext>
<sentencetext>I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation :)In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN [openjsan.org] and (more recently) for C with The CCAN [ozlabs.org] (run by Rusty Russel).Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545386</id>
	<title>Re:Not to troll</title>
	<author>acid06</author>
	<datestamp>1261679940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Try looking at Perl code from 2009 instead.<br>You can say that Perl code from 2000 and Perl code written today are practically two different programming languages.</p><p>Differently from most other languages, Perl is an evolving language.</p><p>Just so you can get a clear example, compare the syntax of Perl code written using MooseX::Declare with whatever code you're dealing with:</p><p>
&nbsp; &nbsp; <a href="http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm" title="cpan.org" rel="nofollow">http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm</a> [cpan.org]</p><p>I bet if it wasn't for the dollar signs in front of variable names, you wouldn't even recognize it as Perl.</p><p>So, yes, Perl code from the 2000 is mostly crappy. Look for the newer stuff.</p></htmltext>
<tokenext>Try looking at Perl code from 2009 instead.You can say that Perl code from 2000 and Perl code written today are practically two different programming languages.Differently from most other languages , Perl is an evolving language.Just so you can get a clear example , compare the syntax of Perl code written using MooseX : : Declare with whatever code you 're dealing with :     http : //search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm [ cpan.org ] I bet if it was n't for the dollar signs in front of variable names , you would n't even recognize it as Perl.So , yes , Perl code from the 2000 is mostly crappy .
Look for the newer stuff .</tokentext>
<sentencetext>Try looking at Perl code from 2009 instead.You can say that Perl code from 2000 and Perl code written today are practically two different programming languages.Differently from most other languages, Perl is an evolving language.Just so you can get a clear example, compare the syntax of Perl code written using MooseX::Declare with whatever code you're dealing with:
    http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm [cpan.org]I bet if it wasn't for the dollar signs in front of variable names, you wouldn't even recognize it as Perl.So, yes, Perl code from the 2000 is mostly crappy.
Look for the newer stuff.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</id>
	<title>And what other languages too?</title>
	<author>Anonymous</author>
	<datestamp>1259781600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Ruby gems? PHP Pears? Python pies?</htmltext>
<tokenext>Ruby gems ?
PHP Pears ?
Python pies ?</tokentext>
<sentencetext>Ruby gems?
PHP Pears?
Python pies?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30549988</id>
	<title>I use both</title>
	<author>Anonymous</author>
	<datestamp>1261736760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>distribution installed perl for distribution-delivered scripts<br>my own copy with using cpan and installing/updating what my perl scripts need<br>-&gt; the only change is that in my own scripts the path to perl is different</p></htmltext>
<tokenext>distribution installed perl for distribution-delivered scriptsmy own copy with using cpan and installing/updating what my perl scripts need- &gt; the only change is that in my own scripts the path to perl is different</tokentext>
<sentencetext>distribution installed perl for distribution-delivered scriptsmy own copy with using cpan and installing/updating what my perl scripts need-&gt; the only change is that in my own scripts the path to perl is different</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544538</id>
	<title>Re:Not just Perl</title>
	<author>Anonymous</author>
	<datestamp>1261674660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1. You are wrong. The "fragmentation" has nothing to do with why Linux hasn't gone farther on the desktop</p><p>2. Even if the "fragmentation" was the sole cause of Linux not going farther on the desktop, I would not trade any of the choices we have for more market share. If people want to inflict Windows on themselves (although 7 is so bad), that is their problem.</p><p>3. "consistency and minimum standards" - someone has never heard of freedesktop.org</p></htmltext>
<tokenext>1 .
You are wrong .
The " fragmentation " has nothing to do with why Linux has n't gone farther on the desktop2 .
Even if the " fragmentation " was the sole cause of Linux not going farther on the desktop , I would not trade any of the choices we have for more market share .
If people want to inflict Windows on themselves ( although 7 is so bad ) , that is their problem.3 .
" consistency and minimum standards " - someone has never heard of freedesktop.org</tokentext>
<sentencetext>1.
You are wrong.
The "fragmentation" has nothing to do with why Linux hasn't gone farther on the desktop2.
Even if the "fragmentation" was the sole cause of Linux not going farther on the desktop, I would not trade any of the choices we have for more market share.
If people want to inflict Windows on themselves (although 7 is so bad), that is their problem.3.
"consistency and minimum standards" - someone has never heard of freedesktop.org</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542142</id>
	<title>Re:May I Be the First To Say This</title>
	<author>Anonymous</author>
	<datestamp>1259781180000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Fuck <b>PHP.</b></p></div> </blockquote><p>FTFY.</p></div>
	</htmltext>
<tokenext>Fuck PHP .
FTFY .</tokentext>
<sentencetext>Fuck PHP.
FTFY.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545912</id>
	<title>Re:Not to troll</title>
	<author>chromatic</author>
	<datestamp>1261683180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p> <em>All I know is when I review some old Perl code I've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code.</em></p></div> </blockquote><p>Perhaps those of us who write new Perl 5 code in 2009 are better at writing maintainable code than you were in 1999 or 2000.  Certainly I'm much better at it than I was in 1999, especially considering the tools and community standards that have emerged since then.</p></div>
	</htmltext>
<tokenext>All I know is when I review some old Perl code I 've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code .
Perhaps those of us who write new Perl 5 code in 2009 are better at writing maintainable code than you were in 1999 or 2000 .
Certainly I 'm much better at it than I was in 1999 , especially considering the tools and community standards that have emerged since then .</tokentext>
<sentencetext> All I know is when I review some old Perl code I've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code.
Perhaps those of us who write new Perl 5 code in 2009 are better at writing maintainable code than you were in 1999 or 2000.
Certainly I'm much better at it than I was in 1999, especially considering the tools and community standards that have emerged since then.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542240</id>
	<title>Re:And what other languages too?</title>
	<author>Dice</author>
	<datestamp>1259782740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Gems would be a godsend.  I have a repository with 86 packages in it for one of my clients who runs a RoR app, most of those are gems.  Most of them are easy to package thanks to <a href="http://rubyforge.org/projects/gem2rpm/" title="rubyforge.org">gem2rpm</a> [rubyforge.org], but there are a few which are a PITA and required me to patch the source, hack the spec file, or both in order to get them to install correctly.  Even so, we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves.</p></htmltext>
<tokenext>Gems would be a godsend .
I have a repository with 86 packages in it for one of my clients who runs a RoR app , most of those are gems .
Most of them are easy to package thanks to gem2rpm [ rubyforge.org ] , but there are a few which are a PITA and required me to patch the source , hack the spec file , or both in order to get them to install correctly .
Even so , we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves .</tokentext>
<sentencetext>Gems would be a godsend.
I have a repository with 86 packages in it for one of my clients who runs a RoR app, most of those are gems.
Most of them are easy to package thanks to gem2rpm [rubyforge.org], but there are a few which are a PITA and required me to patch the source, hack the spec file, or both in order to get them to install correctly.
Even so, we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545164</id>
	<title>More generic complaint</title>
	<author>SnarfQuest</author>
	<datestamp>1261678440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Perl has problems, but there's a lot more irritating problems in the FOSS world.</p><p>Why, for example, does everyone have to develop their own versions of 'make'? Sometimes using two or three different varients in the same package. The Linux kernel uses it's own configuration routines, while many modules use somethings else, and libraries will use yet another method. Every time you need to add a module to drive some strange hardware, you have to spend several days just trying to figure out how you are supposed to compile it, just because the author of that package found a "better" way of handling the build process. It's really bad when some parts of the build use automake/autoconf, others use plain make, and others use some self-developed construction. Pick ONE package build process, don't pick every one.</p></htmltext>
<tokenext>Perl has problems , but there 's a lot more irritating problems in the FOSS world.Why , for example , does everyone have to develop their own versions of 'make ' ?
Sometimes using two or three different varients in the same package .
The Linux kernel uses it 's own configuration routines , while many modules use somethings else , and libraries will use yet another method .
Every time you need to add a module to drive some strange hardware , you have to spend several days just trying to figure out how you are supposed to compile it , just because the author of that package found a " better " way of handling the build process .
It 's really bad when some parts of the build use automake/autoconf , others use plain make , and others use some self-developed construction .
Pick ONE package build process , do n't pick every one .</tokentext>
<sentencetext>Perl has problems, but there's a lot more irritating problems in the FOSS world.Why, for example, does everyone have to develop their own versions of 'make'?
Sometimes using two or three different varients in the same package.
The Linux kernel uses it's own configuration routines, while many modules use somethings else, and libraries will use yet another method.
Every time you need to add a module to drive some strange hardware, you have to spend several days just trying to figure out how you are supposed to compile it, just because the author of that package found a "better" way of handling the build process.
It's really bad when some parts of the build use automake/autoconf, others use plain make, and others use some self-developed construction.
Pick ONE package build process, don't pick every one.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542192</id>
	<title>Create a cpan package in your package manager</title>
	<author>Anonymous</author>
	<datestamp>1259782080000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>This module installs a tool which installs modules directly from cpan <b>but</b> enforces the conventions of the native environment. So if there is a perl module from the debian repositories called <i>kludge</i> and the same module is available directly from cpan, the cpan module would understand that they were the same basic thing, and know how to relate the different versions.</p></htmltext>
<tokenext>This module installs a tool which installs modules directly from cpan but enforces the conventions of the native environment .
So if there is a perl module from the debian repositories called kludge and the same module is available directly from cpan , the cpan module would understand that they were the same basic thing , and know how to relate the different versions .</tokentext>
<sentencetext>This module installs a tool which installs modules directly from cpan but enforces the conventions of the native environment.
So if there is a perl module from the debian repositories called kludge and the same module is available directly from cpan, the cpan module would understand that they were the same basic thing, and know how to relate the different versions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542698</id>
	<title>Debian solution ...</title>
	<author>Anonymous</author>
	<datestamp>1261650840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p> <tt>
apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install<br>
</tt></p> </div><p>
As for the CPAN client that asks too many questions - that's a matter of pre-configuring it for a distribution or for the installation options you chose when installing the distribution (it's not CPAN.pm's problem really, although it could indeed ask fewer questions).
</p></div>
	</htmltext>
<tokenext>apt-get install dh-make-perl ; dh-make-perl --cpan Your : : CPAN : : Package --install As for the CPAN client that asks too many questions - that 's a matter of pre-configuring it for a distribution or for the installation options you chose when installing the distribution ( it 's not CPAN.pm 's problem really , although it could indeed ask fewer questions ) .</tokentext>
<sentencetext> 
apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install
 
As for the CPAN client that asks too many questions - that's a matter of pre-configuring it for a distribution or for the installation options you chose when installing the distribution (it's not CPAN.pm's problem really, although it could indeed ask fewer questions).

	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544040</id>
	<title>As a music lover,</title>
	<author>Errol backfiring</author>
	<datestamp>1261671420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"Perl gem" sounds good!</htmltext>
<tokenext>" Perl gem " sounds good !</tokentext>
<sentencetext>"Perl gem" sounds good!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544464</id>
	<title>Re:The problem is simple to understand</title>
	<author>perlchild</author>
	<datestamp>1261674240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I think it'd be nice if the perl/cpan crowd would release a "ready for production" subset of cpan, that would be built, then packaged into every distro.  For the rest of us.</p></htmltext>
<tokenext>I think it 'd be nice if the perl/cpan crowd would release a " ready for production " subset of cpan , that would be built , then packaged into every distro .
For the rest of us .</tokentext>
<sentencetext>I think it'd be nice if the perl/cpan crowd would release a "ready for production" subset of cpan, that would be built, then packaged into every distro.
For the rest of us.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542226</id>
	<title>Re:Better fix it somehow</title>
	<author>SheeEttin</author>
	<datestamp>1259782500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Yep. A little while back, I was looking for an svn-bisect. Ubuntu has a perl svn-bisect in the repos, so I tried it. As far as I could tell, it didn't do anything, so I tried to get a newer version from CPAN. Now, how do I use this... It requires other modules? Okay, I'll grab them too. Now, how do I use THESE... compile them? Okay.<br>
These require modules too? Uh, grab this one, and... <br>
Screw it. I can live without.</htmltext>
<tokenext>Yep .
A little while back , I was looking for an svn-bisect .
Ubuntu has a perl svn-bisect in the repos , so I tried it .
As far as I could tell , it did n't do anything , so I tried to get a newer version from CPAN .
Now , how do I use this... It requires other modules ?
Okay , I 'll grab them too .
Now , how do I use THESE... compile them ?
Okay . These require modules too ?
Uh , grab this one , and.. . Screw it .
I can live without .</tokentext>
<sentencetext>Yep.
A little while back, I was looking for an svn-bisect.
Ubuntu has a perl svn-bisect in the repos, so I tried it.
As far as I could tell, it didn't do anything, so I tried to get a newer version from CPAN.
Now, how do I use this... It requires other modules?
Okay, I'll grab them too.
Now, how do I use THESE... compile them?
Okay.
These require modules too?
Uh, grab this one, and... 
Screw it.
I can live without.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543278</id>
	<title>Re:And what other languages too?</title>
	<author>Anonymous</author>
	<datestamp>1261663980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Ruby gems? PHP Pears? Python pies?</p></div><p>java beans!</p></div>
	</htmltext>
<tokenext>Ruby gems ?
PHP Pears ?
Python pies ? java beans !</tokentext>
<sentencetext>Ruby gems?
PHP Pears?
Python pies?java beans!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545676</id>
	<title>Reopening Bug, closed in error.</title>
	<author>Medievalist</author>
	<datestamp>1261681860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Close it when CPAN co-operates with the most common package manager on business linux systems - namely RPM.</p><p>Companies that make stuff that people actually need usually run SuSe or Red Hat, if they run any linux at all.  Why not simply have a CPAN plugin that keeps the RPM db updated? Don't use it if you don't want it.</p><p>Ideally, Red Hat and Suse should be paying for this, since their customers would be the ones profiting by it.</p></htmltext>
<tokenext>Close it when CPAN co-operates with the most common package manager on business linux systems - namely RPM.Companies that make stuff that people actually need usually run SuSe or Red Hat , if they run any linux at all .
Why not simply have a CPAN plugin that keeps the RPM db updated ?
Do n't use it if you do n't want it.Ideally , Red Hat and Suse should be paying for this , since their customers would be the ones profiting by it .</tokentext>
<sentencetext>Close it when CPAN co-operates with the most common package manager on business linux systems - namely RPM.Companies that make stuff that people actually need usually run SuSe or Red Hat, if they run any linux at all.
Why not simply have a CPAN plugin that keeps the RPM db updated?
Don't use it if you don't want it.Ideally, Red Hat and Suse should be paying for this, since their customers would be the ones profiting by it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542318</id>
	<title>Not to be pedantic...</title>
	<author>carlzum</author>
	<datestamp>1261685100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>but "Helping Perl Packagers" or "Helping Package Perl" would be sufficient If you package Perl you're a Perl packager, and every Perl packager packages Perl at some point<nobr> <wbr></nobr>:)</htmltext>
<tokenext>but " Helping Perl Packagers " or " Helping Package Perl " would be sufficient If you package Perl you 're a Perl packager , and every Perl packager packages Perl at some point : )</tokentext>
<sentencetext>but "Helping Perl Packagers" or "Helping Package Perl" would be sufficient If you package Perl you're a Perl packager, and every Perl packager packages Perl at some point :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180</id>
	<title>And Santa will bring me peace in the Middle East!!</title>
	<author>Anonymous</author>
	<datestamp>1259781780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Could a<nobr> <wbr></nobr>/. reader get laid? Could I go to bed before 4 AM? Could someone get me a real job?</p><p>No.</p><p>More seriously, not as CPAN works now. There is no "snapshotting" or "consistent distribution level" mechanism, so there is no mechanism to write consistent component compatibility lists, and no way for the existing CPAN to look back *out* into the operating systems available components. Even component naming is too inconsistent among distributions. And when different packagers fold specific packages into their basic Perl package, or components that are required for new modules move into the basic Perl package itself, you have dependency madness just waiting to bite you, very, very hard indeed if you let your local Perl integrator replace all the dependencies. This way lies Gentoo madness, and it's hideously unstable in the real world.</p><p>There are steps you can use, but they're dependent on Perl authors actually following packaging "best practices". Building RPM's from many perl components is fairly easy, especially with components like 'cpan2rpm' available, but then you have the crack-monkeys who prodoce component 1.00, 1.20, 1.201, 1.202, 1.2437, and then 1.30 and expect 1.30 to be considered "the most recent", and no way to flush the funky numbered ones from CPAN lest development continue and you get to 1.201 the hard way. And then there are idiots who can't be bothered to write actual Makefiles or Make::MakeMaker configurations, but each invent their own replacement for "make". And now that Perl 5.10 is out, too many "latest release" components form CPAN are going to simply demand updates to that new Perl release. What a wonderful crapshoot to upgrade your Perl, *on the fly* to a new major release simply because you want to print dates a certain way?</p><p>Then there's the continuing use of Apache 1.3 and the matching mod\_perl by Debian setups, and the utter nuttiness of rolling *BACK* Perl components to be compatible with that. What a wonderful way to *completely* fuck up your existing deployed codebase as rolling back your Perl to perl-5.6 to revert the incompatible components for that one.</p><p>Oh, and don't forget the "site-lib" versus "vendor-lib" settings. God forbids most Perl authors be bothered to actually *CARE* about it, but it does make a different in whether a component will be loaded and actually used in place of a separately installed one deployed as part of the operating system's other dependencies or package management system.</p></htmltext>
<tokenext>Could a / .
reader get laid ?
Could I go to bed before 4 AM ?
Could someone get me a real job ? No.More seriously , not as CPAN works now .
There is no " snapshotting " or " consistent distribution level " mechanism , so there is no mechanism to write consistent component compatibility lists , and no way for the existing CPAN to look back * out * into the operating systems available components .
Even component naming is too inconsistent among distributions .
And when different packagers fold specific packages into their basic Perl package , or components that are required for new modules move into the basic Perl package itself , you have dependency madness just waiting to bite you , very , very hard indeed if you let your local Perl integrator replace all the dependencies .
This way lies Gentoo madness , and it 's hideously unstable in the real world.There are steps you can use , but they 're dependent on Perl authors actually following packaging " best practices " .
Building RPM 's from many perl components is fairly easy , especially with components like 'cpan2rpm ' available , but then you have the crack-monkeys who prodoce component 1.00 , 1.20 , 1.201 , 1.202 , 1.2437 , and then 1.30 and expect 1.30 to be considered " the most recent " , and no way to flush the funky numbered ones from CPAN lest development continue and you get to 1.201 the hard way .
And then there are idiots who ca n't be bothered to write actual Makefiles or Make : : MakeMaker configurations , but each invent their own replacement for " make " .
And now that Perl 5.10 is out , too many " latest release " components form CPAN are going to simply demand updates to that new Perl release .
What a wonderful crapshoot to upgrade your Perl , * on the fly * to a new major release simply because you want to print dates a certain way ? Then there 's the continuing use of Apache 1.3 and the matching mod \ _perl by Debian setups , and the utter nuttiness of rolling * BACK * Perl components to be compatible with that .
What a wonderful way to * completely * fuck up your existing deployed codebase as rolling back your Perl to perl-5.6 to revert the incompatible components for that one.Oh , and do n't forget the " site-lib " versus " vendor-lib " settings .
God forbids most Perl authors be bothered to actually * CARE * about it , but it does make a different in whether a component will be loaded and actually used in place of a separately installed one deployed as part of the operating system 's other dependencies or package management system .</tokentext>
<sentencetext>Could a /.
reader get laid?
Could I go to bed before 4 AM?
Could someone get me a real job?No.More seriously, not as CPAN works now.
There is no "snapshotting" or "consistent distribution level" mechanism, so there is no mechanism to write consistent component compatibility lists, and no way for the existing CPAN to look back *out* into the operating systems available components.
Even component naming is too inconsistent among distributions.
And when different packagers fold specific packages into their basic Perl package, or components that are required for new modules move into the basic Perl package itself, you have dependency madness just waiting to bite you, very, very hard indeed if you let your local Perl integrator replace all the dependencies.
This way lies Gentoo madness, and it's hideously unstable in the real world.There are steps you can use, but they're dependent on Perl authors actually following packaging "best practices".
Building RPM's from many perl components is fairly easy, especially with components like 'cpan2rpm' available, but then you have the crack-monkeys who prodoce component 1.00, 1.20, 1.201, 1.202, 1.2437, and then 1.30 and expect 1.30 to be considered "the most recent", and no way to flush the funky numbered ones from CPAN lest development continue and you get to 1.201 the hard way.
And then there are idiots who can't be bothered to write actual Makefiles or Make::MakeMaker configurations, but each invent their own replacement for "make".
And now that Perl 5.10 is out, too many "latest release" components form CPAN are going to simply demand updates to that new Perl release.
What a wonderful crapshoot to upgrade your Perl, *on the fly* to a new major release simply because you want to print dates a certain way?Then there's the continuing use of Apache 1.3 and the matching mod\_perl by Debian setups, and the utter nuttiness of rolling *BACK* Perl components to be compatible with that.
What a wonderful way to *completely* fuck up your existing deployed codebase as rolling back your Perl to perl-5.6 to revert the incompatible components for that one.Oh, and don't forget the "site-lib" versus "vendor-lib" settings.
God forbids most Perl authors be bothered to actually *CARE* about it, but it does make a different in whether a component will be loaded and actually used in place of a separately installed one deployed as part of the operating system's other dependencies or package management system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126</id>
	<title>May I Be the First To Say This</title>
	<author>sneilan</author>
	<datestamp>1259780880000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>Fuck perl.</htmltext>
<tokenext>Fuck perl .</tokentext>
<sentencetext>Fuck perl.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694</id>
	<title>Not to troll</title>
	<author>gregarican</author>
	<datestamp>1261668720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>but what is the compelling reason that developers still stick with Perl, when there are more elegant languages out there? Python, Ruby and a few other scripting languages come to mind. I realize that Perl is a mature option, with lots of libraries/modules available. But at this point I can say the same about some of the others.</p><p>Perhaps because it would be too tough to totally revamp a project and rewrite it from the ground up? Even then the syntax and logic behind Python, Ruby, etc. are close enough that a decent developer could wrap their head around the nitty gritty details.</p><p>All I know is when I review some old Perl code I've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code. To each their own I suppose, so like I said it's not a troll. Just my US $0.02<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>but what is the compelling reason that developers still stick with Perl , when there are more elegant languages out there ?
Python , Ruby and a few other scripting languages come to mind .
I realize that Perl is a mature option , with lots of libraries/modules available .
But at this point I can say the same about some of the others.Perhaps because it would be too tough to totally revamp a project and rewrite it from the ground up ?
Even then the syntax and logic behind Python , Ruby , etc .
are close enough that a decent developer could wrap their head around the nitty gritty details.All I know is when I review some old Perl code I 've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code .
To each their own I suppose , so like I said it 's not a troll .
Just my US $ 0.02 : - )</tokentext>
<sentencetext>but what is the compelling reason that developers still stick with Perl, when there are more elegant languages out there?
Python, Ruby and a few other scripting languages come to mind.
I realize that Perl is a mature option, with lots of libraries/modules available.
But at this point I can say the same about some of the others.Perhaps because it would be too tough to totally revamp a project and rewrite it from the ground up?
Even then the syntax and logic behind Python, Ruby, etc.
are close enough that a decent developer could wrap their head around the nitty gritty details.All I know is when I review some old Perl code I've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code.
To each their own I suppose, so like I said it's not a troll.
Just my US $0.02 :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30549402</id>
	<title>Re:The problem is simple to understand</title>
	<author>sciurus0</author>
	<datestamp>1261680120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It sounds like you'd be interested in at <a href="http://perllinux.sourceforge.net/" title="sourceforge.net">Perl/Linux</a> [sourceforge.net], a linux distribution where ALL programs are written in perl.</p></htmltext>
<tokenext>It sounds like you 'd be interested in at Perl/Linux [ sourceforge.net ] , a linux distribution where ALL programs are written in perl .</tokentext>
<sentencetext>It sounds like you'd be interested in at Perl/Linux [sourceforge.net], a linux distribution where ALL programs are written in perl.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542308</id>
	<title>GoboLinux has something that does this</title>
	<author>Anonymous</author>
	<datestamp>1259783940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just new, in fact.</p><p>CPAN gets its own directory tree, and the user can install modules to it in the usual way, but system packages can also depend on CPAN modules directly. A dependency on "CPAN:XML::Writer &gt;= 0.604" from a system package will install XML::Writer in the CPAN tree, rather than having everything repackaged and duplicated or conflicting with packages from the distribution. The aim is to cover all the common domain-specific package managers (so also RubyGems, LuaRocks, PEAR,<nobr> <wbr></nobr>...) on the same level.</p><p>I have a paper on it in the Distro Summit at linux.conf.au next month, and until then an <a href="http://mwh.geek.nz/2009/07/23/an-overview-of-systemaliens/" title="mwh.geek.nz" rel="nofollow">overview of the system</a> [mwh.geek.nz] is in the linked blog post.</p></htmltext>
<tokenext>Just new , in fact.CPAN gets its own directory tree , and the user can install modules to it in the usual way , but system packages can also depend on CPAN modules directly .
A dependency on " CPAN : XML : : Writer &gt; = 0.604 " from a system package will install XML : : Writer in the CPAN tree , rather than having everything repackaged and duplicated or conflicting with packages from the distribution .
The aim is to cover all the common domain-specific package managers ( so also RubyGems , LuaRocks , PEAR , ... ) on the same level.I have a paper on it in the Distro Summit at linux.conf.au next month , and until then an overview of the system [ mwh.geek.nz ] is in the linked blog post .</tokentext>
<sentencetext>Just new, in fact.CPAN gets its own directory tree, and the user can install modules to it in the usual way, but system packages can also depend on CPAN modules directly.
A dependency on "CPAN:XML::Writer &gt;= 0.604" from a system package will install XML::Writer in the CPAN tree, rather than having everything repackaged and duplicated or conflicting with packages from the distribution.
The aim is to cover all the common domain-specific package managers (so also RubyGems, LuaRocks, PEAR, ...) on the same level.I have a paper on it in the Distro Summit at linux.conf.au next month, and until then an overview of the system [mwh.geek.nz] is in the linked blog post.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220</id>
	<title>The problem is simple to understand</title>
	<author>erroneus</author>
	<datestamp>1261662540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>In "Perl World" keeping Perl modules up to date is important.  In "Distro World" maintaining a consistent and maintainable distro is important.  These two desires are at odds with each other.</p><p>Does updating Perl Libraries ever result in some older Perl app or script breaking?  My guess is that there is a strong possibility.  Distro makers/maintainers are concerned that updates that occur without their knowledge will result in unpredictable chaos and difficult-to-track bug reports.  By making the set up of CPAN deliberate, you are taking the destiny of your installation into your own hands -- and there is nothing wrong with that in the slightest, so long as you are aware and capable of managing your own operating environment.</p><p>Perl is an important, key-underdog player in the Linux ecosystem.  I can't imagine Linux without Perl.  However, the same goes for a few other components which are not updated by distros at the very same pace as the developers of those components release them.  And there are many reasons for this -- good ones, bad ones and ugly ones.</p><p>Would it be nice if CPAN were configured right out of the box?  Yeah... if you were a Perl developer.  And there's nothing to stop a Perl developer from custom building his own Linux distro based around CPAN and all that.  In fact, I would be really interested to see what a Perl centric Linux distro would look like.  I believe an entire OS could be written in Perl... not saying it is a good idea, just that I believe it could be done<nobr> <wbr></nobr>... from the memory management to the GUI interface, I think it could be done.  But I am certain such a distro would be incredibly unique and speak of the differences of mind that Perl developers are known for.  But it would be difficult and I think it would not take long before Perl fans begin to appreciate what distro-folk deal with... or it could be as perfect and ideal as Perlies say it would be.</p></htmltext>
<tokenext>In " Perl World " keeping Perl modules up to date is important .
In " Distro World " maintaining a consistent and maintainable distro is important .
These two desires are at odds with each other.Does updating Perl Libraries ever result in some older Perl app or script breaking ?
My guess is that there is a strong possibility .
Distro makers/maintainers are concerned that updates that occur without their knowledge will result in unpredictable chaos and difficult-to-track bug reports .
By making the set up of CPAN deliberate , you are taking the destiny of your installation into your own hands -- and there is nothing wrong with that in the slightest , so long as you are aware and capable of managing your own operating environment.Perl is an important , key-underdog player in the Linux ecosystem .
I ca n't imagine Linux without Perl .
However , the same goes for a few other components which are not updated by distros at the very same pace as the developers of those components release them .
And there are many reasons for this -- good ones , bad ones and ugly ones.Would it be nice if CPAN were configured right out of the box ?
Yeah... if you were a Perl developer .
And there 's nothing to stop a Perl developer from custom building his own Linux distro based around CPAN and all that .
In fact , I would be really interested to see what a Perl centric Linux distro would look like .
I believe an entire OS could be written in Perl... not saying it is a good idea , just that I believe it could be done ... from the memory management to the GUI interface , I think it could be done .
But I am certain such a distro would be incredibly unique and speak of the differences of mind that Perl developers are known for .
But it would be difficult and I think it would not take long before Perl fans begin to appreciate what distro-folk deal with... or it could be as perfect and ideal as Perlies say it would be .</tokentext>
<sentencetext>In "Perl World" keeping Perl modules up to date is important.
In "Distro World" maintaining a consistent and maintainable distro is important.
These two desires are at odds with each other.Does updating Perl Libraries ever result in some older Perl app or script breaking?
My guess is that there is a strong possibility.
Distro makers/maintainers are concerned that updates that occur without their knowledge will result in unpredictable chaos and difficult-to-track bug reports.
By making the set up of CPAN deliberate, you are taking the destiny of your installation into your own hands -- and there is nothing wrong with that in the slightest, so long as you are aware and capable of managing your own operating environment.Perl is an important, key-underdog player in the Linux ecosystem.
I can't imagine Linux without Perl.
However, the same goes for a few other components which are not updated by distros at the very same pace as the developers of those components release them.
And there are many reasons for this -- good ones, bad ones and ugly ones.Would it be nice if CPAN were configured right out of the box?
Yeah... if you were a Perl developer.
And there's nothing to stop a Perl developer from custom building his own Linux distro based around CPAN and all that.
In fact, I would be really interested to see what a Perl centric Linux distro would look like.
I believe an entire OS could be written in Perl... not saying it is a good idea, just that I believe it could be done ... from the memory management to the GUI interface, I think it could be done.
But I am certain such a distro would be incredibly unique and speak of the differences of mind that Perl developers are known for.
But it would be difficult and I think it would not take long before Perl fans begin to appreciate what distro-folk deal with... or it could be as perfect and ideal as Perlies say it would be.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543730</id>
	<title>Re:And what other languages too?</title>
	<author>RegularFry</author>
	<datestamp>1261669020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can say from the painful experience of my colleagues that Gems are just broken. It's hard to say precisely what the problem is, but I *think* it's human rather than technical. It's telling that several solutions to "fix" Gems have sprung up in the past few months.</p><p>The problem stems, I think, from a tendency for software developers to attach themselves to the cargo-cult of major-minor-teeny version numbers. Without solid release engineering, you've got no indication that (for instance) a minor version bump doesn't include functionality breakage, or that a certain release only includes bug and security fixes *and nothing else*. What it boils down to is that you might as well only have two versions: current and edge.</p><p>I also see no reason *whatsoever* to allow more than one gem version on a production server. This being supported has caused us some *hideous* problems in the past. It's not helped by gem authors completely ignoring that some libraries (rake is an example) that are available both as gems and as ordinary system libraries. What happens then is that you can have one version installed, a gem requiring a version that should match, and that require failing because rake exists outside gems.</p><p>One way to fix it would be to have a "distribution" layer on top of gems, where people would nominate a specific set of gem versions, and make sure that they work happily together *without* the Gem namespace existing. End users could then install gems from a specific distribution without caring about specific version numbers, knowing that version conflicts couldn't happen. Optionally, the distribution could take care of building binary gems, so that production hosts didn't need compilation tools installed.  A not insignificant benefit of this would be that it could make gems compatible with the Debian packaging policy.</p><p>The only downside is that people would have to stop living on the edge. I don't see this as a bad thing.</p></htmltext>
<tokenext>I can say from the painful experience of my colleagues that Gems are just broken .
It 's hard to say precisely what the problem is , but I * think * it 's human rather than technical .
It 's telling that several solutions to " fix " Gems have sprung up in the past few months.The problem stems , I think , from a tendency for software developers to attach themselves to the cargo-cult of major-minor-teeny version numbers .
Without solid release engineering , you 've got no indication that ( for instance ) a minor version bump does n't include functionality breakage , or that a certain release only includes bug and security fixes * and nothing else * .
What it boils down to is that you might as well only have two versions : current and edge.I also see no reason * whatsoever * to allow more than one gem version on a production server .
This being supported has caused us some * hideous * problems in the past .
It 's not helped by gem authors completely ignoring that some libraries ( rake is an example ) that are available both as gems and as ordinary system libraries .
What happens then is that you can have one version installed , a gem requiring a version that should match , and that require failing because rake exists outside gems.One way to fix it would be to have a " distribution " layer on top of gems , where people would nominate a specific set of gem versions , and make sure that they work happily together * without * the Gem namespace existing .
End users could then install gems from a specific distribution without caring about specific version numbers , knowing that version conflicts could n't happen .
Optionally , the distribution could take care of building binary gems , so that production hosts did n't need compilation tools installed .
A not insignificant benefit of this would be that it could make gems compatible with the Debian packaging policy.The only downside is that people would have to stop living on the edge .
I do n't see this as a bad thing .</tokentext>
<sentencetext>I can say from the painful experience of my colleagues that Gems are just broken.
It's hard to say precisely what the problem is, but I *think* it's human rather than technical.
It's telling that several solutions to "fix" Gems have sprung up in the past few months.The problem stems, I think, from a tendency for software developers to attach themselves to the cargo-cult of major-minor-teeny version numbers.
Without solid release engineering, you've got no indication that (for instance) a minor version bump doesn't include functionality breakage, or that a certain release only includes bug and security fixes *and nothing else*.
What it boils down to is that you might as well only have two versions: current and edge.I also see no reason *whatsoever* to allow more than one gem version on a production server.
This being supported has caused us some *hideous* problems in the past.
It's not helped by gem authors completely ignoring that some libraries (rake is an example) that are available both as gems and as ordinary system libraries.
What happens then is that you can have one version installed, a gem requiring a version that should match, and that require failing because rake exists outside gems.One way to fix it would be to have a "distribution" layer on top of gems, where people would nominate a specific set of gem versions, and make sure that they work happily together *without* the Gem namespace existing.
End users could then install gems from a specific distribution without caring about specific version numbers, knowing that version conflicts couldn't happen.
Optionally, the distribution could take care of building binary gems, so that production hosts didn't need compilation tools installed.
A not insignificant benefit of this would be that it could make gems compatible with the Debian packaging policy.The only downside is that people would have to stop living on the edge.
I don't see this as a bad thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542508</id>
	<title>Homebrew</title>
	<author>mal0rd</author>
	<datestamp>1261645860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It sounds like <a href="http://wiki.github.com/mxcl/homebrew/cpan-ruby-gems-and-python-disttools" title="github.com">homebrew</a> [github.com] provides a good solution.  Perl (and Ruby and Python) already have mature packaging systems and they really don't need to interact with each other.  So homebrew is a smart packaging system that plays nice with others.</p></htmltext>
<tokenext>It sounds like homebrew [ github.com ] provides a good solution .
Perl ( and Ruby and Python ) already have mature packaging systems and they really do n't need to interact with each other .
So homebrew is a smart packaging system that plays nice with others .</tokentext>
<sentencetext>It sounds like homebrew [github.com] provides a good solution.
Perl (and Ruby and Python) already have mature packaging systems and they really don't need to interact with each other.
So homebrew is a smart packaging system that plays nice with others.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544510</id>
	<title>Re:The problem is simple to understand</title>
	<author>sabernet</author>
	<datestamp>1261674480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Where I work at they get around this by installing differing versions of each module into it's own directory and having a core installed module load up the appropriate paths in @INC at compile time.  All it requires is the scripter specify which modules they need and what versions of those via the 'use' statement.</p><p>It prevents newer versions from breaking older distros until such a time as when it's properly tested and vetted.</p></htmltext>
<tokenext>Where I work at they get around this by installing differing versions of each module into it 's own directory and having a core installed module load up the appropriate paths in @ INC at compile time .
All it requires is the scripter specify which modules they need and what versions of those via the 'use ' statement.It prevents newer versions from breaking older distros until such a time as when it 's properly tested and vetted .</tokentext>
<sentencetext>Where I work at they get around this by installing differing versions of each module into it's own directory and having a core installed module load up the appropriate paths in @INC at compile time.
All it requires is the scripter specify which modules they need and what versions of those via the 'use' statement.It prevents newer versions from breaking older distros until such a time as when it's properly tested and vetted.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543842</id>
	<title>Re:FreeBSD - one step ahead</title>
	<author>Rich0</author>
	<datestamp>1261669920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>With Gentoo it isn't seamless, but there is a tool that will create local overlay packages from a CPAN, and then they can be installed.  I don't think you get automatic updates or anything like that, but you do get collision protection, and the ability to cleanly uninstall.</p><p>There are lots of upstream packages that don't give much thought to distros.</p></htmltext>
<tokenext>With Gentoo it is n't seamless , but there is a tool that will create local overlay packages from a CPAN , and then they can be installed .
I do n't think you get automatic updates or anything like that , but you do get collision protection , and the ability to cleanly uninstall.There are lots of upstream packages that do n't give much thought to distros .</tokentext>
<sentencetext>With Gentoo it isn't seamless, but there is a tool that will create local overlay packages from a CPAN, and then they can be installed.
I don't think you get automatic updates or anything like that, but you do get collision protection, and the ability to cleanly uninstall.There are lots of upstream packages that don't give much thought to distros.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542222</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544232</id>
	<title>Re:g-cpan</title>
	<author>shovas</author>
	<datestamp>1261672620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>After 8 years of hardcore gentoo usage on home desktops and production servers, I'm a bitter, shell-shocked  ex-user taking refuge with ubuntu.</p><p>I love the idea of gentoo but I just don't think it can work in practice at scale.</p><p>I always refer back to this <a href="http://forums.gentoo.org/viewtopic-t-475474-start-0-postdays-0-postorder-asc-highlight-.html" title="gentoo.org" rel="nofollow">forum post</a> [gentoo.org] because it captures all of the problems of gentoo in a lengthy snapshot. That post is 26 pages long and started in 2006.</p><p>I love gentoo. About a year ago I got fed up with gentoo and installed other distros certain I'd never go back. But soon I was missing gentoo so I got back onto it for a few months. Then it broke again as usual just doing routine updates. That was the straw that broke the camel's back. I'm now on ubuntu and I'll try anything before going back to gentoo.</p></htmltext>
<tokenext>After 8 years of hardcore gentoo usage on home desktops and production servers , I 'm a bitter , shell-shocked ex-user taking refuge with ubuntu.I love the idea of gentoo but I just do n't think it can work in practice at scale.I always refer back to this forum post [ gentoo.org ] because it captures all of the problems of gentoo in a lengthy snapshot .
That post is 26 pages long and started in 2006.I love gentoo .
About a year ago I got fed up with gentoo and installed other distros certain I 'd never go back .
But soon I was missing gentoo so I got back onto it for a few months .
Then it broke again as usual just doing routine updates .
That was the straw that broke the camel 's back .
I 'm now on ubuntu and I 'll try anything before going back to gentoo .</tokentext>
<sentencetext>After 8 years of hardcore gentoo usage on home desktops and production servers, I'm a bitter, shell-shocked  ex-user taking refuge with ubuntu.I love the idea of gentoo but I just don't think it can work in practice at scale.I always refer back to this forum post [gentoo.org] because it captures all of the problems of gentoo in a lengthy snapshot.
That post is 26 pages long and started in 2006.I love gentoo.
About a year ago I got fed up with gentoo and installed other distros certain I'd never go back.
But soon I was missing gentoo so I got back onto it for a few months.
Then it broke again as usual just doing routine updates.
That was the straw that broke the camel's back.
I'm now on ubuntu and I'll try anything before going back to gentoo.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543490</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543072</id>
	<title>Re:Better fix it somehow</title>
	<author>emilper</author>
	<datestamp>1261659480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>care to elaborate ? I mean:  "broken", "mess" and "inconsistently" ?<nobr> <wbr></nobr>... or were you talking about PHP, Python, Java, C, C++ etc. ? As far as I can tell, Perl has the easiest way to find and install a shared library of them all<nobr> <wbr></nobr>... PHP and Java are coming along, though, with a similar setup<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>care to elaborate ?
I mean : " broken " , " mess " and " inconsistently " ?
... or were you talking about PHP , Python , Java , C , C + + etc .
? As far as I can tell , Perl has the easiest way to find and install a shared library of them all ... PHP and Java are coming along , though , with a similar setup .. .</tokentext>
<sentencetext>care to elaborate ?
I mean:  "broken", "mess" and "inconsistently" ?
... or were you talking about PHP, Python, Java, C, C++ etc.
? As far as I can tell, Perl has the easiest way to find and install a shared library of them all ... PHP and Java are coming along, though, with a similar setup ...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543086</id>
	<title>Re:And Santa will bring me peace in the Middle Eas</title>
	<author>digitalhermit</author>
	<datestamp>1261659720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are tools that can do a decent job of packaging some modules. For example, using the CPAN2RPM tool you can create  a SPEC file. The SPEC file can then contain a Requires and Provides section for generating dependency lists. These lists can contain version information such as a requirement that a package be within a particular version range. Frontend tools such as yum can then use these dependency lists to pull in appropriate modules contained in RPMs.  But yeah, it won't (automatically) solve the bizarre and arbitrary versioning schemes of some modules, but it can be manually worked around by adjusting the RPM version versus the Perl module version.</p></htmltext>
<tokenext>There are tools that can do a decent job of packaging some modules .
For example , using the CPAN2RPM tool you can create a SPEC file .
The SPEC file can then contain a Requires and Provides section for generating dependency lists .
These lists can contain version information such as a requirement that a package be within a particular version range .
Frontend tools such as yum can then use these dependency lists to pull in appropriate modules contained in RPMs .
But yeah , it wo n't ( automatically ) solve the bizarre and arbitrary versioning schemes of some modules , but it can be manually worked around by adjusting the RPM version versus the Perl module version .</tokentext>
<sentencetext>There are tools that can do a decent job of packaging some modules.
For example, using the CPAN2RPM tool you can create  a SPEC file.
The SPEC file can then contain a Requires and Provides section for generating dependency lists.
These lists can contain version information such as a requirement that a package be within a particular version range.
Frontend tools such as yum can then use these dependency lists to pull in appropriate modules contained in RPMs.
But yeah, it won't (automatically) solve the bizarre and arbitrary versioning schemes of some modules, but it can be manually worked around by adjusting the RPM version versus the Perl module version.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542380</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>Anonymous</author>
	<datestamp>1261686360000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>1</modscore>
	<htmltext><p>RedHat is somewhere between 1 and 2 years late releasing RHEL 6. The split of Red Hat Linux into Fedora and RHEL came back to bite RHEL 6, because when RedHat tried to release the responsibility of developing Fedora to the community, what they got in return was an overemphasis on nifty cool stuff while long-standing bugs, some very severe, went disregarded.</p><p>Turns out, people who aren't getting paid to do it only want to do it if it's fun! And so the quality of Fedora, which is what RHEL is ultimately based on, dropped, increasingly sharply, until Fedora Core 9 was so bad it was actually unusable! You couldn't even so much as change the font size in X before it would crash!</p><p>I wish I was kidding. It was horrible.</p><p>So RedHat got the hint, and for the last year has hired a legion of programmers to do little more than fix every bug they can find. There are reams and reams. Rumor is that Fedora Core 12 is ultimately in line to be RHEL 6. I'm using Fedora 10, and it's finally about as stable as Fedora 8.</p><p>We can only hope! RHEL 5 is really starting to show its age, and I have a suite of RHEL 4 servers that I want to switch over to something newer, but as old as 5 is, I'd rather make the jump to 6 as soon as it comes out than do another switchover in a year or two.</p></htmltext>
<tokenext>RedHat is somewhere between 1 and 2 years late releasing RHEL 6 .
The split of Red Hat Linux into Fedora and RHEL came back to bite RHEL 6 , because when RedHat tried to release the responsibility of developing Fedora to the community , what they got in return was an overemphasis on nifty cool stuff while long-standing bugs , some very severe , went disregarded.Turns out , people who are n't getting paid to do it only want to do it if it 's fun !
And so the quality of Fedora , which is what RHEL is ultimately based on , dropped , increasingly sharply , until Fedora Core 9 was so bad it was actually unusable !
You could n't even so much as change the font size in X before it would crash ! I wish I was kidding .
It was horrible.So RedHat got the hint , and for the last year has hired a legion of programmers to do little more than fix every bug they can find .
There are reams and reams .
Rumor is that Fedora Core 12 is ultimately in line to be RHEL 6 .
I 'm using Fedora 10 , and it 's finally about as stable as Fedora 8.We can only hope !
RHEL 5 is really starting to show its age , and I have a suite of RHEL 4 servers that I want to switch over to something newer , but as old as 5 is , I 'd rather make the jump to 6 as soon as it comes out than do another switchover in a year or two .</tokentext>
<sentencetext>RedHat is somewhere between 1 and 2 years late releasing RHEL 6.
The split of Red Hat Linux into Fedora and RHEL came back to bite RHEL 6, because when RedHat tried to release the responsibility of developing Fedora to the community, what they got in return was an overemphasis on nifty cool stuff while long-standing bugs, some very severe, went disregarded.Turns out, people who aren't getting paid to do it only want to do it if it's fun!
And so the quality of Fedora, which is what RHEL is ultimately based on, dropped, increasingly sharply, until Fedora Core 9 was so bad it was actually unusable!
You couldn't even so much as change the font size in X before it would crash!I wish I was kidding.
It was horrible.So RedHat got the hint, and for the last year has hired a legion of programmers to do little more than fix every bug they can find.
There are reams and reams.
Rumor is that Fedora Core 12 is ultimately in line to be RHEL 6.
I'm using Fedora 10, and it's finally about as stable as Fedora 8.We can only hope!
RHEL 5 is really starting to show its age, and I have a suite of RHEL 4 servers that I want to switch over to something newer, but as old as 5 is, I'd rather make the jump to 6 as soon as it comes out than do another switchover in a year or two.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543130</id>
	<title>Deep thoughts</title>
	<author>cntThnkofAname</author>
	<datestamp>1261660680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>OMG alliteration screw c++</htmltext>
<tokenext>OMG alliteration screw c + +</tokentext>
<sentencetext>OMG alliteration screw c++</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182</id>
	<title>At least the Perl crowd is trying,</title>
	<author>Anonymous</author>
	<datestamp>1259781840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>
At least the Perl crowd tries to solve this problem.  The Python crowd has a terrible time coordinating distribution of third-party modules. That's why it's taking forever for Python 3.x to get deployed. Red Hat Enterprise 5, Red Hat's flagship product, still uses Python 2.4, released in 2004.   (There's a Python 2.5 included, but it's not the one the system tools use.)
</p><p>
Perl has CPAN, which is reasonably well organized and well run. Python has the Python Package Index (formerly called Cheese Shop), but it's not well coordinated with Python releases.  Things seem to be improving, but Python is 20 years old now and ought to have a mature distribution system.</p></htmltext>
<tokenext>At least the Perl crowd tries to solve this problem .
The Python crowd has a terrible time coordinating distribution of third-party modules .
That 's why it 's taking forever for Python 3.x to get deployed .
Red Hat Enterprise 5 , Red Hat 's flagship product , still uses Python 2.4 , released in 2004 .
( There 's a Python 2.5 included , but it 's not the one the system tools use .
) Perl has CPAN , which is reasonably well organized and well run .
Python has the Python Package Index ( formerly called Cheese Shop ) , but it 's not well coordinated with Python releases .
Things seem to be improving , but Python is 20 years old now and ought to have a mature distribution system .</tokentext>
<sentencetext>
At least the Perl crowd tries to solve this problem.
The Python crowd has a terrible time coordinating distribution of third-party modules.
That's why it's taking forever for Python 3.x to get deployed.
Red Hat Enterprise 5, Red Hat's flagship product, still uses Python 2.4, released in 2004.
(There's a Python 2.5 included, but it's not the one the system tools use.
)

Perl has CPAN, which is reasonably well organized and well run.
Python has the Python Package Index (formerly called Cheese Shop), but it's not well coordinated with Python releases.
Things seem to be improving, but Python is 20 years old now and ought to have a mature distribution system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542222</id>
	<title>FreeBSD - one step ahead</title>
	<author>Anonymous</author>
	<datestamp>1259782440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>FreeBSD already does this! Installing a package via cpan will create the metadata and register a FreeBSD package.</p></htmltext>
<tokenext>FreeBSD already does this !
Installing a package via cpan will create the metadata and register a FreeBSD package .</tokentext>
<sentencetext>FreeBSD already does this!
Installing a package via cpan will create the metadata and register a FreeBSD package.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376</id>
	<title>Works For Me.  Closing Bug Report.</title>
	<author>Anonymous</author>
	<datestamp>1261686240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Cpan works people.  And it works well.  It works on Windows(strawberry perl) it works on Debian, it works on Mac.  When it fails, it's not that hard to figure out where and quickly get the scope/scale of the problem worked out.</p><p>Besides, it seems to me the whole packaging scheme is designed to be kind of loose on purpose.  Criticizing it for a design feature is pointless.</p><p>If you really insist on blasting away at Perl, then you'll be blasting away at Python soon enough.  Shocking but true, there are packaging issues with Python too.</p></htmltext>
<tokenext>Cpan works people .
And it works well .
It works on Windows ( strawberry perl ) it works on Debian , it works on Mac .
When it fails , it 's not that hard to figure out where and quickly get the scope/scale of the problem worked out.Besides , it seems to me the whole packaging scheme is designed to be kind of loose on purpose .
Criticizing it for a design feature is pointless.If you really insist on blasting away at Perl , then you 'll be blasting away at Python soon enough .
Shocking but true , there are packaging issues with Python too .</tokentext>
<sentencetext>Cpan works people.
And it works well.
It works on Windows(strawberry perl) it works on Debian, it works on Mac.
When it fails, it's not that hard to figure out where and quickly get the scope/scale of the problem worked out.Besides, it seems to me the whole packaging scheme is designed to be kind of loose on purpose.
Criticizing it for a design feature is pointless.If you really insist on blasting away at Perl, then you'll be blasting away at Python soon enough.
Shocking but true, there are packaging issues with Python too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542488</id>
	<title>Re:At least the Perl crowd is trying,</title>
	<author>King InuYasha</author>
	<datestamp>1261688280000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext>There's no way in hell that Red Hat, as an American company, would use Fedora 13 as the basis for RHEL 6. So, almost definitely, Fedora 12 will be the primary release that RHEL6 is based on. There will almost certainly be some components cherry picked from Fedora 13, but Fedora 13 will not be the ultimate basis of RHEL 6.</htmltext>
<tokenext>There 's no way in hell that Red Hat , as an American company , would use Fedora 13 as the basis for RHEL 6 .
So , almost definitely , Fedora 12 will be the primary release that RHEL6 is based on .
There will almost certainly be some components cherry picked from Fedora 13 , but Fedora 13 will not be the ultimate basis of RHEL 6 .</tokentext>
<sentencetext>There's no way in hell that Red Hat, as an American company, would use Fedora 13 as the basis for RHEL 6.
So, almost definitely, Fedora 12 will be the primary release that RHEL6 is based on.
There will almost certainly be some components cherry picked from Fedora 13, but Fedora 13 will not be the ultimate basis of RHEL 6.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543724</id>
	<title>Re:May I Be the First To Say This</title>
	<author>jonaskoelker</author>
	<datestamp>1261669020000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>For your next trick, I'll bet you'll tell us that emacs &gt; vi</p></div><p>Fuck 'em both; ed is The One True Editor.</p></div>
	</htmltext>
<tokenext>For your next trick , I 'll bet you 'll tell us that emacs &gt; viFuck 'em both ; ed is The One True Editor .</tokentext>
<sentencetext>For your next trick, I'll bet you'll tell us that emacs &gt; viFuck 'em both; ed is The One True Editor.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542178</id>
	<title>fSuck a Goat</title>
	<author>Anonymous</author>
	<datestamp>1259781780000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">partner. And if and, after initial EFNet, and aaply [idge.net]</a> [goat.cx]</htmltext>
<tokenext>partner .
And if and , after initial EFNet , and aaply [ idge.net ] [ goat.cx ]</tokentext>
<sentencetext>partner.
And if and, after initial EFNet, and aaply [idge.net] [goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542960</id>
	<title>Re:Works For Me. Closing Bug Report.</title>
	<author>Anonymous</author>
	<datestamp>1261656960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>It works on Windows(strawberry perl) </i> </p><p>Right. Sure it does. Try to get the DBI to recognize Postgresql. I'll bet you a round of beer that it won't install. Ever.</p><p>CPAN was great. However, the sheer number of modules that don't even install is staggering and now CPAN is a bloody mess. I sincerely hope that with the (the time is near!) coming of Perl 6 it will be seen as a good opportunity to start all over with a fresh CPAN6.</p></htmltext>
<tokenext>It works on Windows ( strawberry perl ) Right .
Sure it does .
Try to get the DBI to recognize Postgresql .
I 'll bet you a round of beer that it wo n't install .
Ever.CPAN was great .
However , the sheer number of modules that do n't even install is staggering and now CPAN is a bloody mess .
I sincerely hope that with the ( the time is near !
) coming of Perl 6 it will be seen as a good opportunity to start all over with a fresh CPAN6 .</tokentext>
<sentencetext>It works on Windows(strawberry perl)  Right.
Sure it does.
Try to get the DBI to recognize Postgresql.
I'll bet you a round of beer that it won't install.
Ever.CPAN was great.
However, the sheer number of modules that don't even install is staggering and now CPAN is a bloody mess.
I sincerely hope that with the (the time is near!
) coming of Perl 6 it will be seen as a good opportunity to start all over with a fresh CPAN6.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146</id>
	<title>Re:May I Be the First To Say This</title>
	<author>flydpnkrtn</author>
	<datestamp>1259781240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's the kind of spirit that's made open source what it is today!</p><p>For your next trick, I'll bet you'll tell us that emacs &gt; vi</p></htmltext>
<tokenext>That 's the kind of spirit that 's made open source what it is today ! For your next trick , I 'll bet you 'll tell us that emacs &gt; vi</tokentext>
<sentencetext>That's the kind of spirit that's made open source what it is today!For your next trick, I'll bet you'll tell us that emacs &gt; vi</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542222
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542448
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543730
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544538
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542764
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542226
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542960
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542488
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30549402
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544458
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544232
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543490
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543724
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543114
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542544
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544040
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543336
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544510
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542176
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545676
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543072
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542240
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544464
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543278
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545386
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_0319228_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30556402
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545322
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542258
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542174
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543114
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543730
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543278
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544040
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542240
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542698
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544458
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542256
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542764
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544538
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542180
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542582
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543086
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542126
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542146
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542176
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543724
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544574
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542222
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543842
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542508
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543694
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545386
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545912
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542166
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542226
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543072
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542258
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545322
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30556402
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542376
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30545676
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542960
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542182
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542544
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542380
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542488
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543336
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542448
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543368
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542292
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542192
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30542916
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543490
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544232
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_0319228.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30543220
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544464
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30544510
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_0319228.30549402
</commentlist>
</conversation>
