<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>