This is correct and fine?
It’s also a c wrapper
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 tolibc.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.
yeah, all of this to call libc::getlogin().
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
#RewriteItInRod
it’s wrappers and utils all the way down.
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.
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)
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)
I’d love to hear about how this improves on the original implementation.
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.
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?
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?
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.
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.
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?
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
To be fair, I doubt there’s much that can be done about having to use C interfaces when interacting with Linux itself.
