6 ms·

Author is really good at discrediting themselves straight off the bat in one sentence: > for a bullshit unsuccessful project called CoreOS Container Linux

by alpb 6y ago

Author is really good at discrediting themselves straight off the bat in one sentence: > for a ~~bullshit~~ unsuccessful project called CoreOS Container Linux that was EOL'd several years ago CoreOS was actually quite successful to me as an outside observer. It had decent paid user base as well as people using it without paying. It has showed people that Chrome OS can be used to build atomically updating host OS with a readonly fs for container hosting. It has inspired many other container hosts to come like RancherOS and Google’s Container-Optimized OS. Similarly, it was probably one of the reasons why Red Hat was interested in the acquisition. Furthermore, CoreOS was EOL'ed last month; not several years ago. I can keep going on why etcd API was switched to gRPC and what benefits this offers, even at small scale. But I don't think it's worth anyone’s time convincing the author otherwise. Based on their tone, it's clear to me that they have trouble with using software when things get a tad bit complicated. Usually, there's community decision-making behind these decisions, and they're often deliberated for months, backed with prototypes and data. I'm pretty sure the author doesn't care, however.

Already__Taken 6y ago
Yeh I don't even know what I'm doing and kept a 3 node cluster running with 100% uptime of small/jokey internal apps for 2 years and everything up-to-date. Replaced one node due to failure and often pull the power from one at random as a party trick.
m463 6y ago
I think he added a sidebar to his web page.
dharmab 6y ago
My team ran about 50% of a Fortune 500 software company on CoreOS up until a few months ago when we migrated to Flatcar. We even paid a lucrative support contract while we ran it. I can count the number of major OS issues we had with it over several years on one hand- and we've had even better success with Flatcar so far. Calling CoreOS unsuccessful is a massive misunderstanding of the market.
- gcbw3 6y ago
  Your company running on it (and not flatcar, heh) is what shows a massive misunderstanding of the market. Just because people buy snake oil, it doesn't make it a good product.
  - dharmab 6y ago
    We've been running CoreOS since before Flatcar _existed_. And we seem to be doing just fine on the OS.
  - staticvoidmaine 6y ago
    Let’s keep this chain going: Your viewpoint on this company using it is what shows a massive misunderstanding of the market. Clearly, people are using it successfully and enjoying it (or other similar products). Just because you don’t like it it doesn’t change the reality of the situation.
- einpoklum 6y ago
  Maybe you're right - it's not unsuccessful after all, it really is a bullshit project... Now _every_ part of the OS is in a container! Wheee! https://en.wikipedia.org/wiki/Container_Linux https://en.wikipedia.org/wiki/Container_Linux (for those who don't know, it was renamed from CoreOS to Container Linux)
  - dang 6y ago
    Would you please stop posting flamebait and unsubstantive comments to HN? You've been doing it a lot, and we ban such accounts. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - einpoklum 6y ago
      1. I repeated an argument made in the article itself. That cannot be considered flamebait. 2. I've always expressed strong opinions in my posts. Sometimes this results in multiple upvotes, sometimes in multiple downvotes. 3. About being "unsubstantive" - I underscored the main concept/rationale for Core Linux, and linked to its Wikipedia page. You could argue that it's not substantive _enough_, but when you phrase it this way it's as though you merely dislike the fact that I repeated the inflammatory term from the article.
philosopher1234 6y ago
Could you share some info about the switch to gRPC, not for the authors benefit, but for the rest of HN? As someone not familiar with this story, I’d be very curious for your insights!
- alpb 6y ago
  https://news.ycombinator.com/item?id=23835651 https://news.ycombinator.com/item?id=23835651
jchw 6y ago
I want to make constructive comments about this blog post, but the way it conducts itself makes doing so extremely difficult because nothing about it is constructive. This is troublesome for HN - I almost wish I could flag it for being impossible to discuss without turning into a flame war. It feels like several disjointed complaints based on a desire to jam any and all inconveniences into a unified narrative about Modern Software and Google. Dismissing CoreOS is the opener, but there’s almost nothing on the page that doesn’t wave red flags in some way, and I’m trying desperately to be open and objective.
- specialp 6y ago
  It is essentially a rant with not much substance. If this was a comment on HN it would be flagged probably. Like to hit at so many things in 3-4 paragraphs you aren't making an argument for or against something, you are just making a scattershot blast on like most of systems stuff today.
