People need to stop with this argument. Chromium might be open source, but it's still Google who decides what get merged. And yes, people can fork, do their own patches, fixes, but if it deviates too much from Google, you'll end up with a new browser to maintain on your end without a team the size of Google. If all theses teams choose to not implement their own browser, it's for a reason: a web browser is a complex piece of software. And the best example of this is the Edge team who forfeited implementing their own and just went with Chromium.
They definitely can't reasonably do that but in the long run I don't think Brave has the resources to maintain a hard fork from Chromium. That's the main reason I don't really get the Brave hype when Firefox does the job just fine and is actually a fully independent codebase instead of a relatively shallow customization of Chromium.
The only argument that keeps coming up is that Brave has a built-in adblocker but it's not like installing ublock origin is very challenging in Firefox (and on top of that your extensions are automatically synchronized if you use the Sync feature) and the relatively blurry monetization scheme of Brave makes me think that in the long run this built-in ad-blocker might prove a liability more than a strength. I'll take my ad-blocking independent, third-party and non-profit, thank you.
Brave, Opera, Vivaldi, Epic, Blisk, (and Edge?) can pool development resources. I dont think all the forks would have as much problem as people believe they would. A ton of webkit users switched to blink nearly overnight.
I think the bigger issue is chrome implementing an new web feature that blink-fork2 and firefox dont agree with, that web devs start implementing anyway. Google controls web development more than they control browser development.
Theres also the WideVine argument, but for me personally I dont see why i need my primary browser to also play netflix. Its not that hard to open a separate netflix app/browser. The amount of drm encapsulated video I watch in my browser is minimal to none.
I think Edge is good for Chromium. That puts Microsoft as a stakeholder there too, which takes power away from Google. If Apple were to move to a chromium-backed Safari, that would mean that three major players would be stakeholders in Chromium having a sane future.
This means that if you send a meaningful patch, Google doesn't like it, but Microsoft and Apple do, it might get merged.
I kinda agree that we don't need myriad of browsers. OS and CPU duopoly seems to be kinda ok. But for something that's _supposed to_ be universal it makes no sense to encourage fragmentation...
> chromium-backed Safari
Double whammy. Chromium runs on fork of WebKit which is Safari's engine.
My understanding is that this change in the extensions API will land in Chromium first, and so any browser depending on the extension mechanism of Chromium will be impacted, like Opera and Vivaldi. If I'm not guessing wrong, Opera and Vivaldi are compatible with Chrome extensions because they use the extension mechanism of Chromium, so they'll need additional maintenance burden to keep the `webRequest` API working.
The decisions to include features based on price tier has seemed to grow increasingly petty IMO. We are on the Bronze tier, and won't upgrade because of a feature like this specifically. But each time I see that we don't get new features like this, I lose a little bit of that love I've had in GitLab as a user for over 4 years now.
While using the free tier, I honestly can't validate a a $19/user/mo ($228/user/annum) expense based solely on a single feature, let alone why I should move to the paid version at all if more and more features start to be gated beyond multiple levels (a la Windows 7).
I love using Gitlab as a part of development cycle, managing issues and handling pull/merge requests but per seat licensing is a bit steep for a single user, even more so for a team.
The norm for pricing products and services is more and more "just for a pint/coffee/sandwich a month" but when everyone wants their share of the cash, the end result is a mismash of services and products that don't work together well (if at all) and you get stuck without a pint/coffee/sandwich for the whole month now.
You don't think you get enough value out of Gitlab to justify the seat price?
Based on the fact it seems to power all (or majority) of your development process it seems like it would be worth it?
I'm sorry you feel that way. There is a lot of thought that goes into our pricing and what tier a feature should go in. At the end of the day though, we still need to make money as a company. If you're interested in how we determine which tier something goes in, you can read about it here: https://about.gitlab.com/handbook/ceo/pricing/#the-likely-ty...
I think your confusing Swift's protocols with something akin to Java's interfaces. I don't really know Swift, but it looks a lot like Rust, so I'm going to assume that they work the same.
In Java, the following function definition compiles just fine:
IShape getShape() {
return new Rectangle(20, 40);
}
And, assuming that `IShape` has a `draw()` method, you can write:
IShape shape = getShape();
shape.draw();
It works because there is dynamic dispatch occurring at runtime: the JVM will look for the implementation of `draw()` in the `Rectangle` class (not sure of the exact mechanism, but that's the idea), and call it. To find it, the value (here, shape) must holds a reference either to its class so the JVM can go and look for the implementation, or to a table of all methods it implements (I think it's the first). So the compiler code doesn't know the layout of the concrete type used, it just add instructions to go look for the implementation at runtime. But that's fine, because any Object in Java is in fact like that: a fat pointer, containing a pointer to the data, and a pointer to the implementations.
I won't work in Swift because, as far as I know, there is no dynamic dispatch, at least by default. When you write the following:
The compiler will know what is the concrete type of `T`, and so will use its implementation of the `draw()` method. It won't be found at runtime, it is known at compile time. What this means is that a protocol is not a type. This is the important part. An interface in Java is a type, because it doesn't dictate how the method is called, it allows the concrete type to live under the hood, and call the right method at runtime. A class in Swift is a type because you know how to call it, how to access it. But a protocol is just a set of constraints on a type, not a type by itself.
That's why you need the `some` in return position. Well, you don't really need the syntax, but it helps understanding the difference with the "same" Java code. The `some` keyword says that the function will returns some type that will implements the `Shape` protocol. It will in fact return the concrete type, but this is not included in the type signature, so it can change, it can hide implementation details, without making a breaking change in the API. It also means that the following won't compile (I'm not sure here, but it works that way in Rust):
func union(_ leftShape: some Shape, _ rightShape: some Shape) -> some Shape {
if isEmptyShape(leftShape) {
return rightShape
} else if isEmptyShape(rightShape) {
return leftShape
}
return Union(leftShape, rightShape)
}
Because here, all code path don't return the same concrete type. If you want different concrete types, you'll need the other keyword, `any`. `any` is in fact a lot like the interfaces in Java, because it uses dynamic dispatch under the hood (if it works like it does in Rust). The compiler will know how to turn the concrete type into the dynamically dispatched one.
Generic functions in Swift are compiled separately from their callers. Protocol requirements called on values of generic parameter type are dynamically dispatched via a witness table passed in under the hood for each generic requirement.
> I also suggest sending the version string as the User-Agent so you can debug server-side issues. (Assuming your CLI uses an API of some sort)
Isn't it some kind of disguised tracking? I know it doesn't give as much info as the user agent of a browser, but still, you could track the OS, even the linux distribution, and surely more, while still being a reproducible build.
