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...
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
Thanks for the explanation.
I totally forgot about the endianness.
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 don't code and even I know you don't do this