Re: D-Link: incompetent or evil?
- From: jpd <read_the_sig@xxxxxxxxxxxxxxxxxxxxxx>
- Date: 11 Apr 2006 00:35:22 GMT
Begin <zdB_f.6130$Ce4.390@xxxxxxxxxxxxxxxx>
On 2006-04-10, Rick Jones <rick.jones2@xxxxxx> wrote:
Has anything suggested that the D-link kit involved in this situation
would stop "just working" if it never reached an NTP server?
As I read it, it's only one in a list of servers. Meaning that if it
can't reach one it'll just pick another. Shutting down all is not likely
to be feasible.
Thus remains the core of the problem that d-link allowed their gear
to be shipped with a hard-coded list of servers that they don't own,
resulting in theft of service through violating the conditions set for
use. What is worse, the grief it is causing to one such server and the
community it serves can not be easily remedied even if d-link made an
effort to try, which they're clearly failing to even contemplate.
IANAL but if there was the muscle to force them to heel, I'd expect a
choice of firmware upgrades or a recall, maybe backed by penalties to
give them some incentive to get on with it. Possibly with replacement,
but that is something for d-link to work out with their customers.
[snip!]
That test still requires "thinking" about the big picture.
But it doesn't require nearly as much imagining esoteric faillure modes
caused by chains of interdependent systems as it might seem. Using the
old trick of carving out ``models'' and making them individually solid
in design goes a long way to prevent nastyness.
One such model is making a distinction between ``things we control'' and
``things we don't control but use anyway''. You can't always avoid the
latter, think of the list of root name servers, but that doesn't mean
you should do so with abandon.
Perhaps I'm reading too much into the word "test" but I think of that
as something one runs against the "thing to be tested" that returns an
indication of passing or failing. At least initially the pass/fail
requires not expenditure of thought by a human being.
In the design stage, one has to ask ``what does this depend on?''.
For an appliance (especially one intended to be sold by the million)
that looks to other hosts on the network for certain services, ease of
updating the list of possible other hosts to query is desirable. Any
hardcoded lists are clearly failing the test of ``can we easily change
this data it depends on, when deployed?'' A list of servers found by
looking up, say, timepool.d-link.com would pass the same test.
I don't know what is worse: allowing the former to pass the test, or
never asking the question at all. Either way, it indicates serious
trouble in d-link's design process. Not to mention the glaring faillure
to take responsibility by d-link's management now that it has become
clear d-link's actions are causing grief to other persons. Whatever
their attorneys say.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
.
- References:
- D-Link: incompetent or evil?
- From: Torfinn Ingolfsen
- Re: D-Link: incompetent or evil?
- From: Philip Paeps
- Re: D-Link: incompetent or evil?
- From: Rick Jones
- Re: D-Link: incompetent or evil?
- From: Philip Paeps
- Re: D-Link: incompetent or evil?
- From: Rick Jones
- D-Link: incompetent or evil?
- Prev by Date: Re: D-Link: incompetent or evil?
- Next by Date: FreeBSD 4.11 - TCP Simultaneous open
- Previous by thread: Re: D-Link: incompetent or evil?
- Next by thread: Re: D-Link: incompetent or evil?
- Index(es):
Relevant Pages
|
