oooyay

Hah, I had no idea that he was based on Horatio. I always really loved Horatio as a character and I found his way of observing and reacting to the world in such uncertainty unparalleled. I also always loved Captain Picard for the same reason, but I never realized one may be an influence for the other. Thanks for sharing this.

I don't think this kind of attitude is necessary. I do this work for free, there are no bragging rights in maintaining an IRC client. I maintain this client because there are zero options for clients that look and behave the same across operating systems, are modern, and customizable.

You're welcome to open a PR and participate.

I live in Portland and we've recently committed to moving back to Bay Area because of this exact reason. The remote market that made it possible for me to live here is dying. There are also not many, if any, businesses in Portland that I'd work for that pay market rate.

Would Claude have found it without your guidance and knowledge? If yes, Claude found it. If no, you found it while using an LLM.

I suspect a lot of things fall into the latter. It is a common neg to defer everything to the former though.

> Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app.

Yeah, I think that's fair. I don't think about resource utilization in a vacuum: native apps require I develop three different apps and likely have a lot of CGO dependencies. With Wails and the OS WebView the same client you're used to using on MacOS should work the same or similarly on Linux and Windows within reason. They should also all maintain similar resource utilization profiles. That's why I said it's limited in its footprint, I'm not here to compete with native library performance and native library performance isn't trying to compete with my ability to cross-compile.

    Process                         PID     Avg CPU    Footprint (MiB)
    ------------------------------  ------  ---------  ---------------
    Cascade                         45314      0.46%              73.0
    WebKit WebContent               45349      0.50%             392.9
    WebKit GPU                      45347     <0.01%              26.1
    WebKit Networking               45348      0.02%               6.5
    Nick completer plugin           45344     <0.01%               2.8
    Nickname colors plugin          45345     <0.01%               9.7
    ThemeWidget service             41353     <0.01%              10.1
    SafariPlatformSupport helper    41355     <0.01%              13.1
    ------------------------------  ------  ---------  ---------------
    Total                                     1.00%             534.2

I'm currently connected to four networks for 6 days and 18 hours. Compared to other native apps on the same system:

    App           Main PID  Uptime        Avg CPU  Main MiB  Total MiB
    ------------  --------  ------------  -------  --------  ---------
    Cascade          45314   6d 17h 45m     1.52%      73.0      556.8
    Proton Drive     22091  11d 04h 32m     0.15%      48.0       65.1
    Ghostty          78285  27d 22h 03m    <0.01%     173.6      184.2
    Finder            1308  34d 19h 32m     0.05%     104.4      104.4

so, if I rewrote the application into three separate applications I could probably save ~200 MiB of memory footprint. I'll look into my ability to slim down the memory utilization but some chunk of this is probably the message buffer of each channel.

heh, I'm not sure of your particular beef with these two but I'll use this as an opportunity to explain my rationale.

I obviously write a lot of code in Go but as a language it's also a really nice pairing with the IRC protocol. The way you write abstractions and tests just lends itself so well to writing desktop applications. On the other hand, writing UIs in Go (which I've tried in a multitude of ways) is just a really poor fit because asking Go to emulate Elm architecture is very clunky.

From my perspective, UIs are side effect driven code and demand a language that can fit that paradigm not just well, but great. Anything else I would or could have chosen would've required way more CGO dependencies than I have (of which I only have 1 atm) and would have read worse when I tried to hook it into Go.

Conversely, Wails' bridge to Typescript and React is very simple to use, reliable, and keeps up with the performance and consistency demands on an IRC client. Tailwind is also just very good at making compatible CSS; I was inspired by the use of QT in modern car infotainment systems in my selection of a component-based CSS approach.

Lastly, the whole thing is compiled into the binary that you download and makes no external calls on its own. It's all built on top of the OS WebView rather than a third-party browser the way, say, Electron is.

Thank you! Would love your input

You might like the IRCv3 client I build at https://github.com/matt0x6f/irc-client. It's highly capable and modern but limited in its resource footprint and quite zippy. PRs welcome as well.

There is a singular patent owned by Sony that stands between you and being required to physically acknowledge ads on your TV: https://patents.google.com/patent/US8246454B2/en

I think at this point assessments like this are more qualitative than quantitative. I use Codex far more than I use Claude for coding and my results are generally higher quality. I would not, however, go to someone and tell them that Codex is better than Claude generally. In large part it depends on how you use the model and the harness.

> Perceived performance is actual performance over expectations and the latter just keeps increasing over time.

This is true of all reliability and performance paradigms, incidentally

IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.

I briefly entertained building a modern chat experience on top of IRC when I came to this realization.

I think about this a lot and have reached the same conclusion Norman does. I do wonder if maybe our natural progression is towards something more akin to confidential computing and enclaves.

