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

You're stating: "delivers near-V8 speeds"

But according to zoo.js benchmarks that is far from the case:

https://zoo.js.org/

Unless there were major perf gains since 2026-02-10?

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.

It might be a mistake since it's different from what's stated in their readme:

https://github.com/meta-llama/llama-models/blob/main/models/...

(which is referring to the license of Meta Llama 3.2)

there was an announcement on LocalLLaMA: https://www.reddit.com/r/LocalLLaMA/comments/1g38e9s/ichigol...

there were several links:

- Blog for details: https://homebrew.ltd/blog/llama-learns-to-talk

- Code: https://github.com/homebrewltd/ichigo

- Run locally: https://github.com/homebrewltd/ichigo-demo/tree/docker

- Demo on a single 3090: https://ichigo.homebrew.ltd/

> How do I check how many seconds the replica is lagging behind the master?

Use PostgreSQL administrative functions, specifically: pg_last_xact_replay_timestamp. (https://www.postgresql.org/docs/current/functions-admin.html...)

> How would I monitor the replica? A simple cron task that pings a health check if everything is OK (lag is < x) would be a good start.

There are many solutions, highly dependent on your context and the scale of your business. Options range from simple cron jobs with email alerts to more sophisticated setups like ELK/EFK, or managed services such as Datadog.

> How do I failover to the replica if the primary goes down?

> Should I handle failover automatically or manually?

> Do I need two replicas to avoid a split-brain scenario? My head hurts already.

While it may be tempting to automate failover with a tool, I strongly recommend manual failover if your business can tolerate some downtime.

This approach allows you to understand why the primary went down, preventing the same issue from affecting the replica. It's often not trivial to restore the primary or convert it to a replica. YOU become the concensus algorithm, the observer, deciding which instance become the primary.

Two scenarios to avoid:

* Falling back to a replica only for it to fail (e.g., due to a full disk).

* Successfully switching over so transparently that you will not notice that you're now running without a replica.

> After a failover (whether automatic or manual), how do I reconfigure the primary to be the primary again, and the replica to be the replica?

It's easier to switch roles and configure the former primary as the new replica. It will then automatically synchronize with the current primary.

You might also want to use the replica for:

* Some read-only queries. However, for long-running queries, you will need to configure the replication delay to avoid timeouts.

* Backups or point-in-time recovery.

If you manage yourself a database, I strongly recommand to gain confidence first in your backups and your ability to restore them quickly. Then you can play with replication, they are tons of little settings to configure (async for perf, large enough wall size to restore quickly, ...).

It's not that hard, but you want to have the confidence and the procedure written down before you have to do it in a production incident.

Try Go. Go is really stable as a language and have a very small core feature set.

Some points resonate with me:

> People don't want "to have to play Chess against the compiler"

Things that are easy to express in other languages become very hard in Rust due to the languages constraints on ownership, async...

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.

It's indeed hard to keep up.

> Async is highly problematic.

Yes, more complexity, more fragmentation and feel like another language.

But one point feels unfair:

> the excellent tooling and dev team for Rust [..] pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in.

What? No. The main appeal was the safety. It's still a distinctive feature of Rust. To almost eliminate a whole class of safety issues. It has been proven by several lengthy reports such as https://security.googleblog.com/2024/09/eliminating-memory-s....

They are many projects for which the reliability and efficiency are worth the trouble.

As mentioned in the article, it's a good idea to consider this when creating a new table, since it's essentially a free optimization. However, it's probably not worth the hassle of reordering a production table for that.

> Disk is cheap, memory is plentiful, but your time is expensive, etc.

One thing to keep in mind, though, is that while you often have plenty of disk space, RAM is still relatively expensive. It's also divided into many smaller buffers, such as working memory and shared buffers, which are not that large. These optimizations help to fit more data into cache.

However, what the article said about alignment being important for indexes is somewhat misleading. Reordering an index field is not the same as reordering columns in a table. Beside having to rewrite queries, it also changes the access pattern and the time required to access the data, which is often much more significant than the space saved. Indexes are, by nature, a tradeoff where you give up space to gain time, so this mindset doesn't really apply there.

It's pretty misleading not to mention the performance overhead. That's an obvious downside and quite easy to benchmark. Skipping any discussion of performance feels like sweeping it under the marketing rug :/

well it's human nature to struggle with collective action when the risks are unclear, vague and not shared. stakeholders are juggling immediate, tangible concerns, like climate change, economic stability, and political issues, making it tough to justify moving AI up the priority list.

I would be interested in a computer science only version.

A quick search didn't bring up an already existing one :(

There is also the function scope vs block scope...

var x = 3 will escape the latter.

I think that you have made the right decision.

One of the most common and high-impact failure mode is crashing when parsing a leap second that is represented as "23:59:60".

Jiff is able to parse leap seconds, and beyond that, I doubt that there are many scenarios where you care about leap seconds but not enough to use a library that supports them.

This a pipeline for text to 3D.

But it's using for 3D gen, a model that is more flexible:

https://assetgen.github.io/

It can be conditioned on text or image.

the interesting comparison nowadays would be against mojo:

https://www.modular.com/max/mojo

I think that an easy-to-implement and reasonably performant garbage collector (GC) would combine two approaches:

- Let the compiler automatically free variables that go out of scope (using static analysis to insert free calls).

- Use reference counting when the scope is too hard to determine (fall back on a dynamic check).

They say that Rust is not enough and dismiss it quickly:

> V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.

But looking at the awesome list they provided:

https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtu...

There are a lot of use-after-frees and out-of-bounds accesses, buffer overflow in there...

Postgres is far from perfect:

- The codebase is old and huge, accruing some heavy technical debt, making it a less than ideal foundation for iterating quickly on a new paradigm like AI and vector databases.

- Some ancient design decisions have aged poorly, such as its one connection per process model, which is not as efficient as distributing async tasks over thread pools. If not mitigated through an external connection pooler you can easily have real production issues.

- Certain common use cases suffer from poor performance; for example, write amplification is a known issue. Many junior developers mistakenly believe they can simply update a timestamp or increment a field on a main table with numerous columns.

So, yes, PG is one of the best compromises available on the database market today. It's robust, offers good enough performance, and is feature-rich. However, I don't believe it can become the ONE database for all purposes.

Using a dedicated tool best suited for a specific use case still has its place; SQLite and DuckDB, for instance, are very different solutions with interesting trade-offs.