And you can buy an eSIM from a local carrier, which will then email you a code. It's unheard of for local carriers to mail physical SIMs to the other side of the world.
The typically tier 2 carriers are the main ideal perfect market for eSIMs. If you want to do everything online, you really can't if it relies on a physical something. I would estimate 90% of the market is for mint mobile and consumer cellular. eSIMs are a genius move progression from the old burner phone days, from the perspective of overhead costs and flexibility.
It can be more secure, but it also feels like the kind of "improvement" that's ripe for exploitation. When you put in a step where you have to ask your service provider for permission to swap the SIM, buckle up for the inevitable development of them asking for a $5, $50 or $100 "service fee" so they consider allowing it.
Couldn't they do that with physical SIM cards? On their end, record the IMEI of the first device they see connecting with a specific SIM card and then disallow connections if that SIM is used with a different IMEI.
I'm not sure if that's legal, but even if they did it, it's a lot more opaque. If they started doing it, many people would assume it to be a technical fault by the provider or the phone manufacturer, and the ensuing support calls and drama would probably cost way too much for this to be worth it in the first place. However, with eSIM, they get to redefine all the rules, since the customer has to learn how to use them from scratch anyway. And they also get access to nice, digital, software-driven workflows that can make the need to pay up apparent, as opposed to just randomly cutting service to the user.
I would love if they implemented a feature to prune media files larger than ~10MiB from the existing backup file. This way the file size would not grow to astronomical proportions so quickly.
I'm assuming the backup format uses a container (like Veracrypt volumes), which grows in size forever, and cannot be backed up incrementally. I ran into the same issue when backing up loopback LUKS volumes. An elegant solution in this case was switching to Gocryptfs which encrypts each file individually, but then can mount the entire folder as a whole with fuse. This means only modified files need to be synchronised to the remote.
Came here to say this. I moved my family (and our family domain) into Zoho and love it. It also has better features than Google in many areas. (coughre-ordering filterscough)
This article is already largely irrelevant. The GPL (and the FSF), whether you like it or not, always has been a political movement. The aim of the movement is to expand the pool of free/libre software and to disallow commercial entities from gaining an unfair advantage without contributing back. With the GPLv2 they already have, as it permits them to run the software in the cloud, with their proprietary additions, without contributing back. AGPLv3 closes that loophole that's why it's even less popular.
You can license your software as you wish, but in the long run the GPL has ensured that contributions reach back upstream for the common good, rather than for profit. The GPL gives protections for the people/end consumers, much like labour laws do in your own country. The GPL ensures that your contributions are respected, available to all, and not abused for profit (not always true, but tribunals have enforced the license terms before). The GPL has the effect of doing this globally while allowing contributions back from a global audience. It's genius and the companies absolutely hate it.
The article makes the point that, in practice, permissively-licenced projects see more contributions back. Copyleft projects are being rewritten as proprietary instead (with a few exceptions like Linux, which are too big to fail). The end result may be even worse for the user, if the proprietary alternative ends up being the most developed one, grows an ecosystem and a network effect, and eventually everyone is forced to use that. There's plenty of examples.
It's not about "fairness". It's about reality and survival characteristics.
As a user, I care about my freedom too. But permissively-licenced projects give me enough freedom to choose them over copyleft projects that are even slightly worse in quality
You've been very diligent in replying to the detractors in this thread, but I have yet to see any compelling examples.
You say that there are plenty of examples of copyleft projects being overtaken by proprietary versions that then create network effects that end up being worse for the end user because the original project was copyleft. You further assert that if the original project had been permissively licensed, this wouldn't have happened.
I'm unaware of this ever happening. Can you list a few of the examples you had in mind?
This thread has eventually changed my own stance on permissive licenses. Now I think that LGPL/MPL have the best survival characteristics: https://news.ycombinator.com/item?id=44657017
> Can you list a few of the examples you had in mind?
As I think about it, I see that I wrote "plenty of examples" mechanically (pulled it out of my ass). Sorry :)
That entire argument of mine is stupid because it hinges on the ability to see alternative universes:
> if the original project had been permissively licensed, this wouldn't have happened
I could pull any unpopular GPL project as an "example" (that would be more popular with a permissive license because "trust me, bro"). But that's a bad argument.
> The article makes the point that, in practice, permissively-licenced projects see more contributions back.
How are we measuring this? I mean, sure, MIT will get more contributions than GPL.
But the MIT code is used commercially. So you can get, say, 10x more contributions, but you're losing 100x more money. Is that a worthy tradeoff?
The idea of corporate contributions is that the company is probably making WAY more money off your code than they are spending contributing back to it. Otherwise, they probably just... wouldn't.
// The article makes the point that, in practice, //
The article is over 10 years old. Which is 100 years in computer-dog years. What may or may not have been true about 2015 may or may not be true about what is going on today. We cannot just uncritically take its conclusions as read.
Your comment is pointless, unless you follow up and point out what specifically has changed in these 10 years and invalidated the argument made in the article.
I don't take its conclusions uncritically. I examine them logically and I map them onto my own recent practical experience. Actually, in this thread people gave multiple good counter-examples that I haven't processed yet
People seem to judge these licenses with measures that might not mean anything to the authors or the users. There are different kinds of authors and users.
GPL authors want their rights preserved for the users. MIT authors might just want their stuff "out there", or really not care how their stuff is used.
The aregument here is sort of like judging football as more relevant than baseball because plays are more exciting but short enough to still show ads on TV.
(also both gpl and bsd licenses have been around ~40 years, so what does long run even mean?)
The GPL in no way ensures code modifications go back upstream. It certainly is not a requirement of the license. There are a ton of Linux kernel forks that will never be upstream.
Your comment is ignoring the realities and practicialities in the real world, just like GPL does. GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone, and especially not just because some person talking about "libre software" says so. No one really cares if they have access to their refrigerator's source code.
There are many, many software libraries and tools that are excellent and yet aren't popular. A very common reason as to why they aren't more popular is because they are often licensed with GPL.
> GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone
In practice, that is wrong. GPL software is useful even in a corporate environment because you are required to distribute your modifications only to the users who you distribute the software to. So if your modifications are meant for internal use only, then it's perfectly fine to keep the modifications confined to internal distribution.
On the other hand, if you're talking about publicly distributing modified software with undisclosed modifications, then you're financially exploiting the labor of the original contributors. They did most of the work from which you derive monetary profits. The fair thing to do in such a case is to negotiate an alternate arrangement with the original contributors. Or you could opt to distribute the changes according to the original license, if that's an acceptable option.
I have seen GPL software used in corporate environments in both the manners described above, without any sort of legal or ethical concerns. But the avenue of unpaid labor is so enticing for many large tech companies, that they fearmonger against copyleft licenses as if they're the worst crime committed against open source. Their argument is that copyleft licenses are too restrictive. Restrictive to their financial ambitions, perhaps? Because I don't see them restricting the developers or the normal users in any manner.
> A very common reason as to why they aren't more popular is because they are often licensed with GPL.
They're unpopular simply because of the vilification campaigns I mentioned above. It was very popular at one time to diss on copyleft licenses without a discernable reason. That was until many realized that the permissive licenses, combined with CLAs were an easy avenue for many of those companies to extract free labor from them.
