> Quoth "David Reid": > >> <snip> > >> > >> >Would be Nice To Haves > >> > > >> >- IPv6 > >> > >> I'm definitely interested in this, as well as a few other IP specs such as > >> bridging and tunneling using a few different methods(especially IPSec!). > >> I think BeOS already did NAT? > > > >Yes, but I think we need to look at that. It would be cool to add > >hooks/support for pf as well... > > Definitely some form of packet filtering. Is there a tcpdump for BeOS currently? BONE had tcpdump. I think if we're aiming for a list of utilities we should have, then I'd start with - netstat - ifconfig - tcpdump - ping(6) - telnet(6) - ssh (yes client as default) - nslookup (deprecated now in BIND) - dig - whois - host - hostname - tracert - route - arp - finger It'd also be nice to offer a range of daemons, via inetd, though with them all switched off by default I suspect - inetd - sshd - telnetd - ftpd - sendmail/postfix/some other mail app - dhcpd - named I don't think we even want to think about the r_ daemons (rlogin, rsh and so on) Perhaps we should also say we'll do ppp so we'd need -ppp -pppctl Anyone else intimidated by this list? Of course for most of these we get the network layer correct they can just be built with slight mods to allow for beos's differences in other areas :) > >> Now, I don't have a lot of experience with deep OS stuff, but wouldn't it > >be > >> possible to have a set of 'emulation' libraries or something, which could > >be > >> written on top of our OpenBeOS library in order to provide binary > >compatibility, > >> but still let us advance R1 in small ways? > > > >I guess so. I wouldn't be interested in writing them, but no doubt some > >other people in need of self flagellation will be. > > Fair enough. I suspect we'll get leaned on from the rest of the OpenBeOS > team to have binary compatibility, which is really the only reason I say it. :P I think we should aim for a kick ass network kit and then pander for backwards compatibility as a second priority :) david