Hacker Newsnew | past | comments | ask | show | jobs | submit | xg15's commentslogin

The result of equivalent deregulation would be slums and shantytowns. But hey, cheap rent! I don't think this is s desirable outcome either.

Also, from the article:

> In other words: you can buy a computer thousands of times more powerful than the best consumer device from 40 years ago, for something like 0.3 percent of the price. No other good in history has experienced a decline in cost on that scale: poor people can now carry around in their pockets computers many orders of magnitude more powerful than what the richest slice of the world’s population could afford a few decades ago.

That extreme level of efficiency increase is something very specific to computers and not something translatable to other areas of the economy.


> Iterators, async functions and async iterators don't work well here because they have different semantics to standard functions. When you call them they return immediately with a generator object, coroutine function and async generator object respectively. So the decorator completes immediately as opposed to the entire lifecycle what it's wrapping.

> This is an unfortunate problem I've encountered many times, and it's often a problem for normal decorators too. But this has changed in 3.15, now the ContextDecorator will check the type of the function it's wrapping and ensure that the decorator covers the entire lifespan.

I very much like the idea of that change - but it also seems kind of dangerous, to do this with no "opt-in mechanism", as that quite subtly changes the behavior of existing usage sites.

This is a bit of a "spacebar heating" situation, because someone would have to intentionally use a decorator in the old, broken way, but if someone actually did that, things may unexpectedly break.


The Python core team seems to think it's unlikely that anyone's relying on the existing behavior: https://github.com/python/cpython/pull/136212#issuecomment-4...

Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.

Eh, what's the worst that could happen? Developers opting to run an old version of Python due to incompatible changes? I can't see that happening.

Context: There appears to be a steady increase of volcanic activity in the Phlegraean Fields, an ancient supervolcano near Naples. This tremor is the latest event in that chain.

See also: https://en.wikipedia.org/wiki/Phlegraean_Fields#Activity_sin...


Is the term "tokenmaxxing" now really used unironically and as a desirable thing?

I don't think so. "sleeper" accounts are a thing. A more sophisticated spammer could create a "high-reputation" account over some time that only posts useful info, then turn up the spam after the trust level is high enough - or even turn the tree system into a business opportunity and sell vouches to other spammers.

I think the deeper problem is: How would legitimate new person with no reputation and no contacts be able to get a foothold at all if there are masses of bots pretending to be exactly such a person?

A system which looks more at the content that is posted (probably using AI) and tries to decide whether it is spam feels fairer to me than effectively pulling up the ladder on new users.


I mean.. Get someone to vouch for you.

If people are distinguishable from bots then you should be able to easily distinguish yourself. If they're not, then you need personal vouching to establish who the people are anyway.


> The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox).

Out of curiosity, does that mean that NaCL (without P) only ran on x86? Or were there different subsets for different architectures?


You could compile NaCL code for x86_64, aarch64, and aarch32 as well. Chrome apps has a system similar to mobile apps where you would upload an app with all binaries and users would get the one for their system architecture.

Ah, that makes sense. So users were effectively cross-compiling the NaCL binaries for multiple architectures.

I think the plan was to JIT x86 to other architectures.

Is that so? The amount of atmosphere stays the same, but we're constantly adding more CO2. So wouldn't this continually reduce the dilution?

the volume of CO2 is negliglible (ppms) and it uses often Oxygen from the air.

Ok, that's one of the pollutants...

But I agree, measuring at the end of the ditch was the wrong thing to do if they take issue with that specific factory (though it was the right thing to do to prove a harmful pollution exists in general)

So another measurement directly at the pipe would be in order.


The measured levels of arsenic, strontium, and vanadium are below the limits for drinking water, even in California. And 4% of drinking water sources in California have higher hexavalent chromium content than the water in that ditch.[1] Besides sodium from salt, the only metal that was particularly high was lithium, at 0.0714mg/L or 71 micrograms per liter. A significant fraction of drinking water in the US has higher concentrations than that.[2]

The level of salt shouldn't affect much. Adding up the chloride and sodium content gets you 684mg/L, which is on the low end of brackish water (500-30,000mg/L). The limit for agricultural irrigation is 2,000mg/L, and photos of the pipe show plenty of grass growing around and in the water.

The phosphorous could come from fertilizers, as there's plenty of farm land in the area. That would also explain the higher ammonium levels, as both anhydrous ammonia and ammonium phosphate are common fertilizers.

The article is really about how sensitive our scientific instruments are, not how dangerous the water is. It reminds me of articles like Vice's American Honey Is Radioactive from Decades of Nuclear Bomb Testing[3], where the most radioactive honey they could find was 10 times less radioactive than a banana.

1. https://www.waterboards.ca.gov/drinking_water/certlic/drinki...

2. https://www.sciencedirect.com/science/article/abs/pii/S00489...

3. https://news.ycombinator.com/item?id=26906838


This seems to be the credo of too much of the tech industry lately.

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

Search: