Joel Aelwyn <[EMAIL PROTECTED]> writes: > Fine, if you want to get pedantic, the following is a bare minimum of > capabilities I would expect from any network processing on a 'real' > (non-toy) network stack, where 'network stack' means everything between > hardware driver and delivery of data to a userland application. It's late, > so this may not be exhaustive.
The guidelines do not speak of "toy os". It appears that you are not aware of why this requirement is listed in the guidelines, nor of why it would be important for the secondary archive, nor of what the actual practice is on buildds. Can we replace this with a thread involving people who do know these things? The Hurd has had all the things listed on your schedule of filtering rules for longer than Linux has. All that is necessary is simple user-space tools to implement them. Do you have a specific tool that should run, or anything else? > Unless marked as 'nice to have', everything above is a *must* for running > even basic firewall configurations on a host expected to face the Internet. > If you can do those, and configure them in some semi-sane fashion, then > you probably meet the expectations reasonable people would have for "basic > firewalling". But what is not said here is why this particular feature is necessary for being in the secondary archive, as opposed to other features. To say, "a buildd must have that feature" is only sensible if the buildds are actually *using* such-and-such feature, and you, in fact, don't know that they are. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
