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

91–100 of 175 posts

Re: Linux Namespaces and Go Don't Mix

#91

Post by klodolph »

jankedeen wrote: post #90
klodolph wrote: post #86

Earlier quoted context omitted.

Well, then allow me to cite the standard for you. > If a multi-threaded process calls fork() ... the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. IEEE Std 1003.1-2008, 2016 Edition http://pubs.opengroup.org/onlinepubs/9699919799/ I don't know about "design is broken". I personally think the fork()/exec() model is a clumsy way to create a new proce…

The preferred model with fork() in a thread is to exec as quickly as possible. Otherwise pthread_atfork can be prepared given adequate design: http://pubs.opengroup.org/onlinepubs/009695399/functions/pth... If you have work to do in the thread do these in the thread. If you must fork() then exec. Signal safety in pthreads can be handled generally via the pthread_sigmask|queue family. The corresponding facility in pro…

If you're having problems, please reach out to someone. This is not healthy behavior.

Re: Linux Namespaces and Go Don't Mix

#92

Post by stouset »

pritambaral wrote: post #61
ghthor wrote: post #45

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.

I think Go was designed as a server programming language more than a systems programming language.

Go was retconned into this role, but originally it was marketed as a systems language.

Re: Linux Namespaces and Go Don't Mix

#93

Post by SwellJoe »

jankedeen wrote: post #87
SwellJoe wrote: post #16

Earlier quoted context omitted.

I don't know, exactly, but I know with some confidence that C++ has never had significant uptake among ops and systems people. The folks who build systems, run systems, and dip into code on occasion to make the systems run, but not as their full-time job, have never (to my knowledge) fallen in love with C++. They probably all know some C, Perl, and Python...maybe not a lick of C++ (except the "C" part). I think C++ m…

Better C++ than Go or Rust. Antecedents and track record counts. Young people like the new thing. Go and Rust are capitalizing on that. Learn C. Take the time..it takes a couple years and some pain to learn it and then you will be amply rewarded. These languages (go|rust) are reactive and suffice for some purposes but they really kind of suck in every other possible way.

I'm old(ish), have worked professionally with C, and I think I have to disagree with you. Certainly, learn some C; it's the language on which all of our platforms are currently built.

But, building new things in C? Nah. I don't see any reason for that. Since C was designed, we've ("we" as in our industry, not specifically me and you) learned a lot and our systems have grown massively in all dimensions. It would be optimistic to assume we don't need different tools 40+ years on.

Re: Linux Namespaces and Go Don't Mix

#95

Post by inimino »

jankedeen wrote: post #81
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

At least in this thread, you're getting downvoted because you are being exceptionally rude, not because of any substantive criticism of Rust.

Re: Linux Namespaces and Go Don't Mix

#96

Post by brandon »

vbernat wrote: post #50
brandon wrote: post #43

Earlier quoted context omitted.

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.

The workaround functions by opening the privileged socket and re-executing the binary as an unprivileged user with access to the filehandle. Any background goroutines would exit with the privileged parent.

Also: please don't spawn goroutines during init(). There's generally a better time and place, and in the event that you justifiably need a package-level background routine you can spawn it on demand with a sync.Once.

Re: Linux Namespaces and Go Don't Mix

#97

Post by jpgvm »

pcwalton wrote: post #66
m0th87 wrote: post #17

Earlier quoted context omitted.

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…

It's harder for us, but I think we can get to an ergonomic solution with async/await. It's not as easy as threads (M:N vs 1:1 is a red herring as far as this is concerned), but there's no free lunch.

I hope the Rust team takes a look at Kotlins coroutines (and all the stuff they managed to build on top of them). I think Kotlin is a good example because it is built ontop of a 1:1 runtime and uses very elegant primitives.

I was pretty disappointed Rust didn't ship with async/await and some form of lightweight thread but it's understandable.

Re: Linux Namespaces and Go Don't Mix

#98

Post by wbl »

di4na wrote: post #72
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…

Just saying, but Erlang do not target that type of "System Programming" and the answer to that problem in Erlang would probably work through totally different way to do it. This namespace thing would not be a problem. This is not a problem of M:N. This is a problem of Go being badly designed. Not new.

It's a problem with Linux not permitting inspection of interfaces through a namespace. If I have a chroot I can look in from outside easily. Apparently not so with container interfaces.

Re: Linux Namespaces and Go Don't Mix

#99

Post by concede_pluto »

jankedeen wrote: post #81
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

> Can I not write a well designed and correct program in C?

We have decades of coredumps and exploits to convince us that nobody can. How many well-known apps can you name that have never blown up randomly? I can't think of a single one. How much more failure until it's reasonable to think that C requires an inhuman level of perfection and almost any alternative would be an improvement?

I hear good things about seL4 but that wasn't written so much as translated from Haskell during a formal process that makes Rust look like finger painting.

Re: Linux Namespaces and Go Don't Mix

#100

Post by eropple »

jankedeen wrote: post #81
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

I'm downvoting you for being profoundly shitty and mean, not because I disagree with you.

I do disagree with you, as it happens, but I'd downvote this sort of thing if I agreed too. There's a difference between bluntness being read as rudeness and what you're doing. Stop.

Post reply on HN