Google slams Linux kernel

kpedersen said:
The Linux kernel is a jumble sale of everyone pushing their agendas and doing it quickly to "be the first". That and hardware vendors doing the absolute minimum to get their hardware out there as soon as possible. This cannot produce a secure system.
Click to expand...

Bingo.

No common engineering principles and/or values amongst a community governing software; you get something like the Linux kernel. The Linux kernel should be called the "Driver Bucket".
 
kpedersen said:
I believe that due to Microsoft's collection of Shared Source / University / Internal business agreements, there are probably more eyeballs looking at the NT kernel code than FreeBSD. Does that make Windows more secure? I am not convinced.

A lot of the Linux kernel source code is very rarely looked out. It has been dumped in there by some vendor and forgotten about. So again, I don't know if we can classify Linux as more secure. Certainly some code paths *do* have greater coverage in terms of verification.

In many ways I would be really interested in some sort of measurement / experiment here. I think the best we can do is with static analyzers but very few of them can find new issues in any of the projects.
Click to expand...
Well, gotta keep your eyes peeled in that case, to avoid another UM debacle. The more eyeballs you have, the more likely you are to have a repeat from a few bad apples.
 
Don't forget: the number of bugs found doesn't matter. The number of bugs reported does. And the ratio between them even more.
 
  • Thanks
Reactions: a6h
hardworkingnewbie said:
I think the major difference between Linux and the FreeBSD kernel is the number of eye balls having a closer look at it. This number is much, much bigger at Linux compared to FreeBSD. Would FreeBSD have the same number of eye balls taking a closer look, oh boy, I am pretty sure the number of found exploits would skyrocket.
Click to expand...
It's not the case at all. Most opensource users are like a school of fish that get a confirmation of numbers which doesn't mean much. Linux/GNU has a lot of problems, and it took putting those programs on FreeBSD to find out problems with it. The way I found this, is because it was either make an improvement, or continue to compile 14 hours of bloat for no reason. For GCC, it took an additional 14 hours, because it pulled in sets of Linux dependencies for 3 Operating Systems worth. I replaced that with Clang, and 14 hours of compile time were dropped off. After pointing that out, they fixed GCC on FreeBSD. That took 1 user to find, after several years of using this OS, when Linux/GNU kept piling on, and we ported that way here. How many security holes are in that, if they didn't even know why they added that many unneccessary dependencies, that took hours to compile?

OpenBSD has less eyes than FreeBSD, and they'll find more vulnerabilities than Linux, and be somewhere in the ballpark to other BSD's.

Saying one OS has more eyes on it, therefore it's automatically better or more secure, is like the saying that 1 person is vocal, while everyone disagrees with that person, but outloud everyone says they agree, because they think everyone else agrees.
 
Google should go double-or-nothing and roll with GNU Hurd.
 
Crivens said:
Don't forget: the number of bugs found doesn't matter. The number of bugs reported does. And the ratio between them even more.
Click to expand...
As Beastie7 pointed out, it's brains that fix bugs, not eyeballs. Just because a bug is reported, that means nothing until you can show that yes, this is a problem that demands attention and a fix, otherwise the situation will get in the way of proper functioning. Otherwise, we're gonna have robots fighting it out over for(....) vs do while(...), and humans unable to tell the difference.
 
Yeah... Google does have the money to hire the brains.... At one point Vint Cerf did work for Google, after all.
 
astyle said:
Yeah... Google does have the money to hire the brains.... At one point Vint Cerf did work for Google, after all.
Click to expand...
Not to mention many of the Google Golang guys are from the old AT&T Bell Labs / C group. Also my particular favorite; Renee French (of Plan 9 Glenda Bunny Fame) for the Gopher mascot!

Oddly enough, along with my search just now I came across a certain Dr BSz too @Google. Seems like a smart guy. ;)
 
Why doesn't Google take Minix as a starting point, and rewrite it in Go-lang or Rust? Minix is everything he described he wanted, except it's in neither the language of Google or Rust.

He wants Rust which has safety checks, but Google contributes Go-lang. So why doesn't he add Rust safety features to the next version of Go-lang.

I think Linux should stay as C, unless, there's something closer to C than Rust (and not C++). It seems that it needs to stay as 1 language: either staying as C or a language that's very close so it doesn't need much more in toolchains, or being re-implemented completely in Rust. Rewritting the Linux kernel in Rust is like asking Linus to rewrite everything, which is too tall an order. It could be gradually replaced with Rust code, or with a competing kernel sooner or later.

An Android kernel written in Go-lang modeled from Minix makes a whole lot of sense for mobile phones. A future version of Go-lang with Rust safety features also makes sense. It will give the Minix kernel advertisement it needs, while Minix will remain separate to limit all influence to it.
 
Go and Rust serves different purposes and have different paradigm. Incorporating Rust features into Go simply does not make sense.
Google indeed contributes Go, but I guess it is not the kernel team. At least this is the impression I get when watching conference talks on Go given by Google employees.

They do not want to rewrite it in Rust, but allow writing new stuff in it. Old stuff stays C, the new one will be written in Rust.
 
You must log in or register to reply here.
Back
Top