Yeah, I wouldn’t be too confident in Facebook’s implementation, and I certainly don’t believe that their interests are aligned with their users’.
That said, it seems like we’re reaching a turning point for big tech, where having access to private user data becomes more of a liability than an asset. Having access to the data means that they will be required by law to provide that data to governments in various circumstances. They might have other legal obligations in how they handle, store, and process that data. All of this comes with costs in terms of person-hours and infrastructure. Google specifically cited this is a reason they are moving Android location history on-device; they don’t want to deal with law enforcement constantly asking them to spy on people. It’s not because they give a shit about user privacy; it’s because they’re tired of providing law enforcement with free labor.
I suspect it also helps them comply with some of the recent privacy protection laws in the EU, though I’m not 100% sure on that. Again, this is a liability issue for them, not a user-privacy issue.
Also, how much valuable information were they getting from private messages in the first place? Considering how much people willingly put out in the open, and how much can be inferred simply by the metadata they still have access to (e.g. the social graph), it seems likely that the actual message data was largely redundant or superfluous. Facebook is certainly in position to measure this objectively.
The social graph is powerful, and if you really care about privacy, you need to worry about it. If you’re a journalist, whistleblower, or political dissident, you absolutely do not want Facebook (and by extension governments) to know who you talk you or when. It doesn’t matter if they don’t know what you’re saying; the association alone is enough to blow your cover.
The metadata problem is common to a lot of platforms. Even Signal cannot use E2EE for metadata; they need to know who you’re communicating with in order to deliver your messages to them. Signal doesn’t retain that metadata, but ultimately you need to take their word on that.
KDE has a predefined schedule for “release candidates”, which includes RC2 later this month. So “RC1” is clearly not going to be the final version. See: community.kde.org/…/February_2024_MegaRelease
This is at least somewhat common. In fact, it’s the same way the Linux kernel development cycle works. They have 7 release candidates, released on a weekly basis between the beta period and final release. See: www.kernel.org/category/releases.html
In the world of proprietary corporate software, I more often see release candidates presented as potentially final; i.e. literal candidates for release. The idea of scheduling multiple RCs in advance doesn’t make sense in that context, since each one is intended to be the last (with fingers crossed).
It’s kind of splitting hairs, honestly, and I suspect this distinction has more to do with the transparency of open-source projects than anything else. Apple, for example, may indeed have a schedule for multiple macOS RCs right from the start and simply choose not to share that information. They present every “release candidate” as being potentially the final version (and indeed, the final version will be the same build as the final RC), but in practice there’s always more than one. Also, Apple is hardly an ideal example to follow, since they’ve apparently never even heard of semantic version numbering. Major compatibility-breaking changes are often introduced in minor point releases. It’s infuriating. But I digress.
A lot of my work involves writing scripts for systems I do not control, using as light a touch as is realistically possible. I know for a fact Python is NOT installed on many of my targets, and it doesn’t make sense to push out a whole Python environment of my own for something as trivial as string manipulation.
awk is super powerful, but IMHO not powerful enough to justify its complexity, relative to other languages. If you have the freedom to use Python, then I suggest using that for anything advanced. Python skills will serve you better in a wider variety of use cases.
I doubt any billionaires have that much money “sitting in a bank”.
Most wealth is non-liquid. For example, if you found a company that becomes massive, and you maintain a controlling share, then you could be a billionaire on paper while having no real money to spend – the only way to turn that into “real” money would be to sell shares in the company, and thus lose control of it. If the company is doing good work, it could be better to retain control and act through the company, by ensuring that it pays employees good wages to do good work for the benefit of society. This is not completely incompatible with profit in theory, though in practice…yeah. I’m not sure if there are any such billionaires in the world today.
The real problem is more fundamental to the economy, in that it fairly consistently rewards bad behavior.
Larry Page basically became a billionaire overnight when Google went public. I don’t recall Page or Google doing anything especially evil or exploitative before that, though their success was certainly built in an unsustainable economic bubble.
If Amazon didn’t treat its employees like shit and poison the entire economy, then Bezos could probably still be a billionaire and I wouldn’t necessarily hold that against him.
I don’t think he was ever a billionaire, though he’s certainly done quite well for himself. Since leaving Apple, he has founded several new companies and projects, focusing a lot on education and philanthropy. He was also involved in founding the EFF.
He’s an engineer first and foremost, and several of his projects never achieved mainstream success, partly for being, IMHO, ahead of their time – for example, a programmable universal remote in the 80s, and a GPS-based item tracker in the early 2000s.
As far as I know, he has never been involved in any notable scandals.
The key points are that Google Maps location history will be stored on-device, with an option to back it up (encrypted) to the cloud so if you switch devices you can keep the history. The default auto-delete will be three months, and you can increase or disable that limit.
I guess that means location history will no longer be accessible via the web site.
I don’t think Google has implemented any E2EE system for backups before (correct me if I’m wrong). I wonder how exactly this will work.
Interesting. Are there any other accounts on your phone that provide contacts? Maybe social media or other chat platforms? On Android you can see accounts in Settings > Passwords & Accounts (or somewhere similar; it varies a little between brands). You can also check inside your Contacts app by expanding the sidebar (again, varies by brand).
Just a thought. I don’t have any other contact providers on my phone so I can’t test it myself.
Please keep us posted if you get any official response or learn anything new!
I used to run Tumbleweed with KDE on my Nvidia system. I found the rolling release structure of Tumbleweed to cause extra work for me, because kernel updates came frequently and occasionally broke the Nvidia drivers. As a workaround, I ended up pinning my kernel to an old version.
Nvidia drivers have been at least a little troublesome on every distro I’ve used, particularly with the additional CUDA libraries.
One nice thing about Suse is that it uses BTRFS by default, and you can use snapper to revert your whole system if something goes wrong. So if Nvidia shits the the bed after an update, it’s easy to roll back. Most distros default to ext4 and do not have snapshot support by default, which feels like living in the stone age to me after using Suse and BTRFS.
Of course you CAN set up BTRFS and snapshots in any distro, but that’s a lot to ask for a beginner with Linux. I strongly recommend choosing a distro that does that for you, like Suse.
Carbon wasn’t that prevalent 10 years ago. 15, maybe. 20, definitely.
10 years ago, Carbon was already officially deprecated, and it had clearly been a second-class citizen for years before that. Most apps were already using Cocoa at that point.