Porting Firefox to Apple Silicon
hacks.mozilla.org
hacks.mozilla.org
>"Attempts to contact the vendor through regular support channels were unsuccessful so we ended up searching LinkedIn and managed to find an engineer working on the core antivirus detection. They immediately understood the seriousness of the problem and took prompt action to get a fix shipped, thus preventing quite the disaster for the users of this product. It’s notable that without this last-ditch effort we would have been effectively blocked from releasing a native Apple Silicon version for an indefinite period."
20 years ago Google would have sent someone to Mozilla HQ for a week to work on stuff
Often the expert is too valuable to give up, or is a poor choice for customer engagement. If you have a consulting team, they may lack the experience needed, or reputation, that the customer wants. As soon as you send the expert onsite, you will have a challenge not sending them at a later time. This scares off engineering managers from lending their engineers because inevitably they have to fight off the requests.
The better workflow is one where you can send a less expensive resource (however you measure it) onsite and have them work remotely with the expert. If you can stick with that you often end up with the onsite person leveling up their skills and the ability to re-engage in a scalable manner. Any engagement needs prep before the onsite, a plan for escalation when onsite, and a disengagement plan.
Edit: Apple also had to change the linker for the sake of Macromedia’s monolithic applications. Another story though.
> More of a concern was user reports that some antivirus software was flagging all our Universal Binaries as malware, and corrupting the Firefox installation the moment the update arrived.
> The software was using machine learning techniques and presumably observed that our combined Universal Binaries didn’t quite look like any other legitimate software it had ever seen before.
> Attempts to contact the vendor through regular support channels were unsuccessful so we ended up searching LinkedIn and managed to find an engineer working on the core antivirus detection.
But Apple and Mozilla headquarters are 5 miles apart (roughly). Couldn't you just walk/drive/scoot/fly/what ever over and talk to someone?
If you knew someone and had scheduled time with them, then yeah I'm sure you could hoverboard your way over.
So it's hard to tell if the size of the vendor is the issue here.
Product I used to work on had frequent false positives from antivirus software marking certain files as having some malware or whatever in it.
It's super unpleasant trying to get those changes pushed out. Glad that they were able to get some resolution quickly, usually that isn't the case, at least in my experience.
I could get a quick ya or nay form them on some things and it was so much faster for everyone involved.
If it was a ya, I knew we had something, still more work to do but the case would skyrocket through the usual channels and engineering was engaged and ready.
If it was a nay, the usual channels it went and everyone was ok with that.
The engineers would give me a few minutes knowing I wasn't going to bring them poorly thought out garbage, I would limit the rate of these special situations, and special customers / sales guys could get the job done way faster.
It was a well known process by those who knew about it... but not everyone knew.
I was a regular support drone as far as anyone knew.
I just had some connections that came about because I could be discrete and the engineers understood that I didn't bring them garbage too early (without enough information) or without good reason.
But above all: be a good listener. Listen to what they say, think about it and build it on next time you talk with them. If they see you showing interest and learning about their domain, you'll get a direct line to them. And don't always bring them problems, be sure to stroke their ego too by asking what they're working on.
It doesn't happen overnight, it requires perserverence and a dollop of luck. You won't walk into a job like that, it takes years of building a reputation for yourself.
Parent likely established a working relationship with individual(s) in engineering organically over time, and at some point leveraged that relationship to ping them about a customer issue that crossed their path and seemed to be an engineering concern vs user-error. That didn't cause waves and went well, and got repeated enough to become an established but unofficial "thing" parent was capable of, and they became known by a few sales/account folks as the go-to person when they felt a situation may warrant that unofficial route.
You can make a career off of doing this sort of thing, but I'd caution against it. If a company is hiring for specific scenario of "fast lane between client and engineering", the actual job is "support with special escalation privileges, servicing clients splurged for the premium package". You get all the soul-crushing hell of working a normal support role, but with the added benefit of solely servicing clients that expect you to hand them the world because they paid extra for it. Which is far closer to a nightmare than a dream; particularly considering someone working one of these official roles likely has the skills to pivot out of the support org and into the engineering org in some capacity, and drastically increase their salary potential while simultaneously improving their quality of (work) life.
In a more general sense though, pretty much any career benefits from doing what the parent described. It's effectively just flexing your soft skills and establishing relationships with people outside of your immediate sphere/department. Which has a tendency to make it easier for you to get things done, and garnering a reputation to that effect.
Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.
It's important for at least the following to happen:
1. Bad issues that engineering will fix don't get stuck in support.
2. Product management review and respond to feature requests, or enable support to respond to customers.
3. Support have a reasonable level of technical and communication skill, and are empowered to answer for the company.
4. The organization works through rather than around support.
What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
Your role as the back channel is helping to provide some coherence here. However, things can go bad if you left. Inevitably, this is the fault of the company, but when I've found myself in this position I've tried to "promote" people in support to take the lead on this role. Further, formalizing the special request process to be minimally tracked helps visibility with my manager and others. Eventually managers ask why you have become a gopher.
Improving the workflow often involves helping support build relationships with engineering. Management can buy in if support attrition is high (it often is if there is a limited career ladder for support) and it can also improve their perception when people are focused on trimming support cost.
In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations."
But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address."
As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated.
0 - Because money, I suspect.
I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :)
But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.
But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles.
When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).
To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc.
I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist.
What am I missing?
* people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training)
* people unwilling to RTFM, google, youtube, etc.
* people whining when a general purpose tool doesn’t fit their exact workflow to a tee
Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads.
Fact is, people do what they do and they have their reasons.
Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does.
Net happiness goes up too. True for the enterprise and users, people at large.
And the fact is, enterprises seeing to make every support transaction a positive ROI are, in fact and in deed, penny wise and pound foolish.
They will see an opportunity cost due to missed sales opportunity.
They will see greater load due to people using an inferior process and poorly empowered people, repeatedly.
They will see a diminished overall market perception.
Their products will provide less value due to a greater misalignment with both exiating and potential users needs, which drive perception of value, which drives more dollars.
Personally, having been on all sides of this matter, I rank what we are discussing at the very top when considering who I will buy from and or work with.
Flat out, when I see enterprises putting seriously crazy amounts of money in the bank, I accept zero excuses in this regard.
It is not necessary. Lives are short, money hard to come by. Best get solid value for the dollar.
Right now, I am in the small business space and rock solid support is how we are killing it.
Been there, very large, small, medium, consumer, b2b...
Don't tell me it can't or should not be done when billions land in accounts free and clear.
It can. Should.
I spend with those who get that first and foremost.
And I don’t mean that cynically - since if it’s as easy and guaranteed profitable as you say, why wouldn’t you be able to convince numerous CEOs to unearth all of those extra billions?
Again, if the priority is to always have a positive ROI, and that metric is computed every quarter, without due and inclusive consideration for externalities?
All the things I discussed here are going to get watered down. And it is always the same priority on max dollars now, max recurring dollars now, and WGIF about the future, others.
Where that happens, so do the things I just said. Not my mess to clean up.
Some enterprises get it. They get my time, attention, dollars and referrals first.
Beyond that? Got better things to do.
Clearly you value things differently. That does not make anything I said wrong.
Take care. You get last word on this.
"Cost center" can be transformed into something else given both an understanding that support can and should contribute to future sales, and an organization capable of putting that understanding to work.
I have seen a similar scenario in manufacturing where various setup, prep, quality tasks are seen as cost centers and minimized.
Doing this kind of thing has ripple costs. Always.
In a perfect world, we make software, or hardware, and it just works and people grok it.
In the one we live in, these are fantasies and we can choose to understand, recognize the value, or not and get the benefits or not.
The users, customers, move from role to role, and support often determines their willingness to use the product again. That is straight up powerful marketing by referral.
Support often is the first to understand a user, customer needs an option too, or add on, replacement, preventative maintenance. Done right, these leads into lean, consistent sales.
"Cost center" to me has always been a bit silly in this way. There is opportunity to add value throughout the chain of people, process, machines, systems that are all necessary to properly conceive, realize and deliver something to others.
One thing often missed along with failing to understand value is failing to ask to be compensated for it.
Doing things in a robust, high value for the dollar way is not the cheapest way, in terms of raw product price, and depending, size of margin.
But, we do get what we pay for too, and the lowest price often comes with externalities paid by both the enterprise and its customers too.
Sometimes I see this all framed as a luxury. That is just as much of an error, and does come with unnecessary costs and or poor alignment with actual value.
If there are serious UX issues, your designer might not uncover them, but support will hear about it. If there are edge case performance issues, your dev team might not uncover them but support will hear about it. Very few people know more about how real users interact with your products than support.
I should have included that. Glad you did.
not much, or everything -
it's basically an accounting term on how you are tracking an expense and so it is very insightful as to how the effort of your project,group,department etc. is perceived by upper mgmt
so "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
is pretty spot on, if the effort has been (mostly arbitrarily) categorized as such..
when i learned the accounting theory behind it, it suddenly illuminated managment attitudes in current/previous jobs - literally in some orgs overly reliant on this perspective there is literally nothing certain efforts can do through official channels to be viewed as 'valuable' ..
Support can very much be a profit center. Support personnel is relatively cheap; if their services are priced correctly, they can easily become a stream of recurring income - and everybody knows that "recurring income is best income".
However, this requires efficiency and creativity at the managerial level. It's easier to see support as a burden and just work on shrinking its costs, instead of maximizing its revenues by formulating good price plans. The former is an internal effort that is fairly easy to implement in short timeframes and will easily win brownie points with direct superiors (who doesn't like to cut costs?); the latter requires actual pricing skills and market knowledge, and might take a while to get results. The mediocre manager will always prefer the former.
This sets up perverse incentives, that as far as I can tell, are theoretical, but have potential to become more prevalent. Because of the cost center as a profit center idea, my ISP can generate more revenue by providing less value to me. If failing infrastructure causes me to call support more often, and more support calls increase the likelihood of more revenue, why should the ISP invest in better infrastructure?
The key to having a successful business is to carefully align the incentives of specialities in an organization to make the most competitive offerings to the market. If there are competitors, and customers can switch to them, and the competition is more compelling, then I would go to other ISPs.
Unless you’re into fraud, “accounting” and “accounts payable” are examples of cost centers. You don’t hire a bunch of innovative people to boost it because it’s not going to ever increase your revenue.
The distinction is made from a strategic perspective because scaling up “cost centers” should be avoided at all costs and scaling up “profit centers” is something you want to do as much as you can.
It has no overlap with “interesting work”. Very often the boring parts of an industry are the profit centers (e.g. in academia the profit comes from packing students into classrooms, not research).
Some examples (that I have seen in reality):
Finance departments are cost centres, until you give them enough resource and they find you a more efficient tax structure. Cut finance departments start to struggle with things like credit control which affects your revenue.
Distribution Centres are usually seen as a cost centre, until you drop spend and it impacts COGS or customer lead times, or inventory in shops raises because of less frequent deliveries and you get out of stocks.
IT is a cost centre, but when funding is reduced change across the whole business slows and other areas are impacted (eg the customer web experience).
In reality the distinction of “some areas generate profit” and “some areas just cost” isn’t true in the end. All areas contribute to profit - some just do so indirectly.
I think the idea of Michael Porters “value chain” is better, where everything contributes to customer value (including indirect functions). The argument this makes is if you see some areas as just cost centres (e.g. fulfilment centres) then you can miss your ability to maximise customer value (e.g. offering faster delivery options).
Even sales people don’t usually generate profit on their own because without the other business areas they would be selling hot air.
Expecting enough of them to just volunteer their time doesn't appear to be a sustainable answer.
I spent a few years in IT as a Product Manager (or a similar role), and I viewed my primary role as protecting my team from the barrage of shit that I got, so that they could focus. This involved making sure I was politically the first point of contact and reducing back-channels (some are fine, but not ones that change functionality, involve significant work or are too distracting), placating the people requesting functionality or fixes by understanding how serious the dependency/issue was, triaging it and either placing it on the roadmap or saying no. We also had an engineering manager that could be the contact for specific bugs who could then triage and pass it on.
You're so, so spectacularly wrong on this, I am honestly gasping for air.
Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?
The biggest companies in the world typically end up with CEOs that come either from sales or from accounting. That is not an accident. Business is about money, and you want smart and innovative people to look after it. Conservative CFOs can be the death knell of a company, among other things.
However this:
“Accountants are the only people who know if your company is alive or a walking dead.“
I disagree with.
A walking dead company is only walking dead until one of its initiatives pays off.
The accountants will only know this after the fact, whereas numerous other functions may know it to varying degrees of confidence before the fact.
The accountants know when your debits have to be repaid, how likely they are to be repaid or refinanced by then, and what the penalty for not doing so will be. I'd argue that, in most cases, nobody employed in the development/production chain will have that information, possibly not even the CEO.
Yes, they may have models and estimates, but the real information will be in the hands of those involved directly.
Even things like refinancing and the options for doing so can be affected by things like letters of intent from potential large clients, industry validation, etc.
Just knowing numbers and dates isn’t enough.
I’m not saying accounting isn’t important, but it just isn’t the only source of truth.
Calm the fuck down. It’s a conversation.
> Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?
You entirely missed the point. At no point did I say accounting was not important. I pointed out though that investing more and more into accounting does not boost returns. If that were true, every company could just hire thousands of accountants to boost their profits. This is what separates a cost center from a profit center. Your department provides value in the same way that running water does. It’s critical and you don’t want to skimp on it, but it’s just a part of the business that isn’t helping grow the total market capture.
> The biggest companies in the world typically end up with CEOs that come either from sales or from accounting.
Why would you include sales together with accounting? Sales is precisely the opposite of accounting in this regard because it’s very easy to tie sales directly to revenue. So easy their compensation is literally based on it.
Not so hot take: CEOs that come from accounting and not a customer-oriented profit center are the worst. They know what the numbers look like but are fundamentally disconnected from why customers give money to the business. Seeing the minutiae of the ins and outs of money gives a super false sense of understanding the business. Accounting CEOs are terrible in any industry that requires innovation or getting ahead of trends.
We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$.
Management was totally aware of it all and supportive.
But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.
For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience.
Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help.
So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall.
Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.
> What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane.
You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent.
... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it.
An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.
I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.
The dark patterns used in software like AVG and avast, both making every system I see them on so slow that they might as well be unusable, are all focused on getting more installs, be it to force people into getting whatever "premium" subscription or harvesting data(e.g. attaching themselves to every sent email like a virus).
There are very few that I could actually recommend, like Malwarebytes - for most users, Windows Defender will be more than enough nowadays. I haven't used a mac in a while, do you actually need AV on them today?
Most people using only the app store helps cut that down.
https://unit42.paloaltonetworks.com/new-os-x-ransomware-kera...
>Transmission representative John Clay told Reuters via email that the ransomware was added to disk-image of its software after the project's server was compromised in a cyber attack.
>"We're not commenting on the avenue of attack, other than to say that it was our main server that was compromised," he said. "The normal disk image (was) replaced by the compromised one."
Would make it past Apple's new notarization scheme these days?
At home I have over 8 Linux machines and the only times their fans get louder are when I am actually running a video encoding program or something CPU intensive like that. Some of them are slower with only 4GB RAM and they are always responsive.
Isn’t it basically finger printing files and intercepting IO and so the resources it uses just depends on the activity of the device not the age of the CPU
This is so true it hurts. Veracode releases an annual report ("State of Software Security"), part as marketing material, part as an industry insight leaflet. The worst offenders for software security and defect rate are, year after year, security products.
As an infosec veteran, it's obvious to me that the "industry" at large is not obeying the rules they set for others. The shoemaker's children have no feet.
Malwarebytes installs a program with elevated privileges that starts on boot and always runs in the background, and regularly sends data home - despite that it is an ON DEMAND scanner.
I have written to the company to understand this virus-like behavior, and have gotten no response.
Do you have a reason to trust them?
My reason to trust them is that they seem to be generally respected still, I've been using them for a long time and they've yet to start annoying me with dark patterns and upsells - of course that's not a super great indicator.
The problem is for a lot of jobs you don't get a choice. The employer enforces it, no dark patterns necessary. And then you end up with a computer that is 70% busy doing AV-stuff and leaving 30% for actual work.
This used to be the case, but the commercial/enterprise cloud version of MBAM (required by my company) is godawful. It seems to call out to its cloud back end every time an executable launches, and it murders performance. It's most obvious in terminals when it causes a simple command that should run in < 1 second to take 4-5 seconds.
And they are Mozilla. Imagine Indies.
The Modern Day Apple requires you to get some Mainstream Media publish about How Apple block Open Sources Software to be running on M1 before Apple saw the PR damage and start acting on it.
So, since we're an Apple developer, we decided we would use one of our DTS (developer technical support) tickets. Nope. Pre-release anything is not supported.
So, we ended up waiting for release, bought a new M1 mini and then started our porting effort. Then, we ran into problems and used one of our DTS incidents and we got some help. However, we lost months.
I've resolved to never, ever run A/V software on any machine I control based on the quality of those devs.
Note that there may be still ways to bypass it if you're an attacker sitting at the computer, rather than a hapless user.
If Apple wants to create incompatible hardware, let them put the effort & money into fixing the software, if they want the software on their platform.
Anyway, found a guy working on keyboard layout stuff at Microsoft through LinkedIn as the other support channels were non-responsive. Unfortunately he just confirmed the change if I remember correctly. But at least we knew what was coming.
I found this bit interesting. Likely more prevalent in mobile apps, but perhaps shifting desktop code to Big.Little approach and using core affinity will result in a lot less wasted energy.
https://bugzilla.mozilla.org/show_bug.cgi?id=34572
"Use native context menus on Mac OS"
"Opened 21 years ago"
Granted neither of these are deal breakers for me. I don't use Firefox b/c of pretty context menus.
Also, if you frequently use cross platform software on multiple platforms, it’s possible consistency within the app is more important than consistently with the OS.
Last time I used Chrome they pretty much reimplemented everything from buttons to modal sheets.
But also ended up completely moving out of most "native" tools for a reason or another (from TextMate to VSCode, Mail to Gmail tab, FaceTime to Skype/Meet etc.). At this point deep platform integration looks more like exceptions than the norm, for the better or worse. There are things that I kind of hate in a lot of Apple product (Safari included), which make Firefox's approach a decent tradeoff.
This is one of those rare instances of "no, it's not just different, it's actually much worse".
They link the issue [1] tracking the change which also speaks about disabling cranelift.
To my knowledge cranelift was made for the purpose of compiling WebAssembly in Firefox, so I am not sure if I am missing something here (it's not yet production ready maybe). The Cranelift README[2] mentions that it will be a backend for IonMonkey.
I am a complete layman here so I am curious if someone here has a better understanding.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1687626
[2] https://github.com/bytecodealliance/wasmtime/tree/main/crane...
Ion (nee IonMonkey) predates Cranelift, being the natural evolution of Mozilla's previous SpiderMonkey JITs. From your link:
"Prototyping work (bug 1678097) has demonstrated that Ion can generate good code quickly for wasm on ARM64, and given that Ion has good stability and we know it well, we will ship it as the initial optimizing compiler for wasm on that platform."
The keyword being "initial"; it appears to just be saying that Ion is good enough to enable, with support for Cranelift being retained in the event that it ever surpasses IonMonkey in capability.
Cranelift - experimental, quick to port
Ion - production, slow to port
So Firefox on Apple Silicon got Cranelift first, but only in nightlies, and will soon get Ion in release builds - "become the new default" means it will replace the baseline compiler.
Cranelift was originally started as a project to make a new backend for wasm in SpiderMonkey. It took on a life of its own, and has been transferred by the Bytecode Alliance (which Mozilla is a part of). At the moment it's not mature enough for us to use in production (both in terms of performance and in terms of code churn). We're hopeful that will change over the next few years, but we need to ship wasm support now, so we're sticking with our existing backend.
(We intend to keep Cranelift working behind a compile-time flag.)
I guess split-architecture applications were also not foreseen as it is clear that the auto-install prompt doesn't work very well in that case.
This is correct if you refer to how early versions of the Mac OS X installer was packaged. The Classic environment framework was always installed but a copy of Mac OS 9 was also required to be installed on the system volume as well—and this wasn't included when installing a fresh copy of Mac OS X from a CD.
There was a limited period of time when Apple shipped and installed both Mac OS 9 and Mac OS X on Macs—so for those people, the Classic environment was "effectively" installed by default. Though to reproduce this you'd need to run the Mac OS X and Mac OS 9 installers from their respective CDs.
"X% of machines have installed Rosetta on this version of MacOS" would be a useful number without measuring the specific executions.
Wait, modern browsers still download and run native binaries at the request of certain sites? How is this different from the days when native plugins like Flash were massive security liabilities? I thought we didn't do that anymore?
EDIT: I stand corrected thanks to a colleague on the media team: the EME CDM update servers are known Google servers.
Source: I'm on that team, but I don't work directly on this.
I still think the "best" answer is to untick the box that says "Play DRM Content" in the Firefox preference panes, and refuse to support corporations that would otherwise use it.
I haven't bought DRM media for over fifteen years.
Lack of rust support for 64-bit ARM was a bit surprising to me, especially given the velocity in which people have been rewriting certain components in Rust.
Take for example ffmpeg failing to compile because librsvg was rewritten in rust: https://trac.macports.org/ticket/61668
The widgeting/graphics library is actually run by something called VCL (the Visual Component Library). It's a bit of a mess to be honest, but the simplified version is that there is a class called OutputDevice that the rest of the app uses, which basically acts as a fascade over a platform specific class called SalGraphics (there are a number of other platform specific classes, SalGraphics is what I focus on here).
Basically it is a class that implements a bunch of primitive drawing functions which call on abstract functions. We then implement these functions in a platform specific class.
To see the guts of the Mac class, see AquaSalGraphics [2] - and no, none of know why it was named "Aqua"... our codebase is old.
FWIW, OutputDevice has serious issues. I have detailed them in a mailing list post. [3]
1. https://bugs.documentfoundation.org/show_bug.cgi?id=138122
2. https://opengrok.libreoffice.org/xref/core/vcl/inc/quartz/sa...
3. https://lists.freedesktop.org/archives/libreoffice/2020-Dece...
The macOS UI is called Aqua, and has been for quite a while!
Effectively blocked from releasing it for the single-digit-percentage of people who run an antivirus on a Mac.
Does anyone have credible numbers on this?
Isn't this at the wrong abstraction level? I would expect this to be a job for the OS scheduler.
Indeed while Rosetta does have support for JITs (which is really impressive in and of itself), every piece of machine code generated by the JIT has to be translated on the fly.
While the hiccup at the initial run is not too costly / annoying for a regular application being AOT-compiled in its entirety and Apple can then shove the result somewhere nearby, for a JIT it's basically constant, continuous overhead which can't be cached because it won't be around next run. I'm not surprised that the gains are significant there.
It's good to hear from Mozilla doing some browser developmenmt, and not making bizarre political announcements that an authoritarian shutdown of a social network by a cartel of tech giants is "not enough".
Nathan Froyd wrote this great blog post about compiler usage: https://blog.mozilla.org/nfroyd/2018/05/29/when-implementati...
Seems your interpretation is "does Firefox require any LLVM based compiler to compile?" and yeah. But "does Mozilla use clang for official builds?" is another valid way to parse the question.
(Mozilla does use clang, and they even do cross-language LTO thanks to that: https://blog.llvm.org/2019/09/closing-gap-cross-language-lto...)
See 2.5.6 here - https://developer.apple.com/app-store/review/guidelines/
This is why you don't get any of the features / extensions / etc of Chrome or Firefox on iOS.
Apple does this so that the mobile web can never replace apps that they have a monopoly on and get a % from. If you could just visit netflix.com and have it install a Netflix SPA that worked as well as the native app, why would you ever install the native app?
Edit after reading replies - lol, that programming of Apple users to believe "we need an app for every possible site".
Or you know, because they disallow dynamic code execution of arbitrary downloaded code in apps, and JIT JS compilers do just that.
>If you could just visit netflix.com and have it install a Netflix SPA that worked as well as the native app, why would you ever install the native app?
It's like asking "why would you ever use a native app". Because it's faster, native, and much more convenient?
Take the best desktop browser engine, e.g. Chrome, and put it inside a mobile browser app. Still, I (and most I guess) wouldn't use it to watch Netflix over individual apps.
How many care to use web based apps over native apps in Android?
No offence but what do you think applications for Web OS are written with?
No, they explicitly disallow other implementations, whether they JIT or not. Since Apple's WebKit is missing so many features, this has the effect that GP noted.
"2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript."
So, do you know people who prefer web apps over native apps for their Android, where "other browsers" are not disallowed, and Chrome is available?
I'm sure you'll find some. I doubt you'll find any significant percentage though.
I, personally, never do, and haven't seen any doing it in the wild, except for things there's not an app for...
I do. Twitter's PWA is superior to its native app, and I can customize it with extensions. I prefer mobile Firefox over mobile Chrome though.
If the experience is so much better why are Apple scared to let other browsers into the app store?
Phones are general purpose computers for the majority of the world's population, exercising such authoritarian grip over what a user can do with the device is very depressing to see being defended.
Well, the weasel word "scared" kind of begs the question.
Who said it's "scared"?
Apple spearheaded the modern browser with Safari. Chrome wasn't even a thing then (it forked off of Apple's work on Safari/Webkit later, just like v8 came after Apple's own JSC JIT work).
As for Mobile Safari, it took several years for Android browsers to come close: Android Browser in particular was a piece of crap, slower, and lacking more features, than Mobile Safari. Was Google also "scared" of web apps?
Also note that, when Apple suggested to developers they make their own web apps in lack of a native SDK, most dissed those and wanted, nay, demanded a native SDK.
And Mobile Safari is not exactly some bad browser holding those apps back. You can watch Netflix on mobile safari, on the web, if you so want. Why would you though?
And here's the 1000 pound argument: do you see many people watching Netflix on Android Chrome, as opposed to using the Android Netflix app?
Didn't think so.
Why would they do it on the iPhone then, if Chrome was available in the App Store?
>Phones are general purpose computers for the majority of the world's population
Not even close.
Safari doesn't support the standard unprefixed fullscreen API, while Firefox and Chrome have for years, so Web developers have to write a bunch of compatibility crap or accept fullscreen not working on iOS.
Firefox and Chrome have supported WebGL2 for years, iOS Safari still doesn't.
Having used an iPad for general web browsing for a while, the worst change they made was allowing web apps write their own fullscreen interfaces. I can't think of any video website where they've done a better job at basic video player controls than what the OS does natively.
>As for Mobile Safari, it took several years for Android browsers to come close...
>suggested to developers they make their own web apps in lack of a native SDK, most dissed those...
>Safari is not exactly some bad browser holding those apps back...
>do you see many people watching Netflix on Android Chrome...
Absolutely none of these points are arguments against having the option to have an alternative browser rendering engine. Not sure why you think they are.
Not sure why you think they were intended to be.
Those weren't "arguments against having the option to have an alternative browser rendering engine".
Those were arguments about "Apple not having an alternative rendering engine" is not about sabotaging some imaginary web app revolution, just about Safari having its own timeline and priorities.
Regarding that, not how there's no such web-over-native-app trend in Android either, where Chrome IS available. Most still prefer native apps.
If you think, you could also think them as "arguments not against, but as to why it's no big deal to not have an alternative browser rendering engine".
My central point was I see no reason for Apple to disallow altnernative browsers (not just shells around webkit) other than to gatekeep. Your points about safari being better or users not using a PWA for netflix don't seem to relate to this I don't think. I think Apple is only concerned about staying in control with regards to what users can install on their devices. I don't think they want other browsers to be genuine alternatives to iOS safari so they've essentially neutered the competition.
I also think you flippantly dismissed that a very large portion of the world is mobile first (not just the third world anymore) and this to me makes having the choice even more important.
What would you call a webview? Is it that much different if it is webkit or gecko or blink doing it? If I used a webview to run js-linux, xfce and firefox should that be disallowed too?
I believe it's Netflix that prefers that users use the app.
Being able to download/cache content reliably would be welcome, on all browsers. However, I haven't seen a good example of using PWAs' storage APIs to cache video content, Safari or otherwise.
Lack of push notifications in iOS Safari is a giant shortcoming. It's especially baffling since it exists for Safari on macOS. That being said, I can't say that Netflix's push notifications (in the app) are particularly useful (to me). They always spam me with newly released yet irrelevant in-house produced titles.
(Why did 3 other people interpret this comment as saying something about iOS?!)
Because originally, the comment also said "Firefox already works on apple silicon, on iOS".
Source?
> Of all the work needed to support the new hardware, porting Firefox to the 64-bit ARM architecture was not actually something we needed to do: we’ve supported 64-bit ARM on Android and Linux for years.
On the other hand, it says:
> Secondly, we needed to adapt and fix the various parts of the Firefox codebase that deal with low-level calling conventions and particularly the interfaces between the JavaScript and C++ (and nowadays Rust) parts of the code.
I suppose MacOS on ARM has a different calling convention to both MacOS on x86-64 and Linux or Windows on ARM64.
Also:
> If the user visits such a site, Firefox will automatically download and install such a proprietary EME/CDM module. This presented a problem to us as we would be dependent on those third-party vendors to publish ARM64 versions of those decoders.
So what do Windows or Linux users on ARM64 do? Do they just not get DRM?
The Windows ARM64 build of Firefox comes with a copy of the 32-bits x86 Windows Firefox binaries to launch the win32 CDM.
There is no support for things like this for Linux, and I don't think there's a native ARM64 Linux CDM (although I could be wrong. I mean, such a CDM likely exists, considering ARM64 Chromebooks)
Seems like these abstractions are not exactly zero-cost?
It's more complicated than that. I've been involved in a project (bootstrapping little-endian 32 bit PowerPC on linux) which needed a rust port. I didn't work on that, but from what I saw, it's at best a major nuisance, possibly a nightmare when something breaks. This may be a bad example since darwin/aarch64 is a more sane target, but still. ;-)
More importantly I guess, Firefox has some reeeeaally old platform specific cruft and some really rusty (hah!) ABI-glue stuff lying around. Stuff like the Netscape Portable Runtime. There's still code in Firefox from back when it ran on HP PA-RISC. There's even code for IBM Z mainframes in there. Really glossing over details, but there are some inner mechanisms that are very platform specific and need at least some custom code for each OS + CPU combo.
Mozilla _used_ to be about open internet and security, but that's just a false pretense at this point [3][4].
I believe it's time to embrace Chromium / Blink, throw away the idea of internet freedom and just use the best performing browser of the week.
[0] https://thenextweb.com/insights/2020/08/11/mozilla-firefox-l...
[1] https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[2] https://www.androidpolice.com/2020/09/03/firefox-update-face...
[3] https://blog.mozilla.org/blog/2021/01/08/we-need-more-than-d...
[4] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo...
You can use general extensions on Android in Nightly, so this is in progress: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
But sure, if you want to "throw away the idea of internet freedom" then that's your choice.
The ability to install non-store extensions got completely removed on Firefox for Android and there is (AFAIK) no hint at whether it will ever reappear. That's pretty frustrating and clearly not a win in internet freedom.
Store extensions can be used if you create a Firefox account and use their Nightly, which is really hard to justify, IMO. To me it looks like they wanted to push their account numbers and I have great difficulties to find any potential hidden greatness in this policy.
I'm not sure if you realise the ridiculousness of your statement.
I think many of your citations are used on a surface level to push your point. I don't think you considered the reasons for Chrome's dominance in the market, which is more to do with other issues such as Google's position of power than the issues you brought up here.
Chrome on Android has never supported addons, and now with Google spear heading changes such as manifest v3, I would consider these worse than decisions Mozilla have made with Firefox. You fail to mention decisions such as Mozilla's continued investment into tracking protection, which have been inheriting protections originating from the Tor Browser project.
I think the reasons why Mozilla have decided to slowly reintroduce addons to their new Android release should be considered. Their efforts to work with uBlock Origin to create a better mobile interface seems to point towards a desire for quality control, one that Google avoids with Chrome on Android altogether.
As a reference, I'm going to post the values here:
Source: Jan 2020 - Aug 2020 - Jan 2021
netmarketshare: 3.61% - 3.00% - 2.98%
wikimedia analytics: 5.2% - 4.6% - 4.7%
statcounter: 4.7% - 4.09% - 3.77%
[0] https://netmarketshare.com/browser-market-share.aspx?options...
[1] https://analytics.wikimedia.org/dashboards/browsers/#all-sit... (change date range to Jan 1 2020 - Jan 21 2021, remove other browsers)
[2] https://gs.statcounter.com/browser-market-share#monthly-2020... (remove other browsers)
https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers#...
Second, your concept of rapid decline clearly differs from mine. That is an eleven year decline and I don't think it's "rapid" at all for a browser.
For example Chrome ships with an x64 version of Widevine, a plugin that is required to watch live streams on YouTube TV (and perhaps other services with live TV). Currently, YouTube TV does not work natively in Chrome or Firefox.
All that said, it will work fine if you run Rosetta -- the x64 decoder will run in Rosetta.