HN user

wahern

17,871 karma
Posts7
Comments5,618
View on HN

Very small, less than a few kilobytes, and many less than 1KB. I was compressing and embedding Lua source files individually. There were smarter ways to do it if I cared about overall size, but doing it per file kept the build simple. I spent way more time on the compression test harness, which was more about satisfying my curiosity and penchant for diversion than anything :) I did the tests after the actual embedding work.

without government controlled land registry.

De Soto describes the exact opposite situation. Latin America inherited Napoleonic property law, which only recognized property ownership when formally registered, which required quite alot of red tape. It was impossible to transfer ownership without registration. Moreover, any defect in prior registration meant the lawful owner might be the heirs of someone generations ago. Most property "owned" by the peasantry usually had defective and incurable title, having changed hands in informal private agreements, which meant banks wouldn't accept it to secure a loan. This meant only the aristocracy could leverage the financial system, because they were accustomed to following all the formalities. What piece of real property someone thought they owned, even if occupied for generations, was often in the eyes of the law owned by some aristocratic family or the state.

He contrasted that system with the American common law system, where title could be legally transfered entirely privately. Disputes are handled by courts which look to the timing and substance of transfers. Moreover, adverse possession meant that after a number of years (well within one person's lifespan) nobody could come along and claim title because of a defective transfer (even if in principle they had a better claim originally), securing title in whomever held it, even if it had been transferred without even following the much looser requirements under the common law. A bank would issue a loan so long as you could prove you held an unchallenged title for a sufficient number of years. ("Title" was whatever piece of paper handed you by the previous possessors; no government stamp or recordation required.)

Registration systems in the US are a recent occurrence, and they overlay the traditional common law rules.

A gross generalization, but Napoleonic civil law systems emphasize formal transactions centrally administered by the state, while the common law emphasizes looking to the substance of private transactions, and usually only when a dispute arises (otherwise you just presume they're valid). Broadly speaking, De Soto argued the latter tended to favor the common man, because it was much less rigid.

De Soto also pointed out that US Federal Land Grants also did a decent job at distributing land among the people, unlike Latin America where mostly only the aristocracy held land under a good title.

The problem is you also can't [easily] go fishing looking for parallel construction. Part of a parallel construction scheme is maintaining plausible deniability for the prosecution team and the trial witnesses.

Prosecutors sometimes lie. Normally they're just handed a case file with already laundered evidence, and it's not their responsibility to look behind the facially legitimate evidence.

Condemnation proceedings are the exception. Most of the time, the entity taking the land under the threat of eminent domain offers substantially above FMV, if only because condemnation proceedings cost money and, more importantly, time.

Some states do require above FMV for condemnation, e.g. 120%. After Kelo in the early 2000s, almost every state passed significant eminent domain reform.

It's more misleading than that. The power line that "may" "primarily"[1] serve a private data center has started construction "after nearly 20 years of planning, permitting and lawsuits"[2].

Per usual, NIMBYs continually move the goal posts and rely heavily on rhetoric to oppose a project. Data center opposition is providing them with great PR fodder, but they would have opposed these projects regardless. This is why infrastructure is so incredibly expensive in this country.

[1] https://www.oregonlive.com/environment/2025/11/oregon-regula...

[2] https://www.oregonlive.com/environment/2025/10/a-300-mile-po...

In the 1984 Social Security was in the same situation it was today. To balance things Congress (among other lesser measures) set a new schedule for bumping the retirement age, the last step of which only took effect recently. It's not a coincidence. It's been over 40 years since then; it had been 49 years between then and the creation of Social Security.

The narrative is that Social Security is broken because previous generations were idiots who didn't understand or care that lifespans would increase, yet chose to create a fundamentally unsustainable entitlement program anyhow. But lifespans are right on track today as expected in 1984, just like lifespans in 1984 were exactly where actuarial tables predicted them to be in 1935. And Congress in 1984 expected their successors to do today what the 1935 Congress expected of them. A program isn't fundamentally broken just because periodic maintenance is required. OTOH, in theory the 1935 Congress could have attempted to implement a perpetually self-healing, self-executing algorithm, as could have the 1984 Congress. They didn't because politics doesn't work that way; kicking the can down the road to a future Congress is typical, though kicking it 40-50 years down the road is pretty laudable, all things considered.

Obamacare did try to create a self-executing process to reevaluate costs, and it failed miserably, because it required perennially revisiting contentious points of policy, and to do so outside Congress. The president had the responsibility, but no accountability, because failure would be blamed on Congress, and the Democrats especially. In that light, the approach taken wrt Social Security seems prudent.

The narrative and word choices are deliberate. Republicans want to get rid of Social Security. So the narrative is Social Security is fundamentally broken, and it can be silently ended through passive negligence without having to take responsibility for ending a popular entitlement. No matter that it was created with the expectation that Congress would periodically adjust the retirement age to keep it solvent, and that it was always intended to provide only a bare minimum benefit, just enough to keep you out of the poor house. Poor houses were real, common things back then, and what the "free market" will result in.

Social Security revenue and expenditures can easily be balanced in theory. But neither party wants to do the right thing--Democrats want to expand entitlements, and increasing the retirement age as originally designed is the opposite of their goal.

Doesn't directly answer your question, but the CNBC article appears to be correct. See https://www.faa.gov/newsroom/faa-statement-boeing-airworthin...

The FAA stopped allowing Boeing to issue airworthiness certificates for 737 MAX airplanes in 2019 during their return to service following the Lion Air and Ethiopian Airlines crashes, and for Boeing 787 airplanes in 2022 because of production quality issues.

AFAIU, when beef prices started to spike a year or two ago, ranchers decided to cash in and slaughter much of their herd, including breeding stock. This was on top of a decades-long decline in herd size, and a recent drought that has driven up costs of maintaining a herd--another reason why they decided to cull and cash-in.

The current situation will be the new normal for at least the next several years. Chicken hasn't risen nearly as much, just moderately more than inflation, perhaps because of a shift of demand away from beef.

There also seems to be greater price discrimination going on with beef than previously, with larger spreads between, e.g., bulk ground vs vacuum packed ground vs whole cuts.

I built a benchmark harness for exploring compression of Lua script source files embedded in a Lua app binary as individual static constant C arrays. I settled on gzip, specifically deflate/inflate. Deflate does as well or better for small source files compared to xz, bzip2, and zstd.[0] More importantly, the inflate algorithm is tiny[1]; embedding the zstd decompressor blew up the binary.

I also explored building precomputed dictionaries, which means you can easily embed the files individually (C source file inclusion and runtime loading through the Lua C API remains relatively straight-forward compared to gymnastics of parsing and transforming preprocessed files) while getting similar compression ratios as when compressing an enormous file (e.g. a concatenation of all the source files). This is trivial with the zstd reference utility. It's also simple for deflate, though you have to roll your own dictionary builder by hacking the zlib implementation, or just writing it from scratch[2]. But I never bothered implementing it beyond the benchmark harness. I probably would have stuck with deflate rather than switching to zstd just because the compiled inflate implementation is so small.

[0] This is because the greatest advantage of the alternatives over deflate is the larger dictionary size they build up; deflate has a very small, upper bound. But for short inputs this advantage is diminished.

[1] https://github.com/madler/zlib/blob/develop/contrib/puff/puf...

[2] https://blog.cloudflare.com/improving-compression-with-prese...

Pigs, chickens, rats, and humans all have different thresholds and responses to hypoxia, and CO2 in particular. What might be humane for humans can be extremely distressing and painful for a particular animal, and vice-versa. There's a significant amount of research exploring these responses. The gassing protocols are driven by solid science; alot more solid than nitrogen asphyxiation for humans. Though, how well the protocols are followed is a different matter.

This is true in Singapore and Malaysia, as well, where Filipino or Indonesian cooks and housekeepers are extremely common, as are separate entrances--typically into the kitchen. In Malaysia there's an odd situation, the reverse of the dynamic in the US, where Indonesian servant immigration is encouraged as a way to grow the Muslim population and help diminish the political power of Chinese-Malaysians and Indian-Malaysians.

Serfdom wasn't legally abolished in Russia until 1861. Slavery was technically abolished in the late 1700s, but in some areas serfs were still bought and sold like chattel until the end of serfdom.

The Ottoman Empire legally abolished slavery in the 1880s, but there was still illicit yet tolerated slavery in Turkey into the 1930s.

I think in some areas of the Sahel chattel slavery may still exist as a practical matter. Mauritania didn't legally abolish chattel slavery until 1981, for example, but as in other areas it can take decades for reality to match the law, given the laws were often changed under international pressure rather than reflecting any change to the domestic social order.

You can do it in Canada. Canada is on a euthanasia tear, and something like 3-4% of all deaths are by euthanasia or assisted suicide, and on track to reach double digits in the coming years. But euthanasia for dementia is a fine ethical line to navigate (Canada notwithstanding) because consent is either absent or suspect when the time comes.

Room & board constitutes 1/2 - 2/3 of the cost of undergraduate school. Even in European countries with free tuition (and that's not as common as you think) students still often must take out loans for living costs. With financial aid the typical American student ends up financially similarly situated to their European counterparts.

The problem of college affordability is arguably another dimension of the housing crisis. You can look at the numbers yourself. Yet oddly I've never seen this pointed out or discussed, not in the media or anywhere else.

In principle an easy way to lower the cost of college would be for public universities to invest in building more subsidized or free dormitories. The problem is that most of the popular coastal universities are in areas where development is absurdly expensive and contentious, even for government.

Nobody in Ukraine is separated from the carnage, least of all the soldiers. The value in the points system is in communicating target priorities down the line. It's just another technological improvement in the vein of, say, the radio. All technological improvements will seem to have the effect of dehumanizing people. But war is fundamentally dehumanizing. In fact, for most soldiers dehumanizing the enemy is a necessity, because otherwise they can't pull the trigger. The dehumanization to be worried about is the dehumanization of people from the perspective of non-combatants, especially those isolated from the war, like Americans.

Where technology creates greater moral hazards in war is when it helps insulate the leadership and population from the consequences of war, and so lowers the sociological and political costs to violence. In that sense having a professional rather than conscripted army should be much more morally repugnant than e-points. Again, no one in Ukraine is isolated from consequences in any meaningful way.

The Ukraine War is the most televised war in history. Especially in the beginning I forced myself to watch the videos, just so I wouldn't get lost in abstraction. The human suffering is gut wrenching. You can watch men getting shredded down; soldiers embracing each other in fear and helplessness moments before they're killed or maimed. Debates over e-points, to me, reflect a failure to appreciate the reality, a reality which is only hidden from one's view by choice. (After a few videos that left me crying, I figured I saw enough to ensure I was dutifully more engaged with the reality than the typical non-veteran at a comfortable remove.)

If anything drones and the necessity of having to record a kill for "points" is arguably an improvement over traditional aerially bombardment. Being forced to watch people injured and killed comes with a greater cost, even for veteran soldiers. On HN we take for granted that, e.g., Facebook employees forced to sift through child porn continually pay a price no matter how long they've been at the job, yet seem to assume soldiers watching a drone video feed feel no different than playing a video game. That perspective betrays a certain callousness that is in some respect even more worrisome than these technological advancements on the battlefield.

The point was just that gameification is just a modern word that doesn't reflect any change in behaviors. Presumably you were familiar with these practices under previous descriptors. And your moral objections would have been shared by many millions before you, long before gameification was coined.

On the other side of the coin to thinking there's something new about the way war is waged are the people who think they can wage war without the same consequences as befell nations before. It's fundamentally the same err, IMO. So I take moral objection to the pretense that there's something morally novel to criticize. This stuff is what happens in war, always. And things can get way worse than this, and will get worse the longer we tolerate open hostilities among nations.

Temporal API seems to be based around Unix/POSIX timestamps, which ignore leap seconds. In Unix time a day is always 86400 "seconds". This makes it trivial to do UTC calendar arithmetic into the past and future without recourse to a database and without necessarily having to deal with fractional seconds. Leap seconds are handled by the OS by repeating or skipping a second, or slewing the length of a second for some period before and after the leap second.

Most datetime APIs are fundamentally designed and intended for supporting calendar and wall clock operations for business functions. If you need SI seconds for scientific purposes, you really need to use alternative APIs and facilities that provide and guarantee the semantics required all the way down to the hardware level. Likewise, if you want timers, etc, for software facilities like thread sleeping, you use dedicated interfaces like monotonic clocks. If leap seconds are phased out, this won't really change the situation. It was wrong for software to rely on Unix timestamps for, e.g., mutex algorithms before and it'll be wrong if and when leap second clock adjustments are gone.

To the extent Xi Jinping isn't seriously interested in invading Taiwan (and that seems dubious), he still needs to keep the PLA and other factions thinking he does. Reclaiming Taiwan is a pillar of PLA ideology and strategic doctrine. PLA culture is why China has never forced its will in North Korea despite continued disobedience to Beijing--the old guard in the PLA feels honor bound to defend North Korea's independence, rather than making it a client state, which it easily could do. It's similar to defense policy hawks in the US regarding Middle East intervention, who have nominally always been a minority faction. Perennial Middle East intervention never made much sense, and yet it keeps happening over and over, even when the military is woefully unprepared (e.g. Iran), because that faction is adept at manipulating defense policy, and has been playing the same long game since the 1990s. Which is precisely why the Taiwan threat is real. China isn't a political monolith, and the forces pushing to invade Taiwan, even if presently held at bay, could succeed in a blink of an eye, even without China being properly prepared for a successful invasion.

A state of affairs you can thank the US for.

Egypt was a military dictatorship long before they were American allies. You can thank Nasser for that. Repproachment with Egypt in the 1970s was a diplomatic effort to stop the fighting between the Arabs and Israel, and to win over a Soviet ally.

The US supported the democratic movement and even helped ease the way. In fact, alot of Middle Eastern countries are still resentful for American support of the Arab Spring. But it couldn't stop, and admittedly wasn't particularly interested in stopping, the regression back to a military dictatorship in Egypt given the elected president was about as democratic as Turkish president Erdogan. But it never intervened, AFAIU, because while dysfunctional, Egypt is relatively stable from an international perspective and a reliable-enough American ally either way.

I don't understand the conflation of multiplexing and multicasting. Are we talking about the same multicasting? (https://en.wikipedia.org/wiki/IP_multicast)

Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.

Yes and no. Had there been more demand it would still be around, of course. But one of the reasons (albeit a lesser reason) there wasn't much demand was because of the antiquated engine tech. The poor A380 fuel efficiency competitiveness had less to do with it having 4 engines than that those engines were 1990s tech, same generation as on the 777, despite the first delivery of the A380 being more than 10 years after the 777. The 787 and A350 were favored by the industry not only because of point-to-point, but because their engines had far better fuel efficiency. (Even at the same generation, ETOPS aircraft would have slightly better fuel efficiency, but maintenance and overall operational cost is significantly higher because of the power envelop and reliability margins required, keeping the quadjet A380 cost competitive.)

Both Airbus and Emirates were willing to keep the A380 alive. Emirates was making money on it, and Airbus believed the market would eventually turn as airports reached takeoff/landing capacity. But Emirates wanted upgraded engines, so for several years there were negotiations between Emirates & Airbus on the one hand, and the big 3 engine makers on the other. IIRC, circa 2018 Emirates & Airbus were very close to a binding agreement with Rolls-Royce for an upgraded engine, but then Rolls-Royce faced costly issues with its existing programs. At the same time, prospective investment in the engine industry had already started winding down, and Rolls-Royce didn't want to be spending cash on a new program while GE and Pratt & Whitney were passing through profits to shareholders. So in 2019 Rolls-Royce walked away, and shortly thereafter (weeks if not days), Airbus and Emirates agreed to terminate the A380.

It's difficult to find non-paywalled sources, but see, e.g., https://www.forbes.com/sites/michaelgoldstein/2018/10/16/is-...

I think a lot of the jet engine manufacturers are seeing this same corporate rot process, the number of high profile scandals across the industry and reports of insiders on how the number crunchers are taking over the business are strangely reminiscent of what we heard out of Boeing and Intel.

And there's the opening for China. The 90s and early 2000s saw alot of innovation by engine manufacturers. Boeing and Airbus built their planes around the next generation of engines coming out. But over the past 10 or so years all the major engine manufacturers decided to stop investing in new civilian engines and maximize their dividends on existing models. That's what killed the A380--the A380 engines are 90's tech, and all the engine manufacturers declined to build a new engine for an upgraded A380, not even one that utilized the current tech, and not even if Airbus backstopped potential losses.

So now is probably the best time since the 1980s for China to play catch-up. But the biggest problem is as you pointed out--engines and airframes are developed together, and both Airbus and Boeing also decided to stop new aircraft development and instead coast and reap dividends for the next decade or two, so there's no market for China to break into. There's still development happening in the defense space, but that's not a market open to China, either. Their only potential market is primarily domestic, and it's not capable of incentivizing and demanding dogged innovation in the same way the international market could.

Weapons systems like the Tomahawk and HIMARS are continually evolved, especially the electronic systems like navigation and command+control. The iteration isn't nearly as fast as in other industries, but the modern incarnations are not 30+ years old, AFAIU, old stockpile notwithstanding.

That's also why they're so damned expensive, and why it's difficult for upstarts to break into the market with cheaper alternatives. Like any tech company, once they get the customer locked into a platform they're constantly pushing upgrades to both stay technologically competitive and, more importantly, keep their margins high.

I couldn't find any evidence Google pushed QUIC with the aspiration of utilizing IP multicast.

In 2022 an RFC for adding multicast support to QUIC was published, but backed by Akamai, not Google. And of course the RFC has the caveat that it would only be useful over multicast networks, e.g. edge servers colocated at an ISP. It seems this effort has picked up some steam over 2025 and 2026.

But I didn't look too hard. Can you share sources?

They claimed and showed QUIC slightly-to-moderately reduced latency, particularly for mobile. This benefits Google by loading pages with third-party content, i.e. ads, faster.

But QUIC significantly increases CPU utilization on servers, at least the widely used userland stacks do. Unless/until Google deploys QUIC in the kernel (or puts the whole network stack in userland, a la DPDK), this won't change.

The multicast claim is kinda bizarre. I can see how QUIC could help eliminate UDP client barriers, but those barriers pale in comparison to multicast. Multicast routing just doesn't exist on the Internet; it's only supported within some independent, typically small networks. Most ISPs don't support it. Wherever you could manage to distribute content with multicast, you'd necessarily also be resolving the collateral routing problems which QUIC support resolves, whereas even ubiquitous QUIC doesn't materially improve the multicast situation.