avidamoeba

joined 1 year ago
[โ€“] [email protected] 16 points 5 months ago (4 children)

Security. ๐Ÿ˜…

[โ€“] [email protected] 4 points 5 months ago

Has hell frozen over?

[โ€“] [email protected] 12 points 5 months ago* (last edited 5 months ago) (1 children)

A search nonprofit. Something like Kagi but nonprofit. Publishing its index on regular basis along with its source code. Wikimedia could perhaps start something like that.

[โ€“] [email protected] 18 points 5 months ago (1 children)

A space heater.

[โ€“] [email protected] 2 points 5 months ago

Firing developers and managers?? ๐Ÿ”ฅโค๏ธ๐Ÿคฏ

[โ€“] [email protected] 32 points 5 months ago (1 children)

You can factory reset it easily. You can't use it without the previous Google account credentials afterwards. You can't reuse a stolen Pixel which has Google account logged into it.

[โ€“] [email protected] 2 points 5 months ago* (last edited 5 months ago) (4 children)

The Debian community already maintains a Chromium fork. How much does that cost?

The human time needed should grow with the number of patches that need to be applied to the upstream code base, because some will fail now and then. This is what I refer to as "fatness" of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work. Testing is done by the users as it always has been in Debian and its derivatives. You're referring to a few full-time developers and I simply don't see the need. Maybe I'm missing something obvious. ๐Ÿ˜…

[โ€“] [email protected] 9 points 5 months ago* (last edited 5 months ago) (6 children)

It depends on how fat the fork is. While I haven't worked on Blink, as a developer who works on other people's very large codebases, including one from Google, I disagree. There are free tools for build automation. That'll take care of being up-to-date with upstream in terms of security. Patching things can be done using conflict-minimizing strategies. I used to work at an Android OEM and I've seen it done with great success. Thinking of Blink specifically, there have been lots of forks during its WebKit days. If I remember correctly there are also thin forks of Firefox maintained by some open source developers. This is all to support thay I don't think it's that big of a deal. Especially if most of it is rebranding and restoring some deprecated or deleted functionality. Could be wrong. I think we'll see, because I have a feeling the cost of maintaining a Chromium fork could be cheaper than patching apps to work well on Firefox. Some corpos might even pitch in. Not to mention that it isn't at all obvious for how long Firefox will be developed by Mozilla. If they drop the ball at some point we'll be faced with implementing new features in Firefox vs patching features of Chromium. โš–๏ธ

[โ€“] [email protected] 11 points 5 months ago (1 children)

Why not all? Add SFTP (file transfer over SSH) to the mix if needed.

[โ€“] [email protected] 14 points 5 months ago* (last edited 5 months ago) (8 children)

When it comes to open source software, market choices aren't nearly as necessary because new ones can be created at will and very low cost by forking. But in the abstract thech companies are definitely not interested in choices. Choices don't maximize profits.

[โ€“] [email protected] 8 points 5 months ago* (last edited 5 months ago)

The old default. They've been a part of market economies for a very long time. If anything we might have learned to tame them a bit as of late.

view more: โ€น prev next โ€บ