nighthawk454

Ironically, no

I recall an article on personalized pricing that had it reversed - the poor pricing is actually higher, bc it's harder to buy more at bulk rate / shop around / just not buy it (discretionary).

I'm inclined to agree. While not always appropriate or popular, it makes some sense to me to have the visual weight/area of the code being ~proportional to it's significance. Communicates the ideas more clearly. Instead of spending the majority of space telling me what _isn't_ going to happen, and hiding what is.

I often find myself wishing this was more ergonomic in languages.

That doesn’t look super awful to me? Hardly extreme code golfing.

The far more interesting part is the order of magnitude. If they can pull off a 20k LOC with zero dependencies (implying a pretty concise project size) and it still works well on meaningful applications, that’s pretty neat. A 1000x reduction in code size and matching/exceeding in perf is worth looking at. Probably also implying a better architecture as code golf isn’t gonna get you 1000x less code. Again - their claims not mine, so we’ll see.

But at that point they can triple the LOC to 60k with nothing but white space, new lines, and comments, for all I care. It won’t even add a zero.

Amazing! I wonder if the Every Noise At Once[1] site could be updated with the metadata from this?

[1] https://everynoise.com/

I’m working on a new UMAP alternative - curious what kinds of improvements you’d be interested in?

Mentioned in the article's comments:

> Why not use UUID7?

> "ULID is much older than UUID v7 though and looks nicer"

For those unfamiliar, UUIDv7 has pretty much the same properties – sortable, has timestamp, etc.

ULID: 01ARZ3NDEKTSV4RRFFQ69G5FAV

UUIDv7: 019b04ff-09e3-7abe-907f-d67ef9384f4f

Of note, Sam’s co-founder in Atomic Semi is none other than Jim Keller (!)

On the contrary, I think that was a wonderful answer and reflects the POV well. Hard to imagine something more Stallman-esque!

Ghostty is a terminal like iTerm. This compiles it so it runs in the browser directly, or browser-based environments like VS Code or the Hyper terminal. Without that you’d have to reimplement a whole terminal in JavaScript. Which is what people have been doing with via the xterm.js project. Naturally, there is effort and bugs that go into maintaining a clone/port like that. This lets you use the Ghostty terminal code directly - compiled to WebAssembly and with no other dependencies - as an API-compatible drop-in replacement

There are a couple philosophies in that vein, like finitism or constructivism. Not exactly mainstream but they’ve proven more than you’d expect

https://en.wikipedia.org/wiki/Finitism

https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...

Simple, they’re arbitraging the overhead of switching. The game is not to balance quality and dissatisfaction. It’s to balance quality against dissatisfaction + cost of doing something about it. If you just make the switching cost really really high, you can justify pretty much arbitrary levels of dissatisfaction.

The gap between noticing something is unsatisfactory and successfully doing something about it (capital, time, effort, risk, market share, …) is massive. It’s really only the second line they have to worry about. If the customer is unhappy but it’s too hard/expensive to switch, or there’s no other options, etc that’s really not a problem. It might even be good for “engagement” or whatever.

The gap is even wider when there’s extra barriers like network effect (dating apps) or legal rights (tv, movies, music). And the more things tilt in that direction - inherently cheap products with huge artificial moats - the more power they have. Every tick up of market capture fundamentally justifies another tick down in quality and/or an increase in price, when needed. This is just the ‘enshittification’ concept we’ve come to know.

Worst case, like another comment mentioned, when the market occasionally does produce something notable - let them do the legwork then buy it. And the bigger entities get the easier that becomes. They get harder to catch up to, while gaining more money and influence to purchase a competitor.

This isn’t 2005 where you can just make a social network or streaming platform with no consequences and take over the world. You’re not even allowed to make the app without permission.

AND as the article mentions, our only classical defense is ‘vote with your wallet’. Which presumes that a critical mass of people would be informed, willing, organized, and able to structurally boycott. Clearly we’re not equipped for that kind of economic warfare on every front from burritos on up.

And as the consumer continues to weaken economically, we actually get less power.

> But if they are actually doing that (which is unclear to me) or if they are bad in some other way, then how do they get away with it? Why doesn’t someone else create a competing app that’s better and thereby steal all their business? It seems like the answer has to be either “because that’s impossible” or “because people don’t really want that”. That’s where the mystery begins.

Pretty much all the article’s examples are known to be happening. As to why - it’s essentially because it’s impossible, just not because no one can code a dating app. Consumers have no real leverage. There is structurally no back-pressure on this in any way, by design.

Nothing worse than a screw you dont have a driver for. I resolved to just have drivers for everything

https://www.ifixit.com/products/mako-driver-kit-64-precision...

If the playlist is something like a CUE file then yes, certainly. CUETools/XLD/foobar2000 can split by cue file. And Picard can do audio fingerprints to match tracks and get metadata for them.

Developing a fingerprinting method for identifying music masterings! Like Shazam but to tell what version of an album you have.

The idea being able to compare measurements to see what mastering you're really getting - because they are NOT all equal. With the remasters and stealth replacements on streaming, it seems like every other month I wake up one day and my favorite music sounds worse (or is gone...). Now I can measure it and help find what versions I really want to collect!

I may end up trying to make a fingerprint database/tool that sits in between MusicBrainz and Discogs. That way hopefully the community can standardize and quantify some of this info that only lives ad hoc in Steve Hoffman forum threads or partially on sites like https://dr.loudness-war.info

Neat! The idea is that _all_ output embeddings must lie on a given ellipse. (On a hypersphere due to layernorm, distorted to an ellipse by the final linear layer).

