Experiences with FreeBSD 9.0-BETA2

[Garrett Cooper]

On Mon, Sep 26, 2011 at 5:59 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
> Hi,
>
> On Mon, Sep 26, 2011 at 7:48 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
>> On Mon, 26 Sep 2011, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> 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
>>> uses.
>>
>> 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:
http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target
. 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.
Thanks,
-Garrett