
CoreOS Linux Is Now Container Linux by CoreOS - philips
https://coreos.com/blog/tectonic-self-driving.html#coreos-linux-is-now-container-linux
======
zilkoopsie
This name is conversationally awful. Previously one could trivially identify
CoreOS as a linux distro to someone. Now what are they supposed to say?
container linux? it sounds like someone misspoke, what is it you're saying?
you use containers and linux?

There's absolutely nothing distinctly identifying in the new name, nothing
distinguishing it from other words expected in the relevant topic of
conversation.

And pointing out that keeping its name all lower-case is to be consistent with
the rest of CoreOS projects is a bit weak when clearly everything else has a
succinct and short identifying name then this black sheep ambiguous mouthful
of "container linux" shows up. Come on guys!

And what is up with this new logo, what does it even attempt to represent?
Clearly Tectonic is the new shiny and this didn't receive much thought or
investment.

~~~
irontoby
> This name is conversationally awful.

It's also entirely un-Googleable. Searching "CoreOS" would return you stuff
only about CoreOS. Searching "container linux" will return you tons of other
unrelated results, if you don't get carpel tunnel by the time you even finish
typing it.

~~~
masmullin
However, the inverse is probably what CoreOS is going for.

Now, whenever you google "linux container" you'll get "container linux by
coreOS" as one of the top hits (currently, for myself, googling "linux
container" doesn't have coreOS on the first page).

~~~
mandelbulb
That would be a good point as a question but as an idea it's naive. Unless
they increase their popularity by several times they never displace any of the
current top search results.

~~~
masmullin
CoreOS is fairly popular isn't it?

------
otterley
That name sounds descriptive, which could be a problem with respect to
trademark protection. (Descriptive names are more difficult to protect.)

I'm frankly surprised the lawyers signed off on it.

~~~
pawadu
_" The Linux Foundation protects the public and Linux users from unauthorized
and confusing uses of the trademark and authorizes proper uses of the mark
through an accessible sublicensing program. The Linux Foundation offers a
free, perpetual, world-wide sublicense to approved sublicense applicants. In
return, the sublicensee holders must agree not to challenge Linus Torvalds'
ownership of the Linux mark in any jurisdiction, and to provide proper
attribution of ownership on their goods, services and elsewhere. The Linux
Sublicense Agreement is available for review."_

[https://www.linuxmark.org/](https://www.linuxmark.org/)

~~~
dchest
The parent meant that they could protect CoreOS
([http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:a60...](http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:a60d9j.4.2)),
but might not be able to acquire trademark for Container Linux, because
"container" is a descriptive term. Like, you can protect "Colgate", but not
"White tooth paste". Pretty sure, though, they know what they were doing and
consulted lawyers :)

~~~
jgillich
Linux is a trademark, toothpaste is not, that's the difference. You could
definitely trademark "Black Colgate", "Ubuntu Linux" and "container linux",
the latter two via the Linux sublicensing program the comment above yours
linked to. IANAL.

~~~
icebraining
The sublicense agreement just means you get to use Linux in your name. It
doesn't mean you get to protect your new name with your own trademark. That's
up to the law.

------
raesene6
I'm guessing they're shooting for a name assocation thing here, the same thing
that Microsoft pulled off with SQL Server associating the generic term with a
specific product.

However as others have said, searchability for that product name is awful and
I'm not sure they're not a little late in the game to try this trick. Googling
container linux at the moment and they're not even on the first page of
results...

I've had a look at CoreOS in the past and it's interesting but very geared
towards cloud/large deployments (e.g. by default there is no way to use a
password to login after intallation, you need to use automation and setup an
SSH key), makes it kind of hard to tinker with in a desktop env. though.

~~~
robryk
I do not have an opinion on whether CoreOS is geared towards large
deployments. However, I very strongly disagree with the example you give.
Every person who does Ops work has an SSH key. Creating one and keeping it on
your laptop/desktop is not hard. Not allowing any remote password-based
authentication is very helpful for security _of non-large deployments_ too (or
even more helpful for them).

~~~
raesene6
I didn't say I thought key based logins were bad, but that not allowing a
password login during setup made it more awkward for people trying out CoreOS
to test.

That said I wouldn't say that SSH key based login were necessarily great for
large deployments, one lost key+passphrase ('cause everyone totally always has
a good passphrase on their SSH keys right) and an org. can be in for a world
of pain, as in many cases the procedures for key management of SSH aren't well
formalized.

~~~
robryk
> I didn't say I thought key based logins were bad, but that not allowing a
> password login during setup made it more awkward for people trying out
> CoreOS to test.

Especially if it's awkward, it's good to force this immediately. Thus "test
deployments" will not evolve into real ones while keeping the possibility of
password-based authentication.

You can also argue that disallowing empty password for remote access makes
things more awkward (which is true). Yet, I expect that you are very happy
with systems that do so.

> That said I wouldn't say that SSH key based login were necessarily great for
> large deployments, one lost key+passphrase ('cause everyone totally always
> has a good passphrase on their SSH keys right) and an org. can be in for a
> world of pain, as in many cases the procedures for key management of SSH
> aren't well formalized.

