This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.
I don't think it's very common to believe the Chinese people are bad guys. It's the government and its control of the people that's the problem. And no, I don't think the US is immune to that sort of problem either.
A mocha is an espresso drink. A latte is an espresso drink. A cappuccino is an espresso drink. An espresso is an espresso drink. Some espresso drinks have milk in them and some don't. Anyone offended by the question, "did the espresso drinks have milk in them?" is just looking for something to be offended by, as seems to often be the case with people who fly off the handle over the topics of coffee, pasta, and pizza.
Some sites that block "+" in email addresses are actually just doing it out of incompetence. My credit union, for example, will actually accept an address with a "+" in it, but nothing will work because some broken bit of web 1.0 plumbing along the way converted it to a space (it shows up that way on my profile page). I wouldn't be surprised to see " " on my printed bank statements.
I think "he's almost certainly a better programmer than me" is a double form of humility: first, he's assuming that Fabrice Bellard is a better programmer than him based on the evidence and reputation, but he's also admitting that he doesn't have direct knowledge of this. Hence "almost certainly."
I just poked around in your reference and every county I looked at in california is near all-time highs (higher than or equal to 2022) except for the northern nowheresville counties.
Yes, totally agreed that for a LOT of organizations, relying on a system dependency that will likely get upgraded independent of your service is probably the simpler way to go and the way to make sure your TLS implementation stays current. But when you're building tier zero services that must control their dependencies like their lives depend on it, the opposite approach can be quite beneficial, and I don't need Microsoft telling me I'm doing it wrong because I'm not in the 99% use case.
Agreed. The fact that .NET has a way to do true static linking is great and I didn't know it existed. The fact that they apparently think it's a weird and undesirable thing is less great and would make me worried that they're going to undermine the ability at some point. Golang has had this ability since way back and they think it's a strength.
Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be and do not consider that a liability but a strength.
Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS.
(full disclosure, I don't think I ever had my service look up the address of localhost)
edit: seems like you probably have CGO_ENABLED=1, which is now the default and will cause simple networking things to use libc. Set CGO_ENABLED=0 and you won't have libc.
"compiles to a binary" is not a useful criterion. The criterion Go is winning on is "compiles to a single, completely self-contained binary," meaning it does not depend on libc or any external runtime. You can't say that about .NET. You can't say that about damn near any other programming language. It's extremely rare. The fact that .NET uses a binary packaging format is, like... well ok, so what?