loeg

Lmao.

Again, deposits are capped well below the damage a pet can cause. And recovery post facto is impossible.

No, that was already separately prohibited (capped extremely low). Lol.

Seattle severely caps deposits; this isn't even close to adequate.

Yes, we'll see an exodus of small landlords and see much higher monthly rents passed on to all tenants just to subsidize the ones that cause damage. This isn't better for most tenants.

Seattle severely caps deposits, too.

Banning junk fees / truth in advertising is good. But I absolutely hate that pet rent was bundled in to this. Pets occasionally cause very high amounts of real damage that should be covered by pet owners, not tenants without pets. And Seattle has banned every other possible avenue of passing this expense only to the parties responsible (higher deposits).

How successful do you think landlords are at recovering damage costs from former tenants that aren't covered by the deposit?

It does not. Total deposit is capped at a single month's rent.

Kids do less damage and there's a stronger argument for subsidizing them than dogs.

Pet rent isn't about directly covering damage; it's more like buying an insurance policy that occasionally covers large pet-necessitated repairs.

It's wild that you think good people can't support enforcing laws.

It is also reasonable for employees to hold the position that Flock is a public good and the vocal minority of people complaining about it are simply wrong.

Yeah. Some of it may just be "thinking" less rather than faster token generation.

Yeah but Starcraft needs, like, 10-20x the APM these agents are doing.

There's a bot data stream already; it's probably hooked up to that rather than screencap. Yes, I believe these were playing in real time.

I guess I'm not really interested in Kim Jong Un's opinion.

What is md-raid10 doing that is so much worse than lvm-raid10? In terms of "I/O" and "responsiveness." It's not really obvious to me from either the linked page or https://github.com/fenio/modern-fs-benchmark . In principle they should be similar?

That nuclear devices offer some benefit to the hereditary dictators of oppressed, impoverished North Korea does not actually make them "pro-social."

Fair enough.

Ah, cool.

> and can be burned in the same power plants

I don't believe nat gas is burned in the same plants as coal.

This is some rhetorical thing people say, but you don't actually believe it, right? You're not that wildly delusional? You think that if the air is 4C warmer, we won't have laws, people, culture, or whatever else makes a civilization? And that in the mean time, people being able to heat their homes in winter and not freeze to death, and otherwise afford electricity, are not offsetting pro-social benefits?

This blog post and also comment section are a tire fire of misunderstanding. Passkeys solve a couple crucial problems 99.99% of users face, including smart, technical ones who use password managers. They have great ergonomics. They do not obviate having some kind of recovery flow and are not intended to.

It's got "JE" in the name.

Don't you just take the current cpuid when you go to access the cache again? Then you mutex and access the per-cpu state. There is a tiny race window but 99.99% of the time you will be hitting the same cpu's cache as you just identified, and there will be ~zero contention.

The main issue is thread preemption while you're holding a per-core cache mutex. Some other thread can't do meaningful work using the cache while the holder is sleeping.

It's simple, really. Fracking has offsetting pro-social benefits in a way that NK possessing nuclear weapons does not.

Yeah. I would call ll/sc atomic. Wikipedia's current verbiage:

> Load-link returns the current value of a memory location, while a subsequent store-conditional to the same memory location will store a new value only if no updates have occurred to that location since the load-link. Together, this implements a lock-free, atomic, read–modify–write operation.

https://en.wikipedia.org/wiki/Load-link/store-conditional

> unless it has enough other things to do to to keep every core busy.

And in this all-cores-busy case, do you want your waiters burning one of those precious cores while lock holders are preempted? If you care enough about your system design to even affirmatively select spinlocks in the first place, you should probably also care enough to not use them in preemptible userspace. Or at least, I am not aware of any reasonable usecase. Hybrid sleeplocks are fine, of course.

Kernel can prevent preemption (mostly). Userspace can not (mostly).

ARMv8-A has atomic CAS, unless this is some silly definition thing where it's "a system that has the behavior of atomic CAS but is named something else."