You are arguing that the situation is bad with keys, while ignoring the fact
that the situation is much worse with passwords (seatbelts are annoying and
people still die in accidents; yet, they're useful):

If you allow passwords, the situation is the same, except you don't have to
lose the key too.

Also, password reuse between different systems in the same deployment is
usually rampant, which makes it very easy for an attacker to jump between such
systems (just wait until someone logs in remotely to a compromised system and
you have the password).

If the situation with keys is bad enough for you, then you can use SSH
certificates, which require you to just protect the CA (It is, unless you need
revocations, very simple to set up. You can get by without revocations by
having an automated CA that gives you certs with a validity of something like
an hour.)

~~~
raesene6
I'm not ignoring password problems I didn't make any mention of passwords one
way or the other. You seem to be ascribing views to me that I just didn't
state, I'm guessing this is you assuming my world view, a common issue with
Internet discussions.

I didn't say passwords were good, I said that people often overlook the
weaknesses of managing SSH key based deployments. key proliferation is a real
issue and as passphrases on SSH keys are susceptible to offline attack,
without very strong passphrases they can present a risk. Also in my experience
centrally managed key rotation and expiry is rarely included, thus the risk
that if a key is compromised, detection/revokation/re-issuance are hard.

To provide some background I've been an IT security professional for 15 years,
I know the ups and downs of various authentication mechanisms, I was just
pointing out a rarely noted downside of SSH key based auth. given you seemed
from your comments to view it as an unalloyed good.

~~~
robryk
Ah, I see where the disagreement lies. I've thought that by downsides you mean
_relative_ downsides, whereas you meant absolute ones. Thanks for the detailed
explanation of your position.

------
Rapzid
Ubuntu is container linux for me. I WANT to install stuff on my host; thank
you apt. CoreOS produced etcd which is outliving the OS distribution.. Fleet
was a thing.. Their update system.. This pivot away from the distro makes
sense.

~~~
colemickens
CoreOS is still _very_ much a thing. The update system is seamless and has
never once caused a hiccup for me. And I certainly don't perceive this as a
pivot away from the distro, at all. Not sure where any of your statements come
from. Except the Fleet bit, maybe, but that's just because they saw something
better in Kubernetes and now contribute heavily to it.

And I'm curious what you want to install on your host if you're using
containers. Surely you're not logging into these VMs interactively?

(A bit funny too, Ubuntu's fork of docker in Xenial was causing a reboot of
basically everything under systemd (including ssh) under certain conditions
used in Kubernetes.)

~~~
eikenberry
Where is the statement that they are moving away from fleet? There was no
mention of anything related to that in the linked article.

~~~
colemickens
Sorry, I didn't mean that. My perception is that I see far less announcements
about Fleet, but I don't know any official stance or anything. Didn't expect
it to have as much activity as it does on GitHub, but the most frequent recent
committer doesn't seem to be an employee (again, that doesn't necessarily mean
anything). I was mostly agreeing that I don't see Fleet as a super popular
tool these days (contrary to features they've contributed to Kubernetes or the
ecosystem, etcd, coreos, flannel, etc)

~~~
philips
This is roughly correct. The README says it best:
[https://github.com/coreos/fleet#current-
status](https://github.com/coreos/fleet#current-status)

Also, as you mention there are very compelling reasons that when Kubernetes
came on the scene 2 years ago we started contributing heavily instead of
trying to compete. We started to say something with fleet and Kubernetes
completed our sentence:
[https://github.com/coreos/fleet/blob/master/Documentation/fl...](https://github.com/coreos/fleet/blob/master/Documentation/fleet-k8s-compared.md)

Overall, we recommend everyone use Kubernetes as the way to orchestrate
containers.

~~~
vidarh
Personally I feel it's a shame - Kubernetes is way overkill for most of the
deployments I do. At the same time fleet has a number of annoying problems
even on (or even particularly on) small clusters.

I see Kubernetes deployments where more of the containers running are there to
provide infrastructure than actual workloads, which gets just silly. For small
deployments like that, something as simpl as Fleet but with a better
scheduling story would be preferable to me.

But I get that those kind of deployments won't pay the bills as they're
certainly much less likely to pay for CoreOS services.

~~~
untoreh
Indeed if you have just a handful of hosts, spending gigas of ram for
kubernetes is not really exciting.

------
corbet
I was going to read the site to see what they are up to, but, grumpy old man
that I am, I no longer feel the need to push through sites done in low-
contrast text. If they don't want it to be readable, I won't read it...

~~~
sciurus
I'm not sure what you mean. I see black text on a white background.

[http://imgur.com/BDXuFXj](http://imgur.com/BDXuFXj)

~~~
brainfire
That's grey on a white background. This is what it would look like if it was
black (I removed the "color: rgba(0,0,0,75)" tag via chrome's inspector):
[http://i.imgur.com/v491foi.png](http://i.imgur.com/v491foi.png)

It looks like your rendering (resolution, dpi, hinting? no idea) mitigates the
effects of the reduced contrast in a way that mine do not. I'm guessing that's
true on their developers' systems as well.

------
vonklaus
There logo and brand is great. It was one of the logos/brands I used yesterday
for a gig I had designing a logo for a VR startup-- and CoreOS was my
favorite.

It was minimal & likely unique enough for trademark and clean. I like it. This
is a terribly verbose pivot and pretty bad as far as rebrands go.

------
amouat
Does the logo remind anyone else of Pacman?

------
hubert123
i think the name change makes sense and it's a power move, it basically says:
hey if you want to run containers on linx, we are -the- software to do it
instead of just one among many. this only works if you're already fairly
established and I think CoreOS has some justification to do it

------
politician
Ok, the sky is not falling. "CoreOS Tectonic" is their _googleable_ paid
enterprise OS product, and now "container linux by CoreOS" is the free
offering.

The move is clearly designed to push their free offering lower in the search
rankings.

------
chrismorgan
I wish the logo didn’t set the C and L in lowercase.

~~~
philips
I can see that. It does make a bit more sense when placed alongside the other
wordmarks [http://i.imgur.com/4hqbVG4.png](http://i.imgur.com/4hqbVG4.png)

~~~
nikolay
I hate the Container Linux logo! Also, why does etcd's doesn't any reddish
element?!

------
fucking_tragedy
In 3 - 5 years, the name will sound archaic.

