Hacker News Reader

Comment by CBLT | Hacker News Reader

> To this day, I've heard CGroups being mentioned only once.

See https://www.kernel.org/doc/Documentation/cgroup-v2.txt

> "cgroup" stands for "control group" and is never capitalized. The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used.

To this day, I've heard cgroup mentioned only once...

To put forth a more substantive argument, everybody has a layer of abstraction they do not peek under. You interviewed people that didn't peek under container. You went a layer deeper, but never peeked at the source tree to learn what cgroup really is. Does it really feel that much better to be one level above others?

View on HN

> To put forth a more substantive argument, everybody has a layer of abstraction they do not peek under.

Sure. Though it's reasonable to want your level N developers to have some idea of what goes on at levels N-1 and perhaps N-2, cf. Law of Leaky Abstractions etc. It's similar to wanting your developers to be aware of their users' needs, which are level N+1 concerns.

Yeah, I wonder if there's an "optimal target" for the number of layers up and down you'd ideally be aware of. It has to be at least yours, and ones immediately above and below, but I see innovation coming from people with unusually keen insight into layers further away--eg. people making brilliant architectural decisions because they really, really know what the consumers of an api need and how those people think about the domain. Or vice versa, someone making something radically better or faster in a web app because they really get how the linux kernal is implemented.

It seems like cases where that deep knowledge is an advantage are rare but also very high value. I wonder how the EV pans out, both for individuals and orgs.

> The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used.

They're free to say this, but since it violates the rules of the language they're never going to get any significant level of compliance.

> To put forth a more substantive argument, everybody has a layer of abstraction they do not peek under.

I hope you meant have not peeked under, so far. Any obscure problem will you down the rabbit hole. If you just stop looking then how can you solve problems?

By working around them, which is sometimes the smart decision. Hard to know ahead of time when that is the case, though...

> everybody has a layer of abstraction they do not peek under

Reminds of this xkcd: https://xkcd.com/435/

The beauty of programming is abstraction - you write a function to do one thing, do it well, and then you can abstract that concept away and reuse that abstraction. Although it's only an abstraction - a container is "like" a lightweight VM, and you can use it like that until it doesn't act like a lightweight VM. In which case, you have to dabble one layer deeper just to understand enough to know why the abstraction of your layer isn't a perfect analogy.

In which case, if you're looking for an expert in layer n, then basic knowledge of layer n - 1 might be a decent proxy for expertise

>Does it really feel that much better to be one level above others?

Yes? Because levels are finite and quantifiable.

I mean, maybe technically, but not practically. Knowing how your computer works requires knowledge of semiconductors, p- and n-type doping, quantum physics, etc.

So yes, maybe you can enumerate the levels, but at some point they become not useful to discuss. The same way that discussing NPN gates is not really useful to discussing containers and VMs.

Reply on news.ycombinator.com