HN user

ethanrutherford

111 karma
Posts0
Comments34
View on HN
No posts found.

This makes me feel physically ill. It's like something straight out of a sci-fi dystopia, how did this get approved? Who determined that reinjecting biological activity into a human brain is definitely not some form of reanimation? If they're using heavy sedation to prevent electrical activity, is that not tacit admission they're not 100% sure that consciousness might return otherwise? How did this pass ethics review, or did they even bother?

The issue with "At the right price", is that your minima (what's enough to filter the spam) and maxima (what are legitimate contributors willing to put up with) can be on the wrong side of each other. The "right price", mathematically, isn't guaranteed to exist.

Everybody is not you

Perfect example of a non-sequitur. Irrespective of whether or not the statement is true, it has no bearing on the veracity of the original claim: that in the current market, the majority of workers simply do not have this leverage.

It's not a communication problem, it's a scale problem. An AI could spit out dozens more massive PRs in less time than it takes you to even evaluate whether or not the current one is AI.

Statistically speaking, most codebases are brownfield. Without joining a startup, working on a greenfield project is actually a pretty rare treat. And deleting code is wonderful. I'd go as far as to say lines removed is more often than not more valuable than lines added; every line that's no longer in the codebase is code you no longer have to understand or care about. So long as functionality remains intact, of course.

The problem, as I see it, with prolific use of AI to generate code is that it goes in the exact opposite direction. More and more code is bolted on top of existing code, more and more edge-cases, patch-ups, workarounds, etc. accumulate, the codebase grows and grows. In the end, no matter how good you are at understanding "code from questionable sources", you're still a human being. The AI can generate new code at rates several orders of magnitude faster than you can injest and understand it, and when your meat brain becomes exhausted, the machine does not tire. From a business perspective, your employer will weigh their options: they can wait for you to interpret the code and generate good code (whether by hand or by machine + human review).. Or they can just keep pulling the lever on the slot machine until it works well enough to sell. And for the business exec just looking for the fastest path to paydirt, I'm afraid the latter option is going to look way more appealing.

That you're only just "learning" that these things are true is a damning admission. And to fix your bad analogy, it's more like "hey maybe we shouldn't be allowing f1 street races through school zones".

I would personally argue that it's a lot easier to say something definitely isn't x, with confidence, than to say it definitely is. I definitely don't know what the surface of jupiter looks like, but I can pretty confidently say it doesn't look like Kansas. I think the better it gets, the easier it will be to spot the shortcomings, because the gap between what it can do well and what it can't will widen. Anything the technology is fundamentally incapable of ever achieving will be made obvious by the fact that it will simply continue to not achieve it. We may not be able to easily define the totality of what exactly it needs to have to count as AGI, but the further it progresses, the easier it will be to point out individual things it's definitely missing.

Maybe you will read it carefully every single time (and to be clear, I doubt even that) but for the majority of users this will only lead to increasing the already excessive amount of decision-fatigue they deal with when interacting with software day to day. People already blindly click through sequences of confirmation boxes when they think they already know what they're doing. Odds are a million to one you've done that very thing before yourself. Adding even more friction is only going to make the average user spam the "next" button even more fervently.

Not exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder".

It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.

It's pretty shortsighted, bordering on intentionally obtuse, to insinuate that the only person that benefits from solving the support problem is the person on support.. Take the example of automatic backups others brought up in this thread. Are you really going to imply that there's zero benefit to the person who didn't lose their data because the app reminded them to turn backups on? I don't disagree that it could be improved with a simple "don't ask me again" style setting, but that doesn't change the fact that every time someone doesn't issue a support ticket, it's because they didn't run into an issue. Any effective solution to a support problem is mutually beneficial for the user as well as the support staff.

No, because the limitation is not money. More money does not magically make the humans in the profession be able to handle higher case-loads, nor magically produce new lawyers and judges. The bottleneck is time that each case takes to be properly and thoroughly adjudicated, and neither "more money" nor "more people" can accelerate that. While it's certainly correct to say that more staff could handle a larger number of cases, a. more staff = more cases, but more money doesn't speed up those cases, so there's still not really anything to be gained in terms of efficiency by increasing individual case costs. And b. if the solution was as simple as "hire more judges", it would have happened already.

Courts aren't lacking in budget to hire more people. They're lacking in people available to hire, with the specific expertise that they need to fill any gaps. The legal profession, at least in the US, consistently has some of the lowest unemployment rates across the board. Unlike over here in the tech sector, the scarcity is in available talent, rather than available jobs.

EFF is leaving X 3 months ago

"what do you mean there's no more sheep in my field? There's hundreds of wolves!"

EFF is leaving X 3 months ago

It's pretty damn simple actually. Their target audience by and large doesn't use twitter anymore, either.

EFF is leaving X 3 months ago

claiming there was rampant "censorship of conservative opinions" is about as honest as claiming that the Romans were being persecuted by first century christians.

By definition, it is exactly a law. It's known as business law. The ToS is a business contract which you must agree to if you wish to use the service. Violating terms of service is literally a breach of contract.

it is neither being delisted, nor was it requested to be. As far as rights holders exercising their rights, this is about the most collaborative way it could have gone. Not every rights holder is a John Carmack.

Counterpoint: these patches are used specifically for slow, controlled absorption of the medication in order to provide symptom relief over long durations. And even then, many drug patches use microneedles to overcome the skin's natural defense against absorption. Only the smallest of molecules can naturally pass through unbroken skin, and the fact that absorption is slow is the primary benefit of medicinal skin patches. They're used for things like hormonal therapeutic treatment or nicotine replacement because for those use cases, the slow, controlled absorption rate is beneficial for long-term relief.

The "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction.

1. You set up an aws bucket with some name (any name whatsoever).

2. You have code that reads and/or writes data to the bucket.

3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.

4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.

5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.

You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.

I'm not sure what would be "pseudo-science" about it, but it is as legit as it can be. Reconstruction of a face from a skull is possible, but the goal is not to create an image that's indistinguishable from a hypothetical photograph of the subject. Rather, the intent is to form a general idea of what people of the time period would have looked like. Facial reconstruction is guided by current understanding of anatomy, musculature, aging processes, etc. Muscles and skin are attached to the skull based on modern human and primate anatomy, so what we get is a plausible representation of what someone with this exact skull shape may have looked like. Like with the dinosaurs, we cannot be 100% certain what the superficial exterior features looked like exactly. But, unlike with the dinosaurs, we know neanderthals are very closely related to modern humans, so we have a much more reasonable base to start from, as we can assume their facial muscles, skin, hair etc. would be similar to humans, but with different proportions. Plenty of real science goes into the process.