dotandgtfo
Joined 8 years ago
Joined 8 years ago
This implies that regulation is codified. The clear pattern of EU digital regulation doomerism is generally pointing at shitty proposals which aren't approved and codified in law.
Digital omnibus is another proposal.
If "rammed and rushed laws" is legitimately a widespread issue, you should be able to find a good example of something codified which is not just a proposal?
I'm not saying we don't have to fight. But vocal opposition to proposals which ultimately don't make it into law is the system working exactly as intended.
Multiple researchers are being told by X that they must pay this fee to get access[1][2][3].
X has recently been fined for not providing this access to researchers. Both for the organic engagement, and for paid advertising. [4]
The pricing of X's API is exorbitant and orders of magnitude higher than arguably higher quality datasets like Reddit. One million posts through the Reddit API costs $2.40.
The pricing scheme is obviously not value based and is clearly designed to limit data access to researchers. As users here note, studying recommender systems requires studying the inputs and outputs of the system. Platforms are rightly not mandated to present the inputs due to privacy concerns. But they are mandated to make the outputs available. And they aren't. "Open sourcing" their algorithm is not a replacement for this, it's an obvious a ploy to present themselves as transparent.
[1] https://arxiv.org/abs/2404.07340
[2] https://devcommunity.x.com/t/academic-twitter-access-is-dead...
[3] https://devcommunity.x.com/t/apply-academic-research-access/...
[4] https://ec.europa.eu/commission/presscorner/detail/en/ip_25_...
They pretend to be transparent about their algorithms while denying researchers access to their API through exorbitant pricing and severely limited quotas.
Not only is the EU miles behind the US, the US is accelerating faster towards more surveillance. Historically PRISM and the US Cloud act. More recently DOGE's recent actions in centralising data and a new crop of private enterprises working on surveillance tech like CCTV facial recognition.
I don't see the federal government applying any breaks on this development. However, I note some states are. But we do see clear attempts from the EU attempt to attempt to curb this. E.g. parts of the AI Act.
While I'm not enjoying the development certain factions are pushing through in the EU either, it is hyperbole to say that the EU is attempting to make a surveillance state, especially in this context.
> The ‘blue checks’ charge is about consumer deception. X changed the rules about how it does verification in a way that allowed impersonation and scams to flourish. [...] As the Commission put it, the DSA “clearly prohibits online platforms from falsely claiming that users have been verified, when no such verification took place.”
> The ‘ads transparency’ charge stems from the DSA’s requirement that platforms must maintain a public archive showing what ads the platform ran, who paid for them, and other information. X fell drastically short of meeting this requirement
> The third thing the EU penalized X for is not giving researchers better access to public data. This enforcement is not about the DSA’s more famous and controversial requirement for platforms to hand over internal data. It’s just about information that was already publicly available on X’s site and app.
It's clear why the tech monopolies want to keep their secrets in the dark. There is a democratic consensus that what they're pulling either is illegal - or should be illegal. E.g. Scam advertisements, overt editorial practices by selective (de)amplification and/or monetization and looking the other way about bots and third-parties leveraging their systems for spreading political propaganda.
Transparency is their enemy. Free speech is their irrelevant but emotion-laden argument. Europeans see straight through it - the questions is, do the Americans?
I think what happened was that I landed on your page. Read the landing page, which only contained code. Scrolled to the top and clicked "install in minutes" and was unexpectedly redirected down the page. Then I clicked into github and didn't click on the forms/tables hyperlinks there.
I think what I'm saying is primarily that I'm lazy.
Secondly, your landing page is too code oriented and does not show off any UI and your anchor link (which typically links into documentation) short-circuited my search for a docs page.
I think you would have gotten considerably more upvotes on this post if you show the product off more on the landing page. Despite the obvious lack of effort I put into learning your product, most people who clicked on this link today did even less.
No shade or anything. Again, the product looks nice now that I've seen it in the docs.
This may be useful for me, but I'm not going to bother setting up a test Django environment to test this just to find out that it isn't what I expected.
> Slicing up your project into apps is something that must be done early, often at the very start of development. This is a simple result of the fact that you need somewhere to put the code you're writing as you go along. In the early days and weeks of work on a new codebase, manage.py startapp gets used a lot, as the high-level structure of the project starts to take shape.
> The issue here is that at this early stage, you often don't really know enough about what the project's final form will look like to correctly draw the boundaries around the apps. Functionality that feels separate at first often becomes deeply entangled, and features that sound similar end up sharing little. Over time, the key concepts and models in your system become clear, and if these are colocated with unrelated or irrelevant code, the waters of the project become muddy and maintenance becomes difficult - before the project is even in production!
> While it is technically possible to migrate models between apps, Django doesn't make it easy, particularly if the models in question have foreign key or many-to-many relationships with other models. And if you think about it, it's not really a technical limitation of the sort that could easily be solved with a PR into Django. It's a conceptual problem: if migrations are a historical record of changes to models, and migrations are encapsulated in the same app as those models, then moving a model to a different app necessarily creates a historical coupling between the two apps that shouldn't really exist.
[0] https://www.django-rapid-architecture.org/structure/