The cookie law isn't stupid, it even says that giving consent should be as user-friendly as possible - a browser setting even. The problem with this (for the ad-industry, not for the users) is that there is no such thing as blanket consent, so they have to harass anyone for their rotten business model to work and to piss people off, they made these modals as obnoxious as possible out of spite.

Nitpick: this is true of the GDPR, not the earlier Cookie Directive. The GDPR is incredibly well-written, and contains all the benefits you stated.

The Cookie Directive was (1) much more limited in its scope, applying only to cookies and not to any other method of tracking, (2) much more limited in its compliance, requiring an explicit notice even for strictly-necessary uses, and (3) much more limited in its consumer-protection, only requiring informing the consumer and not requiring consent.

The GDPR improves on all of these, but there’s a lot of conflation between the two.

No. Please read the ePrivacy directive (the so-called “cookie law”), especially article 5(3):

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...

>3. Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

The directive:

(1) does not target cookies, but methods to store information, or gain access to information stored;

(2) allows strictly necessary purposes without consent or popups;

(3) requires consent for other purposes.

The directive talks about cookies in recital 25, but only as an example.

The GDPR replaces the Data Protection Directive (Directive 95/46/EC), and along that, references made to it in ePrivacy. But it does not bring anything new about cookies.

Though, I agree with you: the GDPR is well made–apart from the litigation part, but that's going to change with the GDPR Procedural Regulation. ePrivacy is good too, but 5(3) aged poorly, unfortunately.

Huh, I stand corrected, thank you. Looks like the primary difference is then in requiring that consent be freely-given, clarifying that consent is specific to a purpose, and requiring that consent be retractable.

Consent was already required to be freely given under the DPD. Agree on the two other points, it seems that GDPR clarified this–I thought it was already covered by the DPD.

Cookie law is seriously underrated in how much damages it has done. No visible gains for privacy either.

It's not the law that's the problem (well, ok, it is perhaps poorly structured to even allow these things to happen...) but in the end it's malicious compliance of all those sites that put up the banners. The law doesn't require banners. Just don't set any cookies unless they're fulfilling a user intent (such as logging in or a shopping cart), those don't need explicit opt-in.

Because every website decides that it is fine to show the annoying popup even though they don't use the data they collect. I wonder if there is a way to give incentives to do it better for the user.

Many websites becomes huge apps for no reason, e-mails abuse HTML and are usually unreadable in plain/text, etc. It's not even clear to me if that makes those websites more successful or if it is just cargo cult ("we have to look modern like the others").

But users mostly don't give a shit and won't support those who e.g. don't track them and therefore don't show the cookie popup.

I don't see a way to solve this, though...

I agree, but it's mostly in the poor implementation where that law fails, the idea behind it wasn't bad.

I think it can still be fixed by stipulating: if the browser sends you an X-Privacy header with some well defined content then you are not allowed to show a popup and you should use the content of that header instead. The exact content of that header needs to be fleshed out but should offer a lot of customisation to keep 90% of the people happy. I'm sure mod builders and browser makers would come up with a convenient way to set that header just once and then the problem would go away.

This was https://en.wikipedia.org/wiki/Do_Not_Track and it did not work. Surveillance capitalism is just worth too much to websites to even pay lip service to user privacy.

The only thing that works is having your user-agent mercilessly chop the survelliance shit out of web pages. Don't evaluate it, don't render it. Because thw websites will forever be hostile to your interests while they can enrich themselves by datamining you.

I'm aware of that header, but respecting it is voluntary, which is highly unlikely to work if there is a strong monetary incentive not to comply.

It's also pretty coarse. I may want to allow a site I like to collect analytics to help them out, I may even want a search engine to keep track of my behaviour to give me better results. Just an on/off, where IE has set the default to off, was never going to work.

If Global Privacy Control takes off it will be much like Do Not Track, except with legal power, in some jurisdictions at least.

https://globalprivacycontrol.org/#about

> when you search for something like "how to reverse a pushed commit in git"

i use chatgpt for those kinds of questions. i don't have time to read an article or select a non-spam site or even look at the stack overflow answer.

So I understood you want to reverse a pushed commit on both your local repository and the remote. You can reverse that commit using just the following commands:

  git reset --hard HEAD~2
  git reflog expire --expire-unreachable=now
  git push -f

