Live data from Hacker News

Websocketd

websocketd.com

21–30 of 233 posts

Re: Websocketd

#21
post #15
post #10

Ok I know the software-today-is-so-bloated trope is overplayed but... "the UNIX way"? The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.

> Written in Go 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.

You can cut your binary size almost in half on Linux by removing debug information and symbols with:

`go build -ldflags="-s -w"`

Re: Websocketd

#22
post #19

is it me, or does the site look really similar to letsencrypt.org? I looked on both sites and neither say they're using a template.

FWIW the css template is just some bootstrap stuff, and this for the syntax highlighter in the code snippets: /* http://prismjs.com/download.html?themes=prism-twilight&langu... / /* * prism.js Twilight theme * Based (more or less) on the Twilight theme originally of Textmate fame. * @author Remy Bach */

Re: Websocketd

#23
post #13

Earlier quoted context omitted.

SVR4 came out 30 years ago. I think it's time to let it go.

I'm fine with letting it go! I just don't understand why they're claiming this is "the UNIX way" as if that's a good thing.

I hate to be trollbait, but: "the Unix way" is less about the size of programs, and more about programs being built as composable, modular components that interact together over a common interface.

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.

Re: Websocketd

#26
This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.

Re: Websocketd

#27
post #15
post #10

Ok I know the software-today-is-so-bloated trope is overplayed but... "the UNIX way"? The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.

> Written in Go 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.

It's certainly an issue, especially now with wasm: https://github.com/golang/go/issues/27266

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 :)

Re: Websocketd

#28
i’ve been using this in production to stream logs to a web console (~2,000 sets of logs distributed across 4 server with about 350 active connections at a time) and have never had any issues

Re: Websocketd

#29
If you really wanted to follow UNIX philosophy, why not build atop xinetd?

for example... simply accept stdin and stdout as I/O streams by default, but don't provide a network mechanism.

Re: Websocketd

#30
post #15

Earlier quoted context omitted.

> Written in Go 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.

You can cut your binary size almost in half on Linux by removing debug information and symbols with: `go build -ldflags="-s -w"`

I thought it was dangerous to use `strip` on any go binaries, because it would result in an incorrect program. LDFlags might cause something else but isn't it the same concept?
Post reply on HN