Comment Re: Simple answer: "No." (Score 1) 59
Save that a single human putting in actual effort can't turn out several dozen PRs a day, every day. That throttles the PR volume to a manageable level for the maintainers.
Save that a single human putting in actual effort can't turn out several dozen PRs a day, every day. That throttles the PR volume to a manageable level for the maintainers.
The answer is a simple "No.". Don't allow them. The vast majority will fail to meet reasonable criteria for acceptance, which is enough of a reason to reject them. For the rest, even if they're acceptable in terms of quality, the sheer cost of reviewing every pull request in detail and sorting the minority of acceptable requests from the swamp of slop will itself damage the project, diverting maintainer time away from feature work and fixing bugs, badly enough that it's not worth it. I think this sums it up nicely:
Why should I spend my time reading something you didn't care enough about to spend time writing?
No, they're already training it with its own dogfood. They don't need contractors for that, because they can do that themselves. They're just also paying people to add human data.
People seem to only have memory that goes back two years.
We went to war with Iraq due to faulty intel. No AI was involved at all, at least not in the modern sense of the term. Just a human expert hallucinating a bioweapons lab from a blurry photo.
Russia almost nuked us due to a faulty machine sending a false positive about a nuclear attack. Definitely not AI.
OpenAI's failures prove that the corporations are the only ones that can be trusted!
I'm not sure what you mean when you imply that AI doesn't understand storytelling. It's not *great* at it, but if you formalize the process (outlines, character profiles, world details, external notes, and so on) you can get something coherent if you use a decent AI.
If artificial superintelligence is a thing, we're going to need it to defend against it.
Honestly, I don't see this law passing anyway.
/thread
Perhaps it's time to apply the same methods here that helped deal with spam back in the day: start threatening the ISPs that don't deal with users infected with proxies with having all netblocks belonging to them blocked unconditionally. That works by shifting the complaints from people the ISP doesn't get paid by (the services being scraped) to people it does (it's users who can't access services). We even have the tech needed already: DNS-based RBLs. Condemn providers who host scrapers who don't provide useful user-agent strings or don't comply with robots.txt to the same fate.
We don't need regulations to do this. The services belong to the people who run them, and they've got pretty much free rein to take actions to protect themselves. Is it severe? Yes. Is it disproportionate? Also yes. But then, to avoid it they just have to do one easy thing: not be assholes. If they can't manage that, are we obligated to shoulder the costs of letting them freely be assholes? IMO, no.
They don't. They think of them as something that happens on their computer, with only them involved. They know, in the abstract, that there's a server somewhere, but the implications of that don't really sink in. The same problems applied to e-mail since forever, but everyone dismissed it as something that didn't matter since they didn't use email. Now, though, we're seeing the result of the third-party doctrine starting to hit home in ways the average person does need to care about thanks to the ubiquity of the cloud. Chatbot logs, search histories, email records, Flock cameras, Ring doorbell cameras, ALPRs, documents stored in cloud services, social media histories, messaging service histories... everything involving records stored long-term in the hands of third parties is starting to affect ordinary people in ways they can't ignore. I suspect at some point the law is going to have to change.
I wrote a compiler for an ObjC-like language (with less brackets), which can produce binaries for any of {Mac, Windows, Linux, WASM, Arm A9 (Zynq), m68k or 6502} running on any of {Mac, Windows, Linux}. So you can produce a dev-signed Mac binary on a Linux box. I’m just going through extending that output range to mobile {Android, iOS} and I’ll release it as open source.
The compiler docs for the language (xc) are at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcompile-xc.org%2F - feel free to browse.
I didn’t think getting the signing working for Mac/iOS was terribly hard.
Here's your comment:
I hate Donald Trump, but I agree with this particular decision.
That wasn't hard.
They're still playing the "Try to get IBM to pay us to go away." game. It didn't work the first time around. This one's even more futile because this particular argument was dealt with during the original case and IBM proved that the code they contributed to Linux wasn't code belonging to Project Monterrey at all but completely different code IBM wrote themselves for a different product. But I suppose, given the people behind this, lack of pattern recognition skills is a given.
Didn't Amazon remove the mandatory arbitration clause a while back because too many users were using it, making Amazon have to spend too much money and time on arbitration? Or was that another large Internet vendor?
Legally or morally.
I'm really surprised how many people around here think it does. It doesn't require consent when a human does it, and it doesn't require consent when a computer does it.
Any given program, when running, is obsolete.