Based on the experiences of systemd, gtk, and X11 in switching to Meson, I'd think Meson might be the best choice here. While Buck, Bazel, Pants, etc. are designed for large projects, Meson is designed for small-to-medium-size projects and integrates with pkg-config, which in turn should provide simpler integration with distribution package managers. My experiences with Bazel demonstrated that integration with distribution packages can be quite difficult.
Seeing as the screenshots are from Gnome, I'd be surprised if they used X11, considering Gnome's future is on Wayland. Not to mention the irony of shipping a "secure phone" with X11...
Their UI looks like it's based on Gnome -- I wonder if they wrote some extensions to make Gnome more phone-friendly.
IMO great idea to use Matrix as the communication layer -- especially when double-ratchet is stable, it'll be able to provide the good UX of things like Signal on Android, iMessage, Google Duo, and FaceTime, but built on an open platform. Hope it does well!
You don't even need the whole web platform to build these sort of UIs -- in theory, you could use the WebRender engine to render CSS-box-like UIs. You could avoid some of the weaknesses of the web platform like the memory-heavy DOM.
I think this would be an excellent target for a React Native-like framework for desktop, as it would support the full generality of CSS with excellent performance.
Firefox must continue to exist if we are to have any browser without an economic incentive to be user-hostile. If they need performance traces from websites, and they have an open, clear discussion of how to preserve as much user privacy as possible, they should collect them.
This is a reasonable compromise, but it does bias the sample towards popular sites. Granted, many of these sites are the sites that Firefox struggles with, but browsing habits are a heavy-tailed distribution. That said, smaller sites do open the door for problems, so it's probably a workable compromise.
EDIT: It should also be completely disabled in Private Browsing mode -- otherwise the optics are even worse than they are now.
This data will be used in the pursuit of #2. As it turns out, a lack of understanding of what users are doing with their browsers is an obstacle to making a better browser. Performance issues in complex systems often only show up in production, and that's what Mozilla is trying to collect this data to fix.
Samsung actually has a decent track record of updating their software -- my family's Galaxy S5s on T-Mobile (purchased 2014) are actually still receiving security updates, despite being on Marshmallow API level.
They won't delay it since they've already begun breaking the old XUL extensions API in order to make room for new improvements. This is getting quite tiresome at this point -- extension devs have had over a year to port. If the extension devs are targeting Chrome too, it's easier to use WebExt than XUL anyway, and if they haven't spent this time to engage with Mozilla about expanding the WebExt spec so their extension is not possible in WebExt, the fault lies with the extension dev.
I once read that for this reason, many people send screenshots instead of links - so others don't have to reproduce the right sequence of closing ads, etc to show the content the user is interested in sharing.
Wonder if they could embed the Tor proxy into the apk, that way it would be completely transparent -- no need to download Orbot whatsoever. This might also work for iOS
I like and use Orbot, but requiring it isn't the greatest UX.
Technically, Apple does not have a monopoly, unless you want to argue they are the monopolist of the market for iOS devices. They don't even have a majority market share of smartphones in most jurisdictions.
That being said, I still believe it is an abuse of market position, and I'm not sure how we can fight it.
Yes! This has been my view on Rust for a while -- it's a relatively inexpensive way to boost productivity and general security of projects. This is especially true when the alternative is formal verification, which is less ergonomic than Rust and effectively would require a rewrite of C code anyway.
I've written awful Rust code myself, and I'd still rather be writing Rust than C++, because sticking to Rust idioms makes it harder to do the wrong thing without it being obvious.
My personal opinion on this is that Docker's application of Linux namespaces+cgroups happened to solve a specific problem - reducing differences between prod and dev and doing stateless deployment - in a way that is pretty simple and didn't break people's expectations for how Linux works. Prior to that, namespaces and cgroups didn't have a "killer app".
Excellent -- Meson is so much clearer than the alternatives. It has the advantages of Bazel and similar (Pants, Buck), but seems more geared toward smaller projects, which is great for those of us not using a mono-repo.
To add to this, Google spent a lot of time and effort on building a custom build system (Bazel) to make this sort of dependency tracking in a mono-repo easy. It's pretty great, and I'd rather write BUILD files than Makefiles/shell scripts any day, but the OP appears to have been focusing on extremely simple projects, where shell scripts are okay.
You can start now by filing issues with your favorite extensions, trying to see if WebExtensions is on their radar. If so, they'll lobby Mozilla's WebExtensions group to get the missing features implemented.
At the beginning of this thread, the main dev states interest in migrating to WebExtensions, then cites all the bugs that prevent that. Towards the end of the thread, an extension dev (`nt1m`) states that the APIs have been approved, and simply need implementation in Firefox. There's definitely a chance they won't make it into 57, but the rapid-release cycle will help them land in a release not too long after 57.
If TST is essential to your workflow, you may wish to consider using 52 ESR until these APIs are finished in mainline, or contribute implementations of the APIs (time permitting, of course).