Linus Torvalds No Longer Knows the Whole Linux Kernel and That's OK (eweek.com)

← Back to Stories (view on slashdot.org)

Linus Torvalds No Longer Knows the Whole Linux Kernel and That's OK (eweek.com)

Posted by BeauHD on Friday August 31, 2018 @12:45PM from the don't-panic dept.

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."

119 comments

Min score:

Reason:

Sort:

Linux begat Android by Anonymous Coward · 2018-08-31 12:52 · Score: 0

and for that sin, every Linux nerd everywhere deserves all the swirlies they get
No, this is not okay by Anonymous Coward · 2018-08-31 12:52 · Score: -1

Looks like hes got the dumbs, the SystemDumbs!
Monolithic Kernels by Anonymous Coward · 2018-08-31 12:52 · Score: -1

Are bad. Yet another example.
1. Re:Monolithic Kernels by Anonymous Coward · 2018-08-31 13:44 · 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 knowledge that you wouldn't expect Torvalds to really need to know.
  In a lot of ways Torvalds has moved on to more of a project manager/architect role than just a straight code hacker.
2. Re:Monolithic Kernels by Anonymous Coward · 2018-08-31 15:25 · Score: 0
  
  Monolithic is a problem if you don't update subsystems and there's inertia to push out a new kernel version for that reason, anything else is whining.
3. Re: Monolithic Kernels by Anonymous Coward · 2018-08-31 16:50 · Score: 0
  
  So when a microkernel exists that has a reasonable amount of usage and performance Iâ(TM)ll listen to the microkernel whiners.
  You donâ(TM)t have jack and shit... and jack left town.
4. Re: Monolithic Kernels by Stormwatch · 2018-08-31 17:47 · Score: 2
  
  Mach. Good enough?
  
  --
  Circumcision is child abuse.
5. Re:Monolithic Kernels by LostMyBeaver · 2018-08-31 17:51 · Score: 5, Interesting
  
  There is something in-between.
  
  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'm not talking about a few years after stabilizing, I'm talking as soon as the monster code base called the kernel no longer depends on them. Forget that there are external modules build from DKMS other other tools that need to handle different versions. And we're not talking about massive APIs, we're talking about things that support name changes.
  
  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
6. Re: Monolithic Kernels by Anonymous Coward · 2018-08-31 18:20 · Score: 0
  
  Well lets hope one day you're lucky enough to be one of the 30 people who get to write software for it
7. Re:Monolithic Kernels by religionofpeas · 2018-08-31 19:49 · Score: 2
  
  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 corruption. And notifying all tasks of every little change would be hugely inefficient, not just because of all the overhead of sending the messages, but also because tasks would need to be made with frequent check points. In the end, it would do nothing to simplify the overall system, because you'd basically be implementing a virtual shared memory, and you'd have to deal with exactly the same issues as with a real shared memory.
  The tradition solution in microkernels is to have a single task running the file system. This may be a practical idea on some small scale single user systems, but it's totally unacceptable on a larger server, say a big web server with a few hundred simultaneous connections.