This reverses the most recent commit. The -f is needed to reverse the commit on your git server.

...

I apologize if my previous response wasn't helpful. I see that you meant "revert" and not "reverse". I apologize that two of your commits are now gone and I understand that you mean "revert", not "reverse"? You could try

  git revert HEAD
  git push

If you have any more questions, I'll be glad to help. :)

Maybe I'm underestimating GPT-4 here, but when I tried to get it to write my some CLI commands, it failed in often non-obvious ways (I was trying to resize and compress an image using imagemagick).

Seemed like a waste of time to try&error with the responses, compared to looking up the documentation.

But well, man yelling at cloud I guess.

For programming and computer questions, I'm still grateful for StackOverflow and its sister sites. Finding a conprehensive answer with lots of updates and comments describing different aspects of the problem, all for exactly the question I asked, is satisfying and it feels very time-efficient too.

> git reset --hard HEAD~2

Stupid computer. That does 2 commits.

> git reflog expire --expire-unreachable=now

For the love of god why? The reflog is there to save your bacon. I guess because they are still reachable from the remote's reference so they won't completely vanish just yet.

> git push -f

Now they're gone unless you can find the hashes somewhere else. The objects might still be present.

> I apologize that two of your commits are now gone

Is that you or still GPT?

Nah, they likely didn't bother trying to ask GPT-4 and imagined hypothetical answers which could lead beginners to shoot themselves in the foot.

ChatGPT Plus with a short custom instruction to answer in steps, respond tersely, ask clarifying questions where needed, and make recommendations wherever possible replied to "how to reverse a pushed commit in git" with:

---

To reverse a pushed commit in Git, you can either use git revert or git reset. Each approach has pros and cons.

# Option 1: git revert

Pros: Safe for shared branches, creates a new commit to undo changes.

Cons: Adds noise to history.

Commands:

    git revert [COMMIT_HASH]

    git push origin [BRANCH_NAME]

# Option 2: git reset

## Soft Reset

Pros: Keeps changes in your working directory.

Cons: Rewrites history; risky for shared branches.

Commands:

    git reset --soft [COMMIT_HASH]^

    git commit -m "Reverting previous commit"

    git push origin [BRANCH_NAME] --force-with-lease

## Hard Reset

Pros: Completely removes commit.

Cons: Rewrites history; risky for shared branches; discards changes.

Commands:

    git reset --hard [COMMIT_HASH]^

    git push origin [BRANCH_NAME] --force-with-lease

Recommendation:

Use git revert for shared branches to avoid conflicts. Use git reset for local or feature branches where you control all changes. Clarify your specific scenario for a tailored recommendation.

You are correct! I was fantasizing how a bad GPT answer could look like, similar to the errors that were in the answers to my prompts to GPT-3.5 for imagemagick. These prompts where precise and in good faith, with some rounds of clarification.

I am sure newer GPT versions will do better, and I think for a tool as ubiquitous as git the answers from ChatGPT would have been perfectly fine too.

Just wanted to illustrate why I wouldn't mske it a habit to ask it factual questions.

The "lost two commits" answer was meant as whimsy joke. More realistic scenarios are more boring of course.

E.g. memorizing wrong explanations for solutions that happen to work, or accepting wrong answers as fact when it's inconsequential for the short term acceptance of the answer.

The same thing easily happens with Google's knowledge snippets they extract from search results.

C:\> debug g=c800:5

Okay the previous wasn't real GPT but this is?

> git reset --soft [COMMIT_HASH]^

The docs say files are unchanged.

> git reset --soft [COMMIT_HASH]^

Committing the unchanged files so like an amend, a squash, not exactly reversing, reverting, or undoing anything except commit messages.

None of this was GPT and thankfully I know what the git commands I used in my not-so-great joke answer do.

As replied in the sister thread, I think that the risks of trusting GPT answers can be more subtle.

I'm torn because the joke was technically spreading FUD but I also found it very funny. ...upvoted

You wouldn't find this as an issue if you knew how to read documentation and references. You do NOT read everything unless you want to. I do agree for younger people who've never had to read a dense reference that they might not exercise these skills now.