Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Namespaces and Go Don't Mix

weave.works

Post reply on HN
Print view View original

41–50 of 175 posts

Re: Linux Namespaces and Go Don't Mix

#41

Post by geodel »

m0th87 wrote: post #17
pcwalton wrote: post #3

Earlier quoted context omitted.

No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…

This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics withou…

You can see for yourself [1]. Seems many users are not following the patterns of Async IO in Rust.

1. https://www.reddit.com/r/rust/comments/6enj5d/what_does_rust...

Re: Linux Namespaces and Go Don't Mix

#42

Post by holydude »

scriptkiddy wrote: post #28
holydude wrote: post #11

Earlier quoted context omitted.

Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now). Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actua…

> Yes but the problem with languages like Nim is lack of support and maturity. Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning. > Go is more versatile and at the same time more mature than anything out there. This is objectively i…

No it is absolutely fine to be enthusiastic about PLs. I enjoy reading about production ready Nim or Crystal apps :-)

Re: Linux Namespaces and Go Don't Mix

#43

Post by brandon »

liveoneggs wrote: post #37

this is just a more complex version of the issue where go can't safely do the daemonize dance for a privileged port

There's a simple-ish workaround for the privileged port issue if you can't just use CAP_NET_ADMIN: http://play.golang.org/p/dXBizm4xl3

The namespace issues are unfortunately a lot tougher to address.

Re: Linux Namespaces and Go Don't Mix

#44

Post by sqeaky »

zellyn wrote: post #8
scriptkiddy wrote: post #4

Earlier quoted context omitted.

> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowle…

> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.

Even then you don't know if program is correct. There have been pieces of software running in production for 20 or 30 only to fail because of some unforeseen and planned for error condition.

My favorite was the Comair christmas failure back in 2004 or 2005. I tried googling the root cause, but I think it was an Integer overflow in the 16 bit integer they used for storing the flight number. The system was designed in the mid 80s and 65535 flights was an insane amount, but but when the software failed on Christmas it interupted more than 1,100 flights.

Re: Linux Namespaces and Go Don't Mix

#45

Post by ghthor »

This is discouraging considering go was initially designed as a systems programming language. I wonder if there is another way for go to handle blocking syscall such that this use case would become reliable.

Re: Linux Namespaces and Go Don't Mix

#46

Post by lunixbochs »

vbernat wrote: post #18
SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

In Linux, many properties are task-related and therefore the API is also task-related. Namespaces are not the only problem. See for example https://github.com/golang/go/issues/1435 . The problem is Go runtime does not provide a way to exclusively lock a system thread from existing or future routines. Most other languages would work just fine (C or Python for example).

> The problem is Go runtime does not provide a way to exclusively lock a system thread from existing or future routines.

runtime.LockOSThread() does exactly that [1].

[1] https://golang.org/pkg/runtime/#LockOSThread

Re: Linux Namespaces and Go Don't Mix

#47

Post by zellyn »

sqeaky wrote: post #44
zellyn wrote: post #8

Earlier quoted context omitted.

> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.

Even then you don't know if program is correct. There have been pieces of software running in production for 20 or 30 only to fail because of some unforeseen and planned for error condition. My favorite was the Comair christmas failure back in 2004 or 2005. I tried googling the root cause, but I think it was an Integer overflow in the 16 bit integer they used for storing the flight number. The system was designed in…

This too is true in every programming language.

Re: Linux Namespaces and Go Don't Mix

#48

Post by vbernat »

lunixbochs wrote: post #46
vbernat wrote: post #18

Earlier quoted context omitted.

In Linux, many properties are task-related and therefore the API is also task-related. Namespaces are not the only problem. See for example https://github.com/golang/go/issues/1435 . The problem is Go runtime does not provide a way to exclusively lock a system thread from existing or future routines. Most other languages would work just fine (C or Python for example).

> The problem is Go runtime does not provide a way to exclusively lock a system thread from existing or future routines. runtime.LockOSThread() does exactly that [1]. [1] https://golang.org/pkg/runtime/#LockOSThread

No, it doesn't. Go runtime can decide to spawn a new thread from the locked one. The new thread will inherit the characteristics (namespace, uid) of the old one. See https://github.com/docker/libnetwork/issues/1113 for more details.

Re: Linux Namespaces and Go Don't Mix

#49

Post by zellyn »

scriptkiddy wrote: post #28
holydude wrote: post #11

Earlier quoted context omitted.

Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now). Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actua…

> Yes but the problem with languages like Nim is lack of support and maturity. Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning. > Go is more versatile and at the same time more mature than anything out there. This is objectively i…

It's more than fine to be enthusiastic about programming languages. However, some of your points about Go are dubious.

The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented.

I also don't believe Google's marketing budget contributed much if anything to supporting Go. The _reputation_ of Google and the Go authors was far more important. (Personally, when I saw people like Brad Fitzpatrick try Go and rave about it making programming fun again, I decided to try it.)

You can happily accuse me of shilling Go if you like :-)

Re: Linux Namespaces and Go Don't Mix

#50

Post by vbernat »

brandon wrote: post #43
liveoneggs wrote: post #37

this is just a more complex version of the issue where go can't safely do the daemonize dance for a privileged port

There's a simple-ish workaround for the privileged port issue if you can't just use CAP_NET_ADMIN: http://play.golang.org/p/dXBizm4xl3 The namespace issues are unfortunately a lot tougher to address.

It's only reliable if none of your dependencies are spawning goroutines during initialization. If this is the case, some goroutines (yours' or the dependencies') can end up with increased privileges.
Post reply on HN