The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.
The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.
This is a program built around executing programs and communicating over pipes. It's composing programs together. I think that's certainly UNIX-ish.
No, but literally the first point is:
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
It's not hard to see how this would apply to libraries, and how including third party code in your binary would break this idea because you're essentially "freezing" the application in time.
Your definition regarding "composing programs together" is not all that makes a program UNIX-ish.
I have a fairly simple web-app written in go – no websockets, just net/http. I just checked and the binary size is 6.8 megabytes.
There's a lot in there. For starters, there's the go runtime. Then there's the HTTP server.
I suspect there may be ways to improve on the binary size if it mattered so much. xz gets it down to 2.1MB, suggesting there's some redundancy in there.
`go build -ldflags="-s -w"`
Probably unavoidable for this kind of app though. Unicode alone involves a whole lot of data tables that are going to be hard to get rid of unless they're dynamically linked.
7MB is still a lot smaller than Docker containers :)
And why should it be criticized? Outside AT&T, people were writing OSes in high level languages since 1961.
Curious people can read more about it at https://en.wikipedia.org/wiki/Unix_philosophy or https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...
The websocketd site outlines this fairly well with the big quote on their homepage.
Looked at another way, a Unix-like ecosystem satisfies two of the principles of a SOLID software architecture: the Single Responsibility Principle and (arguably) the Open-Closed Principle.
If websocketd focuses on handling the nuts and bolts of websocket connections and invoking other programs and piping data into and out of them over a standard interface, then it's a Unix-like architecture, even if it's a fat, monolithic, statically linked binary.
I hear that representing the absence of value as a number was invented about 6000 years ago, perhaps we should abandon that as antiquated as well..
also, to wit, a Unix kernel of recent vintage:
$ uname -msr
OpenBSD 6.3 amd64
$ du -skc bsd.rd bsd
9664 bsd.rd
12912 bsd
22576 total
vs, say, a Linux kernel of recent vintage: $ uname -msr
Linux 4.9.0-8-amd64 x86_64
$ du -skc /boot/vmlinuz-4.9.0-8-amd64 /boot/initrd.img-4.9.0-8-amd64 /lib/modules/4.9.0-8-amd64
4152 /boot/vmlinuz-4.9.0-8-amd64
21616 /boot/initrd.img-4.9.0-8-amd64
212248 /lib/modules/4.9.0-8-amd64
238016 total
yes, there are likely more drivers in the latter.
highly doubt there is an order of magnitude more though.not to mention some 'modern' npm+webpack monstrosity.
that said, given the latter, i can hardly fault a <10Mb go executable as 'excessive', so you're right on that front.
That's exactly what they are; ~180M of those 212M are in drivers/. And even outside that, it includes stuff like fs/ocfs2, which I don't think OpenBSD supports.