egnehots

don't you then introduce a new risk?

with a gap between the update of your deps, you are at risk of systematically being unpatched for a window of time that the attackers know (just after a fix is published).

From a customer perspective, I think there should be an option:

- prioritize security: get patchs ASAP

- prioritize availability: get patchs after a cooldown period

Because ultimately, it's a tradeoff that cannot be handled by Cloudflare. It depends on your business, your threat model.

I don't think so, pdf.js is able to render a pdf content.

Which is different from extracting "text". Text in PDF can be encoded in many ways, in an actual image, in shapes (think, segments, quadratic bezier curves...), or in an XML format (really easy to process).

PDF viewers are able to render text, like a printer would work, processing command to show pixels on the screen at the end.

But often, paragraph, text layout, columns, tables are lost in the process. Even though, you see them, so close yet so far. That is why AI is quite strong at this task.

What about all the designers that used to handle this issue by tweaking their font weights, colors...? Changing a long standing issue with a lot of users will break things for some people (using edge, with an eyes for these details..)

this could be used as an incredible low bitrate codec for some streaming use cases. (video conferencing/podcasts on <3G for ex, just use some keyframes + the audio).

If you understand how LLMs work, you should disregard tests such as:

- How many 'r's are in Strawberry?

- Finding the fourth word of the response

These tests are at odds with the tokenizer and next-word prediction model. They do not accurately represent an LLM's capabilities. It's akin to asking a blind person to identify colors.

here is their Elevator Pitch:

> Minor rant incoming: Something's not working? Maybe a service is down. docker-compose ps. Yep, it's that microservice that's still buggy. No issue, I'll just restart it: docker-compose restart. Okay now let's try again. Oh wait the issue is still there. Hmm. docker-compose ps. Right so the service must have just stopped immediately after starting. I probably would have known that if I was reading the log stream, but there is a lot of clutter in there from other services. I could get the logs for just that one service with docker compose logs --follow myservice but that dies everytime the service dies so I'd need to run that command every time I restart the service. I could alternatively run docker-compose up myservice and in that terminal window if the service is down I could just up it again, but now I've got one service hogging a terminal window even after I no longer care about its logs. I guess when I want to reclaim the terminal realestate I can do ctrl+P,Q, but... wait, that's not working for some reason. Should I use ctrl+C instead? I can't remember if that closes the foreground process or kills the actual service.

What a headache!

Memorising docker commands is hard. Memorising aliases is slightly less hard. Keeping track of your containers across multiple terminal windows is near impossible. What if you had all the information you needed in one terminal window with every common command living one keypress away (and the ability to add custom commands as well). Lazydocker's goal is to make that dream a reality.

yeah, I wonder if there's room for a different networking abstraction that could address most of complex orgs networking issues, I, for sure, don't think that we should still think about cidr range limitations when making networks, for ex.

that said, I'm not sure the tailscale approach scales well in typical modern corporate environments, where you've got a small army of junior devops often overlooking security or cost implications (don't forget about egress costs!).

the traditional, meticulous approach of segmenting networks into VPCs, subnets, etc., with careful planning of auth, firewall rules and routes, helps limit the blast radius of mistakes.

tailscale's networking & security model feels simple and flat, which is great for usability, but it lacks the comforting "defense in depth" that will be asked in most big corps.