My understanding is that a locked bootloader helps protect against evil maid attacks and bootloader-level malware persistence. I find this a security risk that I would absolutely take for Google independence. "Properly secure" is subjective.
GrapheneOS do decide what phones they support. It is exactly their choice to support only Google Pixels, rather than taking a security hit for hardware independence (whether you agree with the decision or not).
My comment was to answer the question of: "Why is this relevant?" (Its been asked a lot). It's relevant because Bitwarden is claiming that they "cannot see your passwords".
At which point it simply gets forked from the last release/commit. Unless the project nukes all of the history and no one comes forward with a backup.
And, they would typically need the consent of every contributor to legally change the license, unless they had been forcing contributors to sign over rights to their code before contribution.
I'm sorry but this is simply incorrect (See 1,2,3), as I have previously stated. You could point to sources that agree with you though if you disagree.
They take Firefox, make changes to it, then release it. As such, it is a fork. More specifically a "soft fork" since they continue to pull changes from upstream (Firefox).
EDIT: Oh I see you're focused on the "duplication of the code" part. A bad phrasing on my part. It doesn't matter the specifics of how they pull in the source code, it is pulled in and used as the basis for librewolf's modifications.
They could even pull it in on first launch and compile the latest version of Firefox with their modifications for subsequent launches and it would by all means be a fork, since they are shipping a modified version.
They duplicate the code, creating a "fork" under their control, and make independent changes to the code. That is all that is needed to satisfy the "fork" definition.
The issue is when it's used inefficiently or for useless purposes. An unoptimized application takes 500MB of extra memory and that is 500MB that cannot be used for read/write caching nor another application, and 500MB closer to an OOM situation.
In theory, an application can suffer from issues of underutilization of memory, just as one that over-utilizes memory. In practice, I find that lower-than-expected memory use is a much more positive indicator of an optimization-focused project than one that uses more memory than expected.
In the meantime, it's not sitting there, unused and useless.
If your system uses caching, then "usused" memory may not be so. Memory used for caching is also cleanly "Available" for use if needed. This is not the case with the 500MB of extra memory a process might decide to capture. Of course this is complicated further with swap (I wouldn't use it).
Everything you do in any GUI is executing commands for you.
Those people have to understand programming and the CLI/terminal because, again, every GUI interaction is issuing a command to the system it runs on.
No one has built a GUI tool to help you with xyz yet so users have to issue the commands directly if they want xyz.
There is no world in which an operating system exists without a terminal.
There seems to be an incorrect understanding of what a terminal is doing. A terminal typically runs a "shell" program, which accepts input from the user. Some of the inputs are "commands", which are either internal (run an internal shell function) or running a binary.
An operating system can exist that has a GUI and doesn't have a terminal. A terminal is an interface just as a GUI is. (GUI vs CLI). They are not interdependant. They are simply different ways of allowing a user to interface with a computer.
Using a terminal and running "ls" not necessarily "issuing a command directly" anymore than a clicking an "ls" button in a GUI and it running some variation of system.exec("ls") is. Both simply run a binary and output the results.
My understanding is that a locked bootloader helps protect against evil maid attacks and bootloader-level malware persistence. I find this a security risk that I would absolutely take for Google independence. "Properly secure" is subjective.
GrapheneOS do decide what phones they support. It is exactly their choice to support only Google Pixels, rather than taking a security hit for hardware independence (whether you agree with the decision or not).
My comment was to answer the question of: "Why is this relevant?" (Its been asked a lot). It's relevant because Bitwarden is claiming that they "cannot see your passwords".
And static linking even better than both
At which point it simply gets forked from the last release/commit. Unless the project nukes all of the history and no one comes forward with a backup.
And, they would typically need the consent of every contributor to legally change the license, unless they had been forcing contributors to sign over rights to their code before contribution.
I'm sorry but this is simply incorrect (See 1,2,3), as I have previously stated. You could point to sources that agree with you though if you disagree.
1: https://itsfoss.com/librewolf/
2: https://wiki.gentoo.org/wiki/LibreWolf
3: https://lwn.net/Articles/1012453/
These are some examples that use "fork" in describing Librewolf.
You have described the creation of a fork.
I'm here if you wish to discuss further.
A custom version of Firefox, focused on privacy, security and freedom.
This project is a custom and independent version of Firefox, ...
LibreWolf is a free and open-source fork of Firefox, ...
This repository contains all the patches and theming that make up LibreWolf, as well as scripts and a Makefile to build LibreWolf. There also is the Settings repository, which contains the LibreWolf preferences.
They take Firefox, make changes to it, then release it. As such, it is a fork. More specifically a "soft fork" since they continue to pull changes from upstream (Firefox).
EDIT: Oh I see you're focused on the "duplication of the code" part. A bad phrasing on my part. It doesn't matter the specifics of how they pull in the source code, it is pulled in and used as the basis for librewolf's modifications.
They could even pull it in on first launch and compile the latest version of Firefox with their modifications for subsequent launches and it would by all means be a fork, since they are shipping a modified version.
It certainly is.
They duplicate the code, creating a "fork" under their control, and make independent changes to the code. That is all that is needed to satisfy the "fork" definition.
Some of those countrymen are conscripts. 2/3rds? Which makes continuation of battle far less justifiable IMO.
Some people will choose to fight in Ukraine, to possibly die in Ukraine. Conscripts face punishment for refusal.
How many of those fighting would refuse the peace deal?
It's more constructive to refute the point than breaking 196@lemmy.world rules in this fashion.
The issue is when it's used inefficiently or for useless purposes. An unoptimized application takes 500MB of extra memory and that is 500MB that cannot be used for read/write caching nor another application, and 500MB closer to an OOM situation.
In theory, an application can suffer from issues of underutilization of memory, just as one that over-utilizes memory. In practice, I find that lower-than-expected memory use is a much more positive indicator of an optimization-focused project than one that uses more memory than expected.
If your system uses caching, then "usused" memory may not be so. Memory used for caching is also cleanly "Available" for use if needed. This is not the case with the 500MB of extra memory a process might decide to capture. Of course this is complicated further with swap (I wouldn't use it).
I'm reminded of the horrid example showcased on the amber-lang website previously.
There seems to be an incorrect understanding of what a terminal is doing. A terminal typically runs a "shell" program, which accepts input from the user. Some of the inputs are "commands", which are either internal (run an internal shell function) or running a binary.
An operating system can exist that has a GUI and doesn't have a terminal. A terminal is an interface just as a GUI is. (GUI vs CLI). They are not interdependant. They are simply different ways of allowing a user to interface with a computer.
Using a terminal and running "ls" not necessarily "issuing a command directly" anymore than a clicking an "ls" button in a GUI and it running some variation of system.exec("ls") is. Both simply run a binary and output the results.
Wanted. It was a choice.
The image attached to your post:
So its already set up for people to argue on that claim.
Overreacting can undermine your cause. I don't see how reacting accordingly cannot "stop enshittification before it starts".
It can be if you buy from stores, such as GOG and Itch, that provide DRM-free downloads of games. Even Steam, depending on the game.