8. Re:Monolithic Kernels by Anonymous Coward · 2018-08-31 20:01 · Score: 0
  
  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.
  I haven't looked at it, but you saying that doesn't surprise me. And it's an important hint.
  How does this work? Someone up and says "I want a better OS". I myself have thought this on many occasions. And true to form, someone with half a clue but no experience just goes and builds it. And because they didn't look very closely at what had come before, they end up with something shitty. linux is a case in point, and look how popular it is.
  
  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.
  There's a long way between the hardware and the software guys. The hardware guys get idiotic ideas like buying a third party company for eight milliard dollars so they can patch up certain specific software's failings in hardware. Turns out that's a lot of money wasted. The software guys just want to fix it all in software.
  Yeah, there's been lots and lots of opportunity, but somehow the few in the rigth places didn't manage to even try.
  Shit, you could have had a dual core 10 Watt CPU, MIPS64 laptop back in 2000 or so, but nobody thought to build one. Well, I did but I had neither the money nor the contacts to make it happen. You could have had something good but all anybody did was build more laptops for the suitwearing crowd. What do they know of good software? Look at what they're using!
  The same with servers. "Real servers are headless", but these days they have entire secondary computers built very deeply into the system to emulate that head over the network. That's just bad and wrong on so many levels. But it's what "everyone" does. Reasons why left as an exercise.
  So no, this is what you get when there's nobody with serious vision around: A lot of derping. There has been no meaningful pressure from the market to make microkernels work well in the hardware, so all that opportunity, wasted.
  
  The Linux network stack is amazingly fast and should be given credit for being that way.
  Not the only one that's nice and fast, mind.
  
  Then there's the fun we call "finding shit in the Linux headers".
  Unix traditionally came with very good documentation. Something that didn't quite carry over into the linux (and gnu) world.
  
  And finally... the programming language thing.
  So you'd make a "better" C just to make a "better" Unix in? I don't think that flies. Again, reasons why left as an exercise.
  
  I suppose I could go on and on. But let's face it... sooner or later things like Redox will get proper support.
  Because having a language with a CCoC is a neat feature to have. Nevermind its dependencies on C++ and the inability to bootstrap the compiler on other hardware. It's the CCoC that makes all the difference.
  
  We can't keep depending on Linux. It's just ancient technology which isn't even proven... it's more like "what else is there?"
  It's very well proven. It's a giant pile of poo but it's been in use so widely that people feel comfy with it. Same with windows, by the by. That is an even bigger pile of poo and even more popular.
  But if your best answer to "what else is there?" is an OS with its one and only reason to be promotion of a shitty language with a large ideological chip on its shoulder, you haven't looked around very much.
9. Re:Monolithic Kernels by Anonymous Coward · 2018-08-31 20:11 · Score: 0
  
  I semi-agree with a lot of your rant until you went off on C. Writing secure code has very little to do with the language and a lot to do with the programmer. I've seen code in python, java, c#, c++, typescript just this year that you can drive a bus through .. simply because the programmers haven't got a clue about security. Writing secure code is about understanding all possible interactions and making sure you code still works as designed. It's then about ensuring that "works as designed" is the safe thing to do
10. Re: Monolithic Kernels by Stormwatch · 2018-08-31 20:43 · Score: 1
  
  You better be trolling.
  
  --
  Circumcision is child abuse.
11. Re:Monolithic Kernels by Zero__Kelvin · 2018-08-31 22:56 · Score: 4, Insightful
  
  What did Linus say when you used your obviously elite dev skills to rewrite sk_buff elegantly and submitted it to him and his team for review?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
12. Re:Monolithic Kernels by Megol · 2018-08-31 23:03 · Score: 1
  
  You have no idea what a microkernel is right?
13. Re:Monolithic Kernels by religionofpeas · 2018-09-01 00:38 · Score: 1
  
  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.
