Date: Thu, 21 Nov 1996 22:47:24 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: nik@blueberry.co.uk (Nik Clayton) Cc: msmith@atrad.adelaide.edu.au, davidn@sdev.usn.blaze.net.au, terry@lambert.org, roberto@keltia.freenix.fr, hackers@freebsd.org Subject: Re: Who needs Perl? We do! Message-ID: <199611211217.WAA13171@genesis.atrad.adelaide.edu.au> In-Reply-To: <Mutt.19961121110821.nik@blueberry.co.uk> from Nik Clayton at "Nov 21, 96 11:08:21 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Nik Clayton stands accused of saying: > Michael Smith writes: > > I'm entirely in agreement with the basic principle, but I strongly > > believe that we need to incorporate mature and ubiquitous tools in > > as seamless and standard a fashion as possible. > > Uh, /usr/ports? pkg_add? *snort* The ports/packages collection is fine as far as it goes, but you are still failing to understand what I'm on about. I'm talking about a _basic_system_service_, like the compiler or sendmail. > As far as I can see, FreeBSD currently has a few admin scripts written in > Perl (which someone in this thread has already volunteered to re-write > in C). And that's about the extent of it's requirement at the moment. What is this blinkered mentality that seems to think that the only purpose of a system component is to perpetuate the system? Is everyone disappearing inwards through their own navels? > If J. Random User wants to write a nifty adduser script (or whatever) in > Perl, then great. Even better, encourage them to submit it as a port > with a dependency on a particular Perl port. Great. Have you been watching the "CVSup is evil because it requires the monster Modula-3" thread resurfacing every few weeks? Do you have any idea how unwieldy the ports collection is if you don't have a (n outdated) copy handy on CDrom? I try to stay reasonably current at work, but got _seriously_ bitten this week with a rush to get a couple of notebook systems out the door for on-the-road demo systems; it's very hard to explain to an anxious sales jock that you have to download a pile of "oops just changed" distfiles from the other side of the planet so that they can deal with whatever printer the customer might have, or whatever. > Or punt Perl (and other niceties) into a 'recommended' distribution (or > something) and have the install say something like Having a "core binaries" distribution, which contained just enought to boot the system and operate the basic system services, and then putting everything else in the "basic system services" bundle (compiler, includes, interpreters, etc) would make sense. Drawing arbitrary lines based on the phase of the moon just doesn't cut it. If you like, I am respectfully offering the gauntlet to the anti-bloatists, and suggesting that they nominate what they feel to be the core of the system, and then do something about it. > If you're new to Unix then you may want to look at the > 'recommended-software' distribution. This is a collection of > software pre-compiled that you will probably find immediately > useful. Completely the wrong way around. The _advanced_ user should be offered the opportunity to _not_ install these things. The "default installation" should provide all the services that can be reasonably and _manageably_ be provided. (This is a key requirement, and is why I am trying to publically finger people to maintain the proposed Perl.) We _do_ need to address the "kitchen sink" issue, and we need a solution to handle _both_ the 'with' and 'without' cases. > And if you really know what you're doing, you're probably already > running 'ncftp ftp.perl.com/perl/latest.tar.gz' over in another > virtual terminal. No. What you want is to be able to say "I can write my Excellent New Application in Perl and know that it can be installed on any 'normally' configured FreeBSD system without significant user grief." What we're talking about is making it _easier_ to work with FreeBSD from positions other than the arrogant myopic power-user's point of view. > This man page describes the contents of the 'recommended' distribution, > with pointers on how to get more information about it. Yuck. Maybe a shellscript (installed when the "core binaries" are) that writes a message to stderr (and maybe calls 'logger' too) linked in place of all the binaries containd in the "basic system services" distribution, observing that said distribution is required. > Create a ports/recommended (or something) category into which stable versions > of software go. ports/lang/perl might be at version 5.4 (fictitious example) > but ports/recommended/perl stays at version 5.003 (or whatever) until > everything else that depends on perl in the 'recommended' category has been > re-written to work with the new version (assuming any re-writing is > necessary). Aside from a camouflaged 'anti-bloat' stance, you're not actually saying much new. There's nothing significantly different from the 'contrib' model there, except that it's extra work to install. > Thoughts. Appreciated, even if I don't agree with you. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611211217.WAA13171>