A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
Man, I swear to god, the comment section under an article always seems to drive just the shittiest, lowest quality, most "microwaved thinking" takes on any given subject, regardless of the side they take in the discussion
Reading just a few of those comments makes me frankly sad.
Phoronix has notoriously dumb commenters. I don't know why exactly but it's really notable.
Hackaday too. Again, not sure why. They're both significantly worse than Reddit, HN, Ars or here. Maybe even worse than YouTube comments...
Phoronix is a drama mongering site so of course the comments will be dumb, just like the articles.
Hackaday's comments are bad mostly when the article is about Linux. Electronics stuff gets better comments.
More specifically it is full of older people who refuse to change. They learned electronics in the 20th century and don't want to see anything newer than 2005.
Eh works for me, I value different opinions
Pro-tip: Avoid reading comment sections in general.
Yet here we are.
You folks are cool though
Nuh-uh poopyhead!
I stand corrected!
@Cris_Color
I like Phoronix because it soaks up all the faux-techno nutters and I can get on with my life
@Sunshine
If you don't mind my asking, is your instance a piefed or Mastodon instance? Or something else?
I only occasionally see people using @, and it's always cool seeing people interacting across different server software 😊
@Cris_Color It is a Mastodon instance.
Neat! I'm glad your voice can be part of the conversation started on lemmy from a totally different platform, I may never get over how cool that is lol
Hope you have a lovely day 😊
I mean, he explained what and why is garbage and he's not wrong, so it's a valuable lesson at least.
Sort of. He's definitely right that make_u32_from_two_u16 is a terrible function name that obscures the meaning but I don't think he's right that the best solution is to inline it. C bit shifting is notoriously error prone - I've seen this bug multiple times:
uint32_t a = ...;
uint32_t b = ...;
uint64_t c = (a << 32) | b;
The real problem is the name isn't very good. E.g. it could be u32_high_low_to_u64 or something. Might clearer. Certainly easily at kernel code levels of clarity.
(Really the naming issue comes from C not having keyword arguments but you can't do anything about that.)
I am not a C developer, but I found the "helper has a terrible name" and "it's not clear what the helper is doing" arguments a bit weak.
Who in they right mind does not think the helper creates a 32 bytes word by putting the 16 bytes of the first argument followed by the 16 bytes of the second one ?
It's bits, not bytes. And endianness is a huge consideration in systems programming. And it's basically Linus' whole role at this point to enforce extreme consistency and standards since the project is so large with so many contributors
Yeah it actually is fairly common to have the high word first because humans unfortunately picked the wrong endianness, and integers are written in big endian.
E.g. what value would you expect from u16x2_to_u32(0x1122, 0x3344)? If you said 0x11223344...
Still, the rant is stupid because all that needs to happen is to fix the name.
Honestly it's really surprising that the kernel doesn't already have a library of reliably but manipulation functions for common stuff like this.
Read the article. Can't imagine anyone who has ever worked with software development not agreeing with Linus here.
I think the one who wrote this title should be blamed. It may not be intentional, but it sounds like Linus is an evil villain who beat RISC-V superhero.
Look at this function that gets submitted to the pull request.
make_u32_from_two_u16()
These "helper" functions never help for the reasons Linus addressed in the article. As a JavaScript developer, which often results in a messy codebase because of management issues, I hate these functions with a passion. It's usually only the person who wrote it finds it helpful, and only at the week he wrote it. After six months he will just be confused as everyone else.
Garbage, in other word.
Even if it's not garbage, why submit it alongside the RISC-V change? If it's a dependency, submit this one first and postpone your RISC-V change.
RISC-V may not be garbage. It's the industry not getting quality and experienced developers for it.
Its because junior devs get DRY hammered into them by idiot teachers/trainers who dont know much else. So they try ti DRY absolutely every little function. Its the one thing I have fought the most dealing with juniors and even seniors. The other thing is making utility functions into DRY utility functions AND THEN overloading their purpose by adding a bunch of features to it just to justify it being DRY.
The biggest issue I have with Risc-V is the lack of a clear standard. It incredibly fragmented which means that lots and lots of code is needed to try and account for every type of hardware.
I don't code and even I know you don't do this
Linus moment. He isn't wrong though
Yeah, but a better person could be not-wrong without turning a single sentence criticism into a multi-paragraph rant only serving to stroke their ego. Turns out people can be "garbage" despite being skilled at something.
I don't know, when you are dealing with this level of coding it should be top tier, and getting called out will make the person really review their next submission. The expectation that somebody always has to be nice to you while you fuckup, is not ideal. And I say that as a supervisor that is way too PC and nice to people whom unwittingly are sabotaging work, as a way to nurture them--but I honestly think it is counter productive
getting called out will make the person really review their next submission.
Yeah or they'll say "fuck this" and quit.
The expectation that somebody always has to be nice to you while you fuckup, is not ideal.
It's hardly a fuck up. They named a function slightly poorly. As if Linus has never done that.
Cmon, this is not about naming, this is about non-generic code in generic header.
IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.
this is about non-generic code in generic header.
(a << 16) | b is about the most generic code you can get. How is that remotely RISC-V specific?
Making a u32 ~~pointer~~ from two u16's isn't a generic operation because it has to make assumptions about ~~how the pointers work~~ endianess
Edit: Actually, I'm wrong, didn't think this through properly. See the replies
What makes you think it's making a pointer? Nobody said anything about that.
Oh my bad I don't know where I got that from lol
Nw. You're also wrong about endianness. This function would be written exactly the same irrespective of endianness:
uint32_t u16_high_low_to_u32(uint16_t high, uint16_t low) {
return (high << 16) | low;
}
That is endian agnostic.
They named a function slightly poorly. As if Linus has never done that.
Not only that. They introduced a obscure function, which inner workings are not clear and that is only used by their new code into a global header which is used by many other code parts, which means other people could start using it. This could lead to bugs since the semantics are not clear from the function name or if they change the function in the future. Also they added their pull request much too late to be properly reviewed.
Also that it was requested earky if it was going to be submitted.
Seems like Linus is accusing them of doing it last minute because they wanted to take advantage of him being busy as an intentional strategy, as he said and they didn't even submit a good offering.
That last bit kind of sounds up that he might have accepted in spite of his difficulty due to travel, but they also fucked that up and wasted a whole lot of effort.
This really seems like a public lesson for everyone else using this submission as an example of what he does not want other people to do and then proceeds to explain exactly how he feels about it.
It's definitely a rant, did seem like it had a purpose to it beyond him just letting out a rant
I read is rant, seems more than just a poor naming issue
I say that as a supervisor that is way too PC
Linus doesn't have to be a dick all the time. However, as I get older, I begin to understand the wisdom behind a monologue in Team America: World Police more and more:
We're dicks! We're reckless, arrogant, stupid dicks. And the Film Actors Guild are pussies. And Kim Jong Il is an asshole. Pussies don't like dicks, because pussies get fucked by dicks. But dicks also fuck assholes: assholes that just want to shit on everything. Pussies may think they can deal with assholes their way. But the only thing that can fuck an asshole is a dick, with some balls. The problem with dicks is: they fuck too much or fuck when it isn't appropriate - and it takes a pussy to show them that. But sometimes, pussies can be so full of shit that they become assholes themselves... because pussies are an inch and half away from assholes. I don't know much about this crazy crazy world, but I do know this: if you don't let us fuck this asshole, we're going to have our dicks and pussies all covered in shit!
In this case, Linus is a dick who fucks when it's not appropriate a lot (i.e., is harsh in his critique about bad code in pull requests). Assholes push bad code, and sometimes it's so bad that it'll fuck up the whole kernel. Pussies in tech magazines criticize his style of critique. Other pussies get "butt-hurt" because they code like shit too and they can't or won't admit it, and they're so full of shit, they're pussies who've become assholes themselves.
The code in question is, in fact, garbage.
Fuck that, this is what creates those assholes and makes people unable to work in teams and we should be doing everything we can to push people like this out of the field, because it causes more harm than good. I'd rather have some fresh out of college kid who can actually communicate like a human and work with people while giving/receiving criticism without throwing a tantrum on my team than a Linus.
When Linus is nothing but a grave people piss on I want better people to have taken over, not the same. The entire basis of computer science is building off a previous iteration to make things better, and that should apply to the people too.
Fuck that.
Too many people with brittle spirits performatively clutch their pearls to the point of banality when they're called out on it.
That anger and lack of self-control is fine as a vague blogpost maybe, but as an actual developer? Hell no, anyone who thinks this is acceptable has no place in any important field. Anybody who can't control their emotions and act efficiently when putting criticisms forward is worthless, 30+ year old accomplishments they've been coasting on notwithstanding.
"I'd like to be a nice person and curse less and encourage people to grow rather than telling them they are idiots. I'm sorry—I tried, it's just not in me."
He self-admittedly doesn't care about people growing and improving, which is the single most important aspect of being a developer. He'll probably accomplish more than I ever will, but you know what? I'm still going to pass on better habits to the next generation, because in the long run they will accomplish more because of people actually encouraging that growth. It's just that selfish, self-serving, admittedly less extreme, Andrew Tate-style toxicity in its earlier form (and being a KotH fan, you're probably familiar with that episode from the newer season showing how Cotton's behavior relates to those types, so hopefully you get what I mean).
I think "coasting" is a bit too strong.
Furthermore, to clarify, I think people should be allowed to be dicks (verbally). I also think they should face the consequences of being a dick.
Nerfing "toxic" language with the weight of law is too much, but public shunning and/or an employer's ire are absolutely consequences that people should face with the same stoic fearlessness that they purport to have when they're being dicks to other people. In this case, (I think) he is the owner of the kernel repository. His word is in fact law when it comes to pull requests. He can be a dick if he wants to, so long as it complies with Finnish law on slander, libel, inciting violence, etc. And, of course, we, the public, are free to judge him on it.
I read what he said. I also read the pull request in the code that he was talking about. I also noted how late the pull request was submitted. He's harsh but also absolutely right, in this case.
What I can't stand is the performative pearl clutching and virtue signaling that people love to masturbate to.
It's a simple premise. As said in the gif I posted, "He's outta line, but he's right."