14. Re:Monolithic Kernels by Anonymous Coward · 2018-09-01 01:35 · Score: 0
  
  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.
  
  That example is silly. "Outdated snapshot?" You don't keep copies of state, you keep only one state and query that at every use. That way, nothing to 'synchronize', no "snapshots" to 'get old'.
  Of course, now you have the cost of querying that filesystem state. In the monolithic kernel, this cost is no higher than looking at some local snapshot, which is the reason no local snapshots are ever made. Linux tries to do "zero copying", and a snapshot is a copy that simply takes too much time. And of course, a snapshot provides zero benefit for its substantial cost in the monolithic kernel.
  In a microkernel, looking at some other tasks state may cost more - and that is precisely the context swaps you claimed wasn't the problem. Looking at some other tasks state involves two context switches - to that other task and back to the current. Just like when userspace makes a system call into the kernel. Only now you get this overhead inside the microkernel too - whenever a task boundary has to be crossed.
  Call it "messages" if you like, but that is a high-level construct. Passing a message between two tasks really is a couple of context switches, on the low level of things. If you want to talk about kernel architectures, you should understand that much.
  
  The tradition solution in microkernels is to have a single task running the file system. This may be a practical idea on some small scale single user systems, but it's totally unacceptable on a larger server, say a big web server with a few hundred simultaneous connections.
  Huh? A file system had better be in a single memory context (a "task"), so it won't be slowed down by internal context switching. 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. For these reasons, a microkernel with only one thread per memory context won't be useful for big servers. (Either losses to internal context switching, or single-thread inefficiency.) But if you design a kernel, you can of course have a multithreaded microkernel. If each task is big enough - such as one task being the entire file system - then maybe you can have an efficient microkernel with a little more internal protection than a monolithic kernel. But only a little. If the file system task crashes, the other tasks may be isolated from that disaster. But your server is dead for all practical purposes anyway - so where is the micorkernel advantage?
  And additionally - a webserver with a few hundred simultaneous connections is nowhere near "big", and it will work just fine with a single-threaded file system. "Big" is more than that!
15. Re:Monolithic Kernels by religionofpeas · 2018-09-01 01:56 · Score: 1
  
  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.
16. Re:Monolithic Kernels by Anonymous Coward · 2018-09-01 02:51 · Score: 0
  
  this guy has no idea what he's talking about. usually you would have one server managing the filesystem that would manage filesystem state, no need to synchronize data. the big problem has long been the context switches because internally the kernel has to context switch between different kernel subsystems, when the kernel is running, to perform its various tasks, whereas with monolithic, it does not need to.
17. Re:Monolithic Kernels by Anonymous Coward · 2018-09-01 04:23 · Score: 0
  
  Wow. I don't want to hear why you don't/can't write a few simple string or collection functions in C.
18. Re:Monolithic Kernels by Anonymous Coward · 2018-09-01 05:18 · Score: 0
  
  >I love microkernels and have written a few for personal entertainment.
  Fucking nerd. You should try getting laid once in a while.
19. Re:Monolithic Kernels by Eravnrekaree · 2018-09-01 07:24 · Score: 1
  
  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.
20. Re:Monolithic Kernels by Eravnrekaree · 2018-09-01 07:25 · Score: 1
  
  If people did that it would certainly address a lot of their concerns about C without needing a new language
21. Re:Monolithic Kernels by Anonymous Coward · 2018-09-01 07:47 · Score: 0
  
  Of course you can always roll your own, but is it preferable to have a million different custom solutions in place of 1 or 2 standard supported features?
22. Re: Monolithic Kernels by WorBlux · 2018-09-02 04:18 · Score: 1
  
  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.
Blame Google by Aighearach · 2018-08-31 12:52 · Score: 1

He probably just has too many search tools, so now he's more stupider.
1. Re:Blame Google by Anonymous Coward · 2018-08-31 18:05 · Score: 0
  
  Time to AI the sucker that is the Linux kernel.
Open source is winning. by Anonymous Coward · 2018-08-31 12:52 · Score: 0

Winning
Winning
1. Re: Open source is winning. by Anonymous Coward · 2018-08-31 12:57 · Score: 0
  
  Is there a TrumpOS?
2. Re: Open source is winning. by jfdavis668 · 2018-08-31 13:06 · Score: 1
  
  No, but there is a Palm OS.
3. Re: Open source is winning. by Anonymous Coward · 2018-08-31 13:12 · Score: 0
  
  but its small.
4. Re: Open source is winning. by Anonymous Coward · 2018-08-31 13:17 · Score: 0
  
  It runs on your hand, main task is lube dispensing.
5. Re: Open source is winning. by Tyr07 · 2018-08-31 13:20 · Score: 0
  
  TrumpOS: What does it do? No one knows, they can't get past the startup because the boot logo hurt their feelings.
