5 ms·

Three New Open Source Container Utilities

74 points by insulanian 9y ago

ajdlinux 9y ago
I'm as much a member of the Rust Evangelism Strike Force as everyone else here on HN, but "(written in Rust)" ain't in the article title.
- tovacinni 9y ago
  It's hackernews clickbait for sure :p
- conradk 9y ago
  Probably because Smith (1 of the 3 tools) is written in Go and because Oracle wouldn't use Rust just for the sake of using Rust but because it was suited to the task at hand. edit: you might be interested in their article on "Building a Container Runtime in Rust" [1] [1] https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run...
  - pjmlp 9y ago
    With that we have now Microsoft and Oracle adopting Rust based tools. Even if Rust fails to gain wide adoption, their ideas already tainted (in a very positive way) future work on the design of Swift, Pony, D and C++ lifetime static analyzers. Also on Go side, Microsoft being a Docker contributor regarding its support on Azure and VS Code tooling. Which I find very positive for both communities as a language geek.
joseluisq 9y ago
I transcribe the following: "Go is a poor choice of language for a container runtime," Abrams wrote in a blog post." Go is a great language, but for small system utilities that need tight control over threads and make a high volume of syscalls, there are better options." Is this true ?
- sanatgersappa 9y ago
  Not sure about that, but Oracle is a poor choice as a source of open source tools, given their history.
  - joseluisq 9y ago
    Right, especially its famous MySQL "Community"...
  - praneshp 9y ago
    The author was one of the heaviest early contributors on the Openstack project.
    - reitanqild 9y ago
      Sadly whatever open source work a person does while working for Oracle seems to be tainted by it: It might be successful but if the name Oracle shows up I am scared.
  - Veratyr 9y ago
    How is this relevant to the question raised by the person you're replying to? You've raised an entirely different concern and ignored the question. Why did you post this as a reply rather than a top level comment?
- solidsnack9000 9y ago
  Abrams is the author of the Go Netlink library, and participates in an interesting conversation here: https://news.ycombinator.com/item?id=14470231 https://news.ycombinator.com/item?id=14470231 (as `vishvananda`, it's the top comment). Many of the things the commenters discuss there are intricate. It's a lot of people who've worked on container runtimes and the issues relate to the interaction of Go with POSIX process and thread semantics. Go is not really intended to have transparent, finely controlled integration with C systems stuff...while Rust is.
- deleted 9y ago
  [deleted]
turingbook 9y ago
This is the technical blog from the tool author: https://blogs.oracle.com/developers/three-new-open-source-container-utilities https://blogs.oracle.com/developers/three-new-open-source-co...
Illniyar 9y ago
Open source or not, I'll do my best tp avoid any product by oracle. They have shown to value short-term profit above both community and even PR, which makes using their products an uneasy gamble for me.
- jsmthrowaway 9y ago
  They're all Apache 2, which is about as permissively decoupled from the organization as it gets. Oracle could disappear tomorrow, delete all the repos, or begin charging $5,000/seat for this software, and nothing would happen. You could, literally, fork all three, rename them, and run off on your own projects and have a merry 'ole time. In fact, everyone going after Oracle in this thread should do exactly that right now.
  - Illniyar 9y ago
    You are right in theory, however it's very rare for abandoned or mishandled OSS projects to gain new life by forking. Most of the knowledge, expertise and incentives are tightly coupled with the original creators. Also, open source license doesn't cover patents, so they could decide to sue for patent infringement, which I don't thunk is likely, but if there ever was a company that might try something like that it's oracle.
    - jsmthrowaway 9y ago
      > Also, open source license doesn't cover patents http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0 http://en.swpat.org/wiki/Patent_clauses_in_software_licences... The patent assignment and retaliation clause, in Apache 2.0 §3, is one of the key reasons to use it. Your hypothetical would not happen. > however it's very rare for abandoned or mishandled OSS projects to gain new life by forking. Given the counterexamples that have sprung to life from Oracle's behavior in the past (MariaDB, Jenkins), I find this a very odd observation in this thread.
      - Illniyar 9y ago
