Does [mainstream Linux] strike you as bloated, and possibly quite insecure?

Does [mainstream Linux] strike you as bloated, and possibly quite insecure?

>pic related
>the modern kernel has +4 million lines of code

Some quotes by Linus:
>The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse

>I think we've been pretty stable," he said. "We are finding the bugs as fast as we're adding them — even though we're adding more code."

>Torvalds said he'd love for Linux to shrink in size "We've been bloating the kernel over the last 20 years, but hardware has grown faster".

>Linus Torvalds stated that Linux has become "too complex" and he was concerned that developers would not be able to find their way through the software anymore. He complained that even subsystems have become very complex and he told the publication that he is "afraid of the day" when there will be an error that "cannot be evaluated anymore.

Kernel dev Andrew Morton:
>I used to think code quality was in decline, and I think that I might think that it still is. I see so many regressions which we never fix.

Then we have the issue of systemd. Many threads exist on that topic already.

The reason I'm thinking about this is that every time I'm setting up a Linux server, I am daunted by the sheer scale of the system. There are kernel subprocesses that have no available documentation, and endless configuration files. A debian server of mine has like 50 running processes currently.

How am I supposed to keep tabs on the system, beyond data-sniffing everything that passes to and from it? How am I supposed to identify malware for example in this kind of setting? It feels like it's based off insecurity through obscurity. When doing system hardening, it feels like I'm mounting high-tech defenses on a glass castle built on pillars of sand.

>queue the ebin "install gentoo"/"install openbsd" comments

Other urls found in this thread:

youtube.com/watch?v=5iFnzr73XXk
github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/xt_CONNMARK.h
github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/xt_connmark.h
harmful.cat-v.org/software/andy_tanenbaum
harvey-os.org/
twitter.com/NSFWRedditImage

>>the modern kernel has +4 million lines of code
That's because more and more hardware supports are landing on Linux.

Hurd is the future.

Video related:
youtube.com/watch?v=5iFnzr73XXk

wow
just the first few minutes of the video makes it seem like Linus is some kind of code mage

Looks to me like it has way more than 4, more like 22

Give tl;dr please

yes. I don't know how I managed to write that.
- OP

>mid 90's
>Linus working by himself
>Small code, doesn't look bloated
>Code base simple

>fast forward 20 years
>N number of companies contributing to the kernel because they want to be compatible
>millions of lines of codes
>Kernel not so simple anymore
>kernel is very bloated
Pick any successful project, it's the same story.

>Torvalds said he'd love for Linux to shrink in size "We've been bloating the kernel over the last 20 years, but hardware has grown faster".
Linux could have been rewired for some ideal (virtual) Linux machine, so countless drivers could be taken out of the kernel.
Well, it looks rather like some microkernel architecture.

Is it because the kernel tries to implement every single driver that has ever existed?
I doubt that many things in the kernel as still used if not by the occasional grandpa still stuck in 1980.

Are all those archs actually needed? x86-64 has basically a monopoly over desktop and so is ARM on mobile.
Are all those fs needed? Again, only a couple are actually in active usage
And so on...

I bet there is people still updating the floppy drivers because "muh retrocompability"

yep

linus really needs to tell people off more often

>Then we have the issue of systemd. Many threads exist on that topic already.
Systemd is a completely different problem that is unrelated.

Rather than lines of code, I want to see that graph in bytes.

Jesus Christ. I think I have stumbled into part of the problem just by downloading and extracting the source on Windows.

github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/xt_CONNMARK.h
github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/xt_connmark.h

Do you know Windows supports case-dependence?

what if you compile it yourself and enable only the things that are needed on your hardware? it takes only few minutes to compile a usable kernel if its configured properly.

i actually used the floppy driver and a real floppy drive because i found some old disks and wanted to see what was on them.

>queue
It's cue.

>winbabby discovers that case sensitivity doesn't exist in windows

The reason for it was laid on day 1.
monolithic kernels are wrong

It exists, it's not enabled by default.

I do know, but I also know it is off by default.

The problem is that one just calls the other, which means that there are some files linking the uppercase one that should be changed to link the lowercase one.
Instead you have another file and more lines of code.

don't compile the shit you don't need, congrats your kernel hasn't grown

They're not talking about the compiled size of the kernel, but nice try.

>enable only the things that are needed on your hardware
Is there a guide for this?

if you have to ask, then you really shouldn't try compiling your own kernel.
I mean this in an unironic and helpful way.

I'm running Arch + i3-wm but I was to lazy to look it up, thanks for the help though.

it's not that hard

>Linus working by himself
It doesn't say "Linus", it says "Linux before BK".

>proliferating the "hardware support is bad" meme

Not the one you're replying to, but it's not about it being hard, but just about being able to do stuff by yourself without having to ask every step of the way.

>thinking that hardware support for all kinds of hardware should be implemented in one kernel, rather than having it modular as per the unix guidelines
>making an argument using "meme"

Why do you think they're called "kernel modules" in the first place? Most distros probably stick in every single module they can think of just for the sake of compatibility.

as we all know, the linux kernel bloat is almost exclusively caused by hardware modules

I doubt that's what Linus is referring to when he says that "our icache footprint is scary" or that the kernel is "too complex".

yes. sarcasm.

It is because of hardware compatibility, yes. And yes, it's needed. If you don't want to use them, then the code is never even run on your system. If you compile your own kernel, it's never even compiled. Most of the hardware support code "bloat" is mostly a concern to people having to manage the Linux source tree.

tl;dr
If you're not running a sparc CPU, the sparc Linux code isn't slowing you down. Same for FSs you don't use, etc.

Yes lets keep shipping the kernel with built-in drivers for obscure and dead hardware from 25 years ago.
Why if linus is so smart he designed such retarded system for hardware support. He could have made something that works like windows drivers,
instead no, cramp 10 gb of drivers for all possible hardware ever existed since the beginning of time into the kernel.

You'd probably need to ask every step of the way, the kernel compilation infrastructure is surprisingly good, but require a decent understanding of how the kernel is set up.

The general procedure is to:
>check out the current linux kernel source tree
>copy your existing kernel configuration from whatever distro you're currently using (e.g. `zcat /proc/config.gz > .config`)
>run `make menuconfig`, and go through the menu and disable all the features you know you'll never use (this is where the complications lie)
>run `make`, `make modules`, `make modules_install`, `make install`

And how many decades has it gone nowhere? There is a GNU Debian version you can try and see for yourself it has the stability of jelly nailed to the ceiling.

And all the fuss about microkernels increasing stability. And still it is useless for any serious use. And there are no, absolutely no signs that it will be stable within the foreseeable future.

And that is why all the brouhaha about Linux being GNU.

I was still talking about the code desu.
The code is bloated because of trillions of little hacks, drivers and stuff that are pretty much dead but are still carried on.

Backward compatibility is good and all, but up to a point. Eventually you must drop it.

This post is so retarded, it's hard to even know where to begin.

>shipping the kernel with built-in drivers
Linux has supported modules for well over a decade, and the vast majority of drivers ship as modules which are never activated unless they're needed. You can even disable including the modules if you compile your own kernel.
>for obscure and dead hardware
CPU architectures have no impact on kernels for other architectures, and everything else that's obscure or dead has long since been ported to modules.
>retarded hardware support
Linux has pretty damn good hardware support, and where it doesn't isn't Linus' fault--it's up to manufacturers to contribute drivers for their black-box hardware. But I suppose that's "bloat" to you.
>windows has good drivers
This is the dumbest thing from your post, which is saying a lot. Windows has more legacy support than Linux, if anything. Windows ships with fucktons of drivers. The windows driver system is a clusterfuck, and it supports lots of hardware only due to microsoft's market dominance forcing manufacturers to provide drivers. It has nothing to do with a good software ecosystem on Windows.
>cram 10GB of drivers into the kernel
Answered several times already.

Seriously, if you know how to program, go try to write a Linux kernel module, and then compare the experience to writing a Windows kernel-mode driver.

Yeah, I can certainly get this. I would appreciate it if the kernel code *at least* switched to using stdint.h, but a lot of the hacks (e.g. for processors without MMUs, etc) are still prevalent with cheap CPUs used for embedded applications. I mean, shit tons of Motorola 68Ks are still manufactured every year for one example. Cutting some of the cruft could hugely reduce Linux's market share in domains like that.

I said
>He could have made something that works like windows drivers
not
>windows has good drivers
you sperglord. I was referring to the SYSTEM itself of delivering the support, that could have been designed better from the beginning.

99% of the "kernel" is drivers

NT did it right with separating drivers from the kernel.

And I responded in kind to the idiotic notion that Windows has a drivers system that works well. The need to run a unique installer written in broken english every time you buy new hardware is not indicative of a good system.

Notice how I said
>the windows driver *system* is a clusterfuck
not
>windows drivers are a clusterfuck

Once again, try writing a driver for each system if you can program, and then tell me which one has a better system.

And majority of those locs are drivers for mobile socs, afaik. They really need to clean up or split kernel into desktop, server and mobile versions.

>split the kernel into desktop, server, and mobile versions

I'm actually glad they don't do this--the difference between server and desktop are fairly minor. The difference between desktop and mobile is UI--which Linux does a great job of separating from the kernel. With complex mobile CPUs, there's really not much different about managing a mobile kernel from a desktop one.

"Micro"kernel doesn't automatically mean "small", you know. Kind of like how if you study the global market for, say, wheat, that's microeconomics and not macroeconomics. (Because microeconomics is named wrong and should really be called price theory.)

harmful.cat-v.org/software/andy_tanenbaum

>the difference between server and desktop are fairly min
Well, yeah, on a second thought splitting server and desktop looks like a bad idea. But mobile should be separated. How many desktop/server users need drivers for mobile socs? Especially such kind as semi-recent qualcomm(?) drivers which broke ability of kernel to compile under certain circumstances.

This. So many brainlets here think "bloat" means "many lines of code", but when Unix types say Linux and GNU are "bloated" what they mean is it's a bad architeture.

not monolithic doesnt mean micro

>- Microkernels are the way to go
>False unless your only goal is to get papers published.

lol, where is the rob pike of '92

>So many brainlets here think "bloat" means "many lines of code"
That's what the OP image implies, and is what some people in this thread are complaining about. The vast majority of hardware support in Linux is packaged into modules and never touches the core kernel.

That's where I remind them of harvey-os.org/

Plan9 that can be built with gcc. This could be the future but sadly the project owner are subjected to the removal-disease and removing 32-Bit x86 support was one of the first things those faggots did.

I thought 'make' included 'make modules'

Honestly, for a *new* OS, removing older support is a great idea. No entrenched legacy hardware is going to adopt it, so it seems like a good idea to not try to carry the baggage.

Oops it actually does.

This sounds reasonable by itself but Plan9 is by nature a multi-platform OS. If they don't "update" the code with that in mind they're doing it wrong right from the start. So removing 32-Bit doesn't make sense unless you add politics to the reasons. And from that point of view, you can already count on it that they'll sell out any user like a drity paw poo-in-loo does any day.

How many of those lines of code are drivers, tho? Obviously the code is goign to grow to support more hardware. How about a graph seeing the number of non-driver code?

Yeah.
He even admit the whole thing is no longer suitable for embedded.

Was actually thinking of starting a project to take the OKL4 kernel, mod it a bit, and see if it rubs well with GNU's userland.

OKL4 belongs to the L4 family, which did a great job of ripping most things out of the kernel, while not impacting performance.

Is it even possible to get an L4 running on real hardware with anything resembling user interaction? I can't imagine you'd just be able to install it on a thinkpad, regardless of whether you're able to cajole the GNU userland to compile for the L4 ABI.

Not trying to discourage you from trying, it would be cool if you can actually make a usable general-purpose PC based on L4.

>ripping most things out of the kernel, while not impacting performance
Not saying much, unless you're talking about things like FS caching

>Is it even possible to get an L4 running on real hardware with anything resembling user interaction?
You could, but you'd need to rewrite a lot of in-kernel stuff outside of it.

>Not saying much
Performance issues are the biggest problems affecting micros, so kind of a big deal.

What did he mean by this?

...

BR = Brian Krzanich?

...

It's bloat and die just like everything else in industrial technological society.

2004-04-11 andrew morton going super saiyan