Re: Mailman in Perl (Re: the list is dead, long live the list)
On Mon, Jan 15, 2001 at 10:42:34AM +, Steve Mynott wrote: > "David H. Adler" <[EMAIL PROTECTED]> writes: > > > > Oh, you're much too kind. My redhat box is disintigrating before my > > very eyes. root partition filled up for no reason and, thus I looked > > at the partition table: > > > > / > > /boot > > /home > > > > With home being the largest. > > > > What *were* they thinking when they configured this? > > I don't think you can really blame the distribution (which allows you > to partition the disk how you want) for someone partitioning the disk > wrongly. Except that the box came to me like this. I intend to rectify this in a bit by scaping red hat off with a large trowel and installing something useful, but I'm still trying to figure out why *anyone* would partition it this way... :-/ dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ There are 6 billion people in the world, and only 30 billion of those are Canadians - Headline in the Toronto Globe and Mail
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Mon, Jan 15, 2001 at 09:26:40AM -0500, Mark Rogaski wrote: > An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: > > : And as a matter of fact, I *did* check the script by hand before piping it > : in to a shell. Mainly out of interest to see how it did it rather than because I was paranoid about what it was doing, I should point out :-) > : Of course, that still doesn't help when it comes to > : verifying all the binaries involved. Perhaps you're saying we should > : never install binaries, and should compile everything ourselves. Perhaps > : we should check every line of code first before compiling. > > I never said that I was any less guilty of said idiocy ;) > > However, I have to disagree with the all-or-nothing approach to system > security. Actually, I agree with you. I was taking a reductio ad absurdam approach to the claim that Helix's installer was risky, and pointing out that it is no more risky than lots of stuff that we all do every day. IMO, Helix's server is sufficiently trustworthy for downloading binaries on my laptop. If I was downloading stuff to my server I would be more careful. > A reasonable first step would be to support digital signatures for > distributions on CPAN. [rant about verification etc] >This would, at the very least, reduce the > vulerability to the problems inherent in public key encryption (key > management, verification, MitM, etc). By developing a security model for > CPAN, we shift the weak links to the system rather than the new software. Ah, OK [snip above rant]. Yeah, all that does is shift the problem elsewhere, but does not solve it. I fear that this problem is not soluble given current technology whilst still retaining CPAN's ease of use both for end-users and for contributors. Which reminds me, I *really* should get round to uploading my hex thingummy. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: : : And as a matter of fact, I *did* check the script by hand before piping it : in to a shell. Of course, that still doesn't help when it comes to : verifying all the binaries involved. Perhaps you're saying we should : never install binaries, and should compile everything ourselves. Perhaps : we should check every line of code first before compiling. : I never said that I was any less guilty of said idiocy ;) However, I have to disagree with the all-or-nothing approach to system security. In a digital network, you _can't_ make things absolutely secure, hence the concept of a threat model ... you tailor your security policy to fit the potential threat to the system instead of all possible threats. Rather than ignore security because it will never be bulletproof, I think it is much better to construct a reasonable security model for CPAN. A reasonable first step would be to support digital signatures for distributions on CPAN. This would, at the very least, reduce the vulerability to the problems inherent in public key encryption (key management, verification, MitM, etc). By developing a security model for CPAN, we shift the weak links to the system rather than the new software. Mark -- Mark Rogaski | "What in the ding-dong-heckama-doodle [EMAIL PROTECTED] | hell is that?" http://www.pobox.com/~wendigo | -- a farmer in the 1992 __END__ | movie "Seedpeople" PGP signature
Re: Mailman in Perl (Re: the list is dead, long live the list)
> programs together, but I increasingly see it as a rather hackish peculiarity > of unix as opposed to a design strength. And it seems more hackish with each > passing year. This kind of stuff is groovy for sysadmin and local automation > but I don't like it in widely distributed stuff. As languages go, sh sucks Its not an original method. I saw it used 5 years ago for the automatic compilation of ircii (Of course, it didn't work under AIX) ;) Except it was then telnet some.host 54321 | sh
Re: Mailman in Perl (Re: the list is dead, long live the list)
Greg McCarroll wrote: > * Philip Newton ([EMAIL PROTECTED]) wrote: > > David Cantrell wrote: > > > And even CPAN counts as untrusted and unverified - how am I > > > to tell that $random_mirror has not been compromised? > > > > Heck, how can you tell that the super module someone told > > you about or you found through search.cpan.org doesn't > > contain a trojan in its Makefile.PL? > > see MJD's Memoize for this Ouch, that's nasty. However, he appears to have turned it off in 0.62. Cheers, Philip
Re: Mailman in Perl (Re: the list is dead, long live the list)
* Philip Newton ([EMAIL PROTECTED]) wrote: > David Cantrell wrote: > > And even CPAN counts as untrusted and unverified - how am I > > to tell that $random_mirror has not been compromised? > > Heck, how can you tell that the super module someone told you about or you > found through search.cpan.org doesn't contain a trojan in its Makefile.PL? > see MJD's Memoize for this -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Mailman in Perl (Re: the list is dead, long live the list)
David Cantrell wrote: > And even CPAN counts as untrusted and unverified - how am I > to tell that $random_mirror has not been compromised? Heck, how can you tell that the super module someone told you about or you found through search.cpan.org doesn't contain a trojan in its Makefile.PL? Cheers, Philip
Re: Mailman in Perl (Re: the list is dead, long live the list)
* Michael Stevens ([EMAIL PROTECTED]) wrote: > On Sun, Jan 14, 2001 at 11:26:28PM -0500, Mark Rogaski wrote: > > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > > source directly to the shell. > > How is it less secure than downloading a tar file and typing ./configure? > > Admittedly you *could* check several meg of source for trojans, but I > don't believe you *do*. > this is something that is going to become a bigger and bigger thing, i could see the concepts of karma/ebay reputations merging more and more with digital signatures needless to say that WIDs make this an even bigger concern -- Greg McCarroll http://www.mccarroll.uklinux.net
RE: Mailman in Perl (Re: the list is dead, long live the list)
> How is it less secure than downloading a tar file and typing > ./configure? It's not, I suppose, but it's annoying in a unixy kind of way. I used to think it was really cool the way you could chain lots of little unixy programs together, but I increasingly see it as a rather hackish peculiarity of unix as opposed to a design strength. And it seems more hackish with each passing year. This kind of stuff is groovy for sysadmin and local automation but I don't like it in widely distributed stuff. As languages go, sh sucks big time - the fact that (only slightly different) implementations of exist on all Unix systems doesn't strike me as a good reason for doing everything in it. CPAN.pm strikes me as a good way of doing things. Its interfaces are programmatic not OS dependant, its scriptability is programmatic not OS dependant, and it works pretty well (apart from occasionally trying to upgrade your copy of Perl for you).
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, Jan 14, 2001 at 11:26:28PM -0500, Mark Rogaski wrote: > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > source directly to the shell. How is it less secure than downloading a tar file and typing ./configure? Admittedly you *could* check several meg of source for trojans, but I don't believe you *do*. Michael
Re: Mailman in Perl (Re: the list is dead, long live the list)
"David H. Adler" <[EMAIL PROTECTED]> writes: > On Sat, Jan 13, 2001 at 05:19:18PM -0600, Paul Makepeace wrote: > > It continues to amaze me that people still use Red Hat. It's > > just a pile of marketing driven crap. > > Oh, you're much too kind. My redhat box is disintigrating before my > very eyes. root partition filled up for no reason and, thus I looked > at the partition table: > > / > /boot > /home > > With home being the largest. > > What *were* they thinking when they configured this? I don't think you can really blame the distribution (which allows you to partition the disk how you want) for someone partitioning the disk wrongly. -- 1024/D9C69DF9 steve mynott [EMAIL PROTECTED] brook's law: adding manpower to a late software project makes it later
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Mon, Jan 15, 2001 at 10:20:02AM +, David Cantrell wrote: > On Sun, Jan 14, 2001 at 11:26:28PM -0500, Mark Rogaski wrote: > > > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > > source directly to the shell. > > Of course, it's equally stupid to install software from an untrusted, > unverified source using any other method. And even CPAN counts as untrusted and unverified - how am I to tell that $random_mirror has not been compromised? And as a matter of fact, I *did* check the script by hand before piping it in to a shell. Of course, that still doesn't help when it comes to verifying all the binaries involved. Perhaps you're saying we should never install binaries, and should compile everything ourselves. Perhaps we should check every line of code first before compiling. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, Jan 14, 2001 at 11:26:28PM -0500, Mark Rogaski wrote: > An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: > > : It's more than cute. It's *BRILLIANT*. The user doesn't even have to > : know what computer they have. Whilst they only support a couple of > : combinations of architecture and OS in that script, it would be pretty > : damned trivial to have it support a few Linux distros, Solaris, *BSD > : and MacOS X. > > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > source directly to the shell. Of course, it's equally stupid to install software from an untrusted, unverified source using any other method. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
* Mark Rogaski ([EMAIL PROTECTED]) wrote: > An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: > : > : It's more than cute. It's *BRILLIANT*. The user doesn't even have to > : know what computer they have. Whilst they only support a couple of > : combinations of architecture and OS in that script, it would be pretty > : damned trivial to have it support a few Linux distros, Solaris, *BSD > : and MacOS X. > : > > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > source directly to the shell. > i trust you read Makefile.PL before doing perl Makefile.PL in that case?[1] Greg [1] See Memoize -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, Jan 14, 2001 at 11:26:28PM -0500, Mark Rogaski wrote: > An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: > : > : It's more than cute. It's *BRILLIANT*. The user doesn't even have to > : know what computer they have. Whilst they only support a couple of > : combinations of architecture and OS in that script, it would be pretty > : damned trivial to have it support a few Linux distros, Solaris, *BSD > : and MacOS X. > : > > It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified > source directly to the shell. But it's so much fun! Well, on someone else's shift, anyway... :-) dave, just kidding, in case there was some question... -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ "You can't give a 4 to truth." - Saul Williams
Re: Mailman in Perl (Re: the list is dead, long live the list)
An entity claiming to be David Cantrell ([EMAIL PROTECTED]) wrote: : : It's more than cute. It's *BRILLIANT*. The user doesn't even have to : know what computer they have. Whilst they only support a couple of : combinations of architecture and OS in that script, it would be pretty : damned trivial to have it support a few Linux distros, Solaris, *BSD : and MacOS X. : It's also sheer idiocy to pipe arbitrary code from an untrusted, unverified source directly to the shell. Mark -- Mark Rogaski | "What in the ding-dong-heckama-doodle [EMAIL PROTECTED] | hell is that?" http://www.pobox.com/~wendigo | -- a farmer in the 1992 __END__ | movie "Seedpeople" PGP signature
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 05:19:18PM -0600, Paul Makepeace wrote: > On Sat, Jan 13, 2001 at 03:05:48PM +, Michael Stevens wrote: > > > > Or, more sensibly, debian. > > > > apt-get install foo > > It continues to amaze me that people still use Red Hat. It's > just a pile of marketing driven crap. Oh, you're much too kind. My redhat box is disintigrating before my very eyes. root partition filled up for no reason and, thus I looked at the partition table: / /boot /home With home being the largest. What *were* they thinking when they configured this? dha, g. -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ "Last year in Oregon, Summer fell on a *tuesday*. That was it. One day. Big shiny thing in the sky. Some people thought it was a UFO." - Randal Schwartz in comp.lang.perl.misc
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, Jan 14, 2001 at 05:01:55AM +, Shevek wrote: > I had always committed to the nature of Unix being that one does end up > with a pile of stuff on disk which one doesn't use. for i in etc usr; do find /$i -mount -type f -atime +60 | perl -lne unlink; done :-) > The point is that this > doesn't matter. There are some downsides: if you have have old binaries that have slipped out of the upgrade/patch cycle you are looking at a potential security risk. I have thought in the past "1GB is *bound* to be a big enough /usr!" and when I hit 85% utilisation have to look at upgrading my disk, faffing with extra mounts or a suffering performance hit. Or clearing it all up. > I bet you have libc5 and libc6 installed... # dpkg -l | grep libc[56] ii libc6 2.2-1 GNU C Library: Shared libraries and Timezone [snip other shit] # Paul
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, Jan 14, 2001 at 05:01:55AM +, Shevek wrote: > On Sun, 14 Jan 2001, David Cantrell wrote: > > > rely on RPMs. The real reason I haven't switched is because it's really > > *nasty* trying to switch from one distro to another without a) losing > > valuable config data and b) ending up with a ton of unused junk on the disk > > which is nigh-on impossible to tell apart from stuff that's in use. > > I had always committed to the nature of Unix being that one does end up > with a pile of stuff on disk which one doesn't use. The point is that this > doesn't matter. Unless you're upgrading something every day or every week, > the junk pile-up on a production server won't do much more than double or > treble the hard disk usage of the OS, which will be small compared to the > user data, and is still in a small order of magnitude. Whilst this may be OK on servers, it ain't OK on desktops or even worse, laptops. And yes, I am upgrading something several times a week. When there's new security alerts, for instance. This is essential if you are permanently online. And on my personal server, disk space is very much at a premium. There, the OS + programs is only *one* order of magnitude less than the user data, and even if remains an order of magnitude less, it will soon bump up against having filled the stuff-other-than-user-data disk. Even the Mighty Debian suffers in this regard. Can anyone here enlighten us as to whether the BSD systems are any better at keeping themselves tidy? -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
David Cantrell <[EMAIL PROTECTED]> writes: > Yeah, I know, but then I compile plenty of stuff from scratch rather than > rely on RPMs. The real reason I haven't switched is because it's really The drawback with 'make install' from source is that it doesn't write a database of files owned by that source package which is the great advantage of binary packages. So you can't use do 'make uninstall' to cleanly remove the program if you don't like or use it. This is basically what the *BSD ports system does. It should be possible to write some wrapper for GNU configure to add a 'make uninstall' to the Makefile. In the absence of this I usually type 'script' to log whats installed at the 'make install' stage.. > *nasty* trying to switch from one distro to another without a) losing > valuable config data and b) ending up with a ton of unused junk on the disk The way to handle UNIX configuration files is like software and use RCS. On every system you can then type one command 'locate ,v' to see all your local changes. You can then systematically port config changes to the new distribution. > which is nigh-on impossible to tell apart from stuff that's in use. It's a one liner to display files that haven't been used in the last three months using 'find -atime'. Other advantage of binary package managers is you can then go ahead and delete large chunks of your OS that you never use and it should warn you if it breaks other stuff. -- 1024/D9C69DF9 steve mynott [EMAIL PROTECTED] if we knew what it was we were doing, it would not be called research, would it? - albert einstein
Re: Mailman in Perl (Re: the list is dead, long live the list)
* Shevek ([EMAIL PROTECTED]) wrote: > On Sun, 14 Jan 2001, David Cantrell wrote: > > > rely on RPMs. The real reason I haven't switched is because it's really > > *nasty* trying to switch from one distro to another without a) losing > > valuable config data and b) ending up with a ton of unused junk on the disk > > which is nigh-on impossible to tell apart from stuff that's in use. > > I had always committed to the nature of Unix being that one does end up > with a pile of stuff on disk which one doesn't use. The point is that this > doesn't matter. Unless you're upgrading something every day or every week, > the junk pile-up on a production server won't do much more than double or > treble the hard disk usage of the OS, which will be small compared to the > user data, and is still in a small order of magnitude. > exactly, i was having a chat with a colleague the other day about hard disk usage over the years, and i noted that my home directory took up 10Gb's and that was excluding the 15Gb mp3 partition, he responded saying that he had filled up his data partition (20Gb) already, shocked that he had used so much i queried him further it appeared that the data he had stored was all game installls it seems that win32 users consider computers to be software orientated while unix users consider computers to be data orientated -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, 14 Jan 2001, David Cantrell wrote:
> rely on RPMs. The real reason I haven't switched is because it's really
> *nasty* trying to switch from one distro to another without a) losing
> valuable config data and b) ending up with a ton of unused junk on the disk
> which is nigh-on impossible to tell apart from stuff that's in use.
I had always committed to the nature of Unix being that one does end up
with a pile of stuff on disk which one doesn't use. The point is that this
doesn't matter. Unless you're upgrading something every day or every week,
the junk pile-up on a production server won't do much more than double or
treble the hard disk usage of the OS, which will be small compared to the
user data, and is still in a small order of magnitude.
I bet you have libc5 and libc6 installed...
It's still smaller than win2k...
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 05:19:18PM -0600, Paul Makepeace wrote: > It continues to amaze me that people still use Red Hat. It's > just a pile of marketing driven crap. Debian is so far superior > it hurts watching people struggle with RPMs. Yeah, I know, but then I compile plenty of stuff from scratch rather than rely on RPMs. The real reason I haven't switched is because it's really *nasty* trying to switch from one distro to another without a) losing valuable config data and b) ending up with a ton of unused junk on the disk which is nigh-on impossible to tell apart from stuff that's in use. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 03:05:48PM +, Michael Stevens wrote: > > Or, more sensibly, debian. > > apt-get install foo It continues to amaze me that people still use Red Hat. It's just a pile of marketing driven crap. Debian is so far superior it hurts watching people struggle with RPMs. And I'm not the type to get all zealous and mount flags of allegiance (hell, I use NT more than Linux :-) Paul
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 02:53:57PM +, David Cantrell wrote: > > Surely, then, rpm should have the ability to install and fetch > > dependencies from the network automagically? > Yes it should. It doesn't. Which is why Helix's installer is so much > easier to use. Or, more sensibly, debian. apt-get install foo already knows how to fetch foo from the network and install, grabbing any required dependencies. I even hear you can use it with rpms these days. Michael
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 02:59:26PM +, Rob Partington wrote: > David Cantrell <[EMAIL PROTECTED]> writes: > > > Cos the 'special' install is a damned sight less hassle for most users than > > downloading 50 RPMs? > > Surely, then, rpm should have the ability to install and fetch > dependencies from the network automagically? Yes it should. It doesn't. Which is why Helix's installer is so much easier to use. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
In message <[EMAIL PROTECTED]>, David Cantrell <[EMAIL PROTECTED]> writes: > Cos the 'special' install is a damned sight less hassle for most users than > downloading 50 RPMs? If you want to download individual packages you can. Surely, then, rpm should have the ability to install and fetch dependencies from the network automagically? On OpenBSD (and possibly the other *BSD's, I know not), doing this: pkg_add ftp://ftp.plig.org/pub/OpenBSD/2.8/packages/i386/moo.tgz will not only ftp the file for me, but will check for dependencies and, if necessary, ftp and install those first. Much like CPAN.pm, except without the insane desire to install Perl5.6 at every opportunity. -- rob partington % [EMAIL PROTECTED] % http://lynx.browser.org/
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sat, Jan 13, 2001 at 02:04:15PM +, Steve Mynott wrote: > I would have prefered a short list of RPMs and FTP. Why should it > have a "special" install and why can't it install like everything else? Cos the 'special' install is a damned sight less hassle for most users than downloading 50 RPMs? If you want to download individual packages you can. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
David Cantrell <[EMAIL PROTECTED]> writes: > On Fri, Jan 12, 2001 at 02:46:34PM -0600, Paul Makepeace wrote: > > On Fri, Jan 12, 2001 at 08:28:25PM +, David Cantrell wrote: > > > lynx -source http://go-gnome.com/ | sh > > > > That's cute! > > It's more than cute. It's *BRILLIANT*. The user doesn't even have to > know what computer they have. Whilst they only support a couple of > combinations of architecture and OS in that script, it would be pretty > damned trivial to have it support a few Linux distros, Solaris, *BSD > and MacOS X. How do you resume your gnome download if your modem disconnects? How do you know how much data is being transfered and at what rate (whether you have time to make a tea or a three course meal). The FTP client I use tells me first and I don't what to use anything else. It's a pretty lame script which is dependent on the presence of lynx in order to download. This road ends with the distributor supplying their own lynx all to use one small feature of the program and leads to bloat. It also assumes that the lynx on the system has been correctly configured for firewalls and the like. I thought the Helix gnome install was one of the worse I ever saw -- they were trying to look like windows but hadn't done it properly by thinking about all possible error cases. I would have prefered a short list of RPMs and FTP. Why should it have a "special" install and why can't it install like everything else? -- 1024/D9C69DF9 steve mynott [EMAIL PROTECTED] "my watch with a black face .. has the date in a little hole in the face"
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, 12 Jan 2001, Aaron Trevena wrote: > On Fri, 12 Jan 2001, Paul Makepeace wrote: > > > On Fri, Jan 12, 2001 at 08:28:25PM +, David Cantrell wrote: > > > lynx -source http://go-gnome.com/ | sh > > that would rock. > > also what would be very valuable would be the ability to install from one > config for a cluster or synchronise config changes (using a version > control system of course). And some of the key API calls from NSAPI and ISAPI - as long as the I/O is replciated or aproximated in such a way as to easily port code then that would make a huge difference. A. -- http://termisoc.org/~betty"> Betty @ termisoc.org "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, 12 Jan 2001, Paul Makepeace wrote: > On Fri, Jan 12, 2001 at 08:28:25PM +, David Cantrell wrote: > > lynx -source http://go-gnome.com/ | sh that would rock. also what would be very valuable would be the ability to install from one config for a cluster or synchronise config changes (using a version control system of course). A. -- http://termisoc.org/~betty"> Betty @ termisoc.org "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, Jan 12, 2001 at 02:46:34PM -0600, Paul Makepeace wrote: > On Fri, Jan 12, 2001 at 08:28:25PM +, David Cantrell wrote: > > lynx -source http://go-gnome.com/ | sh > > That's cute! It's more than cute. It's *BRILLIANT*. The user doesn't even have to know what computer they have. Whilst they only support a couple of combinations of architecture and OS in that script, it would be pretty damned trivial to have it support a few Linux distros, Solaris, *BSD and MacOS X. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, Jan 12, 2001 at 08:28:25PM +, David Cantrell wrote: > lynx -source http://go-gnome.com/ | sh That's cute! If you wanted to use Perl; # `GET http://go-gnome.com` : ) Paul
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, Jan 12, 2001 at 07:06:00PM +, Steve Mynott wrote: > No you would want to build packages (.deb, .rpm and BSD and Solaris > packages) of rope for a "binary" type install as well as supplying a > "source" tar which works with make, make install. The installation method used by Helix is very nifty. lynx -source http://go-gnome.com/ | sh And that's it. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Any technology distinguishable from magic is insufficiently advanced
Re: Mailman in Perl (Re: the list is dead, long live the list)
Greg McCarroll <[EMAIL PROTECTED]> writes: > finally is it enough to simply tar.gz /usr/local/Rope and tag it > with the architecture details No you would want to build packages (.deb, .rpm and BSD and Solaris packages) of rope for a "binary" type install as well as supplying a "source" tar which works with make, make install. -- 1024/D9C69DF9 steve mynott [EMAIL PROTECTED] as far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality. --albert einstein
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, 12 Jan 2001, Greg McCarroll wrote: > what about the actual mechanics of putting rope together? i'm assuming > we'd create a /usr/local/Rope, build the latest stable perl in there, > then configure apache for mod_perl etc and install it under there as > well, the the other modules. A directory structure that is documented and standardised accross platforms would make life a little easier. > finally is it enough to simply tar.gz /usr/local/Rope and tag it > with the architecture details we need *secure* skeleton / sample applications (preferably configureed during installation or optionally not installed rather than use out of the box p/words and users like every CMS on the market ). > we would probably need some final install program to be run, that > would handle the local details of the system - such as what user > to run apache as Configuration. Decent configuration to cope with multiple virtual domains, specifying paths ffor core handlers, etc. Also good guide and documentation. So that A moderately good developer (not necessarily perl) can get the package and get started without spending 100 quid on ora books. (of course they ought to do that anyway but they shouldn't need to). A. -- http://termisoc.org/~betty"> Betty @ termisoc.org "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Fri, Jan 12, 2001 at 02:16:15PM +, Andy Wardley wrote: > Said I: > > In all fairness, I have to say that mailman is an *excellent* mailing > > list manager. > > Said David H. Adler: > > So why haven't you reimplemented it in perl? :) > > Are you sitting comfortably? :-) > > Because the tools aren't yet in place to allow me to do it > within a truly flexible and generic application framework. [snip lengthy discussion of how to do this] Ah. I won't bother trying, then. :-) dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ Also know as the first rule of finance: "Don't run out of money". - Tony Bowden
Re: Mailman in Perl (Re: the list is dead, long live the list)
* Aaron Trevena ([EMAIL PROTECTED]) wrote: > > Following the interest in rope/pope, etc perhaps it would be an idea for > some of the more perl / oss oriented companies in london (or wherever) to > agree to take part in the project on a semi official basis - much of what > the work that the london and UK companies do is replicated because of lack > of comunications and worry over company secrets and competition. > > If a handful of london companies can put together a press release saying > that they are supporting or backing the project with time, money, services > in lieu, etc then it would be a publicity coup and get the ball rolling. > the first thing they could offer to do is to host the final rpms/tar.gz's what about the actual mechanics of putting rope together? i'm assuming we'd create a /usr/local/Rope, build the latest stable perl in there, then configure apache for mod_perl etc and install it under there as well, the the other modules. finally is it enough to simply tar.gz /usr/local/Rope and tag it with the architecture details we would probably need some final install program to be run, that would handle the local details of the system - such as what user to run apache as comments? suggestions? -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Mailman in Perl (Re: the list is dead, long live the list)
Following the interest in rope/pope, etc perhaps it would be an idea for some of the more perl / oss oriented companies in london (or wherever) to agree to take part in the project on a semi official basis - much of what the work that the london and UK companies do is replicated because of lack of comunications and worry over company secrets and competition. If a handful of london companies can put together a press release saying that they are supporting or backing the project with time, money, services in lieu, etc then it would be a publicity coup and get the ball rolling. A. -- http://termisoc.org/~betty"> Betty @ termisoc.org "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Mailman in Perl (Re: the list is dead, long live the list)
> Said Andy Originally:
>
> > In all fairness, I have to say that mailman is an *excellent* mailing
> > list manager.
>
> Said David H. Adler:
>
> > So why haven't you reimplemented it in perl? :)
>
I would like to kill this thread (and suggest using mailman rather than
anything else) as
* We're lazy (which is a virtue)
* TMTOWTDI (and one of them is even python)
Meanwhile if anyone else wants to develop anything else then I suggest
they go ahead while we continue to use mailman, and use the list to
discuss what their plans are. I think Andy's plans sound great but are
not about to happen RSN. I'd be more than willing to help pitch in
myself, just point in the direction of the code[1]
Right. Nuff said.
Mark[2].
[1] Once I've got some more free time. Which should be when new people
start at work.
[2] Who hasn't contributed to the box, so shouldn't really get a say, but
would be more than happy to do so)
--
print "\n",map{my$a="\n"if(length$_>6);' 'x(36-length($_)/2)."$_\n$a"} (
Name => 'Mark Fowler',Title => 'Technology Developer' ,
Firm => 'Profero Ltd',Web => 'http://www.profero.com/' ,
Email => '[EMAIL PROTECTED]', Phone => '+44 (0) 20 7700 9960' )
Mailman in Perl (Re: the list is dead, long live the list)
Said I: > In all fairness, I have to say that mailman is an *excellent* mailing > list manager. Said David H. Adler: > So why haven't you reimplemented it in perl? :) Are you sitting comfortably? :-) Because the tools aren't yet in place to allow me to do it within a truly flexible and generic application framework. If I'm working to a plan (and that's not to say I necessarily am) then it goes something like this: Presentation: * Template Toolkit to allow presentation to be clearly separated from application / data. This is pretty much complete. Data: * XML::Schema to allow XML data types to be specified in a manner which can be "understood" and easily manipulated by various tools. With a standard representation for our data structures it becomes much easier to write tools like database abstraction layers, interface generators (for view, edit, etc), and so on, that do away with 90% of the tedious work in building such applications. This is the current work in progress (the XML::Schema part). Hopefully, we might inspire the various people working on DBA's like Alzabo, Tangram, etc., that this is a Good Thing and convince them to work together, or at least adapt their products to utilise a consistent schema representation so that their products can work together. Application logic: * Regular Perl is just fine for writing the business/application logic parts. Once you strip out the presentation and low level data manipulation parts, things often become quite simple. Framework: * Camelot (or AO, Pope, etc.) as a generic application framework to glue it all together. This should define high-level application service in terms of the other components. For example, the "mailman" service to display a subscriber list can be described in simple terms like: - extract the mailing list name from part of the URL (handled by a generic URL munging service) - go fetch the subscription list for this mailing list (handled by the data abstraction layer) - display it using templates. (handled by the presentation engine) Behold, in Crap ASCII Art[tm]: +--+ | Application | | (Service) | +--+ | +---+---+ | | | +--++--++--+ | Data || App. Logic || Presentation | |(Model) || (Controller) ||(View)| +--++--++--+ I'm of the opinion that re-writing mailman in Perl is something of a futile excercise until we can do it *significantly* better than it has already been done in Python. The only benefits I can see are that Perl hackers would be able to hack on it without having to learn Python, and we would be able to equalise this particular notch on the Perl vs Python scoring stick. I would like to see the Perl equivalent of mailman written as an application component. You should be able to add it to your current application framework by simply merging the mailman XML config into your server XML config. All the other services it relies on (data abstractions, MTA services, presentation tools, etc.) would be specified in the same way. Here's a *very* pseudo example trying to illustrate what I'm getting at: ... ... ... ... foo qmail tt-fancy The mailman_config.xml would define the individual nitty-gritty services that it offers, making calls against the DBA, MTA, presenters and so on. ... By defining it this way, it should be much easier for other applications / services to hook into the mailing list services that mailman provides. So if you want to build an application which merges an online FAQ system with a web bulletin board with a mailing list then you can do so with the minimum of fuss. I have to stop writing now. The nice men in the white coats tell me it's time for my medication. Hope that answers your rhetorical question :-) A -- Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated. <[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
