I'd try to do the same thing, just at the interface level, like the
kernel does. Eg, preadv2 as described at https://lwn.net/Articles/670231/
--dave
On 26/12/17 11:42 AM, Fabien wrote:
Thank you, lots of food for thought. For the go package-writer, now, I
guess the best practice so as not
I'd try to do the same thing, just at the interface level, like the
kernel does. Eg, preadv2 as described at https://lwn.net/Articles/670231/
--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
Thank you, lots of food for thought. For the go package-writer, now, I
guess the best practice so as not to be part of the problem is to
1- in minor revisions, of course, keep backward-compatibility.
2- in major revisions, either:
- make a new project, for instance, if my first project was
Lots of in-line reply-bits (;-))
On Tuesday, December 26, 2017 at 8:58:47 AM UTC-5, Fabien wrote:
>
> Thank you, that's a very interesting read.
>
> TLDR: If I understood everything, NP-complete != DLL hell, but anyway, go
> is vulnerable to DLL hell, so we're screwed.
>
> I'm not sure I
Thank you, that's a very interesting read.
TLDR: If I understood everything, NP-complete != DLL hell, but anyway, go
is vulnerable to DLL hell, so we're screwed.
I'm not sure I understand everything, though. Both your article and Russ
Cox' you mention seem to confuse NP-completeness and the
>
>
> A bit of an unresolved problem in several universes, one of which contains
Go (;-))
I have some definite opinions: I grew up in a universe where it was
resoilved in Multics, rediscoverd in Solaris and independantly rediscovered
in Linux glibc. Way more information that you want in
