Re: duprkit User Repository
- Date: Tue, 9 Apr 2019 00:42:25 +0000
- From: Mo Zhou <lumin@xxxxxxxxxx>
- Subject: Re: duprkit User Repository
On Mon, Apr 08, 2019 at 10:22:42AM -0400, Roberto C. Sánchez wrote:
> Two suggestions:
> - Stop claiming that what you propose is "zero-cost", "only 1 second of
> work", etc.*
And, I'm already tired of saying that again and again.
> - Find the individuals who currently experience the greatest pain
> associated with the problem you are trying to solve and whose pain is
> relieved by your solution. Get them to adopt it. If it works as well
/me. The packaging work for at least cudnn, bazel, pytorch, tensorflow
and their dependencies will stall if one targets on high quality and
policy-compliant work, because I believe they don't worth investing huge
amount of time to be made policy-compliant.
> as you say it does, they will be enthusiastic adopters and will have
> no problem telling others, in concrete terms, how much better your
> solution is than whatever the current situation is.
This idea, or the prototype, needs to be lucky enough to be properly
spreaded among the targeted users. However, if nobody believed in
the insight or the motivation, the idea has failed at the beginning.
> * Even in a perfect world, nothing is "zero-cost." To a community of
> contributors whose purpose it is to build an operating system
> distribution a deep understanding of the components that compose the
> system and the components used to build the system are effectively a
> requirement. Thus, if I came along and said, "here, I have a drop-in
> replacement for utility 'foo', and I call the replacement 'bar', and
> it supports all the same options as 'foo' so that you can use it
> without having to think about any differences" I would still expect
> that there would be a need for me to convince potential adopters that
> things really work that way. Experience tells us that even "drop in"
> replacements for things are seldom that "perfect" when it comes to
> compatibility with whatever they are replacing.
Fair enough. Since both traditional debian/ layout and the single-file
cruft are supported explicitly, I'll stop replying comments on preference.