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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
