[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-discuss
Subject:    Re: [osol-discuss] self-compilenced software
From:       Mike Meyer <mwm () mired ! org>
Date:       2008-07-27 16:07:56
Message-ID: 20080727120756.3a7c891b () bhuda ! mired ! org
[Download RAW message or body]

On Sun, 27 Jul 2008 13:47:08 +1000 (EST)
Andre van Eyssen <andre@purplecow.org> wrote:

> On Thu, 24 Jul 2008, Mike Meyer wrote:
> 
> > On Thu, 24 Jul 2008 13:52:55 +1000 (EST)
> 
> > getting more prevalent all along. Users on a machine that runs
> > production servers? Who'd put their servers at risk that way? Forcing
> > large numbers of users from different organizations to share a
> > machine? Nah, you put one (or more) on each desk, and have
> > departmental or even lower level servers for shared
> > resources.
> 
> Sunray and other thin clients squeeze a lot of users onto a shared 
> machine. Hosts used by developers squeeze a lot of users onto one machine. 
> SSGD and Citrix appservers squeeze a lot of users onto one machine.
> 
> Also, when I say "users", I mean "people logging in interactively". That 
> includes DBAs, junior admins, people handling care and feeding of 
> applications, not just sysadmins. On a larger platform, there might be 
> six sysadmins, three DBAs, and six application guys who use the host 
> frequently. There might be a couple of different releases of Oracle, a few 
> different directory trees for application servers and if this is a 
> development host, a mountain of odd software stacked up.
> 
> Life is hard enough without considering how you're going to manage three 
> Java releases, four Oracle releases and two compilers living in /usr/bin.

Your last comment is a straw man, as they almost certainly belong in
/opt/bin. But even on large projects, these days the norm is that you
have more machines than users. Making all those users sort out which
PATHs they should be using on which machine - or worse yet, for which
project on which machine - is much worse than having to deal with a
few extra virtualized environments.

> > So in dealing with servers, whereas before a typical user would have
> > to deal with one or two machines that served lots of other users and
> > functions, so that sorting things out on the machines made lots of
> > sense and wasn't to bad for the user, these days you have lots of
> > machines - some virtual - that each serve a few functions, so sorting
> > things into different areas on the machines doesn't really serve much
> > of a purpose, and makes for lots more work for the users.
> 
> It's happening. In some places. There are still a lot of deployments out 
> there with large servers doing a lot and not using zones. There's a lot of 
> Solaris 8 and Solaris 9 out there in the real world, and a lot of packages 
> are built to a Solaris 8 or 9 target to ensure compatibility with 
> everything required.

So your argument is that we need to make life harder for people who
are leveraging this millenniums technology in order to coddle those
who haven't are still using last millenniums technology?

> > Actually, forcing things into the the same directory helps deal with 
> > some of the naming issues. I.e. - I have a gnu tool set available that I 
> > need *sometimes*. If they had kept their original names and gone into a 
> > private directory, I'd have to use the full path name to get to them 
> > (with the subdir thrown in for grins). Since they all just had a 'g' 
> > prefixed to the name to deal with the name collisions, I can get to them 
> > by simply typing that one extra letter. Much easier.
> Yep, prefacing the GNU tools with g helps keep them seperate and out of 
> the way. But it means that things that expect a GNU version of those tools 
> need to be modified to look for "gawk" instead of "awk", whereas one could 
> have just changed the PATH if they had the same names. Swings and 
> roundabouts.

Only if you think there's no difference between right and wrong -
answers, that is.

Both require a bit of porting to get said application working outside
it's native environment. By tweaking the name, you fix it so that if
it can't find the right version, it breaks. If you require users to
have the right PATH, then all they have to do is get it wrong (and
you're the one pushing for a more convoluted PATH!) and they've
suddenly undone the port. If they're lucky, it'll break in an obvious
way (if they're *really* lucky, it won't matter); if not, it'll just
quietly produce the wrong answers.

I won't even talk about the case where you want a pipeline to include
two tools, one of which wants "awk" to be gnu awk, and one of which
wants it to be the BSD version.....

   <mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]