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.
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.
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.
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.