It's come up in interesting cases.
I can't remember which package it was, but there was one package that was distributed under the humourous "Don't Be Evil License", where you could "use this software for anything that's not evil" or something like that.
This technically does not qualify as free software (freedom 0 must allow anyone to use it for evil), so Red Hat (I think it was?) had to get their lawyers to contact the developer and get him to give them an exemption to the licence, just in case one of their users used it for evil.
It's a website that's managed by a community of pirates.
It's invite-only (meaning you have to be invited by an existing user) and you will have your membership revoked if you don't follow certain rules (mostly about seeding).
The .torrent files you get from them are specific to that private tracker, so no one who's not also a member of the same site can see which files you're seeding.
Indeed.
Licensing usage of something is antithetical to free software culture anyway.
It would violate the Free Software Foundation's Freedom Zero, that you should never have to accept a licence to use something.
(This is why free software cannot ever have a EULA, for instance)
ZFS, mostly.
There are some smaller peripheral things (like much better manpages), but these days the big one is probably ZFS.
Zero licensing conflicts allows it to be an integral part of the kernel.
It's a bit more complicated than that.
System load is a count of how many processes are in an R state (either "R"unning or "R"eady).
If a process does disk I/O or accesses the network, that is not counted towards load, because as soon as it makes a system call, it's now in an S (or D) state instead of an R state.
But disk I/O does affect it, which makes it a bit tricky.
You mentioned swapping.
Swapping's partner in crime, memory-mapped files, also contribute.
In both of those cases, a process tries to access memory (without making a system call) that the kernel needs to do work to resolve, so the process stays in an R state.
I can't think of a common situation where network activity could contribute to load, though.
If your swap device is mounted over NFS maybe?
Anyway, generally load is measuring CPU usage, but if you have high disk usage elsewhere (which is not counted directly) and are under high memory pressure, that can contribute to load.
If you're seeing a high load with low CPU utilization, that's almost always due to high memory pressure, which can cause both swapping and filesystem cache drops.
I'll go against the grain and say that's cool as heck!
Wikipedia says the designer (the guy flying/driving it, I think) has been working on it since the 80s.
I like people passionate about their hobbies.
Keep in mind that the tar "manual" does not actually call itself a "manual": it refers to itself as a "book".
It has 20 pages of preamble (5 title pages, discussions of the authors, descriptions of the intended audience, etc.)
It has another 20 pages elaborating on important structs in the tar source code.
The licence takes up another 10 pages.
The index at the end is 25 pages long.
It doesn't change the larger point that GNU is way bigger than Linux, though.
There are a tonne of things that are larger than Linux, and GNU is one of them.
The Villages and their sky-high STD rate would beg to differ.
(Edit: apparently that's just an urban legend.
Still, old people in The Villages are very social)
This is what I don't get.
Rewriting COBOL code into Java code is dead easy.
You could teach a junior dev COBOL (assuming this hasn't been banned under the Geneva Convention yet) and have them spitting out Java code in weeks for a lot cheaper.
The problem isn't converting COBOL code to Java code.
The problem is converting COBOL code to Java code so that it cannot ever possibly have even the most minute difference or bug under any possible circumstances ever.
Even the tiniest tiniest little "oh well that's just a silly little thing" bug could cost billions of dollars in the financial world.
That's why you need to pay COBOL experts millions of dollars to manage your COBOL code.
I don't understand what person looked at this problem and said "You know what never does anything wrong or makes any mistake ever? Generative AI"
Unfortunate title, but it's a good video and some good thoughts from both Linus and AC.
Interestingly, this video is just 2 years after Linus and Alan Cox had a bit of a blowup that caused AC to resign from the TTY subsystem.
And even more interestingly, the blowup was specifically about the very topic they're discussing: not breaking userspace and keeping a consistent user experience.
Linus felt AC had broken userspace unnecessarily, was too proud/stubborn to revert the change and save the user experience.
AC felt Linus was trivializing how easy "just fix it" was going to be and threw up his hands and resigned.
I was curious if they were still on good terms after that, and it's nice to see that they were.
For newcomers to Linux, Alan Cox used to be (in the 1990s) the undisputed Riker to Linus' Picard, the #2 in command, ready to take over all of Linux at a moment's notice.
As we got into the 2000s, that changed, and this video (2011) was from the middle of a chaotic time for him.
In 2009 he quit Red Hat, then joined Intel 2 years later, then quit shortly after that and has just a few years ago stopped kernel development permanently.
What kind of rube works in the same country they live in?
I met a lot of WFH workers when I visited Thailand, and not a single one of them was working for a company in Thailand.
It's come up in interesting cases. I can't remember which package it was, but there was one package that was distributed under the humourous "Don't Be Evil License", where you could "use this software for anything that's not evil" or something like that. This technically does not qualify as free software (freedom 0 must allow anyone to use it for evil), so Red Hat (I think it was?) had to get their lawyers to contact the developer and get him to give them an exemption to the licence, just in case one of their users used it for evil.