<div dir="ltr"><div>Here are some ideas I've been thinking about for the next release.  3.6 came out in  late November, so we should aim for late May.</div><div><br></div><div>VM support: </div><div><br></div><div>- Getting run in a VM is more common; better drivers would help.</div>
<div>- There's a start on a network driver floating around.  Finishing that wouldn't hurt.  I'd like DragonFly to be able to work in a virtual environment with as little special configuration as possible.</div>

<div><br></div><div>pkg:</div><div><br></div><div>- pkg should work immediately upon install; right now it requires a copy of a sample file.<br></div><div>- We could use up to date notes on <a href="http://dragonflybsd.org" target="_blank">dragonflybsd.org</a> on running pkg.<br>

</div><div>- I've noticed some of the packages expect the 'service' command to be present; that probably isn't hard to bring over.</div><div><br></div><div>i386 support:<br></div><div><br></div><div>I think we're on the edge of where it can be dropped.  PC-BSD and FreeNAS are both dropping i386, for example.  My instinct - and this can certainly change - is to say the earliest we'll drop it is for the 4.0 release, which will hopefully also be the first user-testable version of Hammer 2.  That's two releases from now at the soonest.</div>

<div><br></div><div>PAM support:</div><div><br></div><div>ftigeot has been working on this with the most recent consensus being initrd support for setting up the dynamic and static binaries instead of the /rescue path that FreeBSD / NetBSD are using.  (What does OpenBSD do?  I don't know.)  It would also be good for the release, but it will need testing by people in the right sort of environment to test it out.  (that part I can do.)</div>
<div><br></div><div>I'm bringing these ideas up to get them out there; I can't do them all myself, but I'll certainly help out.</div><div><br></div><div><br></div>
<div><br></div><div><br></div></div>