headlines have focused on the detrimental effect this will have on ad blockers, which will need to adopt a complex workaround to work as now. There is a risk that users reading those headlines might seek to delay updating their browser, to prevent any ad blocker issues; you really shouldn’t go down this road—the security update is critical.
It’s almost like tying together feature updates with security updates was a deliberate choice by tech companies so that they could tell users shit exactly like this.
How can there be any real market choices when software literally tells users “for your own safety, you must abandon the things you want, and take the things we give you”. How can consumers influence the direction of the product if they never have the option to decline that direction?
We’re all trying to figure out where these headlines came from. The stable channel with all the fixes does not (at this time) bundle the warning. How is that users have become confused and believe the dev channel is the only way to get security fixes?
The headline is supposedly CISA urging users to either update or delete Chrome — it’s not Chrome/Google itself. However, I’m having trouble finding the actual CISA alert. It’s not linked in the article as far as I can tell.
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.
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. ⚖️
It does not depend in how fat the fork is.
You provide some reasons on your own.
Your assumption appears to be that open source software can be maintained with minimal costs by the community and sofware-aid assures an ongoing bug prevention of some sort.
In the end you still need at least a few full-time devs on it. It would be fair to pay them accordingly if they are maintaining behemoths of software.
Funfact: Infrastructure costs are x-times higher then IT Personel in my organization. A big chunk of it is energy and space; But its less then licensing costs…
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. 😅
The Debian community not already maintains a Chromium fork. How much does that cost?
I honestly can’t and wouldn’t judge: Time, Resources, implicit know-how etc. are unknown to me.
The human time needed should grow with the number of patches that need to be applied to the upstream code base, …
jupp
… because some will fail now and then.
Forks are done due to different reasons.
Therefore it depends why to fork.
It could be possible that one feature diverges so much that applying patches isn’t enough.
Especially patches in a debian sense, neither .diff/.patch-patches.
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.
For a brief period, until something rattles on the build system.
Debian patches are often applied to remove binary blobs due to licensing -
Imagine upstream chooses to include M$ Recall into the render engine.
You would need to apply extraordinary amounts of work. Maybe even maintaining a complete separate implementation.
This would also imply changes on the build systems, which needs to get aligned continiously between both upstreams, now.
Maybe I’m missing something obvious. 😅
With each version you have to very carefully review every commit if you want to maintain compatability with upstream, in order to merge patches into your fork.
When there are 50 devs working on upstream and you need to review every commit to assure requirement X, this alone is a hard path.
If you need to also apply workarounds compatible with future versions of upstream, you need PROFESSIONALS. Luckily these are found in the FOSS community; But they are underpaid and worse: underappreciated.
// plus I could imagine that things like chrome may even not be coming with the full test suite. The test suite of a browser are surely so huge I can’t even comprehend the effort put into it. And then bug tickets… Upstream says: Not in my version. Now the fork has to address these themselves! :)
Add into that, I’m betting googie will actively try to make downstream forks difficult to maintain without accepting the components they want to force on everyone like manifest v3
It’s almost like tying together feature updates with security updates was a deliberate choice by tech companies so that they could tell users shit exactly like this.
How can there be any real market choices when software literally tells users “for your own safety, you must abandon the things you want, and take the things we give you”. How can consumers influence the direction of the product if they never have the option to decline that direction?
We’re all trying to figure out where these headlines came from. The stable channel with all the fixes does not (at this time) bundle the warning. How is that users have become confused and believe the dev channel is the only way to get security fixes?
The headline is supposedly CISA urging users to either update or delete Chrome — it’s not Chrome/Google itself. However, I’m having trouble finding the actual CISA alert. It’s not linked in the article as far as I can tell.
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.
Maintaining a fork of Chromium would cost millions to do it responsibly.
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. ⚖️
It does not depend in how fat the fork is. You provide some reasons on your own.
Your assumption appears to be that open source software can be maintained with minimal costs by the community and sofware-aid assures an ongoing bug prevention of some sort.
In the end you still need at least a few full-time devs on it. It would be fair to pay them accordingly if they are maintaining behemoths of software.
Funfact: Infrastructure costs are x-times higher then IT Personel in my organization. A big chunk of it is energy and space; But its less then licensing costs…
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. 😅
I honestly can’t and wouldn’t judge: Time, Resources, implicit know-how etc. are unknown to me.
jupp
Forks are done due to different reasons. Therefore it depends why to fork. It could be possible that one feature diverges so much that applying patches isn’t enough. Especially patches in a debian sense, neither .diff/.patch-patches.
For a brief period, until something rattles on the build system. Debian patches are often applied to remove binary blobs due to licensing - Imagine upstream chooses to include M$ Recall into the render engine. You would need to apply extraordinary amounts of work. Maybe even maintaining a complete separate implementation. This would also imply changes on the build systems, which needs to get aligned continiously between both upstreams, now.
With each version you have to very carefully review every commit if you want to maintain compatability with upstream, in order to merge patches into your fork.
When there are 50 devs working on upstream and you need to review every commit to assure requirement X, this alone is a hard path. If you need to also apply workarounds compatible with future versions of upstream, you need PROFESSIONALS. Luckily these are found in the FOSS community; But they are underpaid and worse: underappreciated.
// plus I could imagine that things like chrome may even not be coming with the full test suite. The test suite of a browser are surely so huge I can’t even comprehend the effort put into it. And then bug tickets… Upstream says: Not in my version. Now the fork has to address these themselves! :)
Add into that, I’m betting googie will actively try to make downstream forks difficult to maintain without accepting the components they want to force on everyone like manifest v3
Don’t hate google too much…! They are an essential company to the west world; They contribute a lot to the community.
As long there is no business interest, the developers there are very competent and would defend their architectural choices I want to believe.
But yes, they - as a whole - have earned such a mistrust by now very much IMO.
They always have an option, they just don’t have the balls to actually do it.