ideas

[Matthew Dillon]

:..................................................................
:
:1) Please choose the complete and official project name: "DragonFly", 
:"DragonFly BSD" or "DragonFlyBSD" ?
:
:Browsing the website I see all of them and also "uname" is not what I've 
:expected.

    It's a matter of context.  For programming purposes we just use
    DragonFly.  E.g.  the compiler predef is __DragonFly__, not
    __DragonFlyBSD__.  Internally we just call it DragonFly.

    But for publishing and 'nametag' purposes... any situation where
    the target audience might not be familiar with what DragonFly
    is, we tend to stick the 'BSD' onto the end to make it more 
    clear.

:..................................................................
:
:2) I think that it could be a good idea to include a package with (src tree + 
:cvsup + cvsup.conf) in the ISO, so that you install it during the 
:installation process and then you are ready to update the src tree with 
:cvsup.

    No, this would put us in the same situation that FreeBSD is in,
    which is that the distribution is spread out over 4 CDs and getting
    everything together and properly tested for a release takes four
    times as long as it does for us.

    But there are several other very good reasons to not include packages
    (beyond the half dozen that the installer needs and things like cvsup),
    ports, and source on a release-CD... the reasons are: (*) Because the data
    becomes obsolete virtually the day after it is released and (*) Because
    these days anyone capable of downloading the ISO is also going to have
    sufficient network access to get the other pieces they want, (*) Because
    we have to be more careful about our download bandwidth resources.

:..................................................................
:
:3) I think that it could a good idea providing privacy by default, using 750 
:permissions for every user home directory.

   I think this is simply inherited from FreeBSD.  Real privacy is 700,
   though.  I wouldn't mind it if someone made that change to adduser.

:..................................................................
:
:4) If I'm not wrong DMA for CD drives is disabled by default. This means that 
:the installation from the CD takes more time than it could. I think that 
:setting somewhere in the installer sysctl hw.ata.atapi_dma="1" could improve 
:the CD drive throughput and reduce the time needed.

    As Joerg indicates, ATAPI DMA is fraught with compatibility issues and,
    besides, I really doubt that that turning on DMA would make the CD go
    any faster.  CD transfer rates (even on 50x drives) are quite slow and
    the real bottleneck is track seeking, which is ultra slow on any CD
    drive.

:..................................................................
:
:5) I've read that some developers are working on amd64 platform. If I'm not 
:wrong amd64 CPUs let you use the NX bit even in 32bit mode if they're used 
:via PAE. I think this could be a good way to introduce a memory protection 
:system, without waiting for a complete release for 64bit.

    It is our intention to use the NX bit on both 32 and 64 bit platforms.
    I don't know when it will happen, but it is definitely our intention.

    We will not be doing segment tricks to get stack execution protection on
    machines without NX, though.

:..................................................................
:
:6) I would strongly suggest to disable every network service by default.
:The better way is that the installer asks you what you want to enable (sshd, 
:sendmail, ...) and if you don't select anything because you don't know, your 
:box will be secure. Maybe.

    Well, I think sendmail defaults to localhost mode by default.  sshd should
    probably be turned off on the disk installation by default but as with
    a few other things on the CD we want it on for 'CD' boots to make it
    easier for a sysop to boot a CD, slap in a root password with passwd on
    the console, and login remotely via ssh.

:..................................................................
:
:7) Do you plan to use a different filesystem ID ?
:165 for FreeBSD, NetBSD, 386BSD
:166 for OpenBSD

    Probably not, though perhaps our extended disklabel structure warrents
    it.

:..................................................................
:
:8) Is there any plan to choose one packet filter as the official one ?
:PF, IPF or IPFW ?
:
:..................................................................
:
:Next time I'll write the rest ;-)
:
:	Ed

    We would like to consolidate on one packet filter, probably OpenBSD's.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>