gcommer

Only two commits have 'Co-Authored-By: Claude' and they're both PR contributions from a non-google email.

For feature parity, the old PC will require USB OTG, HDMI input, wiring for ATX control, and a software stack.

This is why I recently went with a PiKVM. Pricier and clunkier but much more open and transparent.

AlphaPhoenix mentions in the description that he wants to try and image an interference pattern, and it seems possible.

Though it wouldn't really be showing you the quantum effect; that's only proven with individual photons at a time. This technique sends a "big" pulse of light relying on some of it being diffusely reflected to the camera at each oscilloscope timestep.

Truly sending individual photons and measuring them is likely impractical as you'd have to wait for a huge time collecting data for each pixel, just hoping the photons happens to bounce directly into the photomultiplier tube.

The article never claims tariffs going into effect caused the Q1 issues.

Yep, and that's what I stick to today. I just worry how much longer until the remaining games that support this die out...

Agreed. To be more precise: I think the solution is small, community-run servers. This allows large, consistent groups of players to play together regularly with a much higher percentage of admins who can handle cheaters manually.

I also maintain that human judgement, can still catch things anti-cheat software is yet incapable of. Example: it doesn't matter how well hidden your aimbot is, I still notice cheaters when their accuracy is wildly out of proportion with their strategic understanding of the game.

Even better: never use process.exit(). Set process.exitCode instead.

https://nodejs.org/api/process.html#processexitcode

I know solo projects always have an infinite list of "nice to haves". But personally I never skimp on vendoring dependencies.

In my experience, not vendoring has _always_ led to breakages that are hard to debug and fix.

Meanwhile, vendoring is quite easy nowadays. Every reasonable package manager, and even npm, can do this near-trivially.

Avoiding side effects does not require inventing a brand new purely functional language programming language.

Tinc is incredible, it has worked flawlessly for me for 6+ years with exactly 0 maintenance.

As trustworthy as it is, I am sadly on the hunt to replace it. Compared to wireguard, the throughput ain't great, and it takes way too much CPU on my low power nodes. I would pay good money for "tinc, but with wireguard transport" -- there's of course projects purporting to do this but I haven't found one I trust yet.

It is a weird example. But that transform does not work generally. Consider if you want to stop when insertIntoMouth() returns a particular value. Or if there is some filter() step, so that you don't know that `n` input items will map to `n` output items.

The difference here is push vs pull (also called eager vs lazy). It is often easier to write pull computations that only do the work that is actually needed.

I know multiple companies doing the same thing -- it's really great to use JSX that most JS shops will already know instead of introducing a whole other template language that (typically) have a brand new syntax, weird logic-in-html, and/or poor componentization.

Lot's of cool follow-on value-adds you can do once your emails are in JS like this. Like writing test cases to validate that none of your emails are susceptible to HTML injection. Or writing tests about never exceeding Gmail's 100kb limit. Or rendering your emails in Storybook.

This is a common thought but it certainly hasnt been the case at any of the bay area startups or faangs I have worked at or interviewed for. Always 40 hrs.

Are there super heavy hustle places? Probably, but most places realize more time is not linearly more output for creative/knowledge work.

(Similarly, the internet would have you think anywhere offering "unlimited vacation" is a scam but I used and loved it)

In every interview I've done, lunch was explicitly bracketed by "this is a free, casual lunch that won't affect your interview at all".

And as an interviewer, I've never been asked to report on lunch chats.

You're not my peer. We're not having fun.

Actually, most interviewers are your peers, and they typically know that you're under interview stress and are trying to help. If you can't take a break and de-stress during lunch, you're just hurting yourself.

There's tons of little details and inefficiencies in elisp that crop up such that easy things like "listen to responses" are hard to get fast. Random example: before native json support, large lsp responses (which can be multiple megabytes from some servers!) would take over a second and hitch the UI just to parse the json response. And that was after a lot of work to get response parsing dominated by json instead of GC time.

Plenty of server-rendered apps have been caught putting private data in responses. In this very same comment section people have mentioned the story of a state website that included teacher SSN's in hidden fields[1], and OJFord shared a story of a server that included a full env var dump in error messages[2].

This sort of thing happens all the time to all sorts of services. Rather than just blaming JS, it's far more productive to think of technical controls that could catch this. For example Taint Checking[3] or scanning server responses for API keys.

[1] https://news.ycombinator.com/item?id=31026374

[2] https://news.ycombinator.com/item?id=31026415

[3] https://en.wikipedia.org/wiki/Taint_checking

Fair point, but I haven't hit it in practice. Tons of services are embracing docker as a first-class output. I just checked and I run exactly 2 images that are from a third party.

I feel for you. I also wasted a lot of very painful hours trying to get it to work. I even had it working for a while before a docker update broke it -- turns out docker-compose's ipv6 support that many people relied on for years was a "bug" that they "fixed".

Ultimately I also gave up and now have a combination of port forwarding, nat64, and 10+ socat proxies in my docker-compose file. (Specifically, intranet->container and container->intranet are ipv6; but container->container is still ipv4)

More generally, I now try to keep my docker host as stock as possible. Whenever I'm reaching for daemon.json I just catch myself, take a step back, and say "what's the stupid but easy way to get this working".

Lots of good points about the challenges of self-hosting throughout this thread, especially maintenance, security, and time-investment.

Here's my solution to all of them:

Invest in your common infra. Docker provides stable images configured primarily with env vars. I have a docker-compose host with logging/monitoring/alerting. All service-specific files are mounted from a NAS that has backups. All network access is closed by default, but exposed via a central login proxy (tailscale would be an easier alternative, but my Beyondcorp-esque system lets non-technical family members use my services easily from anywhere by tapping a yubikey).

That's 3 pieces of infra to maintain (docker host, NAS, login proxy) but I can check all the boxes for self-hosting 15+ services. O(n) services with O(1) infra.

I regularly spin up new services in under 10 minutes, while only having to touch 3 files that I am already familiar with (docker-compose.yml, dnsconfig.js, nginx.conf). I've run stable services for years on this stack. The only painful issues have been upgrades to the docker host, docker ipv6, and hardware issues.

This is all on a recycled computer in the basement, with a cheap VPS as a stable public entrypoint.

Is there really an epidemic of EE's who know how to use a field solver, but don't know to consider coupling between signal lines? My intuition is the opposite of yours: most EEs actually know the ideas from the Veritasium video. Therefore, the way EE is taught is not a lie, since it includes that knowledge.

(For completeness, the alternate take is that Veritasium was claiming "the way _elementary_ EE is taught is a lie" -- but that still leaves Veritasium having left out critical context for such an audience)

I found the responses from other EEs on youtube like Electroboom and EEVBlog disappointing. [...] Rather than responding towards him with hostility, perhaps they should have considered if their own mental models weren't quite as accurate as they had thought.

Personally, I didn't get hostility from any of their videos. They were just injecting some engineering sensibility to bridge the gap between most people's EE knowledge and Derek saying "everything you've been taught is a lie."

Also, to my recollection they both absolutely attested that yes Maxwell's equations are the correct description which supports Derek's results (modulo Electroboom's callout about the bulb actually always being on)

There's two bits of controversy:

1) Slander: He claims that the way EE is taught is a "lie" but leaves out the many ways that standard EE models agree with his result.

2) Clickbait / inadequate explanation: he leaves out many details in order to make his experiment seem far more mind-blowing that it really is.*

Critique 1 can be countered by saying he is targeting a lay audience (say, they took 1 high school physics course).

Critique 2 can be countered by saying he is targeting a slightly more advanced audience who would understand those details (say, 1 or 2 college courses).

But no matter who you think he's talking to, at least one of these critiques holds.

* In particular: a) He doesn't explain how "1/c" is derived from the 1m gap. b) He portrays the electrical field as totally detached from the layout of the wires. But if you rearrange his lightsecond-long wires to be a circle, the effect won't happen. c) He leaves out the fact that this experiment works even if you cut the ends of the wires, which would change many people's intuition (think of the wires more like antennas). d) His thought experiment is actually wrong: see Electroboom's video, but basically by Derek's own parameters the light would _always_ be turned on.

I find the focus on the employee being WFH very weird -- there's no justification for the remote work situation contributing to this theft. There's just a nebulous claim of too little oversight. But if Sony apparently allowed this employee to just directly transfer nine figures by saying "yeah my boss approved it" then I highly doubt they have robust safeguards to stop this from happening in an office environment either.

Aside from being unwanted, it also is symbolic of much of Mozilla's worst behavior. During launch, it was specifically described as not being a paid placement: "There's no monetary benefit to Mozilla from the integration: Pocket didn't pay for placement in the browser"[1]. This way key to the discussion about why they chose Pocket over any other reading list plugins -- but this turned out to be a lie: "Hum. Apparently, _someone_ in bizdev thought that "revenue sharing" doesn't involve money, and spread information inside Mozilla accordingly. :rolling eyes:"[2]

Also, I can't find the reference anymore, but I definitely remember promises of getting a pref to use a different backend. AFAICT, that was another lie.

So multiple lies surrounding this product, along with it being continuously pushed on users (I've had it disabled via pref since day 1, and then it started showing up on the new tab page regardless).

And people are surprised when it gets hate.

[1] https://www.pcworld.com/article/2930532/reading-service-pock... [2]: https://groups.google.com/g/mozilla.governance/c/2PYq2w8tejs...

Their video on the front page contradicts itself. They highlight the UI coded by "user interaction" and no surprise, the Pocket button in the URL bar has tiny usage. And yet, in the new design? It's bigger and more prominent. And they try to say this is data-driven in the voice-over.

Now, yet again, I'll have to just pin Firefox and stop updating it everywhere for a few months until the inevitable "undo all these changes" plugins are ready.

Update: Just tried the new design. As expected, the new tabs take up substantial vertical space and even compact mode (now hidden behind about:config) barely helps. Time for more userChrome.css...

git add --patch can help here, but it's still tedious work.

This is pretty much the operative line of the post. Rather than invert my whole development flow, I just use a UI like Magit which makes patch commits trivial.

Same. It's seriously hard to say how awesome it is that a few days invested into customization ~10 years ago have lasted with me all this time. According to my dotfiles, the last "upstream updated something so I had to fix my setup" change was 4 years ago.

Firefox is the only program I run that requires constant "config maintenance".

Meanwhile, I've used macOS at work for ~5 years. Every time a big release comes out, IT departments have to go around screaming "DONT UPDATE IT WILL BREAK EVERYTHING" for a month. Once that calms down later we finally can update (though I only _want_ to update because by that point the incessant "Update now or tonight?" prompts have driven me mad) -- and instead of everything breaking, it merely breaks half my customizations and I have to waste time fixing it.

This could be handy for automating a real world end-to-end test of a yubikey auth flow.

tl;dr of confidential computing:

In normal cloud computing you are effectively trusting the cloud provider not to look at or modify your code and data. Confidential computing uses built in CPU features to prevent anyone from seeing what is going on in (a few cores of) the CPU (and in EPYC's case, encrypt all RAM accesses). Very roughly: These CPU mechanisms include the ability to provide a digital signature of the current state of the CPU and memory, signed by private keys baked into the CPU by the manufacturer. The CPU only emits this signature when in the special "secure mode", so if you receive the signature and validate it you know the exact state of the machine being run by the CPU in secure mode. You can, for example: start a minimal bootloader, remotely validate it is running securely, and only then send it a key over the network to decrypt your proprietary code.

Effectively, it increases your trust in the cloud from P(cloud provider is screwing me over) to P((cloud provider AND CPU manufacturer are both working together to screw me over) ∪ (cloud provider has found and is exploiting a vulnerability in the CPU)).

Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.

If you trust the CPU vendor to not be colluding with your cloud provider, and that the cloud provider hasn't found and exploited a hardware or software vulnerability in the enclave, then a successful remote attestation is a cryptographic proof that you are executing your code unmodified without the cloud provider being able to see either your code or (with careful delivery) your data.

There are additional side channel concerns such as RAM bus sniffing; it looks like the EPYC processors handle that by encrypting all memory accesses. Additional concerns include memory access patterns and power usage monitoring; I don't see these mentioned in any of AMD's SEV whitepapers but they can (with great care) be mitigated in your software.

Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.