Darren J Moffat wrote:
> Alan.M.Wright wrote:
>> Providing this as a temporary solution to relieve a customer problem
>> is excellent. My disagreement is that it should be committed as a
>> long term solution for offline support when we already have a defined
>> system attribute mechanism that could be used to solve the problem
>> via libc.
>
> Given the above I'm derailing this case for the purpose of writing an
> opinion with Advice to fund the above mentioned project and to point
> out the issue of adding Solaris/Sun functionality to Samba with no
> planned match for the in kernel CIFS server.
>
> PSARC members please are you willing to vote based on the above our
> would you like to see draft opinion text first. I've marked the case
> as "waiting need vote" for now.
>
> Note that this is *derail* not *deny* (though depending on the vote it
> could be but I doubt it).
>
I was the original +1. I would normally have thought to vote to
approve, but given the recent discussion, I'm not sure I am ready.
Since this solution to the problem is temporary, and since binary relief
is already available to the customer, I am inclined to vote to deny this
project until they have a solution that works with both kernel CIFS and
Samba.
On a higher level, as yet another case where we have redundant
functionality in two (or more) different systems, it seems like someone
(PAC) ought to start funding an effort to consider reducing the
complexity of the system by also reducing the number of duplicated
subsystems. (Do we need both of these SMB servers? Do we need a bunch
of different web servers? Do we need both cups and lpsched? Then the
array of various different packet interception and filtering mechanisms
in our stack boggles the mind... at what point does the fact that we
have so much choice actually become a liability to our customers rather
than a benefit? Its *clear* to me that it is already a liability in the
cost to Sun engineering....
-- Garrett