Since the ellipse is given by the parameters of the model, it is characteristic to the model. And, you can pretty easily verify if a given embedding (probably) came from that model or not simply by checking if it lies on that ellipse.

Recovering the ellipse without access to the model weights takes large number of embeddings, so not terribly practical.

This easy-to-verify hard-to-forge property could naturally lend itself to use for fingerprinting. Noting that they call out it’s not cryptographic grade.

This study manages to find that drinking exponentially more per week is probably bad for you. I think that falls under 'no shit'.

The main aim seems to be to refute previous "U-shaped" and "J-shaped" studies that suggested a moderate amount of drinking was good because there was a dip in the distribution. Going so far as to suggest that moderate drinking must somehow be 'protective'. The explanation for that seems to be that those studies collected _current_ drinking use only, when presumably a history of binge drinking would still be quite relevant. This would artificially inflate the 'non-drinking' category with people who actually did have a history of drinking, while also deflating the moderate category. Apparently to the point that the moderate drinking levels looked even safer than non-drinking - which probably should've been a clue. In other words the data was probably pretty flawed, and garbage-in garbage-out.

As for this study...

"Genetically-predicted drinks per week" - are we serious with this?? Maybe they're claiming that their 'predicted models' align well with the smaller amount of surveyed self-reported data but that's hard to find in the paper.

They seem to bend over backwards to make alcohol causal, even going so far as to suggest that a decline in drinking behavior over the years may just be reverse-caused by the future dementia. And for higher incidence of dementia in non-drinkers - seemingly the opposite of the conclusion - that's explained away by suggesting those people may have just had a hypothetical prior heavy use, therefore the "reverse causation is further supported". Pretty circular...

I'm not sure how much more can be reasonably concluded from this other than health risks probably scale with drug use in some fashion. The data, methodology, and modeling seem far far too hand-wavy to suggest any kind of definitive explanation. The results barely even exclude 'no effect' in a 95% CI.

I would not be surprised for a second if effects like early cognitive decline correlate with decreased drinking habits, but I just don't see how you can conclude any of that from this.

I suppose if we're getting off the apparently very loosely suggested 'moderate drinking is good' myth, that's still progress, but...

Yeah, but it’s ’quantization aware’ during training too, which presumably is what allows the quantization at inference to work

Recently someone shared a method for encrypting the timestamp portion as well:

https://news.ycombinator.com/item?id=45275973

Also discussed at:

https://news.ycombinator.com/item?id=45070019

How To Make Everything on YouTube is along those lines

https://youtube.com/@htme

That’s Leland McInnes - author of UMAP, the widely-used dimension reduction tool

Another fun one :)

    import antigravity

Ha, Pandas just to parse a website is a bit extra, I’d say. But yeah, it’s weird that you need libraries and api endpoints to do basic tasks these days.

It feels like something broke around 2015-ish. Going back, you could make a whole app and gui with Basic. You could make whole websites simply with HTML+PHP, sometimes using nothing but Notepad. You could make portable apps in Java with no libraries - even Swing or whatever was built in.

Now…? Electron, a few languages, a few frameworks, and a few dozen libraries. Just to start.

Bizzare.

I think a lot of it is things have shifted away from the raw language. Less and less you’re dealing with Python, and more an assortment of libraries or frameworks. Pandas, numpy, torch, fastapi, …, and a dozen others.

Packaging has been a nightmare. PyPI has had its challenges. Dependency management is vastly improved thanks to uv - recently, and with a graveyard of tools in its wake.

The modern Python script feels more like loosely combining a temperamental set of today’s latest library apis, and then dealing with the fallout. Sometimes parallels the Node experience.

I think an actual Python project - using only something remotely modern like 3.2+ standard library and maybe requests - is probably just as clean, resilient, and reliable as it ever was.

A lot of these things are and/or have been improving tremendously. But think to your point the language (or really the ecosystem) is scaling and evolving a ton and there’s growing pains.

Essentially, when you buy in bulk you trade upfront commitment for a discounted price. Which isn’t a good deal unless you’re confident you’re going to use all the units/seats you bought.

This is the same logic as over buying at the grocery store. The unit cost of bulk items may be less, but if the surplus is just gonna spoil you’ve wasted money in the difference.

1.0 * N * discount_rate * price <= certainty * N * 1.0 * price

—> discount_rate / certainty <= 1.0

—> discount_rate <= certainty

In the event your confidence/usage is lower than the discounted rate - say discounted to 80% of sticker price but you expect 60% utilization - this might suggest you buy 60% of your capacity at the bulk rate and fill any further demand with on-demand full-price option.

You can even still mail a brick! As long as it’s addressed. Apparently other things too including flip flops, inflated beach balls, and potatoes.

They do call out that you can no longer mail enough to build a building haha.

https://facts.usps.com/sending-bricks-in-the-mail/#:~:text=I...

Seems to be a trend away from mean-pooling into a single embedding. But instead of dealing with an embedding per token (lots) you still want to reduce it some. This method seems to cluster token embeddings by random partitioning, mean pool for each partition, and concatenate the resulting into a fixed-length final embedding.

Essentially, full multi vector comparison is challenging performance wise. Tools and performance for single vectors are much better. To compromise, cluster into k chunks and concatenate. Then you can do k-vector comparison at once with single-vector tooling and performance.

Ultimately the fixed length vector comes from having a fixed number of partitions, so this is kind of just k-means style clustering of the token level embeddings.

Presumably a dynamic clustering of the tokens could be even better, though that would leave you with a variable number of embeddings per document.

Got it, makes sense! For the deformation, I mean would there be enough information to determine how a mesh of the eFlesh would be deformed, to cause the observed magnetic readings