I would've guess so, but I was talking about it in a "does Claude Code (not the model) have access to the internet?", which, according to Anthropic, it didn't.
It is a bit vague, but I think that this means that you aren't going to be able to use Animate altogether after 01/03/2027.
> Access to your Animate files and project data will end on the date that support ends. To ensure a smooth transition, we encourage you to export your Animate FLA and XFL files to other formats such as SWF, SVG, and MP4 before this date.
The fact with Software-as-a-Scam subscription stuff discontinued software doesn’t just mean "it'll probably bitrot away over time" (probably a bit more aggressively with MacOS than Windows) to "it'll just be gone" is kinda mad. See also Microsoft Publisher. These are supposedly professional tools, surely they can still make it available with a "YMMV" disclaimer so they don't leave their own customers (and their work) in the lurch.
To add insult to injury, the obvious path is for studios to switch from Adobe to ToonBoom... which already copied Adobe's playbook by going subscription-only last year.
Some news outlets did report on it. However, in my experience after testing the patch applied on top of Wine 11.0, both the Creative Cloud and the Photoshop installer did not work.
I suppose that the thing that the patch fixes is the "offline" Photoshop installers, which are not provided anymore unless if you ask Adobe nicely... or if you get it from third party sources. The PR's creator did say that they didn't pay for Creative Cloud, so I think it is likely that this is what happened.
This made me wonder if anyone had actually tested the patches with a legit Creative Cloud/Photoshop installer, or if everyone just ran with the PR saying "look it works now!!!" but nobody bothered to actually test it. The creator did submit their own precompiled Wine version, however that version is meant to be run via Proton, so I wasn't able to make it work because I don't know how to run things via Proton outside of Steam.
I was able to get the Creative Cloud app in Wine (set to Windows 10 mode) by using some very dubious methods, as in, I asked Claude Code to implement the stub to see what would happen because if AI is sooo good as how people are saying, it should be able to fix things in Wine... right? And surprisingly, it did actually work.
However you aren't able to use Photoshop CC 2021 (the earliest Photoshop version you can install from Creative Cloud, newer versions crash during startup) because the activation popup does not render the input controls. The reason why I think it is trying to render something is because the activation popup background does have the same color as the Adobe website and, if my memory is correct, in Windows that popup is used to ask for your Adobe account credentials.
(Sadly the PR patch does not fix the activation screen)
Of course, if you bypass the activation using... alternatives means, Photoshop CC 2021 does work under Wine, which is why you can find a lot of "Photoshop CC 2021 in Wine!" repositories on GitHub.
You know what's weird? You being late by 3 days and not bothering to read the comments on reddit [0], then going ahead and trying a Wine 10 patch on Wine 11. Like, what exactly did you expect?
Edit: Even worse, other people are finding it easier to get creative cloud to run on older wine versions [1], meaning that there are regressions in Wine that aren't being spotted.
Edit 2: Worse yet, people aren't pirating Photoshop, they copy the files of a working activated Photoshop installation from Windows so they can run it under Wine [2].
> then going ahead and trying a Wine 10 patch on Wine 11. Like, what exactly did you expect?
You can copy the PR's diffs and apply it on Wine 11.0, it is not like it doesn't work or that OP patched functions that are only available in Proton.
Seeing that people actually got it to work gets me intrigued, sadly they didn't say if they actually used an official Creative Cloud license, or if they downloaded it from the web from third party sources. Because, as I said before, the installers that OP used are not the installers you normally get from Adobe. So, if you know where OP got the installers, please share. :)
Now, it could be that Proton somehow has something else that fixes the installers, or that there is a regression between Wine 10.0 and Wine 11.0 that breaks the creator's patch. But like I said in my own posts that I linked, I can't find the exact installers that OP is using. The only time I've seen similar installers was when I was downloading pirated Photoshop copies to test it out on Wine.
> Even worse, other people are finding it easier to get creative cloud to run on older wine versions [1], meaning that there are regressions in Wine that aren't being spotted.
I don't think it is a regression. Hear me out:
The user was installing Photoshop CC 2023 with a installer similar to OP's installer, so I suppose that the installer also installs an older Creative Cloud version.
Maybe that Creative Cloud version does not require the stubbed function, nor does it require WebView2.
To get the RECENT, downloaded right off Adobe's website Creative Cloud installer, you will need to install WebView2 on your Wine prefix and set "msedgewebview2.exe" to Windows 7 mode. This makes the Creative Cloud work up until it tries to start it, which makes it use the stubbed function.
To workaround that, you can set Creative Cloud to Windows 7 mode, because that forces a different code path in the app which does not use the stubbed function (SetThreadpoolTimerEx was only added in Windows 8). However, this makes all apps show that it is "incompatible on your system", so you can't actually install anything from it.
My own patch DOES fix Creative Cloud in Windows 10 mode, so you are able to install Photoshop directly from Wine.
However, the patch (nor OP nor my own patch) fixes Photoshop's activation. And let's not rule out that maybe it IS actually a regression.
> Worse yet, people aren't pirating Photoshop, they copy the files of a working activated Photoshop installation from Windows so they can run it under Wine [2].
I'm not sure why you think that linking MattKC's post is a "gotcha", when I explicitly linked that post on my Reddit post AND MattKC's post also says that you need to bypass activation with GenP. So you aren't activating the application in Wine, you are bypassing the activation altogether.
But maybe you didn't notice that because I've only noticed now that my markdown was broken, because I included "(archived link because MattKC's forum is down)" within the URL by mistake, so the link didn't actually work, whoops. I've fixed that now.
I never said that Photoshop doesn't work in Wine. I said that it does work as long as you bypass activation with external tools. If you are using a legitimate copy from a Windows machine, or if you installed it via CC on Wine, or if it is a pirated copy, it doesn't matter, you WILL need to bypass the activation somehow. Which is the point I made in my post.
> The guy who claimed to have fixed creative commons has posted an update
That update was made after my post, and the installers on the creator's post are STILL not the same installers that you can get downloading from Adobe.
Unless I'm missing something and these installers can ACTUALLY be downloaded from Adobe, because I couldn't find them anywhere and the ones that I get from Adobe's website are the ones that I shared the screenshots of on my Reddit post.
___
Now, if you want to prove me wrong, please go ahead and try the creator's patch and try installing the Creative Cloud app, downloaded directly from Adobe's website.
I really want to be proven wrong because it would be really cool if you could get the Creative Cloud app + Photoshop working in Wine without needing external activation tools.
To be SURE that I'm not "misrepresent basically everyone involved": Right now I tried the Proton build the PR creator made... and Photoshop still does not work. It shows the activation screen with "Loading..." written on it (sometimes it is just a blank box). https://i.imgur.com/QN2rxoO.png
You also aren't able to install Creative Cloud with that fork, the Creative Cloud installer gets stuck on a loading loop, so I needed to copy my Photoshop + Creative Cloud installation from my other Wine prefix.
This is not me throwing the PR's creator to the curb, it is impressive that they were able to fix the installers, even though they aren't the "main" installers, and I'm pretty sure that the PR creator could fix the activation screen too, because I think the issue is similar to the ones they are fixing, they probably just didn't do that yet because they don't know the activation screen is also borked.
Because I really want to be proved wrong, I tried using the patch creator's pre-compiled build with umu-launcher. However I couldn't get it work because umu-launcher kept complaining about a missing container runtime after I set the PROTONPATH to the pre-compiled build. It also did not work with umu's default Proton fork (it did run something, but even after I tried starting winecfg with umu, it just didn't do anything)
This is probably a skill issue on my part, so someone smarter than me could try getting it to work.
Because after using umu it sets up all of the override DLLs on my Wine prefix, I've tried running the Wine build directly, and I must say that the Photoshop GUI DOES render way better here, however the activation screen is still a empty white box (sometimes it does show "Loading..." in the box): https://i.imgur.com/Jxnga5W.png
But when doing this, the Creative Cloud app does not work anymore, it says that it needs to be repaired, but it fails to be repaired. https://i.imgur.com/jdQeU4t.png
This is very scuffed, maybe I should try Lutris and see what happens
Again, I really want to be proven wrong and it would be amazing if someone that ACTUALLY made it work with a PAID Creative Cloud license and used Photoshop CC 2021 WITHOUT bypassing its activation shows up and says "hey look, I got it to work and you are just stupid".
> Of course, if you bypass the activation using... alternatives means, Photoshop CC 2021 does work under Wine, which is why you can find a lot of "Photoshop CC 2021 in Wine!" repositories on GitHub.
> Oh!, and the one thing I miss is Affinity Designer.
While I haven't experimented with it that much yet, Affinity (the new one, the one after the Canva acquisition) does work in Wine 10.20.
Now, I won't say it is a smooth experience, one of the workarounds that I needed to do is use Wine's virtual desktop so Affinity's tooltips are rendered correctly instead of being pure black, and the GUI does seem to not render correctly sometimes (it renders as white until something causes a redraw).
This makes you wonder: How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?
> How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?
First 80% of a job typically takes 80% of the allocated time. The last 20% of a job typically takes another 80% of the allocated time.
> This makes you wonder: How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?
CodeWeavers (developers of CrossOver and one of the main contributors and sponsors of Wine and related tools) actually offer something like this as a paid service for companies called PortJump:
Getting it running in linux is the easiest part dev wise.
It is the rest of the iceberg that causes problems.
- You need your support to be able to support linux which means they will need training and experience helping people in an entirely new system
- Linux comes in finite but vastly more combinations than OSX and Windows which means you are probably going to need to pick something like Ubuntu or struggle with the above
>- Linux comes in finite but vastly more combinations than OSX and Windows which means you are probably going to need to pick something like Ubuntu or struggle with the above
This is easily solvable by distributing the app via a distro agnostic mechanism, like as a Flatpak or AppImage. Using Flatpak also eliminates the need for rolling their own app update mechanism.
But most of those issues are because Linux doesn't have enough market share. No one brushes off Windows because they need to support Windows and they need to add CI/CD for Windows.
The combination issue is a real issue though that (as far as I know) is mostly solved with Flatpaks, or in case of games, by using the Steam Runtime.
Of course, it is a "chicken and egg" problem of "we don't want to support Linux because there aren't enough users using it" but "we don't want to use Linux because there aren't enough business supporting it".
Thankfully with improvements in Wine the need of having "native" Linux support is shrinking, but at the same time there is still a looooong way to go (like the issues I said before with Affinity).
Windows userland compatibility is outstanding. I can run most 30 year old Windows applications on Windows 11 without a problem. This makes it easy for a commercial vendor to support their applications on Windows.
The same is not at all true on Linux.
Right now at work, I’ve got a bunch of commercial apps built for RHEL9 for which I’m chasing vendors for new builds that work on RHEL10, for a variety of reasons. Dependencies like libXScrnSaver have simply been removed, and so apps linked against that library no longer work.
Wine has some gaping holes in some of its API implementations. Direct2D, for instance, has existed since Windows 7 but is badly implemented in Wine -- there is no antialiasing and the ArcTo() function draws a line. The MS documentation is not that great either, so fixing Wine isn't necessarily easier than porting to native.
Yeah, I thought that Affinity would work pretty well in Wine because I've seen a lot of people pointing to the "just follow the guide (AffinityOnLinux repo) and it will work!" but in my experience it didn't work that well as people were saying.
And the guide itself seems to be outdated, the guide says that you need to install some stubs/shims but doesn't say that happens if you don't do it (I think that it would crash) but at least in my experience it did "work" without them when using an up-to-date Wine version.
Sadly Photoshop also doesn't work, if you want to follow the rules and use Creative Cloud it won't work at all, if you decide to sail the seven seas and download an older Photoshop version it will work but it also has some annoying bugs (sometimes the canvas doesn't update after an edit until you try to do another edit).
Don't get me wrong I do think that Wine is an amazing project and I hope that it continues to improve, but sometimes people don't seem to actually point all the issues that it exist when running an application in Wine.
> This makes you wonder: How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?
I've had cases where running an app under wine worked better than the native linux port :/
I have something similar on my website, and my solution was to make server driven modal/toast responses.
Allow the server to return a modal/toast in the response and, in your frontend, create a "global" listener that listens to `htmx:afterRequest` and check if the response contains a modal/toast. If it does, show the modal/toast. (or, if you want to keep it simple, show the content in an alert just like you already do)
This way you create a generic solution that you can also reuse for other endpoints too, instead of requiring to create a custom event listener on the client for each endpoint that may require special handling.
At the time I used headers to indicate if the body should be processed as a trigger, due to nginx header size limits and header compression limitations. Nowadays what I would do is serialize the toast/modal as a JSON inside the HTML response itself then, on `htmx:afterRequest`, parse any modals/toasts on the response and display them to the user.
> Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.
And why would that differ from React?
When I was building a website with React, I needed to model a "apply coupon" endpoint with different states (coupon applied, coupon does not exist, coupon exists but has reached its max usage limit) and it was so annoying because you needed to
1. The backend route that returns JSON with a different model depending on the coupon state
2. The JSON models for each response type
3. And then on the frontend you need to load the data, parse the JSON, figure out which "response state" it is (http status code? having a "type" field on the JSON?) convert the JSON to HTML and then display it to the user
In my experience it added a lot of extra "mental overhead". It is something that should be extremely simple that ends up being unnecessarily complex, especially when you need to do that for any new feature you want to add.
When using htmx, a simple implementation of that would be
1. A backend route that returns HTML depending on the coupon state
2. Some htmx attributes (hx-post, hx-swap) on the frontend to make the magic happen
Don't get me wrong, there are places that you wouldn't want to use htmx (heavily interactive components) but that's why htmx recommends the "islands of interactivity" pattern. This way you can make the boring things that would add unnecessary complexity when using React with htmx, and then you can spend the unused "mental overhead" with the interactive components. (which, IMO, makes it a more enjoyable experience)
At the end of the day it is just choices: Some people may prefer the React approach, some people may prefer the htmx approach. All of them have their own upsides and downsides and there isn't a real answer to which is better.
But for my use case, htmx (truth to be told: I use my own custom library that's heavily inspired by htmx on my website, but everything that I did could be done with htmx + some htmx extensions) worked wonderfully for me, and I don't plan on "ripping it all out" anytime soon.
I haven't checked Hetzner's prices in a while, but OVHcloud has dedicated servers and they do have dedicated servers in the US and in Canada (I've been using their dedicated servers for years already and they are pretty dang good)
