>"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."
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
20 years ago Google would have sent someone to Mozilla HQ for a week to work on stuff
> 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.
So it's hard to tell if the size of the vendor is the issue here.
I've resolved to never, ever run A/V software on any machine I control based on the quality of those devs.
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.
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.
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.
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.
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".
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.
I believe it's Netflix that prefers that users use the app.
> 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)
(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?
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.
"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?
Source: I'm on that team, but I don't work directly on this.
EDIT: I stand corrected thanks to a colleague on the media team: the EME CDM update servers are known Google servers.
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.
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?
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...
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.
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.
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#...
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...)
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...
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.)
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.
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
Isn't this at the wrong abstraction level? I would expect this to be a job for the OS scheduler.
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!
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".
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.
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.
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.
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.
.png){kind=link}