Right now all of the Ethernet interfaces (serial servers, Web server) turn on immediately, and there's no way to stop them. This isn't ideal in situations where you have code that you're not sure is going to work: you'd like to make sure that you can change the code, try activating it, and if it doesn't work, that you can just upload new code with the Ethernet bootloader without having to use the forced Serial bootloader.
So the plan is to move to a service-based model, where the 'default' services are specified by a bitfield from the EEPROM. Then, when testing a new release, you can disable all of the running services except the Ethernet bootloader (and the web server if you don't have serial access), upload the new code, and then try enabling the new code to see if it breaks horribly. Then if it does, you can just reboot it (or power cycle it in the worst case) and upload new code using the Ethernet bootloader. If it doesn't, you can reactivate the default service state.
Right now all of the Ethernet interfaces (serial servers, Web server) turn on immediately, and there's no way to stop them. This isn't ideal in situations where you have code that you're not sure is going to work: you'd like to make sure that you can change the code, try activating it, and if it doesn't work, that you can just upload new code with the Ethernet bootloader without having to use the forced Serial bootloader.
So the plan is to move to a service-based model, where the 'default' services are specified by a bitfield from the EEPROM. Then, when testing a new release, you can disable all of the running services except the Ethernet bootloader (and the web server if you don't have serial access), upload the new code, and then try enabling the new code to see if it breaks horribly. Then if it does, you can just reboot it (or power cycle it in the worst case) and upload new code using the Ethernet bootloader. If it doesn't, you can reactivate the default service state.