I read the issue, and am unclear as to why a plug-in wouldn’t support your use
case?
> On Feb 26, 2019, at 6:19 PM, cos.pip...@gmail.com wrote:
>
> Has this been finally decided or is there still room to save this feature?
>
> We have invested all last year building an SDK (industrial
Has this been finally decided or is there still room to save this feature?
We have invested all last year building an SDK (industrial automation for
oil and pharma) we have two customer on a paying beta agreement.
Many have spoken to this rather common scenario to protect IP (no, plugins
do
I feel like I should stress this a bit more, because it's really
important:
It is under no circumstances reasonable to rely on lack of source code
for security. History has taught us time and time again that security
through obscurity doesn't work, and home grown/custom algorithms are
usually
On Tue, Jan 22, 2019 at 1:06 PM Wei Tang wrote:
>
> Well, I do think Binary-only packages are very important for some security
> case, such as authentication algorithm in a private enterprise。
I would not recommend using them in that way. A binary package should
be thought of as a slightly
Well, I do think Binary-only packages are very important for some security
case, such as authentication algorithm in a private enterprise。
在 2018年10月19日星期五 UTC+8上午1:16:43，Russ Cox写道：
>
> The go command supports "binary-only packages", in which
> the compiled .a file is installed in GOROOT/pkg
Well, I do need it that in our company, I need to provide the
binary-package to other developers to protect my source code.
在 2018年10月19日星期五 UTC+8上午8:13:01，Tharaneedharan Vilwanathan写道：
>
> Hi Ian,
>
> Good question. I don't have an answer.
>
> But this raises some questions:
>
> Should Go be
On 10/19/18, Ian Lance Taylor wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this? Is anybody seriously
>>> thinking about it?
>>
>>
On 10/19/18, Ian Lance Taylor wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this? Is anybody seriously
>>> thinking about it?
>>
>>
Thanks. I have a better understanding of the situation after reading the
reference.
Sent from my iPhone
> On Oct 23, 2018, at 4:53 PM, Ian Lance Taylor wrote:
>
>> On Tue, Oct 23, 2018 at 2:11 PM, Robert Engels wrote:
>>
>> So are there any plans for security patches for prior versions
On Tue, Oct 23, 2018 at 2:11 PM, Robert Engels wrote:
>
> So are there any plans for security patches for prior versions shipped as an
> updated shared library?
>
> Given the amount of code in the std it seems this would be almost a
> requirement - if Go apps are released in the wild in binary
So are there any plans for security patches for prior versions shipped as an
updated shared library?
Given the amount of code in the std it seems this would be almost a requirement
- if Go apps are released in the wild in binary form (e.g Linux tools)
Sent from my iPhone
> On Oct 23, 2018, at
On Mon, Oct 22, 2018 at 8:53 PM, Robert Engels wrote:
>
> Wait... you can ship a Go binary that dynamically links with the Go runtime
> and stdlib at runtime??? Awesome. Can you point me to the docs on this. I’ve
> always considered the “single binary” taunted feature as somewhat of a
>
Is there documentation on how to do this, or was I misunderstanding your
answer? Thanks.
> On Oct 22, 2018, at 10:53 PM, Robert Engels wrote:
>
> Wait... you can ship a Go binary that dynamically links with the Go runtime
> and stdlib at runtime??? Awesome. Can you point me to the docs on
Wait... you can ship a Go binary that dynamically links with the Go runtime and
stdlib at runtime??? Awesome. Can you point me to the docs on this. I’ve always
considered the “single binary” taunted feature as somewhat of a limitation
because of this.
> On Oct 22, 2018, at 9:41 PM, Ian Lance
On Mon, Oct 22, 2018 at 7:18 PM, robert engels wrote:
>
> I think there is a bigger concern than shipping binaries. I believe that the
> Go stdlib and runtime should be shipped as a shared library, and be field
> upgradable independent of the binaries. This is the only reasonable way to
> to
I think there is a bigger concern than shipping binaries. I believe that the Go
stdlib and runtime should be shipped as a shared library, and be field
upgradable independent of the binaries. This is the only reasonable way to to
distribute security patches in an efficient and stable manner.
I think Binary-only packages are very important for Go's Eco, something
like maven(Java) & sbt(scala)
- all it's dep packages should save in the same repo, together, like a
snapshot, or similar concept like docker image
- use a manifest file to list all the dep package's name and version
On Monday, 22 October 2018 07:17:57 UTC+2, Ian Lance Taylor wrote:
>
> On Sat, Oct 20, 2018 at 1:26 PM, jclc via golang-nuts
> > wrote:
> >
> > Currently I don't use them, but couldn't binary packages be used to
> > distribute CGO-dependent packages for developers who might not have a C
> >
On Sat, Oct 20, 2018 at 1:26 PM, jclc via golang-nuts
wrote:
>
> Currently I don't use them, but couldn't binary packages be used to
> distribute CGO-dependent packages for developers who might not have a C
> cross-compiler? I think the feature would be more commonly used if it wasn't
> so
Currently I don't use them, but couldn't binary packages be used to
distribute CGO-dependent packages for developers who might not have a C
cross-compiler? I think the feature would be more commonly used if it
wasn't so impractical. Rather than abandoning the feature I'd like to see
it
Hallo,
On Fri, Oct 19, 2018 at 11:45:04AM -0700, Ian Lance Taylor wrote:
> > Unhelpfully, I imagine it unlikely that anyone distributing binary go
> > packages reads golang-dev or golang-nuts.
>
> Is there a more likely place to reach such people?
I believe the best ways to reach attention on
Hi dharani,
I don't think the bigger questions about end products or services are so
much implied by the question.
BOPs are just one form of binary that have some problems for users and
maintainenance, and there are workarounds to supplying a package with
binary dependencies that don't
On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer wrote:
>
> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote:
>>
>> The question is: is anybody actually doing this? Is anybody seriously
>> thinking about it?
>
> Unhelpfully, I imagine it unlikely that anyone distributing
On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote:
>
> The question is: is anybody actually doing this? Is anybody seriously
> thinking about it?
>
> Ian
>
Unhelpfully, I imagine it unlikely that anyone distributing binary go
packages reads golang-dev or golang-nuts.
I'd say it's a useful feature, but not in it 's current form. I rather than
dropping the featture I'd like to see it enhanced so so it works as well as
a pascal .unit file does as a binary package for a high level language.
This also points to a solution as well, have a .gobin file that is an
Sorry, I did not mean to hijack the discussion.
To summarize our answer on Russ's question - in a current form Go's binary
packages are not useful for our team.
Thanks,
Andrey
On Thursday, October 18, 2018 at 2:15:57 PM UTC-6, Ian Lance Taylor wrote:
>
> On Thu, Oct 18, 2018 at 1:10 PM,
Providing a plugin (I prefer a separate binary called through rpc, but the
native .so is ok, too) is not a solution?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
Hi Ian,
Good question. I don't have an answer.
But this raises some questions:
Should Go be anticipating many such possibilities today and tomorrow? Or
shut them off?
With this limitation, doesn't it look like Go is best suited for building
end products or service but one cannot build on top
In the past (C/C++ days) we used a lot of third-party binary-only packages
like SmartHeap for memory management and LeadTools for imaging. (I like to
think of that as the "Programmer's Paradise" era.) I haven't used
binary-only packages in many years, but I do wonder how a company like
On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan
wrote:
>
> This means source-code is the only way to share the work. When it companies
> to sharing/selling their work on top of which others can build their
> app/solution, this won't work. Doesn't this seem like a big restriction?
>
Hi Ian,
Thanks for the clarification!
This means source-code is the only way to share the work. When it companies
to sharing/selling their work on top of which others can build their
app/solution, this won't work. Doesn't this seem like a big restriction?
Particularly, computer industry being
On Thu, Oct 18, 2018 at 2:20 PM, Tharaneedharan Vilwanathan
wrote:
>
> If this happens, by design, Go will not allow, say, a middleware company to
> provide binary only distribution?
Yes. There would be no way to for a company to provide a binary-only
package to its users. They would have to
Hi All,
I have a quick question. I hope I am not off topic.
If this happens, by design, Go will not allow, say, a middleware company to
provide binary only distribution?
Regards
dharani
On Thu, Oct 18, 2018 at 1:15 PM Ian Lance Taylor wrote:
> On Thu, Oct 18, 2018 at 1:10 PM, Andrey
Hello,
I have to agree that binary packages In the current form are not very
useful, at least to us. We have played with an idea of having sqlite (C + a
Go wrapper on top) wrapped up into a binary package, so we can continue to
build multiple platforms from a single build machine. As result of
34 matches
Mail list logo
