In principle integrated graphics are better. They share the same memory as the CPU, so games can just modify memory in place instead of doing a costly data transfer via pcie, this is one of the major pain points in emulators, games expect to just modify memory, while the emulator has to emulate this behaviour with limited bandwidth.
The problem is that most computer games do not take advantage of this, and instead do pcie transfers even if they could simply not do that. Also PC APIs (DirectX, vulkan, etc) are not build around this ability, while console SDKs are.
Plus, a console GPU is much bigger than usual integrated graphics. To put this into perspective, the major selling point of AMD's me ai max etc etc CPU is the big integrated GPU... It's still smaller than a ps5 GPU... It is more powerful because it's newer, but it's smaller, and the ps6 will likely have a bigger one.
And instead vscode supports SSH (without quotes), you can connect to an SSH host, and it will open files and folders on the host like it does locally. And if you open the integrated terminal it will run on the remote host. And it will forward the git login agent so you can commit or push with the credentials of your local machine. And it can forward ports from the remote.
Oh, I use the terminal a lot, it doesn't throw me off. When I can't have vscode (e.g. small openwrt devices) I can use vim. It's just plain easier to use vscode for editing files when I can
It's there and it's easy. Most people don't use terminal text editors unless they are SSHing in a server, and they would only do that sporadically, so it makes no sense to become proficient in a complex text editor like vim or Emacs for that little use case.
Sidenote: personally, I learned vim once, and used it extensively every day for two years. I stopped using it for one year and was back to square one. Now I use vscode for everything... Even when I'm using SSH, because vscode supports SSH
Hey Claude, what does "int open parenthesis asterisk fun closed parenthesis open parenthesis int c comma char asterisk asterisk v closed parenthesis equal get open parenthesis closed parenthesis minus greater sign fun semicolon" means?
Yeah, I also only learned natural deduction, until I got to the languages course and the professor told us "this is similar to natural deduction, but different".
Personally I don't like lean, I prefer coq. But that's mostly the vibes, both are actually fine. Lean doesn't do constructive logic, it does classic logic, but you have to give up program extraction for that. That's why mathematicians are head over heels for lean.
Not at all. I would not expect any riir project to reimplement the entire stack in rust.
This is not calling a random C dependency. This is literally calling the OS's API. Literally there's just this and the kernel.
As you said its goal is to rewrite a C codebase. The C codebase is coreutils. The correct way to getuser is to use the OS's API, which happens to be inside libc.so, which has nothing to do with coreutils, it's an entirely different codebase. End of the story.
The OS's API needs to be exposed as a c library, because c is the only language that can be imported from any other language. If you were to rewrite it in rust, it would use extern 'C' and it could not be any other way. And uutils would still import it from libc.
Maybe one day we'll see a rust rewrite of libc (tho it doesn't make much sense), but this has nothing to do with uutils.
If you are asking for a rust wrapper around the correct way to getuser, you have literally posted it. You can find it in uutils.
Also, being compliant is just being compliant. I wouldn't expect it to be called something like POSIX.rs unless it were implementing every part of POSIX. Which is clearly not what we have here. Or are you suggesting that bash should be called POSIX.c, because it's in c and it's POSIX compliant?
Well, if you want to be pedantic, I'll entertain you a bit more.
You see, C and Unix were "born" together. So sometimes, POSIX intertwines them in weird ways. In this case, getlogin is declared in unistd.h because it's part of the Unix standard API, however the POSIX standard states that it must be implemented in libc. So the POSIX compliant way to getlogin is to call into libc, which doesn't need to be glibc, you could use musl and avoid the GNU dependencies.
If rust's stdlib were to offer a getlogin function, the proper approach would be to still call libc.
It's like if on windows you were to call into Win32 to getuser, except on *nix it's the same file as libc.
If you want to replace the getlogin implementation, the POSIX compliant place to do it is not in coreutils but in libc, like the aforementioned musl library does.
So the key here is that getlogin is not art of the c system API. It is actually part of the POSIX APIs, it is just "located" inside of libc, which by the way, does not need to be GNU if you are concerned with uutils' philosophy.
I would like to interject for a moment. What you are referring to as coreutils Is actually coreutils+libc+Linux... And fill the rest yourself.
The "anti rust" crowd spends half of their time yapping about how you still need c in some places, then why did you get upset with calling into libc here? Are you suggesting to rewrite every rust program in C so you can have only c calling into c?
Both roads have been regularly travelled by car. I don't think any of those would be untravelled enough for Frost