pythonaut_16

This is actually one of the huge tradeoffs and pitfalls of LiveView. Its websocket model is all or nothing.

For example I have a small side project using LiveView where users would typically pull their phone out, quickly record data, then put it away again. But due LiveView only working with a connected websocket they often have to wait ~1s for the socket to reconnect, and get an annoying error message while it does.

I'm sure there's more I could do to configure this but the default at least is terrible. I believe with Hotwire I wouldn't have this problem, my view would just work and then restore the websocket when it can.

I use Phoenix and LiveView for a lot but I wish we could get more of these rough edges polished up.

Does Tangled offer any solutions or suggestions for backing up data stored on the Knots?

From what I've seen merino tends to be more delicate than synthetics, but much more odor resistant.

Merino is the only fabric I've found that can handle multiple sweaty days or even workouts without a hint of smell.

Technically it does make you irrelevant to statistics about child rearing outcomes.

Curious to hear why you think tiling window managers aren't practical.

Hyprland is like half the point of Omarchy (the other half being Arch)

Do you need to redeploy your service without downtime? Do you need multi-user and remote access?

Why can't you just use a copy of the database when you need to examine it or resolve issues?

None of these things have anything to do with being a "toy" app or not. They are matters of scale and business requirements. But that's the point isn't it? There are plenty of non-toy systems where none of these requirements apply.

Plenty of very successful business and applications could handle a brief downtime for deployment. Plenty don't need multiple users or remote access, plenty have reasonably small databases.

Do you actually need all those things?

The simple answer to your question is you don’t. And if you do need them you don’t use SQLite.

Basic survival advice is to stay put and wait for rescue unless you're in imminent danger. So maybe if your watch is your only lifeline stop running around the mountains once it dies.

Or use something intended for the purpose like a Garmin inReach. The satellite SOS features on phones and watches are nice to haves that could absolutely save your life but they're no replacement for being prepared. Really no device is a replacement for being properly prepared in the wilderness, even with your location you still need a way for rescue teams to spot you, for example.

Great so they can give you an option to kill all charges except basic storage. Or let you reserve part of your budget for storage. Or let you choose to have everything hard deleted.

Surely these billion and trillion dollar companies can figure out something so basic.

Mozilla's been doing a pretty good job destroying Firefox all by themselves

It’s more honesty that you see from most service providers, both dogfooding the approach and not handwaving the costs.

Seems a bit reductive when the post is literally him pushing Arch Linux and he's also been hyping Framework and talking about his Apple departure for quite a while now.

But also for GP, there's literally an "About DHH" section at the bottom of the pretty short post you're commenting on.

"Even if it never reaches orbit reliably"

How is that a greater achievement than Falcon 9 and reusable boosters, especially Falcon Heavy? Like sure if Starship lives up to its goals it will be a greater achievement. But how would an ambitious project that fails its most fundamental task (reaching orbit reliably) be a greater achievement than one that actually does meet its goals and was (and is) still incredibly revoluationary?

It seems you're thinking of the "full cost of the engine" as like material + labor to produce 1 engine. So profit vs loss is equivalent to whether you pay more or less than the unit cost of 1 engine.

Car manufacturer thinks of the cost of the engine as something like research + development + testing + sourcing + manufacturing lines + materials for all engines produced + labor for all engines produced. So for the manufacturer profits are total revenue of units sold minus total costs. To maximize profits they need to identify market segments and figure out the best way to sell into them, in some cases by selling one physical model at different price points.

If a manufacturer only targeted your market segment with a model you wouldn't get a cheaper car, you'd most likely get roughly the same car for the same price. (Ignoring design/feature compromises made to try to address one model to multiple market segments)

Not that I agree with VW or holding features behind a subscription. Just that we can understand the unit economics of why. And anyway subscriptions for hardware features are a different matter entirely.

Go links are a specific subset of short links with a slightly different purpose than services like goo.gl.

And more organizations should adopt them because they are great.

QR Codes is the main case I've looked at where the shorter link makes a difference in the complexity (and therefore scannability) of the generated code.

But otherwise I think it's about traffic and tracking.

First in that you can track visitors to the short link, perhaps in a more centralized place if your org has multiple systems or if you're linking to sites you don't otherwise control. And secondly it's used when tacking on tons of query parameters that would otherwise make it too long even with expanded character limits. And just aesthetically a short link might be more aesthetic in your post.

