SaberTail

The name is misleading. The glyphs are showing individual chord shapes. I can't write out a song using this. At best I can use this at the top of a tab to remind myself how the chords are meant to be shaped. But that doesn't appear to work much beyond the basic cowboy chords. For example, I tried 577655 which is an A major barre chord, and it didn't render. I realize a font can only do so much, but I wouldn't pay for this.

I said to a few friends that the recent trailer felt like it could be for a House of Leaves movie. Different overall setting, but the "found footage" aspects, and the narrative over it, felt like they could be right out of the Navidson Record.

I don't have any real proof for this, but it feels like House of Leaves inspired a lot of the people making "found footage" and "creepypasta" stuff one the internet in the 2000s and early 2010s (SCP, Marble Hornets, Slender Man), and then that stuff came together to inspire the Backrooms.

The term I've heard for this sort of thing is "Physical Neural Networks" or "PNN"s. My impression is that one of the big things holding them back is that because we can't manufacture components to perfect tolerances, you can't train a single model and reuse it like you can with digital logic. Even if you can get close, every single circuit needs some amount of tuning. And we haven't worked out great ways to train them.

There's a lot of research going on in this space though, because yeah, nature can solve certain mathematical problems more efficiently than digital systems.

There's a decent review article that came out recently: https://www.nature.com/articles/s41586-025-09384-2 or https://arxiv.org/html/2406.03372v1

The "figure out what you want to say" is key. I've started to think of LLMs, at least in a business setting, as misunderstanding amplifiers.

How many times at work have you been talking to someone else where they're using common words as jargon? Maybe it's something like "the online system" or "the platform". And it's perfectly clear to them what they mean, but everyone else in the company either doesn't know what that actually is, or they have a distorted idea based on the conventional definitions of the words. Even without LLMs in the mix, this can lead to people coming out of meetings with completely different understandings of what's going on.

My experience is few people are actually providing the relevant context to the LLM to explain what they mean in situations like this. Or they don't have the actual knowledge and are using the LLM in the hopes it'll fill in for their ignorance. The LLMs are RLHFed to sound confident, so they won't convey that they don't know what a piece of jargon means. Instead they'll use a combination of the common meaning and the rest of the context to invent something. When this gets copy/pasted and sent around, it causes everyone who isn't familiar to get the wrong idea. Hence "misunderstanding amplifier".

To the point of the article, this is soluble if people take the time to actually figure out what they are trying to convey. But if they did that, they wouldn't need the LLM in the first place.

as far as MSHA is concerned it is. They take salt out of the ground to make room for the waste.

This doesn't seem to be complete. It's missing the Waste Isolation Pilot Plant, for example, which should be southeast of Carlsbad, NM. It's a underground salt (metal/non-metal) mine, and MSHA definitely regulates it

The poetry you quoted is originally by Vladimir Nabokov in Pale Fire.

I'd speculate we had a few factors working against us that made us hit the "limit" sooner.

Several different engineering teams from different parts of the company had to come together for this, and the overall architecture was modular, so there was a lot of complexity before we had to start integrating. We have some company-wide standards and conventions, but they don't cover everything. To work on the code, you might need to know module A does something one way and module B does it in a different way because different teams were involved. That was implicit in how human engineers worked on it, and so it wasn't explicitly explained to the coding agents.

The project was in the life sciences space, and the quality of code in the training data has to be worse than something like a B2B SaaS app. A lot of code in the domain is written by scientists, not software engineers, and only needs to work long enough to publish the paper. So any code an LLM writes is going to look like that by default unless an engineer is paying attention.

I don't know that either of those would be insurmountable if the company were willing to burn more tokens, but I'd guess it's an order of magnitude more than we spent already.

There are politics as well. There have been other changes in the company, and it seems like the current leadership wants to free up resources to work on completely different things, so there's no will to throw more tokens at untangling the mess.

I don't disbelieve the success stories, but I think most of them are either at the level of following already successful patterns instead of doing much novel, or from companies with much bigger budgets for inference. If Anthropic burns a bunch of money to make a C compiler, they can make it back from increased investor hype, but most companies are not in that position.

I was on a greenfield project late last year with a team that was very enthusiastic about coding agents. I would personally call it a failure, and the project is quietly being wound down after only a few months. It went in a few stages:

At first, it proceeded very quickly. Using agents, the team were able to generate a lot of code very fast, and so they were checking off requirements at an amazing pace. PRs were rubber stamped, and I found myself arguing with copy/pasted answers from an agent most of the time I tried to offer feedback.

As the components started to get more integrated, things started breaking. At first these were obvious things with easy fixes, like some code calling other code with wrong arguments, and the coding agents could handle those. But a lot of the code was written in the overly-defensive style agents were fond of, so there were a lot more subtle errors. Things like the agent adding code to substitute an invalid default value in instead of erroring out, far away from where that value was causing other errors.

At this point, the agents started making things strictly worse because they couldn't fit that much code in their context. Instead of actually fixing bugs, they'd catch any exceptions and substitute in more defaults. There was some manual work by some engineers to remove a lot of the defensive code, but they could not keep up with the agents. This is also about when the team discovered that most of the tests were effectively "assert true" because they mocked out so much.

We did ship the project, but it shipped in an incredibly buggy state, and also the performance was terrible. And, as I said, it's now being wound down. That's probably the right thing to do because it would be easier to restart from scratch than try to make sense of the mess we ended up with. Agents were used to write the documentation, and very little of it is comprehensible.

