beeboobaa3

[flagged]

sure but politely demanding some documents is not the same as raiding an office

A guess that's probably correct: Many torrent sites (where the client can download .torrent files from when given an URL) their infra sucks. This includes expired certificates. Users don't want to deal with that shit. Developers don't want to deal with users complaining. It's not really considered a risk because lots of those torrent sites (used to) just use HTTP to begin with, so who cares, right?

Let me guess, you're in the US along one of the hardcoded routes?

It can, for plugins. GP is talking about extensions which you typically don't need.

I'm using several maven plugins (not extensions) that are defined within the reactor project itself. It works well.

You do need to split your build into multiple projects governed by a reactor but you'll have that anyway as soon as you have more than 1 module. Then you just always build the reactor. Pretty much the same idea as gradle.

My problem with gradle is that its configuration language is a programming language.

Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.

What? I never said being computer illiterate is bad. Plenty of fine people are computer illiterate. And plenty of fine people are fantastic at things I'll never be good at. That's fine.

It allows it's users to actually use their computer as a computer instead of a glorified phone.

MacOS nannies you left and right, preventing you from doing things you want to do because Apple says no.

Windows historically didn't have such restrictions because it's a desktop operating system and not a gimped phone. They're slowly being added, but it takes time to overhaul an entire architecture while maintaining backwards compatibility (which MacOS also doesn't care about at all).

Linux is of course far more "hackable" but there aren't as many computer illiterates using it.

I mean in total it's like 10-30 lines of code put in the place where you load the user session, and a very small rearchitecture of the database.

So... Kind of, yeah.

Each user gets a token associated with them. On each request you first check if they are authenticated via your auth of choice. If so, you take the token associated with this auth from your database. If not, you take the token sent via cookie. If no token is available, you generate one and set it.

Then when a user "signs up" you do the same thing. If they sent a token via cookie, you associate this token with their auth in your database. If they somehow didn't have a token yet they were probably blocking cookies, but you can just generate a new one at that point.

If a user logs in again later while they already had a token you can choose to migrate all data from that token to their login token, so no data that was created prior to login gets lost.

The point is that there's essentially no difference between regular profiles and shadow profiles. Both are just profiles. And a profile can be authenticated with using its token, or using an associated auth provider.

It would be a good first step for you stop being sneaky about this. Very hard to respect you as a moderator when you employ underhanded tactics like sneakily rate limiting accounts and trying to gaslight people into thinking this is an universal limit. I suppose it's a (small) step up from the shadowbanning you used to.

Perhaps change the message to something like: "Your account has been rate limited. For more information email [...]"

And honestly, having people beg via email is just gross power tripping behavior.

> Haven't heard of this happening with later models. Baseband sourcecode firmware is really rare.

You know what they say. "If you have nothing to hide, you have nothing to fear"

So I wonder what they're trying to hide from all of us. Probably all the backdoors and glaring security issues.

The triggering of the limit is automatic, but being subjected to the limit is something the moderators can turn on per account.

If I make a new account it'll be free of the limit until dang gets upset again.

After you've written your comment and when you click reply you get the message:

> You're posting too fast. Please slow down. Thanks.

> (snarky response)

This is what we call "Put up or shut up". It's easy to bash someone for not wanting to spend many hours of their time to work they have no interest in, just because some third party is now demanding it. The change is absolutely arbitrary, also. There used to be no way to grant apps access to specific folders. This is when the app was written. This still works. Google's own apps work that way. But now Google has also implemented additional ways to access the filesystem, and they are demanding people who don't even work for them to rewrite their projects.

It would be understandable if they demanded new apps to adhere to these new policies. But blocking older apps, that were written when there literally wasn't an alternative available, to do a full rewrite or be banned from updating? Absurd.

how are you going to authenticate the user? now you need to solve that if you didn't have a web login before.

---

Guess @dang decided to rate limit my account again so I can't post replies :-)

> Some token that every account gets generated? It's really not that much to ask honestly.

How is the user going to know this token when they visit the website on their laptop? Keep in mind that the Google requirement is that you link to this delete page from the play store, where the user is not authenticated with your app. You can't just generate an URL containing this token.

The point is you can't use the regular filesystem syscalls on android, it has to go through a weird java layer

Since you have such strong opinions on the matter, and experience, why don't you contribute to the SyncThing android app and implement this? Alternatively you could grab your time machine, travel back several years and let them know to anticipate this arbitrary change google would pull in the future.

it's how the cross platform software works and has always worked. demanding a total rewrite just to publish on a single channel is insane, especially since this used to be the ONLY way to do things.

google could always contribute to the open source app to implement the features they wish to see, but instead of using their billions for good they'd rather use it for evil.

It depends on how you're publishing your apps. If you have a registered business which publishes the app then you can use the business address, so a PO box might be viable. You'll need to make sure your business is registered on that address in your national business registry.

Otherwise you are required to give your personal address.

See e.g. https://dev.to/svprdga/privacy-nightmare-as-google-plans-to-... but there are plenty of other sources that match my experience.

Not allowed.

> Technology should develop towards simplifying humanity’s life, not making it more complicated

I agree with this statement for normal people. Not for software developers. You're just begging for stagnation. Your job is literally dealing with computers and making them do neat stuff. When you refuse to do that because "computers should be making my life easier" you should really find another line of employment where you're a consumer of software, not a producer.

The problem is that my coworkers are morons who seem incapable of remembering to run a simple `explain analyze` on their queries. They'd rather just write monstrosities that kindasorta work without giving a single damn about performance.

It seems like computers are getting more capable, but developers are becoming less capable at roughly the same pace.

This has been solved by logical replication a few versions ago.

1. Leave your old database running

2. Start your new database with new version

3. Run logical replication and let it catch up

4. Decide you want to switch over.

5. Using a script: Stop your apps writing to the database (or switch to read only mode), let logical replication catch up one final time, stop logical replication, run a procedure to fix your sequences, and switch your apps over to the new database.

You are now done. Sure, it requires a one-time investment to work out the exact steps needed for your situation, but it's easy to do with minimal downtime.

Of course if you don't care about downtime just shut down your database server, make a backup(!), and then do pg_upgrade.

It just opens/closes the file/edit/view menu.

So is a million years. Not how it works.

nsa is storing everything

No, that doesn't count. Companies have tried arguing that their ads' tracking cookies are strictly necessary otherwise they wouldn't be able to offer their services (ads pay the bills). And yet, they require consent.

Preventing cheaters is similar. And this is blatantly a tracking cookie.

It's clearly a tracking cookie.

> for a limited persistent duration

FTA:

> However, the VGUI browser had no issues saving cookies with expiry dates exceeding 10+ years!

So no, it doesn't even qualify.