6. Re: Open source is winning. by Anonymous Coward · 2018-08-31 13:48 · Score: 1
  
  The only app that it can run is twitter. Anything else results in a kernel panic saying, "I never crash."
7. Re: Open source is winning. by Anonymous Coward · 2018-08-31 13:59 · Score: 0
  
  Is there a TrumpOS?
  "I'm the most stable, and the least racist, OS that ever existed !"
8. Re: Open source is winning. by Anonymous Coward · 2018-08-31 14:29 · Score: 0
  
  And only a special Russian version of Twitter from a reliable source.
9. Re: Open source is winning. by Daemonik · 2018-08-31 17:02 · Score: 1
  
  TrumpOS loudly declares all other OSes to be enemies of the people and fake data.
10. Re: Open source is winning. by Anonymous Coward · 2018-08-31 18:44 · Score: 0
  
  Isn't that Windows
11. Re: Open source is winning. by Anonymous Coward · 2018-08-31 20:32 · Score: 0
  
  It grabs the PussyOs.
Steered clear of toxic community issues by Tough+Love · 2018-08-31 13:49 · Score: 1

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.

--
When all you have is a hammer, every problem starts to look like a thumb.
1. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 14:14 · Score: -1
  
  stupid trannies are stupid and everyone knows that
2. Re:Steered clear of toxic community issues by guruevi · 2018-08-31 14:32 · Score: 2
  
  What toxic community issues? The Linux kernel is going well regardless of small skirmishes in the political arena. It's good that Linus steers clear of them because nobody wins.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
3. Re:Steered clear of toxic community issues by Tough+Love · 2018-08-31 15:06 · Score: 1
  
  Let me google that for you.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
4. Re:Steered clear of toxic community issues by guruevi · 2018-08-31 15:22 · Score: 1
  
  All those articles point to one idiot that quit because he couldn't take criticism. Being criticized is not toxic.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
5. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 15:35 · 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.
6. Re:Steered clear of toxic community issues by Tough+Love · 2018-08-31 16:24 · Score: 0
  
  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.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
7. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 16:55 · 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.
8. Re:Steered clear of toxic community issues by Tough+Love · 2018-08-31 17:03 · Score: 0
  
  I read them, they all [lie] concern Sarah Sharp, the looney feminist substandard kernel dev...
  Your filth speaks for itself.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
9. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:07 · Score: 0
  
  I'm male and I bet you're an even larger turd in the office.
10. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:08 · Score: 0
  
  The truth is in the muck.
  captcha: sloppy
11. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:14 · Score: 0
  
  1. I doubt you're male.
  2. I'm an even larger turd in your mom's ass.
12. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:24 · Score: 0
  
  wish i could upvote a million times
13. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:31 · Score: 0
  
  I expect that your analysis is more or less correct, but it is still pretty toxic. If you improve the wording, readers would only think badly of her, rather than of both of you.
14. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:33 · Score: 0
  
  LOL
  Love this... they respond to you with "Google it"
  having spent a couple of years, targeting Torvalds, whining about him and filling up blogs with shite and false allegations.
  These people are scum - they are the true toxicity in IT.
15. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 17:57 · Score: 0
  
  I'll go it alone, that's how it must be
  I can't be right for somebody else
  If I'm not right for me
  I gotta be free, I've gotta be free
  Daring to try, to do it or die
  I've gotta be me
  captcha: regret
16. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 18:32 · Score: 0
  
  No definately while we're at it, we should make sure people are verbally competent. If you can't speak then that's toxic. Obviously since autism doesn't exist it's no biggie to ask people to simply be polite we must be able to do the same to people of other disabilities.
17. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 20:24 · Score: 0
  
  I'm male and you can go fuck yourself.
18. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 22:03 · Score: 0
  
  Talking to yourself again? No wonder shit doesn't get done around here. This is the shit you get up to over the weekend.
19. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-08-31 22:11 · Score: 0
  
  Peak SJW was 2015 chief. Nobody cares about your blathering anymore lol.