We did screw some things up. People were so enthusiastic about agents, and they produced so much code so fast, that code reviews were essentially non-existent. Instead of taking action on feedback in the reviews, a lot of the time there was some LLM-generated "won't do" response that sounded plausible enough that it could convince managers that the reviewers were slowing things down. We also didn't explicitly figure out things like how error-handling or logging should work ahead of time, and so what the agents did was all over the place depending on what was in their context.

Maybe the whole mess was a necessary learning as we figure out these new ways of working. Personally I'm still using the coding agents, but very selectively to "fill-in-the-blanks" on code where I know what it should look like, but don't need to write it all by hand myself.

And then they'll start feeding in data like gaze tracking, and adjust the generated content in real time to personalize it to be maximally addictive for each viewer.

It's most notes, and for EU and US notes (as well as some others), it's based on a certain pattern on the bills: https://en.wikipedia.org/wiki/EURion_constellation

And meanwhile today you can get more power than the Cray-1 (or Cray-2) from a single chip a fraction of the size of that coin.

Very quickly:

  a dollar coin is about 550 mm^2 on a face
  the Cray-1 could do 160 MFLOPS
  an M1 chip has a die size of 120 mm^2
  an M1 chip can do over 1 TFLOPS

The last line about "simplifying approximations within the literature[...] applied outside of their intended context" makes me think the author has an issue with the way other theoreticians are using LIGO data in their analyses.

I'd suggest a better analogy would be telecommunications fiber[1].

[1] https://internethistory.org/wp-content/uploads/2020/01/OSA_B...

California requires a warning a month in advance for anything a year or longer. Pointing out this law has gotten me a few refunds from services that failed to comply and renewed my subscription without telling me.

https://leginfo.legislature.ca.gov/faces/codes_displayText.x....

Currently, domain specific languages written in YAML. I see these everywhere, from configuring individual utilities to managing giant architectural stacks. People get in their heads that YAML is more easily written and read than code, and so instead of just writing the code to do something, users have to deal with a bunch of YAML.

The drawbacks of YAML have been well-documented[1]. And I think it's worse now in the LLM era. If I have a system that's controlled via scripts, an LLM is going to be good at modifying those scripts. Some random YAML DSL? The LLMs have seen far fewer examples, and so they're going to have a harder time writing and modifying things. There's also good tooling for linting and checking and testing scripts to ensure LLM output is correct. The tooling for YAML itself is more limited, even before getting into whatever application-specific esoteric things the dev threw in.

[1] https://noyaml.com/

CFIT is not necessarily pilot error. For example, if ATC vectored a plane without ground proximity warnings into the side of a mountain, that would also be CFIT.

On the one hand, it sounds very stressful. On the other hand, if you screwed up, you wouldn't even notice because your brain would be obliterated before it would register.

dupe: https://news.ycombinator.com/item?id=44127739

You can search the official python docs on DDG with !python. So if you search for "!python sum", it takes you right there. They have a lot of other "bangs" that work really well, too: https://duckduckgo.com/bangs

I got my PhD at Stanford. There were a few things that made me choose it over others. First, there are effectively 3 physics departments, between physics, SLAC, and applied physics (which is a different program, but still the resources are there. This gives you more choices in what to do. And the rotation system is good for trying labs and fields out before you make a decision.

I don't know much about your field of focus, so I can't speak about potential advisors too much.

You're now entangled with the system, and so we will need someone else to observe you.

The control is daylight, where countless species of life survive on a daily basis. You are comparing the hypothesis that life can survive with very little light to the hypothesis that it needs normal amounts of light to survive.

My impression is that there are a lot of geeks out there who want the Star Trek holodeck, and they see VR and generative AI as a way to get there. But they ignore all the episodes that explored the ways such a technology could be harmful, socially and psychologically and physically.

The "cold copper" accelerator technology is really neat, in my opinion. The way particle accelerators work is that they pump RF through waveguides into cavities, such that the electric field pushes on the electrons right as they enter the cavity. Historically, they've been built with geometry like cylinders and rectangles where the fields can be worked out analytically, and that can be fabricated easily. They're proposing using modern computational modeling techniques to design better cavity geometries that can then be fabricated with modern CNC techniques. That should allow more efficient accelerators and higher acceleration gradients.

I don't remember it that way. I took it more more as being about the definition of "fish", and demonstrating that whalers don't think about things the same way that non-whalers do. It's not ignorance; he acknowledges repeatedly throughout that whales breathe air, and nurse their young, and other mammalian traits.

I don't think it's anything so interesting. The FM band starts at the round number of 88.0 MHz and ends at 108.0 MHz. To divide that evenly into 200 kHz channels without bleeding over the ends of the band, they have to be centered at the odd decimal points.

There's no climate scenario in which Mars is more habitable than Earth. Even if a Texas-sized asteroid crashed into Earth, Earth would still be more habitable than Mars.

Taking a public asset and reserving it for exclusive use by certain individuals is not right: Thats a fancy way of saying: parks are not campgrounds. These types of policies are plain wrong, and cities should know better by now.

How do you reconcile this with the existence of private property at all? The lands of the planet earth were not formed with deeds attached.

I think it's at least plausible that ADHD traits could have been useful in the hunting and gathering environment humans evolved in. Being more inclined to pay attention to new things in your environment might make you more likely to discover threats and new food sources. Being able to hyperfocus might be useful if you are practicing persistence hunting and following prey for hours. These traits become a "disorder" because they're not as well suited to capitalist modes of production.