The rural & underdeveloped area and the niche applications (ex: ships and planes) will bring-in some cash.

And in addition, the US Army will pretty much guaranty it to be in the green: it wants this capability plus some control over it.

If it was civilian only, I doubt the economics would make much sense, specially given the amount of satellites and their short lifespan combined with the overall shrinking market (rural flight to cities + fiber deployment on land).

I published nearly everything I code on my free time, that's ~100 git repositories. Out of these, ~15 are documented and made generic enough to be used by other people, and out of these ~5 actually have some users, 2 being packaged in mainstream Linux distributions and one even has a CVE.

In total, I have received one AI slop PR. one.

Your mileage may vary, and you may be blessed/cursed with the new redis or xz. But in all likelihood, things will stay more than manageable in terms of critical infrastructure piece.

I have the feeling these projects were not deeply intertwined with Google products like this cli is.

This project was not exactly some random devtool or library polished a bit to be published and used outside of Google.

It was a de-facto major feature of a significant Google product.

Honestly, at Oracle scale, doing the "let's destroy and rebuild the company mid-flight" seems like a losing proposition compared to newly formed companies or more natural extension of existing companies.

And meanwhile, customer reliant on Oracle products are left alone, with all the negative output it entails.

From what I could found, billionaires die on average at ~83 years old. ( https://strygin.substack.com/p/how-billionaires-die )

It's not far off what a decent health care system is able to provide in most wealthy countries. It's even somewhat lower actually.

It's difficult to assess the risk factors, but in the end, I have the feeling their additional medical staff and their ability to "cut the queue" (S. Jobs-style) just barely offsets the additional common risk factors (stress, long hours, segregated life), specially if we compare to the upper-middle class.

In the end, there is no magic $100M pill giving you 10 more years. And in truth, access to food, drinking water, a non-toxic environment and really basic healthcare & medicine (vaccines, antibiotics) probably already brings you at a fairly high life expectancy.

Given the number of moving parts, I would be terrified to have to look under the hood of what Talos deployed for me.

Here is whim-proxy, a client + server combo helping developers tests webhook consumers when running the producer service is not practical (e.g. third-parties like GitHub or Stripe)).

Whim-proxy solves this issue with a whim-server & whim-client combo working as follows:

.1 A public/reachable webhook listener on whim-server receives the events from producers.

.2 Each event is then forwarded to subscribed whim-client processes (pub-sub) running on developer's laptop via WebSocket reverse-tunnels.

.3 Finally, the whim-client takes the event, and reproduces the original webhook, targeting the local consumer being developed/tested.

In all honestly, the tool itself is not that impressive. What impressed me was how quickly I got something working.

With Claude, and from the initial idea, it took me maybe 2 hours for a working prototype. And reaching something looking presentable took barely more than a slightly long evening; logo and demo deployment included.

The tool is probably far from perfect, I highly expect it to be DOSable quite easily for example.

But producing something similar would have probably taken me 1 or 2 weeks pre-AI.

For these kind of small/internal tools, AI as been kind of a blessing. The scope is small and all the code fits in context, also the quality is generally not critical (not on the production path).

For now, it's a far better option in my opinion compared to the old Perl script Joe Nothereanymore wrote 15 years ago. I just hope it will not become a curse, with a jungle of IA generated tools nobody actually understand.

It's kind frightening how little I looked at the actual whim-proxy code. It's small enough that I could probably dive into it. But multiply it by 20 in a corporate settings... well...

Comments URL: https://news.ycombinator.com/item?id=48517209

Points: 2

# Comments: 0

Given how many quick & dirty sed patching or exec commands I've seen in the few nix package/modules I've read, I would not exactly bet my life on it being completely idempotent & reproducible.

It's not like the Linux world where you have distinct projects like the Kernel, GNU, OpenSSL, and then it's the distributions job to assemble everything.

In the BSD projects, the scope is developing and distributing an entire base system, i.e., the kernel but also the libc, the shell/all posix utilities, and a few third parties like OpenSSH (which are usually "softforked").

It's quite visible in the sources, it's a lot more than just a kernel: https://github.com/NetBSD/src

