MaxGanzII

In my experience, all the major platforms eventually close all accounts.

> it’s just bad UX

"Bad" I would say means you can still achieve your task.

I was presented with over sixty download links, and not being an idiot or someone to be taken for a ride, I refused to go along with it, and that means the UI is not bad but failed.

What's more, it OBVIOUSLY failed.

There's no way a single person at Amazon could have genuinely sat there and thought, "yes, this, THIS is it, THIS is the right way to make this page", not, that is, if their goal was the user actually getting hold of their data.

Exactly the problem I had.

It would take Amazon almost no effort to make a single archive with all those files in.

I cannot help but view this as deliberate obstruction.

I've been trying for over two years to get my data from Amazon.

I eventually got to a point where Amazon provided a web-page, which has no less than sixty-two download links on, each of which would have to be manually operated.

It's properly tantamount to obstruction.

After finally reaching this point, Support were arrogant and high-handed - "We will not do any more than we have. We look forward to seeing you on Amazon in the future."

I still do not have my data.

I tried to start the process off a second time, but it went nowhere. I chased it, and then had some very disconnected and confusing responsese from Support (email from some random guy in Support who by the looks of it had been told to email me, but neither he had been told what for, nor I that it would happen).

I've not spent more time on it since then.

I stopped using Amazon about two years ago, because I've come to the view that the stories about how Amazon treats warehouse staff are accurate.

I want to get my personal data, so I can close the account.

Amazon of course refuse point blank (in the usual, slimey, support-talking-past-you way) to delete any personal data, so all you can do is delete the account and hope in the end Amazon expire the data.

I wonder if the Tor people know about this?

Firefox to my eye jumped the shark a long, long time ago, when they took to using deliberate deception during the install process to get people to sign up to a Mozilla account.

Pretty much everything they've introduced for years I've not wanted or disliked.

The saving grace has been that pretty much everything can be turned off in about::config.

I may be wrong, but I think Moz has become a typical larger company, wholly divorced from its users, unable to know what users want, let alone respond.

What Moz as a large company wants is really completely different to what users want, and a unique tracking ID is a shining example of this.

I'll be using Tor, but I my secondary browser now has to change, as this is intolerable.

Seemed okay to me with regard to caveats.

Performance issues -> it's lock-free and scales profoundly better than non-lock-free.

> So all operations on _Atomic variables in C11 are implicitly atomic

I may be wrong, but I would be shocked if this was so.

I think you may be mixing up non-tearing writes as opposed to atomic writes, which are performed using either cache-line locking (Intel) or exclusive reservation granules (everyone else) and as such require the employment of a specific mechanism to achieve (typically a macro or function, which leads to the use of the particular special instructions for atomic writes).

The overhead of an atomic write is very large, and it is often not needed. It would make no sense for every write (to an _Atomic type) to be atomic.

An atomic write will need to be issued, and on the face of it, that C11 code is not issuing an atomic write. I could be wrong, but I would expect a particular function or macro to be used for an atomic write, and when it is not, you have normal writes.

> So yes, that "++*barrier" operation is read-modify-write atomically AND with memory-barriers in sequential-consistency style

The quoted material does not describe this assertion.

Lock-free garbage collection exists and there's quite a body of literature.

You can produce this behaviour. Look for MCAS, from Cambridge Uni.

It never took off. I think it didn't scale.

You're talking here about memory barriers, but I was asking if atomic writes are in use.

Atomic writes have nothing to do with memory barriers. On modern platforms atomic writes are available without memory barriers of any kind.

Memory barriers do not cause events to become visible.

Only atomic writes do this; and so the question is not whether barriers are in use due to _Atomic, but whether atomic writes are in use due to the use of _Atomic.

> The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value.

Firstly, if the writer has used no barriers, writes can emerge in any order (and may never emerge at all, anyway, even if barriers were used). Secondly, if the reader has not used barriers, then even if writes have been written in some given order, the reader will by no means observe that order.

> A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time

A fence does NOT guarantee this. A fence controls and only only controls order of events. It has NO influence on whether events actually emerge. An atomic operation does, but this only solves the write-side of the problem; the reader still needs to issue a read barrier to guarantee seeing atomically written values.