3 ms·
Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally
by alerighi 2y ago
Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. That could be a performance problem, since busybox is used typically in embedded systems that doesn't have a lot of resources: imagine a shell script that runs a command in a loop, it has to do a lot of extra work.
Finally, symlinks can be relative, while the solution you proposed is not. This is particularly useful for distributing software, e.g. distributing a tar file with the busybox itself and their symlinks.
In fact, you don't even need symlinks at all: you can even have hard links, that could even save disk space on embedded filesystems, that are readonly images anyway.
- Too 2y agoImagine the performance problems of running 'shutdown' and 'reboot' in a tight loop! Besides, should one really write something performance critical for embedded in shell in the first place?
- vlovich123 2y agoI’m going to challenge you on the performance angle. Instead of doing the shebang line, it has to traverse the filesystem to resolve the link. I suspect that’s probably more expensive than parsing the shebang line. Indeed, a shell script that runs a command in a loop should have busybox detecting the built in command & executing it inline without spawning executables via the file system (this is common in bash as well btw). There are valid reasons but I think the performance angle is the weakest argument to make.
- deleted 2y ago[deleted]
- Denvercoder9 2y ago> Instead of doing the shebang line, it has to traverse the filesystem to resolve the link. I suspect that’s probably more expensive than parsing the shebang line. I highly doubt that. Path traversal is one of the most optimized pieces of code in the Linux kernel, especially for commonly accessed places like /bin where everything is most likely already in the dentry cache. For the script with a shebang on the other hand it first has to read it from disk (or the page cache), then parse the path from it, and then do a path traversal anyway to find the referenced file.
- cxr 2y ago> Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. Those that exist today would, but no kernel would have to work like that. Once you've agreed that monolithic kernels have merits, you've accepted that the kernel can do whatever it wants to make this efficient—including being complicit in this scheme and leapfrogging over most of what you just described.
- kelnos 2y ago> Those that exist today would, but no kernel would have to work like that. That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong." We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- cxr 2y ago[flagged]
- jolmg 2y ago> it's against the rules here to those kinds of fake quotes. What part of the guidelines are you referring to? Also, despite the quotation marks, I don't think they mean to quote you. They're just rephrasing you as they understood you. Coincidentally enough, I've just done that too in another comment: https://news.ycombinator.com/item?id=41442007 https://news.ycombinator.com/item?id=41442007
- cxr 2y ago