jondubois 9y ago
What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists. I really don't buy it that Go is a poor choice but that Rust isn't. If they had used C/C++, then the argument would sound more compelling. I think that Oracle has forever tarnished its open source credentials. These days Oracle is synonymous with vendor lock-in which is the antithesis of open source. I think they would have had more success if they had done the announcement anonymously.
- jsmthrowaway 9y ago
  > What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists. Competition is a good thing overall, particularly when it is a corporation with a lot of resources putting some of them to creating an alternative. The alternatives to Docker have made them improve drastically. Uncharitably, this observation sounds like it's colored by your opinion of Oracle more than the structure itself: what if Google put out these three tools? I also strongly condemn a world where people are discouraged from exploring new approaches because something else, often something that a commenter happens to like, exists. Trust the market to speak. > I really don't buy it that Go is a poor choice but that Rust isn't. They're not selling it, WeaveWorks is, and the specific (legitimate) issue has been extensively debugged on go-nuts and elsewhere: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... It's dark corners of hardware and low-level APIs where Go suffers. Platform-heavy concepts in C often translate more readily to Rust than Go, but that's not a knock of any language -- just different targets. I've been down the syscall/C ABI/etc path in Go, and most of that stuff (oddly, given that the stdlib exercises it) feels bolted on to the language as an afterthought. Rust, OTOH, intentionally sailed the "C But Better" tack. Interop between C and Rust is quite pleasant, and that is the gateway drug to all sorts of hardware-heavy tricks that really exercise a language. The same tricks in Go tend to surface weird stuff like the aforementioned issue. That being said, generalizing to an indictment of Go as a language for this use case is flawed. That first sentence under Railcar could use some work.
  - 9y ago
conradk 9y ago
It's unclear to me what this offers that runc or rkt do not offer. They say this : > railcar always runs an init process separately from the container process What does that mean in terms of day to day operations/debugging ? What are the benefits ?
- rndmio 9y ago
  One thing it means is no zombies in the process table. When you're running something like squid in a container and you HUP it to reload the config (volume mounted) without something to reap the old process you're going to have zombies.
- vishvananda 9y ago
  Author here. For more discussion on init handling you may find my article on pid namespaces[1] enlightening. In terms of differences from runc, there aren't many. The goals for railcar are threefold: 1: provide an alternative implementation of the oci-runtime so that the spec doesn't become too locked to a single implementation. 2: provide an implementation in a single language without some of the "baggage" of the existing implentations so that it is easy and fun to hack on. 3: experiment with new ideas to inform the future of the oci-runtime spec. [1] https://hackernoon.com/the-curious-case-of-pid-namespaces-1ce86b6bc900 https://hackernoon.com/the-curious-case-of-pid-namespaces-1c...
vishvananda 9y ago
Author here. This hit hacker news in the middle of the night for me. I'm happy to answer any questions if anyone is still lurking.
insulanian 9y ago
Having read the comments here about Go not being suited for the low level stuff, I really wonder why did the designers of Go think it would be THE replacement for C/C++?

74 points by insulanian 9y ago

I'm as much a member of the Rust Evangelism Strike Force as everyone else here on HN, but "(written in Rust)" ain't in the article title.

tovacinni 9y ago
It's hackernews clickbait for sure :p
conradk 9y ago
Probably because Smith (1 of the 3 tools) is written in Go and because Oracle wouldn't use Rust just for the sake of using Rust but because it was suited to the task at hand. edit: you might be interested in their article on "Building a Container Runtime in Rust" [1] [1] https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run...
- pjmlp 9y ago
  With that we have now Microsoft and Oracle adopting Rust based tools. Even if Rust fails to gain wide adoption, their ideas already tainted (in a very positive way) future work on the design of Swift, Pony, D and C++ lifetime static analyzers. Also on Go side, Microsoft being a Docker contributor regarding its support on Azure and VS Code tooling. Which I find very positive for both communities as a language geek.

joseluisq 9y ago

I transcribe the following: "Go is a poor choice of language for a container runtime," Abrams wrote in a blog post." Go is a great language, but for small system utilities that need tight control over threads and make a high volume of syscalls, there are better options." Is this true ?

sanatgersappa 9y ago
Not sure about that, but Oracle is a poor choice as a source of open source tools, given their history.
- joseluisq 9y ago
  Right, especially its famous MySQL "Community"...
- praneshp 9y ago
  The author was one of the heaviest early contributors on the Openstack project.
  - reitanqild 9y ago
    Sadly whatever open source work a person does while working for Oracle seems to be tainted by it: It might be successful but if the name Oracle shows up I am scared.
- Veratyr 9y ago
  How is this relevant to the question raised by the person you're replying to? You've raised an entirely different concern and ignored the question. Why did you post this as a reply rather than a top level comment?
solidsnack9000 9y ago
Abrams is the author of the Go Netlink library, and participates in an interesting conversation here: https://news.ycombinator.com/item?id=14470231 https://news.ycombinator.com/item?id=14470231 (as `vishvananda`, it's the top comment). Many of the things the commenters discuss there are intricate. It's a lot of people who've worked on container runtimes and the issues relate to the interaction of Go with POSIX process and thread semantics. Go is not really intended to have transparent, finely controlled integration with C systems stuff...while Rust is.
deleted 9y ago
[deleted]

turingbook 9y ago

This is the technical blog from the tool author: https://blogs.oracle.com/developers/three-new-open-source-container-utilities https://blogs.oracle.com/developers/three-new-open-source-co...

Illniyar 9y ago

Open source or not, I'll do my best tp avoid any product by oracle. They have shown to value short-term profit above both community and even PR, which makes using their products an uneasy gamble for me.

jsmthrowaway 9y ago
They're all Apache 2, which is about as permissively decoupled from the organization as it gets. Oracle could disappear tomorrow, delete all the repos, or begin charging $5,000/seat for this software, and nothing would happen. You could, literally, fork all three, rename them, and run off on your own projects and have a merry 'ole time. In fact, everyone going after Oracle in this thread should do exactly that right now.
- Illniyar 9y ago
  You are right in theory, however it's very rare for abandoned or mishandled OSS projects to gain new life by forking. Most of the knowledge, expertise and incentives are tightly coupled with the original creators. Also, open source license doesn't cover patents, so they could decide to sue for patent infringement, which I don't thunk is likely, but if there ever was a company that might try something like that it's oracle.
  - jsmthrowaway 9y ago
    > Also, open source license doesn't cover patents http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0 http://en.swpat.org/wiki/Patent_clauses_in_software_licences... The patent assignment and retaliation clause, in Apache 2.0 §3, is one of the key reasons to use it. Your hypothetical would not happen. > however it's very rare for abandoned or mishandled OSS projects to gain new life by forking. Given the counterexamples that have sprung to life from Oracle's behavior in the past (MariaDB, Jenkins), I find this a very odd observation in this thread.
    - Illniyar 9y ago

jondubois 9y ago

What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists. I really don't buy it that Go is a poor choice but that Rust isn't. If they had used C/C++, then the argument would sound more compelling. I think that Oracle has forever tarnished its open source credentials. These days Oracle is synonymous with vendor lock-in which is the antithesis of open source. I think they would have had more success if they had done the announcement anonymously.

jsmthrowaway 9y ago
> What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists. Competition is a good thing overall, particularly when it is a corporation with a lot of resources putting some of them to creating an alternative. The alternatives to Docker have made them improve drastically. Uncharitably, this observation sounds like it's colored by your opinion of Oracle more than the structure itself: what if Google put out these three tools? I also strongly condemn a world where people are discouraged from exploring new approaches because something else, often something that a commenter happens to like, exists. Trust the market to speak. > I really don't buy it that Go is a poor choice but that Rust isn't. They're not selling it, WeaveWorks is, and the specific (legitimate) issue has been extensively debugged on go-nuts and elsewhere: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... It's dark corners of hardware and low-level APIs where Go suffers. Platform-heavy concepts in C often translate more readily to Rust than Go, but that's not a knock of any language -- just different targets. I've been down the syscall/C ABI/etc path in Go, and most of that stuff (oddly, given that the stdlib exercises it) feels bolted on to the language as an afterthought. Rust, OTOH, intentionally sailed the "C But Better" tack. Interop between C and Rust is quite pleasant, and that is the gateway drug to all sorts of hardware-heavy tricks that really exercise a language. The same tricks in Go tend to surface weird stuff like the aforementioned issue. That being said, generalizing to an indictment of Go as a language for this use case is flawed. That first sentence under Railcar could use some work.
- 9y ago

conradk 9y ago

It's unclear to me what this offers that runc or rkt do not offer. They say this : > railcar always runs an init process separately from the container process What does that mean in terms of day to day operations/debugging ? What are the benefits ?

rndmio 9y ago
One thing it means is no zombies in the process table. When you're running something like squid in a container and you HUP it to reload the config (volume mounted) without something to reap the old process you're going to have zombies.
vishvananda 9y ago
Author here. For more discussion on init handling you may find my article on pid namespaces[1] enlightening. In terms of differences from runc, there aren't many. The goals for railcar are threefold: 1: provide an alternative implementation of the oci-runtime so that the spec doesn't become too locked to a single implementation. 2: provide an implementation in a single language without some of the "baggage" of the existing implentations so that it is easy and fun to hack on. 3: experiment with new ideas to inform the future of the oci-runtime spec. [1] https://hackernoon.com/the-curious-case-of-pid-namespaces-1ce86b6bc900 https://hackernoon.com/the-curious-case-of-pid-namespaces-1c...

vishvananda 9y ago

Author here. This hit hacker news in the middle of the night for me. I'm happy to answer any questions if anyone is still lurking.

insulanian 9y ago

Having read the comments here about Go not being suited for the low level stuff, I really wonder why did the designers of Go think it would be THE replacement for C/C++?