>/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code. >When the Unix Support Group (development organization at Bell Labs) formalized everything, they gave it a long SCCS header, as they did every other file, and then needed to add "exit 0" at the end. The file was therefore infinitely larger than before. >At some point, somewhere (not sure where) it was decided this was poor engineering, probably because the shell spends time reading that big SCCS header as a comment one byte at a time >(it probably became a shell builtin somewhere along the line too, but that's for someone else to study.) >The command moved to /usr/bin/true. I don't know when, where and especially why. >Eventually to avoid the unbearable overhead of executing a commend that shouldn't be there at all, someone rewrote true as a C program. What was once an empty file is now a non-portable executable binary compiled from C. >This is why we can't have good software. This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly. >but the inexorable forces of improvement dictate we can't accept that, so here we are:
How does an empty file or "nothing at all" capture the essence of something being True. In fact modern langs tend to use False to represent something being empty or "not there".
If you think that is bad, wait until you take a look at modern Web development.
Caleb Martinez
Literally nobody uses Unix. Delete your thread.
Samuel Young
Robert the gay faggot Pike
Jonathan Robinson
>This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly. >a name capturing the essence perfectly. You have no reading comprehension.
Jason King
It's hard to take someone seriously when their entire legacy is making a language for diversity hires too stupid for C++.
Caleb Watson
touch ~/bin/true_empty && chmod a+x ~/bin/true_empty how to benchmark this against the default /bin/true?
$ time ./bench /bin/true 10000 Running /bin/true 10000 times...
real 0m8.000s user 0m0.326s sys 0m7.445s
$ file ./true ./true: empty
$ time ./bench ./true 10000 Running ./true 10000 times...
real 0m29.561s user 0m0.801s sys 0m10.058s
Grayson Walker
okay, i made the same 10k test but funrolled the loop so it doesn't impact the results: /bin/true: 3.528s true_empty 6.6318s true: 0.020s the last one is obviously just some shell build-in
Austin Jones
So why empty true is slower?
Connor Ross
Because a native binary is faster than a interpreted shell script, which is what executing an empty file essentially is. Pike's argument isn't that empty true is better because it's faster, but because it's simpler.
Why is it a shell script if it has no shebang line pointing to a shell? It might be worth calling it with the absolute path.
Joshua Morgan
If the shebang is missing, /bin/sh will be used
Hunter Nguyen
nullptr > empty file
Nathan Rodriguez
>Unix and Linux are pieces of shit Their only plus arguments are that they are better than winlols and macos.
Austin Wilson
if your shell doesn't automatically parse true command into a built in function and actually runs /bin/true instead you need to switch a distro like right now
One more to add to this. This time with busybox: busybox true: 3.0216s It's the fastest so far, but I'm not sure if that is due to bb itself being faster or it being staticly linked vs GNU/coreutils' /bin/true which is linked against few M of libs
Owen James
It's still just 1 and 0 so technically software hasn't evolved at all
This. I was needing a DLL injector to rewrite custom code into a closed source application for a client. Every fucking google result was binaries >2MB with custom libraries and alot of bloat to go with it, and to boot the DLL was already fairly large since I had to rewrite a large portion of the program.
I ended up coding a custom implementation in ASM only calling the absolute necessary API's and assembling it as a binary with a custom PE header.
Final result was a 97 byte portable executable with exactly the same functionality as all the bleeding edge DLL injectors.
Programming is not what it used to be. People are just lazy I guess. In the real world you're expected to show results, most of the time it doesn't matter how you did it as long as it works.
You are doing God's work user, wish more programmers were like you.
Bentley Adams
It was a 987 byte PE, not 97 missed a number there.
Juan Garcia
>most of the time it doesn't matter how you did it as long as it works. yeah that sums it up.
Blake Cook
>most of the time it doesn't matter how you did it as long as it works. You missed the most important part: "as long as it works FOR NOW."
The amount of complexity and bloat is basically making software like grinding in Tony Hawk, you keep going side to side to balance and keep things going, but it eventually gets unmanageable at which point you fall on your face and lose a 150,000 point combo.
Nathan Walker
Exactly and most of the time, the written code is shit and looks like it was done in a rush to just get something working.
Honestly sometimes I just find it easier to read compiler generated assembly than most projects on github.
Lucas Phillips
Which is better? Normies being able to write a program, providing thousands upon thousands of new applications to pick from that are bloated. Only smart people being able to write a program, providing small application pools that only do their job and do them well.
Tyler Williams
Normie idea guys and autist programmers
Jaxson Anderson
Doesn't work like that. The bloated code is what we are stuck with when normies don't pay attention at making something different, and even what you call smart people not thinking on doing different than the normies.
Dominic Lee
still in /bin/true for me other one doesn't exist
however it is 31KB file filled with crap (compiled crap at that)
Ayden Diaz
wow, fuck that cunt in OP
Jose Jones
Are we really going to argue the usefulness of shell scripting?
Second. But the problem is that Normieitis is a contagious disease and once its settled in everyone comes down with it.
Bentley White
/thread OP faggotry gets a sage
Jacob Nguyen
At that point it's just magic to the normies, how normie programs are to ubernormies. Logistics and feasibility need to be explained to normies, and autist suck at explaining anything. Also, the FOSS vs propritary gets involved havily here. Both have a realatively even amount of bloat to them, maybe foss is a bit less, but lacks that is what makes it lack the features of propritary, both are probably written in the same bloated way, both with normie programmers today. Autist are forced into principle, it's just how their minds work, they get stuck on philosophy and care more about it than normies do, which makes them more keen toward FOSS. On the otherhand, autist struggle finding jobs, and have a lot of trouble getting things done for a business, so they avoid hiring autist, leading to propritary software losing out, meaning R&D and other benefits of propritary development don't happen, overall slowing the progression of the technology.
Dominic Nelson
>>The command moved to /usr/bin/true. I don't know when, where and especially why. This happened in the 70s. As they added more stuff to Unix eventually they outgrew a disk drive so they got another and put user files (/usr) on the second one and the OS on the first. Then the OS outgrew the first drive so they borrowed some space from the /usr second drive.
So yeah, the mess that is the FHS with a gorillion compatibility symlinks everywhere happened because they ran low on drive space in the 70s. And they say only Windows can do backwards compatibility....
Nicholas Cooper
I don't see what's wrong. And I still don't see why an empty file would be a sensible or logical representation of "True".
Austin Morales
>muh piece of paper! >fagos is unix >mach-o executables not sysv
Cooper Gomez
how's it feel not having any perspective on the subject of unix?
