Please submit the original article. Spamblog submissions are subject to removal, readers are encouraged to report them.

GNU/Linux is a free and open source software operating system for computers. The operating system is a collection of the basic instructions that tell the electronic parts of the computer what to do and how to work. Free, Libre and open source software (FLOSS) means that everyone has the freedom to use it, see how it works, and change it.

GNU/Linux is a collaborative effort between the GNU project, formed in 1983 to develop the GNU operating system and the development team of Linux, a kernel. Initially Linux was intended to develop into an operating system of its own, but these plans were shelved somewhere along the way.

Linux is also used without GNU in embedded systems, mobile phones and appliances, often with BusyBox or other such embedded tools.

Ever noticed how you get tonnes of comments about the content when you post written text but essentially nothing when you post a video because no one is going to watch 40 minutes long of someone talking?

"talks" are such a worthless vessel for communication, especially about technical subjects. Mathematics is not a language that is well expressed orally. Reading out mathematical formulae and code will make no one remember it. You need to see it for it to make sense. Writing is in general just superior for any information of specific technical content because you often need to read and re-read some parts of it for it to sink in.

Re: the points about the "worthless"ness of talks; obviously I'm biased here, but I don't really agree. I can only speak from my personal experience which is pretty much the inverse (ie. I often watch videos of 40+ minutes of someone talking about technical subjects, and get a lot out of them).

I barely ever read long pieces of writing, because I generally find that writing does not tend to hold my attention very well past the ~10 minute mark (with occasional exceptions). This doesn't really have much to do with the writing, only that writing itself is not a medium I find easy to engage with.

Talks on the other hand, I can actually get knowledge from. I spend a non-trivial amount of my time just watching talks and improving my technical breadth of knowledge from them. I enjoy the personalities, and I'm mostly an audiovisual learner, I like to see somebody's body language and way of speaking -- it helps keep me rooted in the content and engage with the material.

In my talks I try and reiterate the key points multiple times (in this talk for example: the nature of the new unified hierarchy, an understanding of issues with cross-domain actions in v1, etc). To some extent, this can act as an analogue to the "re-reading" you're mentioning.

Another thing about this talk is that I've tried to keep it quite high level. For a technical talk, I go into all the high level points that we're trying to achieve, but don't necessarily go into absolute technical detail on each point. I agree that technical talks are often a really poor place to present mathematical formulae or pieces of code, but I don't think this talk has any of those. This talk is mostly talking about high level goals and design, not technical implementation detail.

If you find these kinds of talks are not very useful for you, then that's why we also have a long document describing version 2, which is also linked to at the end of the talk. I personally need to be able to watch talks as a staple of my long-term learning, so I'm glad people do them. :-)

I know, I read it from cover to cover before. Obviously there is some actual docuemntation as well.

I barely ever read long pieces of writing, because I generally find that writing does not tend to hold my attention very well past the ~10 minute mark (with occasional exceptions). This doesn't really have much to do with the writing, only that writing itself is not a medium I find easy to engage with.

I find it very hard to believe you would implement software that works with cgroupv2 from a talk rather than the official written documentation. I used the documentation to implement stuff using cgroupv2 and I have no idea how you would do that from a talk. If I had to do it again I would still go back to the documentation to fresh up some exact things I forgot to ensure I respect the specification and it remains future-proof. I for instance remember that they guaranteed they would never create new controllers that have certain words like 'slice' and 'session' in them or that start with a _ but I'm certainly not sure.

Another thing about this talk is that I've tried to keep it quite high level.

That's often the problem with talks, they are so high level that they are useless as actual documentation or information. They're like newspapers, information without information because it's givening such a way that the reader of the newspaper has no actual investment in its accuracy and factuality. It's just providing "interesting information", not actually soemthing you attend/read because you intend on using the information for anything and thus are highly dependent on that it is actually factually correct.

I'm pretty sure you could just go into that talk and tell them that cgroupv2 employs a single writer mandate as was once planned and it wouldn't matter, no one would care or notice. And that's exactly thekind of stuff that ends up in newspapers and I've seen this myth repeated a lot on reddit, one assumes by people who didn't actually work with the cgroupv2 API directly because when you do then it suddenly becomes important that the information is accurate. If the official docmentation told me that it was there and I had to write my pid to a file to gain authority and I would and I would get a write error I would file a bug report and be confused.

I agree that technical talks are often a really poor place to present mathematical formulas or pieces of code, but I don't think this talk has any of those. This talk is mostly talking about high level goals and design, not technical implementation detail.

Okay, then what's the purpose of it? What benefit do you achieve by spreading this information? Are they going to use it for something? Probably not? Maybe it wil inspire their own design ideas, I can see that maybe and just maybe happening.

It just seems to me to be mostly about "I go to talks because I think it's interesting" rather than an actual practical purpose of needing the information for something. Which has been exactly my experience with most academic conferences.

If you find these kinds of talks are not very useful for you, then that's why we also have a long document describing version 2. I personally need to be able to watch talks as a staple of my long-term learning, so I'm glad people do them. :-)

Maybe, but every time as I said when you see a talk posted here there are very few comments opposed to article and the comments that are there are more about the title than the talk, no one dmonstrates having actually watched the talk.