- abnercoimbre 6y ago
  I have worked with (and under) big names in system software and so many of them think saying "terrible", "garbage", and "trash" will motivate people to do productive corrections or improvements. Nope. Times have changed and the very people he criticizes are infinitely better at branding and inspiration. There's a reason they're the ones gaining traction. Like you, I want to be constructive, and I do agree with the author's core complaints. He just doesn't realize he's actively self-sabotaging and harming his own reputation.
x87678r 6y ago
I didn't even know CoreOS was going away, looks like there is a Fedora CoreOS which seems essentially the same. https://coreos.com/os/eol/ https://coreos.com/os/eol/
- dharmab 6y ago
  Fedora CoreOS is slightly different and not 1:1 compatible. https://www.flatcar-linux.org https://www.flatcar-linux.org is a fork of the original which is actively developed.
SNosTrAnDbLe 6y ago
The author is talking about keeping things simple which is not a bad idea. I am genuinely interested in why etcd switched to gRPC?
- m463 6y ago
  It must speak gRPC before it can be subsumed by systemd. (joking)
- KaiserPro 6y ago
  the need for speed, or something.
- alpb 6y ago
  First of all etcd API is still available on a JSON interface. https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/etcd-io/etcd/blob/master/Documentation/de... and some historical discussion here: https://github.com/etcd-io/etcd/issues/1980 https://github.com/etcd-io/etcd/issues/1980 Many reasons to switch from JSON to gRPC: * gRPC uses HTTP/2 which means you can concurrently make multiple requests on a single TCP connection, while on a typical JSON API which probably uses http/1.1, you can't. * Type safety of protobuf types. * Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. * Client libraries are automatically generated, and not error prone. * RPCs are already optimized for bytes on the wire efficiency, whereas JSON is not. This matters a great deal as Kubernetes objects get large in size/quantity over time but controllers still work effectively by not spending too much CPU on encoding/decoding like they do on JSON. * Similar to the previous point, most json decoders don't reuse objects, so every decoded object is a new alloc, whereas gRPC can Reset() and reuse the same object while decoding/encoding. * Builtin authentication primitives (such as JWT/tokens or even adding TLS to client and/or server). * gRPC has support for interceptors which are like middleware functions you can inject to requests/responses on both client and server-side for logging, authorizing etc. The list goes on, but something to note is that etcd was not developed by Google (and as far as I know, not by ex-Googlers). Both etcd and gRPC are owned by the same open source foundation, so it's natural that they make use of an existing technology.
AdamGibbins 6y ago
Entirely agreed, CoreOS Container Linux was a great project that served its purpose well. Yes it went EOL last month and we just moved to one its successors, Fedora CoreOS, also works well. The authors tone is incredibly off putting.

Author is really good at discrediting themselves straight off the bat in one sentence: > for a ~~bullshit~~ unsuccessful project called CoreOS Container Linux

by alpb 6y ago

Already__Taken 6y ago

Yeh I don't even know what I'm doing and kept a 3 node cluster running with 100% uptime of small/jokey internal apps for 2 years and everything up-to-date. Replaced one node due to failure and often pull the power from one at random as a party trick.

m463 6y ago

I think he added a sidebar to his web page.

dharmab 6y ago

My team ran about 50% of a Fortune 500 software company on CoreOS up until a few months ago when we migrated to Flatcar. We even paid a lucrative support contract while we ran it. I can count the number of major OS issues we had with it over several years on one hand- and we've had even better success with Flatcar so far. Calling CoreOS unsuccessful is a massive misunderstanding of the market.

gcbw3 6y ago
Your company running on it (and not flatcar, heh) is what shows a massive misunderstanding of the market. Just because people buy snake oil, it doesn't make it a good product.
- dharmab 6y ago
  We've been running CoreOS since before Flatcar _existed_. And we seem to be doing just fine on the OS.
- staticvoidmaine 6y ago
  Let’s keep this chain going: Your viewpoint on this company using it is what shows a massive misunderstanding of the market. Clearly, people are using it successfully and enjoying it (or other similar products). Just because you don’t like it it doesn’t change the reality of the situation.
