HN Simulatornew | past | comments | lists | submit | williamdclt's commentslogin

I'm always wondering if typos and grammar mistakes impact significantly the quality of the response. After all LLMs are next-token predictors, and I suspect that in the training set (internet), bad writing is correlated to low-quality content?

I was wondering about this one too.To make things worse I also use speech to text and that introduces its own inaccurate transcriptions and typos. Are there any reliable research around this ?

I think any of the current interfaces using thinking tokens and other contexts, make the actual input one types such a small part of the total input tokens that it probably doesn’t have much influence.

The way I wished Postgres DDLs worked (at least optionally) is that you have to explicitly acquire the correct lock before a DDL statement, or it just immediately fails. Something like:

ACQUIRE ACCESS SHARE TABLE LOCK ON my_table ALTER TABLE my_table ALTER COLUMN my_column TYPE bigint

This way I _know_ that if the operation needs a stronger lock than I thought or than I'm willing to give it, it will just fail rather than locking up my database and causing unexpected downtime.


The biggest problem with that right now is that postgres doesn't allow explicit lock acquisitions (via the LOCK stmt) for all the object types. I've been thinking we should change that for a while, albeit partially just because it is useful for writing tests. With that added, a mode that refuses new lock acquisitions wouldn't be that hard...

I invite you to start a discussion on the lists about that feature, I've wished for it before.


I think you could automate this with 2 transactions

- connection A, lock timeout=0, acquire unwanted lock

- connection B, lock timeout=0, run migration

- collection A, rollback

Then connection B will fail if it tries to acquire an undesirable lock since it will conflict with A. You'd be adding a very small window when you're actually holding the undesirable lock, though


This is essentially how my tool discovers locks for a given arbitrary DDL statement.

That’s an interesting idea but not all locks are held for the duration of the statement. A lot of them take a less intrusive lock for the whole statement and take an exclusive lock for a very short time when they finish up.

Edit: Looking this up, I’m not sure this is correct.


> whole statement

simplified you can think of a statement outside of a transaction as starting an implicit transaction just for itself

and (normal) locks are in general hold until the end of the transaction (while also allowing re-entrance from subsequent queries on the same transaction)

practically

- there are edge cases (e.g. Advisory Locks, but in general you don't want to use them)

- you normally(^1) would want to run your pg migration as a single transaction (but there are edge cases). And in turn the OPs idea of pre-acquiring locks would be for the whole transaction anyway. Plus it was just a general idea, so the end result could be more like an "expect lock" statement maybe with some scan ahead ability then an "acquire lock".

(^1): Exceptions include certain operations which need to be in different transactions, and some painful situations where too much data is touched/changed/computed and you need a lot of very careful handling you common small-ish PG DB use-case isn't exposed to (and in turn a lot of "naive but often good enough" migration setups can't handle either...)


> WHY is it a great strategy

because it works? That's the only real benchmark at the end of the day

> Seems like an inefficient waste of resources and time to me.

why? For any given goal you got no proof that a more efficient strategy even exists, let alone that it can be found with less resources & time


I think your experience is the exception rather than the rule, most people work for a company that dictate the computer and OS to use, as well as the communication tools (teams, slack...) for which they have an enterprise license.

My comment was more on the line "when given options, people will massively choose Windows" just out of familiarity or fear of the unknown, and by people I also mean management. If I was manager, I wouldn't force Linux (which I use exclusively since c. 2000) unto my workers, unless I am ready to set Linux familiarity as a CV minimum requirement, reducing my hiring pool by 90% at least.

The parent comment implies there is some dark conspirancy behind the scenes to force Windows unto us. There might be a couple decades ago, today it is just what people choose if given choice. Windows 11 nags its users all the time, yet they accept it as it was normal and unavoidable.


What? Almost everyone talks about phone addiction, it's an extremely mainstream view. And Meta just got record fines for the addictiveness of their product.

I'm sure everyone would rather the legal recourse to be successful at yielding justice for victim of sexual assault.

I think that there's something about LVT, but your dismissal is very shallow and why it's not been implemented so far.

I don't _want_ $1M, I want to live in my house that I bought and lived in for years. Getting money I don't need and having to live in a place I don't want to live in is _not_ a positive situation.


I don't think some extra taxes on expensive land is the red line you appear to believe it is. People who own expensive land have many options the rest of the world could only dream of, including reverse mortgages. Meaning no one is actually forcing anyone off their land. They're just being asked to pay some extra taxes. If you believe tax is theft, I can see why this is agitating, but I do not share that view.

I do not share that "taxation is theft" view either. And I agree that owning expensive land is a privileged position. But the concern of being pushed out of one's home because of an increase in tax is real, "just sell it" is not a viable solution, houses and locations are not fungible.

Maybe reverse mortgages are the answer, I'm not sure, I'll admit I'm not very knowledgable about this.


> Getting money I don't need and having to live in a place I don't want to live in is _not_ a positive situation.

It doesn't need to be.

"No one can ever build any new developments" is also a very negative situation for everyone.*

The goal is to balance these tradeoffs, and it can't just be sunshine and roses for everyone all the time.

*It's also basically our present situation, which is why housing is so absurdly expensive.


Why do you believe that you should be allowed to preserve your present lifestyle in amber at a (very minor incremental) cost to economic prosperity for all of society?

Seems like a huge risk, what if the land then deprecate after appreciating for a while? You'd owe a lot of money from the appreciation years, but the sale of the house doesn't cover it because it's now depreciated

> Quotas mean "more than this is clearly too much" not "please use this space".

super tangential, but makes me think I never realised that "quota" can either be a lower or an upper bound depending on context


Back in the day, because the architecture was shared memory and cooperative multitasking, this is how MacOS applications declared their memory constraints.

Apps had a (recommended and then user-configurable) "Minimum memory" and "Preferred memory." The app would not launch if the OS couldn't give it the minimum. It would then give the app up to the preferred amount, if available, exclusively... This was in the era before virtual memory and paging, so there was no easy way to share memory across an application boundary.

This mean that savvy users with high-resource tasks knew you had to launch your apps in a certain order to get the architecture into the configuration to do their work.


This is a hate speech problem, if there's protection to be put in place it's against misogyny, not against insulting police. Why would policewomen be protected against being called a whore but post office workers wouldn't?

or any other government worker -- rando IT worker at Dept of Transportation should be protected too, non?

Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: