• 0 Posts
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle
  • 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.







  • 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.



  • 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.






  • Same here. In fact, I bought my Legion (which btw I feel like it was a good choice on OPs part because I believe Lenovo’s laptops tend to have better cooling engineering in general, for whatever laptop category, compared to other brands) to serve first as a work laptop, and then some gaming on the side, which I’m not too picky about because I don’t really play on PC that often anyway. My reasoning for that is that the business laptops I had been looking before going with the Legion were frankly overpriced crap with limited expandability, shoddy components and build, and full of built-in bloatware pre-installed. I find that gaming laptops tend to have higher quality components and slightly better expandability, so it was a win all around.




  • 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?