Linus Torvalds No Longer Knows the Whole Linux Kernel and That's OK (eweek.com) 119
darthcamaro writes: In a wide-ranging conversation at the Open Source Summit, Linus Torvalds admitted that he no longer knows everything that's in LInux. "Nobody knows the whole kernel anymore," Torvalds said. "Having looked at patches for many years, I know the big picture of all the areas in the kernel and I can look at a patch and know if it's right or wrong." Overall, he emphasized that being open source has enabled Linux to attract new developers that can pick up code and maintain all the various systems in Linux. In his view, the only way to deal with complexity is to be open. "When you have complexity you can't manage it in a closed environment, you need to have the people that actually find problems and give them the ability to get involved and help you to fix them," Torvalds said. "It's a complicated world and the only way to deal with complexity is the open exchange of ideas."
Blame Google (Score:2)
He probably just has too many search tools, so now he's more stupider.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
The only app that it can run is twitter. Anything else results in a kernel panic saying, "I never crash."
Re: (Score:2)
Steered clear of toxic community issues (Score:2)
Linus steered clear of toxic community issues and the interviewer softballed him on it, or actually completely glossed over it. Can't see that as a good thing, it looks a lot like the ostrich defence.
Re: (Score:3)
Re: (Score:2)
Let me google that for you. [google.com]
Re: (Score:2)
Re: (Score:1)
All those articles point to one idiot that quit because he couldn't take criticism.
First, that is an easily falsified lie (just read the links) and second, you outed yourself as one of the toxic assholes who helped ruin the Linux kernel community's reputation. Now you are being a toxic ass here. Sucks to be you.
Re:Steered clear of toxic community issues (Score:5, Informative)
I read them, they all concern Sarah Sharp, the looney feminist substandard kernel dev who tried to inject herself into a linux kernel ml thread she wasn't even a part of and bait Linus into saying something nasty to her and failed miserably do it. Standard SJW ploy targeting male leadership who aren't cowed by feminist bullshit. In shame, she had to leave the project. Not even sure if she's still employed by Intel anymore. Probably not.
OMG, they is hilarious!!
Sage Sharp @_sagesharp_Diversity & inclusion consultant at @ottertechllc. @outreachy organizer. Explorer of the kyriarchy. Hufflepuff. Non-binary (agender trans masculine). They/them.
Not even a programmer anymore. Pathetic.
Re: (Score:1)
I read them, they all [lie] concern Sarah Sharp, the looney feminist substandard kernel dev...
Your filth speaks for itself.
Re: (Score:1)
Re: (Score:2)
You must be lots of fun at parties
Re: (Score:1)
Every single person who uses the term toxic in this way is an absolute fucking moron. I'm glad you people use it, though, because it makes it easy to identify and ignore you wankers. You'll probably need to find a safe space to deal with this.
Re: (Score:2)
Re: (Score:2)
He doesn't let political crap into the kernel. One example here [freedesktop.org].
Comment removed (Score:4, Informative)
Re: (Score:2)
Dude's job is whatever his boss says it is. He who pays the piper calls the tune, not the entitled and obnoxious freeloaders of the Internet.
Re:stop it (Score:4, Insightful)
Nice excuse there, I guess (Score:1)
And that's how backdoors can be slipped into the Kernel by the big bad guys who are pretending to be fixing something or updating its drivers.
Complexity (in software) is indeed the enemy of security.
Spoken like a true idiot (Score:1)
"When you have complexity you can't manage it in a closed environment"
Try working in a manufacturing environment some time, Linus, because we manage the complexity all the time. For example, solar panels - HUGE amounts of detail you need to pay attention to (even one bad solder joint destroys a panel during lamination) and yet we manage this all the time, with all of our documentation very much closed off to the outside world. Hell, we even manage our constantly-changing crew, and there's not much of a prob
Re: Spoken like a true idiot (Score:1)
Elon?
Software more efficient? (Score:5, Interesting)
"Performance is not really doubling every two years and that's good," Torvalds said. "It means we'll maybe go back to the time when you cared more about performance on the software side and you had to be more careful and couldn't just rely on hardware getting better."
He's wrong: it means we'll just get slower and slower software because hardly anyone knows how to do anything besides paste libraries together.
Re: (Score:2)
He's wrong: it means we'll just get slower and slower software because hardly anyone knows how to do anything besides paste libraries together.
Except when they write massive kludges of spaghetti code that should have been a library or used the standard library. It's not that libraries are inherently bad, I mean you couldn't even write print( "Hello world!" ) without something interpreting letters to bitmaps and defining what a "standard output" is. The problem is often that these libraries grow because there's always one more use case to cover until they become huge and complex. At which point somebody decides fuck it, I don't need this let's just
Re: (Score:2)
. It's not that libraries are inherently bad,
It's not that libraries are inherently bad, but a lot of the ones powering the 'modern' web are bad.
Re: (Score:2)
Bill neither (Score:2)
Re: (Score:2)
He denied ever saying such a thing. And to be fair, that was a lot back then. Most 1980s home computers maxed out at 64 KB.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Gates wrote code, did Jobs?
Re: (Score:2)
Re: (Score:2)
True for many years now (Score:2)
Linus quote (Score:5, Insightful)
"It's a complicated world and the only way to deal with complexity is the open exchange of ideas."
This is a quote that Mr. Torvalds should be known for, forever. It applies to much more than just software.
Re: (Score:2)
You are correct. The quote should go down in history as the turning point towards more "individual friendly" governing systems. But then, the architecture of the kernel itself says that we will never see these systems materialize. *sigh*
Re: (Score:3, Insightful)
I'll bite the flamebait regarding monolithic vs micro kernels.
The assertion that Torvalds not knowing all of what in Linux simply means that those subsystems were logically delegated out. In a microkernel, those same subsystem functions would still be done by a different group, except they wouldn't be in kernel.
Simply because a kernel is "monolithic" doesn't mean that there aren't subsystems that your primary kernel architect needs to fully understand. For example, a video driver. That's very specific kn
Re: (Score:3)
Mach. [wikipedia.org] Good enough?
Re: (Score:2)
You better be trolling.
Re: (Score:2)
Mach (and BSD) are used in Apple's various OSes. Does that qualify as "reasonable amount of usage and performance" of the original comment?
Not really. Apple uses Mach as a HAL. All process management is done by the monolithic BSD kernel which runs atop Mach. That's why OSX is not a microkernel-based system any more than NT (which also has a HAL.)
Re: (Score:2)
L4, QNX are probably the top 2. And performance is tied to old hardware limitations and models, which make context switches expensive. A cpu better suited to micro-kernels, like the Mill could bring about a different story. If a context switch cost 5-10 cycles instead of hundreds, all of a sudden the micro-kernel architecture looks a lot better.
Re:Monolithic Kernels (Score:5, Interesting)
I love microkernels and have written a few for personal entertainment. I have even been following Fuschia OS's development quite closely... though I can't believe anyone would make something that shitty from the ground up in 2018.
A more or less monolithic with a pluggable and stable ABI and API is often the best of both worlds. Add some form of module signing and code review process and we're in a good place.
After all these years, there has been ample opportunity to optimize microprocessor design to make a better microkernel CPU. There is generally just too much cost involved in the constant context swaps for a desktop OS. Remember that we spent many years trying to trim the fat between application and graphics subsystems. Even today, it's pretty simply to almost devastate the performance of a micro kernel with a massive amount of disk I/O operations.
Last month, I wrote a new Linux kernel module. I needed to implement the Cisco Discovery Protocol on Linux in a less stupid way than it's been done until now. I believe I achieved doing it equally dumb from an opposite direction. This is because the Linux Kernel is an enormous disaster of crap on crap.
Let's talk about something relatively simple that should have been ripped out and entirely moved out of the kernel a LONG time ago... the network stack.
The Linux network stack is amazingly fast and should be given credit for being that way.
It's also a cesspool of shit code from almost end to end. Probably the most important piece of code in the Linux kernel is sk_buff. Oh... sk_buff, you are the biggest, ugliest and shittiest piece of code in the entire world. I mean... you're a buffer... a kinda sorta reference counted buffer which never really gets deleted...except when you do. You're a huge chunk of trash code that looks like you were designed by a drug fuddled preschooler that wanted to try daddy's C compiler while on a series trip.
sk_buff is probably the most critical piece of code to keep the documentation up to date on. This is the code which makes things like kernel panics in the weirdest ways when even the slightest thing goes wrong. And yet, after 27 years of Linux, you guys still can't seem to stabilize the API for the frigging network buffer!!!
Then let's consider procfs...
So... procfs is basically the ability for a user mode application to access a file and it calls procedures for reads and writes... well all files in the kernel work that way, but procfs is a bit special, it was meant to be informative and work in a printf'ish kinda way.
procfs for the most part is nothing more than, open, read, write, seek, close. It doesn't need anything other than that. It's a simple random access file stream.
Somehow, the API is still changing like mad... and worse the transition mechanisms that support the newer APIs are actually getting removed from the kernel
I was looking into adding a new address family to the kernel for CDP... and I tried looking at other code for a good example. I absolutely refuse to make pull requests to the Linux kernel unless it's a bug fix (and deleting the whole tree and starting over doesn't count). I believe that tools like DKMS should point to git repositories and download drivers and build them against the kernel. CDP does not need to be part of the mainstream kernel. It's a tool.
Well, as I said, I was looking into it. And after this many years, because of the absolute shitty state of the kernel... I'd at least have to register AF_CDP and PF_CDP somewhere so that I could have my very own protocol number. And for the most part, that would prob
Re: (Score:3)
After all these years, there has been ample opportunity to optimize microprocessor design to make a better microkernel CPU. There is generally just too much cost involved in the constant context swaps for a desktop OS
The reason that microkernels suck has nothing to do with context swap inefficiencies. The biggest problem is trying to maintain a synchronised state between the different tasks across different memory protection areas.
A simple example is a file system. Imagine a dozen different tasks, all working on the same file system, As soon as one task makes a change (say, delete a file), all other tasks are working with an outdated snapshot of the file system state. Unless notified of the change, this will lead to cor
Re: (Score:2)
You have no idea what a microkernel is right?
Re: (Score:2)
Of course I do. The key feature of a microkernel is that it uses different access spaces. with protection barriers between them. In contrast, a monolithic kernel has shared access spaces, so different tasks can modify the same data and keep common state synchronized.
That's the only really important difference.
Re: (Score:2)
Looking at some other tasks state involves two context switches - to that other task and back to the current.
Looking at another task's state means making a copy of the state, a snapshot if you will. As soon as you make a copy, you now have two versions. Right after you make a copy, before the 2nd task can even examine it, the original state can change again.
To be efficient on a large server, it obviously has to support many parallel threads of execution - but should still be a single memory context
Yes, that's very efficient. That's what a monolithic kernel does.
Re:Monolithic Kernels (Score:5, Insightful)
Re: (Score:2)
C++ has some of the features you mention, such as vectors. Proposals to introduce C++ to the kernel are quickly rejected.
Kernel code is bound to be difficult. I've often thought, for drivers, maybe a compatibility layer that presents a nice stable API can be provided for people to write drivers for (not forced, the internal API can also be exposed), but as another option.This would avoid cluttering kernel internals with backwards compatability stuff but would provide a nice stable API for drivers to use.
Re: (Score:2)
If people did that it would certainly address a lot of their concerns about C without needing a new language