I think this is a cool tool, although my personal preference when working with GraphQL is to have it be a very thin layer over my graphQL agnostic API function calls.
Grats author here. That's supported as well. You can simply write annotated wrapper functions/classes/types/interfaces around your GraphQL agnostic API.
I don't find it ironic at all. The purpose of telemetry is to be able to obtain information about the user population at large. It's anonymous and the data only flows one way (i.e. you don't see personalized ads based on telemetry data), but of course some data about your browsing behavior is being sent somewhere, yes.
It's a trade-off: You sent some anonymous usage data but in turn that contributes to decisions made about the product. If you opt-out of sending this data, obviously, it does not contribute to the pool of data from which decisions are being made.
Now, that a small group of people with very specific opinions and preferences is the same that disproportionally also opt out of sending telemetry... I don't see how that is Mozilla's problem.
You can't have your cake and eat it too, as the saying goes.
> Now, that a small group of people with very specific opinions and preferences is the same that disproportionally also opt out of sending telemetry... I don't see how that is Mozilla's problem.
I disagree. If you create a piece of software and develop a userbase that disproportionately opts out of telemetry relative to your software's alternatives, congratulations, you won. You got the power users, the developers, the people who care enough to submit quality bug reports, they're all on your side. Game over.
You don't need telemetry to understand what features these users need because they will tell you - loudly and forcefully - in bug reports filed if you break something. Assuming we're talking about open source software, and we are, they may also be the people sending you patches and improvements for these features.
Telemetry is what you need if you're making a mass market product that meets the needs of 80% of users. It isn't necessary, and in fact may not be useful, if you're developing software designed around the needs of the people contributing to the software. Some software tries to do both. But the way you do that isn't by looking exclusively at telemetry and then pretending that what you see there describes the behavior of all user categories, at least when it comports with the plans of your UX team. It's by listening to the people who are most passionate about the software.
The users who opt out of telemetry are a very tiny minority barely worth considering in terms of numbers. Further, they are explicitly saying "I don't value my vote on feature usage as much as I value turning off this data report which contains zero personal information and is used for no other purposes than changing the product. Again, don't want a voice in how the product evolves, cool, just don't complain about not having a voice down the road when something you don't like happens. It's like people who don't like their local politician who spent the year before bragging about how voting was stupid and just a way for the government to track you so you weren't going to do it.
An idea can be good regardless of telemetry, telemetry is descriptive and not prescriptive. Telemetry is inherently reductive in that sense. You're making a leap of logic that's genuinely unfounded - an idea can be good or bad and this is wholly independent of telemetry unless your only concern is maximising or minimising use of some kind of feature. I would never dismiss an idea because someone has telemetry disabled and it seems like a genuinely disturbing idea to even hold the position that a user with telemetry disabled is lacking value.
A user with telemetry disabled isn't lacking value, it's throwing away its vote. Plain and simple, if you want a vote that tells the software maker how you think the product is best used, that's telemetry. If you don't care about that vote, throw it away by turning off telemetry. Now, telemetry is only one (small) input into whether a feature warrants maintenance in a codebase of over 20 million lines, but it is one input that you have involvement in. As I said, up to you if you want to use your vote or throw it away but it's silly to complain about not having a voice after tossing yours in the dumpster.
I don't know, this post wants to convince readers that there are UX rules from which the theme author created an objectively better Firefox theme, yet most of the changes strike me as personal preferences.
It's obviously well made and maintained, but personally I don't think it's visually very appealing and looks in parts more cluttered. So I think people have different preferences, Firefox went with one design but they also enable support to make these changes, and that's all nice.
But I find the post to a bit silly, in that the author wants to prove that their preferences are empirically right.
I mean, the majority of work on Firefox is being done by Mozilla. If they stopped working on Gecko, I would be highly surprised if it would get security maintenance, let alone feature work.
Donating to the Tor Browser project could be an idea. The Tor Browser is a Firefox fork, and they are a legitimate org that is on friendly terms with Mozilla. Even to the extent that some Tor features are actually in the Firefox source code, and just disabled by default.
I've had a Hacktintosh from 2016 until end of last year.
Initially I just did it because I assembled a pretty good PC for gaming, but for work stuff I liked macOS more, so dual booting was a nice option!
This was also before the M-series chips, where you had to pay a hefty premium to get better Intel processors, and also (imo) Apple increasingly struggled with the heat produced by the chips.
Things got a bit more annoying a couple years later, when Apple had their fallout with NVIDIA and would not sign their drivers anymore, which meant I had to buy a cheap AMD GPU to use for macOS.
End of last year I changed a couple of components, including the GPU, in my PC and then decided the hassle with two GPUs was just not worth it for me anymore; so I bought a Mac studio.
I gained some and lost some with this transition. I'm no longer worried about major software updates, it's nice that I don't have to deal with complicated config files for the bootloader every once in a while, and of course there were some minor bugs too.
But I kind of miss the convenience of dual booting, with shared IO and drives. Now I need a network switch, USB-hub and have to toggle between monitor inputs. So yeah! Wasn't all bad!
Anyways, I think it's very cool that there is this community of people that write and maintain special bootloaders and drivers to make it all possible!
Yeah, in the head issue, the last work issue i9 MacBook I ever had was absolutely horrible... Would stutter and freeze up constantly under load and just become unusable as a platform.
It was nice in paper, but really needed to be undervolted and under locked... Not an easy task in a mbp. I couldn't get IT approval to buy a software to do it and didn't have local permission to load a self signed driver to do it either.
It was unusable for such a beast of a machine on paper.
From the article, I don't see Mozilla saying they don't want to comply with the technical requirements, just that they don't want to maintain two versions of Firefox for iOS (one Webkit, one Gecko).
I think that is a fair complaint. It's a financial burden to maintain two versions that Apple is imposing on them.
>Apple takes EU specific actions to satisfy EU specific regulations
Is that an indecent argument? I'm probably among the last people to defend Apple, but the only problem I'm seeing here is Mozilla complaining they can't keep paying their CEO $7,000,000.00 USD if they have to hire more developers.
So if Mozilla wanted to ship Firefox with Gecko on iOS, they would need to maintain that, but only for the EU, while maintaining a WebKit version for all other markets. Oof.
