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.
> how is ARM China going to continue innovating? On their own?
Yes. Thery may do badly, but this isn't going to be much of a problem for China for ages. They are unlikely to do that badly though - among 2 billion people there will be plenty of good people.
Their much bigger problem though is their lack of access to cutting edge semi-conductor manufacturing technology. I imagine they are on this though, probably through industrial espionage (invading Taiwan would help, but they will face similar issues for acccess to tech long term unless they also get access to ASML work I think).
SMIC is already at 14nm, and ASML is allowed to continue to sell equipment for this process. The more advanced process nodes have several drawbacks; the domestic market could likely adjust to 14nm long-term.
The MIPS processor was copied for production in China (illicitly, until fully licensed), as was the DEC Alpha. There is significant processor design knowledge, and ample ability to copy any new designs produced by ARM-UK, even if they have to be scaled up to 14nm for domestic production.
Oddly enough, I learned recently that Russia prefers SPARC (known as Elbrus).
Elbrus are not SPARC. They are developed by Moscow Center of SPARC Technologies(MCST) though, that's where your confusion comes from(and there were few SPARC machines under Elbrus brand, but that was a long time ago). They were basically design team for hire in the 90s and were named such to attract customers. Then Intel wanted to acquire them in mid-2000s, but ended up just hiring almost everyone and leaving company as an empty shell. Now they are doing their own ISA and it's very different from SPARC. For starters, they are the only ones who are doing VLIW in CPUs nowadays(outside of CPUs I can think of only one other company, Groq).
Thanks, I just saw their association with SPARC from 1993 to 2010, so I assumed it was their main architecture.
On the subject of VLIW, Sophie Wilson was talking up Firepath as late as 2020.
"In 1992 a spin-off company Moscow Center of SPARC Technologies (MCST) was created and continued development, using the "Elbrus" moniker as a brand for all computer systems developed by the company."
"Elbrus-90micro (1998–2010) is a computer line based on SPARC instruction set architecture (ISA) microprocessors."
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.