My other problem with talks when it's something that is opinion based is that it's a unilateral praesenstation, not discourse. Ideally when you debate a matter whoever disagrees with you quotes each of your individual points and addresses them piece by piece. But the kind of "dsicusssion" that follows from these talks are typically someone giving a high level opinion and someone giving an opinion of "I disagree" without actually answering to the arguments the other person raised. Typically both don't really give any arguments and just both give their opinion without actually poking holes in the arguments of the other.

It's how GNOME conducts their meetings. It's basically a case of "alice thinks we should do X", "bob thinks we should do Y", both say their piece without really answering to the other and poking holes in the reasoning of the other. Alice convinces more people than Bob on the board purely by feeling and the board goes with Alice' idea.

I find it very hard to believe you would implement software that works with cgroupv2 from a talk rather than the official written documentation.

Like I said in the talk, this talk is about getting key people in the future of containerisation and resource management enthused and interested in cgroupv2, and understanding of the core principles underlying its design. In addition to container folk, I know for a fact that there are many other SREs out there who could benefit from cgroupv2, but don't know about its benefits (or perhaps even existence) yet. This talk is a starting point to get people engaged with learning more about cgroupv2.

I don't expect anyone without prior experience to be able to walk away from this talk and immediately go to design a system using cgroupv2 without looking at any documentation -- the aim here is to plant the seeds of knowledge and interest, not to provide a comprehensive technical documentation in the form of a talk.

Okay, then what's the purpose of it? What benefit do you achieve by spreading this information? Are they going to use it for something? Probably not? Maybe it wil inspire their own design ideas, I can see that maybe and just maybe happening.

The people in the room where I presented are technology leaders in containerisation and init systems. It's important that, if cgroupv2 is to succeed, people are interested and passionate about the work being done here. Technical documentation is one thing, passion is entirely another.

Maybe, but every time as I said when you see a talk posted here there are very few comments opposed to article and the comments that are there are more about the title than the talk, no one dmonstrates having actually watched the talk.

I can only speak for my own talks, but YouTube's analytics around audience retention shows me that approximately ~30% of people watching this video watched the entire thing. Of people that watched >2 minutes, 80% of them completed the whole thing. That seems like a pretty good hit rate to me. :-)

My other problem with talks when it's something that is opinion based is that it's a unilateral praesenstation, not discourse. Ideally when you debate a matter whoever disagrees with you quotes each of your individual points and addresses them piece by piece. But the kind of "dsicusssion" that follows from these talks are typically someone giving a high level opinion and someone giving an opinion of "I disagree" without actually answering to the arguments the other person raised.

The questions were cut off in this video because the mic kept on cutting out, but I can assure you that none of my answers to these questions were "I disagree". I got questions about whether the I/O controller in cgroupv2 supports some particular features of non-CFQ schedulers, I got questions around how cgroupv2 handles situations without memory overcommit, etc.

Any question which can immediately be responded to with "I disagree" probably wasn't phrased very well. Instead of clashing with the presenter, the most productive way to discuss this involves asking questions of the presenter, not making statements. For example, if someone disagreed with the transition towards TGID-level granularity, I'd at least explain why that decision was made. Disagreeing or not with the presenter's judgment is only tangential to actually answering the question.

One of them flat out told me that the main reason they give them is because they obviously cannot charge you 1 200 EUR per year tuition fees while just saying "Here's the book, this is what you need to learn, exams are in 2 months', but it actually wouldn't be much better than that. Of course a human face to interact with and ask things when you have quaestions is nice and it's more comfortable to do this when yous ee that person eery day as well as ask some things you don't understand in the breaks.

But if you had to choose between only the book or only the talk, no one in their right mind would pick only the talk. You always had to read it again later from the book to understand it, and the talk definitely put it in context and it made reading the book later easier for sure. But for the most part the talk was pretty much reading out loud what was inside the book and writing it down on the whiteboard.

Wanna know how I know you've never watched any kind of technical lecture?

My Bachelor in Electrical Engineering tells me different.

Because if you had, you'd know they almost always use text presentations as a secondary medium to assist with technical language and symbols precisely because talks are an awful format for discussing technical matters.

I disagreed with the assumption that talks in STEM fields are always worthless. It highly depends on the presentatation and the intent of the talk.

I also never said anything about (availavle or the lack of) supplementary material.

I will then first skim the slides, this is usually fast. Then, if it's really something that helps me to learn, I'll look at the talk (because I assume that the talk contains a little bit more information than the slides, good talkers do it that way).

I mean I understand it, I don't agree but he or she basically doesn't like container tech and there are certainly arguments against it. A lot of those supposed "security" stuff has created security holes because it creates so much complexity that no one understands what is going on any more and creates confusion.

I see a lot of people approach cgroups under the mistaken belief that:

They are a security measure rather than a resource allocation measure

A cgroup cannot be escaped by the process inside it

Both of these are wrong and if you approach it as true you just live in a false sense of security. Cgroups are as advisory as niceness is. While obviously the root user can assign a less privileged process to cgroup limits which it can't escape, a process that runs as at the same privileges as the process that assigned it those cgroups (typically itself) can just escape them no problem.

They are definitely super useful though, together with a lot of other things like Namespaces and Seccomp but it's certainly not all sunshine and their introduction has hurt some causes by giving people, including developers of whom you think they should know better, a false sense of security.