netshade

Agree with this. I started down learning more about archival while I was adding it to my own thing [1]. I wish there was more of an existing toolset for diffing archivals as well - what changed is just as interesting as what is there. Equally, something I kind of think is lacking in WARC/WACZ is exploration of the archives - maybe forensics is too strong a word but it would be nice to have an easier way to explore what you’ve captured and understand the data in different dimensions.

I’ve supported some of this in my own tool, ZShot - capture in sqlite, Quicklook extensions for WARC and WACZ. Just trying to make archiving easy and interpretable.

It’s also been interesting to see people use archival but for different uses: Kiwix [2] showed up in my reading recently, “archival but for offline internet”, which I’m kind of fascinated by.

[1]: https://zshot-app.com/for/archivists/

[2]: https://get.kiwix.org/en/

Working on ZShot [1]. I'm about a year in on a local-only browser tuned specifically for CLI and API usage - kinda filling the gap for "geez, I sure wish I had a browser, but not one to look at". You need a webpage as PNG, or an MP4, or a website as a WACZ or SQLite database. There's a Mac app to help with discoverability of options, but I wanted for my local tooling and building services on top of it.

Along the way I ended up adding an internal agent framework to satisfy stuff like "log in, click the button, and then take a screenshot", out of which fell stuff like automatically generating Playwright tests from that. It even runs the Playwright test suite and Puppeteer test suites ( a bit faster, and for a lot less memory ). I kinda love this bit because I can layer in multiple models that will bounce control of the web session between each other, to do stuff like let a Typesafe model choose to escalate to Opus when it needs higher minded behavior. It's fun to watch it happen.

I've mentioned it a few times around here, I'll probably do a Show HN soon when I feel like it's ready for that. Hopefully soon.

[1] https://zshot-app.com/

Sensors everywhere. If it's at all relevant to what you're working on, providing a different way of viewing something, and a skill description on how to do that, has these long-compounding effects that are magic at first, and then become "of course, it should always just work" as your expectation.

My product that I'm working on sorta acquired a bunch of that. I put a ton of work into making a browser that could just see / interact w/ the web in a ton of different contexts. Now that I have it, it's pretty amazing to just have the agent do everything I need it to ( pull a network log, debug JS, navigate a form ), and it has the appropriate context everywhere.

I'm working on documentation for zshot[1][2]. Kinda like "what if browser automation had curl-like ergonomics, but also was extremely agent friendly, but also could turn into your headless browser infrastructure". I've been working on it for a while now and have incurred a hell of a debt of "explain what it is and how to do it", so working that debt off bit by bit.

[1]: Mac app, https://zshot-app.com/

[2]: Linux / Mac CLI, https://zshot-cli.com/

If you're up for trying something a bit fresh, I've been working on something that helps in this space. Check out: https://zshot-app.com/for/agents/

You'll have to sign up for a trial to do this, but you can just have your coding agent drive a session and just ask it to install the zshot skill, then drive a session and record a puppeteer script for you. If you try it out, love to hear what you think.

I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.

I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.

For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.

All to say that this decision is worth considering without even taking LLM assistance into account.

Started vanilla and importing things like projectile, magit, all of that. I didn't like the awkward edges of how they joined tho, and eventually tried switching to Spacemacs with "less" of my own config. None of it was awful, but none of it felt great.

When VSCode came about and had great integration for a language I was primarily using at the time ( Typescript ) I switched to that and was happy for the comparatively low config required. My Helix switch came about just because of how VSCode absolutely chewed through battery usage when I was out and about.

I was an Emacs user for about 3-4 years. I never felt very proficient in it, I always felt like I was cargo culting in config changes that I never felt comfortable with. I liked the power, but never graduated to the point where it felt like it was working with me. AFA why I didn't switch to Vim, there was enough "Vim is great with a great config" which felt so similar to the situation I was already in with Emacs that I just wasn't convinced. Not the greatest rationale, but that's what it was.

