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.
What?!?! I'd put OpenVZ'd RHEL a country mile ahead of Ubuntu, and there are better candidates than that (like CoreOS). What's the idea behind Ubuntu's claim to the brand?
> I WANT to install stuff on my host
I'm sure you do, but that means you don't want "container linux". It means you want Linux with containers.
I suspect many already do that. From experience, it's still easier to develop on and deploy to the same container host OS. Ie: Docker on Ubuntu for both is best. You'd be hard pressed to do development on CoreOS/Container Linux.
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.)
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)
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...
Overall, we recommend everyone use Kubernetes as the way to orchestrate containers.
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.
Fleet is great for some things - I love being able to use it to distribute systemd units. But it has a bunch of problems (doesn't scale well to really large systems, balances poorly without "help" in the case of hosts that fail and recover, has a tendency to restart things unnecessarily if it loses connection to etcd or heartbeats fail, which can happen way too easily) and CoreOS have been pretty clear they're not prioritising fixing them.
For my part I still use it for smaller clusters - it's far easier to deploy than Kubernetes, for starters - and I might very well continue using it in parallel with Kubernetes for deploying systemd units as well, but it's important to be aware of its shortcomings.
I didn't see a statement, but their inclusion of the kubelet last year, and their ongoing involvement with Kubernetes is indicative that if fleet remains, it will be as a niche bootstrapping tool for higher order cluster management.
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
"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."
The parent meant that they could protect CoreOS (http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:a60...), 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 :)
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.
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.
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.
> 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?
On the bright side, Docker has been trying to "own" the term container for quite a while, all to the point that people don't even know that other kinds of containers even exist.
This might open up people to the idea that a container is a concept, and that there are multiple implementations out there, and not just Docker.
I've honestly only thought of containers as related to Docker. They definitely appear to be pushing to "own" the term as you said. Anyway, yeah, really bad name. CoreOS was a wonderful distro name that hinted at its overall purpose/function.
I absolutely agree, and generally prefer descriptive names over the silicon valley marketing focus group vomit the typical company name is these days.
That said, CoreOS was perfect. A name that is both largely descriptive, short, and doesn't pigeonhole the product into one static market segment during it's lifetime.
This? I will refuse to even bring it up in executive strategy meetings since it's such a horribly confusing name that will just cloud the subject being discussed in explaining what I meant.
Certainly a minor thing, but definitely a minor step backwards not forwards.
Definitely backwards. Usually companies with successful products adopt the product name as the new company name, like dotCloud to Docker or 37signals to Basecamp.
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.
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).
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.
Folks said the same thing when Red Hat became RHEL. I remember because I was one of them both times. That being said these things blow over and while you specifically get it, I can tell you first hand that many people do not and get REALLY confused.
The thing that changed was only the insertion of the word "enterprise." (Red Hat Linux -> Red Hat Enterprise Linux)
The company name (which is a fanciful mark)'s inclusion as a prefix of the product name did not change.
Here, the company's name is no longer included in the product's name. If they'd called it "CoreOS Container Linux," then that would be a different story.
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.
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.
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).
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.
> 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.)
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.
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.
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...
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
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.
Jonathan- if you are seeing grey that is not the intended rendering. I will email you to get some details but it should be pure black on pure white: http://i.imgur.com/e1StBlC.png
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.
60 comments
[ 3.3 ms ] story [ 136 ms ] threadWhat?!?! I'd put OpenVZ'd RHEL a country mile ahead of Ubuntu, and there are better candidates than that (like CoreOS). What's the idea behind Ubuntu's claim to the brand?
> I WANT to install stuff on my host
I'm sure you do, but that means you don't want "container linux". It means you want Linux with containers.
YMMV but I think coreos has a good base to support the latter.
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.)
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...
Overall, we recommend everyone use Kubernetes as the way to orchestrate containers.
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.
[0] https://circleci.com/blog/its-the-future/
For my part I still use it for smaller clusters - it's far easier to deploy than Kubernetes, for starters - and I might very well continue using it in parallel with Kubernetes for deploying systemd units as well, but it's important to be aware of its shortcomings.
I'm frankly surprised the lawyers signed off on it.
https://www.linuxmark.org/
But that's the thing about lawyers; you can find one to agree with you on anything if you look hard enough.
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.
On the bright side, Docker has been trying to "own" the term container for quite a while, all to the point that people don't even know that other kinds of containers even exist.
This might open up people to the idea that a container is a concept, and that there are multiple implementations out there, and not just Docker.
It is confusing.
"We should use Container Linux."
"No, you mean lxc, it's used for containers on linux."
... :(
That said, CoreOS was perfect. A name that is both largely descriptive, short, and doesn't pigeonhole the product into one static market segment during it's lifetime.
This? I will refuse to even bring it up in executive strategy meetings since it's such a horribly confusing name that will just cloud the subject being discussed in explaining what I meant.
Certainly a minor thing, but definitely a minor step backwards not forwards.
This!
What are the follow on products? "Relational Database", "Distributed Cache" ?
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.
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).
Here, the company's name is no longer included in the product's name. If they'd called it "CoreOS Container Linux," then that would be a different story.
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.
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.
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.
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.)
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.
http://imgur.com/BDXuFXj
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.
The move is clearly designed to push their free offering lower in the search rankings.