einpoklum 6y ago
Maybe you're right - it's not unsuccessful after all, it really is a bullshit project... Now _every_ part of the OS is in a container! Wheee! https://en.wikipedia.org/wiki/Container_Linux https://en.wikipedia.org/wiki/Container_Linux (for those who don't know, it was renamed from CoreOS to Container Linux)
- dang 6y ago
  Would you please stop posting flamebait and unsubstantive comments to HN? You've been doing it a lot, and we ban such accounts. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - einpoklum 6y ago
    1. I repeated an argument made in the article itself. That cannot be considered flamebait. 2. I've always expressed strong opinions in my posts. Sometimes this results in multiple upvotes, sometimes in multiple downvotes. 3. About being "unsubstantive" - I underscored the main concept/rationale for Core Linux, and linked to its Wikipedia page. You could argue that it's not substantive _enough_, but when you phrase it this way it's as though you merely dislike the fact that I repeated the inflammatory term from the article.

philosopher1234 6y ago

Could you share some info about the switch to gRPC, not for the authors benefit, but for the rest of HN? As someone not familiar with this story, I’d be very curious for your insights!

alpb 6y ago
https://news.ycombinator.com/item?id=23835651 https://news.ycombinator.com/item?id=23835651

jchw 6y ago

I want to make constructive comments about this blog post, but the way it conducts itself makes doing so extremely difficult because nothing about it is constructive. This is troublesome for HN - I almost wish I could flag it for being impossible to discuss without turning into a flame war. It feels like several disjointed complaints based on a desire to jam any and all inconveniences into a unified narrative about Modern Software and Google. Dismissing CoreOS is the opener, but there’s almost nothing on the page that doesn’t wave red flags in some way, and I’m trying desperately to be open and objective.

specialp 6y ago
It is essentially a rant with not much substance. If this was a comment on HN it would be flagged probably. Like to hit at so many things in 3-4 paragraphs you aren't making an argument for or against something, you are just making a scattershot blast on like most of systems stuff today.
abnercoimbre 6y ago
I have worked with (and under) big names in system software and so many of them think saying "terrible", "garbage", and "trash" will motivate people to do productive corrections or improvements. Nope. Times have changed and the very people he criticizes are infinitely better at branding and inspiration. There's a reason they're the ones gaining traction. Like you, I want to be constructive, and I do agree with the author's core complaints. He just doesn't realize he's actively self-sabotaging and harming his own reputation.

x87678r 6y ago

I didn't even know CoreOS was going away, looks like there is a Fedora CoreOS which seems essentially the same. https://coreos.com/os/eol/ https://coreos.com/os/eol/

dharmab 6y ago
Fedora CoreOS is slightly different and not 1:1 compatible. https://www.flatcar-linux.org https://www.flatcar-linux.org is a fork of the original which is actively developed.

SNosTrAnDbLe 6y ago

The author is talking about keeping things simple which is not a bad idea. I am genuinely interested in why etcd switched to gRPC?

m463 6y ago
It must speak gRPC before it can be subsumed by systemd. (joking)
KaiserPro 6y ago
the need for speed, or something.
alpb 6y ago
First of all etcd API is still available on a JSON interface. https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/etcd-io/etcd/blob/master/Documentation/de... and some historical discussion here: https://github.com/etcd-io/etcd/issues/1980 https://github.com/etcd-io/etcd/issues/1980 Many reasons to switch from JSON to gRPC: * gRPC uses HTTP/2 which means you can concurrently make multiple requests on a single TCP connection, while on a typical JSON API which probably uses http/1.1, you can't. * Type safety of protobuf types. * Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. * Client libraries are automatically generated, and not error prone. * RPCs are already optimized for bytes on the wire efficiency, whereas JSON is not. This matters a great deal as Kubernetes objects get large in size/quantity over time but controllers still work effectively by not spending too much CPU on encoding/decoding like they do on JSON. * Similar to the previous point, most json decoders don't reuse objects, so every decoded object is a new alloc, whereas gRPC can Reset() and reuse the same object while decoding/encoding. * Builtin authentication primitives (such as JWT/tokens or even adding TLS to client and/or server). * gRPC has support for interceptors which are like middleware functions you can inject to requests/responses on both client and server-side for logging, authorizing etc. The list goes on, but something to note is that etcd was not developed by Google (and as far as I know, not by ex-Googlers). Both etcd and gRPC are owned by the same open source foundation, so it's natural that they make use of an existing technology.

AdamGibbins 6y ago

Entirely agreed, CoreOS Container Linux was a great project that served its purpose well. Yes it went EOL last month and we just moved to one its successors, Fedora CoreOS, also works well. The authors tone is incredibly off putting.