40
top 21 comments
sorted by: hot top controversial new old
[-] flamingos@feddit.uk 9 points 2 weeks ago
[-] cockmushroom@reddthat.com 5 points 2 weeks ago
[-] flamingos@feddit.uk 7 points 2 weeks ago

So? It's logname, what do you expect, for them to read the bits directly from memory? If you're going to criticise this for anything, it should be that it doesn't support Windows, not that it calls out to libc.

[-] cockmushroom@reddthat.com 2 points 2 weeks ago

See the third clause in the kitty's train of thought. If it's of any consolation to you, I'd never have gone looking if I'd known what to expect.

[-] Magister@lemmy.world 4 points 2 weeks ago

yeah, all of this to call libc::getlogin().

[-] four@lemmy.zip 11 points 2 weeks ago

I no longer use any wrappers or utils, they're just bloat. Now I just use my dousing rod to read and set bits in my RAM, way more efficient

[-] cockmushroom@reddthat.com 3 points 2 weeks ago

#RewriteItInRod

[-] Eggymatrix@sh.itjust.works 5 points 2 weeks ago

I mean, have you ever looked at any low level code from any language that came out in the last 30 years? Its always C.

[-] cockmushroom@reddthat.com 7 points 2 weeks ago

Sure, but they don't usually have the audacity to market themselves as a viable alternative and cannibalize its system interfaces (or, in this case, claim to)

[-] shy_mia 2 points 2 weeks ago* (last edited 2 weeks ago)

I'm sorry but you sound like this:

(Not a Rust zealot to be clear, if something works and is fast enough idc what it's written in)

[-] cockmushroom@reddthat.com 1 points 2 weeks ago

I'd love to hear about how this improves on the original implementation.

[-] shy_mia 1 points 2 weeks ago* (last edited 2 weeks ago)

Mine was more of a general statement. There's definitely some actual business logic in coreutils that can benefit from being written in a memory safe language of some kind. I find complaining about getting a simple string using C APIs on a C based OS to be a pointless critique. That's not cannibalizing C APIs, it's making use of the only thing that's available.

[-] cockmushroom@reddthat.com 1 points 2 weeks ago

There's definitely some actual business logic in coreutils that can benefit from being actually written in a memory safe language of some kind.

so despite this not being an example of that you just had to chime in with a general statement? Why so thirsty to talk shit for no reason?

[-] shy_mia 1 points 2 weeks ago

there's only one person here being butthurt about this whole situation and trying to be confrontational and it ain't me.

coreutils has lots of stuff in it, there's going to be trivial stuff in it as well, which has to be programmed if one wants to make a full rewrite. I don't get what the big deal is. how is that sabotaging free software in any way?

[-] cockmushroom@reddthat.com 1 points 2 weeks ago

You're still doing it ...

It's one thing to treat open source like a giveaway and an other to treat it like infrastructure. If that difference doesn't matter to you then there's probably no reason to continue this conversation, but since you asked:

The main downside of the MIT license compared to the GPL is that it doesn't guarantee that derivative works remain open-source. This exposes code to a few key risks:

  • Proprietary "Forks": Companies can take MIT code, make improvements, and sell a closed-source product without contributing anything back. This is its biggest weakness. Competitors can create modified, closed-source versions that might splinter the community and reduce its control over the project's integrity.
  • No Patent Protection: MIT offers no explicit patent grant, so if a user of your code is sued for patent infringement, the MIT license offers no defense.

The GPL's "copyleft" policy is specifically designed to prevent these issues by ensuring that modified versions distributed to others must remain open source.

The good news is that code under MIT can be re-licensed as GPL by the copyright holder, but not the other way around. Unfortunately that sort of change probably won't sit too well with uutil's funding agreements.

If I were to depend on this project, 5 years from now, I’d rather not wake up to find the core contributors sold or yielded to a closed-source vendor.

Notice, I didn't once go after anybody with personal attacks over this. You couldn't seem to stop yourself.

[-] shy_mia 1 points 2 weeks ago* (last edited 2 weeks ago)

If you think I have any interest in personal squabbles over 8 lines of code, I don't.
That meme at the start was directed at your argument, not you in particular; those are not the same thing. I apologise if it came across as personal to you, but it wasn't meant to be. Notice how I immediately went to discuss the actual topic with no further "personal attacks" until you decided to get pissy with your next comment. Had you just shrugged and actually wrote your counterpoint instead, that would've been the end of it. You didn't. Just... you know, if you wanna go around being snarky on the internet, be prepared to receive some snark back as well.

With that said, I think the argument about uutils' license is a much more sound one. As a matter of fact I expressed the same concern a over year ago, albeit in a much less elaborate fashion: https://lem.lemmy.blahaj.zone/post/23171431/13400085 (Which of course I didn't expect you to dig up because that'd be absurd)
I'm not a big fan of uutils, believe it or not. It's not nearly as stable as they tout it to be, they broke cp recently as an example, and it's is generally not a step in the right direction IMO. Still, the fact that uutils may be ill conceived doesn't invalidate the fact that relying on public, official, C APIs is perfectly reasonable. Both can be true.
Had this post been about the license instead of "oh look the hypocrites use C APIs in the end" as if there was any alternative, we wouldn't be having this conversation.

[-] Eggymatrix@sh.itjust.works 1 points 2 weeks ago

Good engeneering solutions are better than steering clear of hypocrisy. The rust zealots will happily tell you that this is just an implementation detail, YOU should write rust, because you will have no bugs, they instead need to ship, so concessions need to be made.

[-] stingpie@lemmy.world 3 points 2 weeks ago

I'm not that well versed in rust, is this literally just wrapping the C library in rust, and calling it a rust implementation of it?

[-] Sxan@piefed.zip 7 points 2 weeks ago

Yes. Unsafely.

No, it is not rust implementation if the library (not does it call itself that). It is a rust implementation of one of core utility programs. Here is the code it reimplements, it is similarly short, and hopefully dispels the confusion - https://github.com/coreutils/coreutils/blob/165b62de8083ed9dec9ef4e1699ed44c3c7a2b91/src/logname.c

[-] shy_mia 2 points 2 weeks ago

To be fair, I doubt there's much that can be done about having to use C interfaces when interacting with Linux itself.

this post was submitted on 02 Jul 2026
40 points (100.0% liked)

Programmer Humor

42872 readers
217 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 7 years ago
MODERATORS