Tried Halloy on macOS for ~6mos, has some serious issues ...
(1) It silently disconnects from the server without indication, and does not reconnect. You might assume it is connected, until you send a message and see "message can not be sent". You will lose conversation history unless using a bouncer. Clicking around, all the buffers will clear indicating some major state issue, and you will have to restart it.
(2) Consistently uses ~5% CPU doing nothing at all.
(3) Doesn't behave like a macOS app, pressing the red "close window" button will close the window, but the main process goes ANR.
After leaving Textual since that was discontinued, guess I'm looking for a macOS IRC client again. Might give Mango a try.
Yeah, Halloy is "interesting", although I haven't personally run into issues yet. It just clearly not a native Mac app, which is fine, but not my ideal.
TL;DR someone bought Textual and are restarting development. It's not a PE-style purchase, like a Bending Spoons / Evernote kind of thing. According to the buyers, they bought it because they're heavy users and wanted to take it over so they could resume active development. I always keep a healthy skepticism, but I'm hopeful.
I don't get the impression Mozilla puts much effort into Firefox on macOS - whether its performance, or fitting in UX wise. So it's nice to have another browser on macOS that can run uBo.
The RPI Zero 2 has micro-USB ports ... there are plenty of reasons given for this, which arguably made sense 5 years ago. I'm not sure about 2026 though.
People are still using Arduino boards with USB-A mini B ports. At least for micro USB you can easily find cables everywhere. Hardware world is kind of slow in that regard. You can always go for ESP32 if you want though. Cheap and USB-C.
I gave it a few minutes of trial and then disabled it.
With memory prices increasing, many people unable to afford new machines, and web browsers being one of those things that can potentially take a lot of system resources, I wish the Firefox team would prioritize CPU and memory performance of the core engine for users with lots of tabs.
I have stuff like 'Auto tab discard' installed but it seems to break other things, like 'Close Duplicate Tabs'.
Lol, there's enough people out there with hundreds of tabs open that there's clearly a real usecase for it, but I have just never understood this usage model. Feels to me like complaining you get bad gas mileage in your car because you're carrying around 15 years' worth of discarded McDonald's wrappers. The car isn't the problem! :)
Haha - if you read my post above, I detail my setup. I didn't cover usage there. Essentially, in my most used panels, I open a bunch of tabs that may be interesting in the AM, when I designate ~30mins to perusing sites like HN. I dedicate some reading blocks of time later in the day where I actually look at what I opened, usually kill a bunch of low info tabs quickly and maybe read/kill a few big info tabs. Others that I want to dedicate real time to float to the bottom of the list until I have time to read them. It stays fairly evergreen because I am a systematic reader...
This devkit does look fun. I had a few small personal projects I though might be worth writing for Android Wear OS, but Google isn't worth the hassle, and this little ESP32 Watch might be less friction.
> A YouTube spokesperson said the ad should be appearing soon, though as of late Saturday morning Bleecker Street has not yet been informed of any change.
> The Meta reversal is especially notable as the company had previously rejected an appeal by Bleecker Street, leaving it with few options to run ads on Instagram and Facebook.
> TikTok and X have remained quiet and continue not to run the ad.
I'm looking at the Theater list right now and it's not looking great maybe they're still ironing out the details. We are still a few weeks away. Social media companies can block all they want, but there are tons of art house theaters across the country that can play this thing, and they're not(so far). It's really annoying that the first run is only on these enthusiast-led theaters. It's a bad omen its as if the distributors don't have a lot of confidence in this film.
One thing I would like is a tree-like chat structure like reddit / HN. Many times I abandon the direction things have gone but would like to resume at some ancestor or sibling response.
I solved this with task management and got work trees.
The downside of course is branching in got, but I usually don’t go of course more then a handful of tasks.
I had to engineer my own ticket management to keep opus on target. It’s been great for managing work, history, audit trails and commits are tagged with the task id.
I implemented subtasks to deal with the way Claude likes to stage its own objectives.
Then I made enforcement logic in the task manager so tasks can’t be closed out until reviewers have consensus on the same sha.
The adhd that is Anthropic demanded I build it and now I’m knocking out issues faster than Batman.
>Each conversation is a Yjs CRDT tree. It can branch into sub-threads (recursively), and you can drill down, backtrack, edit, undo/redo, and inspect everything: tool calls, approvals, and the raw context JSON going to the model, etc.
I was on Sequoia as well, and just updated ... first thing I noticed is LaunchPad is gone.
The Tahoe Dock "App View" / Spotlight just lists my 30 installed apps intermingled with Apple System Apps, which I hardly ever use. Hard coded categories, no way to re-order as far as I can tell.
Seems like the closest thing to LaunchPad is dragging ~/Applications to the Dock.
The other thing I have noticed is scrolling in Firefox is more choppy, and animations are more Janky than Sequoia on this old MacBook Air M1.
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language.
That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API.
This will likely get extended over time to eventually allow package definitions to themselves be in JSON.
> I suspect that the number of people that use and know Groovy is steadily declining
One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need
"One of America’s Last Chestnut Groves Is About to Be Destroyed for a Data Center"
https://www.gadgetreview.com/one-of-americas-last-chestnut-g...
reply