Is the Linux kernel really a sloppy mess? Or does Jow Forums just have no idea what they're talking about

He can't

Oh right. So that's why they are always playing catch-up when it comes to device support and drivers...

My understanding was most of the sloppiness of the Linux kernel's source code comes from the permissiveness of C and abusing undefined behavior. I could be wrong but I think they also inline assembly fairly often. My understanding is that both of these may have lead to compiler incompatibilities previously at some point.

Just recently they got rid of variable length arrays so I think they are trying to improve the situation but I don't how much better it has gotten.

Attached: 1550375212529.jpg (772x507, 71K)

terry davis

Jackpot51, Redox-OS

The kernel is HUGE!
The only reason it works so well is Linus Torvalds.
If he dies Linux will deteriorate pretty quickly.

sloppy mess is a relative term that doesn't mean much without comparison

the only thing we can realistically compare linux to is BSD (everything else is either niche or closed) and that's not a good comparison because BSD doesn't have the hardware support that Linux does

All software above a certain threshold of lines of code is a sloppy mess.

True. The important question is, does the sloppy messiness cause enough problems to warrant a rewrite. So far that doesn't seem to be the case for Linux, despite the driver bloat and C usage.

Attached: Linux.png (1563x1650, 756K)

Not all of the kernel is sloppy and messy, but some parts definitively are. Like the TCP output function that's literally 1050 lines of code, riddled with gotos and labels and ifdefs and funny bitshifting.

elixir.bootlin.com/linux/v5.2.11/source/net/ipv4/tcp.c#L938

Also the framebuffer terminal is a huge mess. It is basically a remnant of some old AMIGA port of Linux that has not been touched for years.
I tried to submit a patch for better unicode support and it was rejected right out of the gate.

Yeah, but that's a problem with contributing in general. There are a bunch of "chieftains" that I would like to call them, that are in total control of their subsystem and refuse to let outsiders in on it. Google employees are pretty much in charge of net-next, so the only patches they accept are pretty much whatever Google wants to get in. I submitted a patch that used some free space in skbuffs in order to bundle previously sent data in smaller TCP segments (in order to proactively prevent retransmissions in case of loss, search for Redundant Data Bundling if you're interested), but that patch just ended up in eternal limbo because Google wanted to use that free space for their BBR congestion control algorithm, so half a year later or something their stuff went straight in and my patch never materialised.

>linux network stack is cucked by google
I warned you about GPLv2, bro. I fucking told you.

Attached: rms-despair.jpg (1024x768, 294K)

The function is 200 lines, and I'd see you make one that's not slower with any better source code.

At least I wouldn't rely on implementation behaviour such as comparing a size_t with an int.

Have it occurred to you that maybe the shit you're submitting is not as great in reality as it is in your mind? There's a good reason why fucking Google, the one entity the most interested in impeccable networking, didn't approve of your patch. I don't pretend like I know what it is, but it's sure as shit not just mindless gatekeeping as you think it is.

>Have it occurred to you that maybe the shit you're submitting is not as great in reality as it is in your mind?
You mean except for the fact that it was ack'd? If it was shit, it wouldn't get ack'd, it would be rejected. Not to mention that one of the replies by the maintainers was literally "thank you for this high quality patch submission"

lkml.org/lkml/2015/10/24/56

It was just left in ack-limbo, this isn't an unknown thing, it happens all the time.

>but it's sure as shit not just mindless gatekeeping as you think it is.
It definitively is.

Hi Bendik Ronning Opstad
Thanks for doxxing yourself.
Linux maintainers are right to reject anything from people with enough time on their hands for trolling at Jow Forums of all places.
The system seems to work.

It wasn't rejected, that's the point. It was ack'd. It was simply never merged.

that's the power of people still believing it's the 80s and hacky code is the way to go.

it's a meme

>lkml.org/lkml/2015/10/24/56
I recognize one of those names, is that the same guy that made the GPU PCIe SSD-thingy that got picked up by Nvidia?

Ok just read the patch. That's some solid work and should definitely be included in the kernel.
Fuck google!

Yes, although it wasn't so much "picked up" by Nvidia, they've simply shown some interest in it.

Damn user we need more ppl like you posting here, this place is filled with idiot skiddies and corporate shills

Thanks, but it will never be picked up now, as it relies on free space in SKBs that is currently used for BBR stuff (the new default TCP congestion control, as decided by Google). Unless you can convince Dave Miller or whoever is in charge these days, to make BBR non-default again or make the RDB-thing a compile option or something.

Thanks

Dude If you are not at least a platinum donor to the Loonix foundation your patches are worthless.
Why even bother? Move yo ass to OpenBSD!

I came to this thread and expected shitposting, instead I found kernel hackers. I'm pleasantly surprised.

The problems with the linux kernel are social, not technical, the project was never meant to scale to the level it did and the license has also poisoned the well on a many better patches that did not get accepted.

Dave Cutler
en.wikipedia.org/wiki/Dave_Cutler

He was the technical lead for VAX/VMS at Digital Equipment Corporation. Then Microsoft hired him away to create the Windows NT-based operation systems.

He was at least better than Linus, who can't even run his side Tech Tips website well while maintaining the Linux kernel.

Well there's your answer - they decided using a different method. Considering it's Google, there's a very good chance they did the math thoroughly on this decision. For all you know, they tested your implementation against theirs and concluded it wasn't as good.