Человек года в Linux и Open Source-сообществе — 2015

Без примеров я не возьмусь обсуждать эту тему.

Пожалуйста. И это только Линус.

И? Это не то. Я не вижу там ничего сексистского.

И? Это не то. Я не вижу там ничего сексистского.

Вот поэтому тебя и нет в этом списке.

«Человек года» оценивается по кол-ву произведённого шума, а не по принесённой обществу пользе.

Код-ревью от Торвальдса, номер раз: https://lkml.org/lkml/2013/2/21/228

Guys, this is not a dick-sucking contest.

If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic «we only sign PE binaries» stupidity? We support X.509, which is the standard for signing.

Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel.

Код-ревью от Торвальдса, номер два: https://lkml.org/lkml/2015/10/28/215

Christ people. This is just sh*t.

The conflict I get is due to stupid new gcc header file crap. But what makes me upset is that the crap is for completely bogus reasons.

This is the old code in net/ipv6/ip6_output.c:

mtu -= hlen + sizeof(struct frag_hdr);

and this is the new «improved» code that uses fancy stuff that wants magical built-in compiler support and has silly wrapper functions for when it doesn't exist:

if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||
mtu <= 7)
goto fail_toobig;
and anybody who thinks that the above is

(a) legible
(b) efficient (even with the magical compiler support)
(c) particularly safe

is just incompetent and out to lunch.

The above code is sh*t, and it generates shit code. It looks bad, and there's no reason for it.

The code could *easily* have been done with just a single and understandable conditional, and the compiler would actually have generated better code, and the code would look better and more understandable. Why is this not

if (mtu < hlen + sizeof(struct frag_hdr) + 8)
goto fail_toobig;
mtu -= hlen + sizeof(struct frag_hdr);
which is the same number of lines, doesn't use crazy helper functions that nobody knows what they do, and is much more obvious what it actually does.

I guarantee that the second more obvious version is easier to read and understand. Does anybody really want to dispute this?

Really. Give me *one* reason why it was written in that idiotic way with two different conditionals, and a shiny new nonstandard function that wants particular compiler support to generate even half-way sane code, and even then generates worse code? A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation.

And yes, you still could have overflow issues if the whole «hlen + xyz» expression overflows, but quite frankly, the «overflow_usub()» code had that too. So if you worry about that, then you damn well didn't do the right thing to begin with.

So I really see no reason for this kind of complete idiotic crap.

Tell me why. Because I'm not pulling this kind of completely insane stuff that generates conflicts at rc7 time, and that seems to have absolutely no reason for being anm idiotic unreadable mess.

The code seems *designed* to use that new «overflow_usub()» code. It seems to be an excuse to use that function.

And it's a f*cking bad excuse for that braindamage.

I'm sorry, but we don't add idiotic new interfaces like this for idiotic new code like that.

Yes, yes, if this had stayed inside the network layer I would never have noticed. But since I *did* notice, I really don't want to pull this. In fact, I want to make it clear to *everybody* that code like this is completely unacceptable. Anybody who thinks that code like this is «safe» and «secure» because it uses fancy overflow detection functions is so far out to lunch that it's not even funny. All this kind of crap does is to make the code a unreadable mess with code that no sane person will ever really understand what it actually does.

Get rid of it. And I don't *ever* want to see that shit again.

в обоих ревью вполне адекватный ответ на говнокод :))

но, опять же, в них тоже нет ничего сексистского

Где ты там сексистские шуточки увидел?

Он хоть и матом, но предельно по делу написал там. Что не так?

увидел

не увидел, а увидела.

anonymous> не увидел, а увидела.

Ах да... Я же совсем забыл: у анонимуса нет пола. Значит не увидел и не увидела, а увидело.

Это не сексизм. Вот если бы он какой бабе предложил валить на кухню, а не ядро патчить, то это можно было назвать сексизмом.
Если бы он мужику сказал, что пусть сначала рожать научится, а потом уже в ядро лезет, то это был бы с натяжкой сексизм.
А просто упоминание слова «член» не делает сообщение сексизмом.

Пожалуйста. И это только Линус.

А где сексизм там?

Человек года в Linux и Open Source-сообществе — 2015 (комментарий) и ниже.

А сексизм-то где? То что он deep-throad употребляет в негативном значении?