The most remarkable things about this announcement:
- Electron based app: Electron is a framework sold on the basis of enabling rapid cross-platform development at the cost of performance.
- Frontier AI company: AI is sold on the basis of enabling rapid development
- App was released in February & took 6 entire months to port to Linux
I guess it's easier to solve Erdos problems and improve the lower bound of the Riemann hypothesis, than it is to solve Linux desktop app distribution.
LOL!
Though as someone who shipped commercial software on Linux, it wasn't that bad, you just had to ship everything other than the kernel.
LOL. Conveniently, electron is everything other than the kernel. Also, as much wasted RAM as an entire second instance of chrome that shares nothing, but oh well.
> LOL. Conveniently, electron is everything other than the kernel. Also, as much wasted RAM as an entire second instance of chrome that shares nothing, but oh well.
Well, with RAM being so cheap, why bother trying to trying to be memory efficient? It's not like OpenAI has an infinite pool of "AI" software engineers to work on this...
Oh wait...
Yeah, but if you use Qt like I did, you're shipping libstdc++, some other crap and Qt.
Yeah, I was kind of surprised recently that there's no solid native way to build desktop apps on Linux! I was thinking I'd build something actually native with AI but then the options were QT or or gtk...
Qt is as solid as it gets. It's very, very high quality. Much higher quality than Microsoft's frameworks on Windows.
Well yes, I was surprised by the situation in Windows too! So my stack is now split like this
- Apple: SwiftUI/AppKit
- Android: Jetpack
- Windows + Linux: Avalonia (C#)
Avalonia seems good so far. I couldn't do Qt because I can't deal with that qBittorrent look. GTK is aesthetically pleasing for me, but it only runs on Linux. Avalonia lets me target both of these UI-toolkit-less platforms with something native-ish. Flutter is probably good too, but I am using uniffi-rs and that doesn't generate Dart bindings AFAIK.
Would love to hear other options.
Isn't Qt themeable? I also recall at one point they "emulated" native widget look and feel in their own renderer but I might be misremembering.
Indeed! I wrote my note-taking app with a block editor (like Notion) in Qt with QML for the UI and C++ for the logic and it's been an incredible experience![1]
[1] https://rubymamistvalove.com/block-editor
Very nice, thank you for sharing!
How would you know? It's impossible to have done a thorough analysis of all the Windows UI frameworks, five have been released since I started typing...
You don't care what were you trying to build but for a quick me alone Linux app I used Flutter. Honestly it's my go-to when I want to have a quick native app on any platform but dont want to bundle electron.
Flutter is solid choice, and Canonical seems to be putting weight behind it for Ubuntu as well. Canonical is also now the new lead maintainer of Flutter Desktop.
QT and GTK are as native (and solid, I guess) as it gets, since there's no "default" UI toolkit that's shipped along with the kernel, unlike e.g. Windows or macOS. Speaking of Windows, why do they even ship browser-UI apps as a part of the OS? Do they find native Windows UI development too hard or feature-limited even with LLM assistance?
Because Microsoft screwed up their native UI story. They are slowly starting to go native again with WinUI3, but Microsoft went through a rough period with UI frameworks, I mean how many do they have now all still "supported"? WinForms, WPF, MFC, WinUI, MAUI, etc.?
Well what does native mean? An XWindow? Native on gnome is different from native on kde or xfce or lxde…
I mean there is the no true linux argument, but covering the main stream desktops you basically have kde which is written with qt(so qt is native) or gnome which is written with gtk and both frameworks/DEs do implement other things besides "just" the gui, so you are native.
Yes... Just use DEB package files for any distro. Make a compatibility layer that is distro dependent so that it can come preinstalled on any distro. It converts the DEB package to a distro native package so that it doesn't fuck up existing packages or the existing distro-native package manager, and gives you the apt and dpkg commands . Unlike appimages and flatpaks it has no reviewer, no store and it can be installed just like EXEs on windows which is already the case for DEBs on debian and debian based distros. Would this work?
Microsoft used to ship a Linux binary for Teams, but they stopped doing that. Guess the tech was lost.
It sucked.
Download Edge for Linux and use the PWA. It's still crap but at least it kind of works mostly.
I'm not usually one to defend Microsoft, but since Teams works great in a browser, I actually prefer it that way. My video conference doesn't need access to my whole filesystem and an opacity layer that prevents me from seeing what it does. I actually applaud them for supporting browsers as well as they do.
Yes, except it only worked some of the time on some of the distros (mainly Ubuntu/Debian variants of a certain vintage).
With the AI, we can finally have the year of desktop Linux.
Nonetheless, it's the year og the linux desktop!
Yeah idk what OpenAI was thinking. Just going off their own claims… OpenAI must be filled with bozos to not be able to utilize their own supposed product capabilities…
Same with Anthropic and their "support" team, which seems to be Claude 0.1 run on a commodore 64 in the basement...
It's the exact opposite. They picked the easiest way, done countless times just fine by everyone else and still failed
AppImage, yawn.
I think they were joking...
What problems are there with appimages?
Yet I have to install a not very famous, maybe unmaintained daemon to get basic system integration
It is already pre installed in most distrosk
Exactly my thoughts! I was expecting a Rust app written from scratch available at least in Qt and GTK flavors , and maybe with a third and a fourth option.
Don't they have agent swarms with infinite tokens?
They replaced a pretty decent native Swift Mac app (with only some chronic state management bugs), weighing ~100MB ish, with the Codex app that most people don't need, made in Electron, which takes minimum 5GB+ including filesystem cruft. Today I ran into a memory leak that froze the app and made the Renderer process take 5GB, then 10GB of RAM.
That was after I asked it to only touch 3 text files in its working directory, after which it sparked macOS permission prompts to access my Desktop, Documents, Downloads, and other apps' data. Thank god for the web platform and web apps.
"Thank god for the web platform and web apps."
They can be amazing. But you can write shitty code in them like anywhere else.
Browsers fundamentally chew on RAM for breakfast.
AIUI the reason is, "we", collectively even though we don't all work on them, optimize browsers for speed above almost all else. Then, when all the advertising websites on the internet consume all that speed, we can't go back and have to optimized for speed even harder. All that optimizing for speed ends up consuming lots of RAM, from all the images, the speed-optimize DOM with lots of cross-linking, the JIT and its generation of native code paths, the endless layers of caches, etc. etc. at every point where a browser can choose between RAM and speed it will choose speed unless it's just impossible to choose it for some reason.
So even if you write good code in Electron, it still tends to eat resources like candy.
On the plus side, if you write good code, you will pick up all those optimizations too, which is not necessarily all bad. Running something like VSCode at all is a powerful testament to the browser ecosystem now. IDEs do a lot of very heavy duty lifting and need a lot of performance to do all their work. But you can imagine that when the same text rendering system that enables all that fancy & fast syntax highlighting and all the other decorations and features in the editor window is used to display a preview of a markdown file that said preview is probably going to eat way more RAM than your instincts may have guessed.
But they're strictly sandboxed and won't muck up my local filesystem.
> They replaced a pretty decent native Swift Mac app (with only some chronic state management bugs), weighing ~100MB ish, with the Codex app that most people don't need, made in Electron.
Not even a $1T dollar company wants to maintain a native Swift Mac app even though they have AI models to build native apps for every platform.
Maybe they thought Electron would save them tokens to build the feature once and it works everywhere rather than spending more tokens on building the same feature on 3 platforms.
Works everywhere except Linux for a long time.
What better way to showcase their tools capabilities than to deliver apps that are native, efficient, and integrate well with the host system? By compromising with Electron and making mediocre, bloated software they are signaling that they just aren't there yet.
It would be like Ford buying Hondas for their company cars. It might save them money but it sends the wrong message.
Yeah that's what gets me. If, according to them, "software development is a solved problem" then there's no reason they can't make native, efficient, well integrated apps for each platform. If the problem is solved, just have the AI do it! If it's truly as advanced and accelerating as they claim, then there's no need for electron anymore.
Maybe they are drinking their own kool-aid, resulting in less then optimal choices and worse software for everyone and everything
What! They replaced the native mac app with this?!
I hate the new app aswell but you can still get the old one called ChatGPT Classic. Just scroll down to the bottom of the download site.
Its unmaintained and has glaring bugs (cant adjust thinking level) for a month now
Yup, this pisses me off so much. I now just go to the web app instead of using this broken app.
It’s apple fault that swift and swift ui is completely garbage.
I have already created a croos-platform solitaire game in Rust with Opus 4.5. Done in one evening. I absolutely do not understand why OpenAI could not write a proper application in 6 months. Do they struggle to use the product they sell?
I am thinking about this too. I mean they have access to the highest level models and still they just produced a garbage.
They probably just don't see it worth the extra effort. And maybe they want to keep it in sync with the web UI.
It definitely is a fraction of the work these days to maintain three different desktop apps + two different mobile apps + a web app. But it's still a lot more work than an Electron app that is merely tweaked between platforms.
I was under the impression electron is chosen less because of broad cross-platform concerns and more because chat apps, specifically, require a level of care in text rendering that nobody really wants to design from first principles when they can just piggy back on web technologies.
But I wouldn't know first-hand.
Text rendering is:
1. generally done well by many different UI frameworks
2. generally done better by most popular native UI frameworks than what Electron provides
BUT - those UI frameworks are typically not (very) cross-platform. In that context, Electron provides one of the best unified text-rendering stories of cross-platform options. But definitely far from the best overall.
> App was released in February & took 6 entire months to port to Linux
Product releases at large companies are slowed dow by coordination and resources more than actual development. (I'm an Electron maintainer who is currently working on better Linux support in the framework, and also a developer/PM for a commercial app that supports Linux.)
It's very likely that the Codex Electron app already "worked" on Linux back in February, as in someone internally could build and run it from source and start a chat session. That fact would have made it possible for a small team to make a business case and start getting support from ops, QA, CS, marketing, legal, etc. The engineers would spend their unlimited tokens on Linux-specific build, packaging, and platform integrations (remember this is a computer use agent) to take the app from a prototype to something a company could actually launch and support for millions of users.
Apps are also a moving target. The entire time building up to release, the Linux desktop app would have been getting feature and design updates for free from the updates going out on Mac/Windows/web. None of those other teams working on those features have have had the time (or the mandate) to coordinate with Linux engineers if they were building a separate app from scratch, and I suspect such a proposal would never have gotten off the ground.
I work in a large corp, I know how these things work - my company has taken longer to do simpler things than this. My observation wasn't to call this out as unusual or unexpected.
I think you've summarised it really well, & it shows:
- the revolutionary promises of AI-driven rapid delivery is nonsense when the delivery bottleneck was always elsewhere - AI is speeding up the part that was never slow
- the fact that - as you point out - it was likely working in Feb but needed a business case gives a good impression of the leadership's approach to Linux support: it's likely such internal case-making will continue to be a factor in future Linux build maintained
Wonder how many will bother using the desktop version on linux. Im on macos and i just use the CLI most of the time
The desktop app is actually really good (esp on macos). I used to be CLI only, but after trying it recently it's super convenient. Much easier to manage multiple projects simultaneously and it has a built in diff viewer, file browser/reader, terminal, side chat interface, etc.
well this just shows how good the AI is at programming
The most remarkable thing is that it was built at all. What self-respecting Linux desktop user wouldn’t be satisfied with the TUI?
It is a marketing expense. We are talking about it. Surely the token cost was worthwhile on that basis alone. Students will likely get some usage out of it, too. But paying a human to do this port would have been an insane thing to do two years ago. I’d be surprised if they have more than 1000 MAUs for this client by the end of the year.
How are you doing testing for desktop apps? any tool recommendation?
Corporate it is a scam pretending to be a job creation program to make sure people dont get funny ideas
i doubt the UI was the hard part. these desktop apps are about computer use. thats where the tricky bits are.
6 months is way too long IMHO