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

The debt amount is very roughly proportional to the size of the economy.

It's also a system that is unstable in non-booming economies, drifts over time and needs periodic resets (through revolution, debt cancelling or inflation for example).

When dealing with material well-being, it makes much more sense to focus on goods and services and frame things more in the line of "would you trade a bit of wealth (smaller car or home, less Uber Eat, etc) to ensure a few unlucky people have food and roof".

Most western economies, specially one as wasteful as the US, have the luxury to make this choice. Not sharing it is a political & ideological decision, not a materially constrained one.


I agree with the system you describe, i tend to disagree with the conclusion.

I suspect the size of the debt is just a "dc offset" and not the main signal. While important, maybe not as "information-ally" significant as it's size would suggest. Still it is probably hiding something, a subtle bug in the accounting, and that something contributes to the frequent cycles of debt-jubilees, revolutions, upheavals etc.

Now the real question you have posed is what is missed in the debate - most wealth in our society is captured in the make up and choice of goods and services consumed, and what is the contribution of a bias towards wealthy consumption here? e.g. in my country there were about 150 luxury yacht sales totaling ~$4billion, vs ~80,000 luxury car sales @ ~$15billion, vs total car sales of ~1,000,000 at ~$100billion. The annual cost of our public disability insurance scheme is ~$50billion. The "sharing" seems to have a significant access to resources compared to luxury on those accounts. I personally think the public disability insurance scheme causes harmful distortion to the broader economy while also meeting the important needs of some members of society.

My gut feel the issue is not ideological or political or a luxury preference, it's structural - the economy is not structured to deliver the correct set of needs, and this is due to real material constraints that have always constrained the economic problem. Not in terms that just the wrong top down decisions are being made, but that the correct bottom up decisions are prevented from being made. If you apply a model of computation complexity, feedback and iterative improvement - bottom up generally has more access to information and compute to directly address problems, while top-down can occasionally deal with global biases and accumulated error.

One true material constraint is the scarcity of competence and accountability. Wealth accumulation is the natural consequence of that material constraint. Top down "political & ideological decisions" are generally the enemy of competence and accountability.


And at the risk of being a downer, I'm not sure Open Source LLMs is actually viable.

Training a model requires two or three orders of magnitude more investment than the typical OSS/Creative Common contributor can reasonably afford.

It reminds me a bit of Open Source hardware (CPU, GPU).


Well, it has proven itself to be a very useful military asset in Ukraine.

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 feel this is way too fear mongering heavy against developing in Open Source.

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.


> was very common for individuals and teams to publish projects to open source repositories under Google-managed Github orgs.

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.


I don't recall any current car manufacturer with such lineage.

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.


A sample size of 3 is hardly statistically significant.

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.


And the troubleshooting?

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


I’ve found it to be excellent at troubleshooting- recently had a hardware incident and it diagnosed the problem and migrated my cluster to a new machine super fast. I just give the agent access to kubectl and I let it investigate bugs and it does an excellent job - I would say way better than it is at normal coding.


In the end, Nix is just a thin veneer on this stuff.

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 the best option after IllumOS (OpenSolaris) IPS integrated with ZFS. Far less powerful not imposing zfs (only well supported for root, swap, encryption etc), so not integrated in the package system and bootloader management (BEs, Boot Environments).

It's not reproducible bit by bit, it fetch the current version of anything, but it's still easy to reproduce enough, stable enough and complete enough, while classic distros need a fresh install every major release or facing issues an keeping a system in unknown state for long until it explode.


Also, the *BSD are structured somewhat differently to a Linux distro.

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.


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: