yuliyp (u/yuliyp) - Readit News

yuliyp commented on Kilauea erupts, destroying webcam [video] youtube.com/watch?v=TK2N9... · Posted by u/zdw

hnburnsy · 13 days ago

Looks like the camera and stream are still active...

https://m.youtube.com/watch?v=BqmpkUdMtyA

yuliyp · 13 days ago

Starting at 9:46 is when it goes from wow to WOW. The last 2 minutes in particular are incredible, including the bizarre artifacts in the last 15 seconds before the stream dies.

yuliyp commented on Cloudflare outage on December 5, 2025 blog.cloudflare.com/5-dec... · Posted by u/meetpateltech

crote · 14 days ago

Is a roll back even possible at Cloudflare's size?

With small deployments it usually isn't too difficult to re-deploy a previous commit. But once you get big enough you've got enough developers that half a dozen PRs will have been merged since the start of the incident and now. How viable is it to stop the world, undo everything, and start from scratch any time a deployment causes the tiniest issues?

Realistically the best you're going to get is merging a revert of the problematic changeset - but with the intervening merges that's still going to bring the system in a novel state. You're rolling forwards, not backwards.

yuliyp · 14 days ago

I'd presume they have the ability to deploy a previous artifact vs only tip-of-master.

yuliyp commented on AI scrapers request commented scripts cryptography.dog/blog/AI-... · Posted by u/ColinWright

Calavar · 2 months ago

If you are serving web pages, you are soliciting GET requests, kind of like ordering a package is soliciting a delivery.

"Taking" versus "giving" is neither here nor there for this discussion. The question is are you expressing a preference on etiquette versus a hard rule that must be followed. I personally believe robots.txt is the former, and I say that as someone who serves more pages than they scrape

yuliyp · 2 months ago

Having a front door physically allows anyone on the street to come to knock on it. Having a "no soliciting" sign is an instruction clarifying that not everybody is welcome. Having a web site should operate in a similar fashion. The robots.txt is the equivalent of such a sign.

yuliyp commented on Responses from LLMs are not facts stopcitingai.com/... · Posted by u/xd1936

HarHarVeryFunny · 2 months ago

Right, but now you are not talking about an LLM generating from it's training data - you are talking about an agent that is doing web search, and hopefully not messing it up when it summarizes it.

yuliyp · 2 months ago

Yes, because most of the things that people talk about (ChatGPT, Google SERP AI summaries, etc.) currently use tools in their answers. We're a couple years past the "it just generates output from sampling given a prompt and training" era.

yuliyp commented on Poker fraud used X-ray tables, high-tech glasses and NBA players bbc.com/news/articles/cz6... · Posted by u/vegasbrianc

darepublic · 2 months ago

I understand the "need" for cheating but it does seem like overkill the way they cheated, at least as described. They've already got colluders, and then the auto shuffler reads the cards, and then they've ALSO got the contact lenses? Just some marked cards would have been sufficient. And then the rare time the fish catches up after being behind is your "let them win a hand and get traction". It just seems like they really went too far to control every part of the hand

yuliyp · 2 months ago

Perhaps those were different iterations of the technique over time. Start with marking cards to identify face cards, then move on to x-ray table.

yuliyp commented on When Compiler Optimizations Hurt Performance nemanjatrifunovic.substac... · Posted by u/rbanffy

anon-3988 · 2 months ago

Since the biggest one is only 11110 (5 bits), can't you use a lookup table of 32 characters by masking the last 3 bits?

yuliyp · 2 months ago

That's not the problem. The problem is that you're adding a data dependency on the CPU loading the first byte. The branch-based one just "predicts" the number of bytes in the codepoint and can keep executing code past that. In data that's ASCII, relying on the branch predictor to just guess "0" repeatedly turns out to be much faster as you can effectively be processing multiple characters simultaneously.

yuliyp commented on AWS multiple services outage in us-east-1 health.aws.amazon.com/hea... · Posted by u/kondro

malfist · 2 months ago

But that is the stance for a lot of electrical utilities. Sometimes weather or a car wreck takes out power and since its too expensive to have spares everywhere, sometimes you have to wait a few hours for a spare to be brought in

yuliyp · 2 months ago

No, that's not the stance for electrical utilities (at least in most developed countries, including the US): the vast majority of weather events cause localized outages (the grid as a whole has redundancies built in; distribution to (residential and some industrial) does not. It expects failures of some power plants, transmission lines, etc. and can adapt with reserve power, or, in very rare cases by partial degradation (i.e. rolling blackouts). It doesn't go down fully.

yuliyp commented on Elixir 1.19 elixir-lang.org/blog/2025... · Posted by u/theanirudh

dns_snek · 2 months ago

No their results are correct. It roughly halved the compilation time on a newly generated Phoenix project. I'm assuming the savings would be more extensive on projects with multiple native dependencies that have lengthy compilation.

    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile
    ________________________________________________________
    Executed in   37.75 secs    fish           external
       usr time  103.65 secs   32.00 micros  103.65 secs
       sys time   20.14 secs  999.00 micros   20.14 secs

    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile
    ________________________________________________________
    Executed in   16.71 secs    fish           external
       usr time    2.39 secs    0.05 millis    2.39 secs
       sys time    0.87 secs    1.01 millis    0.87 secs
    
    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile
    ________________________________________________________
    Executed in   17.19 secs    fish           external
       usr time    2.41 secs    1.09 millis    2.40 secs
       sys time    0.89 secs    0.04 millis    0.89 secs

yuliyp · 2 months ago

Oh, interesting. I guess `time` is only reporting the usr/sys time of the main process rather than the child workers when using PARTITION_COUNT higher than 1?

yuliyp commented on Elixir 1.19 elixir-lang.org/blog/2025... · Posted by u/theanirudh

asa400 · 2 months ago

Just a data point on the deps compilation, on a small Phoenix app with mostly stock Phoenix deps:

  MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile  32.30s user 7.23s system 320% cpu 12.336 total

  MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile  0.37s user 0.49s system 12% cpu 6.970 total

  MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile  0.38s user 0.50s system 12% cpu 7.236 total

Machine is a Mac M1 Max, `rm -rf _build` in between each run.

yuliyp · 2 months ago

You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.