From owner-freebsd-current@FreeBSD.ORG Sun Apr 11 08:14:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0205106566B; Sun, 11 Apr 2010 08:14:26 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87B9A8FC08; Sun, 11 Apr 2010 08:14:26 +0000 (UTC) Received: by gwaa12 with SMTP id a12so2593813gwa.13 for ; Sun, 11 Apr 2010 01:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Ccka2ZNchPIlkmSI78ui8ZNHlhgIw0zjku5O0IMAFW8=; b=Rd/e4NhE+4Gt3ktAC5pY8kFkaelPktrQTY2KX4g4DlaCXRJAXQLm+nHPN0enMUdgFS E/dwWueb1w/Ys/pGkCu6XhkET7Wd7LbBKSo8SaSUg37JCEsNIdgVyT8/8IqDmedF6gdR JSx4s42o+rrHtJVqH8vBgkO+xwuIqn7PpWvzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PgUFm635SzxnHMZ6YdajzbQy7qkXIIz0TzJTeY7DnR/o3idYsvw03dWfyuyZbonYLT j3sPkv0u3Mrfn3pBCKD7fQIpUOd/dlgq82OYMRMMKJssZLT4plCNqCcey0iHJLQxNlOh w9LXAUL0v1RaQ5gO0S1Dcvr78cKNyJ931difU= Received: by 10.151.2.5 with SMTP id e5mr2163598ybi.164.1270973665591; Sun, 11 Apr 2010 01:14:25 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 20sm2711854iwn.9.2010.04.11.01.14.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 01:14:24 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC184E0.8070901@elischer.org> Date: Sun, 11 Apr 2010 01:14:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> <4BC0AF62.9050600@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Kris Moore , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 08:14:27 -0000 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