Hey OP, I'm curious about the accuracy of this quote:
> When the tool is gone, the model cannot “hallucinate” a diagnosis because it lacks the “form” to reason and write it on.
What's to stop the model from just hallucinating an entire tool call, or result of the tool call? If there's no tool available it could just make up the result of one, and then further context would treat that as a source of truth. Maybe if you threw an explicit error message, but that still feels like it would be prone to hallucination.
You are learning an entirely different operating system. You're going to have to make some choices and do some research/learn new things. There will be challenges because it's something completely different from what you know.
The entire point of Linux is there isn't just one Linux, having centralized control of an OS is how Mac and Windows ended up so godawful.
As time goes on the UX will continue to improve (through targeted distros) for less sophisticated users, but we're realistically only now at the point where everything in the ecosystem is "good enough" for a large number of people.
I've been using Linux on and off for a decade+, and it's a moving target. There is one Linux kernel, they can make one Linux OS. (and ofc people can fork but it should remain niche)
Meanwhile I can go on Windows after years and still know how to use it. Last version I daily used was 98, but 11 is still intuitive (despite being annoying).
Running ComfyUI or _any_ AI stuff on Linux is a night and day difference in terms of ease of use and performance when compared against that of Windows users. Python on Windows is suffering
The pain I’ve experienced running ComfyUI on windows is from (1) pytorch and the complexities of managing it through pip when python’s platform concept doesn't encompass CUDA versions, (2) dependency conflicts between custom nodes (some of which also involve #1 because they pin a specific pytorch version as a dependency), and (3) gratuitous breakage in ComfyUI updates.
You are not entitled to play the game, which is hosted on their server which requires bandwidth and other resources. In the same way that you are free to make demands about how software runs on your machine, the author is free to make demands about the use of their software.
It is trivially easy to filter this with an LLM or even just a basic CLIP model. Will it be 100% foolproof? Not likely. Is it better than doing absolutely nothing and then blaming the users? Obviously. We've had this feature in the image generation tools since the first UI wrappers around Stable Diffusion 1.0.
Windows users: Linux is too complicated, you have to configure too much stuff and eww command line
Also Windows users: I downloaded this massive collection of registry tweaks and PowerShell scripts that I have to run as admin after every update to undo whatever fresh fuckery Microsoft just forced on me. And there's no guarantee that it won't all be undone with the next update.
I'm being facetious to make a point, but it's always amused me how much effort you have to expend just to keep a moderately sane experience.
Software should adapt to the user, not the other way around.
You've got nothing to lose by trying but time. Time spent learning something new is certainly better than time spent trying to regain control of your OS and workflow after another mandatory "improvement".
Oh, I've run Linux on the desktop before all right, for years. I eventually decided, at the time, that Windows was drastically better at "just working" for desktop applications and it wasn't worth the bother.
Now, though, Microsoft's antics with Windows 11 is starting to make me think that might not be the case anymore.
The incentives for improving Linux are driven only in part by commercial interests, and those interests are not completely centralized. Windows' fate is entirely in the hands of the current Microsoft leadership, and they seem hellbent on extracting maximum value from their users while ignoring the suffering their "Continuous Innovation" creates.
It's almost as if they want everyone to start looking for the exits, and thankfully Linux is finally at the point in its maturity on desktop to start attracting power users who have no prior experience.
I don't think 2026 is the year of the Linux desktop, but it does feel like we're at the start of a big shake-up in the industry. Once we start seeing the hockey stick pattern in the adoption rates I would expect that more money and developer time will follow to help smooth out the areas where the transition is still difficult, like professional software.
If the heavy WINE support continues, there will never be a Year of the Linux Desktop because all software will continue to be perpetually Win32 -- OS/2 already proved out this path of [full] compatibility.
>OS/2 already proved out this path of [full] compatibility.
it is not the 1980s anymore. majority of apps are for better or worse in the browser or cross platform with electron.
Wine is merely a stepping stone for adoption because some software compatibility is a hard requirement for user to even considered another platform as an alternative, without these user there won't be any native development to begin with proven by the failure of the original steam machine.
Not all software is for consumers and a good amount runs a hardware as a whole product. 2026 will be the year moving from Windows IoT / embedded to Linux as the host OS for the solutions I work on.
Personally, I find software more stable when coding on Linux and making Windows changes after it is operational. Windows takes more work with edge cases than Linux, BDS, and macOS.
Windows treats STDIN and STOUT different between console and GUI. All other OSes that I have worked on threat them the same.
Note my comment was "Linux on the Desktop", not "Linux on Embedded".
It's quite obvious that not all software is for one platform or another. It's just the vast majority of Desktop software happens to be Windows. And if that's what you're writing, targeting Win32 gets you Linux on the Desktop as well as Windows. There's no reason to write a Linux-native version and have to deal with all of the incompatibilities across distros, let alone compatibility issues over time.
That is a subjective statement. We are moving our software off Windows to Linux hosting for our products. Microsoft has made Windows hostile to the embedded market. They are are pushing a Microsoft account over local with their IoT while plugging the hacks too.
It's difficult to compare embedded to desktop. It's not a market Windows does well today with the available alternatives. And yeah, if you're embedded, by definition you're resource constrained so running Wine makes less sense.
Not so with run-of-the-mill desktop software, games or otherwise.
These studios have profit margins in the multi-millions, they could afford a symbolic $100k donation. Instead they choose to push their developers through another crunch cycle.
> When the tool is gone, the model cannot “hallucinate” a diagnosis because it lacks the “form” to reason and write it on.
What's to stop the model from just hallucinating an entire tool call, or result of the tool call? If there's no tool available it could just make up the result of one, and then further context would treat that as a source of truth. Maybe if you threw an explicit error message, but that still feels like it would be prone to hallucination.
reply