I'm an Emacs -> VS Code -> Helix convert, have enjoyed using it thus far. I've tried to internalize all the existing keybindings and use thus far rather than configuring it much ( I've wanted to have the least amount of config necessary to be effective with it )

One thing I've struggled with is simply remembering everything it can do. I made a Desktop Mat[0] to help remind me ( literally just finished it so will see how helpful it is when the printed version arrives ).

[0] https://git.sr.ht/~netshade/helix-deskmat

LOL, this truly made me laugh. I'm also doing humor stuff with Claude, I was pretty pleased with 3.5 so excited to see what happens with the 3.7 change. It's a radio station with a bunch of DJs with different takes on reality, so looking forward to see how it handles their different experiences.

Not a great look when many responses are "if the provider won't protect people, then the researcher should contemplate hurting people".

You can communicate those ideas specifically without hiding it beneath the veneer of relatability. The entire post started with this bit:

> But, come on: you never took us too seriously about K8s, right? K8s is hard for us to use, but that doesn’t mean it’s not a great fit for what you’re building. We’ve been clear about that all along, right? Sure we have!

which already starts the post in a bad space for the reader. I have cognitive whiplash from what is intended. "We DON'T like Kubernets UNTIL WE DO but then WE MIGHT NOT IN THE FUTURE". Clear meaning is far more appreciated.

I am a current Fly customer (personal and work), and have been happy with the service. Will likely be trying this out. That said, the marketing tone of this final part of the blog:

> More to come! We’re itching to see just how many different ways this bet might pay off. Or: we’ll perish in flames! Either way, it’ll be fun to watch.

is like nails on the chalkboard for me.

Yeah, agreed. I use Eleven Labs a lot but this was a very compelling demo to consider changing. Also, curious that you mention Bark - I never found Bark to be very good compared to Eleven Labs. The closest competitor I found was Coqui ( imo ), but even then, the inflection and realism of EL just made it not worth considering other providers. ( For my use case, etc. etc. )

Disclaimer: I'm just an investment noob.

Could it just be that investing in Apple could be seen as "I get all the upside of any benefits I would get in investing in TSMC, with the additional upside of getting exposure to all of Apple's product decisions in non-chip related markets ( eg financial, content, et al )?" Like, if TSMC invented a new fab process tomorrow that was amazing, that'd be cool, but it'd be unlikely to make a substantial increase in stock prices in its future as that sort of is how TSMC normally behaves. That's their whole business. But Apple has a history of unlocking new markets and adding new cash flows, plus doing a pretty good job maintaining their current cash flows, so you get more upside on Apple, plus a hedged exposure to TSMC?

I say all that with full acknowledgement I'm just like, playing a guessing game at professionals here.

Currently using Swift for a side project. It's "server side" in that I have a server implementation that runs on an iOS device and in Linux on a server. Using SwiftNIO for the server pieces, as it's from the Netty folks, and I really like their design.

I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.

So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.

Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.

Corollary to this: if you have insurance, it's also worth asking your insurance provider if they know of any aid programs that can assist. I was shocked to discover Humana has a team that will help you discover aid programs to cover the rest of the cost that Humana might not cover.

Obvs it would be great if they covered 100%, but if you're trying to cover your ass right now, it's worth asking your provider about.

If you're near the Canadian border, I've heard some anecdotes about folks crossing to get cheaper insulin. I've not done it, though was on the fence about doing it.

Also, I know that some makers ( Eli Lilly in particular ) also offer need-based aid programs to provide insulin. If you reach out to them and they're manufacturing, I believe you can get the insulin at near free if not free. ( This is also true for many medications that fall into the commonly-used category, you can explore manufacturer sites to see if they provide aid for a particular drug that is in your list )

I say this as someone who bought some INTC a while back expecting something like the following to play out.

Last year's (and somewhat, continuing) chip shortage will combine with a view in the US that chip-availability is a national security issue. At some point, the US will make a strong case for in-nation chip fabrication as a national push, whether that be favorable business conditions for companies like Intel, or negative business conditions for foreign chip providers. Intel already sees this, and is playing to that future game; maybe not necessarily win Apple back ( as they say ), but to play to a future environment where many companies that aren't 3T mega corps to not have very many attractive domestic options other than Intel.

Certainly I'm just playing a guessing game here, but that may be a potential future market they pitch to someone. "Apple will continue to play their own game, but here's a whole other market we see in the future".

I enjoyed this article, but I’m confused. The section raising the question about how this has affected other asset prices seems to just posit the question without establishing how the banks actions would have done so. Is there some obvious link between the FED buying mortgage backed securities and technology stocks going up? Or should it be inferred that by buying those securities they just put more money into the system that is creating the situation they describe? Thanks for any explanation.

(Addendum) I did a Fast Ring update on a separate machine and did not see substantial performance improvements, but the comparison is not valid between the machine linked and the machine I tested on, so I'd be hesitant to say that the performance hasn't improved at all, just that IO performance is definitely a weak point to WSL.

Just a note to anyone looking to go down this road: IO performance is still pretty awful last I checked. If your workflow is IO intensive (non trivial Rails app, let's say), proceed w/ caution.

https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.

Wow, that is pretty fast. I played w/ doing CSV parsing taking advantage of SIMD string lookahead a while back ( https://gist.github.com/netshade/aa9e836e843c8e84b97a ) and found it to be quite fast as well, as I had assumed (perhaps wrongly) that the cost of navigating back and forth between the CPU and the GPU would erase any performance gains. I suspect ( it's been a while! ) that the SIMD approach would be faster than GPU, but tbh after working on it for a bit, then comparing it w/ mawk's (http://invisible-island.net/mawk/mawk.html) performance, mawk still beat my approach handily, and did it w/ way more functionality. Which is all to say that mawk is pretty amazing and worth checking out if you're in the market for parsing CSV fast.

Awesome, thanks very much.

Nice, thanks for this!

Would be cool if this included cstore_fdw as well ( https://github.com/citusdata/cstore_fdw ).

This. I randomly picked Bellingham as a quiet place to go to for a week and do some self-teaching plus vacationing.

Decent food, friendly people, nice coffee shops, great areas to go trail running in. I'm not sure I'd go there for an actual vacation, but for just getting away and trying to learn some new things, it was a great place.

I had a hell of a time getting PgPool II w/ PG Streaming Replication set up right. The trivial cases seemed to be fine, but when I started triggering failovers back and forth, I ran into a lot of cases where PgPool II would go stale due to a data file left around in /tmp.

I eventually got it working, but there were way too many informally created scripts that PgPool and PG had to know to trigger failovers, initiate resyncs from WALs, etc. I didn't like it at all, and around about then AWS started offering PG on RDS, so I just moved to that.

So, my advice would be, unless you've got someone on team for who that isn't that much work, you get a lot of benefit from going w/ hosted. RDS Postgres has been pretty great - not exceptional, but for my use cases, okay. Hoping they add cross region read replicas for PG sometime soon, as that would make a lot of expansion opportunities really easy.