Rich Morin -- Prime Time Freeware founder, SunWorld columnist, and editor of the MacPerl book -- has written a piece (still in draft form) called Integrating package management and documentation that has people talking on various lists and web sites. An interesting read. Hopefully we can take some of these ideas and fix the problems he identifies.
Modules and Maintenance
Maclir on 2000-06-19T01:34:13
Some very good points raised. One thing I have discovered, not just with Perl, but *ix in general, is because there is no "central controlling" authority, anyone who thinks they can produce a useful tool does. And just like anyone these days can produce their own web pages, sadly, many do - and that is why there is so much dross on the web. Likewise with software products in the open source arena.
Now, how many different (and overlapping) modules / tools / utilities are there for doing CGI "stuff" with perl? What one do I choose to implement a large corporate site? I suspect that there are several good tools (or modules) - remembering "TIMTOWTDI". But, there is a lot of overlap, and the development effort that could be put into creating new (but needed) functionality is expended in making the overlap even greater.
This duplication in effort is one of the downsides of the open / free software process - and not identifited in the "Cathedral and the Bazaar" paper.
Not sure how well the culture of the open source development community would survive a transition to a more rigidly controlled environment.
Ken
XML responses from search.cpan.org
gbarr on 2000-06-19T12:10:34
Well we already seem to be hitting articles with this. Although they did not give a link or details how to do it
Re:XML responses from search.cpan.org
pudge on 2000-06-19T13:44:34
Is that good or bad?
If bad, well, what you like to have done?
Re:XML responses from search.cpan.org
gbarr on 2000-06-19T20:08:19
Both
:)
If they are going to mention it they could have at least given a link to search.cpan.org
The adjective "unixish"...
clintp on 2000-06-19T20:28:02
...must die before some "journalist" gets a hold of it and starts using it as a collective adjective to describe Unix systems.
Quit beating around the bush and call them Unix systems, or Unix or something. Yeah, the name "Unix" is owned by someone else. Ack! Pttth! If you're not slapping the name "Unix" on something you're selling, don't sweat it.
If it walks like a duck, sounds like a duck...
Re:The adjective "unixish"...
pudge on 2000-06-20T00:20:45
Yeah, but Rich is an Old School Unix user. He has trouble calling Linux "Unix", "unix", or "UNIX". I can't say I blame him.
My favorite is the ORA survey I recently took that asked which platforms I used, and I think the three "Unixish" choices were Unix, Linux, and Solaris.
Re:The adjective "unixish"...
jns on 2000-06-20T08:36:24
If it walks like a duck, sounds like a duck...
... then its William Hague
I tend to use Unix-like where I might be concerned with appeasing the pedants. If I am not thus concerned I'm not worried what things get called really.
/J\
Re:The adjective "unixish"...
rdm on 2000-06-20T16:13:49
I understand your problem with "Unixish". It's
not my favorite neologism, either, but I needed
something. Unfortunately, there
is no collective adjective or noun that is commonly accepted.
BTW, I heard about a Linux vendor who used the
assertion that "Linux is a UNIX-like operating system" in their literature. They shortly got a threatening letter from the Open Group! So, they decided to say that "UNIX is a Linux-like operating system" (:-).
In any case, even this "journalist" is open to suggestions...
Re:XML responses from search.cpan.org
hfb on 2000-06-23T15:20:11
I believe they got their information from use.perl and didn't list a link to it due to the comments made about it being a premature announcement . It's good press even so.
A link to the front page would have been good though most of the referring sites are cpan.org and perl.com. And the most popular search engine query is 'CPAN'
:)
e.
Re:Modules and Maintenance
rdm on 2000-06-25T08:15:10
Meta does not presume a "more rigidly controlled environment", any more than (for example) the FreeBSD Ports Collection does. It simply provides a way to bring together existing information
and (I hope) add new information.
If Meta becomes a "Category Killer" (like GCC),
some implicit control would be involved, but I
think we have time to deal with that issue (:-)
before it becomes annoying.
FYI, I have had a number of interesting comments
on the paper and have made quite a few additions
and changes. If you haven't looked at a recent
draft, please do so!
