Not the same poster, but the first "D" in "DDoS" is why rate-limiting doesn't work - attackers these days usually have a _huge_ (tens of thousands) pool of residential ip4 addresses to work with.
I work on a "pretty large" site (was on the alexa top 10k sites, back when that was a thing), and we see about 1500 requests per second. That's well over 10k concurrent users.
Adding 10k requests per second would almost certainly require a human to respond in some fashion.
Each IP making one request per second is low enough that if we banned IPs which exceeded it, we'd be blocking home users who opened a couple of tabs at once. However, since eg universities / hospitals / big corporations typically use a single egress IP for an entire facility, we actually need the thresholds to be more like 100 requests per second to avoid blocking real users.
10k IP addresses making 100 requests per second (1 million req/s) would overwhelm all but the highest-scale systems.
> I would imagine that such a tool to infer emotional states would be most useful for autistic people who are as I can attest, somewhat handicapped upon that front.
It might well be a useful tool to point at yourself.
It's an entirely inappropriate one to point at someone else. If you can't imagine having someone estimate your emotional state (usually incorrectly), and use that as a basis to disregard your opinion, you've lived a very different life to mine. Don't let them hide behind "the AI agreed with my assessment".
The thing that makes any given arrangement of society work (or not work) is how quickly/cheaply it removes decision-making power from people who demonstrate poor judgement.
This is a difficult task, because people with decision-making power tend use that power to alter the system to solidify their position.
Capitalism, at its finest, does this by letting people make bad decisions with their money until they haven't got any. This was an improvement on, say, holding wars until enough people decision-makers get killed off. However, a variety of long-term policy shifts have meant this no longer appears to happen - merely possessing capital is so profitable that even astonishingly poor decisions cannot reduce your wealth enough to matter.
IMO, through this statement Larry Ellison has demonstrated the kind of poor judgement which a functional society cannot tolerate in a decision-maker, and lacking an effective way to remove this from the decision-maker pool is the primary cause of societal trouble today.
Are you saying that we/some govt org should seize his assets because he had a bad opinion?
Fwiw I agree with you in disliking the “eternal power“ dynamic that seems to come with being rich. I’d prefer to solve this by requiring more disclosure in lobbying efforts, restricting the kinds of donations you can make, etc. Money shouldn’t lead to political power IMO.
> Are you saying that we/some govt org should seize his assets because he had a bad opinion?
I'm saying that a system in which someone with poor judgement manages to accrue his level of assets is broken somewhere.
Policy settings under which "having capital" allows you to grow your wealth while making terrible decisions are bad policy settings.
Various alternative policies exist, the most obvious of which is adjusting taxation settings such that growing your wealth requires consistently making good judgement calls.
I’m not trying to be obtuse, my best guess is that I’m in favor of what you’re proposing. Can you add more details though? I’m certainly in favor of progressive taxation, which kindof matches the spirit of what you’re saying by reducing the profit margin for those who have massive amounts to “play with”. Maybe there’s a more direct method though? Maybe a wealth tax? Something else?
I'm explicitly not claiming any particular proposal is right; my background is not in public policy.
I'm pointing out that across a great many economic nations, times, and economic systems, the core problem of every social system is not the obvious stuff like "how do we allocate resources" - it's "how do we remove bad decision-makers" - because those people are implementing "how we allocate resources".
There's a great many ways to solve this problem, but there's little evidence that _anything_ is currently being tried. I'd support any policy that seemed reasonably likely to improve this situation.
For established software where performance matters, hand-writing the SQL is reasonable.
Hand-writing SQL for, say, a faceted filtering UI is a tedious job that takes most of a day in even fairly simple cases, or about 20 minutes with a decent ORM.
ActiveRecord (and related libraries like ActiveAdmin) are _amazing_ for rapid prototyping - eg if you don't even know whether you're going to end up keeping the faceted search.
> For established software where performance matters, hand-writing the SQL is reasonable.
These things aren’t mutually exclusive though. Every ORM I know gives you an escape hatch to write whatever sql you want. ORMs are great for 90% of things and as a reviewer I don’t need to scrutinize their queries too much. It’s much easier to for me to review an ORM builder query because I know it’s going to do the correct joins on the correct columns. For example in the ORM I use id rather see:
query()
.where()
.eq(“parent”, parent);
Instead of:
“select * from table join parent on parent.id = table.parent_id where parent.id = :parent”
Since you’re not returning anything from `parent`, it makes much more sense to use a semijoin, which is something ORMs usually bury in an obscure section of docs, if they support them at all.
SELECT * FROM `table` t
WHERE EXISTS (
SELECT 1 FROM parent p
WHERE p.id = :parent)
Or, you know, just eliminate the other table entirely (which the optimizer may well do) since p.id = t.parent_id = :parent
You’re completely missing the point while also completely making my point.
The ORM is going to do the correct thing here, while the SQL I quickly typed out will work, but does the inefficient thing and requires more manual review and back and forth in discussions.
I disagree. The point you're making is predicated on not understanding SQL. If you know an ORM well, and don't understand SQL, then of course it will be easier to review. I would however argue that if you don't understand SQL, then you can never truly understand an ORM, in that you can't know what the DB is capable of doing. You'll probably get lucky for things like `WHERE foo IN (...) --> WHERE EXISTS` translations that the DB's optimizer does for you, but you also probably won't even know that's happening, since in this scenario you don't understand SQL.
ORMs typically do an OK job at producing OK queries, in that they're unlikely to be the worst possible option, but are unlikely to be optimal. This is largely driven by schema decisions, which, if you don't understand SQL, are unlikely be optimal. The clunkiest, least-performant queries I've ever dealt with were always rooted in having a poorly-designed schema.
Common table expressions do exist, and they compose ~alright (with the caveats that you're limited to unique names and they're kinda clunky and most ORMs don't play nice with them).
I mean, maybe we would have found another solution to DDOS, but as someone who has had a pretty significant attack (on a service which is a clear public good) mitigated for free… it’s pretty nice being able to keep your services online in a hostile environment.
If I contribute code to a GPL project without signing a CLA, and they later decide to re-license, they cannot use my contributions in the re-licensed version.
The original code up to that point is still GPL though, so they can't lock down your contribution, they are just using it in a closed system. The open system is still available for everyone.
It seems somewhat vacuous to say it when it applies to every second administrative act.
reply