cloudfudge

You not bending over and opening your wallet is, frankly, a red flag. /s

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 "&nbsp" on my printed bank statements.

There's nothing "fake" about the email. It's just an alias made specifically for each recipient.

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.

"Tens of thousands of new millionaires" sounds like a disaster tbh.

> Only usable if you only care about your own system.

Ahaaa, that clicks. Yes, I tend to build software that only cares about my own systems.

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.

That isn't truly self-contained. It still relies on libc.

> that also compiles to a binary

"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?

"Attempting" is not in any way a valid description of what he's doing there. That was a wild clip.

"Requiring something be allowed" != "requiring them to have them"

> The consequence of saying they cannot choice to not have them. Is saying your requiring them to have them whether or not the people their want them.

Sorry, but this is nonsense. They are currently not banned in Maine, yet they do not have them. There is obviously no requirement to have them.

I can prove everyone doesn't love hyberbole because I have found a counterexample, but I cannot prove everyone doesn't use Rectangle.app.

In what universe is requiring them the only alternative to banning them? The actual alternative is obvious: not banning them.

As someone who's really into music theory, I am always annoyed by what I perceive as a patronizing faux exaltation of it supposedly being mathematically based. It's not math; it's cyclical patterns. Yes, it can all be represented mathematically, and it is surprising to some people how something with feeling can map to these interesting cycles of discrete values in unexpectedly regular ways, and there are very interesting mathematical ratios involved, but that doesn't make it math. I don't think we need to pat John Coltrane on the head and talk about how he's actually kind of smart because he's doing math.

I would love to see the effect of the mirror's effect on the motion of the camera in a weightless environment. I bet it's enough to measurably affect the picture, especially on a long exposure. Net torque of it opening and then closing should be near (but probably not exactly) zero, but while it's open the camera should spin a tiny amount.

Oracle Cloud isn't actually "terrible cloud", but it definitely isn't geared toward smaller users like startups and individuals. It's downright hostile to casual use. But for fortune 500 companies who don't mind being in bed with Oracle, the price can be right.

The focus not being the DB for 20 years is mostly true, with the exception that all of their applications are well-served by having a very scalable and very bulletproof database in-house.

> Here are some completely normal and plausible [reasons]. It was worked on over weeks internally, commits referenced other internal NVIDIA software/libraries they used. It name dropped projects and code names. Maybe it was just an extremely long chain of messy commits that is improper to have on a potentially big open source repo.

... it referenced internal servers and they want to scrub that for security reasons

... it might have had secrets embedded at some point because it was a quick and dirty proof-of-concept

... it could have had swear words in the code

... it had enormous binaries checked in at one point and they don't want the repo to be huge

... they don't want you to know the names of everyone that worked on it

... it's forked off other internal work that isn't public yet

There are so many reasons that the easiest thing to do is just snapshot it and have minimal public git history. Some places I've worked make it so publicly, there's one commit per release. Did NVidia do this? Well, they didn't collapse it down to a single commit, but we have no evidence that the commits we see were the actual internal development timeline.

> there's overwhelming evidence that their public github history is accurate and Nemoclaw was written in a weekend

Aside from commits on github, which we've already established mean absolutely nothing, what is the overwhelming evidence?

I don't have to know their reasoning in order to know public github history is not necessarily an accurate record of all changes.

Just let go of the notion that a 4 day github history necessarily means the project is only 4 days old. It's a ridiculous assumption to base an argument off of. It's extremely normal to have work in one, perhaps internal, repo which you then blast over to a public repo in one (or a few) big commits. There is zero reason for them to let you see their internal progress.

I got a new Maverick last year for $24.5k.

What is this "security through obscurity" you're talking about? We're talking about running linux in a VM running in a browser. That has just as much attack surface (and in some ways, more) as running linux in a hypervisor.

GP says "You don't want to just run that code in ... even a very well protected VM." Why?

I just had a conversation with gemini where I asked it to analyze my style and one of the things it claimed was that I referred to things as "AI slop" and "brainrot", both of which are terms I haven't ever used. I spent a few minutes trying to get cites for that and it kept producing the same quotes from other people and insisting it had corrected the record.

Seems like it's overstating perceived anti-AI sentiment. :)