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).
The above is a general rule protecting you against supply chain attacks by default. If there is an important CVE published with a patch you can manually review that patch and bypass the minimum-age requirement for that dependency specifically.
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.
You are wrong. Pdf.js can extract text and has all facilities required to render and extract formatting. The latest version can also edit PDF files. It’s basically the same engine as the Firefox PDF viewer. Which also has a document outline, search, linking, print preview, scaling, scripting sandbox… it does not simply „render” a file.
The purpose of my original comment was to simply say: there’s an existing implementation so if you’re building a pdf file viewer/editor, and you need inspiration, have a look. One of the reasons why mozilla is doing this is to be a reference implementation. I’m not sure why people are upset with this. Though, I could have explained it better.
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..)
Web designers must simply accept that they are working in a medium that is not amenable to (sub)pixel-perfect reproducibility. It is not—and never has been—safe to assume that future versions of a given browser will render identically to the current one. It is not safe to assume that the browsers you are fine-tuning for will remain popular in the future. It is not safe to assume that other users with the same browser version (or a browser claiming to be the same version) as you are using will get an identical rendering as you get on your system.
As a web designer, you must accept that the browser is fundamentally not yours to control. It is an agent acting on behalf of the user, not on behalf of you.
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.
Ask a LLM to spell "Strawberry" one character per line. Claude's output, for example:
> Here's "strawberry" spelled out one character per line:
s
t
r
a
w
b
e
r
r
y
Most LLMs can handle that perfectly. Meaning, they can abstract over tokens into individual characters. Yet, most lack the ability to perform that multi-level inference to count individual 'r's.
From this perspective, I think it's the opposite. Something like the strawberry-tests is a good indicator how far the LLM is able to connect individually easy, but not readily interconnected steps.
The funny thing about those "tests" is that LLMs are judged by their ability to do that themselves, as opposed to their ability to write code that does it. The best LLMs still fail at doing the task themselves, because they fundamentally are not designed to do anything except predict tokens. But they absolutely can write code that does it perfectly, and can write code that does so many things better than that.
I'm not going to argue these are good tests, if you asked a coworker these questions they'd look at you weird, but what surprised me is how well you can encode a sentence never written down before, put it through base64 encoding, and then ask an llm to decode it. And the good models can do this surprisingly well.
> 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.
Oh, I see the links now, thanks! But they reference four different licenses, and those are the licenses just for model weights I think?
If the intention was to make something that you can only use with Llama models, stating that clearly in a separate code license file would be better IMO. (Of course, this would also mean that the code still isn’t open source.)
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).
reply