Experiences with FreeBSD 9.0-BETA2
yanegomi at gmail.com
Tue Sep 27 01:11:28 UTC 2011
On Mon, Sep 26, 2011 at 5:59 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
> On Mon, Sep 26, 2011 at 7:48 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
>> On Mon, 26 Sep 2011, Arnaud Lacombe wrote:
>>> On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass <brett at lariat.net> wrote:
>>>> My personal preference would be to place portions of the directory tree
>>>> which contain critical configuration information and are not written in
>>>> normal use -- e.g. /etc and /boot --
>>> The problem with /boot on a dedicated partition is the the kernel,
>>> since at least 8.x, is installed by default with a vast majority of
>>> crap. That's all the .symbols, that 99% of FreeBSD users will never
>> My recollection is that this is because kensmith forgot to take 'makeoptions
>> DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a
>> couple of releases in, at which point it seemed consistent with POLA to just
>> keep it there. Unfortunately I am not having much luck digging through mail
>> archives trying to confirm that.
>> I don't remember whether the plan was to turn it off on stable/9 or not.
>>> Beside that, the auto-partitionner refuses to work on <1G drive, which
>>> is really ridiculous...
>>> FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out.
>> Can you even buy a spinning disk less than 50GB these days?
> The storage world is not limited to spinning hardware. Take a 512MB
> CF, put it in a soekris box, and you got an embedded system capable of
> doing a whole bunch of stuff.
> Now, FreeBSD may no longer want to target such "niche" usage.
>> If you have hardware of that nature, you are almost certainly going to want
>> to customize other aspects of the system (and if it's an under-provisioned
>> system, are you really going to be doing this customization in-place?), at
>> which point removing the extra stuff is minimal extra work. If a developer
>> has to ask a user to do something (e.g. compile) in order to debug
>> something, there is a huge hit in the response rate; having the symbols
>> available in the general case can be helpful.
> Then why don't you provide symbols for the whole system, including
> binaries and libraries ? At least be consistent in your argument...
> And, yes, I have patches for that.
For embedded this doesn't make sense with limited storage -- but
that's what binutils enables:
. I've linked against debug symbols when doing debugging with gdb and
I can definitely attest to the fact that it's convenient and works
well when trying to produce tiny embedded images.
More information about the freebsd-current