20. Re:Steered clear of toxic community issues by Zero__Kelvin · 2018-08-31 23:00 · Score: 1
  
  He said in the Altoa talk that "People who are offended should be offended." In other words he is well aware that it keeps people like you away, and that is a good thing ... a very, very good thing.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
21. Re:Steered clear of toxic community issues by guruevi · 2018-09-01 01:08 · Score: 0
  
  I think it's you and your leftist marxist fascist kind that is the toxic one. Read the links, follow up on the person, they are the toxic ones that destroyed the left and the mainstream media. The fact you don't realize this means you are just as toxic.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
22. Re: Steered clear of toxic community issues by Anonymous Coward · 2018-09-01 03:34 · Score: 0
  
  SJW is an acronym used by the mindless.
23. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-09-01 04:38 · Score: 0
  
  There is really no gender discrimination to speak of, anyone should submit a patch who feels they have something quality, and it should be evaluated on its merits. No one is objecting to that. The idea that patches would be rejected because they come from someone with particular genders or other traits is just absurd, no ones going to turn down something that benefits the project and virtually no one is sexist and has these ideas people of certain genders should not be involves, such would be a ridiculous notion. The objections are to these SJWs going around everywhere and screaming about discrimination and trying to make false accusations, frame and set up people and create huge controversies where there are none. Thats whats toxic. You go into a mailing list or other project and you start pointing the finger at people and screaming at them that they are sexist bigots, and you expect to not be considered to be a toxic? Its these SJWs that are toxic.
24. Re:Steered clear of toxic community issues by Tough+Love · 2018-09-01 13:42 · Score: 1
  
  You must be lots of fun at parties
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
25. Re:Steered clear of toxic community issues by Anonymous Coward · 2018-09-01 13:42 · Score: 0
  
  Where is the tolerance for people who speak their mind? Or is gender tolerance all that matters.
26. Re:Steered clear of toxic community issues by KiloByte · 2018-09-01 23:31 · Score: 1
  
  He doesn't let political crap into the kernel. One example here.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
It's OK because ... by thadtheman · 2018-08-31 14:10 · Score: 0, Troll

the real OS is systemD. PS: I win the "first systemD comment" contest.
1. Re: It's OK because ... by Anonymous Coward · 2018-08-31 17:30 · Score: 0
  
  Lol
stop it by ArylAkamov · 2018-08-31 14:26 · Score: 3, Informative

"and that's okay"
I agree in this case. However. Stop trying to tell me how to feel and think, you cunt. Your job is to report.
1. Re:stop it by Jeremi · 2018-08-31 14:41 · Score: 1
  
  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.
  
  --
  
  I don't care if it's 90,000 hectares. That lake was not my doing.
2. Re:stop it by Anonymous Coward · 2018-08-31 15:44 · Score: 0
  
  Grow a sense of humour, cunt.
3. Re:stop it by Anonymous Coward · 2018-08-31 16:31 · Score: 0
  
  This argument might work if journalists weren't trying to be a special class, and claiming that they have higher responsibilities and deserve more consideration and respect than the average person.
4. Re:stop it by Anonymous Coward · 2018-08-31 17:26 · Score: 0
  
  It's the buzzfeed/blogger asshole style of writing:
  [controversial statement] - and that's ok.
  A fucking plague on the lot of them
5. Re: stop it by Anonymous Coward · 2018-08-31 17:33 · Score: 0
  
  Your momma is so fat I rolled over twice and I was still on the bitch and that's okay. I see what you mean!
6. Re:stop it by Anonymous Coward · 2018-08-31 17:46 · Score: 0
  
  "and that's okay"
  I agree in this case.
  No, no it isn't. It's a weakness that would have been avoided by not putting so damn much stuff in the kernel.
  
  However. Stop trying to tell me how to feel and think, you cunt. Your job is to report.
  What, are you saying you aren't a dumb consumer that needs to be fed moral upbringing from the press? What do you think the press thinks the press is for?
