Re: CVS removal from the base
On Dec 4, 2011, at 7:42 PM, Julian Elischer wrote:
> On 12/4/11 3:36 PM, Randy Bush wrote:
>>> This seems too reasonable a suggestion, but, as always, the devil
>>> is in the details. There will be long. painful discussions (and
>>> arguments) about what to remove from the base to the new structure
>>> and what things currently NOT in the base should be promoted.
>> as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is
>> tempting. but, as you hint, is this not just doubling the number of
>> borders over which we can argue?
>>
>> but let's get concrete here.
>>
>> i suspect that my install pattern is similar to others
>> o custom install so i can split filesystems the way i prefer,
>> enabling net& ssh
>> o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
>> if it does not have emacs)
>> o hack /etc/ssh/sshd_conf to allow root with password
>> o rsync over ~root
>> o hack /etc/ssh/sshd_conf to allow root only without-password
>> o rsync over my standard /etc/foo (incl make.conf and src.conf)
>> and other gunk
>> o csup releng_X kernel, world, doc, ports
>> o build and install kernel and world
>>
>> and then do whatever is special for this particular system.
>>
>> anything which would lessen/simplify the above would be much
>> appreciated. anything not totally obiously wonderful which would
>> increase/complicate the above would not be appreciated.
>
> my suggestion is that the 'sysports' or 'foundation ports' or
> 'basic ports', (or whatever you want to call them) in their package
> form come with the standard install in fact I'd suggest that they
> get installed into some directory by default so that 'enabling' them
> ata later time doesn't even have to fetch them to do the pkg_add.
>
> They have pre-installed entries in /etc/defaults/rc.conf. and only their rc,d
> files need to beinstalled into /etc along with their program files.
> They are as close to being as they are now with the exception of
> being installed in the final step instead of at the same time as the rest of
> the stuff,
> and it allows them to easily be 'deinstalled' and replaced by newer versions.
I really don't understand how this is much different than having them exist in
base. We have WITHOU_foo (I don't really care if that were to become WITH_foo
if we want to default to a more minimum system), so one can always use ports if
they want some different version of foo. And it's not just releases we care
about, we want a stable foo (BIND for example) with security and bug fixes
throughout all updates to -stable, not just at releases.
I want to do one buildworld and have a complete and integrated system. I don't
see how having a separate repo for sysports helps; it is yet another thing I
have to track. And are ports in sysports going to default to being installed
in / or /usr/local?
--
DE___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
>>> BIND OTOH is something different. >> what's bind? :) > http://www.isc.org/software/bind see the smily? bind is not in my install set. if i need an on-system cache, i use unbound. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Le 05/12/2011 03:00, Randy Bush a écrit : BIND OTOH is something different. what's bind? :) http://www.isc.org/software/bind Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer wrote:
> On 12/4/11 3:36 PM, Randy Bush wrote:
> >
> > i suspect that my install pattern is similar to others
> >o custom install so i can split filesystems the way i prefer,
> > enabling net& ssh
> >o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
> > if it does not have emacs)
> >o hack /etc/ssh/sshd_conf to allow root with password
> >o rsync over ~root
> >o hack /etc/ssh/sshd_conf to allow root only without-password
> >o rsync over my standard /etc/foo (incl make.conf and src.conf)
> > and other gunk
> >o csup releng_X kernel, world, doc, ports
> >o build and install kernel and world
> >
> > and then do whatever is special for this particular system.
> >
> > anything which would lessen/simplify the above would be much
> > appreciated. anything not totally obiously wonderful which would
> > increase/complicate the above would not be appreciated.
>
> my suggestion is that the 'sysports' or 'foundation ports' or
> 'basic ports', (or whatever you want to call them) in their package
> form come with the standard install in fact I'd suggest that they
> get installed into some directory by default so that 'enabling' them
> ata later time doesn't even have to fetch them to do the pkg_add.
>
> They have pre-installed entries in /etc/defaults/rc.conf. and only
> their rc,d
> files need to beinstalled into /etc along with their program files.
> They are as close to being as they are now with the exception of
> being installed in the final step instead of at the same time as the
> rest of the stuff,
> and it allows them to easily be 'deinstalled' and replaced by newer
> versions.
>
> Some of them would come from the current system sources and some of
> them would be
> what are currently 'normal' ports but we consider them to be 'basic'
> and 'extra supported'
>
> Examples of the first type would be bind, sendmail, cvs, and examples
> of the second type would be perl, bash, maybe python, and possibly a
> very minimal set of the
> X11 packages.
>
> These are things we talk about having extra support for in the
> installer anyhow.
> I also suggest that said packages include a "plugin" for
> sysinstall/bsdinstall. so that it can ask its own
> quesitons during install.
A while back I had toyed with a config based approach. The
idea is you install a minimal system and then use one of the
predefined system configs to bring the system upto a desired
state. The same config will use your local script of the same
name if one exists, to allow for local modifications. The
same config (or an updated version) can be rerun after an
update.
Basically the idea is that you are dealing with a system as a
_whole_ for the purpose of install/update/convert/replicate.
You are capturing the "personality" or "metadata" of a system
a single file (it in turn relies on a small set of small text
files). This can be used for other purposes as well.
A config is essentially names of packages to install, variable
names, names of any pre/post external scripts to run, and
other included configs. But no executable logic here!
If this is used, a new release would also contain a repo for
every predefined script -- this makes it easy to see what
changed and deal with it.
Benefits:
- people can consistently customize their setup and keep
it so after an upgrade
- what is included in the "base system" becomes largely
irrelevant
- you can check/fix system personality at any time
- you can generate a local config easily
- can exactly replicate the same config on multiple machines
- can systematically change the personality of your system
- you can integrate this in sysinstall (and provide more
flexibility)
- you can define your own specialized configs for whatever
purpose.
To give you an idea:
syscfg install # install foo on a new installation
syscfg set # change existing (unconfigured) system to foo
syscfg convert # change existing (configured) system to bar
syscfg diff# compare local system against foo
syscfg [-f] check # check and optionally fix
syscfg update
You would need to tell it where to get its data (either a
released ISO or a site). Lot of details would have to be
worked out.
Unfortunately I don't get to use FreeBSD much these days @
work and my home setup doesn't change much.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
> BIND OTOH is something different. what's bind? :) randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Am 05.12.2011 um 00:36 schrieb Randy Bush: >> This seems too reasonable a suggestion, but, as always, the devil >> is in the details. There will be long. painful discussions (and >> arguments) about what to remove from the base to the new structure >> and what things currently NOT in the base should be promoted. > > as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is > tempting. but, as you hint, is this not just doubling the number of > borders over which we can argue? > > but let's get concrete here. > > i suspect that my install pattern is similar to others [] > and then do whatever is special for this particular system. > > anything which would lessen/simplify the above would be much > appreciated. anything not totally obiously wonderful which would > increase/complicate the above would not be appreciated. Most of that stuff should be solved by a configuration-management system - or (partly) by an automated installation. BTW: Does anybody have a link to some documentation how that (PXE-install etc.) is supposed to be done in 9.0? Personally, I don't think cvs should be removed any time soon: - it's AFAIK stable, doesn't change a lot - doesn't introduce vulnerabilities every other month - will be needed for some time for historic reasons BIND OTOH is something different. But even on the couple of servers we actually use BIND, we like to have a version that is supported over the lifetime of the FreeBSD system it's installed on. As has been said, FreeBSD (as of 8.2 - haven't had the chance to look into 9.0 a lot) is a nice system with a lot of functionality without installing lot's of packages. Just FYI: we use rubygem-chef for configuration-management, but we don't think it would be a good idea to have ruby in the base-system, even though we need it on every system anyway... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On 12/4/11 3:36 PM, Randy Bush wrote:
This seems too reasonable a suggestion, but, as always, the devil
is in the details. There will be long. painful discussions (and
arguments) about what to remove from the base to the new structure
and what things currently NOT in the base should be promoted.
as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is
tempting. but, as you hint, is this not just doubling the number of
borders over which we can argue?
but let's get concrete here.
i suspect that my install pattern is similar to others
o custom install so i can split filesystems the way i prefer,
enabling net& ssh
o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
if it does not have emacs)
o hack /etc/ssh/sshd_conf to allow root with password
o rsync over ~root
o hack /etc/ssh/sshd_conf to allow root only without-password
o rsync over my standard /etc/foo (incl make.conf and src.conf)
and other gunk
o csup releng_X kernel, world, doc, ports
o build and install kernel and world
and then do whatever is special for this particular system.
anything which would lessen/simplify the above would be much
appreciated. anything not totally obiously wonderful which would
increase/complicate the above would not be appreciated.
my suggestion is that the 'sysports' or 'foundation ports' or
'basic ports', (or whatever you want to call them) in their package
form come with the standard install in fact I'd suggest that they
get installed into some directory by default so that 'enabling' them
ata later time doesn't even have to fetch them to do the pkg_add.
They have pre-installed entries in /etc/defaults/rc.conf. and only
their rc,d
files need to beinstalled into /etc along with their program files.
They are as close to being as they are now with the exception of
being installed in the final step instead of at the same time as the
rest of the stuff,
and it allows them to easily be 'deinstalled' and replaced by newer
versions.
Some of them would come from the current system sources and some of
them would be
what are currently 'normal' ports but we consider them to be 'basic'
and 'extra supported'
Examples of the first type would be bind, sendmail, cvs, and examples
of the second type would be perl, bash, maybe python, and possibly a
very minimal set of the
X11 packages.
These are things we talk about having extra support for in the
installer anyhow.
I also suggest that said packages include a "plugin" for
sysinstall/bsdinstall. so that it can ask its own
quesitons during install.
randy
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
> This seems too reasonable a suggestion, but, as always, the devil
> is in the details. There will be long. painful discussions (and
> arguments) about what to remove from the base to the new structure
> and what things currently NOT in the base should be promoted.
as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is
tempting. but, as you hint, is this not just doubling the number of
borders over which we can argue?
but let's get concrete here.
i suspect that my install pattern is similar to others
o custom install so i can split filesystems the way i prefer,
enabling net & ssh
o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
if it does not have emacs)
o hack /etc/ssh/sshd_conf to allow root with password
o rsync over ~root
o hack /etc/ssh/sshd_conf to allow root only without-password
o rsync over my standard /etc/foo (incl make.conf and src.conf)
and other gunk
o csup releng_X kernel, world, doc, ports
o build and install kernel and world
and then do whatever is special for this particular system.
anything which would lessen/simplify the above would be much
appreciated. anything not totally obiously wonderful which would
increase/complicate the above would not be appreciated.
randy
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On 4. Dec 2011, at 18:07 , C. P. Ghost wrote: > On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin wrote: >> Christian Laursen wrote: >>> >>> [...] >>> >>> I use CVS myself from time to time, but I see no need for it to be in base >>> for that reason. >> >> By the way, since there is no way to count +/- I guess the rule "do not >> brake that is working >> or provide a way to do the same" should work. If there is a number of users >> of smth it should >> not be broken. csup/cvsup does not provide the same. > > Actually, a whole lot of stuff that was still perfectly useable has > been deprecated over the years. I'm thinking of net/freebsd-uucp > for example. Which is a good example as - to my memory - it needs cvs to build. Moving our CVS (and yes the base CVS has quite some modifications still I think) into ports would probably mean taking the CVS history and run into a chicken and egg problem;-) We'll need "our" CVS probably for another 2-3 years I think as some non-significant infrastructure will still depend on it even after docs and ports moved away from it. Some others have suggested things like "lpd" however which could probably go to ports as well as it's anther conflict these days for most people using cups or similar anyway. I can think of more but we shouldn't be overly eager either or we'll end up with a README in src/ saying "please install the following ports;-)" /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
on 02/12/2011 19:18 Attilio Rao said the following: > BTW, I'm waiting for the details to settle (including the patch we > have been discussing internally about binding to CPU0 during ACPI > shutdown) I do not see strong interdependency between that patch and the panic patch. BTW, I think that your patch is good to go. > before to read the whole thread and start a proper review, > would it be possible to have an almost-final version of the patch? It is still the same patch that Kostik posted a few weeks ago. I think that it is long overdue to be committed. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On Sun, Dec 4, 2011 at 1:22 PM, Doug Barton wrote: > On 12/4/2011 12:19 PM, Julian Elischer wrote: > >> I propose we create a companion directory to src in SVN and cal it >> "sysports" >> it uses the ports infrastructure in organization (though may be more >> hierarchical) >> but is populated with items that have come out of the 'src' tree. >> it is shipped along with src and revisioned WITH src. >> >> basically a privileged set of "primary" packages. >> both ports and src maintainers have access to them and they >> are tested as part of the release engineering process. > > Julian, > > You've proposed this before, and the more I've thought about it the more > I like it. :) In fact, the other day a bunch of us in #bsdports were > kicking it around and the idea was generally well received. (I think we > slightly preferred the category "system," but that's an implementation > detail.) > > My (personal) plan is to start pushing for this after the 9.0-RELEASE, > and after the ports repo svn conversion. That's one of the reasons that > I want to start socializing the idea now. > > In regards to having this new category be supported as part of the > release process, we've already received tentative support from the > release engineering team for the idea of having a small number of > critical packages on the install medium and offered to the user as > options at install time. So the seeds have been planted for this idea, > and I'm hoping to see it grow in the coming months. > > > Doug This seems too reasonable a suggestion, but, as always, the devil is in the details. There will be long. painful discussions (and arguments) about what to remove from the base to the new structure and what things currently NOT in the base should be promoted. As to what to name the new area, I vote for burnt orange with blue trim. Go Broncos! (American football for those out of the Estados Unidos.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
on 21/11/2011 18:58 Attilio Rao said the following: > I would be very in favor about having a 'thread trampoline for KDB', > thus that it can use locks. I keep hearing the suggestion to add this trampoline, but I admit that I do not understand its technical meaning in this context. And also how it helps with the locking. So I will appreciate an explanation! Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
on 02/12/2011 17:30 m...@freebsd.org said the following:
> On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote:
>> on 02/12/2011 06:36 John Baldwin said the following:
>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when
>>> kdb was
>>> active). But I think these two changes should cover critical_exit() ok.
>>>
>>
>> I attempted to start a discussion about this a few times already :-)
>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the
>> current definition) ? That is, skip all locks in the same fashion?
>> There are pros and contras.
>
> Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I
> can no longer remember...) when it enters? If so, then I'd say
> whether it enters via sysctl or panic doesn't matter. It's in a
> special environment where nothing else is running, which is what is
> needed for proper exploration of the machine (via breakpoint, for
> debugging a hang, etc).
>
> Maybe the question is, why wouldn't SCHEDULER_STOPPED be true
> regardless of how kdb is entered?
I think that the discussion that followed has clarified this point a bit.
SCHEDULER_STOPPED perhaps needs a better name :-) Currently it, the name,
reflects the state of the scheduler, but not why the scheduler is stopped and
not the greater state of the system ("in panic"), nor how we should handle that
state ("bypass locking"). So I'd love something like BYPASS_LOCKING_BECAUSE
_SCHEDULER_IS_STOPPED_IN_PANIC haven't it be so unwieldy :)
When the kdb_active is true the scheduler is stopped, true. But it is a
different kind of system state from which we potentially may want to continue
normal operation. So a lot more care is needed and simply bypassing locks is
probably not a solution. I guess that some day in the distant future we might
decide that a built-in debugger is for critical/abnormal situations only...
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On 12/4/2011 12:19 PM, Julian Elischer wrote: > I propose we create a companion directory to src in SVN and cal it > "sysports" > it uses the ports infrastructure in organization (though may be more > hierarchical) > but is populated with items that have come out of the 'src' tree. > it is shipped along with src and revisioned WITH src. > > basically a privileged set of "primary" packages. > both ports and src maintainers have access to them and they > are tested as part of the release engineering process. Julian, You've proposed this before, and the more I've thought about it the more I like it. :) In fact, the other day a bunch of us in #bsdports were kicking it around and the idea was generally well received. (I think we slightly preferred the category "system," but that's an implementation detail.) My (personal) plan is to start pushing for this after the 9.0-RELEASE, and after the ports repo svn conversion. That's one of the reasons that I want to start socializing the idea now. In regards to having this new category be supported as part of the release process, we've already received tentative support from the release engineering team for the idea of having a small number of critical packages on the install medium and offered to the user as options at install time. So the seeds have been planted for this idea, and I'm hoping to see it grow in the coming months. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: running old binaries on -current
On Sun, 4 Dec 2011 22:25:19 +0200 Kostik Belousov wrote: > Try to set sysctl security.bsd.map_at_zero to 1. I didn't even think of that. It helped, thanks :) -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpZ0f86AZ7Fv.pgp Description: PGP signature
Re: running old binaries on -current
On Sun, Dec 04, 2011 at 08:54:27PM +0100, Yamagi Burmeister wrote: > On Fri, 2 Jul 2010 21:44:26 +0300 > Kostik Belousov wrote: > > > On Fri, Jul 02, 2010 at 11:12:13AM -0700, Julian Elischer wrote: > > > every now and then, for fun I run up a chroot of freebsd 1.1. or 1.0 > > > under a chroot. Usually hillarity ensues with teh 15 second kernel > > > compile and the 4 minute make world. > > > > > > in -current I can't do that any more.. any binary just exits with 'Abort'. > > > > > > I think I last tried it in 7.0 or there abouts. > > > > > > I have options COMPAT_AOUT and COMPAT_FREEBSD4 through COMPAT_FREEBSD7 > > > > > > does anyone else have any ideas as to what may be needed? > > > > > > I vaguely remember another option but I am not seeing it at the moment. > > > > > > For those of you who do not remember, 1.0 had a.out static binaries only. > > > > > > > Can you ktrace/kdump the run attempt, I suspect that abort is > > sent by image activator. > > > > Also, please put some static binary somewhere to download. > > Hi, > digging around I found one of the first programs ever written. It's an > static aout binary from 1994 or so, running it on FreeBSD 8.2 shows > exactly this problem. Some more extensive tests narrowed this problem > down to FreeBSD 1.x binaries, they're all broken. FreeBSD 2 aout > binaries are still working. > Since Google found this rather old thread I decided to provide the data > your requested, but I do not insist on a fix. I guess that nobody will > try to run FreeBSD 1.x binaries these day... So if you want to spend > some work on this I'll test patches but if you decide to do nothing > it's okay. > > This is the /bin/sh of FreeBSD 1.0 (taken from the official > installation cd image f?r i386): > > % file sh > sh: VAX demand paged pure executable > > % ./sh > Abort > > The ktrace / kdump: > 1065 ktrace RET ktrace 0 > 1065 ktrace CALL execve(0xbfbfee1b,0xbfbfecf8,0xbfbfed00) > 1065 ktrace NAMI "./sh" > > I've uploaded the binary to: > http://deponie.yamagi.org/freebsd/tmp/sh_freebsd1 Try to set sysctl security.bsd.map_at_zero to 1. pgpg2AX8U5A4g.pgp Description: PGP signature
Re: CVS removal from the base
On 12/3/11 6:40 PM, Adrian Chadd wrote: The problem I have with all of this is pretty simple. With the CVS in base, it's treated like the (mostly) rest of the system in a stable release - ie, people don't simply keep updating it to the latest and greatest without some testing. If there are any critical bugs or security flaws, they're backported. The port isn't upgraded unless it has to be, and then if it's a major update, there are plenty of eyeballs to review it. It's in /src, after all. But with ports, the ports tree only has the "latest" version or two; sometimes a few major versions to choose from (eg apache), but we don't maintain the same kind of package versions that Linux operating system packages do. So it's entirely possible the "CVS" port maintainer updates the port to the latest and greatest, which works for him - and it breaks someone's older CVS repository somehow. I'd be happier with the idea of things moving into ports if the ports tree did have stable snapshots which had incremental patches for bug/security fixes, rather than "upgrade to whatever the port maintainer chooses." I'm all for change, but it seems those pushing forward change seem to be far exceeding the comfortable level of more conservative people; or those with real needs. Those who have relied on FreeBSD's stable release source tree being that - stable - whilst ports moves along with the latest and greatest as needed. It doesn't matter that you may do a fantastic job with a stable CVS port - what matters is how people perceive what you're doing. It just takes one perceived screwup here for the view to shift that "freebsd is going the way of linux". And then we lose a whole lot of what public "good" opinion FreeBSD has. ;-) I propose we create a companion directory to src in SVN and cal it "sysports" it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of "primary" packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. 2c, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: running old binaries on -current
On Fri, 2 Jul 2010 21:44:26 +0300 Kostik Belousov wrote: > On Fri, Jul 02, 2010 at 11:12:13AM -0700, Julian Elischer wrote: > > every now and then, for fun I run up a chroot of freebsd 1.1. or 1.0 > > under a chroot. Usually hillarity ensues with teh 15 second kernel > > compile and the 4 minute make world. > > > > in -current I can't do that any more.. any binary just exits with 'Abort'. > > > > I think I last tried it in 7.0 or there abouts. > > > > I have options COMPAT_AOUT and COMPAT_FREEBSD4 through COMPAT_FREEBSD7 > > > > does anyone else have any ideas as to what may be needed? > > > > I vaguely remember another option but I am not seeing it at the moment. > > > > For those of you who do not remember, 1.0 had a.out static binaries only. > > > > Can you ktrace/kdump the run attempt, I suspect that abort is > sent by image activator. > > Also, please put some static binary somewhere to download. Hi, digging around I found one of the first programs ever written. It's an static aout binary from 1994 or so, running it on FreeBSD 8.2 shows exactly this problem. Some more extensive tests narrowed this problem down to FreeBSD 1.x binaries, they're all broken. FreeBSD 2 aout binaries are still working. Since Google found this rather old thread I decided to provide the data your requested, but I do not insist on a fix. I guess that nobody will try to run FreeBSD 1.x binaries these day... So if you want to spend some work on this I'll test patches but if you decide to do nothing it's okay. This is the /bin/sh of FreeBSD 1.0 (taken from the official installation cd image für i386): % file sh sh: VAX demand paged pure executable % ./sh Abort The ktrace / kdump: 1065 ktrace RET ktrace 0 1065 ktrace CALL execve(0xbfbfee1b,0xbfbfecf8,0xbfbfed00) 1065 ktrace NAMI "./sh" I've uploaded the binary to: http://deponie.yamagi.org/freebsd/tmp/sh_freebsd1 Thanks, Yamagi -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpFSW9yOmz7a.pgp Description: PGP signature
Re: Third party apps in base [was CVS removal...]
On 12/3/11 11:02 AM, grarpamp wrote: Hi. I have many dependencies on CVS that I 'need' 'out of the box'. Yet at the same time, I would not mind at all if it went to ports. In fact, and from a general position regarding all third party apps, I encourage it. Mostly because they are not authored or maintained by FreeBSD. Yet they are integrated, often in ways that need work to remove and/or manage separately. Such as when the upstream drops a feature version and FreeBSD only drops security/stability patches. If a lighter method than ports is desired, all the third party apps have binary packages (/pub/FreeBSD/ports/packages/All). And even pkg_add can be skipped if that's too heavy. The bit of extra work at install time isn't much, especially when your install already does a bunch of scripted localization. I have advocated for some time that there be different classes of packages. "Primary" packages, which are guaranteed to be with the release or at most very near by, and secondary packages which are fetched separately. Primary packages would be maintained by the ports team, but would be tested and included by the release engineers as if they were part of the base system. There may even by room for other classes. And as an aside, with what to this writer seems to be the majority of the world moving to git... I think it should now properly become user/admin choice as to which to install from ports/packages/source. Rather than say, being equally agnostic/fair in the other direction by including them all to satisfy all whims. The only justified exception I see would be to include whichever one is used by the master repository itself, which today is SVN. And as a topic for another thread, I think even that should be switched to git within the next couple years. And as another topic for another thread... the same goes for the various current methods of source (and other) distribution of the FreeBSD project. I'd be quite happy to see rsync become authoritative and even replace all of them. Lastly, regarding baking and planning... making more use of the wiki to document the FreeBSD timeline would be interesting. While distant dates my not be known, features and dependancies usually are. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On Sat, 3 Dec 2011, Doug Barton wrote: On 12/3/2011 5:03 AM, sth...@nethelp.no wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards "If I use it, it must be the default and/or in the base" rather than seeing ports as part of the overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of "stays up basically forever", and in the sense of "changes to interfaces and commands are carefully thought through and not applied indiscriminately". For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. Agreed. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. So 2 things here that I really wish people would think about. 1. If you're using *any* ports/packages then you're already participating in the larger operating *system* that I described, so installing a few more won't hurt. (Seriously, it won't.) 2. In (the very few) areas where integration of 3rd party apps into the base makes sense, no problem. But at this point the fact that a lot of 3rd party stuff is changing more rapidly than it used to, and often in incompatible ways and/or at incompatible schedules with our release process, means that we have to re-think how we do this. You mentioned BIND, which is a great example of 2. above. I'll have more to say about this soon, but my plan is to remove it from the base for 10.x because the current situation is unmanageable. In my mind, your "2. above" is an example to keep BIND in the base. When I build FreeBSD from sources, I know that everything in src/ works together. I can update my system and be reasonably assured of that. However, updating ports is not at all like that. There is much more work involved in updating ports - you really need an extra test box to make sure that everything works together before updating the deployed system. One might argue that you need an extra test box even for updating src/ only, but in my experience it's not been nearly as necessary as updating ports. We don't have @ports resources for it, but in a perfect world there would be a ports branch for each supported FreeBSD branch. I would like security updates and bug fixes for ports, but not latest and greatest stuff. I like BIND in base (I won't argue against removing it, just stating my preference), and I would also like to see LDAP (at least client) in base. IMHO, FreeBSD base should include everything necessary to work in a networked environment. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin wrote: > Christian Laursen wrote: >> >> [...] >> >> I use CVS myself from time to time, but I see no need for it to be in base >> for that reason. > > By the way, since there is no way to count +/- I guess the rule "do not > brake that is working > or provide a way to do the same" should work. If there is a number of users > of smth it should > not be broken. csup/cvsup does not provide the same. Actually, a whole lot of stuff that was still perfectly useable has been deprecated over the years. I'm thinking of net/freebsd-uucp for example. Instead of moving all this functionality into ports, and therefore into a rather unstable moving target (how sure are we that the corresponding distfiles will stay available as long as /usr/src?), I'd have preferred that it be moved into a dedicated part of the base tree, e.g. /usr/old (or /usr/deprecated, or /usr/historic, /usr/vintage, whatever). Therefore, we could simply add /usr/old/bin to PATH, and link against /usr/old/lib, use headers from /usr/old/include, have the source in /usr/old/src, and so on. If you don't want to build the system with that, just add a knob in /usr/src.conf to exclude /usr/old. That's the kind of stable system I'd wish for FreeBSD instead of the current model or slowly eroding functionality and mysteriously disappearing utilities _and_ source code. > rik -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Christian Laursen wrote: [...] I use CVS myself from time to time, but I see no need for it to be in base for that reason. By the way, since there is no way to count +/- I guess the rule "do not brake that is working or provide a way to do the same" should work. If there is a number of users of smth it should not be broken. csup/cvsup does not provide the same. rik BTW. I think the bikeshed should be painted blue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC2 & make
04.12.2011 19:08, Vladislav V. Prodan wrote: > # /usr/bin/make > /usr/obj/usr/src/make.amd64/make: Permission denied > *** Error code 126 > > Stop in /usr/src. > Sorry. It's my fault, I put: -o setuid=off $poolname/usr/obj -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0-RC2 & make
core# uname -a FreeBSD core.domain.com 9.0-RC2 FreeBSD 9.0-RC2 #0: Sat Nov 12 18:35:25 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # /usr/bin/make /usr/obj/usr/src/make.amd64/make: Permission denied *** Error code 126 Stop in /usr/src. wtf? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9
On Sun, December 4, 2011 13:33, Alexander Motin wrote: > On 04.12.2011 04:46, Nenhum_de_Nos wrote: >> this port multiplier will work ok ? On Sil3124 and which others ? >> >> the tip on FreeNAS was great, but my main concern here is the sata hardware >> compatibility. I'd >> like to buy it knowing it will work :) > > Port multipliers supported by all siis(4) hardware and many mvs(4) and > ahci(4). In case of mvs(4) and ahci(4) support and effectiveness depends > on controller model. SiI3124 is known to be a good option. If > performance is not the first priority (150MB/s should be enough for home > NAS) -- SiI3132 and SiI3531 are also fine. 6Gbps Marvell 88SE91xx in > _non-RAID_ versions also good on tests, but there are not so many > reports about them yet. thanks for the info. I plan on not using hardware raid. will be Geom_(mirror/stripe) - as is now - or ZFS. I have sil3124 on PCI so far, and an older version that is being used on current file server: atapci1@pci0:0:9:0: class=0x010400 card=0x61141095 chip=0x31141095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SATALink/SATARaid Controller (Sil 3114)' class = mass storage subclass = RAID two years, always on and no issues so far. > I can't say for sure about ICH7 and NM10, but many Intel chipset > controllers support port multipliers when AHCI is enabled. I have > feeling that all of them support it in hardware (at least since ICH8), > but it is blocked by BIOS. At least I had motherboard that had and lost > port multipliers support after some BIOS update. You may see that info > in ahci(4) boot messages. Unluckily now Intel supports only > command-based switching, that allows only one device beyond port > multiplier execute commands at a time and significantly limits > performance. Controller support for more effective FIS-based switching > reported by ahci(4) and mvs(4) drivers during boot. All siis(4) > controllers support FIS-based switching. great info, I found some PCI-X and PCIe based sil3124 card that report FIS-compatible, but I can't find on my PCI version. By your saying, I get great news then :) I'll buy FIS-enabled PM :) I Plan on buying if needed a PCIe version of it, and if I find port multiplier for SATA 6Gbs, I will plan on one also. > Also note that not all controller BIOSes support detecting and booting > from devices on port multiplier, except one on the first port. Consider > that when choosing controller and partitioning disks if you are going to > boot from them. thanks again, but I plan on booting from onboard controller. The PM is intended on expanding capacity, and as is home file server, speed won't be a huge issue. If I can stream a high definition video twice, its ok. > Port multipliers themselves are quite simple from driver point of view, > so all of them should be supported if they follow standards. At least I > haven't seen reports yet that some one is not supported. What's about > reliability comparison -- I have no info. ok, I will do some testing when I receive it and plan to tell here results. thanks for all, matheus > -- > Alexander Motin > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Christian Laursen wrote: On 12/04/11 01:25, Doug Barton wrote: [snip] Replying to a somewhat random mail in this thread. Has anyone considerede that the people actually using CVS for getting the source might be somewhat overrepresented on freebsd-current? Probably you are right. I guess I would never use CVS if I wouldn't be a software developer and was not able to fix smth by my self. But as a developer I like to see the tool I got accustomed out of the box as it was to for many years. Especially after I've started to help to friends working in companies with restricted Internet access or detached systems. I've started to hate most of linux distributions since they do not have almost any tool for digging and solving problems. But with FreeBSD I even can solve the problem from my seat just giving instructions by phone or skype. rik If I had to guess, the average user is using either freebsd-update or csup (or even cvsup) to update a freshly installed system. Those that need the added flexibility provided by using CVS directly should be fully able to install it using pkg_add. Personally I pkg_add screen on new systems before doing anything else. I have never considered that a problem. I use CVS myself from time to time, but I see no need for it to be in base for that reason. BTW. I think the bikeshed should be painted blue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
I understand that this is not my business at all :) But anyway, IMHO, you should take GPL-free effort as an example. When you visit http://wiki.freebsd.org/GPLinBase you easily can see what going to be dumped, why, and with what it's going to be replaced. What I mean exactly - throw emails to mail list like this, telling that we need to specify software list for removal, provide page in wiki, with each software listed, propose something in exchange, collect not opinions, but real usage examples, and some stats, like "feature A is used by approx 100 peoples". Or "Feature B is used by 3 peoples, but there's no replace ATM". If you think it's time to move from CVS, create page in wiki, find most frequent use cases, think about replacing them with other tools, collaborate with peoples, create simple pro/con table with free editing. I'm sure that very few peoples, or even no one know _every_ usage of FreeBSD base, so deep investigating on each item is would be necessary. That's only my 2c. -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9
On 04.12.2011 04:46, Nenhum_de_Nos wrote: this port multiplier will work ok ? On Sil3124 and which others ? the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd like to buy it knowing it will work :) Port multipliers supported by all siis(4) hardware and many mvs(4) and ahci(4). In case of mvs(4) and ahci(4) support and effectiveness depends on controller model. SiI3124 is known to be a good option. If performance is not the first priority (150MB/s should be enough for home NAS) -- SiI3132 and SiI3531 are also fine. 6Gbps Marvell 88SE91xx in _non-RAID_ versions also good on tests, but there are not so many reports about them yet. I can't say for sure about ICH7 and NM10, but many Intel chipset controllers support port multipliers when AHCI is enabled. I have feeling that all of them support it in hardware (at least since ICH8), but it is blocked by BIOS. At least I had motherboard that had and lost port multipliers support after some BIOS update. You may see that info in ahci(4) boot messages. Unluckily now Intel supports only command-based switching, that allows only one device beyond port multiplier execute commands at a time and significantly limits performance. Controller support for more effective FIS-based switching reported by ahci(4) and mvs(4) drivers during boot. All siis(4) controllers support FIS-based switching. Also note that not all controller BIOSes support detecting and booting from devices on port multiplier, except one on the first port. Consider that when choosing controller and partitioning disks if you are going to boot from them. Port multipliers themselves are quite simple from driver point of view, so all of them should be supported if they follow standards. At least I haven't seen reports yet that some one is not supported. What's about reliability comparison -- I have no info. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On 12/04/11 01:25, Doug Barton wrote: [snip] Replying to a somewhat random mail in this thread. Has anyone considerede that the people actually using CVS for getting the source might be somewhat overrepresented on freebsd-current? If I had to guess, the average user is using either freebsd-update or csup (or even cvsup) to update a freshly installed system. Those that need the added flexibility provided by using CVS directly should be fully able to install it using pkg_add. Personally I pkg_add screen on new systems before doing anything else. I have never considered that a problem. I use CVS myself from time to time, but I see no need for it to be in base for that reason. BTW. I think the bikeshed should be painted blue. -- Christian Laursen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Jase Thew wrote:
On 03/12/2011 14:48, Roman Kurakin wrote:
Jase Thew wrote:
On 03/12/2011 09:21, Roman Kurakin wrote:
[SNIP]
You are right in general, except one small factor. We are talking
about
bootstrap.
CVS is used by many as the one of the ways to get the sources to the
freshly
installed system to recompile to the last available source. It will
become inconvenient
to do it through the process of installing some ports for that.
Especially if corresponding
ports would require some other ports as dependences.
As has been pointed out elsewhere in this thread, CVS doesn't cover
csup, a utility in base which allows you to obtain the source
trivially for the scenario you provide above. (Explicity ignoring
cvsup which requires a port).
Does csup allows to checkout a random version from local cvs mirror?
So better to say csup(cvsup) does not cover cvs.
Not quite sure what you are referring to by "random version". But csup
certainly allows you to obtain the source as described in your
scenario above ("last available source", even source at a particular
point in time).
By random version I mean any exact version I need, not only head of
branch or tag.
rik
Also, when I said CVS doesn't cover csup, I meant any removal of CVS
from base would still leave csup available for obtaining source.
Regards,
Jase.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Doug Barton wrote: On 12/3/2011 1:21 AM, Roman Kurakin wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards "If I use it, it must be the default and/or in the base" rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. You realize that you just 100% demonstrated the truth of what I wrote above, right? :) Don't you really think that one would protect smth that he/she not using? I hope no ;-) People (and me one of them) just try to protect smth they like in a system and they use. If you are ready to provide alternative the number of people against this change will decrease to smaller list that don't like change habits or use smth in much wider area. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? No. Usually base system is updated in a first turn. I even do not install pkgs usually. 2. If so, why is installing one more unthinkable? Sorry, but the previous answer was opposite. But despite of that, I do not like additional packages. I've started to use jails more often not only from a security issue, but also cause of the problems with upgrade. The more packages you have in the system - the harder to upgrade them if the last upgrade was not done recently. But this is the other story. 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? The amount of time you need to get and compile all the stuff. The first packages I usually install is the 'bash' and 'portupgrade'. I didn't ever count dependences for just two packages I need, but it is about 15-20 of them. I can do working system solving the most of needed task without both of them. And I do my job while they are installing (or better to say their dependences). If I need to fix some detached from the internet systems, I do not need to keep the set of packages for set of branches and for set of dependences just only sources, base system, my hands and my head. rik Thanks, Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
On 04/12/2011 09:08, sth...@nethelp.no wrote: It's not unthinkable. However, IMHO we're then gradually edging closer to various Linux distros that need lots of packages installed to do anything useful. And that, of course, brings up the question - why not just use Linux in the first place? For me, having FreeBSD as a "self contained" system with lots of useful functionality in the base system is one of the main reasons why I use FreeBSD. +1 -- Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
>From Mehmet Erol Sanliturk : > Supplying only a console-mode FreeBSD as a release is making FreeBSD > unusable for > peoples who they are not computing experts . > To allow less experienced people to use FreeBSD easily , it is necessary to > include a > selected ports/packages into release distributions , therefore into > so-called BASE as a > /ports or /packages part . > When a new FreeBSD release will be installed , it is becoming necessary to > install many packages additionally , and setting many parameters in the > *.conf , etc. , files to make it usable . One unfortunate situation is that > some packages are NOT working at the release moment . In the packages tree > , it seems that there is no any regular update policy for a specific > release . It is possible to "make port_name" , but this is NOT so much > usable also : For a specific package , which is installing within less > than 30 minutes by pkg_add , required more than eighteen hours by "make > ..." . Reason was that MAKE is an extremely STUPID system ( without BRAIN ) > because , it is NOT able to remember that it has completed making a package > part a few seconds before , and it is starting the same steps to apply up > to the point that it is not necessary to make it once more ( after applying > many steps which was applied before ) . On an old computer with 256 MB RAM, or less, building some of the bigger ports can take many hours. I never dared attempt to build KDE or GNOME! But I don't think PC-BSD runs with 256 MB RAM. In the recent past, FreeBSD releases offered extra iso images with packages, sysinstall even offered to install packages. I tried that once, with FreeBSD 7.0, or was it 7.1 or 6.2, and didn't really get a workable system. GNOME and KDE didn't work. When I tried portupgrading, I messed everything, went back to Linux (Slackware), and when FreeBSD 8.0 was released, cleaned out my old installation, and installed FreeBSD 8.0 fresh. Now, on a new computer, I still use icewm, haven't attempted KDE or GNOME yet. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
> I want to ask some serious questions here, because I genuinely want to > understand your thought process. > > 1. Do you install *any* ports/packages on a new system before you update > the source? Answering just for myself here... Going back a bit, in many cases I didn't need to install any packages. Nowadays as a minimum I install Perl. > 2. If so, why is installing one more unthinkable? It's not unthinkable. However, IMHO we're then gradually edging closer to various Linux distros that need lots of packages installed to do anything useful. And that, of course, brings up the question - why not just use Linux in the first place? For me, having FreeBSD as a "self contained" system with lots of useful functionality in the base system is one of the main reasons why I use FreeBSD. > 3. Why is it a problem if the port/package you need to install in the > early stages has dependencies? For me the dependency on other ports/packages, in itself, is not really a problem. I am much more worried about the fact that a FreeBSD release corresponds to one particular point in time, while the ports collection moves on - and that we'll end up with a FreeBSD release which is broken with the existing ports collection (but works with an earlier version). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9
On Sat, Dec 3, 2011 at 8:46 PM, Nenhum_de_Nos wrote: > > On Sun, December 4, 2011 00:32, Adrian Chadd wrote: >> Why not just run FreeNAS? > > thanks for the tip on FreeNAS, as others said too. > > will it run some other services, as http server for some stuff (wiki for > example), edonkey and > torrent clients, and some other stuff ? (I will visit the FreeNAS site and > try to figure out) > > although it would solve the problem on configuring the box, I still have the > doubts on the port > multiplier being usefull on it, as FreeNAS will end on FreeBSD :) > > this port multiplier will work ok ? On Sil3124 and which others ? > According to this web site, it should work with the Sil3124: http://www.addonics.com/products/ad5sapm.php Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