Imagine seeing "link.short/abcd1234" vs "linksrus.corporate/blog/2025/08/12/the-title-of-our-post.html?utm=something&some-other-tracking-param=abcdefghijklmnopqrstuvwxyz&even-more-data-in-the-url&some-hashed-value=QXNoIG5hemcgZHVyYmF0dWzDu2ssCiAgIGFzaCBuYXpnIGdpbWJhdHVsLApBc2ggbmF6ZyB0aHJha2F0dWzDu2sKICAgYWdoIGJ1cnp1bS1pc2hpIGtyaW1wYXR1bAoKT25lIHJpbmcgdG8gcnVsZSB0aGVtIGFsbCwKICAgb25lIHJpbmcgdG8gZmluZCB0aGVtLApPbmUgcmluZyB0byBicmluZyB0aGVtIGFsbAogICBhbmQgaW4gdGhlIGRhcmtuZXNzIGJpbmQgdGhlbS4KCg"

Alternatively MIT does exactly what it says it does. It's up to you as an author whether you like those terms or if you'd prefer GPL, AGPL, or SSPL.

If you want a permissive license MIT is perfectly reasonable. If you want more restrictions or stronger copy-left then don't pick MIT.

Yes, they should definitely Goodhardt the Pelican Test so we can... just have to invent a new test?

Can you explain a bit of the workflow you expect for offline support?

Like would I have one set of LiveViews that run on device and a database wrapper that handles online vs offline queries? Do you envision all view code running on device then?

Either way, super cool to see!

On the other hand, this is helpful to know as a user of LLMs because it suggests that LLMs are bad at isolating the math problem from the cat fact. That means providing irrelevant context may be harmful to getting back a good answer in other domains as well.

Ideally you'd want the LLM to solve the math problem correctly and then comment on the cat fact or ask why it was included.

In many places though it's more like most of the stadium is made up of various levels VIP booths. So one of the options is to replace those VIP booths with more dense traditional stadium seating. Only it's not enough to convince the ticket holders of one VIP booth to sell their tickets so more dense options can be sold, for some reason all of the VIP booths around that one also have to agree, and they're not so excited that plebeians might get to sit in dense seats right next to their pristine VIP booth to watch the show.

Someone else mentioned it already, but what is there to talk about with SQL Server (and Oracle)? Like I'm sure there's plenty someone could write about but generally it's pay Microsoft so it's their problem.

Whereas something like Postgres has a plethora of forks and tools built around it, because it's open source devs can actually do interesting things to solve their problems.

Does Asahi actually maintain the Macbook's performance and battery advantage when running Linux though?

I have one as a developer laptop running Linux. It works fine, battery life is bad. (On AMD 7640U Framework 13).

I currently couldn't recommend them to anyone except users (developers?) who want to run Linux specifically. Otherwise a Macbook is going to be a much better computer at a better value, or just get any boring Windows laptop provider.

Pros compared to Macbook: - Runs Linux - amd64 makes some legacy software work easier - Easy and commodity prices to get 96gb of RAM and 2tb SSD.

Macbook pros: - Massively better battery life - Snappier/faster in general usage - Much more polished than Linux

I evaluated Thinkpads as well but trying to find one with the right configuration that wasn't too expensive or worse than the Framework was pretty hard.

I'm pro public transit and trains, but the stat has more shock value than actual logic.

What's feasible for a theme park doesn't necessarily extrapolate to public transit.

Expanding for the original question:

Roughly speaking, Postgres is to SQLite what Clickhouse is to DuckDB.

OLTP -> Online Transaction Processing. Postgres and traditional RDBMS. Mainly focused on transactions and addressing specific rows. Queries like "show me all orders for customer X".

OLAP -> Online Analytical Processing. Clickhouse and other columnar oriented. For analytical and calculation queries, like "show me the total value of all orders in March 2024". OLTP database typically store data by column rather than row, and usually have optimizations for storage space and query speed based on that. As a tradeoff they're typically slower for OLTP type queries. Often you'd bring in an OLAP db like Clickhouse when you have a huge volume of data and your OLTP database is struggling to keep up.

Why would GCP Cloud Tasks be part of the default libraries? If it’s that simple surely a community maintained gem would be fine?

Having both available is a huge win for the Rails ecosystem.

If you’re just starting or have a small project Solid Queue is invaluable and reduces costs and friction.

If and when you need more performance or power Sidekiq is still available. Both run in the context of your Rails app so moving jobs from one to the other shouldn’t be terribly hard.

Come on really?

Do you write perfect commit messages every single time on every project you work on?

Specialization of AI models is cool. Just like some people might be better planners and some are better at raw coding ability.