> 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
I'm one of the project maintainers for Electron (not felixrieseberg) and the level of spitefulness in this post and some of Gruber's other recent articles about Electron is really starting to bother me.
It's fine for Gruber to dislike software, even to passionately hate it I guess. But this article is borderline conspiracy theory stuff singling out one (very friendly and easy-going!) engineer as the source of all his problems. Can anyone take his claim seriously that one person is the reason the entire industry, from indies to the biggest tech companies, has been building web-based/cross-platform desktop apps for the past 15 years?
What's sad is that Gruber and Felix would get along great in real life. I know Gruber doesn't see it this way, but Felix is a knowledgeable Mac developer who has spent a career building successful Mac apps and Mac development tools. As fellow Mac devs, the two of them would be able to get into the weeds about AppKit and Objective-C and the pros and cons of different frameworks and APIs, App Store sandboxing, and so on.
Frankly, Gruber needs to chill about this topic and get some perspective. Electron is not an evil plot to destroy everything that is good and pure about the Mac. It's a completely free and independent open source project maintained by a diverse group of developers, often on a volunteer basis outside of our jobs. We have no ill will toward apps that aren't made in Electron, we use other frameworks and tools ourselves. We love desktop apps and supporting the ecosystem, that's what drives us in the first place, and this antagonism is completely one-sided.
If Electron is successful it's because it's doing a good job at filling a niche for desktop apps that the platform vendors mostly continue to ignore. It helps that Electron gets regular updates with bug fixes and features, including new macOS integrations, and we provide free support for developers and extensive documentation. Trying to shame people just because they work on the framework or use it to build apps is not going to make alternatives any more appealing.
(I'm Mitch from 1Password.) I do appreciate reading about these kinds of paper cuts and always follow up on them when I see them. We are going to address the item title issue next week, so thank you for that one.
It's true that sometimes very small/simple issues that affect some portiion of people can go for a long time. I'd like to find a better way of identifying these and getting to them quicker than just crawling through HN posts. If you have any thoughts or at least issues you'd like us to look into, always open to hear more.
Thanks for the feedback. It's certainly a challenge to make 1Password work on every website that exists, and even more so to keep it working over time, especially with old items that people created years ago which no longer match the site. We do have a whole "filling and saving" team dedicated to the problem, and we do follow up when users report issues with sites.
I'd love to look into the Quick Access placement. It is supposed to appear on all spaces and sets an NSWindow property to do so. Is there anything particular that you think triggers it (multi-monitor, full screen apps, etc)?
> I'd love to look into the Quick Access placement. It is supposed to appear on all spaces and sets an NSWindow property to do so. Is there anything particular that you think triggers it (multi-monitor, full screen apps, etc)?
Thanks! I haven't seen it in a while, so maybe it's been fixed by either a 1Password or macOS update or is specific to a setting I since changed. But I'll keep my eyes out for if it happens again. I do have a multi-monitor setup.
I do see right now that if I'm on a full-screen app, 1Password's quick access window doesn't show up; if I move to the next space over I see it for a moment and then it disappears. In contrast, Spotlight search will actually pop up directly over my full-screen app, though knowing Apple they could be using some private API for this behavior.
Electron maintainer here: We're looking to publish more posts like this on some of the work we've been doing to improve quality and platform integration in Electron and Chromium. Would love to hear from the the HN community if there any areas you'd like to see more of a focus on.
Very sorry to hear this Hackbraten. Wayland support has been gradually improving so you should be able to use an up-to-date version of 1Password in Wayland without these kinds of issues, although as with all things Wayland it also depends on your distro/WM/GPU. (I recently tested in Fedora 40, and I use 1Password in native Wayland mode on openSUSE Tumbleweed.)
I believe our clipboard integration still has an XWayland dependency, but you don't need to actually load into X11 to use it, just have it installed. We are currently working on better native clipboard support for Wayland in the arboard project. (Contributors are always welcome! https://github.com/1Password/arboard.)
Also if you ever feel like applying for that job, I'd love to have more people who are passionate about Linux on the team. :)
Pandoc and multimarkdown are the greatest. I've never found a way to fit textutil into that workflow, though. Is there anything it can do that pandoc can't by itself?
Textutil handles a couple of apple-specific file formats (rtfd, webarchive) that do an embrace-and-extend on open(ish) standards.
(Annoyingly it doesn't provide a way to get at the guts of Apple's own Pages files. Which sucks because the only tools for transcoding Pages are Pages itself, and icloud.com.)
> Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code.
This is an excellent point and one that's not nearly as appreciated as it should be. Fullscreen mode was written off in Lion as an example of Apple dumbing down the platform and making it more like iOS, but it's the perfect mode for writers, coders--and really just about any kind of creator who needs to focus.
I use sizeup[1] to maximize the terminal (or any other app) with a keystroke, instead of native full screen. It works across all applications that allow window resizing, and has handy shortcuts for "half" full screen, which is great to position, say, a browser and editor next to each other across the whole screen.
Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free version is fully functional with just an occasional nag screen.
I do front-end web development and full-screen doesn't work for me. I never spend that much time just coding. I switch to test in the browser often so switching between full-screen windows is jarring.
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.