7. Re:stop it by Anonymous Coward · 2018-08-31 20:05 · Score: 0
  
  Cunts.
8. Re:stop it by Zero__Kelvin · 2018-08-31 23:02 · Score: 3, Insightful
  
  Linus says it is OK (as in not some OMFG issue to be concerned about) and the reporter reported that. DOH!
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
9. Re:stop it by Anonymous Coward · 2018-09-04 03:27 · Score: 0
  
  Well, it still doesn't alter the fact that headlines sometimes leave ambiguity. What could have been used as the headline:
  
  Linus Torvalds No Longer Knows the Whole Linux Kernel And Says That's OK
  And that works without quote marks!
Nice excuse there, I guess by Anonymous Coward · 2018-08-31 14:39 · Score: 1

"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,"

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 by Anonymous Coward · 2018-08-31 15:22 · 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 problem there, either.
You just can't manage the complexity it because you lost 100% control. Admit it. Just like you lose control of your mouth.
1. Re: Spoken like a true idiot by Anonymous Coward · 2018-08-31 17:13 · Score: 1
  
  Elon?
2. Re:Spoken like a true idiot by Anonymous Coward · 2018-08-31 17:20 · Score: 0
  
  >Admit it. Just like you lose control of your mouth.
  Look, you whiney Intel developers are gonna just have to toughen up. You deserve every bit of scorn heaped on you by Linus. And stop bad mouthing him anonymously you cowardly shits.
3. Re:Spoken like a true idiot by Anonymous Coward · 2018-08-31 19:45 · Score: 0
  
  Bitchy with Linus eh hoser? Lose control of something important ... like yo azzwhole? Eat-crap snot-boi.
4. Re:Spoken like a true idiot by Anonymous Coward · 2018-08-31 21:30 · Score: 0
  
  Here's someone who has never developed anything telling Linus how it is...
5. Re:Spoken like a true idiot by Anonymous Coward · 2018-09-01 01:59 · Score: 0
  
  In fact, I develop semiconductor junction materials to test for higher efficiencies. No, not intel. I'd never work for them. I'd rather work for the Chinese.
6. Re:Spoken like a true idiot by Anonymous Coward · 2018-09-01 06:47 · Score: 0
  
  Well, he did work for Transmeta a long while ago. So?
7. Re:Spoken like a true idiot by Anonymous Coward · 2018-09-03 05:16 · Score: 0
  
  A company that couldn't make useful processors, where you needed 40% more cycles to match a lower-speed intel proc. That's supposed to impress me or change my mind?
then disclose it. by Anonymous Coward · 2018-08-31 15:30 · Score: 0

then disclose it.
Software more efficient? by phantomfive · 2018-08-31 16:41 · 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.

--
"First they came for the slanderers and i said nothing."
1. Re:Software more efficient? by Kjella · 2018-08-31 21:27 · Score: 1
  
  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 start over.
  For example take the software above, it would be really nice if we had some kind of string class right? With convenience functions like length(), substring(), append() etc. but real simple ASCII with values 0-127 that always means the same. Then comes a European who wants their mööse and you got code pages. Then Unicode and multi-byte, variable or fixed length characters, sort collations and so on. And while it doesn't necessarily gets slower the library becomes big and complex with a big interface. And then someone says fuck it, this is too much for me to bother with.
  And then you have the printing of "Hello world!", it's no longer a bitmap. It's a FreeType font of vector shapes with kerning and anti-aliasing and whatnot requiring an advanced rendering engine to actually have something to display. And if you wanted to print the date, well there's probably a huge library for that too with short forms and long forms and conversions to/from string format and leap seconds and whatnot. And that's not even starting to get into the fun of input/output devices, networking or whatever... you are in a library world already. Some of them are just a really bad idea.
  
  --
  Live today, because you never know what tomorrow brings
