• 0 Posts
  • 40 Comments
Joined 1 year ago
cake
Cake day: June 4th, 2024

help-circle


  • You might have a point if those people had no choice

    Yes exactly and I may haved leaned on that a bit to make my point here. I worked at an MSP where 90% of their clients had the exact setup I mentioned, so workers had no choice but to run TeamViewer. The company would refuse any other recommendations specifically because it had already paid for a number of perpetual licenses and (at least at the time) free alternatives were limited. It was really awful even back then (~2015ish).

    And for what it’s worth, I also agree that TeamViewer is an awful company and the software itself is awful, and of course if you can help it don’t fucking use it today lol.


  • The argument is that anyone still using TeamViewer deserves this, and anyone who isn’t isn’t actually impacted bym this change so it’s irrelevant.

    That’s your argument, and I disagree with it. I’ve already shared why.

    and anyone who isn’t isn’t actually impacted by this change so it’s irrelevant.

    This is also wrong. Having the license revoked means the people who had one can’t use it at all whether they were using it or not. Let’s set aside that you shouldn’t advocate or endorse a company selling a product, shitting the bed, then revoking the product from those that already paid for it.

    You’d be surprised, but there’s tons of small companies and organizations that rely solely on viewing software, some ancient version of Windows Server, and a remote toaster for administration still to this day. Those people are directly impacted by this.

    I don’t think they deserve a license revocation because I don’t think any company should be able to take back a product that a user has purchased for no cited reason. Which is the case here.



  • It doesn’t matter when they purchased the license because the fact they’re still using it means they deserve it

    Sure it does. I have a Jetbrains perpetual license that I use daily. If they suddenly started enshittifying, and then decided to revoke my fallback licenses in 10 years, they’d be up for a number of lawsuits because that’s illegal.

    End users don’t deserve to have their licenses revoked because a company went to shit over time. They’re in no control of that. And I made 0 arguments about people using Teamviewer today because that was never part of my point.


  • Anyone that isn’t deeply investigating the company or individual making a remote access product prior to using it does deserve what they get in the same way someone handing the keys to their house to a complete stranger they know nothing about would deserve whatever happened to the

    I’ve already agreed with this opinion:

    I’d agree if this post was about Teamviewer being breached once again. In that case, yes the end users who have stuck with them throughout numerous data breaches have very little room to complain when it happens again.

    But it feels like you may have missed my actual point. Again, this post is about a change to perpetual licensing. People that purchased their license back when TeamViewer was a proprietary alternative to VNC, long before it became obvious that TeamViewer wasn’t a great company, (think 2008), don’t suddenly deserve licensing changes. Hard stop. These are the users that are affected the most by this change because they’ve held their perpetual licenses the longest. In addition, TeamViewer stopped selling perpetual licenses years ago, so the bulk of users with one today are likely to be older users. Why do they suddenly deserve this?


  • negligence doesn’t mean they deserve it

    This is why I asked in the first place; negligence == they deserve it seems to be the basis of everyone who has replied to me lol.

    It’s also weird to me because everyone is citing awful data protection (numerous data breaches, and even your link to easily compromised credentials) as the reason end users deserves their Licenses being revoked.

    I’d agree if this post was about Teamviewer being breached once again. In that case, yes the end users who have stuck with them throughout numerous data breaches have very little room to complain when it happens again. But this is a Licensing change. It has nothing to do with their shitty data protection practices.

    Further, these are perpetual licenses. It’s very likely that many of them were purchased years ago when Teamviewer was a lot more popular. To say that people deserve their perpetual licenses getting revoked because a company enshittified over time is silly buddy.











  • I don’t develop distributed applications, but Im not understanding how it simplifies dependency management. Isn’t it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

    That’s correct. This simplifies the dependency management system because not every distribution ships with every version of every package, so when software requires a version of a package that the distro dosesn’t ship with or have in its repositories, the end user has to either build the package from source, or find some other way to run their software. Flatpaks developers will define the versions of dependencies that are required for an application to run and that exact version is pulled in when the flatpak is installed. This makes the issue of every distro not having every version of every package moot.

    Don’t maintainers have to release new bundles if they contain dependencies with vulnerabilities?

    They don’t have to, no. But they absolutely should.

    Is it because developers are often using dependencies that are ahead of release versions?

    Sometimes, yes. Or the software is using a dependency that is so old that it’s no longer included in a distro’s package repositories.

    Also, how is it so much better than images for your applications on Docker Hub?

    I would say they’re suited to different purposes.

    Docker shines when availability is a concern and replication is desired. It’s fantastic for running a swarm of applications spread across multiple machines automatically managing their lifecycles based on load. In general though, I wouldn’t use Docker containers to run graphical applications. Most images are not suited for this by default, and would require you install a bunch of additional packages before you could consider running any graphical apps. Solutions to run graphical applications in Docker do exist (see x11docker), but it doesn’t really seem like a common practice.

    Flatpaks are designed to integrate into an existing desktops that already have a graphical environment running. Some flatpaks include the packages required for hardware acceleration (Steam, OBS) which can eliminate the need for those packages to be available via your distro’s package manager.

    What this means is that a distro like Alpine Linux that doesn’t have an nvidia package in its repos can still run Steam because the Steam flatpak includes the nvidia driver if you have an nvidia GPU installed.

    Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it’s something I should adopt, or if I can continue to blissfully ignore.

    ¯_(ツ)_/¯ It’s a tool. Use it when it’s useful, or don’t.


  • They have individual people maintaining over a thousand flatpacks.

    I don’t believe this to be the case with Flathub, only the Fedora repo. I’m asking about the wider flatpak ecosystem, not the fedora-specific repo or how it’s setup.

    Additionally, if you go to install the real flatpack, Fedora pushes you to use their poorly-maintained unofficial one instead.

    I’d agree that seems like a needless hoop at the very least, but my concern is more to do with the growing trend to shit on Flatpaks as an ecosystem, not just this particular instance of Fedora head-assery.

    I think it’s decent software and has really solid use-cases, far from unreliable shit at least in my own anecdotal experience. But my experience is limited, which was why I asked the OP to elaborate on actual flaws they see with the Flatpak ecosystem.