Not being made in a way that is usable in current systems, not having a commercial scale manufacturing process yet, and not being proven for long term use yet.
As far as GDPR is concerned, I think they are a controller if they are processing data to provide their service they run to customers. The control how that service works, and are not processing data on behalf of a controller explicitly under their written instructions. If they were a service used by a company like this, they would be a processor. The rertention period here is presumably until the user closes their account or deletes the data from it, possibly plus some period to allow for Evernote to delete it, and the basis is performance of the contract created by their terms of service, or consent. If so, they don't have to delete it until they are instructed to bny the user. They would have to probvide for a way gfor it to be deleted by the organisation they setup to retain it when setting that up though. That organisation would be a processor, unless an explicit relationship with the customer was created with them (which I would expect there would be as part of the user accepting using it), in which case I think it would also be a controller. Either way, they would be responsible for deleting the data when the customer wants it deleted because either they would be as a result of their relationship with the cuastomer if they were a controller, or because it would (have to be) be part of the terms of the processoring agreement with Evernote.
A lot of spam is just a link to a page for someone to download malware or enter card details. It is already relatively easy to get these taken down if you care enough to, but a waste of time as the senders have moved on by then. The idea that spammers cannot make something that people tricked by their scam will use, but that insulates them from time wasters, is ridiculous.
Oh god, it is one thing to have it in Windows on a PC, but imagine having it on a device with a locked bootloader.
Obviously you should never pay for a device where they won't support you, the owner, unlocking the bootloader, but obviously people do. I'm not sure if Xiaomi are one of the manufacturers that do not support it.
Really hope Akamai don't mess up Linode - I'm a long time happy customer of theirs. I hope this is positive for their employees, who made it what it is, too.
I don't have a lot of use for it, but I think their load balancer could be better, so hopefully this will happen now.
At least for most Linux systems (not sure about other *nix, but I expect the same?), there is a system default encoding, defined by the locale, and I think decoding the filename in that encoding and displaying the resulting string, is probably the correct way to display a filename? That seems as good as you are likely to get on any system really.
I think for any POSIX system, either there is locale support defining the encoding, or it uses the POSIX locale, which defines the encoding (ASCII).
Of course you need to handle cases where filenames cannot be decoded in the system encoding (probably by replacing characters that cannot be decoded), because a filename in a different encoding, or even with no valid encoding, has been used on disk. While systems can say that file names containing bytes that are not valid characters in the system's encoding are not valid file names, that doesn't stop people mounting disks with them, so the problem never goes away if you support opening media from other systems.
What I am saying is that this is no more a Unix problem than it is a problem on any system that supports removable media.
I thought the same thing as I was reading it, but I think they are probably using larger block sizes than the SSD's blocks for better compression. I'm not certain though.
Edit: reading other comments, it looks like their block size is only 64KiB, so this isn't the case, so I don't know the answer. I can only think that perhaps it is an issue because ZFS doesn't deallocate the freed blocks quickly enough and they are making changes fast, meaning a significant amount of disk space is used by blocks that are about to be TRIMed but haven't been yet.
It isn't an under the table thing, at least in the UK. For the generalloy used frequency bands for this, there was an auction for the spectrum. You can get access to parts not being used by the people who bid on it.
You can also get an amateur radio license, and use frequency not normally used for this, but that probably means using SDR as most devices designed to use LTE will only work on normal LTE bands etc.
No bribes, connections, or anything shady etc needed.
So, I can't see how they can argue that the code generated is not a derrivative of at least some of the code that it was trained on, and therefore encumbered by a complicated, and for anyone other than GitHub, impossible to disentangle, copyright claims. If they haven't even been careful to only use software under one license that does not require the original author to be attributed, then I don't see how it can even be legal for them to be running the service.
All that said, I'm not confident that anyone will stop them in court anyway. This hasn't tenmded to be very easy when companies infringe other open source code copyright terms.
Until it is cleared up though, it would seem extremely unwise for anyone to use any code from it.
The problem with the GDPR is that it is only as good as the authority enforcing it. There are complex rules (from memory about a third of the text, but it is a while since I read it all and this was the bit I was least interested in) on which authority is the one in question that means you can somewhat choose your authority, and some of them are not enforcing it at all. This is how Facebook and Google etc are able to do things that clearly violate it I think.
This is the DB that contains the usernames and (hashed) passwords right? What do they expect? That you have a separate DB for authentication from everything else? What does that achieve? If you DoS the auth DB, you still DoS the application in this scenario.
They also desperately need to improve things like the store, which has no wish lists, no way to see all of the titles in specific categories, etc, at least on mobile.
There are multiple third party services which use the API to make daily copies of your documents, exporting them as MS Office documents. Yes, this isn't perfect, and you can lose some info in the files, it is pretty good for the most part. Nobody shpould be using G Suite without this, IMHO, because this happens too often.