2. Re:Software more efficient? by Zero__Kelvin · 2018-08-31 23:04 · Score: 1
  
  Now that is hilarious. I guarantee you that anyone like that has *never* had their code make it into staging, never mind mainline.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
3. Re:Software more efficient? by Anonymous Coward · 2018-09-01 00:04 · Score: 0
  
  We could always open a can of worms and break a few (million, billion) eggs trying to re-edit, unfuckify and optimize libraries that half the WWW is based on! Let's pray that the Flying Spaghetti Monster will bless us all with knowledge, power, and visions of clarity to see through the sauce and the meatballs!
4. Re:Software more efficient? by Anonymous Coward · 2018-09-01 02:33 · Score: 0
  
  The obvious (to me) solution to this, is for the kernel project to come up with their own string library, mandate it's use, and enforce limitations upon it to ensure it meets kernel needs, and only kernel needs.
  I don't imagine the kernel, internally, needs to know about or use anything but standard 1-127 ASCII. So limit the library to that. That eliminates Unicode, code pages, multi-byte, variable/fixed length characters, sort collations, and everything else you didn't list.
  Mandate kernelstr's use everywhere strings are required within the kernel, and you're done. In short order the library is feature-complete, optimized for speed and memory usage, and it won't need to change for twenty years, just like the rest of C.
  If I'm wholly wrong and the kernel does use more than ASCII internally, than I'm wrong, disregard and move along. If I'm partially wrong and there are the odd places, here and there, where it does? Then do whatever they're doing now to handle that, and use their new string library everywhere else.
  CATCHPA: offend. Yeah, a sounds-sane suggestion offered in good faith is sure to offend a lot of folks. Well called, slashdot.
5. Re:Software more efficient? by phantomfive · 2018-09-01 03:26 · Score: 1
  
  . 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.
  
  --
  "First they came for the slanderers and i said nothing."
Bill neither by hcs_$reboot · 2018-08-31 16:43 · Score: 1

Gates and his "640k ought to be enough for anybody" proved he didn't know what was happening within his OS.

--
Slashdot, fix the reply notifications... You won't get away with it...
1. Re:Bill neither by Stormwatch · 2018-08-31 17:59 · Score: 1
  
  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.
  
  --
  Circumcision is child abuse.
2. Re:Bill neither by Zero__Kelvin · 2018-08-31 23:05 · Score: 1
  
  It was Paul Allen's OS actually. Gates was the Jobs at Microsoft. Allen was the Wozniak.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
3. Re:Bill neither by Anonymous Coward · 2018-09-01 00:12 · Score: 0
  
  Actually, it wasn't Allen's either. Both Gates and Allen were just Basic gurus, and Gates had keen sense of how to make money. Dos was written by a guru in another company, Tim Paterson, and Gates and Allen simply bought it.
4. Re:Bill neither by Zero__Kelvin · 2018-09-01 00:26 · Score: 1
  
  Starting with a purchased codebase doesn't mean the guy who takes it forward until Cutler got involved is "just a BASIC guru." I guess you didn't know that Applesoft BASIC was written in assembly language just like DR DOS.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
5. Re:Bill neither by Megol · 2018-09-01 04:03 · Score: 1
  
  Gates wrote code, did Jobs?
6. Re:Bill neither by Zero__Kelvin · 2018-09-01 04:13 · Score: 1
  
  6 year olds write code. Trying to say writing code makes you someone that at one point understood a whole OS - even one as relatively simple as DOS - is absurd. I have seen an interview with Gates where he himself states that he was never a good coder. Remember when Gates told stories about his many technical interactions with Wozniak? No, that is right ... every time there was an interaction between Gates and Apple it was Gates talking to Jobs. Are there any other brilliant rhetorical questions or assertions you would like to make?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
7. Re:Bill neither by Anonymous Coward · 2018-09-01 06:23 · Score: 0
  
  Gates also said in Triumph of the Nerds that he still knows the source code of the original MS BASIC interpeter "by heart." He stopped coding and hired people to do that for him, but early on he was definitely a competent programmer.
