klodolph

Honestly, I think the permissions model for desktop and laptop computers is way too permissive to begin with, I think it just kinda sucks and doesn’t do its job. Apple is kind of fixing it but there is a long way to go.

There have been alarm bells ringing in my head for a long time with all these settings, and the fact that they’re buried in the settings app gives me a lot of peace of mind. I’ll click through a lot of boxes and alerts and grant permissions that I shouldn’t. I’m SUPER glad that I won’t accidentally grant, you know, full disk access or accessibility to an app just by clicking on a box that appears at startup.

I remember back in the bad old days when I was constantly making extra user accounts just to run some program. Kinda sucked. Hard truth is, you sometimes want to run code that you don’t fully trust.

This particular permission is pernicious, ponder for a picosecond the possibilities:

It’s used for writing keyloggers.

That’s it. It’s the permission that lets you write a keylogger. It SHOULD NOT be just a click away. It should require some extra song and dance, because this is an especially dangerous permission, and the extra friction is justified.

> Why not scale to fill the available bins, though? i.e. trunc(result * 255.999)?

That’s half of the mid-riser staircase quantizer discussed in the article. (The other half is coming up with the reverse.)

(I would implement it as min(floor(x * 256), 255).)

Addition in this case is cutting from 2^64 to 2^33-1.

The 2^64 number is the number of inputs. For an operation which is commutative, you expect the outputs to be 2^63+2^32 or smaller, since you’ve introduced symmetry.

Sure, but I wasn’t thinking of the brokerage fees. Things like the spread.

It’s achievable. It’s called “direct indexing”, and there are some extra costs associated with it, so for most investors, I think it is cheaper to get QQQ. You can flip that around with tax loss harvesting but I don’t understand that strategy and I can’t explain it.

You also don’t need AI to do this. Before AI, the main barrier to direct indexing was the amount of capital you need. That is still true.

Because it is not possible for you (personally) to buy the underlying components of leveraged ETFs.

I realize I might have been mixing up QQQ with ultra pro QQQ… anyway, yeah, you can replicate QQQ. I was thinking of Ultra Pro QQQ.

Real question, where are you going to buy the swap agreements?

QQQ gets the leverage from, among other things, swap agreements and futures. I don’t think what you have could be reasonably considered “pseudo-QQQ”. It’s like copying a cake recipe, but leaving out the flour and eggs because they are too expensive.

Beautiful, lovely sentence fragments. Last I heard, I was on the HN em dash leaderboard, and now sentence fragments?

Interesting, but when I look at the sweater in the second image, the knitting just looks completely lost in the PICO vesion. The knitting looks correct but soft in other codecs. In the PICO version, it looks just completely wrong to me. The yarn structure has been replaced with a bunch of fuzzy strips. Similar problem in the third picture.

I guess this is what happens when you chase after extremely low data rates but I’m not happy with the results.

That definition of durable doesn’t seem useful to me, sorry. I want the failure rates and scenarios.

I used Claude to generate Haskell and it works really well. Claude struggles sometimes with respecting abstraction boundaries, but Haskell enforces parts of those boundaries in its type system better than a lot of other languages (if a module can’t do IO, for example).

Works well, in my experience. Sometimes the agent does weird stuff that you have to rewrite, but I get the sense that this happens in any language.

Maybe Haskell’s training set is not large enough, but it seems to work despite the smaller training set.

I like to think that the true AFR for data is bounded by something like 10^-3, because maybe that’s close to the rate at which civilizations collapse. You have to use a kind of subtle definition to support 10^-7 or 10^-9 or 10^-11. Or maybe instead of “subtle definition”, you can call it a “whimsical, imaginary definition”. Depends on how cynical you are.

The way I would go is by saying that you multiply the number of objects by AFR, and that’s close to the actual losses on most years. You can then exclude WW3 and the late holocene extinction event from your consideration. Or simple bankruptcy, for that matter. If your employer is gone, you don’t care about its data any more.

The half-remembered storage system I pulled those numbers from had records ~100G in size, so a 10^-7 loss is 1 loss event per year, per exabyte of data. A loss event is just “at least one bit in the record cannot be read within a certain deadline”.

Durability is a knob. If you have enough data, or turn the knob too far in the direction of durability, you will simply bankrupt yourself or maybe drown your service in latency. It makes sense that you would have storage services that provide different levels of durability.

I don’t have any respect for the viewpoint that “durable” is equatable with “stored on disk”, and I don’t want to spend time accommodating that viewpoint. It is just an oversimplification in a very bad way.

AFRs and discussions about different failure scenarios are the bare minimum. The bare minimum for scenarios is disk loss, total machine loss, and data center loss. This is just my take on things. I don’t care if something is on disk or not. I do care what happens when a sector on disk goes bad, when a faulty power supply destroys all the disks in a machine, or when a data center floods.

That forces you to think about things like whether you want to turn on synchronous replication.

:-/ it’s a statistical guarantee in the first place. A successful commit in a durable storage engine just needs to achieve some finite level of durability, like “10^-7 probability of loss per year”. The durability is a property of the whole system, and it is possible to achieve durability without fsync, you just may have a hard time explaining what the durability is, how you calculated it, and what the evidence or justifications are for the numbers you give.

Even if you just look at hardware failure rates, you get unrecoverable I/O errors (data corruption) at about one in 10^15 bits, disk failures at a rate of about 1% per year, etc. People usually like to have better guarantees than those numbers give you with just a plain fsync anyway; so you are probably forced to do an analysis of the whole system if you want to provide good durability guarantees and be able to explain where the guarantees come from.

People are also surprised how rural much of China is.

Ah, I was thinking of the editorialized HN title.

What part do you disagree with? It sounds like you don’t disagree with either the title of the article or its contents.

> In talking to engineering management across tech industry heavy-weights, it's apparent that software engineering is starting to split people into two nebulous groups:

> The first group will use A.I. to remove drudgery, move faster, and spend more time on the parts of the job that actually matter i.e. framing problems, making tradeoffs, spotting risks, creating clarity, and producing original insight.

> guess how that turned out?

My guess is that significantly fewer people use drugs than would have used drugs if they were not banned.

> "The Crime Survey for England and Wales (CSEW) estimated that 8.7% of people aged 16 to 59 years (around 2.9 million people) reported using any drug in the last 12 months for the year ending (YE) March 2025; there was no statistically significant change compared with YE March 2024"

Are there some significant changes to policy during that time period? I don’t see how this factoid is related to whatever argument you are trying to make.

There have got to be a million ways to do this by now. Some of the more principled approaches are tools like Nix (https://xeiaso.net/talks/2024/nix-docker-build/) and Bazel (https://github.com/bazel-contrib/rules_oci). But if you want to use an existing package manager like apt, you can pick it apart. Apt calls dpkg, and dpkg extracts files and runs post-install scripts. Only the post-install script needs to run inside the container.

I may be a little out of touch here, because the last time I did this, we used a wholly custom package manager.

IMO—package manager outside the container. You just want the packages inside the container; the manager can sit outside and install packages into the container.

It’s a variety of different software that just isn’t updated very often.

I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.

Recently I’ve been noticing that Nix software has been falling behind. So “the software you need is almost certainly there” is less true these days. Recently = April 2026.

> The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video.

NOT how demos work in Quake. It’s more like Quake uses a client/server architecture, and the demo is a capture of the messages.

https://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html

“Your own server in a colo” means going to the colo to swap RAM or an SSD when something goes wrong. You rent a server and the benefit is the rentor has spare parts on hand and staff to swap parts out.

NFS in practice is too different from S3 to make this work.

I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NFS server and you can get problems.

“You can get replication with RAID” is technically true, but it’s just not good enough in most NFS systems. S3 style replication keeps files available in spite of multiple node failures.

The problems I’m talking about arise because when you use an S3-compatible API on your NFS system, it’s often true that you’re rolling the dice with three different vendors—you have the storage appliance vendor, you have the vendor for the software talking to S3, and you have Amazon who wrote the S3 client libraries. It’s kind of a nightmare of compatibility problems in my experience. Amazon changes how the S3 client library works, the change wasn’t tested against the storage vendor’s implementation, and boom, things stop working. But your first call is to the application vendor, and they are completely unfamiliar with your storage appliance. :-(

> […] why would they sell bitcoin to continue funding their mining operations […]

There are usually some fixed costs involved and you need cash flow. Without cash flow, your business can shut down pretty damn fast. With cash flow, your business can stay around longer, maybe long enough for the economics to shift.

This sort of thing happens with oil. There are oil producers which sell at a loss. There was even a brief moment when the price of an oil barrel went negative, which meant that if you gave somebody a barrel of oil, you had to pay them for the privilege of taking that oil off your hands. Oil producers did not all shut down when that happened.

I am a little doubtful of the $19k figure anyway.

> It would actually make more sense to sell all their bitcoin, flood the market with coins to do the price, wait for large miners to collapse and then restart mining at hopefully lower prices.

This kind of market manipulation is not so straightforward.