chr15p's comments

google tells me "IBM gross profit for the twelve months ending June 30, 2025 was $36.866B"

Its not that someone writes that sort of stuff, its that it people read and think "yeah! give me some of that!" that makes me worry for humanity.

> To save everybody's time: this is about straight white men making an OS for them and thus terrible for everybody else.

That's not what the talk is about, that's one of the examples of brokenness he's talking about, as is the kill example, and yes they are deliberately troll-y examples.

The talk is about the very last statement "sometimes you have to drop your tools and make new ones" whether that's "everything is a file", "do one thing and do it well" (the ps example), or the way communities are structured. You don't have to agree with him on any of them but to dismiss them as "whitestraightmansplaining" is to duck as the point flies over your head.

I don't think it is a pissing context between them, they can both happily exist in the same world, it just interesting to see the difference in approach and try and figure out why one seems more successful than the other.

I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)

Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.

> Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone.

This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum.

I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources to do everything by themselves.

Compare that to Red Hat who always try (and sometimes even succeed!) at developing projects with the community and are far more successful at getting their projects adopted (I know people don't like them, but you cant deny they are effective at it)

no. I don't think that was even a thing in the RHEL7 version I last did and the whole exam/course has changed a lot since then.

I'm sure there are lots of places that still use vsftpd though (I have a vague memory that it supported kerberos at least), so it might still be useful for some people

The coursebook I got as part of the training course, this was 5+ years ago so we got a physical book. I've no idea what they do these days but there's a list of exam objectives on the red hat website and that basically covers what you need to know

To me there are a few benefits of doing exams (at least the Red Hat ones that are not cheap, but well respected):

1) it looks good on the resume, which can help you get past the initial sift by people who dont understand what your experience actually means.

2) They give you the chance to fill in the gaps in what you think you know. My experience of doing my RHCE after 10 years of professional sysadmining was of the 14 chapters in the book I knew maybe 10 already and had never touched the other 4 because they never came up in my job, and the prospect of a looming exam gave me a deadline and the motivation to actually sit down and learn them, which then paid off later in other jobs that did use them.

3) to test whether you are as good as you think you are :)

If those don't speak to you then they're probably not super important to do, luckily we mostly work in an industry where experience trumps exams.

To be honest if the worst thing you can say about a company is they changed the distribution model of the thing they were giving you for free from point releases to rolling updates then they could be a lot worse.

But to selectively quote from slightly further down TFA:

> Krishna’s strategy has been focused on bolstering the company’s offerings in hybrid cloud — providing services to customers that run their own data centers in some combination with public cloud

i.e. making it easier to move between data centers and cloud, and back again, so if "companies are taking a look at how much they are spending on cloud." then sounds like IBM are skating towards where the puck is going.

For Oct-Dec 2022 (according to https://www.ibm.com/investor/att/pdf/IBM-4Q22-Earnings-Chart...)

Mainframes: $4.5 billion

Consulting: $4.8 billion (even after selling off Kyndral)

Software: $7.3 billion

Software includes all of Red Hat, a pretty big security business, and "transaction processing" which isn't explained but I guess is running payroll and the like for other companies.

So lots of un-sexy stuff that never makes HN but keeps the world running.

To make written English you need to take 1 part Old (Anglo-Saxon) German, 1 part old Norse, and 1 part old French, stir together for a couple of centuries, then, just as its going though a major pronunciation shift have its spelling formalised by a random bunch of academics with an unhealthy obsession with latin and greek. Fianlly throw away a bunch of letters because the Germans and Itallians who made block type lettersfor printing presses had never heard of them, and bodge your spelling back together using whatever you can just about get away with. (Bring back Thorn!)

Then sit back and get very upset with anyone who tries to remove the 'u' from colour.

that was a discussion of a previous blog post by the same author (Mathew Garrett). Its on the same subject but this one is much longer and goes into much more detail.

Its not impossible, but it needs someone to figure out how to monetize desktop linux so they can then put the marketing effort in and pay a few companies to port big name apps such as photoshop that would give it some momentum and mindshare. A single profitable desktop would then give other companies a good target to port their own desktop software too, which would encourage more users and get to a virtuous circle.

But without that (and no one has figured out how to do it so far) I agree, I cant see it happening.

a million nodes running a single application is scale, but a thousand nodes running a thousand applications is also scale, and they are very different beasts.

The FAANGs operate the first kind, k8s is mostly aimed at the second kind scale, so its designed "for scale", for some definitions of scale.

A kernel module doesn't have to match the kernel version, it has to be able to resolve all the symbols (function calls, variables etc) it uses into valid symbols supplied by the kernel you are loading on.

The greater the difference between the kernel version you compiled for, and the kernel version you are trying to load it on, the greater the chance something you are relying on changed and the module loader cant resolve all the symbols and so it fails.

So saying a kmod has to match the kernel version is good practice but the reality is not quite as strict.

Red Hat has a list of "white listed" symbols that they try to maintain across a major version of RHEL so if your kmod only relies on them and nothing else then it should load on any kernel version within that release. But that's a Red Hat thing, not a Linux kernel thing.

# CONFIG_SECURITY_LANDLOCK is not set

CONFIG_LSM="lockdown,yama,integrity,selinux,bpf"

on kernel 5.14.0-70.13.1.el9_0.aarch64

So not on ARM at least

Ansible and tmux require a lot more knowledge to be effective with than cockpit does, if you have that knowledge great, but if you have fairly low (linux) skilled first line support or junior sysadmins then giving them a gui lets them solve lots of basic issues without escalating.

sesearch -A

That shows the list of what labels are allowed to do what to which labels, so run ps -Z to get the label of your process and grep the sesearch output for it, and that will tell you what labels it's allowed to interact with and in what ways.

selinux is generally pretty straightforward, but it has a reputation for being impenetrable which puts people of trying to learn it.

sesearch lets you query the rules on a system.

sesearch -A will show you every thing that is allowed, and gives you (a lot of) lines like:

allow httpd_t httpd_t:dir { getattr ioctl lock open read search };

Which says that things (i.e. processes) with the httpd_t label are allowed to perform getattr, ioctl, lock, open, read, and search operations on directories with the httpd_t label.

ps -Z and ls -Z will then list the labels of processes, and the labels of files and directories. If your processes label does not have an allow rule for your file label for the correct action you are denied.

The only trick really is that when it reports a label as say "system_u:system_r:httpd_t:s0" thats 4 different colon separated fields and the only one you really care about is the type field "httpd_t", because thats what the rules are defined for (unless you're the NSA or doing Very Interesting things (the other fields are user, role, and security level, but the default Red Hat etc selinux policies dont use them))

There is no wiki with definitive list of labels because they are just strings and the policy writer can call them what they like, even the _t suffix is just a convention to denote the type.

AppArmour assumes everything is allowed unless it is explicitly denied by policy, SELinux assumes everything is banned unless it is allowed by policy. This makes SELinux fundamentally more secure because unlike apparmour you cant forget to deny some access that leaves you wide open, instead you forget to allow things and your app breaks. It also makes SELinux more complicated to implement because you have to allow everything you need or your app breaks whereas apparmour lets you deny the things you're worried about and ignore everything else.

SELinux also supports interesting things like applying security levels and contexts to data, so you can have data that is only accessible to appropriatly cleared users in one department but not to people with similar clearances in other departments. Very few people use this stuff though.

Selinux uses extended attributes to store its labels which is a pretty standard way of associating metadata with objects, and is supported by most standard unix commands (via the -Z flag) so I'm not sure what you mean by "filesystem hacks". Fundamentally they are both implemented as security modules in the kernel and do pretty much the same thing, which is best depends on whether the added security of SELinux is worth it to you.