Barrier has been abandoned quite awhile ago. Its successor is supposed to be InputLeap, and although their GitHub repo is very active, they have yet to make a release.

I didn’t even know that Synergy provided a “community” version of their app until very recently. I’ve paid for a license many years ago, so I’ve been using their 1.1x versions, which for better or worse, are still maintained along with the 3.x branch (which I’ve tried using but could never make it work, which is for the best because the fact they pivoted their UI to electron-based also left a bad taste in my mouth).

Edit: also, if I understand correctly, Synergy’s latest versions on the 1.x branch borrows a lot from InputLeap.

Not a variant. Read their README. It IS Synergy, they’re renaming the open-source / community version to that, while Synergy will remain the commercial product built out of that.

Here. Tl;dr: He took it private for reasons, should bring it back in a “build it yourself” form later.

Apparently it’s not that the software is broken, it’s that the software being installed breaks Windows Update. There are reports from people that uninstalling StartAllBack, updating the OS, then reinstalling it back (renaming the install executable first) works fine.

As much as being affected by this is frustrating to me (though this is all happening still on the dev channel, so for me it’ll be a problem for the future), I understand Microsoft’s rationale here. They can’t be expected to support every third-party tool that can break the OS, and it’s known that both ExplorerPatcher and StartAllBack relies on many hacks using undocumented APIs to work.

In the last few decades that I’ve been using Windows, I never felt compelled to use shell replacements or customizations - the default experience always worked fine for me with a few tweaks. So, if anything I’m more frustrated at Microsoft that I’m forced to use StartAllBack, because MS went and removed options from the shell that existed forever and always took for granted, and then some.

Thank you for digging this out. Turns out it’s even worse than what I gleaned from my surface-level take.

This sounds like dev sour grapes but what the company was asking them to do seems better from the customer pov and for cyber security I’m general.

As a developer myself (though not on the level of these guys): sorry, but just, no.

The key point is this:

[…] we did not issue CVEs for experimental features and instead would patch the relevant code and release it as part of a standard release.

Emphasis mine. In software, features marked as “experimental” usually are not meant to be used in a production environment, and if they are, it’s in a “do it at your own risk” understanding. Software features in an experimental state are expected to be less tested and have bugs - it’s essentially a “beta” feature. It has a security bug? Though - you weren’t supposed to be using it in a security-sensitive environment in the first place, it sounds perfectly reasonable to me that it should be addressed in a normal release as opposed to an out-of-band one.

We can argue if forking the project is or isn’t extreme, but the devs absolutely have good reason to be pissed. This is typical management making decisions without understanding technical nuances and - from what is being told by the devs - not talking it through before doing it.

Chromium-based browsers still trounces Firefox on the Jetstream benchmark. I mean, I realize the Speedometer benchmark is supposed to test real-world scenarios, while Jetstream is more synthetic, but whatever work mozilla did to improve performance I’d expect to scale in other benchmarks too, so I’d expect Firefox to at least be bit closer to Chromium, even if losing a little.

Fair enough! FWIW, I also think your stance on the matter is fairly level-headed and well thought out, even if I’m more or less on the other side of the fence.

While I personally do not think that all Chromium browsers (especially since there are projects like ungoogled-chromium) transmit your personal data, I can’t verify this myself because the Chromium codebase is far too much of an undertaking for myself to review.

Don’t you think that, with so many contributors and projects having eyes on it (arguably more so than on gecko), if there was foul play wouldn’t anyone have sounded the alarm?

Lemmur is unmaintained.