Additional packages you could get from pkg_in/pkgsrc (NetBSD), pkg-ng/ports (FreeBSD) or pkg_add (OpenBSD) are clearly distinct from the base system, installed in a dedicated subtree (/usr/src in NetBSD, /usr/local/ OpenBSD/FreeBSD), and provided in a best effort manner.

The reproducible build target was almost certainly only for the base system, which is a few percent of what Debian tries to achieve, and on which NetBSD has a tighter control over (developer + distributor instead of downstream assembler+distributor).

A reproducible base system is useful, but given how quickly you typically need to install packages from pkgsrc, it's not quite enough.

Anthropic bought it in a somewhat dumb attempt to solve their "performance" issues (not realizing their horrible code was the issue in the first place).

It probably helped them, simply because they brought in some actually competent developers.

But doing so, Bun went from being a public project to more of an internal tool for Anthropic, spoiled for now with AI money and losing quite a bit of focus.

Let's hope that when the bubble pops, some of the Bun effort could at least be salvaged. I don't see Anthropic maintaining it long term, they are simply not in the business of selling support for a runtime nor have the (Google) scale justifying maintaining one on the side.

In the end, the language doesn't really matter and extremely rarely is the bottleneck.

Python, Java, Go, C#, PHP, Node, Ruby or Scala, for backend stuff, all these languages can do the work 99% of the time. They all have well developed ecosystems, and are sufficiently mainstream to easily find developers.

In the end, these languages are just variants of the same tool, and I find more interesting to just pick one and build something with it, rather than bickering endlessly about which one is better.

Managing and coordinating a bloated organization always has a cost and an overhead, from communication issues to technical inefficiencies.

And I also doubt the frontend/backend divide is so clear. I would bet quite a few developers are working on both.

And there is also the demographic disparity at play here.

The US is attracting migrants mainly from Latin America, that's a population basin of 650M people, roughly 2 times the US population.

In China's case, the surrounding countries susceptible to provide migrants is what? a third of China's population?

I'm not knowledgeable nearly enough about the area but I also feel there are also significant cultural and historical elements limiting large scale immigration (for example, the complex Sino-Vietnamese relations).

It seems to be far more geared toward promoting some sort of misplaced post-collapse resiliency.

In other words: solving some hypothetical issues on the other side of a catastrophe for a world we don't know anything about, and almost ignoring present and actual problems.

Sometimes for good reasons, like thorough validation need or operational constraints like spaced-out maintenance windows.

Sometimes for bad reasons, like a complete absence of unit tests and very old and brittle code bases requiring a lot of manual QA and several iterations for a version to be in a releasable state.

And even something as simple toaster might need some customer support. These things do fail quite often, sometimes dangerously.

Increase complexity even a little; or worse, deal with a service (phone, internet, subscriptions, etc) and you will need this safety net.

Nothing is 100% reliable in this world.

There is tons of variability depending on many factors like the project complexity, usage or visibility, or the size of the community around it or the audience/userbase.

Technically, I'm an OSS developer, some of my stuff is even packaged in Debian, with a whopping 17 installs according to the package popularity contest... And I cannot say this has burnt me. I get a few bugs reports and PRs here and there and that's all. And I feel most OSS work ends-up in this category, with this report painting a far too bleak picture discouraging people from contributing.

But some projects do become popular or critical pieces of infrastructure, or both. The hobby structure is indeed completely inadequate in such cases. Such projects should not be only held by a solo or a pair of developers coding at night and doing everything.

maybe, they should be offered the possibility to make it their day job, or to have some help from developers doing this as their day job?

Sure, it means that from time to time you will reject people like the Homebrew creator. And it also means the recruiting process now sucks for the applicant.

But in a context where it's extremely tricky to evaluate an applicant during the short span of an interview, it seems honestly like the least "arbitrary/trusting your vibes" recruiting method we have now which could be deployed at a large scale.

At least, you are getting people you know had the ability to remember this stuff, and also were willing to put in the effort to learn it.

In such context, I think Go might be a better or at least, more realistic, compromise in most cases.