Re: ports and PBIs

On 4/10/10 10:06 PM, Garrett Cooper wrote:


> It's more than just diskspace though. Consider the fact that now
> you're going to lose a lot of the memory sharing between shared libs
> and what-not, and now you'd have to be running N number of daemons .
> Take PCBSD for instance -- do they really revision packages with
> unshared dependencies, or are all of the dependencies updated at once?
> This becomes a big issue as you can't have dissimilar applications
> like dbus, gamin, openssh, etc running on the same system at one time.
> How does the PBI layout plan to deal with this kind of conflict --
> apart from jails, which would greatly increase the required
> footprint...?


It's a pitty that you didn't read the original post where it was 
stated that doing this would depend on a scheme that is under 
discussion for common components to be shared WHEN POSSIBLE.

>
>> If you can do this with package code, Maybe you will supply the packages..
>
> Not quite sure what you meant here.

I meant. get involved and do some of the work if you can see such an 
easy answer.

>> why?
>> As people have said before.. embedded folks usually want to compile
>> everyrthing for themselves anyhow.
>
> Not necessarily. You have folks in embedded rolling their own stuff,
> sure, but then you have groups like Montavista (now owned by Cavium
> Networks) repackaging Linux for customers, providing a nominal fee for
> the packages, support, and the tools, and there are large companies
> (like Cisco) buying into this. It's not to say that people are going
> to not roll their own solution, but many [intelligent] folks are going
> towards an externally supported model instead of rolling their own
> stuff. Thus, whatever the community decides is sane is what gets
> adopted (unless the developers or management for the group are really
> foolhardy / ignorant of what exists in the outside world, they're
> steeped in existing methods that can't be easily transitioned to the
> new model, or they have expendable resources to toss towards a custom
> solution for specific needs).
>
> If you guys think PBIs are so great... tell ya what -- make me and
> other folks believers:
>
You know young fellow, your attitude is kind of annoying for a
topic that is just up for discussion.

> 1. Produce a port with the magic PBI producing tool.

I hope to be able to do this soon.

> 2. Produce directions on how to use said tool.

the goal is:
cd /usr/ports/misc/cowsay (or whereever cowsay is)
make pbi

> 3. Make sure said tool and install method doesn't conflict with what
> exists in base.

PBIs already don't conflict. Hav eyou ever tried PC-BSD?

> 4. Capture statistics of how many people download this stuff and use

well we would start with the number of people using PC-BSD
because if we did this they would use our stuff.


> 5. Come back when you have data proving how many people care for your
> solution so portmgr and core can make an informed decision on whether
> or not it should be a part of base.

that's not how it's ever worked and I doubt it's going to start now.

>
> Oh, and think about this too: whoever produces the tool, eats the
> support costs.


> The project shouldn't eat the support costs until it's
> a part of base, if that ever happens. Definitely take this point into
> consideration because good support is not only `my package/port/PBI is
> broken .. help me!' -- it's also having QA engineers on hand and
> staffed to validate that the packages or PBIs are valid and functional
> -- in the very least from a DoA / smoke test perspective. I realize
> that this is lacking in packages / ports today, but it's something
> that many folks volunteering in the project (cross-functional in bugs
> area and also in ports) have wanted for a long time.

Sorry, but you've really pissed me off and as most people will tell 
you. that's not easy to do.

This all has the ring of a desperate person looking for excuses to 
complain about something.

Every thing you have mentioned occurred to those of us having the 
original discussion in about the oh, say FIRST 10 SECONDS of
the conversation.

Might I suggest that when you have been in the project another decade 
or so you might learn some manners and stop trying to teach you 
grandmother to suck eggs.

If you are trying to tell me about project dynamics or how things
work of need to work I put it to you that I've been doing this when 
you were about minus 10 years old. I do Not need a lecture from a wet 
behind the ears puppy about how I should handle a discussion with
interested parties on possibly improving FreeBSD's user experience.

When you were born I was decoding network traces.
When you were giving you mother heart attacks by eating the crayons
I was writing disk and network drivers for BSD and
long haul protocols.
When you were learning to read I was playing with the MACH
VM system and kerle build process.
When you were learning to do multiplication of small numbers I
trying to forget the Windows NT internals classes I had been sent to.

Do you think we are so stupid that we didn't take all the points you 
bring up in the "that's a given" starting point. There is twenty years 
of history behind what we are talking about. Do you think that PBIs 
just appeared without thought? Do you really believe I'm proposing 
something without already having discussed it with people
and thought about it from many angles?

p.s. Hi to all the old gang at Ironport

Julian

>
> Thanks,
> -Garrett