In practise, Flatpak packages have many more permissions than you might expect, and the sandbox feature gives a false sense of security. For example, the Obsidian Flatpak package [0] is given all of the following abilities without explicit permission from the user (the user has to know where to look to find out about them):
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
I disagree that this kind of scheme is inevitable. We can "evit" it through thoughtful discussion, foresight, alternative mitigations, and even regulation. Certainly, Google can choose to avoid it. On the other hand, the AI bubble will inevitably burst, since compute is not free. I look forward to post-bubble AI.
> On GNOME we already have a global shortcut for some emoji picker, I think it's Super + , or something
Actually, on most distros, the default keyboard shortcut for the emoji picker on GNOME/GTK is ctrl-. (same as the Firefox shortcut). This only works on apps that support it. Older Firefox versions did not support GNOME's emoji picker at all, but Firefox 150 supports GNOME's emoji picker using the expected keyboard shortcut.
The GPL would not have prevented the scenario that the top-level comment complained about. Nothing in the GPL requires rich downstream projects to send money to poor upstream projects. That's by design. The four freedoms that Stallman preaches intentionally permit distributing the software to free riders.
Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.
To clear up any confusion, Git runs pre-commit hooks, and they can be written in any programming language. There's a completely separate and independent project that gave itself the confusing "pre-commit" name, and it is written in Python. This project aims to make it easier to configure pre-commit hooks. An alternative to it is "prek", written in Rust.
Uppercase "B" stands for byte, and lowercase "b" stands for bit. But it's very common for people to miss the distinction, sadly, even professionals are sloppy.
> "why did you close my question as a duplicate of how to do X with a list? I clearly asked how to do it with a tuple!" (for values of X where you do it the same way.)
This is a great example of a question that should not be closed as a duplicate. Lists are not tuples in Python, regardless of how similar potential answers may be.
It's less meaningful than you think. Widespread prejudice does give you signal on public sentiment, but it doesn't give you much signal on whether the prejudice happens to coincide with reality or not, compared to other methods. People should be open to having their prejudices corrected by more relevant information.
Google doesn't allow you to recover a Google account using only your recovery email address. Despite its name, the recovery email address is not used to recover Google accounts AFAICT, it's only used to receive notifications about security-related events.
I strongly disagree. Python 2 had no bytes type to get rid of. It had a string type that could not handle code points above U+00FF at all, and could not handle code points above U+007F very well. In addition, Python 2 had a Unicode type, and the types would get automatically converted to each other and/or encoded/decoded, often incorrectly, and sometimes throwing runtime exceptions.
Python 3 introduced the bytes type that you like so much. It sounds like you would enjoy a Python 4 with only a bytes type and no string type, and presumably with a strong convention to only use UTF-8 or with required encoding arguments everywhere.
In both Python 2 and Python 3, you still have to learn how to handle grapheme clusters carefully.
If you're talking about free-as-in-freedom software, promoted by Richard Stallman and the FSF, then they have always been clear that Free software must not forbid commercial usage or require payment. Vendors are perfectly free to sell copies of Free software if they wish, but the license cannot forbid making copies and derivatives, even for commercial usage. See:
If you have uv installed, trying out Python 3.14 is as simple as running this command:
$ uvx [email protected]
Python 3.14.0 (main, Oct 7 2025, 15:35:21) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
That was beautifully easy! (Make sure you're on the latest version of uv first (v0.9.0))
Even personalised advertising can be done without sharing personal data with 100+ third parties. For example, ask the user to fill out a survey about their interests, and then serve them more personalised ads based on their survey answers, all without sharing personal data with third parties.
This article is on theguardian.com , and it has started to require a paid subscription for all readers who don't want to share their data with 131 third parties. There is no privacy-respecting free option. The paid subscription is £5 per month, and it doesn't eliminate all ads. (This requirement may depend on which country you're in.)
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
[0] - https://flathub.org/en/apps/md.obsidian.Obsidian
[1] - https://snapcraft.io/obsidian