Joerg Schilling wrote:
...
Let me add an example I came across last weekend:
in.dhcpd is present on OpenSolaris but it is unusable because of two
reasons:
- I cannot be configured by a simple configure scipt
but requires to use configurator programs instead.
These programs depend on Java that is not part of
OpenSolaris and not freely redistributable.
As a result, in.dhcpd on OpenSolaris is 100% unusable.
There is a redistribution clause in the license for the JRE - it perhaps
is not 100% compatible with the OpenSolaris terms to the point that you
could use it in Schillix, but that's something we probably need to get
Sun's lawyers to work out. It doesn't seem likely to me that we'd
prefer you not ship our JRE in Schillix.
- The configuration is so cryptic that I failed a fifth
time to understand it and it was another time that I
compiled and configured ISC dhcpd instead and configured
it within 2 minutes without even reading the man pages.
Sorry that it seems so difficult for you - many customers seem to work
with it pretty easily, and find the tools to be helpful. Each style of
configuration has its strengths and weaknesses, to be sure.
Well, I need to replace in.dhcpd from Sun by a working program which could be
ISC dhcpd. Unfortunately Sun's "add_install_client" and similar scripts
depend on Sun dhcpd....well, I could argue that "add_install_client" does not
work correctly for x86 systems and needs to be fixed anyway.
Well, we try to present an integrated experience among the pieces of the
system that we ship. In the recent past we've talked about abstracting
that interface such that it would be easy to plug in configuration of
other DHCP servers. Unfortunately, that's a little harder when, like
ISC, they don't provide any script or programmatic configuration
interfaces. But I'm sure we'd react positively to contributed changes
that moved us in that direction.
Dave
_______________________________________________
opensolaris-discuss mailing list
[email protected]
