HN user

drdexebtjl

418 karma
Posts0
Comments185
View on HN
No posts found.

Yes. It contains a reference to the image in the source application.

When you paste, X or Wayland lets the source application communicate with the destination application to send the image over.

You’ll likely always have a very simple clipboard manager that stores a single copy of the clipboard so you don’t rely on the source application staying alive.

Clipboard managers are free to store the clipboard anywhere.

What would be in the clipboard after the undo in that scenario?

edit: Yeah, the problem is that the user does not expect undo to do something different depending on what they did on a different program.

Undo doing nothing to the clipboard always is more consistent and the better UX.

hiring at least a couple of DBAs and get more flexibility

Every place I’ve ever worked at that had DBAs had the complete opposite of more flexibility. You have to do things the DBA’s way, and if their way doesn’t work for your service, you need to fight for their time and priority.

Meanwhile every place I worked at where every team completely owned their databases + did periodic data recovery drills had much more flexibility and no data loss.

The problem with Undo reverting the clipboard state is that Undo is usually file or app-local, but the clipboard is shared. You can cut from app A, switch to app B, cut something else from app B, then go back to app A and undo the cut.

“Ghost cut” can work across apps with reasonable undo support by not using the clipboard at all and some form of IPC instead. For example, when you cut from app B before resolving the cut from app A, app A could be notified to cancel its cut.

I think this is much less intuitive than the current convention though.

This might work if we have completely new harnesses for this, because the current one’s intentionally introduce non-reproducible context and tools.

The current way we’re doing SDD is extremely pointless. You reach a decision point that is under specified, make a decision, update the spec and continue the implementation. There’s no guarantee that the implementation followed from the updated spec, and not from the decision.

The problem is that you end up with multiple dialects, just like INI.

For example, I’ve seen booleans being represented with “enable”/“disable”, “yes”/“no”, “t”/“f”, “1”/“0”. Sometimes a mix in the same program.

It’s nice that every TOML config requires “true”/“false” across any application.

The municipal internet in the 1 person per square mile rural area.

Yet that person can receive mail, is within a few miles of a major highway, and is likely connected to or close to the electric grid.

Infrastructure is expensive. LEO Satellite internet is only cheaper because the environmental cost is not being accounted for.

Stop with the false dichotomies. I would rather have no wilderness 90% degraded at all. There are better alternatives than spreading out the farmland. Like better greenhouses that don’t blast grow lights all over the night sky. We have the technology, it’s just cheaper to destroy the environment.

Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all.

These are all just some minor annoyances, some disagreements, and most importantly, a fundamental misunderstanding of the point of command filtering. It is not for security, it’s for steering.

Anyway, it didn’t sound like the author tried building anything with OpenCode, and if they did, they said nothing about the most important part: how well did it do?

These 2008-2010 era netbooks are impossible to use as a desktop. They were already painfully slow when they were new, so much so that OEMs shipped them dual booting a stripped down OS.

I had an HP Mini. It had a weird 1024x600 display panel, and a lot of applications expect you to have at least 1024x768. Sometimes apps would work fine until they opened a modal that was just a bit too tall, and you had to pray that Enter or Escape did something reasonable.

A few years ago I installed Debian, qBittorrent and Samba. I figured it could handle something IO-bound. I ran it for a couple of years and then recycled it when my Internet got faster than the 100 Mbps ethernet card.

A tip if you have one of those laying around and it always ran a 32-bit OS is to check if the CPU is really 32-bit only. Only the very first Atom generation was 32-bit, but the next generations had poor 64-bit driver support on Windows, so OEMs shipped it as a 32-bit machine. Not the case for OP’s netbook, theirs is really 32-bit only.

You can continue to compile as before by using a previous version of the Zig compiler. You even get a 100% byte-for-byte match with reproducible builds.

Why are we so obsessed with updating dependencies, and at the same time, not willing to put in the work to update our own code?

The result of Zig’s approach is that the ecosystem of packages is very active, quickly updating to use the latest language features, and with a good foundation of tests that catch regressions.

I don’t appreciate the holier than thou attitude. These apps and these features are very useful to millions of users. Yes, we’re even paying for it. No, texting “i have pms” every month does not replace it. You’re just out of touch. It’s not for you, and that’s fine.

As the article stated, there are apps that don’t share this data with advertisers, and operate on jurisdictions with strong privacy laws.

We don’t live in a state where we would have no recourse against such privacy violations, and we don’t live in a state where women’s reproductive rights are being threatened by the government.

So we’re using the app.

If your bridge is useful, maybe we’ll buy it.

It just is? I used to get notifications that said something like “$partner is likely to be irritable for the next 2 days”, so I could be extra careful not to piss her off.

No way you can get someone to tell you that unprompted.

Now, of course I would prefer if that data was end-to-end encrypted.

Not really. It’s find and replace work.

If by production-ready you mean you can forever avoid changing code you wrote 8 months ago, sure, pick something else.

To me production-ready means it can be trusted to power production workloads, has all tooling I need, and has a consistent long-term vision. Zig ticks all the boxes.

We want 99% of what we do to be single shard, but occasionally cross-shard work is unavoidable.

Why optimize for the 1% and put the logic in a database proxy, then? It’s a leaky abstraction.

Require the application to explicitly and loudly make a query for each shard and collate the results.

Parent commenter was not asking about when sharding becomes counterproductive, it was asking about when hiding sharding from the application becomes counterproductive.

The point is that it’s a leaky abstraction. It should not be at the database proxy level.

Instead, the application should be responsible to route queries to the correct shard. That way it can’t make cross-shard queries or cross-shard transactions accidentally, it must do so explicitly.

I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about.

To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer).

I also don’t see it being much different from any other language or language runtime that has a major release every year.

It’s fine to update at your own pace.

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes.

Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

What about sequences? The example shows an auto-incrementing user ID. How’s that possible without contention between all shards? Is the proxy responsible for sequences?

What about foreign keys? Do they all have to live on the same shard? How do you do distributed transactions?

On cross-shard reads: how do you do sorting? And cross-shard joins?

I’d love to be proven wrong, but I suspect the 768 servers look like 1 only on the very surface, and you’ll get wildly different characteristics from cross-shard and single-shard queries.

I personally would prefer if they _didn’t_ look like 1 if they can’t behave like 1.