Hacker Newsnew | past | comments | ask | show | jobs | submit | ofek's commentslogin

I won't be able to fully test because the interactive prompt gates on the user having an advanced subscription (I already pay $40 a month) which for now doesn't seem to be worth it.

However, the TUI as shown in a post [0] by one of their engineers is quite beautiful. For a moment I thought it was written in Python because it looks similar to Textual [1] but I inspected the binary for my platform [2] and it seems to be written in Rust. I guess Ratatui is quite customizable!

The state of its Windows support is unclear to me. The Bash installer script [3] has a comment on top that says "Windows: run under Git for Windows / MSYS2 Bash (same curl | bash flow); WSL uses the Linux binary." I ran the binary normally in a Nushell session and didn't encounter any issue other than a start-up time that was slower than expected on the first run. Perhaps I would have seen issues had I gotten past the login step.

[0]: https://x.com/skcd42/status/2054993372662915183

[1]: https://github.com/Textualize/textual

[2]: https://storage.googleapis.com/grok-build-public-artifacts/c...

[3]: https://x.ai/cli/install.sh


hey I am the engineer who worked on the TUI and harness and happy to answer your questions.

We worked quite heavily on the TUI, its written in ratatui and we did try to go the extra mile to make sure that there won't be any regressions from moving to an alt-screen rendering. Lots and lots of small details to manage and get correct, we also tried to get vim keybindings correct while keeping it mouse friendly.


Was there a reason you guys went with ratatui? I made one myself but I went with iocraft instead, it has its quirks that are annoying me, might just have Claude reimplement it in ratatui to see the difference...


> (I already pay $40 a month)

As someone who has had Grok since it came out, I used to pay $40 a month, but then I started using Claude more often, I'm on Claude Max since I use it more than the lower subscription can handle. I at one point built my own Grok compatible coding harness, but Grok was underwhelming for me, I have not had the time or energy to burn $$$ just to make Grok work better with my harness, but I'm not spending $300 a month on something my employer will never approve me to use, I'd love to use it but the pricing will have to come drastically down.


> The state of its Windows support is unclear to me.

yeah this one is a bit weird, you can run the linux binary using WSL and that should work. We have a window flavor build but its not as heavily tested yet (we are figuring out a better testing flow for windows)


Thanks for the clarification! I'm sure your team is already aware but Windows users perceive support as native binaries (no WSL) that can run in a normal environment (no Git Bash or Linux utilities).


Agree, I use Windows, Mac and Linux, and work with .NET developers, so primarily Windows devs, some aren't even aware what WSL is.


Wait, why is Windows different? I'm pretty sure you could get it to compile and run consistently across all three platforms, or is this an issue with the TUI?


I shared the author's frustration when figuring out how to ship such binaries to end users so I wrote a guide [0] detailing exactly how to do it. Apple's documentation is surprisingly poor and I couldn't find any blog posts so I ended up reverse engineering what works via trial and error as well as popular OSS projects on GitHub.

[0]: https://ofek.dev/words/guides/2025-05-13-distributing-comman...


I have also written some notes. They are a bit out of date, but might still be useful:

https://successfulsoftware.net/2018/11/16/how-to-notarize-yo...

https://successfulsoftware.net/2023/04/28/moving-from-altool...


If an agreement can't be reached with your new employer are you certain that folks at Microsoft will continue maintaining this library? I'd like to experiment with it but have trepidation regarding future development.


There are people on my team who are interested in stewarding, so I think it'll be covered.


The naming of this project is quite unfortunate as it resembles the Simplex [1] specification for guiding agent development, which does look promising in comparison.

[1]: https://github.com/thinkwright/simplex


I'd encourage folks to read the recently-published statement [1] about the state of OpenSSL from Python's cryptography project.

[1]: https://news.ycombinator.com/item?id=46624352


We're recording a Security Cryptography & Whatever with them in an hour or so, if anyone's got questions they want us asking Alex and Paul.

True facts: Paul co-created Frinkiac.


Instead of everybody switching to LibreSSL, we had the Linux Foundation reward OpenSSL's incompetence with funding.

We are still suffering from that mistake, and LibreSSL is well-maintained and easier to migrate to than it ever was.

What the hell are we waiting for?

Is nobody at Debian, Fedora or Ubuntu able to step forward and set the direction?


How about standardizing on an API, then switching backends can be up to the administrator of the machine.


LibreSSL has put serious effort into making itself interchangeable with openssl.

OpenSSL as the incumbent has no incentive to do the same.


Indeed, I introduced this [0] as an option for every Python integration that runs on the Datadog Agent.

[0]: https://github.com/DataDog/integrations-core/pull/12986


The post is entirely authentic; it matches the writing style of the author from before the LLM boom and discusses work that the human author recently released. Can you pinpoint what makes you feel that way?

edit: I asked for explanation before the post was edited to expand on that. I disagree but am sympathetic to the weariness of reading content now that AI use is widespread.


Your C extension guide looks very useful and I quite like the foreword/history behind it. Have you considered updating the resource to account for the freethreaded mode (which will eventually become the default) on 3.14+?


For sure, it is on my TODO list. It takes a lot of work to explore each new Python C API and I'll get around to it when I can.


This is awesome, thanks a lot! I'm going to introduce this in the test suites of the extension modules I maintain [0][1] and, if all goes well, eventually at work [2].

I really appreciate the support for Windows as that platform is currently underserved [3] when it comes to such memory tooling.

[0]: https://github.com/jcrist/msgspec

[1]: https://github.com/ofek/coincurve

[2]: https://github.com/DataDog/integrations-core

[3]: https://github.com/bloomberg/memray


> pip could implement parallel downloads, global caching, and metadata-only resolution tomorrow. It doesn’t, largely because backwards compatibility with fifteen years of edge cases takes precedence.

pip is simply difficult to maintain. Backward compatibility concerns surely contribute to that but also there are other factors, like an older project having to satisfy the needs of modern times.

For example, my employer (Datadog) allowed me and two other engineers to improve various aspects of Python packaging for nearly an entire quarter. One of the items was to satisfy a few long-standing pip feature requests. I discovered that the cross-platform resolution feature I considered most important is basically incompatible [1] with the current code base. Maintainers would have to decide which path they prefer.

[1]: https://github.com/pypa/pip/issues/13111


> pip is simply difficult to maintain. Backward compatibility concerns surely contribute to that but also there are other factors, like an older project having to satisfy the needs of modern times.

Backwards compatibility is the one thing that prevents the code in an older project from being replaced with a better approach in situ. It cannot be more difficult than a rewrite, except that rewrites (arguably including my project) may hold themselves free to skip hard legacy cases, at least initially (they might not be relevant by the time other code is ready).

(I would be interested in hearing from you about UX designs for cross-platform resolution, though. Are you just imagining passing command-line flags that describe the desired target environment? What's the use case exactly — just making a .pylock file? It's hard to imagine cross-platform installation....)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: