Slashdot Mirror


User: dabplana

dabplana's activity in the archive.

Stories
0
Comments
2
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 2

  1. Potential for maliciousness... on Explaining WLAN Chips' Poor Linux Support · · Score: 1

    So I'm curious if the proliferation of 802.11g wireless cards is going to mean that the next "Code Red" style internet worm is, among other things, going to target the wireless networking drivers for these cards?

    Seems to me that thousands of infected laptops, all screaming at full power in the police band might cause a bit of problem for emergency services.

    Is anyone familiar enough with emergency services reliance upon wireless communication (and their relative tolerance for interference, which is going to vary based upon the technology they use) to confirm my fears or allow me to sleep a little easier at night?

  2. Re:flawed analogy on Software Aesthetics · · Score: 1

    True, I'll grant you that often, the internal systems of your car or house do not look "pretty" to the non-initiated. However, to a knowledgable repairman, much of the internals of the house and car are arranged in an obvious, maintainable manner.

    You probably wouldn't want to buy a car if you had to pull the engine to change the sparkplugs; you wouldn't want to tear out your freshly painted drywall in order to reset a circuit breaker. Yes, much of the wiring and plumbing within a house or car is hidden and inaccessible -- I'm not proposing that it all has to be beautiful. However, design engineers bend over backwards to make the internal portions that are subject to maintenance intuitive and available. Circuit breakers are sited in one location and given an access panel; sparkplugs are (usually) placed in some easily accessible location.

    I see software the same way. If you know that a piece of software will be subject to maintenance, write it in an obvious and straightforward manner.
    No, the end user won't appreciate your extra work and foresight, but the "mechanic" that has to perform maintenance on your code will appreciate it (even if that "mechanic" is YOU).

    The question then becomes "which portions of software will be subject to maintenance?" Unfortunately, in these times of malleable requirements, inconsistent approaches, and unforseeable changes, the answer is often "all of it."