8. Re:Bill neither by Zero__Kelvin · 2018-09-01 06:29 · Score: 1
  
  You have confused competent programmer with bullshit artist. Nobody with a clue, and I mean nobody, would make such a ridiculously absurd claim. Real programmers have had the experience of looking at code they wrote last year and wondering who wrote it.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
This can only mean one thing... by Anonymous Coward · 2018-08-31 17:21 · Score: 0

...Linux's foot is in the grave. Don't @ me.
Complexity = vulnerability by Anonymous Coward · 2018-08-31 18:01 · Score: 0

Doesn't matter if it's open. If one person (or one entity in AI) can't absorb all of the complexity, it becomes increasingly unlikely that one person/entity will identify vulnerabilities and exploits that arise by chance or by malicious intent.
Another good reason to ditch it by SurenEnfiajyan · 2018-08-31 19:28 · Score: 0

Sadly, this probably means more shit spaghetti code than ever before. Another good reason for Google to ditch this in favor of Fuchsia / Zircon.
1. Re:Another good reason to ditch it by Anonymous Coward · 2018-08-31 22:29 · Score: 0
  
  Look, another moron who thinks the grass is greener on the other side.
Disagree by Anonymous Coward · 2018-08-31 22:20 · Score: 0

Considering the mess that is the whole embedded clusterf**k
microkernel deployments by Anonymous Coward · 2018-09-01 00:08 · Score: 0

You better be trolling.
Mach (and BSD) are used in Apple's various OSes. Does that qualify as "reasonable amount of usage and performance" of the original comment?
Also, L4:
* https://en.wikipedia.org/wiki/L4_microkernel_family#Commercial_deployment
1. Re:microkernel deployments by drinkypoo · 2018-09-01 02:39 · Score: 1
  
  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.)
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
2. Re:microkernel deployments by Anonymous Coward · 2018-09-01 06:26 · Score: 0
  
  Not really. Apple uses Mach as a HAL. All process management is done by the monolithic BSD kernel which runs atop Mach
  The runnable entity in the Mac OS X kernel is a Mach thread, which is further separated into a shuttle and an activation. Threads are contained in Mach tasks. BSD-style process abstraction is retrofitted by associating a process structure with each Mach task, among other things.
It's about time to start a new kernel. by Anonymous Coward · 2018-09-01 00:31 · Score: 0

Linux is too complex. Let's start over.
1. Re:It's about time to start a new kernel. by Anonymous Coward · 2018-09-01 02:41 · Score: 0
  
  Mandantory
All OS kernels are a spaghetti mess by Anonymous Coward · 2018-09-01 01:42 · Score: 0

I think most OS's that have a long history also have basically grown their kernels into a spaghetti mess. Well especially desktop OS which have certainly bloated up over the years. Even mobile OS to some extent require better hardware just to maintain a parallel level of performance. Its not surprising that many stick with older kernels and OS releases because of this performance gain. Yes, you lose the advantage of new features and hardware support. But older hardware likes older kernels.
True for many years now by OneHundredAndTen · 2018-09-01 01:54 · Score: 1

The Linux kernel has consisted of millions of lines of code for many years. It is doubtful that anyone can understand, really understand, all the ins and outs of more than a few tens of thousands of lines of code.
lol tell ibm about it - mvs is complicated by Anonymous Coward · 2018-09-01 03:36 · Score: 0

mvs makes the linux kernel look like a phone app - tell ibm how closed development doesn't work
On a side note... by Anonymous Coward · 2018-09-01 05:54 · Score: 0

Systemd is the human expression of perpetual and covert alien telepathic pressure
Linus quote by TheDarkener · 2018-09-01 06:25 · Score: 4, 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.

--
It is pitch black. You are likely to be eaten by a grue.
1. Re:Linus quote by strikethree · 2018-09-05 05:30 · Score: 1
  
  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*
  
  --
  "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen