sipos

This is what happens when you have a market controlled heavily by one player - they use that to their own advantage.

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.

Not sure about this implementation, but most virtualization implementations, including most KVM/libvirtd/QEMU ones, support shared directories.

> 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).

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.

I'm pretty sure they are just pointing out that IBM has been selling in Europe for longer than 50 years, but the parent comment to theirs did say 50+.

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.

Do you though? Why is 156 anymore familiar than 9C? I can't imagine 156 things any more than I can 9C things.

You might be able to. Personally I can't raise my ring finger without my little/pinkie finger also being raised.

Also, some numbers in finger binary are liable to get you punched if shown the wrong way round.

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.

Seems like a good reason to never use GitHub, and encourage other people not to.

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.

MS Office 365 and Azure or AWS. You can get collaborative editing of documents in MS Office now, if they are stored on OneDrive/SharePoint I think.

As someone who runs IT for a medium sized organisation using G Suite (now Google Workspace), I can not recomend against it enough. I understand why the decision was taken at the time it was (it was before my time, but it was when G Suite had much better collaborative editing than MS offered, and when the company needed to upgrade it's on-prem file server, and didn't have any capable of managing things like that in house), but it turned out, with hindsight, to be a huge mistake.

You get things like issues with a user not having visiblity of items in a folder, and support ask you to check all folders shared with the user to see how many are affected. There are tens of thousands of these, so this is obviously impractical.

I had an issue with their "eventually consistent" admin interface not showing whether a user was part of a group, and their response was to wait 24 hours to see if they have been sucessfully added to it, or to email the entire group and ask the user to check whether they got the test email.

We had a Google Sheets file that, for whatever reason, was not able to be opened. Months later, the issue is unresolved. If we didn't have daily backups that use the API to make a copy, exporting Google Docs, Sheets and Slides files as MS Office documents, using a thrd-party service, we would have just effectively lost this data.

It is clear that Google does not treat this as a business class product, and it hurts to business users.

It is getting worse and worse IMHO, while the MS competition is getting better and better. It is only a matter of time until we switch I think, and I would strongly caution anyone against adopting it, especially if you plan to use it as the primary file sharing method for more than 10 users. For us, the thing making it hard to move is that our data on Google Drive is a mess. We haven't been using Team Drives, because we have been using Google Drive since before they were a thing, so have complicated nested permissions, meaning we can't simply move things to Team Drives. If you have used it for as long as we have, when there was no way to prevent users from doing this, and didn't have policies about how it was used to prevent this (whiuch we didn't, we started using it before I joined the company) I don't see how you can have avoided this.

I'm not sure how GCP compares, but I have been pretty disappointed by how slow they have been to support recent versions of PostgreSQL and MySQL in their hosted DB service. We use AWS mostly, and, while there are things about GCP that look nice, they seem to fail to do the basics that would not be at all hard for them to do, and it looks like they don't take it seriously as a product either really. It is sad really, given that there really needs to be more competition for AWS and Azure IMHO.

Not if it discriminates on protected characteristics, in UK law. This isn't, but you can easily imagine many of the countries it operates in hjaving multiple laws that restrict its freedom to block whatever it likes. Some protect registered political parties (like the SWP) freedom of speech I think even (but not thre UK AFAIK).

> We're playing the same with messaging, whereas in reality what we'd need is federated providers, competing with their client software which can all write to each other - see SMS and email.

True, but nothing particularly good seems to exist yet. It has to solve the problem of end-to-end encryption in a way that users can manage to not lose their keys too easily, which is a hard problem. It only has to solve this, when email did not (at least in an easily usable way for most people) because it already exists in messaging, but that doesn't stop it not being well solved holding back the situation.

Anything that uses an open source client is a meaningful step better than WhatsApp, because it is easier to make and maintain a bridge from something better, like Matrix, IMHO. At least recently, I did not think Matrix was easy enough to use and stable enough to recomend to people, but them moving to something with an open source client, is better than nothing IMHO.

I'm not convinced Signal is better than Telegram, as an alternative, since Telegram is so much easier to use if you don't care about end-to-end encryption (most users don't sadly), and basically as easy to use (but much less trustworthy) if you do. I'm not sure which is better TBH, but I expect more people will stay off WhatsApp if they try Telegram than if they only try Signal, which is an advantage of recomending that (though I'm not sure it out-weighs the advantage of there being less end-to-end encryption).

> Somehow, the big players have managed to convince us to suck up the damage.

Not always. The GDPR has some decent provisions against overuse of machine learning, for example (it is just a shame it is basically unenforceable against global megacorps, and otherwise so shit as a set of law). We should not accept it, and I don;t think this is a fight that is lost. It is fine to use ML, as long as you are prepared to suffer the consequences of the mistakes of your models that you do not check. This is an important principle.

> Even in a world without Google and Facebook, enterprising nerds will be encoding H.265 via smoke signals to ensure we get our cat videos.

Damn right. These are important. I'm concerned this statement isn't entirely serious. While I hope not to have to resort to similar to that, I will if I have to. Cat videos are important damn it.

It isn't hard to make them triggered a different way, it is that it is hard to make them reliable enough and triggered a different way. They are designed to be triggered this way because it makes them simple. They are hard to service (requires surgery) and need to be triggered reliably when they are bring triggered. To achieve this, they are made as simply as possible, so have a simple trigger mechanism. Users of them are then told that they have to avoid this situation, by being very careful. One of the instructions anyway is to not keep a phone near them, because of concerns about RF interference. It isn't a case of making another way to trigger pace-makers, it is a case of making a way that is extremely unlikely to fail to work and will remain like that for decades, and where equipment to do it is very cheap. It will then take decades for there not to be people with these devices walking around. If they are changed to work a different way, you also need to equip hospitals around the world with a way to trigger them. Basically, it is really impractical, and it is not as much of a problem as you might think because users should already be hyper aware of the danger of this. Anything you do to change it has a huge risk of killing them because of failing to work if it turns out to be even a tiny bit less reliable after the devices have been inside people for years.

Another example of a device that would be a problem like this is my watch. Jewelry that would have similar problems is also common. Things which would be a problem if put close enough are everywhere, but this is always going to be an issue with something like this that is designed to be triggered easily and extremely reliably, and the decision has previously been taken to educate the tiny number of users of them about it rather than go through the unimaginable logistical effort of changing them now (obviously it was much easier when they were new and rare).

Edit: removed paragraph about making a warning device that I don't think is worth including here.

The point is that it is fairly easy to trigger. This is considered safer than having a hard to trigger mechanism and less user caution, because of greater chance of it failing to be triggered when needed. You could have some sort of complex signal sent that switches them, but it'd make the devices much more complex, and since they are very hard to service, and need to respond when triggered, they are designed to be simple. Users of these devices aren't supposed to have phones near them anyway.

Speaker magnets tend to be strong but small, meaning they would have to be very close. Thanks s is for attaching a charger, so is likely a much larger magnet, so more likely to be an issue.

Anecdotal, but I doubt there is much hard evidence about reasons people stop using Google products, or even if individuals do, or whether there is just less growth.

I have decided not to buy a Google phone next time, and to start the mamoth task of moving my primary email address to one using a domain I own rather than a gmail.com one (changing email address is hard :( ).

It isn;t so much because Google is evil, it is because their stuff isn't as good as it used to be, and they arbitarily lock people out of accounts for poor reasons, or force changes on people, at times. I have a Pixel 4 and have been pretty unimpressed with it as a phone and with how buggy Android seems to have become. I've also, over the past few years, started to dislike their stuff more and more. Having to use G Suite for work, as a user and an admin of it and supporting users (though I don't actually suport them directly myself), puts me off their stuff too.

Google no longer makes good products, but they think they do, and change thewir stuff on the assumption that they are improving it when they are not.

It wasn't just Reddit they were fleeing. I think it was Twitter too...