I'm not sure if it was any kind of official rule, but I worked at times in a JTAC capacity for troops in contact. I mention the last bit because it's very high stakes where seconds and minutes count a great deal more than when you do coordinated tactical strikes against strategic objectives like weapons caches. When I did that kind of work we had to have three eyes-on forms of contact. Often that was the calling troops, the observer (like an Air officer), and an air asset like a drone. They all had to independently describe the target, its orientation, and surrounding activity.

However you sourced your target is irrelevant to the activity at hand. When I first heard of this news I knew immediately someone skipped target verification or that it was simply no longer a policy of the DOD.

FTA

    "Finally, we just uncovered that an AI botnet has discovered our pico services and are using it to communicate with other bots. Normally when we discover spam on our platform we simply move our services from the free tier to the paid tier. This has worked really well in the past and keeps our services feeling like a smol community. However, prose is a service we want to keep free because it's a great way to see how our services work. Therefore, we plan to introduce an invite system. Anyone can create an account but they won't be able to do anything with that account until they get an invite from someone within the platform. We plan to move pretty fast on this change since our discover page is completely flooded by bots. Once we move to an invite system we will likely re-open pgs.sh to have a free tier (and potentially our other services as well)."

We used to call this the game of telephone. The shameful part comes from three posibilities:

1. A head of a frontier AI lab has no idea what happened in that incident and did not read the multiple papers that came out of it.

2. A head of a frontier AI lab did read the papers and was informed but still walked away with this understanding.

3. Andrew Yang made this whole thing up.

I think what most of the commentary is on is the initial gameplay loop which has to do with planetary exploration and learning words. After that there's a multitude of new gameplay loops that become intertwined. I don't think most players get that far unless they have a very old account.

This is old tech money as I call it. People from the early 2000s and 2010s who owned a home in the Bay area back then through the pandemic. Most of these folks share a characteristic of not knowing how wealthy they are comparatively to new tech entrants or even those than entered in the 2010s.

Not to say anything negative of that, I think it's just a byproduct of the free wheeling and fast paced times back then, but if you're not prepared for it then it can rub you the wrong way sometimes.

This is the way it should've always been. I don't care what tool you use, but you'd better be ready to stand by and explain the results if necessary.

Their primary storage medium is block storage which is quite expensive. Codeberg cited it, although post-hoc, in their decision to ban AI projects. GitLab runs (or ran) the large block storage based Git service I know of which is Gitaly.

If you want to achieve public service level traffic and cost then you pretty much need to find a way to leverage object storage.

Why use my brain when I can rent space in yours? Hell, I could see building the fee structure in such a way that three close proximity humans run the same app just in case one gets hit by a bus.

Tangled is good, I have a repository hosted with them. Both they and Radicle lack private repositories though.

Forgejo and Codeberg I look at as more like hobby projects. I would not trust them with my code.

One of the least innovative teams I've worked on involved engineers that would try to force group discussion on ideas early on. Nearly every project or initiative I tried to build there met significant friction.

The most innovative teams I've worked on implored, and maybe incentivized, periods of reflection and evolution of ideas. Often we built POCs along side that evolution. They'd often juggle many different new ideas. Each, often, had its own evolution. Whatever shook out is what won and we often had pivots in line if we needed them.

I think in general it's what Sam says it is: if you artificially force people to defend their ideas early on then you end up coming up with pretty mid ideas.

An interface is an example of a seam in regular code. It's basically what forms architectural shapes that you can depend on for both design and testing.

Linux namespaces, and containers, are not security features in themselves. They end up having to be combined with SECCOMP and some sort of application kernel or SELinux in order to have an effective security apparatus. This is before you give it application aware security controls like policy.

I'm not sure the difference changes the conclusion but I think projects demanded certain workflows and resultant processes, not the other way around. That's why Jetbrains has so many workstream specific IDEs that sold very well. The processes didn't go away but a lot of us changed our IDE surface. Those processes still need to exist, largely, but the way in which we invoke them is moving and changing. To some degree, the processes are also changing because other factors are changing outside of the tooling.

For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.

I don't mind that Tangled is VC funded as long the tech is open (it is) and as far as I can discern it is federated and decentralized. You and I probably have different ideas of what the future may be and that's okay.

As a maintainer of an open source project I largely care about CI, discoverability on the web, and the sign up burden being small so that issues continue to be reported. I think Radicle and Tangled are probably the future in that way. Tangled needs to support private repositories and Radicle needs a real CI solution. We're not far off from either.

Cursor was a great introduction to agentic engineering but I've learned their Claude pricing is largely just batch purchases. Their real moat I think is Composer 2.5 because both their agentic and IDE experiences fall short of Codex and Claude Desktop in my opinion. I think their sales will tell you economically they make the most sense and I would probably agree, but cost isn't everything especially when the spread isn't that wide. At this moment, capability is really king.

These days I'm using Codex and Claude Desktop with Zen when I need to look at code. Codex's real time audio chat feature (not dictation) is also second to none when paired with their agentic flow.