
Three New Open Source Container Utilities - insulanian
https://blogs.oracle.com/developers/three-new-open-source-container-utilities
======
Illniyar
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.

~~~
pjmlp
I have been using Oracle products since around 1996 and will keep using them.

MS SQL Server is the only one that can compete with PL/SQL, the feature lists,
and the GUI tooling provided out of the box for database administration,
report generation and data modeling.

Java, they have made quite a few improvements to the language and runtime,
some of them even unthinkable under Sun's stewardship, namely adding Graal to
the official JDK and adding AOT support (most commercial JDK have it since
early days of Java).

Also their roadmap for value types, GPGPU, fully replacing Hotspot with Graal
and eventually having OpenJDK mostly implemented in Java, after those changes
are done.

They created SPARC M7 with Silicon Secured Memory, as yet another band-aid
against C security exploits.

So while the company might be heavy profit oriented, it is no different than
any other corporation that likes money.

~~~
robert_foss
To say that Oracle is no worse than any other profit oriented company is not
quite true.

It is the worst company that we in the open source community know of.

Everything they touch dies. If it does not die, it probably should, probably
even for technical reasons.

~~~
stargrazer
VirtualBox seems to be an exception to the rule?

~~~
gtirloni
One can argue VBox has been on life support since Oracle acquired it from Sun.
I'm puzzled about why they haven't shut it down too.. maybe some profitable
support contracts? Internal usage?

------
joseluisq
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
Not sure about that, but Oracle is a poor choice as a source of open source
tools, given their history.

~~~
praneshp
The author was one of the heaviest early contributors on the Openstack
project.

~~~
reitanqild
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.

------
conradk
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 ?

~~~
vishvananda
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-1c...](https://hackernoon.com/the-curious-case-of-pid-
namespaces-1ce86b6bc900)

------
vishvananda
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
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++?

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

------
ajdlinux
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.

~~~
conradk
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-
run...](https://blogs.oracle.com/developers/building-a-container-runtime-in-
rust)

~~~
pjmlp
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.

------
jondubois
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.

~~~
joseluisq
It's true, but to affirm that "Go is a poor choice of language for a
containers" it would be equivalent to say that Docker did a poor language
choice... ?

~~~
cyphar
Docker didn't have much of a choice. At the time they had two options: C/C++
or Go (Rust wasn't usable at). They went with the right choice _at the time_ ,
Go. Unfortunately nobody really knew about all of the pitfalls of Go (there
are many upsides, but writing a container runtime in Go is definitely not one
of them).

Right now, I would definitely recommend people write things like this in Rust.
In fact I was planning on working on something similar. :P

~~~
joseluisq
Sure, in that case, some Rust expert should write an article detailing all
these Go pitfalls related to syscalls at kernel level :P

~~~
cyphar
I'm not a Rust expert (yet) but I probably should write something up because
this topic always comes up when people like me start complaining about Go.

